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 instanceof
native.
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 .