#UWPHTML – Building Windows 10 web applications

Many people still ignores it, but since Windows 8 (and 8.1 for Windows Phone), you can build Windows native applications using HTML and JavaScript. Yes you read it correctly NATIVE applications. Those applications does NOT run through a webview but with a native HTML/JavaScript application shell called « wwahost ». Those applications are now called « Windows web applications ».

Windows 10 introduced a few enhancements to Windows web apps. They run with a different security context and on Microsoft Edge engine. There is also something called « project Westminster ». More simply, Westminster is « hosted applications », or applications that runs with content hosted on the internet but still have access to Windows APIs. You could find more about hosted apps on our blog, or obviously on Microsoft’s blog.

Windows web apps are fully parts of the new concept of Universal Windows Platform applications. It means that you could make applications using HTML/JavaScript for Windows desktop and tablet, but also for Windows 10 mobile, Xbox, Windows IoT, and the soon to come Hololens.

This post is the first of a serie where we will talk about various aspects of Universal Windows web apps using HTML and JavaScript. We will illustrate the different topics with a real application called « Bring the popcorn », a remote controller for a Kodi or Xbmc media server.

This application is open source, and available in the Windows store. It uses WinJS and WinJSContrib to provide a fast and fluid experience, using the latest features of Edge and Chakra engine (or at least those made available in web apps…).

Hope you will enjoy this serie !

Build 2015 – The « Microsoft Edge » rendering engine that makes the Web just works

Le moteur d’Internet Explorer a 20 ans (1995), mettre en place de nouvelles versions sans altérer la compatibilité devenait un réel problème, et la gestion de la compatibilité un frein à l’innovation et aux performances. Les navigateurs concurrents ne se posent pas ces contraintes… il était donc temps pour Microsoft de faire place nette.

Le moteur de Edge est issu de celui de Trident (le moteur HTML de IE), mais il a subit un gros nettoyage avec la suppression de certaines fonctionnalités anciennes (ex: attachEvent) et de tout ce qui touchait à la compatibilité avec les version séculaires de IE. Edge s’aligne ausi sur le comportement implémenté dans les autres navigateurs pour que les sites fonctionnent correctement, même si ils sont alignés sur les spécificités de webkit.

Edge implémente aussi beaucoup de nouvelles choses. La liste est longue et l’idéal est de consulter status.modern.ie pour se faire un aperçu complet.

Si vous jetez un oeil à cette session, vous pourrez voir des démos de css filters (post processing d’un noeud du DOM avec des shaders déclarés en css), @support (feature detection en css), srcset (gestion des images selon la résolution), svg foreign objects (incorporer du HTML dans du SVG), et HTTP 2 (multiplexage des requêtes, …).

La session se termine par une petite démo de Vorlon.js, un nouvel outil dans la ligné de choses comme weinre, pour diagnostiquer et auditer très facilement une application web, quel que soit son mode de fonctionnement (Cordova, web, web mobile, etc).

Build 2014 – Applications Windows Phone 8.1 en HTML et en Javascript (Channel 9) : David Rousset, Microsoft France, reçoit Guillaume Leborgne, MCNEXT – http://bit.ly/1pX4SDs via @ch9

[Build 14] – How to Analyze Performance Issues in Your Windows and Windows Phone Apps

Mail de John
Samedi 5 avril 2014 20:33
How to Analyze Performance Issues in Your Windows and Windows Phone Apps

La performance est un problème d’expérience utilisateur. C’est l’utilisateur qui jugera. Avoir une application performante améliore les notes dans le store.

Les outils :
– Visual Studio
– WP 8.1 SDK VS Dev Power Tools
o Tracer l’application
– Windows Performance Toolkit
o Tracer l’application et faire une analyse approdonfie
o http://aka.ms/downloadWPT

Identifier les scenarii :
– Se focaliser les scenarii qui
o Ont une vraie valeur pour les utilisateurs
o Sont les clefs de l’utilisation de l’application
o Ont des problèmes de performances visibles
– Fast scenarios
o App launch
o Page navigation
o User Interaction
– Fluid scenarios
o Glitch free animation
o Glitch free panning
o Keeping up with the panning

Demo :
– Capturer une trace
– Localiser un scenario dans la trace
– Investiguer les problèmes de vitesse
– Investiguer les problèmes de fluidité

Cette démonstration utilise à la fois de XAML et du HTML pour montrer que WPA fonctionne dans les deux environnements à la fois sur Windows et sur Windows Phone.
John

