Architectures Applicatives Microsoft

Architectures Applicatives Microsoft

Développement Windows Client / NUI / RIA

Version du document: V1.0

Contact : http://forum.archims.fr, archims-à-microsoft.com

  • Introduction
  • Vue d'ensemble
    • Schéma Synoptique
    • Vocabulaire
  • Caractéristiques d'une application Windows
    • Utilisation des ressources locales
    • Utilisation des ressources réseau
    • Mode déconnecté
    • Installation et mise à jour quasi-transparentes
    • Adaptation à diverses plates-formes matérielles
    • Sécurité
  • Les technologies de développement
    • WPF
    • Silverlight
    • Positionnement des technologies WPF, Silverlight et HTML5
  • Développement d'une application pour Windows
    • WPF : Vue d'ensemble
      • Architecture du framework WPF
      • Comment fonctionne WPF ?
      • Librairies du framework WPF
      • Structure d'une application WPF
      • Arbre logique WPF
      • Arbre visuel WPF
      • Les contrôles
      • Les « styles »
      • Les « ressources »
      • Les « control templates »
      • Les « data templates »
      • Les « triggers »
      • Les « animations »
      • Le « Visual State Manager »
      • Les Toolkits
      • Développement de contrôles
      • Plus de ressources sur le sujet
    • XAML : Notions élémentaires
    • Développement d’une application métier
      • Les bases du « Data Binding » : Objets métier, Collection & Notification d’interface
      • « Philosophie de développement »
      • L’annulation des modifications
      • La validation des données
      • Debugging du DataBinding
    • Les Design Patterns
      • Modèle M-V-VM
      • Pattern Command
    • Un axe de réflexion complémentaire : l’extensibilité
    • Framework de composition dynamique et injection de dépendance
    • Framework de communication et exposition des données
    • Le multilinguisme
    • Les performances
    • Le modèle de déploiement
    • La sécurité
    • Convergence Silverlight WPF
  • Les nouvelles interfaces utilisateur
    • Surface
    • Application Multi-touch Windows
    • Kinect
  • Synthese

Introduction

Ce document, qui évolue régulièrement contient les liens vers les ressources pertinentes concernant cette discipline d’architecture qu’est lDéveloppement Windows Client / NUI / RIA - Techno WPF, Windows 8, Surface, Kinect,

Ce document est disponible à http://rich-ui.archims.fr et sera mis à jour régulièrement dans ce dossier skydrive.

Si vous souhaitez nous faire part de remarques sur le document, nous suggérer des évolutions, n’hésitez pas à vous exprimer sur le forum des Architectures Applicatives Microsoft . Si vous préférez un lien plus direct, vous pouvez envoyer un mail à l’auteur de ce document à archims-à-microsoft.com.

Si vous avez un projet, vous pouvez également nous en faire part et nous contacter par ces moyens, de façon à ce que nous puissions vous aider à trouver le meilleur moyen de vous faire accompagner.

Vue d'ensemble

Schéma synoptique

Une vue d’ensemble du développement d'application Windows peut être être représentée par le schéma suivant

Vocabulaire

A compléter

Caractéristiques d'une application Windows

Les applications Windows peuvent présenter de nombreuses différences d’implémentation. La conception et les scénarios d’utilisation permettent de déterminer plus précisément les caractéristiques de ces applications. Certaines de ces caractéristiques peuvent être partagées. Les plus fréquentes sont décrites ci-après.

Utilisation des ressources locales

Une application Windows bien conçue doit exploiter le fait que le code et les données sont présents sur le client, le traitement et l’exécution de l’application restant en local. Cela permet d’offrir à l’agent une grande réactivité, une interface graphique riche et de puissantes capacités de traitement côté client. Par exemple, il devient possible d’envisager en local des manipulations complexes de données et des opérations de recherche, de tri et d’affichage sophistiquées. De multiples applications Windows peuvent être intégrées ou coordonnées afin de proposer une solution complète, efficace et cohérente. Ces applications doivent tenir compte du contexte de leur utilisation et doivent s'y adapter afin d'aider au mieux l'agent. Par exemple, elles peuvent mettre en cache les données appropriées en fonction du rôle de l’agent ou de l’usage qu’il en fait.

Utilisation des ressources réseau

Les applications Windows exploitent des services et des données en provenance du réseau en provenance de différentes sources et peuvent servir à les analyser et à les agréger. Les applications bâties sur ce modèle ene doivent pas se comporter comme des applications autonomes et doivent être conçues comme faisant partie d’une solution répartie globale. Elles doivent, au minimum, utiliser des services centralisés destinés à la maintenance, au déploiement et à la mise à jour. Les connexions établies leur permettent d’offrir de puissants services d’agrégation, d’analyse et de transformation de données. Dans de nombreuses situations, ces applications peuvent ainsi offrir des caractéristiques semblables à celles d’un portail : des services et des données disparates peuvent être coordonnés et intégrés dans une solution complète. Les services Web permettent aux organisations de proposer un large éventail de solutions métier personnalisées en facilitant l’accès par programme aux sources de données disparates et en proposant ces sources de données aux applications Windows. Tout comme les composants logiciels, les services Web sont programmables et réutilisables. Cependant, ils peuvent être déployés plus facilement sur un intranet ou via Internet et proposent une totale indépendance vis-à-vis de la plateforme.

Mode déconnecté

Prise en charge des agents connectés de manière occasionnelle Une application Windows peut être conçue pour apporter des fonctionnalités intéressantes lorsqu’elle est connecté de manière occasionnelle au réseau, lorsque la bande passante est réduite ou quand le temps de latence s’allonge, ou lorsque la connexion est intermittente. Même lorsque l'application Windows est connectée au réseau, elle peut améliorer les performances et l’exploitation en plaçant les données en cache et en exploitant au mieux la connexion.

Installation et mise à jour quasi-transparentes

De nombreuses applications imposent des impératifs d’installation complexes et partagent du code en enregistrant des composants et/ou en installant des bibliothèques dynamiques partagées (DLL) dans des répertoires communs à toutes les applications : cela conduit à fragiliser les applications et provoque des incidents lors des mises à jour. Les applications Windows peuvent être conçues afin de gérer leur déploiement et leur mise à jour d’une façon souple. Cela contribue à réduire les coûts d’administration des applications. Différentes procédures existent pour déployer des applications Windows. Il peut s’agir d’une simple copie sur l’ordinateur local, d’un téléchargement automatique du code à partir d’un serveur central, d’un déploiement automatisé, ou du déploiement de packages Windows Installer via une technologie de réplication par émission (« push ») Les applications peuvent se mettre à jour automatiquement, soit lors de leur démarrage soit en tâche de fond. Cela leur permet d’être mises à jour en fonction de leur rôle ou par étapes (la mise à jour suit un calendrier pré-établi).

