Développement d'une application mobile multiplateforme [fermé]


109

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

Et la création d'applications multiplateformes est un casse-tête pour les développeurs. Je recherche des éléments communs sur les plates-formes qui aideront les développeurs qui souhaitent porter une 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 l'une des plates-formes.

Ou existe-t-il des possibilités, en écrivant du code en html (objet de type widget) et en le chargeant dans l'application native. Je connais l'Android, dans lequel nous pouvons ajouter la vue Web à l'application en appelantsetContentView(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 entre les développeurs. marquage comme wiki communautaire.

Outils et bibliothèque multiplateformes


1
Bien que j'aie trouvé un fil de discussion intéressant lié à celui-ci, stackoverflow.com/questions/3326110/…
sohilv

un autre bon article sur le développement multiplateforme: stackoverflow.com/questions/51988/…
sohilv

1
A voté pour fermer cela comme un double. Ceci est trop important pour être divisé en deux questions. stackoverflow.com/questions/51988/…
ripper234

Réponses:


97

Ma réponse ici couvre certaines des limitations techniques des outils cross-platfrom, mais permettez-moi de développer un peu:

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

Tous les arguments de vente des outils multi-plateformes 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 seule fois n'importe où. Ils sont vendus sur l'idée qu'ils permettent aux développeurs d'élargir 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.

Les outils multi-plateformes ne sont PAS vendus, c'est l'avantage 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 force 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 de savoir 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 que cela ne leur apporte aucune valeur.

À l'inverse, les compromis inévitables liés à la création d'une API multiplateforme signifient que toutes les applications créées par l'API seront au mieux de qualité B sur chaque plateforme. 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 donnent à l'utilisateur final un produit de qualité inférieure par rapport à ceux fabriqués avec des API spécifiques à la plate-forme. L'utilisateur final aura toujours un meilleur choix.

Vous gagnez de l'argent sur le long terme en offrant aux utilisateurs finaux les outils les plus utiles. Si vous ne vous concentrez pas philosophiquement pour rendre la vie de l'utilisateur final plus facile et plus productive, vous êtes pratiquement 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 devriez 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 (des développeurs), alors vous les avez choisis pour la mauvaise raison et ils vous feront plus de mal qu'ils ne vous aideront.


52
Moins de travail (inutile) pour les développeurs signifie des cycles de mise à jour plus rapides, de nouvelles fonctionnalités plus rapides, des corrections de bogues plus rapides, etc. Avec la même main-d'oeuvre, plus peut être réalisé. Je considère cela comme un avantage pour l'utilisateur final.
schoetbi

10
En théorie, un développement plus rapide pourrait être préférable pour l'utilisateur final, mais ce n'est pas le fondement philosophique de la plupart des API multiplateformes. J'ai vu de nombreuses tentatives pour utiliser de tels outils dans de nombreux environnements et l'objectif est toujours de faciliter la vie du développeur au détriment de la qualité du produit final. De plus, la promesse d'une solution plus rapide et moins chère se réalise rarement. Il semble toujours y avoir un accroc de spectacle quelque part qui mange la plupart du temps économisé.
TechZen

5
Pour faire valoir mon point de vue, considérez ceci: les API multiplateformes existent pour de nombreuses classes différentes de matériel et de système d'exploitation. Combien d'applications multiplateformes utilisez-vous personnellement régulièrement? Combien d'applications multiplateformes avez-vous déjà utilisées et auxquelles vous avez bien pensé? Les gens ont poussé des API multiplateformes depuis qu'il y avait plus d'une plate-forme, mais ils n'ont jamais vraiment réussi nulle part. Ils ne réussissent pas car ils ne produisent pas les applications les plus utiles pour les utilisateurs finaux.
TechZen

4
@TechZen - J'utilise StackOverflow maintenant sur mon navigateur Web et je ne vois aucune raison de rechercher un client natif. Je pense que vous généralisez trop vos affirmations.
Youval Bronicki

4
Je suis assez contrarié que ce genre de débat philosophique subjectif obtienne la bonne note sur un site Web technique. Pire encore, la thèse de cet article est invalide pour la plupart des principaux logiciels que nous utilisons aujourd'hui: les navigateurs Web sont multiplateformes; Photoshop, MS Office, Dropbox et les trucs sont multiplateformes; ouvrez simplement votre menu Démarrer ou Finder et listez les types spécifiques à la plate-forme - il y a de fortes chances pour que vous trouviez de petits utilitaires. Votre argument serait valable si vous croyez que les téléphones mobiles sont radicalement différents (une hypothèse très valable), mais il ne semble y avoir aucun argument pour construire cette base.
kizzx2 du

14

Il existe plusieurs approches du 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éutiliser le code

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

Le C ++ par exemple peut probablement être réutilisé pour une application iOS , pour une application Android en utilisant le NDK , pour une application Symbian puisqu'ils sont développés 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)
  • Les projets de type mono AFAIK n'existent pas (encore?) Pour toutes les plateformes 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. C'est ainsi que certains des cadres multiplateformes que nous verrons plus loin travailleront.

L'essor du 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 and feel natif en tirant parti des derniers standards web HTML5, CSS3, Js:

Mais HTML5 est encore très jeune et la mise en œuvre peut varier d'un navigateur à l'autre. La plupart des navigateurs mobiles par défaut utilisent le moteur WebKit (l'exception principale étant Windows mobile / téléphone utilisant Internet Explorer) et même s'ils ne prennent pas nécessairement en charge les mêmes fonctionnalités . La base de données locale est toujours difficile à utiliser et nous ne pouvons pas être sûrs de la manière 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 quelques 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 reposent sur le moteur WebKit. Ils offrent plus d'interaction avec les fonctionnalités du téléphone tout en développant avec les technologies Web. Les plus connus sont Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. Mais beaucoup d'autres sont disponibles 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 qu'Apple a une politique spéciale concernant les applications écrites pour leur plate-forme. Ils ne semblent pas bloquer ces applications à cette date mais c'est une information qui doit être prise en compte. Edit: Apple a changé cette politique depuis le 9 septembre.


6

Vous obtenez des points communs 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 frameworks de smartphones «multi-plateformes» tels que Phonegap, mais j'ai surtout entendu de mauvaises choses sur son utilisation pour un travail «réel». (beaucoup de frais généraux, etc.)


5

Oui, html5 retient l'attention. Vous devriez également regarder ce consortium et cette plate-forme à venir au quatrième trimestre. Je ne suis 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=fr&q=%22Wholesale+Applications+Community%22

WAC a pour objectif de 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 W3C et créera une plate-forme solide pour le développement d'applications Web mobiles riches. WAC fournira également une rétrocompatibilité pour les appareils sur la base des spécifications JIL et BONDI actuelles. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

C'est une coalition internationale d'environ 25 entreprises de télécommunications qui vise à créer une plate-forme ouverte à tous les développeurs et vendue à 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/ )


1

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

Java ME - la plate-forme d'application la plus omniprésente pour les appareils mobiles

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


En fait, il n'y a pas de java sur l'iPhone, et pour autant que je sache, java me ne fonctionne pas sur Android
Alaa Nassef

Le développement Android est massivement Java. developer.android.com/reference/java/net/package-summary.html
Nick Garvey

Je ne connais pas les détails, mais Avian JVM permet à java de fonctionner sur les appareils iOS.
Quazi Irfan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.