Quels sont les avantages et les inconvénients des approches d'applications mobiles HTML5, natives et hybrides?

Je souhaite développer une application mobile. J'ai récemment lu un article sur Telerik Forum , qui se compare entre trois types d'applications mobiles et je ne sais pas lequel dois-je sélectionner pour commencer. Voici une image décrivant les avantages et les inconvénients des différents choix de conception mobile

Pour décider entre ces choix de conception, j'aimerais mieux comprendre les avantages et les inconvénients de chaque choix d'architecture répertorié dans le diagramme. Quels sont les avantages et les inconvénients de chaque approche architecturale?

Je suis un développeur mobile qui a passé beaucoup de temps à réfléchir à ce problème.

Pourquoi demandez-vous?

Vous espérez probablement réduire les coûts de développement d'applications en:

• Utilisation des compétences de développement HTML5 / Javascript existantes
• Cibler plusieurs plates-formes sans écrire plusieurs applications à partir de zéro
• Ne pas avoir à maintenir plusieurs bases de code à l'avenir

Les raisons peuvent également inclure:

• Développement HTML5 / Javascript perçu comme "plus facile" que le développement de plateforme native
• Éviter le paiement des frais d'inscription au programme développeur
• Éviter les restrictions de contenu de l'Appstore (jeux d'argent, etc.)
• Éviter l'achat de matériel de développement (par exemple, développement Mac pour iPhone)

Définitions

Établissons exactement ce que nous entendons par chacune des trois approches mentionnées:

Native
Une application installée sur un appareil, généralement à partir de sa boutique d'applications (bien qu'elle puisse parfois être téléchargée). Pour les besoins de cette discussion, l'interface utilisateur d'une application native ne se compose généralement pas uniquement d'une vue Web en plein écran.

Web mobile
Il peut en fait s'agir de n'importe quelle page Web, mais pour cette discussion, considérons une application Web d'une seule page qui tente d'imiter l'apparence d'une application native. Ce n'est pas une application native, elle s'exécute dans le navigateur de l'appareil.

Hybrid
Hybrid app application instanceofnative.

La plupart des gens comprennent probablement qu'une application hybride est une application Web mobile d'une seule page (encore une fois imitant très probablement l'apparence d'une application native), mais conditionnée comme une application native avec accès aux services natifs (à la Phonegap).

Cependant, il existe en fait un spectre entre le modèle Phonegap et entièrement natif sur lequel je reviendrai plus tard.

Web mobile

Restrictions techniques
Commençons par énumérer certaines restrictions techniques sur les applications Web mobiles qui pourraient en elles-mêmes être un facteur de rupture en fonction de ce que vous faites:

• Interface utilisateur HTML / toile uniquement
• Pas d'accès à certains événements et services de l'appareil (ceux-ci sont largement documentés)
• Ne peut pas être répertorié dans les magasins d'applications (affectant la découvrabilité)
• Peut devenir plein écran et avoir une icône d'écran d'accueil sur iOS, mais c'est une expérience inhabituelle et inconnue pour la plupart des utilisateurs

Si vous pouvez vivre avec tout ce qui précède, lisez la suite pour en savoir plus sur les défis des applications Web de style natif à une seule page. Cependant, cette section ne serait pas complète sans référence à l'application FT.

Financial Times
L' application Web FT est un exemple célèbre de ce style d'application. Voici une fonctionnalité intéressante du journal UK Guardian à ce sujet.

C'est certainement un exploit d'ingénierie remarquable. Notez qu'il n'est actuellement disponible que sur iOS uniquement - cela me dit qu'ils trouvent en effet qu'il est très difficile de résoudre les défis du développement multi-navigateur avancé.

Applications Web de style natif sur une seule page

Cette section s'applique aux applications Web mobiles et de style Phonegap.

L'aspect et la convivialité de style natif dans une application Web sont généralement obtenus avec un cadre tel que Sencha Touch qui fournit une suite de composants d'interface utilisateur que vous pouvez utiliser.

De tels cadres conviennent parfaitement aux interfaces utilisateur très simples. Cependant, ils manquent de flexibilité. Vous ne pourrez pas implémenter de conception d'application native à l'aide de Sencha, vous devrez adapter votre conception à ce que le cadre peut accueillir.

