Focus sur les applications hybride

Le blog est migré vers blog.reactor.fr

Jusqu’où peut-on aller avec une application hybride ?

A lire la presse spécialisée (ouais ok, « blog » si vous préférez, mais ça fait moins pro…), les applications hybrides seraient LA voie à adopter. Une solution prenant les avantages des applications 100% web et/ou 100% native. (Pour faire la différence, c’est par ici). Les plus grands acteurs comme Microsoft, Adobe, Facebook… ont opté pour cette solution… ce qui serait rassurant. (voir article) pour nous petit développeur de garage. (NB : les plus grands ont commencé dans un garage, en musique aussi d’ailleurs…)

Mais, de mon côté, je ne suis pas convaincu par cette orientation. Surtout, je me pose pas mal de question… Jusqu’où peut-on aller avec une application hybride ? Quelles sont les limites ? Comment fait-on ?

D’abord essayons de bien comprendre ce qu’est une application hybride. Une application hybride est écrite en HTML5 + CSS3 + Javascript ET surtout dispose d’un accès à presque toutes les ressources disponibles sur l’OS (Caméra, accéléromètre système de fichier…) via ce qui est appelé dans le jargon « des conteneurs natifs ». L’intérêt est de minimiser les coups de développement en utilisant HTML5 qui est un langage de présentation simple (même si toutes ses spécifications ne sont pas encore définitivement fixées), déjà utilisé par de nombreux développeur/intégrateur, facile à maintenir et cross-plateforme (rendu par un navigateur web classique ou via un webkit ou via un webview)

