Dévoilé durant le MIX11 qui s’est déroulé à Las Vegas en avril dernier, c’est finalement à la date du 16 juin 2011 que Microsoft a décidé de mettre à disposition le kit de développement (SDK) Kinect pour Windows. Les développeurs en herbe ou passionnés peuvent désormais se donner à coeur joie dans la conception d’applications exploitant les fonctionnalités interactives de la machine. Espérons voir fleurir rapidement sur la toile bon nombre d’outils qui sauront tirer partie de ce petit bijou technologique !

Initialement dénommé “Project Natal”, le Kinect possède désormais une place d’honneur dans le World Guiness Book comme étant l'”accessoire High-Tech le plus vendu dans un court laps de temps” (dixit. World Guiness Book). Initialement conçu pour la console de Microsoft, la Xbox 360, le Kinect s’est voulu être une nouvelle façon de jouer aux jeux vidéos sans manettes appelé également Motion Gaming. Il a rapidement réussi à attiser la sympathie du public avec son concept de commande à la fois ludique et innovante et offrant alors de nouvelles possibilités en terme d’intéractions. Disposant de deux caméras, un capteur de champ par infra-rouge et d’un microphone, le Kinect fonctionne par reconnaissance spatiale d’un corps en mouvement.

Mais les curieux n’avaient pas attendu cette sortie pour mettre au point un pilote compatible Windows pour faire leurs premiers essais. C’est ainsi que le kit CL-NUI Platform a sévi sur internet et proposait déjà de prendre le contrôle sur les capteurs vidéos de l’appareil. On a pu voir apparaître quelques démos techniques (des exemples sur http://kinecthacks.net/) prenant en compte la détection de mouvements qui laisse présager d’autres innovations dans la conception d’interfaces interractives différentes du mythique combo clavier/souris ou plus récemment écran tactile : robotique, réalité augmenté, … Minority Report, ça vous rappelle des souvenirs ?

Prérequis:
Matériel

• Dispositif Kinect pour Xbox 360
• PC avec processeur dual-core, 2.66-GHz ou plus
• Windows 7–carte graphique compatible DirectX® 9.0c
• 2-Go RAM (4-Go RAM recommandé)

Logiciel

• Windows 7 (x86 ou x64)
• Visual Studio 2010 Express (ou autre édition 2010)
• Microsoft .NET Framework 4.0

Et pour bien commencer…

En C#

Avec votre Visual Studio préféré, ajouter la référence “Microsoft.Research.Kinect” depuis la GAC (Global Assembly Cache) et appeler l’assembly dans vos codes projets.

Pour l’API NUI
using Microsoft.Research.Kinect.Nui

Pour l’API Audio
using Microsoft.Research.Kinect.Audio

En C++

• Ne pas compiler vos projets C++ avec w_char comme type de séparateur.
• Pour utiliser l’API NUI, faire un include de MSR_NuiApi.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Pour utiliser l’API Kinect Audio, faire un include de MSRKinectAudio.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Faire le lien vers MSRKinectNUI.lib.
  Localisation :  Program Files\Microsoft Research KinectSDK\lib
• Enfin, s’assurer que les dlls du SDK de Kinect sont présents dans le bon répertoire lors de l’exécution du projet.
  Localisation: Program Files\Microsoft Research KinectSD

Pour plus de détails, je vous recommande de lire la documentation fournie avec le kit de développement (disponible ici) ainsi que de vous appuyer sur les différentes applications démos présentes dans le répertoire “Mes documents\Microsoft Research KinectSDK Samples”.

Have fun

Télécharger le SDK Kinect for Windows

The post Kinect for Windows SDK: Released! first appeared on In Fine - Le Blog.

Accéder à la partie 1

Après une première partie qui s’est concentrée sur l’organisation d’un projet WPF/Silverlight, attaquons-nous à quelque chose de plus compliqué avec les techniques avancées…

Silverlight et WPF en entreprise : retours d’expérience, bonnes pratiques et techniques avancées par Luc Vo Van (Microsoft Services) et Thomas Lebrun (Access-IT)

Architecture type

WPF et Silverlight nous offrent la possibilité de développer des applications composites. Le pattern Models-Views-ViewModels dit MVVM est favorisé.

Principes fondamentaux

Composition

Développer une application par composition c’est créer une coquille vide à laquelle vient se greffer différents modules applicatifs  indépendants qui interagissent ensemble pour les besoins de notre application. Le principal intérêt de ce type d’application est qu’il est possible de paralléliser les développements. En effet, puisque chaque module est indépendant, il est simple de regrouper les équipes en unités fonctionnelles. Ces unités fournissent alors aux autres équipes l’interface de leur implémentation ce qui permet d’exécuter toute l’application même si le développement d’un module n’est pas totalement finalisé.

Avec ce mécanisme, il est alors très aisé d’activer ou de désactiver une fonctionnalité. La maintenabilité de l’application est également largement revue à la hausse grâce au découpage par modules. Chaque module étant cloisonné et hiérarchisé, l’évolution d’un module ne sera visible de l’extérieur qu’à travers son interface. L’impact sur les autres modules est donc fortement limité.

Généralement, on observe deux approches d’architecture de développement par composition

• Régions + Services, c’est le cas avec le Framework Prism
• Services

Inversion of control

Plus communément appelé Ioc, l’Inversion of Control est un pattern utilisé pour l’injection de dépendance. On l’appelle  également parfois injection de code car en favorisant un découplage fort entre l’interface (UI) et l’implémentation (UI logic), il facilite la substitution des composants par des mocks lorsqu’un module n’est pas encore disponible.

Diverses implémentations sont possibles via Unity, Spring .NET, Ninject…

Commanding

Le système de commande est un mécanisme qui permet l’exécution d’actions déclenchées par des contrôles de l’IHM. Par exemple, sur un contrôle de type Button, habituellement, les actions qui suivent le clic sur celui-ci sont codés dans l’événement Click du code behind. Avec le système de commande, on écrit les actions dans la commande et il suffit alors de préciser au bouton le nom de cette commande à exécuter.

Ce mécanisme permet donc de découpler la source de l’action car les actions ne dépendent plus de l’événement Click. Il y a donc peu d’adhérence à l’interface graphique. Autre point fort, une commande peut également être affectée à plusieurs contrôles à la fois.

L’objectif du système de commande est de découpler l’interface graphique du code appelé lors de l’exécution d’une action. Un événement CanExecute intervient dans la définition d’une règle d’activation de la commande. Cette règle, lorsqu’elle est satisfaite active alors les contrôles de l’IHM affectés par cette commande.

Exemple :

//Création de la commande MyCommand
public static RoutedUICommand MyCommand { get; set; }

//Execute : Actions de la commande
private void ShowMessage_Executed(object sender, ExecutedRoutedEventArgs e)
{
MessageBox.Show(“Hello world”);
}

//CanExecute : Condition d’activation de la commande
private void ShowMessage_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
if(condition)
e.CanExecute = true;
}

