web-dev-qa-db-fra.com

Développement d'une application mobile multiplateforme

De plus en plus de plates-formes mobiles sont lancées et des sdk sont disponibles pour les développeurs. Différentes plateformes mobiles sont disponibles: Android, iOS, Moblin, Windows mobile 7, RIM, symbian, bada, maemo etc.

Et créer une application multiplateforme est un casse-tête pour les développeurs. Je recherche des choses communes sur les plates-formes qui aideront les développeurs qui souhaitent porter l'application sur toutes les plates-formes. Comme quelles sont les résolutions d'écran diff, les méthodes de saisie, le support open gl, etc. veuillez partager les détails que vous connaissez pour n'importe quelle plate-forme.

Ou existe-t-il des possibilités, en écrivant du code en html (type de widget) et en le chargeant dans l'application native. Je connais Android, dans lequel nous pouvons ajouter la vue Web dans l'application en appelant setContentView(view)

Veuillez partager les détails de la classe où nous pouvons ajouter la vue html dans l'application native de différents types de plates-formes que vous connaissez.

Le but de ce fil est de partager des détails communs aux développeurs. marquage comme wiki communautaire.

Outils et bibliothèque multiplateforme

androidwindows-phone-7blackberryios4cross-platform
108
sohilv

Ma réponse ici couvre certaines des limitations techniques des outils multi-plates-formes mais permettez-moi de développer un peu:

Je pense que les outils multiplateformes ont toujours été aussi des rans parce que ces outils ont une mauvaise orientation philosophique.

Tous les arguments de vente pour les outils multiplateformes sont les avantages qu'ils apportent aux développeurs. Ils sont vendus sur l'idée qu'ils permettent aux développeurs d'écrire une fois une fois n'importe où. Ils sont vendus sur l'idée qu'ils permettent aux développeurs d'étendre leur marché sans apprendre de nouvelles API. Ils sont vendus sur l'idée qu'ils permettent aux développeurs de réduire les coûts et les délais de commercialisation.