Ce schéma explique l’imbrication d’une page web HTML5 dans un conteneur appelé WebView qui est rendu (affiché si vous préférez) par l’application du téléphone. Celle ci est dite native car elle est compilée dans le langage de l’OS (Java pour Android, Objective C pour iOS, C# pour Windows Phone…)

(Source)

On visualise donc le résultat final sur notre appareil (Smartphone, tablette…peu importe) qui dispose d’un OS (iOS, Android… peu importe) qui dispose lui-même d’une WebView qui affiche de l’HTML5.

On est donc très large, normalement on couvre tous les cas, toutes les plateformes, tous les OS… Enfin pas tout à fait. L’élément clé est la liaison WebView – HTML5.

Pour l’instant certaines applications devront rester native, notamment si celles ci ont besoin d’un rendu graphique important (jeu vidéo). Une application hybride sera « plus lente » qu’une application native, mais ces écarts tendent à réduire au fur et a mesure que les appareils gagnent en puissance.

Pour les autres, on peut tenter l’hybride. Dans ce cas, on va utiliser ce qu’on appel un framework Javascript (JS), entendez une panoplie d’outil pré-codé qui nous facilite la vie tant qu’on sait encore comment s’en servir. Voila une petite liste des framework les plus connus :

Oui mais voila, moi développeur, lequel je vais choisir ? et pourquoi ? Pour m’aider j’ai trouvé ce site : http://www.markus-falk.com/mobile-frameworks-comparison-chart/

Une mine d’or ! C’est un immense tableau comparatif des différents frameworks et leurs possibilités. Il y a même un Wizard pour nous aider !

Vu le nombre de Framework, je vais arrêter mon article ici, et développer un exemple plus approfondie en essayant un ou deux parmi ce vaste choix qui m’est offert.

J’ai rapidement essayé PhoneGap et lancé une application sur l’Android Market (Test PhoneGap). J’ai testé avec mon Galaxy S et ça fonctionne bien. J’ai accès à de nombreuses fonctionnalités (Caméra, accéléromètre…), le tout en quelques lignes de codes. Le déploiement est simple. (Enfin, j’avais déjà fait ça en natif, ça aide beaucoup). Par contre elle n’est pas compatible avec la tablette Galaxy Tab 2 ! Je ne sais pas encore pourquoi.

Voila, s’achève une série de 3 articles sur l’univers des applications mobiles. Vous avez vu un bref état des lieux du marché, on a essayé d’avoir une vision à court terme, je vous ai présenté les grands acteurs et décisionnaires dans ce secteur. Ensuite on a pu voir les différents type d’application, leurs incidences sur les couts, leurs contraintes. Et pour finir nous avons développé le type d’application à la mode, l’application hybride qui nous amène au choix d’un Framework JS.

La suite ? Aidez moi à l’écrire ! A bientôt alors !

(…)

Auteur : Yann Vasseur

Native App VS Hybrid App VS Web App

Une app ? N’attendez plus, parlez-en à votre développeur !

Si pour vous les mots web app, hybrid app, mobile site… sont encore un peu flous, alors cet article est fait pour vous !
Avant de commencer, si vous n’avez pas lu Web Stories : « Allo ! Y’a quelqu’un ? », je vous conseil de commencer par là. Cet article nous permet de situer le marché en cette mi-année 2012.

Alors, qu’est ce qu’une Web-App ? Une application hybrid ? Ou native ?

Une Web-App va utiliser les technologies web (HTML, CSS, Javascript). En général, elle « simule » une application native en reproduisant certains éléments comme des boutons, des listes, des cases à cocher, mais en n’utilisant que des éléments web. Cela veut dire qu’elle peut très bien être consultée dans un navigateur sur votre ordinateur de bureau, ou sur votre smartphone. Elle est bien évidemment principalement destinée à la consultation sur mobiles (petit écran), nous parlerions sinon d’un site web classique.

Quel intérêt ? Pouvoir développer une seule application pour une portabilité maximale (appelée aussi Cross-Plateform). Vous pouvez l’utiliser sur tous les supports ayant un navigateur internet. Ce qui est maintenant devenu la norme !

Un inconvénient cependant. Par défaut, l’application web n’aura pas accès à certains éléments natifs de l’appareil, comme le GPS, la caméra, etc. Ce qui handicape sérieusement l’utilisation de l’application. Par ailleurs, elle ne sera pas disponible dans les magasins App Store ou Google Play.

Une application native est une application développée directement sur l’OS de l’appareil (son système d’exploitation). Aujourd’hui, il existe deux grands acteurs : IOS d’Apple et Android de Google. Une application pour iPhone, par exemple, sera développée avec le langage Objective C. Une application Android sera quant à elle développée en Java. Il existe certaines méthodes pour utiliser d’autres langages, par exemple C# avec Mono, ou Action Script (flash) (nous y reviendrons…).

Quel intérêt ? Disposer de toute la puissance des ces langages et développer des applications utilisant toutes les ressources de l’appareil (Caméra, GPS…). Bref, quasiment aucune limite, sauf celles dictées par le constructeur (IOS par exemple n’est pas aussi permissif qu’Android). L’application sera référencée sur les boutique d’Apple et de Google.

Là aussi , il existe des inconvénients. Le coût de développement est élevé et il n’y a pas de portabilité (une appli écrite en Java sur Android ne pourra pas être déployée sur IOS, il faudra tout refaire). De ce fait, les coûts de maintenance seront aussi élevés. Il faudra, pour chaque évolution ou mise à jour, modifier chacune des versions d’applications par plateforme.

Une application hybride serait alors un mixte des deux… L’idée est simple, mais la réalisation moins aisée ! Je vous conseille la lecture de cet article.

Voici un schéma illustrant les avantages et inconvénients entre le développement d’une application native, d’une Web App ou d’une application hybride :

(Source)

Encore un tableau un peu plus simple pour vous situer.

( Source Vidéo )

A lire aussi:

• Un article de Be-App-News, de mars 2012: article
• Un autre article plus complet de WorkinDay, datant de Janvier 2012 : article
• Pour finir, un dernier article de NrBlog.fr, datant d’avril 2012, avec un arbre de décision : article

(…)

Auteur Yann Vasseur