Webcast Aprés Midi du Développement

by Nicolas Calvi 12. janvier 2012 18:56

Vous pouvez regarder les Webcasts, mais aussi récupérer les sources et slides des Après Midi du Développement : Le Design d'application, qui a eu lieu au campus Microsoft.

Pour cela rendez-vous sur ce lien.

J'y intervient pour parler du cycle de vie d'une application tactile, mais aussi sur la programmation tactile avec WPF 4 et le Surface SDK 2.

Evénements et Sessions

by Nicolas Calvi 8. décembre 2011 18:04

Un petit billet pour vous parler des sessions que je vais animer dans les 3 prochains mois.

Après midi du développement

Design et nouvelles interfaces naturelles

Le 9 janvier à 14h00 au campus Microsoft France

J'animerais une session sur le sujet "Comment gérer et développer une application tactile". Au programme, méthodologie, définitions des nouveaux métiers et implémentation d'un ScatterView avec le Surface SDK 2.0.

Techdays 2012

Les 7, 8 et 9 Février 2012 au Palais des Congrès de Paris.

Session : Au coeur d'un projet Kinect Innovant

Session : Tout sur Microsoft Speech

 

J'espère que vous viendrez nombreux !

Microsoft Surface 2 - Pré-commande ouvert

by Nicolas Calvi 18. novembre 2011 11:01

Ca y est on est plus très loin de la sortie officiel de la table Microsoft Surface 2. Tous les détails dans le lien ci-dessous :

http://blogs.msdn.com/b/surface/archive/2011/11/17/preorder.aspx

Microsoft Surface 5

SqlDependency, vue rapide.

by Nicolas Calvi 14. octobre 2011 11:54

Il m’a été amené récemment à utiliser les SqlDependency dans le cadre d’un de mes projets. Je vous fais donc partager aujourd’hui mon retour sur cette fonctionnalité SQL Server / .Net et en bonus je vous donne un code pour les gérer plus facilement.

Qu’est que SqlDependecy

Avant toute chose, revenons sur cette fonctionnalité. Depuis SQL Server 2005, il est possible de créer une dépendance entre du code .Net (via les APIs ADO.Net) et un jeu de résultat SQL. Pour faire simple, SQL Server va pourvoir nous notifier quand le résultat d’une requête change. Pour cela on lui fournit une requête SELECT simple qu’il va exécuter, le résultat de cette requête servira de référence pour la notification. Ensuite, si ce même SELECT donne un résultat différent plus tard, SQL Server nous rappelle pour nous notifier que le premier résultat obtenu est différent du dernier résultat qu’il a évalué. Très pratique en web pour faire de l’invalidation de cache.

Requête et base de données

Il y a cependant des choses à connaître quand on utilise la SqlDependecy. Par exemple pour la requête qui est donnée pour référence :

  • La requête qui est donnée pour référence ne doit pas être avec un SELECT *, il lui faut des noms explicites de colonne.
  • La requête qui est donnée pour référence doit indiquer l’utilisateur qui possède la table accédée, par exemple [dbo] pour le cas le plus courant. 

On doit donc avoir des requêtes qui ressemblent à ça : 

SELECT [col1], [col2] FROM [dbo].[MaTable]

Ensuite au niveau de l’instance de la base de données, il faut activer le service BROKER sur la base, si ce n’est pas fait cette commande permettra de l’activer :

ALTER DATABASE [Nom Base] SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE

Le service BROKER va permettre justement de gérer cette communication entre notre assembly et SQL Server. Une fois cette fonctionnalité activée, passons au code coté .Net.

Implémentation de la SqlDependency

Ci-dessous le code pour implémenter simplement une SqlDependency, je vais l’expliquer par la suite.

private void CreateDependency()
{
  string connectionString = "Mettre ici la chaîne de connexion";

  // Démarrage du broker sur la base
  SqlDependency.Start(connectionString);

  // Création de la connexion
  using (SqlConnection connexion = new SqlConnection(connectionString))
  {
    // Création de la commande pour la requêt de référence
    using (SqlCommand command = new SqlCommand("SELECT col1 FROM [dbo].[MaTable]", connexion))
    {
      command.Notification = null;

      // Création de la dépendance
      SqlDependency dependency = new SqlDependency(command);
      dependency.OnChange += new OnChangeEventHandler(DependencyChange);

      // On démarre la dépendance
      command.ExecuteReader();
    }

    // Fermeture de la connexion
    connexion.Close();
  }

  // Arrêt du broker sur la base
  SqlDependency.Stop(connectionString);
}

private void DependencyChange(object sender, SqlNotificationEventArgs e)
{
  // On se désabonne
  (sender as SqlDependency).OnChange -= new OnChangeEventHandler(DependencyChange);

  // Code de traitement ici
}

Ici on peut voir comment se structure la création de la SqlDependency. On doit d’abord démarrer le BROKER de la base, afin qu’il écoute les dépendances, ensuite on exécute une requête ADO.Net classique, à savoir l'instanciation d’une connexion, la création d’une commande et l'exécution de celle-ci.

