[SPC14] SPC413 // Complex Problem Solving with the New HTML5 APIs

Mail de Christian

Mardi 04/03/2014 à 10h45

Speaker
Scot Hillier – MVP @ Scot Hillier Technical Solutions, LLC

// Résumé
Comme en 2012, le mec est un peu considéré comme un dieu et a rempli la salle, pourtant énorme, réellement je pense qu’il y a 2500 personnes dans la salle … et c’est une session 400 elle s’annonce très rapide et très technique. Bref le wifi est tombé tellement il y a du monde.
Après coup, cette session est un peu violente en code mais elle est très intéressante ; c’est allé très très vite avec du code assez poussé. C’est donc très dense, on va vite et on finit même 20min en retard. On y voit pas mal de concepts qui tirent partie d’HTML5 pour être utilisés dans les App SharePoint.
Il rappelle malgré tout qu’il est important d’avoir des navigateurs compatibles.

// Intro
Scot se présente, il fait des formations, du développement et du SharePoint depuis 10 ans. Il est MVP, a écrit 4 livres sur SharePoint récemment.
Il fait 80% de projets, 20% de talks, le monsieur se présente. MVP depuis 9 ans.

// From bricks to houses
En 2010, il explique que SharePoint étaient des briques assemblées.
En 2013, SharePoint avec les Apps, les AppPart … On est vraiment avec des vraies maisons complètes.
Ça pour dire que les Apps sont des fonctionnalités à parts entières.

// HTML5 quick preview
Un doctype différent, de nouveaux éléments sémantiques (<article>) qui sont comme des divs spécifiques à une utilisation particulières optimisées pour le SEO … des éléments fonctionnels nouveaux (<video>).
Il rappelle qu’il faut faire attention aux navigateurs qui supportent HTML5 dans l’entreprise où on l’implémente.
Il brosse une liste de différents nouveaux tags sémantiques HTML5 (header, nav etc.) qu’il ne couvrira pas complètement.
Egalement une liste de nouveaux éléments fonctionnels (canvas, video etc.).
Il note que de nouveaux éléments CSS3 apparaissent aussi (bordures arrondies etc.) avec des spécificités par navigateur (ms-, moz- etc).

// Nouvelles APIs HTML5
Media, Drag drop, Offline Applications, Mime type, canvas, messaging, history, server-sent events, Websockets, web workers, web storage).

// Responsive App Parts
Le challenge c’est d’avoir des App part (qui sont des iframes) qui sont responsive et s’adaptent à l’espace allotti.
Solutions : media queries ou postMessage.
Les media-queries permettent de définir le style selon les devices (largeur, hauteur, orientation, aspect etc).
Il a fait une déclaration <link avec media= »(max-width:800px ») où il déclare une CSS. et une CSS où il déclare ses CSS via @media. En javascript il peut faire un window.matchMedia qui dit si ça marche le device-width, on exécute un handler.
L’autre solution est d’utiliser postMessage. C’est une méthode HTML5 qui permet à une iFrame de communiquer avec la page maître. Il y a une gestion de la sécurité car cela autorise le cross-domain. Il faut donc vérifier le message transmis pour éviter les injections de scripts.
Pour ce faire il y a un système d’émetteur/recepteur.
L’émetteur récupère l’iframe contentWindow et utilise la méthode postMessage().
Côté récepteur, il attend un message avec document.addEventListender(« message », …).
Pour AppPart, window.parent.postMessage en passant un noeud HTML pour dire qu’on agrandit l’iframe.

// DEMO : Responsive AppParts
Il a fait une App avec un calendrier custom.
Il a également fait une App Part qu’il a inséré sur on host. Il démontre que son App Part est responsive et s’il diminue la taille de son navigateur, il voit son App Part se redimensionner.
Il retourne sur Visual Studio pour montrer son code.
Il y a du code de récupération des données avec des promises etc. Il utilise le plugin fullCalendar pour gérer son calendrier.
Il a ajouté son AppPart avec des propriétés pour spécifier la vue. <Property><EnumItems>.
Pour expliquer son propos, il y a un Script Part qui exécute un media query pour définir la vue pour l’App Part.
Ainsi selon ses propriétés dans l’app part , il peut dire quelle taille minimum il a besoin selon la vue qu’il sélectionne.
Ensuite dans un mediaquery il peut définir selon la résolution de l’écran on choisit le CSS qu’il faut.

// Single-Page Apps (SPA)
Rappel, ce sont les applications App qui prennent tout l’écran.
Il y a un gros challenge car on n’a peu de chargement de page, tout se fait sur l’écran. On change les éléments de l’écran sans recharger la page côté serveur.
La solution : AJAX Navigation with history object.
Cela permet de gérer les états de la page avec une gestion en pile de l’historique de navigation.

// DEMO : SPA et AJAX Navigation
Il montre une App avec des contacts, paginée sur 51 pages.
Sa liste de contacts se rafraichit quand il navigue.
Sauf que si l’utilisateur fait back avec le navigateur, il risque de casser là où ilétait. Or il le fait et il revient à la page précédente de sa liste de contacts (page 3 avant la page 4).
Il montre en Visual Studio.
Il utilise AngularJS qu’il discutera dans la session de cet après-midi. C’est vraiment pas mal pour les SPA.
Il explique que sans framework il est vraiment moins pratique de faire des SPA.
Il utilise un modèle MVC pour son App avec un modèle « Contact ». Il déclare son controller.
Il utilise du jQuery pour changer le nom de sa page.
Il utilise ensuite l’objet history. Il peut ainsi utiliser history.replaceStat ou history.pushState pour remplacer l’état ou ajouter un état pour définir des paramètres qui signifie à ma page dans quel état il est.
En utilisation le rounding … de AngularJS, tout ça est géré très bien.

