Pour de nombreux développeurs Silverlight, la nouvelle la plus séduisante concernant Windows Phone 7 est sa prise en charge de Silverlight parmi les deux interfaces de programmation gérées (l’autre est XNA).
Ce dossier est issu de notre publication IT Pro Magazine (04/11). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.
Ainsi, ils peuvent non seulement exploiter leurs connaissances et compétences existantes afin d’écrire des applications pour le téléphone, mais ils sont censés pouvoir créer des programmes Silverlight pour le Web et la téléphonie compte tenu du code partagé.
Bien évidemment, le partage du code, notamment du code d’interface utilisateur, est rarement aussi simple qu’il n’y paraît de prime abord. La version de Silverlight utilisée sur le téléphone est intitulée Silverlight pour Windows Phone et il s’agit, pour l’essentiel, d’une mouture dépouillée de Silverlight 3. Avant un projet d’application à code partagé, une lecture attentive de la documentation s’imposera : pour chaque classe Silverlight, la documentation en ligne indique les environnements qui la prennent en charge. Au sein de chaque classe, des listes de propriétés, méthodes et événements utilisent des icônes signalant la prise en charge de Windows Phone 7.
Dans une application Silverlight pour le Web, les interactions utilisateur s’effectuent via le clavier, la souris et, peut-être, l’approche multi-tactile. Dans un programme Windows Phone 7, le multi-tactile constitue le moyen principal d’interaction. Aucune souris n’est employée et, même si le téléphone peut comporter un clavier physique, les programmes Silverlight s’appuient uniquement sur l’existence d’un clavier virtuel, intitulé SIP (Software Input Panel), ce exclusivement via le contrôle TextBox.
Si les entrées de vos programmes Silverlight ne passent jamais directement via le clavier ou la souris et s’appuient uniquement sur des contrôles, le passage au multi-tactile ne posera pas de problème. De même, si vos programmes contiennent leur propre logique de souris, vous pouvez en fait la conserver lors du portage vers le téléphone.
Sur ce dernier, les événements tactiles primaires sont convertis en événements de souris, de sorte que votre logique de souris existante doit convenir parfaitement. (Un événement tactile primaire constitue l’activité complète d’un doigt qui effleure en premier l’écran sans que d’autres doigts soient en contact avec ce dernier.)
Le passage de la souris au multi-tactile nécessitera un certain travail de réflexion : Silverlight pour le Web et Silverlight pour Windows Phone gèrent tous les deux l’événement statique Touch.FrameReported, mais ce dernier constitue plutôt une interface de bas niveau pour le multi-tactile. J’ai abordé cet événement dans mon article « Finger Style: Exploring Multi-Touch Support in Silverlight » dans l’édition de mars 2010 du MSDN Magazine (msdn.microsoft.com/magazine/ee336026).
Silverlight pour Windows Phone gère un sous-ensemble des événements Manipulation qui ont fait leur apparition dans le Surface SDK et sont, depuis, devenus une partie intégrante de Windows Presentation Foundation (WPF). Cet aspect constitue un exemple de la banalisation progressive du multi-tactile. Le téléphone gère uniquement les fonctions de translation et de mise à l’échelle, pas la rotation. De même, il n’implémente pas l’inertie, bien que suffisamment d’informations soient disponibles pour mettre en œuvre des fonctions d’inertie de votre cru. Ces événements Manipulation ne sont pas encore supportés dans la version Web de Silverlight.
En résumé, si vous souhaitez partager du code entre Silverlight pour le Web et Silverlight pour Windows Phone, vous allez passer par les événements de souris ou Touch.FrameReported.
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