La principale façon dont ces cadres souffrent est d'essayer d'imiter les subtilités de l'interface utilisateur de la plate-forme. Ce joli petit effet de rebond que vous obtenez lorsque vous faites défiler jusqu'à la fin d'une liste sur l'iPhone? Votre framework doit émuler cela en Javascript. Il est impossible de le recréer complètement, il sera susceptible de ralentir, et vos utilisateurs seront coincés dans la "vallée étrange" d'une application qui ressemble un peu à native, mais qui ne l'est clairement pas, et non technique l'utilisateur ne pourra pas mettre le doigt sur pourquoi exactement.

Le mythe "HTML5 / Javascript is easy"

La fragmentation des appareils dans les navigateurs Web est monnaie courante, et lorsque vous allez au-delà du HTML et du CSS les plus basiques, vous remarquerez que les choses ne fonctionnent pas tout à fait comme prévu. Vous pourriez vous retrouver à consacrer plus de temps à résoudre des problèmes d'interface utilisateur que vous n'en auriez économisé deux fois en mode natif. Si vous devenez natif, notez que les vues Web d'applications natives ne sont pas les mêmes que les navigateurs d'appareils et ont leurs propres problèmes de fragmentation.

Et comme votre application devient plus complexe sur le plan fonctionnel, vous constaterez que vous avez besoin de plus que des compétences de base en jquery pour garder votre Javascript propre et maintenable.

Cela dit, il est parfaitement possible de créer des applications simples et fonctionnelles assez rapidement avec cette approche. Mais c'est assez évident quand une application le fait.

Plus loin dans le spectre

Nous voulons donc une meilleure expérience utilisateur que les applications de style Phonegap peuvent offrir, sans écrire absolument tout à partir de zéro plusieurs fois. Que pouvons-nous faire?

Partager le code non UI

Il existe une gamme de techniques disponibles pour partager la logique métier sur plusieurs plates-formes natives. Google a lancé J2ObjC qui traduit Java en Objective-C. Avec une factorisation minutieuse du code, une bibliothèque Java pourrait être utilisée à la fois sur Android et iOS.

Des bibliothèques telles que Calatrava et Kirin permettent de manipuler des bases de code écrites en Javascript (et donc tout ce qui peut être compilé en Javascript) à partir du code natif. Avertissement: je travaille pour Future Platforms qui a créé Kirin; nous avons eu beaucoup de succès en l'utilisant sur iOS avec Javascript généré à partir de Java avec GWT, le code Java étant également exécuté nativement sur Android.

Utilisez des vues Web ... le cas échéant

Les vues Web en plein écran ont beaucoup de travail à faire pour pouvoir imiter les transitions d'écran et les effets de rebond. Mais une vue Web à l'intérieur de Chrome de l'application native peut être distinguée de native.

Il existe des méthodes standard et bien documentées pour les applications natives et les vues Web pour communiquer.

Les listes et les tableaux peuvent fonctionner particulièrement bien lorsqu'ils sont effectués de cette manière, mais la saisie de texte est un exemple de quelque chose de mieux géré en natif (pour un contrôle total sur le clavier).

En résumé

L'approche qui vous convient dépend de la complexité de votre application et du niveau de perfectionnement de l'interface utilisateur dont vous serez satisfait.

Ma devise: utilisez des vues Web partout où vous le pouvez, mais assurez-vous que vos utilisateurs ne peuvent pas le dire .

Vérifiez d'abord cette enquête pour savoir ce qui se passe!

comparaison entre les trois types: Comprendre vos options de développement d'applications mobiles

Comparaisons entre natif et hypride:

HTML5 vs natif

HTML5 vs application native: lequel choisir ??

Celui-ci est vraiment bon: applications natives HTML5 v: considérations clés pour votre stratégie mobile

Commentaires:

• Vous pouvez opter pour l'un d'entre eux dépend de ce que vous avez (compétences) et de ce que vous pouvez obtenir (apparence, performance, fonctionnalité, ...)
• Chaque développeur d'applications mobiles doit avoir une vision / des exigences claires concernant l'application qu'il est sur le point de développer pour les premières versions et les futures! juste pour s'assurer que l'option qu'il utiliserait ne le limiterait pas à un moment donné.
• Il n'y a rien de tel que d'avoir une véritable expérience des trois façons et d'être à jour en même temps, cela vous donnera le sens et la capacité de prendre la bonne décision.