Stories from Building the New Windows Mail App (3-104)

Session animée par Jeremy Epling

Retour d’expérience sur la réalisation de la nouvelle application de mail et présentation des tops et pratiques utilisées.

L’application doit fonctionner correctement de matériel 8 pouces peut puissants aux all in one 27 pouces avec quad core.

On voit les différents concepts d’implémentation et les nouvelles possibilités d’ergonomie proposée dans 8.1 comme la possibilité d’ouvrir plusieurs fenêtres pour une même appli (ouvrir plusieurs mails en même temps).

Le choix de html pour l’application de mail a été principalement drivé par le fait que les mails sont souvent en html, ils sont donc plus faciles a restituer dans une app html. On voit comment ils ont découpé le layout et utilise les nouveaux contrôles comme la search box.

Pour les perfs, l’équipe a teste très régulièrement sur Windows RT car, si une app est rapide sur rt, elle est rapide partout. Le nouveau contrôle de Scheduler a beaucoup aidé à améliorer les perfs en permettant de coordonner les opérations, et en facilitant le fait de préparer des portions d’ihm non visibles (comme la fenêtre pour un nouveau mail).

L’appli mail utilise aussi les web workers pour construire des portions d’ihm en générant une string avec le html qui est ensuite envoyée dans l’ui (pas de dom dans les workers).

Pour les listes, garder un layout simple pour les items a un impact significatif sur les perfs (le layout grid par exemple peut parfois être couteux).

Penser ses sélecteurs css et les faire l’élue spécifique possible impacte aussi les perfs (ca se voit sous le nom blopr dans les outils de perf).

Guillaume Leborgne

Windows Runtime Internals: Understanding the Threading Model (4-107)

Session animée par Martyn Lovell

Le but de la session est de présenter pourquoi le threading est important et comment le theading est implémenté dans WinRT et qu’est-ce qui se cache derrière la façade.

La session commence par une démo en C++ nommée « Media Buttons » qui montre tout les threads créés automatiquement par le système.

Pourquoi on a besoin de threads :

  • Services connectés au monde
  • Application responsive
  • Expérience touch
  • Plusieurs cœurs

Comment Windows parallélise :

  • Kernel threads
  • Separate processes
  • Brokers
  • Async operations

 Windows threading model :

  • UI objects dans le thread UI
  • Le thread principal vi aussi longtemps que l’application
  • La plupart des autres objets peuvent être utilisés dans n’importe quel threads
  • La plupart du travail est passé au ThreadPool
  • Les objets Windows suivent des règles naturelles et familières
  • Vous contrôlez la durée de vit d’un thread

 Le thread UI :

  • Les interfaces utilisateurs ont des besoin spécians
    • On ne veux pas que OK soit appuyé pendant le OnCancel
  • Les objet UI sont naturellement sérialisés
  • Ne pas faire de long travail sur le thread UI
  • A la place il faut passer un maximum de travail au thread pool

Demo : Comportement du thread UI

 UI Thread reentrency :

  • Les objets sur le thread UI n’ont pas besoin de locking pour se protéger eux-mêmes
  • Les thread UI ne sont pas réentrants
  • Quand vous faite un appel à un autre thread/process, seul les threads logiquement connectés peuvent vous rappeler
  • Les threads UI ne peuvent pas s’appeler en même temps (rejeté au moment de l’appel dans Windows 8.1)
  • Utiliser un dispatcher ou un objet asynchrone pour éviter ce genre d’appels

Schéma d’explication du « Single-threaded apartment reentrancy ».

 UI Thread waiting :

  • Pas de délais autorisés sur les threads UI
  • Most classic waiting primitives are inappropriate (Windows tue les applications ne répondant plus)
  • A la place il faut appeler des primitives UI-safe (C# await, C++ create_task, JS promise)

Démo : Safe view shutdown (MultipleView Sample)

 Le UI thread Principal :

  • L’interface principale de l’application est toujours lancée dans le thread UI principal
  • Le thread UI principal est utilisé pour gérer l’état global de l’application
  • Les autres threads UI sont pour les documents et les contrats
  • Le thread UI principal est vivant tant jusqu’à ce que l’application meure

 Threading dans l’environnement HTML :

  • Tout les threads sont des threads UI (même les web workers sont single-threaded)
  • Tout les évènement et complétions sont délivrées là où elle ont commencées
  • Utilisez les api standard des applications web au lieu du WinRT Core*

Threading en XAML :

  • Les objets UI sont liés à un threads
  • Utilise le dispatcher to déplacer le travail de l’ui dans le thread UI
  • Tout l’arbre XAML est dans un seul thread
  • Les évènements sont dans le thread UI

Objects and threading

  • Les protocoles basiques de WinRT sont threading-agnostic (Iunknown, Iinspectable)
  • La plupart des objets WinRT n’ont pas besoin de marshaling
  • Même les références à des objets hors du processus (proxies) sont agiles dans WinRT
  • Donc même si le marshaling existe toujours il est rarement visible et ce délibérément

Marshaling :

  • Les objet décident comment ils se marshallent (IMarshal, INoMarshal contrôlent le marshalling)
  • Les objets WinRT généralement « opt-out of marshaling »
  • Tout les marshalers sont fournis par le système avec l’aide des données générés par le MIDL

Thread pool threads :

  • Là où le travail long est effectué
  • Ils sont alloués, étendues et schedulés par le système
  • Les opérations async de WinRT tournent générallement dedans
  • Toujours initialisés par WinRT

Schéma démo des callback sur des objets asynchrones

Les objets agiles :

  • Objets qui peuvent travailler dans n’importe quel thread ou process sans être marshalled
  • Ils ne peuvent stocker que des objets agiles
  • Pas de stockage de Iinspectables
  • Ils sont simple à manipuler
  • La plupart des objets WinRT sont agiles

Apartments :

  • Apartments sont des concepts COM qui groupent et contrôlent les durés de vie des objets
  • Ils existent dans WinRT mais sont maintenant largement inutiles et remplacés par les objets agiles
  • Trois apartment
    • ASTA
    • MTA
    • NTA (Neutral threaded apartment utilisés par WinRT)

Appels cross-threads :

  • Les appels WinRT sont délivrés seulement quand le thread est prêt
  • Les appels sont en compétitions avec les autres pour obtenir l’attention d’un thread
  • Win 8.1 change :
    • Les appels ne bloquent plus les input
    • Le scheduler autorise les priorisation des work items

Une session intéressante qui explique tout ce qui se passe dans WinRT au niveau du threading. Définitivement à voir et à revoir.

John Thiriet

App Performance: The Windows Performance Toolkit (3-100)

Session animée par Chell Sterioff

Objectif : se familiariser avec les outils d’analyses d’applications

Outils d’analyse de performance :

  • Visual Studio
  • Windows performance Toolkit
    • Windows Performance Recorder
    • Windows Performance Analyser

Démo de présentation du recorder et quelles sont les différentes options à notre disposition.

Démo de présentation de tout ce que présente l’analyseur et de la logique à utiliser pour diagnostiquer correctement des problèmes de performance.

Une session très orientée démo et assez difficile à suivre qui dans une certaine mesure entre en conflit avec précédente. La principale difference étant que celle-ci est orienté HTML alors que la précédente était XAML. A voir mais surement plusieurs fois et en plusieurs fois.

John Thiriet

Create Fast and Fluid Interfaces with HTML and JavaScript (3-156)

Session animée par Paul Gildea

Session traitant des perfs et notamment de comment gérer le chargement des apps et des écrans, d’une façon générale et avec les nouvelles API.

UI responsiveness

Un des enjeux est de prioriser des opérations sans lien pour ne pas bloquer le thread UI. Le contrôle Scheduler permet de gérer cette problématique. Le Scheduler permet de définir des priorités sur les traitements. Le Scheduler fonctionne comme un setImmediate.

Consommation mémoire

Winjs implémente un mécanisme de  libération mémoire similaire a celui de .net avec une méthode dispose. Les contrôles qui supportent ce pattern ajoute une classe css “win-disposable”, et doivent libérer les contrôles enfant avec winjs.utilities.disposeSubTree. Le controle Navigator présent dans les templates projet implémente tout cela.

Longues listes

Le point principal concerne le rendu des items. Les contrôles winjs sont responsables du déclenchement de ce rendu. Avec winjs 2 les templates sont compilés, ce qui améliore les perfs. Les templates permettent aussi de libérer la mémoire (disposable). Une option du Template peut le rendre debuggable.

Temps de démarrage

Pour commencer, faire attention à la structure du html car cela impacte le temps de chargement. Le Scheduler permet aussi d’améliorer le chargement (en utilisant une methode requestDrain qui force l’exécution des traitements de la priorité ciblée).

Guillaume Leborgne