Why WinJS can be a good front-end framework…

We are still early in 2015 and the JavaScript front-end ecosystem is still hot.

There are many popular frameworks out there, Angular 1.x, Angular 2 in alpha, React, Ember, Backbone, Aurelia, Polymer, …

This post is the first on a series about WinJS. In this first episode, we will see what is WinJS, and what it is good for.

Web vs Native

All those framework have their own personnality, strengths and weaknesses. But they all have one thing in common : they are built for the web. To my point of view, none of those frameworks are built for making embedded applications like native HTML Windows apps, Cordova apps, Firefox OS apps, …

Designing and optimizing a mobile application for web, or for an embedded applications is different. When building for the mobile web, your worse ennemy is network latency. Every image, stylesheet or script is slowing your site down, and every bytes count. You try to bundle your files as much as possible to avoid those pitfalls.

When you are building for an embedded application, you don’t care about those network latencies. Every file resides on the device, and loading them is as fast as the SSD is on the device. In fact, on most modern hard drives, it can be faster to load several small files than loading a big one. In addition, in those applications, you will favor loading your application incrementally. It helps your app start fast, and saves memory and battery on the device.

Users don’t care…

With an embedded application, users expectations are different. The user does not know, or care, that your application is built using web technologies. He click on your app icon and assumes that it will perform as any other app on his device. The rendering engines are getting faster and faster but it is still not as performant as native.

To achieve a native look and feel, you must have a fine grained control over the DOM, and you sometimes have to orchestrate how and when your views are built and rendered. Common frameworks tends to abstract DOM away and relies on data binding to build UI. It could lead to a lot of frictions when it comes to optimizing your views. Some frameworks, especially Ionic are built with that performance constraint in mind, but unfortunately, they does not work well on all platforms.


WinJS is a JavaScript front-end framework that was publicly announced in september 2011, at the first Microsoft //Build conference. At that time, it was designed to make native Windows applications using HTML and javascript. Since then, it has been open-sources (go have a look at it on Github) and the latest version are designed to work well on all recent mobile devices. WinJS has basics for the different peaces needed by an application framework (templates, binding, messaging, …) and a rich set of UI widgets.

WinJS has been designed for making fast, native looking applications, and it’s great for that. Whether it is on Android, iOS, or Windows, you can take the most of what your device can do with web technologies. You can use it for web (it is still HTML/CSS/Javascript) but it’s really not designed for it.

What is great with it is that the framework rely on componentization of your UI. You are building your UI by composing controls. Controls can be simple JavaScript classes, or they can rely on « Fragments ». A fragment is loaded from an HTML file, and all dependencies defined in the HTML are loaded along with the fragment. You could modularize your UI and logic, and load it incrementally in a very natural way.

As you can see, the mindset when building an application with WinJS is very much like what you have with WebComponents approaches (except for the Shadow DOM aspects). The main difference is about the syntax you use for declaring your controls (instead of defining custom elements, you use attributes).

So, WinJS is wonderful ?

Well… considering what you can do with it, yes. But it is far from perfect. Sometimes, it’s really not developper friendly.

WinJS is very unopiniated about how to do things. It’s great because you stay in control but it means you have to do a lot of things by hand. What is really sad is that, in its almost 4 years, WinJS has not improved at all for that matter. Microsoft has focused their efforts on UI widgets (making them cross platform for example), but you are still writing a lot of unnecessary boilerplate code.

We have made dozens of applications with WinJS, for Windows, as well as Android or iOS. From time to time we gathered a lot of tools and helpers, and a while ago we decided to publish them to the community, as a « WinJS Contrib » project. In the other parts of this series, we will show you the different aspects that you could improve by using WinJS Contrib.

We will see how to reduce boilerplate code, use ES6/Typescript classes, use WinJS with webcomponents syntax in the markup… so stay tuned !

[Build 14] – Windows Phone 8.1 Security Features

Mail de John
Samedi 5 avril 2014 20:33


Windows Phone 8.1 Security Features 


Les objectifs :
– Minimiser le temps nécessaire aux utilisateurs de ré-entrer leurs identifiants
– Offrir aux développeurs un modèle de programmation riche
– Transformer le téléphone en un appareil d’authentification

Microsoft Account :
– Suppression du vieux protocole d’authentification du Windows Phone hérité de Windows Mobile et remplacement par celui de WinRT
– C’est le principal fournisseur d’identité sur Windows Phone
– La majorité des utilisateurs sont authentifiés avec leur compte MSA
– Ajout du Single Sign ON
– Windows.Security.Authentication.OnlineId est le namespace pour ces nouvelles API
– Convergés avec Windows

