Tout débat « HTML5 vs Natif » attire forcément les trolls de tout bord. Etant aussi bien intéréssé par du dev Natif (iOs) que HTML5, j'espère rester impartial tout au long de cet article.

Ainsi je vais commencer par vous donner « MA » vision des choses sur ce point avant de décomposer une des plus fameuses applications du moment : celle de LinkedIn ! Histoire d’aller voir ce qu’il y a sous le capot ! Surprise, surprise !

Il existe actuellement quelle que soit la plateforme de développement (android, iOs, Blackberry…) trois architectures techniques possibles :

Natif : on utilise le langage propriétaire de la plateforme

•  iOs : ObjectivC, C/C++
•  Android : Java / C

HTML5 (buzzword préféré des geeks de moins de 22 ans)

•  xHTML homebrew  
•  JQueryMobile
•  SenchaTouch
•  GWT brut de chez brut…

Hybride

• Utilise le meilleur de deux mondes précédents
• Nécessite les deux compétences dans les équipes évidemment… ou de sous-traiter une partie.

 Voici un petit  résumé des avantages / inconvénients de ces solutions :

	Coût de développement	Présence AppStore	Validation requise pour déploiement	Fonctions matérielles (calendrier, accéléromètre, gps, photo)	Déploiement	Performance
Natif		OUI	OUI	OUI	LONG	Excellente
Html 5		NON	NON	CERTAINES	RAPIDE	Correcte
Hybride		OUI	OUI	OUI	Selon la techno impactée	Correcte

Je refuse tout simplement de donner une valeur même relative aux coûts de développements car ceux-ci sont trop dépendants des personnes dont vous disposez pour les réaliser.

Le seul gain effectif du HTML5 est la factorisation du développement (si celui-ci est bien pensé) sur les différentes plateformes.Toutefois je reste persuadé que du dev mobile HTML5 cross-platform demande également beaucoup de temps dès que l'on souhaite autre chose que la simple application sous JQueryMobile (toujours en béta). Ainsi il faudra falloir se remettre à tester sur chaque navigateur comme sur nos bon vieux postes ... heureusement pour vous designers de tout bord, IE6 n'existe plus sur ces plateformes.

 

Le site http://mobilehtml5.org donne une matrice des fonctionnalités supportées en HTML5 en fonction des différentes plateformes.   

D'ailleurs parlons en de cette fameuse application HTML5 mobile de LinkedIn ! Soit disant la bête du HTML5 ! Si vous avez un smartphone allez sur : touch.linkedin.com 

Ce site est le coeur de la nouvelle application mobile de LinkedIn. En fonction de votre navigateur, vous aurez plus ou moins de plaisir à l'utiliser. Cet article (http://blog.wapreview.com/14814/) pointe les déboires de l'application LinkedIn sur des navigateurs moins courants que les dernières versions de Safari ou Android. Vous touchez ainsi aux limites du html5 sur mobile. Je suis volontairement caustique juste pour faire comprendre que le html5 est certes une belle techno et sera la techno maître à venir des années futures mais que ce n'est pas encore la panacée !

Alors maintenant prenez votre iphone et allez sur AppStore et télécharger l'applicaton LinkedIn. Application qui va de soi est native (au moins en partie) car elle ne serait pas sur le store :-)

Les images suivantes mettent côte à côte les mêmes fonctionnalités de la version mobile et de la version native. On se rend tout de suite compte que le contenu est similaire sur de nombreux points mais aussi que la version html5 pure est bien pauvre par rapport à la version native vendu comme HTML5. C'est bien ce que je reproche aux articles des différents journaux web c'est l'absence de recul sur ces technos. De l'avis même d'un des core développeurs chez Linked In, le HTML5 ne se prête pas à tout .

Je vous conseille absolument de lire cet article : http://venturebeat.com/2011/08/16/linkedin-node

Quelques fonctions de l'application avec un rendu différent selon la techno :

 

• Menu bien différent selon les deux technos : A gauche la version native et à droite la version html5. La navigation native est bien plus agréable.
  

 

• Certains menus sont différents : Votres réseau / Groupes.  A gauche la native et à droite la html5 (moins riche)
  

 

• Heureusement sur certains points les deux versions sont très proches. Techniquement on inclut dans la version native un composant UIWebView affichant du HTML5. Ne pas oublier que iAd de Apple est entièrement HTML 5 !
  

 

Pour choisir la solution technique, vous devez vous poser cette question : ai-je besoin d'une fonction uniquement présente en natif ? Exemple : présence dans l'appStore, pouvoir prendre des photos... notifications push ?

• Si oui, vous n'avez pas de meilleurs choix que l'application hybride (le choix de LinkedIn). Il vous reste alors la tâche de séparer ce qui sera HTML5 du code natif. Ainsi vous aurez déjà des fonctions facilement intégrable sur les autres plateformes.
• Si non, vous aurez un autre souci :-) Choisir le bon framework HTML5. La littérature sur le web ne manque pas à ce sujet.