La création de la dépendance se situe entre la création de la commande et son exécution. On y crée alors la dépendance sur la commande et on s’abonne à l’événement OnChange pour récupérer la notification de changement.

La dépendance n’est créée qu’au moment où la commande est exécutée, le résultat qu’elle produit est la référence SQL Server pour savoir si un changement a été fait.

Ensuite c’est très simple, dès que le résultat de la requête de dépendance change, la fonction de retour (ici DependencyChange) est appelé, il n’y a plus qu’à faire les traitements qui nous intéresses. 

Par contre, il faut bien comprendre une chose, une SqlDependency ne fonctionne qu’une seule fois ! Une fois qu’elle est traitée (en gros que la fonction de retour est invoqué) elle disparait du serveur SQL Server et ne fonctionnera plus. En gros, c’est à usage unique.

Il est donc impossible de créer une SqlDependency qui va invoquer la fonction de retour autant de fois que le résultat de la requête de dépendance est modifié. Pour pouvoir boucler sur les modifications, il faut recréer une autre dépendance.

Dans cette optique, il n’est donc pas nécessaire de conserver les instances des commandes, connexions et autre objets utilisés pour la création de la dépendance. C’est pour cela que dans le code ci-dessus, tout est libéré par des 'using'.

Manager de dépendance

Vous pouvez télécharger plus bas, deux classes qui permettent de gérer des SqlDependency de façon plus automatique et de boucler sur les notifications. J’ai créé ces classes dans le but de factoriser la gestion des SqlDependency par chaîne de connexion. Pour les utiliser, il faut ajouter l’assembly 'System.Configuration', voici le détail des deux classes :

DependencyManagerItem.cs (8,22 kb)

Cette classe gère une dépendance simple, de façon atomique. On peut l’utiliser seule, mais elle n’active pas le BROKER coté base de données. Le constructeur est classique, on y renseigne la chaine de connexion, une fonction de retour et si on active le mode continue (qui recrée la SqlDependency automatiquement).

Cette classe, possède ensuite une propriété 'Datas' qui renvoi l’état du résultat de la requête de référence, ce qui permet de l’avoir sans avoir à le requêter à nouveau. Ensuite, pour démarrer la dépendance il suffit d’invoquer la méthode 'Start()', si vous êtes dans un mode boucle, la méthode 'Stop()' permet d’arrêter la dépendance.

DependencyManager.cs (5,58 kb)

Le principe de cette classe est de gérer de façon plus globale les dépendances. On l’instancie avec une chaine de connexion et elle va démarrer le BROKER de la base, mais aussi l’arrêter quand elle sera recyclée.

Elle possède des propriétés qui lui permettent de démarrer des dépendances avec des valeurs par défaut (il est toujours possible de démarrer une dépendance sans ses valeurs par défaut).

Pour démarrer une dépendance, il faut invoquer la méthode 'Create()' qui prend en paramètre un nom, ce nom servira à identifier la dépendance pendant tout son cycle de vie dans le Manager. Ensuite il y deux versions de 'Create()', une qui crée la dépendance avec les paramètres par défaut, et l’autre pour les outrepasser. Pour finir, une méthode 'Remove()' mettra fin à une dépendance nommée.

Ces classes sont faciles d’utilisation et vous avez le code, donc libre à vous de les étudier et/ou de les adapter à vos besoins.

SDK Surface 2 : Touch & Code

by Nicolas Calvi 26. juillet 2011 07:00

Je vais présenter dans cet article les premiers éléments de la programmation tactile à travers WPF 4 (dit WPF Touch) et le SDK Microsoft® Surface® 2.0. Pour bien comprendre ce qui va suivre, je vous conseille la lecture de mon dernier article sur les notions élémentaires pour la programmation tactile.

Pour commencer, parlons des événements de base de programmation tactile, à  savoir : juste toucher l’écran et démarrer une action suite à cette interaction. Cette partie est gérée par WPF 4 à travers un certain nombre d’événements (tous ces événements existent en version « Preview »). Ils sont disponibles sur l'ensemble des objets qui héritent de « UIElement » et on comme scope l’objet lui-même, ce sera important pour les derniers événements que je vais présenter. Voici la liste de ces événements :

TouchDown : Correspond au moment ou un contact s’initie sur le périphérique, en clair : on pose le doigt.

<Grid TouchDown="Grid_TouchDown">
</Grid>
private void Grid_TouchDown(object sender, TouchEventArgs e)
{        
    // Code de l’évènement
}

 

TouchMove : Correspond au déplacement du contact sur le périphérique, donc quand le doigt (toujours en contact avec le périphérique) bouge sur celui-ci, c’est cet évènement qui va tracer les informations du contact (position, orientation dans le cadre de Microsoft Surface 2.0) tout au long de sa vie.

<Grid TouchMove="Grid_TouchMove">
</Grid>
private void Grid_TouchMove(object sender, TouchEventArgs e)
{        
    // Code de l’évènement
}

 

TouchUp : Correspond à la fin du contact et informe donc qu’il n’existe plus sur le périphérique. C’est donc quand on lève le doigt du périphérique.