Avantages de MSA :
– Roaming des données entre les appareils
– Les utilisateurs n’auront probablement pas besoin de ré-entrer leurs identifiants
– MSA évolue indépendamment de l’OS
– Meilleure robustesse et sécurité

Trois options pour utiliser MSA :
– OnlineId – Meilleure méthode
– Web Authentication Broker (OAuth)
– Live SDK – Permet d’accéder à OneDrive

Démonstration d’une authentification utilisant OnlineId

Web Authentication Broker

Description du fonctionnement du processus d’authentification OAuth avec schemas à l’appui.
Auparavant avec une webview :
– Pas de single sign-on
– Pas d’isolation des identifiants
– Ne fonctionne pas dans les cas de faible mémoire

Maintenant avec le WAB :
– Utilisation de OAuth
– Avantages
o Single Sign On
o API simple
o Isolation des identifiants
– Windows.Security.Authentication.Web
– API similaire à Windows mais optimisée pour les situations à faible mémoire

Démonstration du Web Broker et du « Continuation Pattern »

Stockage des identifiants :
– Utilisation du Credential Locker
– Windows.Security.Credentials
o PasswordVault
o WebAccount non supporté sur Phone
– Roaming des identifiants avec le Credential Locker

Crypto et certificats :
– Convergence avec WinRT
– Nouveaux namespaces

Virtual Smart Card :
– Autorise l’authentification “two factor” pour le S/MIME et les scenarii de navigation sécurisée
– Les clefs d’authentification sont liées au matériel et ne peuvent être accéder tant que l’utilisateur n’a pas fourni son code PIN
– VSC est construit au-dessus de TPM (Trusted Platform Module)

Présentation de l’architecture de VSC
Démonstration de VSC

Applications sur carte SD :
– Pas d’API mais les développeurs peuvent désactiver le stockage de leurs applications sur carte SD depuis le manifest
– Cryptage des fichiers de l’application sur la carte SD (différentes clefs entre le programme et les données de l’application)
– Contrôle d’accès pour FAT

[Build 14] – Dealing with Data : Storage, Roaming, and Backup on Windows and Windows Phone

Mail de John
Samedi 5 avril 2014 20:32
Dealing with Data : Storage, Roaming, and Backup on Windows and Windows Phone
Les problèmes à résoudre :
– Chaque localisation a une API différente
– Les interactions avec les localisations des utilisateurs sont limitées.
– Créer des applications cross-device est difficile.
– Les données précieuses des données sont piégées dans les vieux appareils des utilisateurs

StorageFile and StorageFolder :
La plupart des contenus des fichiers sont gérés par ces classes
o Fichiers/Dossiers locaux
o File activation
o Media libraries
o Share contract
o Pickers
Les métadonnées disponibles varient par fichier.

Description du modèle de fichiers :
– Roaming
– Local
– LocalCache
– Temp

Dans Windows Phone 8, les fichiers existants dans l’IsolatedStorage sont disponibles avec l’API WinRT.

Accéder aux contenus de l’utilisateur

Les données de l’utilisateur sont exposées via KnownFolders (RemovableDevices, MusicLibrary, PicturesLibrary, VideosLibrary) et protégées par des capabilities.

Access Cache

Il est utilisé pour maintenir l’accès aux fichiers partagés (file activation, share contract, file picker). Il est mémorisé par le système même après une suppression. Il faut quand même copier le fichier si on veut le modifier.

Storage for Windows Phone Silverlight 8.1

Nouveau modèle de données :
– Roaming/Temp/Local
– IsolatedStorage == Local Folder
– IsolatedStorage APIs fonctionnent toujours

Les KnownFolders APIs sont disponibles pour les media et cartes SD. Les API XNA fonctionnent toujours.
Démonstration (Stockage de fichiers, CommonFileQuery, Pagination, Possibilité de préciser dans l’émulateur un dossier simulant une carte SD).

OneDrive stocke jusqu’à 100Ko, si la taille est supérieur la synchronisation s’arrête. La synchronisation entre Windows 8 et Windows Phone fonctionne.

Bonnes pratiques pour le roaming :
– Settings
– Rester sur des types WinRT
– Eviter les dépendances entre le roaming et les fichiers

Démonstration du roaming entre une application Windows et une application Windows Phone (attention il faut que les appxmanifest des deux applications aient le même PackageFamilyName)