//Dans le construteur, on enregistre les événements Executed et CanExecute
CommandBinding myBinding = new CommandBinding(MyCommand);
myBinding.CanExecute += ShowMessage_CanExecute;
myBinding.Executed += ShowMessage_Executed;
CommandBindings.Add(myBinding);

MVVM :

<!-- Après avoir inscrit la commande MyCommand au ViewModel et enregistré dans le ViewModel dans le DataContext de la View, on affecte la commande par Binding-->
<Button x:Name="MyButton" Command="{Binding MyCommand}" />

Non MVVM :

//Dans le constructeur, on affecte au bouton MyButton la commande MyCommand
myButton.Command = MyCommand;

Messaging

Par messaging, on entend l’implémentation d’un mécanisme permettant le dialogue entre les modules. Ce mécanisme, appelé Messenger, doit permettre aux modules de publier un événement et de notifier le ou les modules qui y sont abonnés. On parle alors de communication inter-ViewModels. Il est également possible de notifier un service du Shell par cette méthode pour par exemple faire appel au log, etc…

On distingue généralement les différents types d’implémentations suivantes :

• Event agregattor (Framework Prism)
• Messenger
• Queue

Services du Shell

Les services du Shell regroupent tous les composants qui permettent aux Views, Viewmodels et Controls de communiquer avec l’hôte. Ce sont les services transverses  tels que les Popups Messages, Ribbon Menu, Logging, Workspaces, etc …, et qui peuvent être utilisés à tout instant.