<Grid TouchUp="Grid_TouchUp">
</Grid>
private void Grid_TouchUp(object sender, TouchEventArgs e)
{        
    // Code de l’évènement
}

 

TouchEnter : Cet événement correspond au moment ou un contact entre dans la zone de rendu d’un objet, si le contact a été initié en dehors ou est sorti de la zone pour entrer à nouveau, c’est ce qui sera déclenché. 

<Grid TouchEnter="Grid_TouchEnter">
</Grid>
private void Grid_TouchEnter(object sender, TouchEventArgs e)
{        
    // Code de l’évènement
}

 

TouchLeave : Ce dernier événement fait l’inverse du « TouchEnter » à savoir qu’il informe de la sortie du contact de la zone de rendu du contrôle.

<Grid TouchLeave="Grid_TouchLeave">
</Grid>
private void Grid_TouchLeave(object sender, TouchEventArgs e)
{        
    // Code de l’évènement
}

 

Ces événements sont identiques à ceux de la souris, on peut donc les assimiler à la gestion de celle-ci lorsque l’on clic, le clic correspondant au « TouchDown ».

Tous ces événements génèrent dans leurs « Callback » un délégué avec comme argument une instance de la classe « TouchEventArgs » qui représente les informations du contact. Cet argument est particulièrement intéressant, car il va nous permettre de détecter les capacités de notre périphérique.

C’est là que notre SDK Microsoft Surface 2.0 va nous être utile. Il va étendre via des méthodes d’extensions les informations liées aux événements « Touch » de WPF 4. Pour cela, un peu comme pour les extensions « Linq » nous devons ajouter à notre classe la référence de l’assembly « Microsoft.Surface.Presentation.Input » ce qui va permettre d’étendre l’une des propriétés de « TouchEventArgs » à savoir le « TouchDevice ».

Le « TouchDevice » représente toutes les informations relatives au contact qui c’est produit sur le périphérique. Il va donc nous permettre de récupérer des informations diverses sur notre contact.

    

 

Quand on développe une interface tactile et que l’on ne connaît pas précisément le périphérique qui va exécuter l’application, on peut faire appel à la classe « InteractiveSurface.PrimarySurfaceDevice » qui permet de tester les capacités de celui-ci. Exemple de propriétés très utiles :

IsFingerRecognitionSupported : Permet de savoir si le périphérique est capable d’identifier la différence entre un doigt posé sur celle-ci ou un objet quelconque. La table Microsoft Surface 2.0 par exemple en est capable, mais si d’autres périphériques peuvent le faire, ils peuvent le signaler par cette fonction.

IsTagRecognitionSupported : Permet de savoir si le périphérique à la possibilité de reconnaitre des « Tags » (comme Microsoft Surface 2.0), le périphérique peut l’indiquer par cette fonction.

IsTiltSupported : Permet de savoir si le périphérique est inclinable (comme Microsoft Surface 2.0).

IsTouchOrientationSupported : Permet de savoir si le périphérique peut tracer l’orientation d’un contact sur celui-ci (comme Microsoft Surface 2.0), à savoir l’angle qu’il forme avec le point zéro de la zone tactile.

IsTouchBoundsSupported : Permet de savoir si le périphérique peut connaitre la surface de contact (comme Microsoft Surface 2.0), c’est-à-dire la forme et l’aire de ce qui touche le périphérique.

Si le périphérique supporte certaines de ces capacités, il est donc possible de faire appel à des fonctions d’extension du « TouchDevice » pour avoir cette information sur le contact en cours.

GetIsFingerRecognized() : Permet de savoir si le contact est un doigt ou non.

GetIsTagRecognized() : Permet de savoir si le contact est un « Tag ».

GetTagData() : Permet de récupérer la valeur du « Tag » posé sur le périphérique.

Juste avec ces fonctions on est donc capable d’adapter notre interface tactile et de prendre en compte des informations complémentaires. Il devient alors facile d’extraire les informations du contact et de les traiter.

private void Grid_TouchDown(object sender, TouchEventArgs e)
{
    if ( InteractiveSurface.PrimarySurfaceDevice.IsFingerRecognitionSupported && e.TouchDevice.GetIsFingerRecognized() )
    {
      // Détection d'un doigt
      // On effectue les traitements liés au doigt
    }

    if ( InteractiveSurface.PrimarySurfaceDevice.IsTagRecognitionSupported && e.TouchDevice.GetIsTagRecognized() )
    {
      // Récupération de la valeur

      var tagValue = e.TouchDevice.GetTagData();

      // Détection d'un tag
      // On effectue les traitements liés au tag
    }
}

Ensuite il y a les actions communes que l’on peut faire avec un contact, comme récupérer sa position :

// On récupère la position par 
// rapport à un élement graphique
// mettre NULL pour récupérer la 
// position par rapport au device

Point p = e.TouchDevice.GetPosition(this);

Avec ces primitives de base, vous êtes capable de créer des applications tactiles basiques en gérant les contacts simples. Dans un prochain billet je vous montrerais comment utiliser les manipulations (dites Gestuelles) dans votre application.


Certifications

MVP

Microsoft Surface

MCTS

Microsoft .Net