Les données du dossier AppData sont sauvegardées une fois par jour et ce même si le Roaming est désactivé. OneDrive ne maintient qu’un seul Backup par device et par application. La taille du backup compte dans la taille du stockage OneDrive de l’utilisateur.

La fonctionnalité de sauvegarde est activée par défaut pour toutes les applications 8.1 mais pas pour les applications 8.0 ou pour les applications d’entreprise ou side-loadée. On peut désactiver ce backup soit en sauvegardant le contenu dans le dossier LocalCache ou en décochant la fonctionnalité dans le manifest.

Dans Windows Phone 8.1 le StartScreen avec ses tuiles est aussi sauvegardé et peut donc être restauré suite à une installation. Certaines tuiles peuvent faire références à des fichiers du stockage local qui n’existeraient plus suite à une restauration. Il faut donc s’assurer que les applications que l’on développe ne plantent pas dans ce cas.


[Build 14] – Windows Runtime for Windows Phone Developers

Mail de Mehdi
Vendredi 4 avril 2014 10:31

Windows Runtime for Windows Phone Developers

// Speakers : Doug Holland, Jerry Nixon

On débute la session par un petit Historique de WP (7.0 Silverlight, 7.5 Silverlight, 7.8 Silverlight, 8.0 Silverlight, 8.1 Silverlight et maintenant WinRT)
Le speaker commence par nous dire pourquoi nous devons rester sur du Silverlight : Beaucoup d’investissement (une base importante de code) utilisation de certaines API toujours pas disponible avec WinRT (exemple : VoIP, Lock Screen WP) et que Microsoft respecte nos investissements et que Silverlight pour WP continuera à être supporté/amélioré en parallèle que WinRT.

Ensuite il nous dit pourquoi nous devons re targeter nos applications en Silverlight 8.1. La réponse est simple : pour avoir accès à plusieurs nouvelles API (accès à la carte SD, GeoFencing, App Sharing)

Et enfin, il nous dit dans quel cas nous pouvons/devons choisir WinRT. Et là aussi la réponse est plutôt simple : plus de convergences (avec Windows) nouveaux contrôles (lesquels ? aucune présentation) choix de langage …

Petit rappel sur le async await (avec comme règle toute méthode qui dépasse les 50 millisecondes doit être en asynchrone pour ne pas bloquer l’interface et c’est ce qui fait dans WinRT).

Si on choisit le développement avec WinRT le speaker nous présente plusieurs API qui ne sont plus disponibles et qui sont généralement remplacées par l’API équivalente sur Windows.

Si on utilise Microsoft.Phone.Task :
– MarketplaceReviewTask n’est plus disponibleet doit être remplacé par un lacement d’une uri qui redirige vers le store
– Même chose pour le MarketplaceSearchTask
– Le WebBrowserTask est remplacé par Windows.System.Lancher.LanchUri
– AdressChooserTask remplacé par Windows.ApplicationModel.Contacts.ContactPicker
– PhoneCallTask remplacé par Windows.ApplicationModel.Cells.PhoneCallManager
– SmsComposeTask remplacé par Windows.ApplicationModel.Chat.ChatMessageManger
Microsoft.Phone.BackgroundAgent est remplacé par BackgroundTask (comme sur windows 8) avec plus de features.

La navigartion sur WP ne se fait plus par chemin, mais par type de page (comme sur windows 8)

Le bouton back ne ferme plus automatiquement l’application.

Les fichiers de localisation sont maintenant de resw en XAML nous avons maintenant x : UId l’identifiant qu’on utilise uniquement dans ces fichiers. On peut spécifier une propriété genre LeUidDunElement.text ou LeUidDunElement.Foreground.

Dernier point de la session, on nous reparle de la particularité du fileOpenPicker, quand on l’utilise on quitte l’application (elle passe donc en suspended voir elle est tuée par l’OS) donc quand on sélectionne un fichier l’application est relancée on passe par l’event activeted avec en arguement l’activation par fichier.

[Build 14] – What’s new with Windows Phone Silverlight Apps !

Mail de John
Vendredi 4 avril 2014 06:11

What’s new with Windows Phone Silverlight Apps!


Différences entre les applications XAML et les applications Silverlight.
Le framework XAML est le framework du futur. C’est là où les prochaines mises à jour auront lieu. Mais le framework Silverlight continuera à être mis à jour quelques temps afin de suivre les évolutions du framework XAML pour les applications existantes.

La convergence entre les API est de l’odre de 90%.

Cependant certaines API n’ont pas encore migrées :

– Lenses
– Camera Capture Task
– Clipboard
– Lockscreen Wallpaper
– Ringtone et Alarmes
– Simple sound effects (XNA)
– Photos Extensibility
– Search Extras


On enchaîne par une démonstration de la migration d’une application Silverlight 8.0 vers Silverlight 8.1

Les applications Silverlight 8.1 s’exécutent dans le même contexte que les applications WinRT. Pour cette raison, les applications Silverlight 8.1 disposent maintenant d’un fichier appxmanifest en plus de l’historique fichier WMAppManifest.xml. Les deux doivent être mis maintenus à jour.

Lorsque l’on migre en 8.1 il y a quelques « breaking changes » :

– CLR/Silverlight bug fixes
o Array.Sort (IntrospectiveSort à la place du QuickSort)
o DateTime.Parse (correction de bugs)

– Différences au niveau de contexte d’exécution des applications WinRT
o Fast App Resume est activé par défaut (resume vs replace)
o Appuyer sur back ferme l’application, à la différence des Universal Apps, mais il existe une API spéciale qu’il est recommandé d’utiliser pour que les applications Silverlight 8.1 fonctionnent comme les Universal Apps.

Fonctionnalités non supportés dans Silverlight 8.1 :
– Background Audio (existe dans les Universal Apps)
– Continuous Background Execution Agents (GPS Apps)

Nouvelles fonctionnalités et mises à jour :

– Nouvelles API disponibles pour les applications Natives (C++)
– WinRT APIs
– SD Card Support
– Share Source
– Share Target
– WNS Push Notification Trigger
– WNS Notifications
– Storage
– GeoFencing
– Bluetooth 4.0
– Background Tasks
– Known Folders (Audio/Video/Photos/…)
– Appointments / Calendar Enhancements
– Email with Attachments
– Web Authentication
– Data Roaming
– Accessibility (UIA, Large Text, High Contrast)

On a ensuite une démonstration du remplacement d’un EmailComposeTask par un Share Contract avec une pièce jointe suivi d’une autre démonstration où on ajoute une BackgroundTask.

Le Store supporte maintenant 3 versions d’une application (7.1, 8.0 et 8.1).
Avant de pouvoir déployer une application 8.1 pour la première fois, il faut réserver un nom spécifique à cette version. Ce nom doit se trouver dans le appxmanifest et il faut l’éditer à la main en mode texte (voir slides de la présentation).





[Build 14] – Multitasking and Background Processing on Windows Phone

Mail de John
Jeudi 3 avril 2014 10:56

Multitasking and Background Processing on Windows Phone

On commence par un petit rappel du model de multitasking dans Windows Phone 8.
S’ensuit un rappel du modèle d’exécution des tâches de fond dans WinRT (Processus séparés, réponds à des Triggers et à des conditions).

Présentation des triggers disponibles dans Windows Phone.
Comment créer une tâche de fond ?
– Implémenter IBackgroundTask.
– Modifier le Manifest pour activer l’accès aux tâches de fond.

Démonstration en C# de création d’une backgroundtask et comment on l’enregistre dans le système (BackgroundExecutionManager.RequestAccessAsync), l’ajout de triggers (BackgroundTaskBuilder, SystemTrigger, SystemCondition). Ensuite démonstration de comment lancer une backgroundtask en Javascript (Ajout de la définition de la propriété TaskEntryPoint du BUilder qui correspond au fichier js contenant la tâche).

Les tâches de fond natives (aka WinRT) sont disponibles dans les applications Silverlight 8.1. Les BackgroundAgents sont maintenant hébergés par l’infrastructure WinRT.

Accès aux Sensors, Bluetooth LE, RFCoom même si l’application n’est pas en premier plan.
Basé sur les nouvelles API Bluetooth WinRT.

Nouveau triggers :
– GattCharacteristicNotificationTrigger
– DeviceChangeTriggfer
– DeviceUpdateTrigger
– RfcommConnectionTrigger

Les notifications de Geofencing peuvent être reçues en background dans une tâche de fond.
Ajout des Push Triggers dans Windows Phone.
Associer une Background Task avec un WNS channel.
Activation d’une tâche de fond grâce à une notification push raw.

Démonstration des Push Notifications.

Le rendu XAML dans les BackgroundTasks est maintenant possible ! (Démonstration de ceci en C++ c’est mieux pour la mémoire).

– Windows.Networking.BackgroundTransfer
– Pas de restriction de taille de fichiers
– Support du multi part mime (pour les gros fichiers)
– Verbes HTTP supplémentaires (PUT, RETR, STORE) et aussi FTP
– In-progress stream access
– Data-Sense and Battery Save aware

