John,
Eh bien, il semble que vous avez un peu de travail qui vous attend! Lorsque vous disposez d'une application Web existante, il existe deux approches de base pour la rendre disponible sur un périphérique particulier: vous pouvez (1) écrire une application native qui implémente la fonctionnalité souhaitée pour chaque périphérique que vous souhaitez prendre en charge ou vous pouvez (2) écrire un "wrapper" basé sur le Web pour votre application existante et servir le contenu en HTML/CSS à ces mêmes appareils.
Option 1: Construire une application native pour chaque plate-forme que vous voulez soutenir
En ce qui concerne la première approche, les avantages peuvent être énormes. En utilisant les frameworks natifs de chaque périphérique, vous avez la possibilité et la flexibilité de tirer parti des meilleures fonctionnalités de chaque périphérique. Les vues de votre application peuvent également s'afficher plus rapidement, car tout ce que vous récupérerez sur votre serveur, ce sont les données à remplir avec les vues (c'est-à-dire que vous n'avez pas besoin de charger d'images, de modèles HTML ou de fichiers CSS). L'inconvénient de cette approche est qu'elle nécessite intrinsèquement que chaque périphérique ait sa propre application. Ainsi, si vous prenez en charge une application Web, une application iPhone, une application Android et une application Blackberry, cela signifie que vous disposez de 4 bases de code complètement distinctes à gérer.Si vous ajoutez une sorte de nouvelle fonctionnalité à votre application Web (ce que vous allez vraisemblablement faire à un moment donné), vous devrez également implémenter cette nouvelle fonctionnalité dans les trois autres bases de code distinctes. Étant donné que ces appareils peuvent avoir différents modèles d'interaction, cela pourrait poser un problème. Un autre inconvénient ici peut être la distribution (c'est-à-dire, vous devrez peut-être passer par un processus de révision pour quelque chose comme l'app store iPhone en fonction de la façon dont vous voulez distribuer votre application). Cela signifie également que le montant que vous devrez apprendre est un peu plus élevé puisque chaque appareil possède son propre ensemble d'API et sa «philosophie» de programmation.
Option 2: Ecrire un "wrapper" sur le Web pour votre application (en utilisant peut-être une bibliothèque)
Cette approche a aussi beaucoup d'avantages. Tout d'abord, si vous utilisez un framework comme PhoneGap ou Sencha Touch ou Rhomobile, le gros avantage est que vous écrivez théoriquement le code "application mobile" une fois et cela fonctionne sur chacun des périphériques pris en charge par le framework. Par rapport à l'écriture d'une application native pour trois plates-formes, cela représente beaucoup moins de travail.
Les inconvénients sont les suivants. Cette approche fonctionne comme un site Web dans le navigateur de l'appareil, de sorte que vous n'aurez pas accès à toutes les fonctionnalités de chaque appareil. Toutes les bonnes choses dans les API iOS et Android ne seront par définition pas disponibles pour vous. Vous êtes également un peu limité ici en ce qui concerne le stockage local, mais cela ne vous inquiète peut-être pas, compte tenu de votre application Web. Un autre inconvénient est qu'il y aura plus de bande passante requise de la part de votre serveur, puisque vous diffusez tout le code HTML, les images et les CSS que vous n'auriez pas dû utiliser avec une application native. Selon le nombre d'utilisateurs et la complexité des pages, cela pourrait être important pour vous ou non. Un autre inconvénient ici est que vous ne pouvez pas aller en plein écran (avec l'iPhone dans Mobile Safari par exemple, il y a toujours une barre d'outils en bas).
préoccupations générales
Une chose qui me concernait la lecture de votre question était votre liste d'exigences. Reproduire des fonctionnalités et vous connecter à un magasin de données distant sont des choses que vous pouvez certainement faire avec des applications mobiles natives et basées sur le Web. Mais "retenir [drag] drag drop capacités" ne l'est pas. Avec un iPhone, par exemple, vous pouvez utiliser des poignées dans un UITableViewCell pour fournir un moyen de réorganiser les listes, mais le glisser-déposer intégral n'est pas vraiment adapté au modèle d'interaction utilisateur d'un périphérique mobile. Vous devrez peut-être repenser celui-ci.
L'exigence de «fournir une expérience utilisateur riche équivalente ou meilleure que l'application Web» est également un peu troublant. Alors que les applications basées sur le téléphone peuvent avoir des moyens vraiment simplifiés pour obtenir et manipuler les données, n'oubliez pas que vous concevez pour un écran de quelques centimètres carrés. Il est physiquement impossible de fournir la même quantité d'informations d'une manière organisée que vous pouvez avec un écran large HD 21 "
Rappelez-vous que vous êtes en train de concevoir ici pour mobile, donc vous voulez profiter des plates-formes disponibles mais rappelez-vous que vous avez affaire à de petits écrans et à des méthodes d'interaction limitées (touches, glissements et gestes)
Ma recommandation est que si c'est la première fois que vous faites cela, vous voulez supporter tous ces dispositifs , et vous avez déjà de l'expérience avec le Web, je vous suggère de choisir l'option 2 et d'utiliser l'un des cadres mentionnés ci-dessus, ce serait la façon la plus facile de commencer et il n'y aurait pas de concepts radicalement différents pour vous. doit apprendre.
Bonne chance!