Adaptation à diverses plates-formes matérielles

L’application peut être conçue pour s’adapter à l’environnement de l’hôte sur lequel elle fonctionne. Dans de nombreux cas, il est préférable de développer plusieurs versions d'une même application, chacune visant un type d'appareil spécifique, afin d'exploiter au mieux les spécificités de chaque plate-forme matérielle. Les appareils de petite taille étant par nature limités dans leurs fonctionnalités, ils ne peuvent fournir un accès mobile qu’à un sous-ensemble des données et des services exploités par une application déployée sur une plate-forme classique. Ces appareils peuvent aussi être limités à la collecte et à l’agrégation de données lorsqu’ils sont utilisés en déplacement, les données étant ensuite analysées et traitées par une application plus évoluée ou par un serveur. La faculté de comprendre l’environnement du système hôte et de s’y adapter, qu’il s’agisse d’un ordinateur de bureau, d’un ordinateur portable, d'un tablet ou d’un slate, afin de fournir les fonctionnalités les plus appropriées, constitue une caractéristique essentielle pour la plupart des applications Windows.

Sécurité

Les applications Windows peuvent englober de multiples produits et technologies. Sécuriser ces applications implique de considérer la sécurité du point de vue du serveur, du poste client, et de la communication entre les deux machines. Sur le serveur, la configuration de la sécurité concerne le serveur lui-même, le réseau et l’application. Sur le poste client, il est possible de mettre en oeuvre les mécanismes de sécurité de la plateforme (incluant le système d’exploitation et le Framework .NET), les opérations que le code lui-même est autorisé à effectuer (« Code Access Security ») et les interactions avec la plateforme serveur (domaine Windows, Kerberos,…) et l’application serveur. La plateforme Windows et le .NET Framework permettent aux développeurs et aux administrateurs d'exercer un contrôle de sécurité granulaire sur les applications de type « poste de travail intelligent » et leurs ressources en fournissant les mécanismes d’implémentation des fonctions d'authentification, d'autorisation, de propagation d’identité et de cryptographie.

Les technologies de développement

WPF

PF (Windows Presentation Foundation) est un système graphique unifié pour Windows : graphisme 2D, graphisme 3D, documents, animations, dessin vectoriel ou bitmap, audio et vidéo. WPF système graphique est basé sur Direct3D, et est vectoriel, pour le dessin comme pour le texte. Cela permet d'augmenter la taille des objets en fonction de la résolution de l'écran sans effet de pixellisation. L'affichage du texte se fait au moyen des procédés ClearType, TrueType ou OpenType qui améliorent le lissage des caractères. Il supporte l'affichage de nombreux formats d'images ou vidéo comme MPEG, AVI, et bien sûr WMV de Microsoft. WPF sépare nativement les données de leur présentation. WPF fournit les « widgets », les éléments d'interface graphique : fenêtres, bouton, champs de texte, menus, listes, ... La description de l'interface (donc des fenêtres, boutons, ...) peut se faire en XAML (« Extensible Application Markup Language »).WPF est le sous-système graphique de Windows. Il fait partie d'un runtime nommé .NET 3.0, une extension de .Net 2.0, disponible également pour Windows XP (SP2) et Windows Server 2003. Le but de WPF est de fournir un modèle de programmation unique pour le bureau et pour les applications sur le Web, beaucoup plus élaboré que le modèle classique de Windows XP.

Silverlight

Expérience utilisateur riche et multi-plateformes RIA (Rich Internet Application): Interactivité Contenu multimédia (vidéos, images) Animations Installation rapide pour les utilisateurs (plugin à installer la première fois) Multi-plateformes (Windows, Mac OS X, Windows Mobile) Multi-navigateurs (Internet Explorer, Firefox, Safari) Modèle de programmation riche et outils de collaboration Intégration avec les technologies Web Basé sur le Framework .NET 3.5 (Linq,…)Design et développement séparés

Matrice des caractéristiques Silverlight

Evolution des versions de Silverlight

Positionnement des technologies WPF, Silverlight et HTML5

Critères de choix technologiques

En synthèse, WPF est prévu pour des projets d'applications riches devant exploiter sans limite les ressources du poste de travail Windows, et de ce fait concerne principalement les éditeurs de logiciel (ISV). Il semble plus approprié de démarrer les autres types de projet avec Silverlight, quitte à migrer sous WPF si besoin (l'inverse étant beaucoup moins évident). Mais WPF est aussi conseilllé pour des projets mariant des technologies variées par sa bonne capacité d'intégration, qui favorise l'évolution en douceur des systèmes d'information : Win32/GDI (HWndHost), ActiveX (ActiveXHost), Windows Forms (WindowsFormsHost), HTML (WebBrowser) et Direct3D (D3DImage). La prochaine version de WPF permettra d'héberger du contenu Silverlight au sein d'un élément SilverlightHost, et de communiquer entre les deux technologies. WPF pourra ainsi bénéficier de fontionnalités spécifiques à Silverlight, telles que Deep Zoom. Microsoft travaille aussi à résoudre les problèmes de recouvrement, encore appelés problèmes d'espace aérien, qui apparaissent lorsque l'on fait cohabiter ces différentes techniques (à l'exception de D3DImage). Parmi les autres annonces, le composant ruban (Ribbon) sera intégré au framework, et la convergence avec Silverlight sera poursuivie (par exemple avec le portage de la classe Silverlight ChildWindow). Enfin, Microsoft travaille à améliorer la réactivité et les performances de l'interface utilisateur avec de gros volumes de données (multithreading, virtualisation, etc.).

http://blogs.developpeur.org/odewit/archive/2010/10/30/wpf-vnext.aspx

Développement d'une application pour Windows

WPF : Vue d'ensemble

Approche unifiée du développement : Texte, tracé, vecteur, images, audio, vidéo / Statique, dynamique, animée, en 2D ou 3D / Localisation, globalisation et accessibilité

Moteur de composition, intégré, vectoriel : Utilisation de la puissance du PC et de la carte graphique / Le moteur se charge du rendu, des animations, des transformations, et des effets

Programmation déclarative : Implication des designers dans le développement

Facilité d’exploitation : Déploiement et gestion sécurisée des applications

Architecture du framework WPF

Comment fonctionne WPF ?

Sans Composition Engine (Vista, XP ou 2003):

Les applications GDI fonctionnent de manière conventionnelle Les applications WPF créent des surfaces DirectX pour afficher leur contenu

Avec Composition Engine (Vista, Windows 7) :