Non disponible pour les applications Windows XAML :
– Continuous Background Location
– Runs-Under-Lock
– VoIP Agents
– Wallet Agents

Economiseur de batterie :
Permet de trier et de gérer les applications qui tournent en tâche de fond et de voir leurs utilisations de ressources

Contraintes de ressources :
– Toutes les tâches de fond ont des quotas CPU, mémoire et réseaux
– Les quotas sont basés sur l’utilisation actuelle du CPU au lieu d’une limite d’horloge
– Le quota d’horloge sera renforcé (au moins une fois toutes les 30 secondes)
– Le quota de mémoire s’adapte aux capacités de chaque device.
– Le TimeTrigger aura un temps d’exécution assuré d’un maximum de 30 minutes maximum.
Appelez RequestAccessAsync() pour avoir votre quota maximum.


[Build 14] – From 4 to 40 inches Developing Windows Applications across Multiple Form-Factors

Mail de John
Jeudi 3 avril 2014 10:41

From 4 to 40 inches Developing Windows Applications across Multiple Form-Factors

Rappel de la différence entre la layout et les assets.
Layout: Physical Size and Shape, Viewing Distance, Effective Resolution
Assets: Detail Level, Scale Factor, Mastering

Il ne faut plus se demander quelle est la taille de mon application. Il faut se demander quelle forme a mon application (tall, thin, wide).

Démonstration de l’adaptabilité du layout et de la taille du contenu d’un jeu de morpion.
La résolution effective de l’application est importante, pas la taille de l’application.

Démonstration de l’utilisation des VisualState dans Blend pour s’adapter à la taille de l’application. (Utilisation d’un petit helper une classe de base d’une page qui change le VisualState en fonction de la taille).

Choisir de bons assets en fonction de la résolution. Si une image a beaucoup de détails en grande résolution et qu’on la redimensionne en une image à faible résolution elle sera très pixélisée. Il faut choisir une image avec moins de détails à faible résolution quitte à ce que l’image ne soit pas tout à fait la même que celle à haute résolution.

La densité relative des pixels d’une image est importante pas la densité réelle de pixels (DPI).
Il est important d’appliquer les conventions de nommage pour les assets (exemple image.scale-240.png) qui permettra de choisir automatiquement la bonne image en fonction de la résolution. Il faut quand même préciser la taille d’affichage de l’image car sinon le moteur de layout (HTML ou XAML) multipliera la taille de l’image au lieu de s’adapter au DPI.

Génération des assets :
– Déterminer la taille désirée de l’image en pixels effectifs
– Déposer ces assets dans le dossier partagé
– Multiplier la taille du layout par 2.4
– Déposer ces assets dans le projet Phone
– Vérifier que le résultat est le bon sur les appareils cibles (les émulateurs et simulateurs sont insuffisants pour une vérification d’assets)
– Si le resultat est bon vous avez fini
– Sinon essayez un scale factor supplémentaire de 1.4 ou 1.8

Création des masters assets :
– Dans l’idéal utilisez des assets vectoriels
– Sinon des bitmaps ayant un scale factor supérieur ou égal à 400%
– Exportez cet asset dans les scale factor cible nécessaires
– Ne pas oublier le niveau de détail
– Ne pas s’inquiéter si on a un asset à basse résolution

Mais où est le code ?
La plupart du temps il est inutile d’écrire du code pour gérer ce sujet.
Cependant voice quelques informations utiles pour la suite.
DisplayInformation.GetForCurrentView() :
– ResolutionScale (Windows (enum))
– RawPixelsPerViewPixel (WP (double))
– RawDpiX, RawDpiY (Ignore unless measuring real-world objects (ruler, hardware,etc..))
– LogicalDpi (avoid unless working with Direct2D or legacy code that assumes 96 DPI)

Silverlight : Information importante pour la migration d’application Silverlight vers WinRT. La résolution effective minimale pour les téléphones a changée. Il faut multiplier les constantes de taille par 0.8.

Utilisez les bons mots !
– Bien : Effective resolution / shape / scale factor
– Mal : physical resolution / orientation / DPI
Architecturez pour un layout flexible. Préférez l’utilisation de composants à celle de pages monolithiques :
– Laissez le moteur de layout faire son travail
– Focalisez-vous sur le bon set d’assets
– Commencez avec des master assets de haute résolution
– Ne générez que les scales factor nécessaires
– Assurez-vous que le niveau de détail est approprié