La build 2014 a aussi eu son lot d’annonces pour les applications LOB sideloadées avec la première update de Windows 8.1. Beaucoup d’entreprises sont séduites par les design “Modern UI” et les applications Windows Store mais se retrouvent souvent embarrassées par du code existant ne pouvant pas être migré sur le nouveau modèle de développement. Microsoft a apporté quelques réponses à ces problématiques : découvrons-les !

Ouverture de connexion réseau sur la même machine (localhost/loopback)

Il est maintenant possible et autorisé de communiquer entre deux applications d’une même machine via un flux réseau. Il est par exemple possible de créer un service WCF, d’exposer une API ASP.NET MVC ou encore d’utiliser SignalR sur sa machine pour communiquer avec une application Windows Store.

Cette fonctionnalité est activée de base lorsque l’on teste une application via VisualStudio et il est maintenant possible de l’activer de plusieurs façons :

• via des APIs du firewall Windows utilisé par exemple dans un installateur
• via un script powershell (executé par exemple lors de l’installation de l’application)
• via un outil simple disponible sur http://loopback.codeplex.com
• (via Fiddler qui utilise les mêmes APIs)

Pour quel scénario ? Notamment pour permettre la communication entre une application existante et une application Windows Store. Cela permet donc de créer des applications Windows qui vont synchroniser leur “contexte” avec une application “legacy” et faciliter des usages tactiles ou d’affichages de données dans un design “moderne”.

La contrainte de ce scénario est que l’application originelle déclarant le “service local” doit être en cours d’execution.

Le Brokered Windows Runtime Component

Cette nouvelle fonctionnalité permet d’utiliser du code .Net traditionnel existant ou non dans une application Windows Store. Oui, oui vous avez bien lu.

Il est alors possible de créer un composant WinRT (utilisable depuis l’application Windows Store) qui va faire appel à des parties du framework .Net non accessible habituellement comme les apis SQL.

La DLL générée peut alors être utilisée par une ou plusieurs applications Windows Store sans problème.

Pour quels scénarios ?

• Pouvoir utiliser du code traditionnel déjà écrit et migrer alors plus rapidement vers une application Metro
• Pouvoir accéder à des APIs non accessible autrement (SQL, FileSystemWatcher, etc.)
• Pouvoir “supplanter” le cycle de vie de l’application Windows Store : la DLL peut par exemple lever des événements qui vont “réveiller” une app qui serait dans un état suspendu et lui permettre d’exécuter du code
• Pouvoir partage du code : la même assembly pourra être utilisé/consommé depuis plusieurs apps en même temps.

L’avantage de ce scénario est qu’il n’est pas nécessaire d’avoir un service tournant en continu sur la machine locale. L’application Windows Store “consomme” la DLL si nécessaire

WNS disponible

Windows Notification Service est maintenant disponible même pour les applications sideloadées. Il est toujours nécessaire de déclarer l’application sur le Store mais il n’est plus obligatoire de la publier pour pouvoir utiliser WNS.

On peut donc profiter de ce service de notifications scalable sans coût supplémentaire.

N’hésitez pas à me contacter pour plus d’informations !