Toute la surface d’affichage du bureau EST une surface DirectX Le dessin des applications GDI est redirigé vers un bitmap offscreen. Le Composition engine utilise ces bitmaps pour afficher les fenêtres à l’écran L’affichage via un bitmap offscreen permet des previews instantanées (sans Paint) et minimise les invalidations DirectX 10 coordonne la gestion des fenêtres GDI, WPF et DirectX à l’écran

Librairies du framework WPF

Structure d'une application WPF

Une application WPF est construite autour de plusieurs classes :

Arbre logique WPF

  • Création d’arbre d’objets
  • Chaque scène est composée en mémoire et affichée en une seule opération
  • Les commandes sont « bufferisées » et l’écran peut être réaffiché automatiquement (sans interaction avec le code de l’application)
  • Affichage des objets superposés au niveau pixel
  • Héritage de propriétés et d’évènements

Arbre visuel WPF

L’arbre logique WPF décrit seulement les relations : Insuffisant pour dessiner les éléments. WPF maintient un arbre visuel pour décider de la façon d’afficher les éléments
WPF étend l’arbre logique avec de l’information visuelle. Les contrôles sont composés de plusieurs éléments

Les contrôles

La plupart des contrôles classiques sont disponibles avec WPF. Ils possèdent plusieurs caractéristiques : Propriétés, Evènements, Méthodes et « DataBinding »

Grâce à la propriété « Content », on peut personnaliser le contenu d’un contrôle. Un contrôle WPF ne contiendra plus uniquement du texte mais pourra également contenir d’autres contrôles. Les contrôles WPF peuvent donc être décomposés sous forme de graphes d’objets

Possibilité de créer des « UserControl »

Les « ressources »

Par ressource, on entend: les styles, les « templates », les animations, Les transformations, les sources de données,...
La propriété « Resources » permet de définir les ressources qui seront utilisables par les contrôles Les ressources peuvent être locales (liées à un contrôle précis) ou globales (liées à un contrôle parent et utilisable par tous les contrôles enfants)
« StaticResource » : définition d’une valeur d’une propriété XAML sur la base d’une ressource existante. Cette valeur restera toujours la même.
« DynamicResource » : si votre ressource est liée à un composant qui va/peut changer alors votre ressource suivra les variations de ce composant. Ex : application dont le thème visuel est lié au thème Windows, il vous faudra donc utiliser « DynamicResource »

Les « styles »

Les styles permettent de définir l’apparence visuelle des contrôles. Ils sont définis pour un type de contrôle. Leur définition est localisée dans les ressources des contrôles. Ils s’inspirent des styles utilisés dans le développement Web, les CSS

Les « control templates »

L’arbre visuel d’un contrôle peut être redéfini via un « Control Template » en XAML : Définition par la propriété « Control.Template », Définition par un style, Analyse de la structure visuelle avec XAMLPad.
La structure visuelle du contrôle et ses fonctions sont découplées : Les « Control Templates » permettent de modifier le rendu du contrôle tout en conservant son comportement, Ajout d’un comportement visuel dynamique via des triggers définis au niveau du « Control Template »
Définition de contrôle personnalisé

Les « data templates »

Les « DataTemplate » sont utilisés pour définir la représentation visuelle d’un objet de données (objet de type Photo,….)

Les « triggers »

Les « Triggers » permettent une meilleure interactivité entre votre application et l’utilisateur. Ils sont déclenchés lorsqu’une condition spécifique est vraie
Les « EventTrigger » sont les plus utilisés : Le « Trigger » se déclenche lorsque l’évènement indiqué survient. Ils sont utilisés avec les Styles et les « Templates ».

Les « animations »

« StoryBoard »: Regroupe des animations qui seront jouées à la demande.
Les animations sont utilisées dans des « StoryBoards », au moyen des propriétés:« TargetName » : Indique la cible de votre animation« TargetProperty » : Indique quelle propriété doit-être animée Les animations sont utilisées pour animer les propriétés (taille, couleur, etc…) des objets

Les « Transformations »

Utilisées pour donner plus de vie à vos applications, elles permettent de transformer le rendu graphique d’un contrôle. Elles sont également utilisées dans des « StoryBoards » grâce aux propriétés « TargetName » et « TargetProperty »
Plusieurs types de transformation sont disponibles :

  • « TranslateTransform » : Effectue une translation d’un contrôle
  • « RotateTransform » : Exécute la rotation d’un contrôle
  • « ScaleTransform » : Redimensionnement d’un contrôle
  • « MatrixTransform » : Permet de créer ses propres transformations

Les transformations peuvent aussi faire l’objet d’une animation

Le « Visual State Manager »

Les Toolkits

Développement de contrôles

Plus de ressources sur le sujet

Pour plus d'informations, nous vous invitons à explorer les liens suivants :

XAML : Notions élémentaires

Collaboration designer / développeur

XAML

Langage de « Markup » pour Windows : Langage de sérialisation pour toute hiérarchie d’objets CLR.

  • Code et contenu séparés
  • Construction d’applications par déclaration
  • Facile de manipulation et de génération par outils

Pour offrir leur visibilité sous XAML, les types WPF se répartissent dans deux espaces de nommage. La définition avec l’attribut xmlns devrait être incluse dans chaque élément « root » du fichier XAML Pour accéder aux objets XAML depuis le « code-behind », ils doivent être définis avec l’attribut « x:Name »

Ils sont automatiquement générés (dans le .gs). Il faut spécifier l’« assembly » et son espace de nommage pour que XAML puisse connaître le type CLR manipulé

Dans le cas des types « Custom », s’ils sont définis : Dans la même « assembly » que le code XAML, il suffit de spécifier le « namespace » avec l’attribut « xmlns » sur l’élément ou son parent Dans une autre « assembly », il faut également préciser le nom de l’« assembly »

Le contenu d’un contrôle peut être assigné :

  • Par attribut
  • Avec la syntaxe « Property Element » (NomDuType.NomDeLaPropriete) utilisée quand une string ne suffit pas pour décrire la valeur de la propriété. Les éléments XML sont assignés à la propriété par défaut

La limitation de la capacité à assigner des objets complexes aux propriétés XAML est contournée grâce au « Type Converter »

Les gestionnaires d’évènements sont associés via des attributs XAML (dans le « code-behind »)Le code peut-être directement ajouté dans XAML via le tag « x:Code »

Extension de XAML : Les « Markup Extensions » fournissent des mots clés additionnels pour XAML– Extensions spécifiques– L’instance est créée et évaluée à l’exécution Les valeurs entre "{}" sont considérées comme une extension

Plus de ressources sur le sujet

Pour plus d'informations, nous vous invitons à explorer les liens suivants :

Développement d’une application métier

L'approche « Winform »