Quels sont les outils de plateforme croisée [~ # ~] et non [~ # ~] vendus les avantages qu'ils apportent aux utilisateurs finaux.

L'avantage pour l'utilisateur final n'est pas un argument de vente, car le développement multiplateforme est rarement un avantage pour l'utilisateur final. L'utilisateur final ne se soucie pas de la difficulté avec laquelle le développeur a dû travailler pour mettre le produit sur le marché. Ils ne se soucient pas non plus du nombre de plates-formes sur lesquelles l'application peut fonctionner lorsqu'ils n'utilisent qu'une seule plate-forme. Ils se soucient simplement si l'application fait ce dont ils ont besoin sur le matériel dont ils ont besoin pour l'exécuter. À moins qu'ils n'aient un besoin spécifique d'exécuter l'application sur de nombreuses plates-formes différentes, le fait qu'elle ne leur apporte aucune valeur.

Inversement, les compromis inévitables de la création d'une API multiplateforme signifient que toutes les applications créées par l'API seront au mieux de classe B sur chaque plate-forme. Ils ne seront jamais le meilleur outil à utiliser sur chaque plateforme.

Tout cela signifie que dans la plupart des cas d'utilisation, les outils multiplateformes offrent à l'utilisateur final un produit inférieur à ceux fabriqués avec des API spécifiques à la plate-forme. L'utilisateur final aura toujours un meilleur choix.

Vous gagnez de l'argent à long terme en donnant aux utilisateurs finaux les outils les plus utiles. Si vous ne vous concentrez pas philosophiquement à rendre la vie de l'utilisateur final plus facile et plus productive, vous êtes à peu près condamné dès le départ. Les utilisateurs finaux ont beaucoup de choix et si votre outil n'est pas l'un des meilleurs, vous ne le ferez pas sur le marché.

Vous ne devez utiliser des outils multiplateformes que si vous pensez que "les utilisateurs bénéficieront vraiment de l'exécution de cette application sur de nombreuses plates-formes différentes". Si vous commencez à regarder des outils multiplateformes uniquement parce qu'ils vous faciliteront la vie (aux développeurs), alors vous les avez choisis pour la mauvaise raison et ils vous blesseront plus qu'ils ne vous aideront.

95
TechZen

Il existe plusieurs approches pour le développement multiplateforme sur les appareils mobiles. Bien sûr, ils ont tous des limites. Aucune solution ne parvient à tirer parti de toutes les fonctionnalités de l'appareil comme le peut une application native.

Réutilisation du code

Bien que tous les systèmes d'exploitation mobiles n'utilisent pas le même langage de développement et la même API, vous pouvez parfois partager certaines classes ou du code de niveau logique.

Le C++ par exemple peut probablement être réutilisé pour une application iOS , pour une application Android en utilisant l'application NDK , pour une application Symbian puisqu'elles sont développées en C++, etc.

Certaines solutions offrent également la possibilité d'écrire l'application dans une autre langue que celle normalement utilisée par l'appareil. Les plus connus (en fait le seul que je connaisse) sont commerciaux et basés sur le projet Mono (développement C #):

Mais je ne suis pas sûr que nous puissions vraiment appeler ce développement multiplateforme car la réutilisation du code est limitée en fonction de l'appareil:

  • Windows Phone 7 ne permettra pas le développement de code natif (peut-être dans d'autres mises à jour)
  • Le projet AFAIK mono like n'existe pas pour toutes les plateformes (encore?) Bada, webOS, maemo, etc.

Et la partie UI reste également spécifique à chaque appareil.

Développement Web

Une réponse régulière lorsque l'on pose des questions sur le développement multiplateforme pour mobiles est le développement Web. Nous aurions alors besoin d'un wrapper, qui utilisera le navigateur mobile, pour le faire ressembler et se comporter comme une application native. Voilà comment une partie du cadre multiplateforme que nous verrons plus loin sur le travail.

L'essor de HTML5 apporte au développement Web des fonctionnalités qui ne pouvaient être réalisées qu'avec une application native comme la géolocalisation, l'application hors ligne, le stockage local.

Nous pouvons trouver de plus en plus de frameworks pour développer des applications web pour mobiles avec un look et une sensation native en profitant des dernières normes web HTML5, CSS3, Js:

Mais HTML5 est encore très jeune et l'implémentation peut varier d'un navigateur à l'autre. La plupart des navigateurs mobiles par défaut utilisent le moteur WebKit (la principale exception étant Windows mobile/téléphone utilisant Internet Explorer) et même ainsi, ils ne sont pas nécessairement prennent en charge les mêmes fonctionnalités . La base de données locale est toujours difficile à travailler et nous ne pouvons pas être sûrs de la façon dont elle sera mise en œuvre par les différents navigateurs. De plus, même avec HTML5, le développement Web est encore très limité par rapport à une application native. Vous ne pouvez pas accéder aux contacts, à la caméra, à l'accéléromètre, etc.

Edit: Plus tôt ce mois-ci, le W3C a émis des avertissements sur l'évolution de HTML5: Article de ZDNet

Il ne conviendra donc qu'à une catégorie limitée d'applications.

Cadres multiplateformes

Et que nous avons les cadres d'applications mobiles multiplateformes. Avec lequel vous pouvez probablement développer une fois et déployer sur différentes plates-formes. Ces solutions se concentrent généralement sur iOS et Android et s'appuient sur le moteur WebKit. Elles offrent plus d'interaction avec les fonctionnalités du téléphone tout en développant avec les technologies Web. Les plus connues sont Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium, mais beaucoup d'autres existent et n'utilisent pas tous la même technique que MoSync qui traduit votre code dans son propre langage intermédiaire avant de le compiler pour la plate-forme souhaitée.

[ 1 ] N'oubliez pas que Apple a une politique spéciale sur les applications écrites pour leur plate-forme. Il ne semble pas qu'elles bloquent ces applications à cette date mais c'est une information qui devrait être pris en compte. Modifier: Apple a changé cette politique depuis le 9 septembre.

14
Jla

Vous obtenez une certaine similitude lors du déploiement en tant qu'application Web (html5 comme mentionné ci-dessus), mais pour les applications natives riches, les API sont complètement différentes pour les différents smartphones.

HTML5 peut améliorer quelque peu les choses, mais pour faire des choses intéressantes, vous devez devenir natif.

Il existe des cadres de smartphones "multiplateforme" tels que Phonegap, mais j'ai surtout entendu de mauvaises choses à propos de son utilisation pour un "vrai" travail. (beaucoup de frais généraux, etc.)

6
seand

Oui, html5 retient l'attention. Vous devriez également regarder ce consortium et cette plateforme à venir au quatrième trimestre. Pas sûr du succès de ce projet, car cela semble être un énorme défi, mais voici les détails:

Site Web: http://www.wholesaleappcommunity.com/default.aspx

Actualités: http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22

WAC vise à publier sa spécification initiale et les composants de son SDK aux développeurs en novembre. Cette spécification sera basée sur les normes du W3C et créera une plate-forme solide pour développer des applications Web mobiles riches. WAC fournira également une compatibilité descendante pour les appareils en fonction des spécifications JIL et BONDI actuelles. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

Il IS une coalition internationale d'environ 25 entreprises de télécommunications qui vise à créer une plate-forme ouverte à tous les développeurs et à vendre à tous les utilisateurs de téléphones mobiles. ( http: //www.downloadsquad. com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app / )

5
Mathias Conradt

Pour autant que je sache, la plupart de ces appareils sont capables d'exécuter ceci:

Java ME - la plate-forme d'application la plus ubiquitaire pour les appareils mobiles

Je pense que cela peut servir à la fois de bon et de mauvais exemple.

1
Fozi