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
XMLVM, Codename One et iSpectrum (compilation croisée de code Java à partir d'une application Android ou création d'une application à partir de zéro
Phone Gap (applications mobiles multiplateformes)
Titanium (pour créer des applications mobiles et de bureau natives avec des technologies Web)
Mono Touch (C # pour iphone)
rhomobile - http://rhomobile.com/ les exemples sont ici: http://github.com/rhomobile/rhodes-system-api-samples
Sencha Touch - Sencha Touch est un cadre d'application mobile HTML5 qui vous permet de développer des applications Web qui semblent natives sur les appareils à écran tactile Apple iOS et Google Android. http://www.sencha.com/products/touch/
Corona - Bibliothèque multiplateforme d'applications Iphone / Ipad / Android. Trop génial. http://anscamobile.com/corona/
Un guide pour porter une application Android existante sur Windows Phone 7 http://windowsphone.interoperabilitybridges.com/articles/windows-phone-7-guide-for-iphone-application-developers
- Framework Web Jquery Mobile Touch-Optimized pour smartphones et tablettes
Réponses:
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.
la source
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:
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.la source
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.)
la source
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
.
la source
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.
la source