Les premiers développements WPF sont souvent calqués sur une approche Winform

  • Nommage de tous les contrôles
  • Gestion des handlers sur les évènements provenant des contrôles dans le code behind
  • Stockage des références au modèle objet dans le code behind
  • Alimentation directe des contrôles par code

Cette approche présente un certain nombre de limites

  • Approche programmatique plutôt que déclarative
  • Couplage fort entre le code d’interaction avec les données et l’interface utilisateur
  • Usage de références de noms et de types
  • Contraintes pour le responsable du design de l’application
  • Difficile à tester, pas de test unitaire sur le code behind
  • Pas d’utilisation du Databinding bidirectionnel, une des fonctions les plus puissantes de WPF

Approche « Data Binding »

Le « DataBinding » est mécanisme qui cible l'association de données à leur représentation visuelle. L’interface utilisateur peut être liée à des objets .NET ou à du XML. Le Couplage est faible entre les données et l’UI

Qu’attend-on d’une technologie d’interface graphique pour les applications présentant des données ?

  • Des contrôles orientés données
  • Un moteur de binding bidirectionnel
  • Un modèle de vue
  • Une synchronisation de l’affichage avec les interfaces de notifications
  • Simplifier la navigation

Le binding est placé sur la « Dependency Property » cible. La Source est indiquée comme une ressource statique ou dans le code-behind. La propriété « DataContext » fournie une source de Binding par défaut héritée via l’arbre visuel depuis le parent jusqu’à l’enfant et positionnée en « code-behind »La propriété « Path » de la « Binding Source » peut naviguer dans les sous-propriétés de l’objet La propriété « ElementName » permet d’associer des éléments d’affichage contenus dans le même fichier La propriété « RelativeSource » permet au Binding d’identifier les éléments relatifs à l’élément courant (« FindAncestor », « Self »,…)

Résolution des références de binding

Les objets métier représentent les types qui symboliseront les entités affichées et manipulées dans votre application. Pour permettre la résolution des références de binding, il convient d'appliquer l'une des 3 méthodes suivantes :

  • Méthode 1 (méthode la moins performante) : L’objet source est un objet CLR et la propriété source est une propriété CLR : Le moteur de Binding utilise la réflection via l’interface « ICustomTypeDescriptor » sur l’objet source pour obtenir le « TypeDescriptor » puis requête le « PropertyDescriptor » pour obtenir la propriété souhaitée
  • Méthode 2 : L’objet CLR source implémente l’interface « INotifyPropertyChanged » et offre une propriété de type propriété CLR Le moteur de Binding utilise la réflection directement sur le type de la source et obtient la propriété souhaitée Pour se faire, chaque « setter » des propriétés doit faire appel à la méthode RaisePropertyChanged. Cette méthode commence par vérifier que la propriété dont le nom est passé en paramètre existe bien au niveau de la classe. Ensuite, elle déclenche l’évènement PropertyChanged, qui est définit au niveau de l’interface INotifyPropertyChanged, et qui permet de notifier l’interface graphique que la propriété a été mise à jour.
  • Méthode 3 (méthode optimale) : L’objet source est un « DependencyObject » qui met à disposition une propriété source qui est une « DependencyProperty » (WPF connaît alors tout changement se produisant sur cette propriété) Le moteur de Binding n’a as besoin d’utiliser la réflection. Le moteur de Propriété et le moteur de Binding résolvent indépendamment la référence à la propriété.

Personnellement je recommande l'utilisation d'INotifyPropertyChanged avec l’une des multiples implémentations possibles (approché élémentaire, dérivation, réflexion, AOP, EntLib, Spring.NET, extension…).http://blogs.codes-sources.com/fredhamel/archive/2008/06/15/wpf-r-glons-son-compte-inotifypropertychanged-d-rivation-r-flexion-aop-entlib-string-net-extension.aspx(http://tinyurl.com/optionsINotifyPropertyChanged) éventuellement couplée avec l'utilisation d’une classe de base pour les ViewModels incluse dans le Framework nRoute http://nroute.codeplex.com. Cette classe développée par Orktane (http://www.orktane.com/Blog/Default.aspx) implémente l’interface INotifyPropertyChanged et fournit une méthode NotifyPropertyChanged prenant en paramètre une lambda expression à la place d’une chaîne de caractère Elle permet ainsi d'éviter les erreurs lors du renommage des propriétés d’un ViewModel mais a toutefois un impact potentiel en termes de performanceshttp://www.pochet.net/blog/2010/06/25/inotifypropertychanged-implementations-an-overview/

L’annulation des modifications