Pour conclure, je dirais que le travail d'un fournisseur de services mobiles à ce jour est de réfléchir avec son client à ses besoins fonctionnels et identifier pour chacun d'eux la meilleure solution technique parmi les choix précédents. Certains ne jurent que par HTML5 et d'autres par le natif... Vous connaissez mon avis désormais.

 

 

Nicolas Muller 

JEE Architect & Mobile Dev  

 

 

Je n'aime pas Facebook.
Pourtant dans le cadre de mon travail je suis amené à conseiller nos clients sur leur présence sur Facebook, et comment en tirer parti.

Je me suis donc fait violence et, il y'a quelques semaines, j'ai commencé à suivre de nombreuses pages pour voir ce qu'il s'y faisait.

J'aime Michael Connelly, c'est un écrivain américain, l'un des maitres du polard. Voici quelques uns de ces livres adaptés au cinéma : Créance de sang ou encore le récent La défense Lincoln.

Naturellement j'ai donc "liké" la "fan page" de Michal Connelly.
Voici le statut qui ma collé une petite claque et dont je souhaite vous parler :

En gros, si on envoie une photo de soi en train de lire un livre de Michael, on recevra un petit cadeau, en plus ce n'est pas que pour les Etats-Unis.

 

J'ai donc envoyé ce magnifique auto-potrait bras gauche tendu.

Il est important de noter que toutes les photos envoyées par les fans sont publiées sur son compte Flickr, il est multi-canal Michael !

 

Une bonne semaine plus tard seulement, surprise !

Le cadeau en question est un petit livre qui détaille le processus de création de ses deux personnages principaux : le flic Hieronymus Bosch et l'avocat Mickey Haller.

Si ce n'est le budget, qui me semble conséquent, il n'y a qu'a voir le nombre photos sur le Flickr de Michael (ici), c'est vraiment l'idée qui me plait.

On prend soin de ses fans sur la page de Michael.

Il ne faut pas oublier qu'un "fan" consomme trois fois plus qu'un "non fan" ; alors en bon fan j'ai achété son dernier livre, bien joué Michael, ça marche.

Et vous, vous prennez soin de vos fans ? 

 

 

Je vous parlerai aujourd'hui du produit JBoss évoqué lors du dernier MarsJug en présence d'un de ses commiters Jeff Mesnil.

Connaissant le non moins fameux MQ-Serie je sentais que la soirée ne m'apporterait pas grand chose mais par respect pour les intervenants je suis venu. Et quelle claque ! Ainsi j'ai pu découvrir un fabuleux produit de la stack java JBoss : HornetQ. Celui-ci est un MOM aka Middleware Oriented Message. S'intégrant aussi bien dans un serveur JEE ou bien en application standalone (via netty), cet outil peut vous aider à construire des architectures orientées message à la fois très puissantes et très souples.

Sans rentrer dans le détail de JMS, un serveur crée des files de messages qui sont de deux natures possibles : Queue et topic. Des abonnées peuvent poster et consommer les messages en attente sur ces listes.

• Queue : le message sera consommé par un unique abonné. Celui-ci acquiert le message puis commit ou rollback à l'issue du traitement du message.
• Topic : le message sera reçu par chacun des abonnés.

Vu le nombre actuel de projets opensource sur le marché, la qualité de la documentation est un critère à prendre en compte très sérieusement. Le fait qu'un groupe tel que JBoss soit derrière rassure d'autant.

Détail du répertoire "exemples" livré en package avec l'application

Détail du répertoire "exemples > jms" livré en package avec l'application

Détail du répertoire "exemples > jee" livré en package avec l'application

Pour ceux qui ne jurent que par les ESB, sachez qu'il est intégré par exemple dans MuleESB. Parfois il est bien plus simple d'utiliser le produit lui même plutôt que dépendre de son intégration par un éditeur tierce (Mule par exemple). HornetQ disposant d'une documentation très exhaustive ainsi que de nombreux exemples concrets ce qui permet de très très vite l'utiliser pour un POC par exemple. Rien qu'au niveau des exemples voici la liste :

Techniquement HornetQ dispose d'une élégante et générique architecture :

• Implémentation valide de JMS (spécification JEE).
  • Un client utilise une api style JMS tout simplement sans se soucier du mode de communication
  • Le produit apporte des fonctionnalé supplémentaires à la spécification.
• Elle ne dépend pas de JMX, JNDI, JCA ... Bien pratique pour être hors contexte serveur d'application.
• Support de REST
• Peut être embarqué dans une application à l'aide de quelques jars et même un seul suffit pour lancer la partie serveur ! Sur ce point bravo d'avoir pensé aux développeurs/intégrateurs du produits.

Jeff Mesnil nous a fait une démo bien sympathique. Chaque personne dans la salle connecté en 3G ou wifi se connectait sur la page de son application. A l'aide des fonctions HTML5 (geolocalisation et websockets), les iphones/ipads notifiaient le serveur JMS ce qui permettait de suivre le déplacement en temps réel des personnes dans la salle. Totalement inutile mais imaginons que nous suivions une flotte de voitures d'une grosse compagnie. HornetQ est désigné d'office comme serveur JMS capable de supporter une telle charge.

