Office Video Explorer, retour d’expérience sur une application Windows 10

Nous venons de finir le développement d’Office Video Explorer. Une application Windows 10 Universal Windows Platform permettant d’accéder et de visionner les vidéos partagées sur le réseau Office 365 de votre entreprise.

Si vous voulez la tester sur votre PC, tablette ou smartphone Windows 10 vous pouvez vous la récupérer ici : https://www.microsoft.com/fr-fr/store/apps/office-video-explorer/9nblggh1z7h2

Suite à ce développement voici une première salve de retours d’expérience :

L’organisation d’une application Universal Windows Platform 

Windows 10 apporte son lot de nouveautés pour le développement d’applications Windows Store. La plus intéressante est que maintenant il n’y a qu’une seule application à développer, qui tournera sans (presque) aucune distinction sur PC, tablette, téléphone et bientôt Xbox et Hololens. L’organisation d’une application multiplateforme s’en voie grandement simplifiée. Voici l’organisation du code d’OVE.

blog ai3 OfficeVideoExplorerOrganisation-236x300 Office Video Explorer, retour d'expérience sur une application Windows 10

MVVM toujours présent 

Tout d’abord, nous utilisons l’architecture MVVM pour organiser notre projet ainsi que le Framework MVVM Light pour nous simplifier la vie. L’ensemble de nos View Models sont définis dans notre dossier ViewModels et contiendront l’ensemble de la logique de notre application. Rien de neuf ici par rapport à une application Windows 8 :

blog ai3 OfficeVideoExplorerOrganisation1-300x184 Office Video Explorer, retour d'expérience sur une application Windows 10

Un nouveau binding plus performant

Windows 10 apporte également le binding compilé. Ce nouveau binding apporte de grands gains de performances mais quelques restrictions : celui-ci est entre autres fortement typé et s’effectue sur le contrôle/la page courant(e) plutôt que sur DataContext. L’ensemble de nos pages contiennent donc toutes une propriété ViewModel :

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

Le binding aura ainsi la syntaxe suivante dans nos pages XAML :

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

Attention, ce nouveau binding est en mode one time par défaut, il faut bien penser à le passer en mode one way quand nécessaire pour éviter de mauvaises surprises.

Des pages et contrôles adaptatifs 

Au niveau des vues, l’application tournant indifféremment sur téléphone et sur PC, l’interface se doit de s’adapter à la taille de l’écran : nous nous approchons du responsive design du web. Pour mettre en place ce système, l’application utilise le VisualStateManager. Celui-ci met à jour les différents éléments graphiques selon les différents états de l’application que nous avons définis.

Par exemple nous utilisons le nouveau contrôle SplitView : pour une largeur d’écran inférieure à 1000 pixels, celui-ci est par défaut minimisé et peut être maximisé au clic sur le bouton hamburger, pour une largeur d’écran supérieure à 1000 pixels, celui-ci sera toujours affiché :

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

Managed Extensibility Frawmework (MEF)

Ce Framework de Microsoft permet de remplacer le principe d’injection de dépendances (Unity par exemple) par le principe de Composition. Celui c’est est antérieur à Windows 10.

Sur les propriétés d’une classe ou les paramètres de son constructeur, on peut définir un attribut [Import]. En faisant ainsi, lorsque l’on compose cet objet, la valeur des paramètres/propriétés est automatiquement alimentée via MEF, qui se basera sur le type de la propriété, et potentiellement sur des métadatas. Cette composition est récursive : l’objet donné en valeur au paramètre ou à la propriété sera lui aussi composé si nécessaire.

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

Dans le cas de notre application, toutes les fonctionnalités nécessitant d’être lancées au démarrage de l’application implémentent l’interface IKernelPartLaunchable.

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

Grâce à MEF, au lancement de l’application, on recherche toutes les classes implémentant cette interface et appelons leur méthode de lancement. Nous avons configuré MEF pour que ces classes soient utilisées comme des singletons : une nouvelle instance sera créée à leur première composition, puis l’instance créée sera réutilisée pour les compositions suivantes. Avec ce système, pour qu’une nouvelle fonctionnalité soit appelée au démarrage de l’application, la seule étape nécessaire est de lui faire implémenter l’interface IKernelPartLaunchable.

[pastacode lang= »cpp » message= » » highlight= » » provider= »manual »]

[/pastacode]

 

Voici pour cette première salve de retours, d’autres articles viendront plus en détails sur certains points techniques, notamment l’accès aux services Office Vidéo.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.