Hybride vs HTML vs Code natif, que choisir ?

Merci pour le partage...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn4

L’utilisation des smartphones et des tablettes se concrétise, ce n’est plus un secret pour nous les développeurs. Cela dit, certaines questions voient le jour et forcément des choix s’imposent. L’un des premiers étant architectural : dans quel langage allons nous développer notre application ?

 

Faut-il se poser d’autres questions, notamment en ce qui concerne les performances, l’interface et l’expérience à apporter aux utilisateurs finaux ? S’ensuit la nécessité d’accéder aux API, les coûts de développement ainsi que la réutilisation de notre code.

Quelques rappels

> WebApps

Les WebApps mobiles sont des sites mobiles accessibles depuis un navigateur Internet installé dans le téléphone. Elles n’apparaissent pas dans les kiosques d’applications mais ont le mérite d’être utilisables dans tous les OS mobiles.

> Applications hybrides

Ce sont simplement des WebApps intégrées dans une application native pour pouvoir apparaître dans les kiosques et qui peuvent interagir avec le système hôte.

> Applications natives

Les applications natives sont développées dans un langage de programmation plus ou moins spécifique à la plateforme. Objective-C pour iOS, Java pour Android, C++/Silverlight C#/VB.net, etc. pour Windows 8 / Windows Phone 8.

Les questions à se poser

Décider entre développer une application native ou une application « cross-platform » HTML est un choix technique essentiel qui aura des répercussions tout au long du développement du projet.

> Performances

Une application lente peut-être une raison de son abandon par l’utilisateur. A moins qu’elle soit vraiment de première nécessité.

Développer en HTML comprend un risque majeur pour les performances de l’application qui varient en fonction de la connectivité, du navigateur, de sa version et de son moteur de rendu. Sans oublier tous les éléments médias : téléchargement, stockage, … Ces éléments engendrent une perte de performances.

> Évènements OnTouch !

Un point essentiel, bien souvent oublié, c’est que dans une App mobile, il n’est pas question d’utiliser onclick, onmouseover et onmouseout!

Pour gérer des événements équivalents dans les navigateurs mobiles il faut utiliser ontouchstart, ontouchend, ontouchmove. Pour ceux qui ne le savent pas, onclickcorrespond à ontouchstart+ ontouchend. Inutile de vous dire que le temps de réponse est 5 fois supérieur… 500 vs. 110 millièmes de secondes…

> Stockage

Dans le lot des nouveautés de HTML5, le Web Storage permet de stocker des données dans une liste clé/valeur jusqu’à  10 Mo ! Si votre application en a l’utilité, n’hésitez pas à vous en servir pour sauvegarder des données personnelles de l’utilisateur.

Dans une application mobile native, les éditeurs des OS nous ont fort heureusement ouvert les portes pour l’enregistrement de données via les SDK: les classes IOStorage pour iOS, Isolate Storage pour Windows 8 et Windows Phone et les différentes méthodes Android nous permettent d’y accéder et de pérenniser des données.

> Moteur de rendu

Les performances d’une WebApp dépendent du moteur de rendu du navigateur fourni avec l’OS de votre smartphone ou de votre tablette, en l’occurrence Safari pour iOS, Internet Explorer pour Windows Phone et/ou d’outils comme Phone Gap.

> Interface et Expérience Utilisateur

La quasi-totalité des marques affichent leur identité par un jeu de couleurs, de graphismes et autres signatures distinctes pour se démarquer ou ressembler à une autre. L’expérience utilisateur est censée mettre à l’aise l’utilisateur, qui s’est habitué à sa tablette ou à son smartphone et retrouve les mêmes gestuelles dans votre application ainsi que dans les autres applications qu’il s’est procurées.

> Design + WebApp

Si vous décidez de développer une WebApp, vous offrez le même affichage pour toutes les plateformes, à quelques détails près.

Vous n’offrez donc pas l’expérience attendue par l’utilisateur final ni l’interface voulue par la philosophie du système d’exploitation mobile (gestuelles, taille de polices, quantité d’informations, disposition des éléments, …).

> Design + Plateforme dédiée

Dans le cadre d’une application développée avec un langage natif, l’interface respecte dans la plupart des cas les guidelines fournies par les éditeurs des systèmes, Modern UI pour Windows 8, skeuomorphisme pour iOS par exemple.

En suivant les guidelines, vos utilisateurs se retrouveront aisément dans l’application : la navigation sera similaire aux autres applications (y compris celles du système) de même pour les éventuels menus de l’application, les informations seront plus ou moins hiérarchisées ; bref, votre application appréhendera la philosophie de la plateforme !

> L’accès aux dernières fonctionnalités des périphériques et/ou des API

Sur la plupart des plateformes, environ ¾ des fonctionnalités des API sont accessibles par les WebApps : géolocalisation, stockage, réseau, … Pour combler le quart manquant (contacts, géolocalisation complète, moteurs de rendu 3D avancé, …), il existe différentes solutions : injecter du JavaScript, créer une couche pour communiquer entre la WebApp et le navigateur qui exécute celle-ci, utiliser l’existant : Phone Gap et sans doute bien d’autres solutions !

> Coûts de développement

Développement plus rapide et multiplateforme oblige, les WebApps et hybrides remportent haut la main la manche des coûts.

Ayant besoin de passer du temps pour chaque plateforme et parfois ayant besoin de connaissances plus techniques, les développeurs d’applications natives peuvent coûter plus cher, en nombre au moins.

> Réutilisation et pérennité de code

Versionning, commentaires ordonnés, code structuré, les mêmes conseils s’appliquent pour le développement d’applications HTML et natives. Cela dit, en plus des IDE très complets qu’offrent les éditeurs (Visual Studio, Xcode, …), ces derniers fournissent à leurs développeurs des outils plus ou moins poussés et intégrés pour permettre de collaborer sur un projet, de gérer aisément les différentes versions, etc.

> Publication dans les kiosques

Si vous avez une WebApp, uniquement accessible sur Internet, il faudra inviter l’utilisateur à taper son URL directement dans le navigateur ou à vous trouver via son moteur de recherche préféré.

Pour que l’application soit publiée dans les kiosques dédiés aux différentes plateformes, il faut les soumettre en donnant un maximum d’informations et attendre leur éventuelle validation. Les utilisateurs seront alors libres de télécharger votre chef d’œuvre sur leurs petits bijoux.

Conclusion

C’est en fonction des facteurs comme le budget, l’expérience utilisateur, les API nécessaires, etc. que le choix final se fait quant au développement d’une App native ou d’une WebApp.

Sources originales : http://dontcodetired.com/blog/post/The-Architects-Guide-to-Choosing-Between-HTML5-or-Native-Mobile-Apps.aspx

http://www.brianmadden.com/blogs/brianmadden/archive/2012/04/16/how-to-argue-html-vs-nativetouch-vs-keyboard-and-tablet-vs-pc-who-will-win-amp-quot-desktops-versus-tablets-amp-quot.aspx

http://www.localapps.co/mobile-application-development-html-5-vs-native/

http://www.scriptol.com/mobile/native-vs-html5.php

http://dontcodetired.com/blog/post/The-Architects-Guide-to-Choosing-Between-HTML5-or-Native-Mobile-Apps.aspx

Christian Kas

Spécialiste de la réussite et du bien-être.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *