Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

De Silverlight à WinRT (partie 2)

[new:30/08/2012]Parmi les petites différences entre Silverlight et WinRT, en voici une qui concerne l’accès au thread de l’UI, ce qui est essentiel.

Le Thread de l’UI

C’est “ze” thread d’une application Silverlight, WPF et même WinRT. C’est ce thread qui est le seul à pouvoir manipuler les objets d’interface, c’est lui qui, s’il est bloqué par un traitement long, fige l’application, situation aujourd’hui interdite par toutes les guidelines.

Sous ces environnements on travaille donc systématiquement sur des threads secondaires pour décharger le thread de l’UI, ce que C#5 avec sa gestion async/await simplifie grandement, l’asynchronisme devenant sous WinRT la base même des mécanismes de programmation même les plus simples.

Décharger le thread de l’UI n’est pas compliqué en soit. Ce qui l’est c’est de mettre à jour l’interface utilisateur depuis un thread secondaire.

Dans une construction MVVM utilisant le Binding, on n’a généralement pas à s’en soucier car les mécanismes de Binding prennent en charge ce problème. Le ViewModel peut changer la valeur d’une propriété, même depuis un thread secondaire, la propagation vers l’interface se passe correctement.

Il n’en va pas de même dès qu’on manipule directement un objet d’interface.

Pour ce faire, le thread secondaire doit demander d’exécuter l’action au thread principal (celui de l’UI). Ce qui oblige à passer par le Dispatcher. Certains toolkit MVVM (Mvvm Light, Jounce..) offrent leur propre dispatcher, mais les plateformes SL et WinRT ont aussi le leur.

Le nouveau Dispatcher

Sous WinRT le nouveau Dispatcher ressemble fortement à l’ancien. Mais les paramètres sont légèrement différents. On dispose notamment d’un paramètre permettant d’indiquer le niveau “d’urgence” de l’exécution de la tâche dispatchée. La classe mère du Dispatcher semble avoir aussi changé mais peut-être n’est-ce que temporaire (et cela n’a pas d’incidence directe sur l’utilisation de la classe).

Un code portable

Pour rendre un code portable Silverlight / WinRT il est donc nécessaire d’utiliser une construction #IF. Ce qui, en première approximation donnera :

   1: #if !NETFX_CORE
   2:   Dispatcher.BeginInvoke(
   3: #else
   4:   Dispatcher.Invoke(CoreDispatcherPriority.Normal, 
   5: #endif
   6:            (sender, args) => { ... }
   7: #if NETFX_CORE
   8:       , this, null);
   9: #endif
  10:    );

Dans la réalité on aura plutôt intérêt à écrire une méthode ou une classe d’aide qui se chargera de faire la différence une bonne foie pour toute et à l’utiliser partout dans son code au lieu, bien entendu, de farcir ce dernier de #IF dans tous les coins...

Conclusion

Rien de bien compliqué ici encore. La ressemblance du code Xaml et C# de Silverlight avec celui de WinRT est telle qu’on peut assez facilement envisager un code portable sur les deux plateformes.

Il reste bien entendu milles autres détails qui rendent un tel portage pas aussi simple que cela. Par exemple l’asynchronisme systématique sous WinRT qui peut introduire de grosses différences dans le code.

Pour l’instant nous en sommes aux bêta, il faut donc rester prudent sur les différences réelles auxquelles nous devrons faire face avec la version finale de WinRT.

De plus, s’il semble illusoire de vouloir créer très facilement un code complet et complexe pouvant passer sans souci entre SL et WinRT, nous avons déjà de bonnes assurances qu’un certain type de code pourra passer sans gros problème, comme par exemple des classes définissant des données ou des traitements simples. C’est déjà toute la structure de base d’une application qui est portable, et c’est déjà beaucoup.

Plus loin, je ne suis pas convaincu que dans le futur nous serons amené à écrire beaucoup d’applications se devant d’être compatibles entre Silverlight et WinRT. Je pense plutôt que le problème se posera entre des applications WPF et WinRT.

Sur la base d’une même application on pourra vouloir une version WinRT pour attaquer le marché RT tout en continuant à produire une version WPF échappant au Windows Store et ses taxes, ou tout simplement par souci de compatibilité pour continuer à vendre une application à tous les possesseurs d’un Windows plus ancien (XP, Vista, Seven).

Il y aura ainsi, je le pense, un véritable besoin de compatibilité entre WPF et WinRT, plus fort qu’entre SL et WinRT pour la raison invoquée. Silverlight, s’il ne doit pas mourir, restera de toute façon en entreprise pour les intra et extranet, le Web grand public étant terminé pour les plugins de ce type (comme Flash). Et dans un tel cadre, l’intérêt de porter une application interne en WinRT semble assez restreint. Alors que dans une logique Editeur, disposer d’une version WinRT en plus d’une version WPF vendable hors Windows RT m’apparait une stratégie plus fine et totalement justifiée.

D’ici là,

Stay Tuned !

Faites des heureux, partagez l'article !
blog comments powered by Disqus