Si vous avez besoin d'accéder au matériel du téléphone, vous devez créer une application native (en HTML5, vous pouvez accéder à certains composants matériels de l'appareil tels que le GPS).

Si vous êtes plus à l'aise avec le développement Web, vous devez vous en tenir à moins que vous n'ayez besoin de créer une application native.

Pour ce que vous devez savoir, je dirais que vous devez garder à l'esprit toutes les différentes tailles d'écran (y compris l'orientation verticale et horizontale). Vous devez garder à l'esprit les différentes versions du système d'exploitation (c'est plus pour Android). Comme ce sont des appareils mobiles, il est possible que l'utilisateur réponde à un appel téléphonique, c'est un téléphone et qu'ils n'ont pas la puissance de calcul d'un ordinateur de bureau ou d'un serveur.

Pour moi, lors de l'écriture d'une application grand public, ce qui est essentiel à son succès est l'acceptation et la perception de l'application par l'utilisateur. En raison de cela, quatre raisons de pencher en faveur des applications natives, malgré les coûts supplémentaires associés à l'apprentissage, à la formation et à la perte de WORA (écrire une fois exécuté n'importe où) sont:

1. Démarrage plus rapide de l'application
2. Défilement plus fluide
3. Interface utilisateur plus cohérente qui se connecte de manière plus cohérente avec le reste du système d'exploitation et des applications
4. Réponse plus rapide à l'interface utilisateur de l'application

Ce que vous voulez avant tout, c'est une excellente expérience utilisateur qui aide votre application à réussir sur un marché à couper le souffle. Bien sûr, il existe des exceptions, notamment le manque de compétences, le manque de temps et de budget. Parfois, les applications sont destinées à un ensemble limité d'utilisateurs professionnels qui ne se soucient peut-être pas beaucoup de ces choses.

C'est pour des raisons similaires à celles-ci que Facebook a abandonné sa stratégie d'applications au profit d'applications natives pour IOS et Android:

Lisez s'il vous plaît:

Mark Zuckerberg: Notre plus grosse erreur pariait trop sur HTML5 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Pourquoi Facebook a abandonné le Web mobile et est devenu natif avec sa nouvelle application iOS http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

J'espère que cela t'aides.

Avec ce qui suit, ma position actuelle sur cette débâcle est que l'hybride est bon pour commencer, pour explorer votre application, répéter rapidement les commentaires des clients et stabiliser l'ensemble des fonctionnalités. Ensuite, pour réécrire l'application en natif selon les spécifications, pour améliorer l'expérience.

J'ai omis Mobile Web, car il sert un objectif complètement différent. Si vous voulez être dans les app stores, Native / Hybrid est le chemin à parcourir. Si vous souhaitez simplifier le déploiement et que vous êtes prêt à sacrifier l'expérience et les capacités techniques, optez pour le Web mobile.

Pour / Contre natif :

• Pro: il correspond au reste de l'expérience de l'appareil, pas de problèmes étranges de vallée .
• Pro: Il fournit principalement une expérience d'interface utilisateur cohérente et fluide, pas de retards, pas de bégaiements.
• Pro: Peu de limitations techniques, vous pouvez utiliser pleinement l'appareil.
• Pro: les outils natifs assurent la conformité avec la validation des magasins d'applications.
• Pro: les frameworks natifs incluent des ajustements par version de plate-forme, moins de temps consacré au réglage fin.
• Con: c'est construire pour durer, et prend donc plus de temps à construire.
• Inconvénient: nécessite des développeurs polyglottes difficiles à trouver, coûteux.
• Con: besoin de familiariser chaque API de plate-forme d'appareil (iOS / Android / etc).
• Inconvénient: courbe d'apprentissage abrupte.
• Inconvénients: jeu d'outils différent par plate-forme.

Pour / contre hybride :

• Pro: base de code unique pour cibler plusieurs plates-formes d'appareils.
• Pro: cycles de développement rapides, grande flexibilité de mise en page, parfait pour le prototypage et les MVP .
• Pro: courbe d'apprentissage confortable, beaucoup de documentation, des cadres pour vous aider.
• Pro: jeu d'outils de développement unique. Les outils de débogage de Chrome sont excellents.
• Pro: une base de code pour cibler plusieurs plates-formes d'appareils.
• Pro: Beaucoup de développeurs disponibles, faciles à apprendre.
• Con: Nécessite un cadre d'interface utilisateur décent pour adapter l'interface utilisateur pour chaque plate-forme différente afin d'être cohérent avec l'expérience de l'appareil. Il existe des solutions comme Kendo UI , Sencha Touch .
• Con: besoin d'être très conscient de la mémoire et de l'utilisation des calculs, certaines boucles CSS et javascript peuvent sérieusement ralentir l'application. Pas de très bons outils disponibles sur l'appareil pour déboguer.
• Inconvénient: pas encore mûri, les choses peuvent soudainement changer, les outils s'améliorent cependant.

Étant moi-même développeur mobile, le pire est l'accès hors ligne. Vous forcez simplement les utilisateurs à être en ligne, ce qui devrait fonctionner dans de nombreuses applications, mais pas dans toutes.

L'autre grand mauvais aspect est la lenteur. Le temps nécessaire pour analyser les données distantes peut prendre un temps considérable. Oui, vous pouvez pré-récupérer des données pendant le temps de chargement, mais dans tous les autres cas, vous ne pouvez pas éviter la lenteur.

J'ai trouvé qu'une telle application mettait fin à une application plus chère que les applications natives. Je ne les recommande plus à aucun de mes clients.

Le gros problème avec les applications hybrides est la fragmentation des frameworks: il y en a clairement beaucoup plus (Ionic, Xamarin, React Native, etc.) que de plateformes mobiles natives d'intérêt (généralement deux, Android et iOS). Ces frameworks rivalisent, émergent, déclinent, donc l'hybridation ne vous évitera pas de sauter de plateforme en plateforme même si vous prévoyez de garder votre équipe actuelle pour la vie.

Google et Apple font de leur mieux pour fournir et soutenir des éditeurs, des débogueurs, des cadres de test, des outils de refactorisation et d'autres moyens de développement pour leurs plates-formes. Par conséquent, je prendrais une formulation typique " il est juste beaucoup plus facile de développer une application hybride, de la modifier avec votre éditeur préféré et de l'ouvrir dans un navigateur " avec la réserve raisonnable. Xamarin et React Native sont des plates-formes de développement, tout comme Swift ou Java / Android, et même si "bonjour le monde" peut sembler plus court, il faudrait éventuellement prendre le temps comparable pour apprendre correctement.

Si, dans tous les cas, un besoin de composants natifs venait à surgir (par exemple, la bibliothèque tierce existante doit être intégrée), vous vous retrouverez avec trois cadres plutôt que deux: iOS, Android et votre cadre hybride en haut, pour finir avec une architecture plus complexe. Le débogage de telles applications, l'intervalle entre les appels inter-couches, la journalisation de toutes les couches, la synchronisation du code est complexe voire impossible.

Certains disent que "l' application sera exactement la même pour toutes les plateformes ". Est-ce vraiment une bonne chose? L'application Android doit ressembler à l'application Android et l'application iOS doit ressembler à l'application iOS.

Et les nouvelles fonctionnalités? Wearables? Des applications instantanées désormais offertes par la plateforme Android? Affichage de données supplémentaires sur un écran externe? Les applications hybrides prennent désormais en charge de nombreuses fonctionnalités natives, mais les prennent-elles vraiment toutes en charge ? À tout moment, immédiatement?

Enfin, non seulement les performances et l'expérience utilisateur, mais aussi la sécurité peuvent être davantage du côté de l'application native. Le framework hybride ajoute la couche d'indirection qui peut avoir ses propres bugs, y compris les bugs de sécurité.

Pour conclure tout ce qui précède, sous la possibilité de choisir, je choisirais certainement les deux applications natives, une pour iOS et une pour Android, ou bien je concevoirais simplement une version mobile du site Web sans se soucier du développement d'applications pour n'importe quelle plate-forme. .