// AppPart Communication
Il va montrer la simulation de ce qu’on avait pour les WebPart, les connected WebParts Solution : Shared message broker with Server-Sent events et Websockets Server-Sent Events : il autoriser un serveur de faire du push d’information au javascript.
Puis utilisation WebAPI pour faire du PushStreamContent et gérer les Server-Sent Events.
Le client doit créer un endpoint grâce à un window.EventSource (cela est du HTML5, encore une fois attention au navigateur, Modernizr est ton ami pour détecter le navigateur et faire autre chose si ce n’est pas un navigateur supporté).

// DEMO : Connecting App Parts with Server-Sent Events Il a 3 projets : un MessageBroker qui récupère l’info et l’expose en WebAPI REST service, Le consumer et le provider qui vont s’enregistrer sur le MessageBroker via un AppPartId. Le provider va pousser un message au MessageBroker, qui va le transférer avec WebAPI au consumer.
Le provider envoie un filtre, le consumer est un graphe avec des données.
De son provider, il a une textbox pour filtrer le type de graphe. Cela envoie un message au graphe qui est filtré.
Le code sera sur Yammer.
Il passe sur VS. Il a 3 controllers (consumerController.cs, MessagesController, ProvidersController.cs). Il nous conseille d’investiguer dans WebAPI qu’il faut connaître.
Le MessagesController va permet de mapper des méthodes.
Il décrit la méthode Get utilisée par le provider, où il crée un Event-Stream. C’est la méthode qui reçoit la commande du provider.
Ensuite il décrit la méthode Post, qui va boucler sur les consumer en envoyant le message avec le contenu du message.
// Il montre l’App du provider
Il fait appel au service WebAPI en passant l’AppId, et le body du message.
// Il montre l’App du consumer
Il crée une instance d’EventSource avec l’URL de endpoint du WebAPI.
C’est ici que sur le onmessage il s’attache sur l’évent de réception de données.

// WebSockets
Il crée une communication dans les deux sens Nécessité d’un serveur WebSocket qui va recevoir et renvoyer les messages (Il utilise Alchemy http://alchemywebsockets.net).
Il ouvre une connexion avec un new WebSocket(« ws://myserver ») pour ouvrir le endpoint. Ensuite il s’attache aux événements (onopen, oncles, onmessage, onerror) et la méthode send.

// DEMO
Un peu de la même façon que le MessageBroker, on a un Alchemy WebSocket server avec le provider qui envoie un message au serveur WebSocket qui répond au consumer.
Dans Visual Studio, il a un projet C# qui va pusher et poper les messages dans une queue de messages.
C’est Alchemy qu’il a mis dans son projet et qu’il a customisé.
Il a des Dictionary pour gérer les connexions, les messages et les subscriptions.
Sur l’événement de onconnect, il ajoute juste l’adresse du client dans les OnlineConnections.
Sur le OnReceive, il fait un switch qui va traiter le message et faire les actions correspondantes, puis poper la requête.
Côté AppParts, il utilise AngularJS pour créer des services avec factory(). Et il utilise aussi new WebSocket() pour ensuite s’attacher aux événements correspondants.

// Multi threading
Javascript est single-threaded, ce qui a un avantage de simplicité mais un inconvénient lorsqu’on a des traitements longs.
Solution : Utilisation des WebWorkers pour simuler un nouveau thread.
Un objet Worker est dédié à un seul appel.
Un objet SharedWorker supporte plusieurs appels.
this et self référence le WebWorker.
importScripts permet de référencer d’autres librairies.
Les restrictions sont que les communications sont faites uniquement par postMessage et on ne peut pas accéder à tout le DOM.
On crée un worker = new Worker(’task.js’). Et attacher un évent worker.addEventListener(‘message’, function(e) … où e est la réponse du message.
Dans le worker on utilise le mot-clé self … (désolé j’ai pas suivi la fin de la phrase … trop rapide pour moi).

// DEMO Type Ahead
Il montre une App qui d’un côté tape un mot, et de l’autre, des mots correspondant en mode auto-complétion.
En Single thread, pas de souci si le traitement est court (peu de mots par ex).
Si la tâche de recherche est longue (plein de mots potentiels), la saisie est bloquée le temps de la recherche.
On passe en multi thread, on voit apparaitre un logo loading et la saisie libre, car cela permet en fait de ne pas bloquer l’UI lorsque la recherche est en cours.
Il montre sur VisualStudio, que sur l’app, on fait appel au Worker avec new Worker.
Sur le worker lui-même, il décalire un XMLHttpRequest(), et sur la propriété onreadystatechange il fait son traitement de la réons, et renvoie avec self.postMessage(html), HTML qui va être traité dans la réponse. Puis exécute sa requête REST SharePoint.

// Maintaining SharePoint Context
Quand on écrit des Apps Multi-Page, on a au début les informations de contexte (URL du host etc.).
Solution : Web Storage. On va utiliser la geolocation pour le fun.
Web Storage permet d’avoir du stockage local (objet localStorage), ou du stockage par session (objet sessionStorage).
Le stockage se fait par clé/valeur.
localStorage.setItem(‘key’, ‘value’) / localStorage.getItem(‘key’).
sessionStorage.setItem(‘myobj’, JSON.stringify(objet));
window.onstorage(function(e)) où e.key/e.oldValue/e.newValue/e.storageArea est géré.
Christian SU

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s