Lorsqu’on laisse la possibilité à un utilisateur de saisir des informations, il est important de pouvoir faire une annulation. Pour cela, on peut tout à fait imaginer un système de pile qui va stocker les différents changements de valeurs effectués par l’utilisateur. Une autre possibilité est d’utiliser l’interface IEditableObject (https://msdn.microsoft.com/fr-fr/library/system.componentmodel.ieditableobject.aspx), qui permet de valider ou de restaurer les modifications apportées à un objet utilisé comme source de données. Au niveau de l’implémentation, on commence par faire implémenter l’interface IEditableObject. Puis, l’objectif est de faire en sorte de travailler sur une copie des valeurs modifiées par l’utilisateur.

La validation des données

En manipulant l’interface, on fait une modification immédiate sur la donnée métier. Puisque le binding est à double sens, et immédiat, cela veut-il dire que je n’ai plus besoin d’un bouton « Valider » ?Et si je veux annuler ce que j’étais en train de faire ? Que se passe t-il si la donnée envoyée est au mauvais format, trop longue, trop courte ? Dans toutes les applications que l’on est amené à développer, il est important de vérifier les informations saisies par l’utilisateur. Une adresse email doit être correctement formatée, un numéro de téléphone doit avoir le bon nombre de chiffres... La validation des données est un domaine réservé à la couche métier, mais doit être remontée le plus facilement possible vers la couche de présentation Avec WPF, vous avez la possibilité de mettre en place des mécanismes permettant de faire de la vérification sur les valeurs renseignées par les utilisateurs. La première possibilité consiste à utiliser les règles de validation (ValidationRule). Il s’agit d’une classe, qui hérite de la classe abstraite ValidationRule, et pour laquelle il est nécessaire de surcharger la méthode Validate. Une autre possibilité, pour mettre en place de la validation, consiste à utiliser l’interface IDataErrorInfo (https://msdn.microsoft.com/fr-fr/library/system.componentmodel.idataerrorinfo.aspx). Il s’agit d’une interface à implémenter, directement sur les objets métier, lorsque l’on souhaite qu’ils notifient l’interface graphique qu’une de leur propriété est en erreur. L’avantage de l’utilisation de cette interface, c’est que la validation est faîte directement au niveau du modèle et ne repose plus sur l’utilisation d’un élément externe. De plus, vous disposez d’une rétrocompatibilité dans le cas où votre classe est utilisée dans une application WindowsForms utilisant un ErrorProvider (qui est en mesure de réagir en présence de cette interface).https://blogs.msdn.com/wpfsdk/archive/2007/10/02/data-validation-in-3-5.aspxLes règles de validation peuvent être persistées sous forme d’attributs dans le code métier ou stockées dans un fichier XML (elles peuvent alors être éditées avec l’outil fourni avec Enterprise Library) La logique de validation peut être changée sans recompilation

Pour plus d'informations, nous vous invitons à explorer les liens suivants :

Debugging du DataBinding

Pour analyser un dysfonctionnement lié au databinding, voici quelques "tips"

  • L'échec du Databinding affiché dans la console de debug de Visual Studio et capture de toute exception de DataBinding
  • Utilisation de Converter d’« affichage » avec point d’arrêt
  • « PresentationTraceSources.TraceLevel » permet de spécifier le niveau de contrôle directement sur la source (« Low », « Medium », « High »)

<system.diagnostics> <sources> <source name="System.Windows.Data" switchName="SourceSwitch" > <listeners> <add name="textListener" /> </listeners> </source> .. </system.diagnostics>

Les Design Patterns

Le succès du développement d'une application WPF repose souvent sur le respect des patterns réfléchis et éprouvés, telle que la mise en oeuvre d'une une architecture faiblement couplée qui facilite les tests unitaires : – Pattern « M-V-VM » (Model-View-ViewModel)– Pattern « Command »– …Dans certains cas, le développeur pourra éventuellement s'appuyer sur des frameworks utilisant ces patterns

Modèle M-V-VM

Depuis sa sortie en 2007 avec le .NET Framework 3.0, différents patterns ont été explorés pour faciliter l’utilisation de cette technologie dans un contexte d’applications d’entreprises. Le dernier en date – qui est de loin le plus abouti - est le pattern M-V-VM (Model - View - ViewModel). C’est un Pattern dérivé du pattern MVC indépendant de la technologie. Il permet de séparer clairement le métier de l’interface. Il facilite les tests unitaires sur les applications WPF (en aidant à remplacer le test manuel simulant l’interaction utilisateur).

Dans la logique de décomposition proposé par le pattern M-V-VM, le « Model » (ou « DataModel ») est responsable des données métiers, la « View » représente la partie visuelle de l'application tandis que le « ViewModel » expose les données et les comportements (notamment les commandes) pour la « View ».Ce « ViewModel » est spécifique pour chaque vue mais n’hérite d’aucunes classes WPF. Le « ViewModel » est une classe qui implémente le pattern « Observable » : elle implémente l’interface « INotifyPropertyChanged ». De même, les propriétés de la classe « ViewModel » doivent implémenter « INotifyPropertyChanged » (ou « DependencyObject ») ou « ObservableCollection » suivant qu’il s’agit d’objet ou de collection, afin de prévenir la vue lors de tout changement des données. Ainsi la « View » peut utiliser le « ViewModel » dans son « DataContext » pour le « binding » afin de transformer les données en éléments visuel avec les « Data Templates ». Le View Model quant à lui ne fait aucune supposition surla façon dont va s'opérer le binding. Lorsque ce pattern est mis en oeuvre avec WPF, la View ne contient quasiment pas de « code behind » à part les animations et la gestion de « layout ».. Le code réside dans le ViewModel qui est facile à tester unitairement, d'où l'intérêt de cette approche. La version 4.0 d’Expression Blend supporte nativement le DataBinding et le pattern MVVM, disponible sous forme de template, qui peut être utilisé avec les frameworks WPF, Silverlight et Silverlight pour Windows Phone 7.

Pour plus d'informations, nous vous invitons à explorer les liens suivants :

Pattern Command

Dans une application traditionnelle, l’interaction avec les utilisateurs se fait au moyen des évènements Click des boutons, SelectionChanged des ListBox, etc. Bien que fonctionnelle, cette technique n’est pas très souple : que se passerait-il s’il ne fallait plus passer par un bouton mais plutôt une Checkbox ? Vous seriez obligé de réécrire une partie de votre code ! Pour pallier à ce problème, WPF offre un mécanisme nommé les commandes. Techniquement, il s’agit d’utiliser une classe qui implémente l’interface ICommand pour lui dire quand l’action doit-être exécutée et que faire lorsque celle-ci est invoquée. On retrouve plusieurs implémentations connues de l’interface ICommand (DelegateCommand, SimpleCommand, etc.) mais l’une des plus utilisée est sans doute la classe RelayCommand, de Josh Smith.

Au lieu de s’abonner à l’évènement « click » d’un bouton (l’action devenant fortement liée au bouton) on utilise les RoutedCommand pour décoreller l’action, grâce à l’interface ICommand. WPF propose des commandes en standard :

  • ApplicationCommands (Close, Copy, Cut, Delete, Find, Help, New, Open, Print etc…)
  • ComponentCommands (MoveDown, MoveLeft, ScrollPageUp, SelectToEnd etc…)
  • MediaCommands (ChannelDown, DecreaseVolume, NextTrack, Pause, Play etc…)
  • NavigationCommands (BrowseBack, LastPage, Refresh, Favorites, GoToPage etc…)
  • EditingCommands (AlignCenter, AlignJustify, CorrectSpellingError, EnterLineBreak etc…)
  • Il reste possible de définir ses propres commandes

Ces commandes ont un support automatique des mouvements d’entrée (souris, raccourcis clavier, etc…)SL4 supporte ICommand (pour les contrôles de type Button) mais il n’y a pas de classe implémentant cette interface http://www.devproconnections.com/article/silverlight-40/communicating-between-views-and-viewmodels-in-silverlight-4-appsImplémentations proposées de RelayCommand (ou équivalent) dans l’un des différents frameworks comme le MVVM Light Toolkit. https://mvvmlight.codeplex.com/Ou plus simplement, ajout d’une classe « SimpleCommand » http://marlongrech.wordpress.com/2008/11/26/avoiding-commandbinding-in-the-xaml-code-behind-files

Pour plus d'informations, nous vous invitons à explorer les liens suivants :

Attached Behaviors

Imaginez par vous souhaitiez faire en sorte que lorsqu’un utilisateur sélectionne un nœud de votre Treeview, celui-ci soit automatiquement centré à l’écran (et ne reste pas en bas de l’interface) afin de permettre à l’utilisateur de focaliser son regard/attention sur cet élément. Dans le cas de programmation « classique »,si l’on souhaite réaliser ce type de scénario (à savoir enrichir une classe avec un comportement), il existe 3 possibilités :

  • On dispose du code source donc on peut facilement l’étendre pour rajouter des fonctionnalités
  • On hérite de la classe qui nous intéresse et on y rajoute notre code
  • On encapsule la classe dans une autre classe

Bien que cela fonctionne, ces techniques ne sont pas toujours utilisables, par exemple lorsque l’on travaille avec des éléments générés automatiquement. Il existe donc une 4ème possibilité, avec WPF, pour enrichir un contrôle avec de nouvelles fonctions : il s’agit d’utiliser des Attached Behaviors. Il s’agit simplement de propriétés qui, une fois quelle seront affectées, ajoute de la logique à votre contrôle. Avec WPF, l’utilisation de ces Attached Behaviors est envisagée pour :

  • Déclencher une commande lorsqu‘un évènement est déclenché
  • Offrir des données en mode « Design-Time »

Un axe de réflexion complémentaire : l’extensibilité

MEF (Managed Extensibility Framework) est un Framework d’extensibilité apparu sur Codeplex, et aujourd’hui intégré directement au sein du .NET Framework 4.0. Il a pour objectif de fournir toutes les fonctions requises pour la création d’applications modulaires, en proposant un cadre applicatif pour l’implémentation d’addins (plugins) automatisant la liaison entre les propriétés du programme qui importe des valeurs et les addins qui exportent les valeurs. MEF automatise la découverte des modules (les plugins) ce qui permet notamment le chargement de modules dynamiquement depuis un répertoire. Globalement, un module est représenté par un type .NET (classe ou interface) et est « exporté » hors de la librairie dans laquelle il est défini à l’aide d’attributs. Il est ensuite « importé » dans l’application principale (dite Shell), là aussi, à l’aide d’attributs. Il est possible de contrôler l’importation de modules et de forcer ces derniers à posséder des métadonnées précises (par exemple, un nom et une icône).

Initialement Codeplex http://mef.codeplex.com et aujourd’hui fourni avec .NET 4 ou Silvelright 4 Pas de support natif d’une isolation des pluggins en AppDomain. Chargement dynamique des pluggins au Runtime http://blogs.dotnet-france.com/julienc/post/NET-40-Premiere-application-MEF-Recomposition-du-catalogue-de-module-au-Runtime.aspxMais pas de déchargement de la DLL en mémoire (car pas d’isolation AppDomain)

MEF fournit un moyen pour une application hôte de découvrir, d'exposer et de consommer les extensions de composant sans nécessité pour chacun d'eux d'être liés MEF permet ainsi aux auteurs de composants d'utiliser un contrat partagé sans avoir à partager des fichiers binaires Le contrat peut être une classe ou une interface qui peut être exposée pour les autres composants (Export) ou référencer des parties des autres composants à utiliser (Import) Structural Matching (Duck typing) : “If it walks like a duck and quacks like a duck, I would call it a duck. “

La conception de MEF repose sur un découpage en trois couches distinctes :

  • Le « Container » l’API publique pour le développeur
  • Les « Primitives » qui offre un niveau d’indirection afin de propose plusieurs approches pour la découverte et la composition des parties de l’application
  • L’ « Attributed Programming Model » modèle de programmation par attributs, implémentation par défaut de la couche des « Primitives » qui repose sur les types et les attributs pour la découverte et la définition des importations/exportations

Grâce à ce découpage, la couche « Conteneur » n'a aucune dépendance vis-à-vis de l’ « Attributed Programming Model » et interagit uniquement avec les abstractions fournies dans la couche de « Primitives ».

Framework de composition dynamique et injection de dépendance

L'objectif du Composite Application Guidance for WPF and Silverlight (PRISM) est de fournir un Framework sur lequel viendront se greffer des applications WPF orientées « Business ». Ce socle, destiné à s'interfacer avec le Desktop, préfigure en quelque sorte le bureau de demain. Prism ( complète WPF et Silverlight en se concentrant sur 4 domaines :

  • Extensibilité et Modularité grâce à des concepts tels que l’injection de dépendance : lier les objets en fournissant (injectant) une dépendance externe dans le composant logiciel (Intérêt pour les tests unitaires : Switch par des mocks sans intervention manuelle)
  • Composition de l'interface utilisateur par le biais de régions qui peuvent être chargées dynamiquement lors de l'exécution et modification de la structure d’affichage du Shell de l’application
  • Communication entre ces modules (sans inter-dépendance) : Commande Composite via « CompositeCommand » – RoutedCommand via « DelegateCommand » et Publication/souscription pour la communication découplée via « EventAggregator »
  • Testabilité : l’implémentation de référence permet d’utiliser un pattern de séparation de la couche de présentation et rend donc l’UI testable
  • Développement parallélisé des composants avec problématique de licences, déploiement partiel des modules, voire de versions spécifiques de modules :

Framework de communication et exposition des données

Comment exposer des données?

  • Protocole: Communication basée sur HTTP, SOAP: Simple object Access Protocol, REST: Representational State Transfer, OData : Open Data ProtocoleProtocoles
  • Données: Consommables simplement et Auto-descriptives pour minimiser les dépendances avec les clients
  • Quelques attentes: Posséder une solution de mise en cache, La montée en charge doit reposer sur l’infrastructure, Possibilité de réutiliser un mécanisme existant, Requêtage effectué côté serveurk Confidentialité/performance/etc
  • Formats de données (POX: Plain old XML, JSON: JavaScript Object Notation, RSS: Really Simple Syndication, ATOM: Atom Syndication Format)
  • Modèles de programmation : Sockets (pas de support du cross domain), Web Client, WCF (Approche recommandée), Utilisation d’appels asynchrones requise pour Silverlight

Critères de choix :

  • WCF Services (WCF SOAP)
  • WCF WebHttp Services (WCF REST) : Construction de services accessibles en mode REST avec le contrôle de l’URI, du format et du protocole
  • WCF Data Services (ADO.Net Data Services) : Exposion de modèles de données avec une interface REST
  • WCF RIA Services (.NET RIA Services) : Construction end-to-end d’une application Silverlight

WCF RIA Service Possibilité d'exposer le services RIA en Soap ou en OData

Le multilinguisme

Une des fonctionnalités les plus souvent demandée dans des applications Windows (y compris des applications métier) concerne le multilinguisme, à savoir le fait de pouvoir changer la langue de l’application. Dans le cas de WPF, il existe plusieurs Framework permettant de gérer la localisation. Vous pouvez par exemple jeter un œil à celui-ci : http://wpflocalizeextension.codeplex.com. Vous pouvez également regarder ce Framework : http://www.codeproject.com/KB/WPF/WPF\_Resx\_Localization.aspx. Il est simple d’utilisation et couvre la plupart des besoins.

Les performances

Lorsque l’on référence un contrôle, on référence implicitement toute la structure visuelle associée. Lorsqu’un élément est ajouté ou supprimé de la structure logique, des “invalidations” de propriétés sont propagées sur le parent de l’élément et sur ses enfants. ’où l’intérêt d’avoir recours à un pattern de construction « top-down » (plutôt que « bottom-up ») pour éviter le coût d’invalidation non nécessaires sur des éléments ayant déjà été validées. A priori, la virtualisation n’est pas à considérer car il n’y a pas beaucoup de données à afficher ou à manipuler en mémoire http://bea.stollnitz.com/blog/?p=338

MultiThreading

Sur un seul Thread ou sur plusieurs ? – Si plusieurs penser à utiliser le thread pool pour assurer la synchronisation des threads. Penser à empêcher la lecture sur l’objet des propriétés s’il est en cours d’écriture : lock, mutex, …Autres exemples d’implémentation : How can I propagate changes across threads? (Bea Costa) http://bea.stollnitz.com/blog/?p=34 DM-V-VM part 3: A sample DataModel (Dan Crevier) https://blogs.msdn.com/dancre/archive/2006/07/26/679851.aspx Faut-il considérer l’utilisation d’Invoke plutôt que BeginInvoke ? https://channel9.msdn.com/forums/TechOff/501693-Weird-threading-problem/ Multithread logger in WPF (Tamir Khason) https://blogs.microsoft.co.il/blogs/tamir/archive/2007/03/18/Multithread-logger-in-WPF.aspx

Différentes approches pour éviter les problématiques liées l’usage de INotifyCollection dans un contexte multi-threads WPF Data Binding ObservableCollection (cross thread binding support)

Classe Dispatcher

Il est préférable de faire en sorte que les opérations longues ou bloquantes s’exécutent sur des « workers threads »Il faut alors éviter l’usage de « DispatcherObject » dans un thread qui n’est pas un thread UI« INotifyPropertyChanged » fonctionne en « cross-thread » « INotifyCollectionChanged » ne fonctionne pas en « cross-thread »https://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.aspx Méthodes « Invoke » et « Invoke » + « DispatcherPriority » https://msdn.microsoft.com/en-us/library/ms591206.aspx

Classe Backgroundworker

La classe « BackgroundWorker encapsule les des « workers threads » et appelle automatiquement « Control.Invoke » ou « Dispatcher.Invoke » Elle utilise le pool de threads, qui recycle les threads afin d'éviter de les recréer pour chaque nouvelle tâche (-&gt; Ne jamais appeler « Abort » sur un thread « BackgroundWorker »)

Utilisation de la Classe Backgroundworker

  • Instancier un objet « BackgroundWorker » et gérer l'événement « DoWork »
  • Appeler « RunWorkerAsync », éventuellement avec un objet
  • Tout argument transmis à « RunWorkerAsync » est transmis au gestionnaire d'événements « DoWork », via la propriété argument de l'événement
  • « BackgroundWorker » fournit également un événement « RunWorkerCompleted » qui se déclenche après que le gestionnaire d'événements « DoWork » a fait son travail

Gestion des données en entrée

S’il y a plusieurs flux en entrée, Implémenter le Pattern Mediator : routage des différents flux

Optimisations diverses

  • Réduire le nombre de Visuals (dans le visual tree), en simplifiant éventuellement les templates
  • « Visible = collapse » : Attention l’objet n’est pas « accessible » tant qu’il n’est pas rendu visible
  • Préférer l’utilisation de « StaticResource » au lieu de « DynamicResource »
  • Partager les ressources entre les contrôles au lieu de les définir plusieurs fois
  • Rassembler la définition des ressources au niveau de l’Application
  • Utiliser les « TextBlock » à la place des « Labels » si possible
  • Mettre à profit le container recycling, l’UI virtualization le deferred scrolling
  • Scrolling : utiliser « VirtualizationMode.Recycling »
  • Réduire ou supprimer les animations, proscrire celles en Forever
  • Réduire le framerate
  • Réduire le nombre d’effets de transparence (Opacity &lt; 1)
  • Jeter un œil sur les membres de la classe RenderOptions, notamment pour optimiser/mettre en cache les éléments fixes
  • Veiller à ne pas avoir d’effets graphiques soft (pre-3.5SP1) en chassant les classes héritées de BitmapEffect
  • S’il y a besoin de graphisme pur, on peut utiliser les primitives WPF « bas niveau » via un handler sur l’évènement CompositionTarget.Rendering, mais en sacrifiant le databinding

Performance Profiling Tools for WPF

Le modèle de déploiement

xxx

La sécurité

Authentification : Identification des applications. Les mécanismes d’authentification permettent aux application de type « poste de travail intelligent » de se prémunir contre l’usurpation d’identité. Suivant les fonctions offertes par l’application, il peut être nécessaire d’authentifier l’utilisateur à différents moments de son interaction avec cette application (installation, exécution, accès à des données locales, accès à des services externes sur le réseau). Les facteurs clés qui ont une incidence sur le choix d'une approche d'authentification sont en tout premier lieu la nature de des utilisateurs de l’application (comptes Windows ou non), et les besoins en termes d'emprunt d'identité et d'audit (enregistrement des actions de l’application, qu’elles soient autorisées ou non, pour garantir la non répudiation.). Ainsi, les informations d'identification de l'utilisateur sont à la disposition de l'application serveur et peuvent être utilisées pour accéder aux ressources réseau en aval. Autorisation : Définition des droits d’un utilisateur authentifié vis-à-vis d’une application. Les mécanismes de gestion des autorisations permettent d’éviter l’altération des données et la diffusion d’informations sensibles. La sécurité fondée sur les rôles telle que proposée par la plateforme Windows donne aux développeurs la possibilité de construire des scénarios d'authentification hautement personnalisés pour leurs applications. Les fonctions d'authentification les plus courantes y sont disponibles (routines de code .NET vérifiant les informations d'authentification et les attachant au contexte de la demande ou mécanismes du sous-système de sécurité Windows traditionnel). L’authentification Windows prend en charge plusieurs mécanismes d'authentification dont peuvent se servir les applications de type « poste de travail intelligent » par l'intermédiaire des sous-systèmes SSPI (Kerberos, NTLM, certificats X509,...).

La sécurité d'accès au code .NET (« Code Access Security ») s'assure que le code des assemblages satisfait aux autorisations exigées. Si une méthode dans un assemblage nécessite une autorisation pour accéder à une ressource, le code fournissant l'accès à cette ressource demande l'objet d'autorisation approprié. Ce processus contrôle que chaque assemblage dans la chaîne d'appels a reçu l'autorisation demandée (pas seulement l'appelant immédiat). Si l'un des appelants échoue à ce test, une exception de sécurité est générée et l'opération demandée n'est pas accomplie. Les deux principales stratégies d'autorisation sont les suivantes : • Stratégie basée sur les rôles (en général, la plus appropriée). L'accès aux opérations par les applications de type « poste de travail intelligent » est sécurisé en fonction du rôle auquel appartient l'appelant. Les rôles sont utilisés pour partitionner les utilisateurs de l’application en groupes d'utilisateurs qui partagent les mêmes privilèges de sécurité au sein de l'application. Les utilisateurs sont mappés à des rôles, et si l'utilisateur est autorisé à effectuer l'opération demandée, l'application utilise des identités fixes qui permettent d'accéder aux ressources. Ces identités sont approuvées par les gestionnaires de ressources (par exemple, des bases de données, le système de fichiers, etc.).• Stratégie basée sur les ressources. Les différentes ressources sont sécurisées par le biais des listes de contrôle d'accès Windows. Les applications de type « poste de travail intelligent » peuvent emprunter l'identité de l'appelant avant d'accéder aux ressources, ce qui permet au système d'exploitation d'effectuer des vérifications d'accès standard. L'accès aux ressources est effectué à l'aide du contexte de sécurité de l'appelant initial.

Identité : contexte de sécurité de l’utilisateur authentifié. Il est possible de transmettre l'identité et le contexte de sécurité depuis les applications de type « poste de travail intelligent » en se fondant sur les modèles d'emprunt d'identité ou de délégation que proposent la plateforme Windows (Kerberos) et le .NET Framework. Sécurité des informations : il faut faire en sorte que les messages circulant sur le réseau restent privés (chiffrement) et non altérés (signature du message). La plateforme Windows et le .NET Framework proposent des mécanismes de cryptographie utilisables pour le chiffrement à clé publique (asymétrique : RSA et DSA), le chiffrement à clé privée (symétrique : DES, TripleDES et RC2) et les signatures numériques.Appli, profil utilisateur et structure d'appartenance

Gestion de l'authentification Authentification Azman Microsoft.Interop.Security.AzRoles.dll https://msdn.microsoft.com/fr-fr/library/ms998336.aspx Authentification basée sur les revendications avec WIF http://claimsbasedwpf.codeplex.com https://msdn.microsoft.com/fr-fr/magazine/ee335707.aspx https://blogs.msdn.com/b/card/archive/2009/10/20/how-geneva-helps-with-access-control-and-what-is-its-relationship-to-azman.aspx

Mode déconnecté

Synchronisation de sources de contenus multiples et éventuellement de différents types (Fichiers, Flux Web, Base de donnée). Le Sync Framework supporte un grand nombre de types de clients: Silverlight, Windows Phone 7 / Android / Iphone, HTML5

Convergence Silverlight et WPF

Ajout des fonctions clés de WPF dans Silverlight : DataBinding, Custom Markup Extensions, Binding dans les Style Setters, Implicit Data Templates, Ancestor RelativeSource Binding, DataContextChanged Event Graphics : Immediate Mode Graphics API Out of Browser : Multiple Window Support P/Invoke : Enterprise Group Policy Support Support de l’hébergement de Silverlight dans la prochaine version de WPF

Les nouvelles interfaces utilisateur

“Computer technologies are not neutral – they are laden with human, cultural and social values. We need to define a new agenda for human-computer interaction in the 21st century – one that anticipates and shapes the impact of technology rather than simply reacts to it.”https://research.microsoft.com/hci2020/downloads/BeingHuman_A3.pdf

Surface

Vision based with new PixelSense™ Supports touch input Supports tags Full HD Display 1080p – 1920 x 1080 Larger 40” – 16:9 screen 4” thin Horizontal and Vertical deployment

Plateforme de développement : Windows 7 Professional 64-bit edition Surface 2.0 Shell & SDK NET Framework 4.0 Windows Presentation Foundation (WPF) 4.0 XNA 4.0 Windows PowerShell and DMFT DASH support

Form factor usage Tables and counters Tables, counters, kiosks, and walls
Display+vision input technology Rear projection DLP w/cameras Thin LCD w/PixelSense™ technology
Price $12,500 USD commercial MSRP starting at $7,600 USD
Weight 198 lbs. 87 lbs.
Physical dimensions (L x W x H) 42.5 x 27 x 21 in. 42.7 x 27.5 x 4 in.
CPU Intel® Core™ 2 Duo
2.13 GHz processor
AMD Athlon™ II X2
2.9 GHz Dual-Core processor
Graphics (GPU) ATI Radeon™ X1650 – 256 MB AMD Radeon™ HD 6570M – 1 GB GDDR5
Memory 2 GB DDR2 4 GB – 8 GB DDR3
Storage (hard drive) 160 GB HDD – 5400 RPM 320 GB HDD – 7200 RPM
Display size 30 in. 40 in.
Display resolution 1024 x 768 – 4:3 aspect ratio 1920 x 1080 – 1080p HD 16:9 aspect ratio
Extensions (ports)

XGA (DE-15) video out
RGB analog component video out

RCA analog component audio out

4 USB ports

HDMI input & output
SPDIF 5.1 digital surround sound out
RCA analog component audio out
3.5 mm TRS (stereo mini-jack) audio out
4 USB Ports
Networking Wi-Fi 802.11g, Bluetooth, and Ethernet Wi-Fi 802.11n, Bluetooth, and Ethernet

Application Multi-touch Windows

Bonnes pratiques du design d'interaction Suggérer la capacité tactile Manipulation au doigt (sans « s » )Pensez à ce qui peut se placer entre l’utilisateur et l’interface… (sa main?) Oubliez ce que vous connaissez des interactions de type « pointez-cliquez »Ne réinventez pas la roue (gestes compliqués, etc) Gardez une hiérarchie simple entre les écrans Recommencer doit être facile

Kinect

Camera 3D (image + info de profondeur) Reconstitution de squelette Spatialisation du son SDK au printemps pour les chercheurs et les écoles This SDK is packed with features enabling you to build compelling applications using all of the features that Kinect provides both for C++ and Managed code, from advanced audio, to skeletal tracking. The all in one Setup installs the drivers, runtime, samples and documentation. Kinect on Windows Evangelism Site

https://sharepoint/sites/kinectevangelism/SitePages/Home.aspx

Synthese

xxx


(1)La version du document est au format AAMMJJ (date) suivi d’une lettre pour la sous-version du jour s’il y a lieu