Avec un tel produit, il est imaginable de passer trivialement à travers les firewalls pour échanger des données entre applications hétérogénes. Le seul critère est de supporter REST côté client ce qui n'est pas en soi très difficile.

Dans le prochain article, je serai plus technique (avec du code) et expliquerai en détail STOMP, les topics, les queues et espère pouvoir refaire la démo de Jeff :) Bravo à lui de s'être déplacé en tout cas.

 

 

Mise en situation : nouvelle MARQUE propose depuis 4 ans à ses clients d’intégrer leurs projets web sur Liferay, un CMS (Content Management System) basé sur une technologie Java. Comme tout bon CMS, Liferay 5.2 propose aux webmasters d’intégrer leurs articles à l’aide d’un éditeur de type : What You See Is What You Get (Approximately) j’ai nommé FCKeditor ! Aujourd’hui, la plupart de nos clients utilisent cette version datant de 2008. Dépassée, elle augmente largement le temps de chargement des pages et quelques bugs subsistent lors de son utilisation sur Mozilla.

La mission : faire la mise à jour de FCKeditor à CKEditor sur Liferay 5.2. Récapitulatif des avantages de cette nouvelle version : CKEditor hérite bien évidement de la qualité et des fonctionnalités qu’ont pu connaître les utilisateurs sur FCKeditor, dans un produit beaucoup plus moderne, ajoutez à cela des dizaines de nouvelles prestations, comme l'accessibilité et l’ultime performance.

Nativement il est impossible de faire une mise à jour automatique de l’éditeur sur Liferay 5.2. - Qu’à cela ne tienne, je vais bien trouver quelqu’un qui propose une mise à jour manuelle sur les forums. Après une fine recherche sur Google et n’ayant rien trouvé de concluant je décide de poser la question sur un forum spécialisé, et voici la réponse tant attendue :

This has just been developed and will be available in the next version: Liferay 6.0.

Ok ! Cela étant dit, nous n’avions pas prévu de migrer tous nos clients sur la dernière version de Liferay, prétextant que l’éditeur d’articles qu’ils utilisent est dépassé mais fonctionnel. En incluant tous les changements qu’une migration de ce type implique, il n’était pas viable d’envisager une telle solution pour le moment.

Et maintenant ? : « On n’est jamais mieux servi que par soi-même » n’est-ce pas ? Je me lance alors dans l’implémentation de CKeditor sur Liferay 5.2. On aurait dit un épisode de « Man vs Wild », se faire du mal pour réaliser qu’on peut dépasser ses limites. Et donc… 4 cafés, 2 balles antistress et 3 collègues plus tard, je vois enfin le bout du tunnel !

Conclusion : Généralement les éditeurs WYSIWYG mettent un certain temps à se charger, principalement à cause des nombreuses fonctions Javascript qu’ils appellent. CKeditor offre l’une des meilleures performances sur ce point, et travaille d’arrache-pied pour éliminer complètement ce problème. CKeditor propose une API riche et puissante, tant au niveau de l’intégration qu’au niveau de l’interaction. De plus, l’éditeur est maintenant totalement basé sur des plugins que vous pouvez faire évoluer dans tous les sens pour obtenir ce que vous désirez. Avec sa nouvelle interface basée sur un design frais et zen, votre expérience en terme d’intégration de contenu n’en sera que meilleure.

you push the button, we do the rest.

George Eastman | 1888

Matthieu SCHNEIDER
twitter.com/Matthieusch

Mise en situation : Lundi matin 9h30, votre chef de projet arrive et vous debriefe sur une nouvelle création pour un de vos plus gros clients (la pression monte ?). La création n'est rien d'autre qu'un nouveau logo, méfiez-vous des apparences. Ceux à qui une telle situation est déjà arrivée vous voyez de quoi je parle...

Un logo certes, mais pas n'importe lequel, le client aimerait quelque chose de :

• Design
• Contemporain
• Zen
• Original
• Frais
• Simple
• Explicite

Le temps de bien assimiler tous ces mots et vous comprenez que la tâche qui vous est confiée est loin d'être aisée. Rien ne pouvant ébranler votre créativité (et à juste titre) vous vous lancez frénétiquement sur vos crayons et faites des premières esquisses. Les heures passent... et votre créativité trépasse, soumise aux nombres d'échecs de vos précédentes tentatives. C'est la panne d'inspiration ! Expirez calmement, ce n'est pas une fatalité. Aujourd'hui je vous présente un site qui a de l'inspiration à revendre !

Logo of the day : un site épuré de toutes fioritures qui fait place à son contenu : des logos uniquement des logos !

Bien entendu il faut savoir faire la part des choses, il y'a du bon et du mauvais :

Le mauvais d'après moi :

Je vous explique en quelques mots le sens du logo : "Ross + Reiter" est une maison de disques allemande. "Ross" est un ancien mot allemand qui signifiait "Cheval" et la traduction en français du mot "Reiter" est "Cavalier". Le logo s'explique de lui même (d'après la source) : "Cheval + Cavalier"... source en anglais : Logo of the day

Et le bon qui se passe de commentaire :

L'inspiration est maintenant à votre portée, à vos crayons !

Matthieu SCHNEIDER
twitter.com/Matthieusch