Approches par patterns:

Avec le pattern MVVM, nous avons vu qu’il existe une séparation forte entre le View et le ViewModel. Cette séparation permet 2 approches :

• ViewModelFirst : Dans cette configuration, le ViewModel s’occupe de créer les différents Views et de définir les bindings associés.
• ViewFirst : Dans cette configuration, la View utilise le ViewModel comme ressource. Le binding est alors défini dans la vue. Ce pattern est celui qui est utilisé par le Framework Prism.

Pour des applications implémentant des formulaires, l’utilisation du ViewState permet de définir l’état d’un formulaire avec des changements d’états plus simples et plus légers. En effet, il suffit de ne créer qu’une seule View qui contient alors les différents états du formulaire. Introduit par Silverlight et désormais présent dans WPF 4.0, le ViewState ajoute également des animations de transitions issues du Blend SDK à travers l’utilisation de behaviours.

Parfois, il arrive qu’on ait besoin de créer une fonctionnalité supplémentaire pour un contrôle existant. Dans ce cas de figure, nous utilisons alors les Attached Property qui permettent d’étendre un contrôle existant avec notre fonctionnalité, sans avoir à procéder à un héritage.

Blend SDK:

Ce SDK fournit entre autre des behaviours qui permettent de greffer des  fonctionnalités sur des contrôles pour avoir des comportements supplémentaires.

• InvokeCommandAction : Permet de lier un événement à une commande sans envoyer de paramètre.
• DataStateBehaviour : Sélectionne un VisualState en fonction d’une propriété
• CallMethodAction : Permet à un événement d’exécuter une méthode.

Pour utiliser ces behaviours, il faut au préalable charger l’assembly System.Window.Interactivity (2 dlls). Il est également possible d’écrire ses propres extensions.

Testing

Le pattern MVVM d’une manière générale est le pattern de prédilection pour mettre en place des tests unitaires automatisés pour les applications WPF et Silverlight. Nous avons vu auparavant que la mise en place d’un pattern d’IoC facilitait l’écriture de Mocks. Et bien, c’est avec cette même facilité qu’on pourra également mettre en place une série de tests automatisés car l’UI et l’UI logic sont complètement décorrélés dans cette architecture.

Pour réaliser vos tests selon le type d’application :

Liens externes

MVVM : Framework Prism, Microsoft Enterprise Library

Inversion of Control : Unity, Framework Spring .NET, Ninject

Behaviour : Blend SDK

Testing : Silverlight Toolkit (Silverlight Unit Test Framework)

The post WPF & Silverlight : L’état de l’art au Microsoft TechDays 2011 (partie 2) first appeared on In Fine - Le Blog.

A chaque événement TechDays, c’est l’effervescence au sein de la communauté Microsoft. Pour commencer cette nouvelle année, c’est le Cloud qui était à l’honneur. Mais nous allons ici évoquer un sujet un peu moins brumeux et qui, nous, les développeurs .NET, nous concerne plus particulièrement : WPF & Silverlight.

A travers une série d’articles, nous ferons le point sur les principales conférences autour de WPF & Silverlight…

Changer la vie de vos utilisateurs en intégrant du design et de l’ergonomie par Olivier Courtois (Bewise)

De nos jours, nous avons affaire à des “superutilisateurs” qui ont des attentes surdéveloppées. Bien plus que par le passé, les applications doivent se soucier davantage du confort d’utilisation : on parle alors d’ergonomie. Pour pallier à des surcoûts postproduction, cette réflexion doit être posée en amont.

