Loupe

UWP : quoi de neuf dans la prochaine mise à jour RS4 pour les développeurs

L'information est déjà disponible depuis un moment dans la vidéo du Community Standup de l'équipe Windows et même sur le site de Microsoft (en anglais ici) mais un bon article en français sur les prochaines nouveautés (unboxing de SDK ?) qui arrive ne fait pas de mal ! 

 Personnellement, je suis très heureux de voir évoluer ce SDK que j'apprécie beaucoup. La liste des évolutions est longue mais voici mes préférées :

  • Applications console en UWP !
  • Applications UWP multi-instances,
  • Accès aux même fichiers que l'utilisateur sans Picker !

 

Applications console en UWP 

L'idée surprend au premier abord mais il s'agit bien de créer des applications Console en UWP déployables sur tous les devices supportant un Shell. On cible donc dans un premier temps le Desktop et l'IOT mais rien n'empêchera Microsoft de rajouter le Shell sur les XBox un jour ou l'autre.

D'un point de vue développement, on est sur du .net standard 2.0 et la volontée affichée est donc de pouvoir copier-coller le code existant d'une app console et que cela fonctionne tel quel

Pourquoi faire une app Console en UWP ? Notamment pour pouvoir bénéficier du déploiement via le Store : plus besoin d'ajouter votre application dans le PATH, elle le sera de base après installation. Il sera aussi possible de mettre des alias dans le manifest de l'application pour la rendre disponible sous un petit nom personnalisé. 

Quelles limites ? 

  • Il n'est pas possible d'utiliser de l'UI (logique en même temps),
  • Certains contrats d'activations ne sont pas supportés (fichiers, protocoles, etc.) et c'est bien dommage :(
  • Pas de possibilité de faire des tâches de fond.
  • Uniquement disponible en C++ pour le moment.

Pour plus d'informations, c'est par là !

Applications UWP multi-instances

Auparavant, il était possible de créer des applications multi-fenêtrées, on s'en servait même dans un précédent article sur une application HoloLens.

Ce que propose Microsoft est de créer plusieurs processus d'une même application. Là encore, cela ne sera disponible que sur les plateformes IOT et Desktop.

Bien sûr vous aurez le choix et il s'agira de l'activer au sein de votre manifest avec l'option "SupportsMultipleInstances". Il sera même possible de faire de la multi-instances redirection : choisir au lancement si l'on utilise une instance existante (exemple : vous ouvrez le même document Word) ou si l'on créé un nouveau processus (vous ouvrez un nouveau document Word).

Chaque instance de votre application aura un identifiant que vous choisirez vous même et il sera possible de retrouver une instance existante avec l'API AppInstance.FindOrRegisterInstanceForKey(key). Ce choix devra être fait au tout début du lancement de votre application : dans la méthode Main ajoutée notamment pour les applications Console. Il y aura un template de disponible pour ce genre d'application car il faut penser à mettre certaines directives de pré-compilation pour gérer correctement ce Main non-classique.

Il faudra aussi faire attention à vos Background Task. Si vous utilisez le modèle originel (Out of Process - une lib à part qui est gérée par l'OS) il n'y aura a priori aucun soucis mais le mode InProcess introduit dans l'anniversary update (on en parlait aux Eperiences'17 avec Jérome) ne sera pas supporté dans ces scenarii.

 Pour plus d'informations, c'est par là 

Accès aux même fichiers que l'utilisateur sans Picker !

Et j'ai envie de dire "enfin" ! De base on était limité à l'accès à quelques emplacements bien restreints dans une application UWP et il fallait demander l'autorisation à l'utilisateur via des Pickers. D'un point de vue sécurité c'était assez génial mais d'un point de vue liberté de développer un peu moins surtout pour des applications B2B.

Avec l'ajout d'une capacité au manifest

Dorénavant, en ajoutant la capacité "broadFileSystemAccess" à votre Manifest, il deviendra possible d'accéder à tous les fichiers et dossiers accessibles par l'utilisateur. La première utilisation d'une API du namespace "Windows.Storage" demandera quand même son autorisation à l'utilisateur une fois pour toute. Pour information, il sera possible d'activer cela automatiquement au niveau entreprise via une group policy.

Sans ajouter de capacité au manifest

Aussi, sans même ajouter de capacité à votre manifest, une application lancée depuis une ligne de commande aura accès au dossier depuis lequel elle est lancée. Il a été décidé par Microsoft que si l'utilisateur s'amuse à aller dans un dossier en ligne de commande pour lancer une application, c'est qu'il veut vraiment donner accès à ce dossier à l'application. On parle d'autorisation implicite ici.

 

Pour plus d'informations, c'est par là 

 

Ce n'est qu'une partie des nouveautés mais je trouve cela très intéressant !

 

Happy coding :)

Photo de profil

Ces billets pourraient aussi vous intéresser

Vous nous direz ?!

Commentaires

comments powered by Disqus