Le travail général de l’ergonomie s’effectue dans le cadre d’une réflexion centrée autour de l’utilisateur. Cette réflexion, auprès d’utilisateurs réels -dans le meilleur des cas- ou auprès d’utilisateurs fictifs, donne naissance aux exigences ergonomiques.

Avec la technologie SilverLight/WPF, la chaîne de travail est occupée autour de 4 postes d’exécutions clés :

• Ergonomie
• Graphisme
• Intégration graphique
• Développement

Nous allons ici nous intéresser plus particulièrement aux 3 premières étapes de cette chaîne.

Ergonomie

L’ergonomie c’est l’art de faire s’adapter l’outil à l’homme à travers une interface. Le rôle de cette étape est de constituer le document de spécification ergonomique.

Le travail sur l’ergonomie est constitué des phases d’exécutions suivantes :

1)      Recueil du besoin : on itère auprès des utilisateurs pour déterminer le fonctionnement général de l’application

2)      Etude de l’existant (s’il existe !)

3)      Création de croquis

• Croquis papier : permet d’être plus créatif
• Application d’UI Design Pattern

4)      Proposition statique

• Croquis numérique : toujours à l’état de croquis, cette étape permet d’être clair lors de la confrontation avec les utilisateurs.

5)      Proposition dynamique

• Maquette dynamique : avec la mise en place d’interactions dans les croquis numériques, les utilisateurs perçoivent de manière plus évidente le fonctionnement que pourrait donner l’ergonomie de l’application.
• Permet de tester auprès des utilisateurs
• Permet de valider l’ergonomie

6)      Spécification ergonomique

• Recommandations ergonomiques
• Typologie des utilisateurs
• Croquis des principaux écrans
• Rationalisation des choix

Le travail sur l’ergonomie produit le document de spécification ergonomique, document qui sera par la suite réutilisé au cours de l’intégration graphique.

Graphisme

Le graphisme -ou design d’application- doit à travers son esthétisme communiquer visuellement la même information à tous les utilisateurs tout en prolongeant la marque du client. Au final, le design sublime l’ergonomie. Cette étape doit permettre la production de la charte graphique de l’application.

C’est ici qu’intervient un designer dont la tâche est de construire la charte graphique selon les étapes suivantes :

1)      Recueil du besoin

2)      Maquettage

3)      Définition de la charte graphique de l’application

Intégration graphique

L’intégration graphique consiste à créer les écrans de l’application tout en respectant son ergonomie. Cette étape permet notamment de préparer le travail du développeur. Pour ce faire, l’intégrateur graphique doit avoir à sa disposition à la fois le document de spécification ergonomique qui identifie les contrôles visuels et la charte graphique qui définit le style visuel appliqué aux contrôles.

1)      Recueil du besoin

2)      Création des squelettes d’écrans

3)      Intégration graphique

A l’issu de ce travail, l’intégrateur graphique met à la disposition des développeurs une bibliothèque de composants stylisés qui doit couvrir tous les besoins de l’application.

Gains Utilisateurs

La prise en compte de l’ergonomie au sein des applications SL/WPF offre bien des apports sur plusieurs aspects. Tout d’abord au niveau de la conduite de projet, on observe une amélioration de la productivité grâce au séquençage des tâches. Avec une meilleure ergonomie, l’application est beaucoup plus intuitive d’un point de vue utilisateur et donc les besoins en formations sont diminués et une meilleure satisfaction d’utilisation de l’application et l’adhérence des utilisateurs. Et d’une manière générale, on observe une diminution du nombre d’erreurs.

Conseil aux développeurs qui veulent se lancer dans l’ergonomie:

• Faire attention au vocabulaire employé
• Ne pas placer ses contrôles n’importe où

The post WPF & Silverlight : L’état de l’art au Microsoft TechDays 2011 (partie 1) first appeared on In Fine - Le Blog.