Aller au contenu | Aller au menu | Aller à la recherche


Développer des Apps pour Android, iPhone, Windows Phone

Par PlaceOweb le mardi, mars 5 2013, 01:20 - Système - Lien permanent

2013, mondialisme ? que nenni ! Si tout le monde parlais la même langue, cela serait peut être plus simple. Et c'est la même chose pour les langages de programmation à destination des différents systèmes d'exploitation mobiles.

Liste des OS principaux

Questions majeures

Comment développer, avec quel langage(s) ? depuis quel OS ? vers quel(s) OS mobile (multiplateforme) ?

  • les IHM (widgets, ...)
  • les bases de données (sqlite, ...)
  • les fichiers (.txt, .jpg, ...)
  • les accès réseaux (http, ...)
  • les services web
  • xml, xslt, json, ...
  • les accès aux ressources matérielles (gps, photo, ...)
  • les accès aux services locaux (téléphone, calendrier, sms, système de fichiers, ...)
  • les services lancés au démarrage
  • exécution en tâche de fond (synchronisation, notification, ...)
  • les mises à jour (automatiques) de l'application
  • comment distribuer/publier/déployer/installer sur les mobiles ?

Cross plateformes ou développement spécifique pour chacune des plateformes ?

Cross plateformes

PhoneGap / Appcelerator Titanium / Xamarin / Tabris

Tabris
PhoneGap, jQuery Mobile et Dreamweaver, un trio de choc (février 2013)

Le terme « solution mobile » a trois sens :

  • Site pour une version mobile. Cette version mobile sera accessible par le navigateur du smartphone. Aucune application n’est à télécharger et à installer.
  • Application native : l’application mobile du site à télécharger/installer depuis le store de la marque du téléphone. Il y a plusieurs avantages à préférer cette méthode pour un usage quotidien :
    • La vitesse d’utilisation
    • La qualité et la sureté du contenu : avant d’être disponible sur les stores, l’application est testée (plus ou moins bien en fonction du store) et validée par un groupe de testeurs.
  • Application hybride. Cette notion regroupe les deux précédents. On développe alors une application qui sera déployée sur différents stores.

Les multiples avantages du framework PhoneGap :

  • Gain de temps
  • Réduction des coûts de développement
  • Grosse communauté
  • Utilisation des langages web

Mais il ne faut pas oublier que cette méthode a des limites :

  • Lenteurs : lenteurs constatées par rapport à des applications natives
  • Limite dans l’exploitation des ressources : impossibilité d’utiliser des tâches de fond (notifications push, par exemple)
  • Débuggage : difficultés lorsque l’on souhaite débugger son application

Conclusion : il est conseillée d’utiliser PhoneGap pour une application multi-plateformes lors de petits projets.

Comparing Titanium and PhoneGap par Appcelerator Developer Blog (mai 2012)

Les faiblesses de l'approche PhoneGap

  • La qualité de l'interface utilisateur dans une application PhoneGap varie en fonction de la qualité de la vue web et moteur de rendu sur la plate-forme.

Les faiblesses de l'approche de titane

  • Le champ d'application de l'API Titanium permet l'ajout de nouvelles plates-formes difficiles - la mise en œuvre de l'API de titane sur une nouvelle plate-forme native est une entreprise colossale. Pour cette raison, la plate-forme Titanium est disponible uniquement sur ce qui a été jugé que les plates-formes mobiles les plus critiques à l'heure actuelle: iOS, Android et sur ​​le Web.
PhoneGap VS Appcelerator (avril 2012)
  • PhoneGap : moteur de rendu Web
  • Titanium : conversion en code source pour la cible
jQueryMobile et PhoneGap : un duo gagnant pour vos applications mobiles ? (avril 2012)

Les points faibles de jQueryMobile (qui ne sont pas tous spécifique à jQM, mais plutôt à l’approche HTML5) :

  • L’expérience utilisateur (User eXperience) est vraiment pauvre par rapport à ce qu’on peut obtenir avec une application native
  • Les performances sont mauvaises, notamment sur les transitions entre écrans sur Android
  • On subit les bugs des différentes versions de WebKit (nous avons eu des problèmes avec Android 2.1 par exemple) et finalement on retrouve les mêmes problématiques qu’avec un développement web classique : debug pas spécialement évident, même s’il existe des outils

Les points faibles de PhoneGap :

  • Il ne s’agit “que” d’une API Javascript : l’implémentation des méthodes de callback est une charge non-négligeable
  • Il faut bien prendre en compte que si on développe des plugins spécifiques PhoneGap il faudra effectuer ce développement sur chaque plateforme cible (pour la partie native ET la partie Javascript). Seule “l’API” exposée par les méthodes Javascript reste stable entre plateformes, non pas le cœur de PhoneGap.
  • Le niveau de qualité des plugins, notamment de la communauté, est très hétérogène
  • Assez compliqué de faire une application vraiment “offline” : il faut alors utiliser manuellement le localStorage HTML5 + gérer de la synchronisation avec le serveur ensuite + traiter les erreurs JSON/Ajax. Je n’ai pas eu le temps de tester des outils comme OpenMobster pour gérer la synchronisation, mais cela s’annonce prometteur.

Trois exemples pour illustrer quelques limites :

  • L’avantage évident des solutions hybride est de réduire les coûts de développement mais il ne faut pas oublier les coûts de maintenance : le développement hybride ne permet pas de réduire le périmètre de tests. D’autre part, le code étant partagé, une correction de bug devra être testée sur toutes les plateformes pour s’assurer de l’absence de régression
  • La comparaison entre les Android Design Guidelines et les iOS Mobile HIG Guidelines permet d’identifier que les approches proposées par ces deux plateformes différents parfois radicalement. Proposer une IHM identique pour ses deux plateformes ne pourra logiquement se solder que par un écart entre l’ergonomie de l’application “hydride” et des autres applications de l’OS
  • Il n’est pas possible d’utiliser des services en tache de fond : une fois le composant navigateur fermé, l’application n’existe simplement plus. Il est donc impossible de proposer du push, de synchronisation en tache de fond ou des traitements en parallèles. La norme JavaScript WebWorkers permet théoriquement de lancer plusieurs traitements en parallèle, mais n’est pas supportée par Android
Différences entre PhoneGap, Appcelerator Titanium, Sencha Touch et jQuery Mobile (février 2012)

Je n’ai jamais été fan de l’objective-C ou du Java. 2 choix : du web mobile ou du mobile natif.

jQuery Mobile, à l’inverse de Sencha Touch, élève les possibilités du DOM et de l’HTML de la page selon sa façon. Vous devez d’abord construire vos listes de menus, espaces de données etc et en y ajoutant une classe de type « list » ou autre, jQuery Mobile va transformer le visuel et l’afficher de façon plus intuitive sur mobile. C’est une philosophie à l’entière opposition de Sencha Touch.

Pour pouvoir distribuer votre application sur les markets App Store ou Android Market, vous pouvez utiliser PhoneGap qui se charge de créer une webview native et y lance à l’intérieur votre application HTML5. Mais ce n’est pas tout, il ajoute au composant webkit de la webview de nombreuses fonctions javascript vous permettant d’accéder à la caméra, aux contacts et autres directement dans votre code JavaScript. Une fois finie, vous la packagez et l’envoyez comme n’importe quelle application native.

Le framework Titanium d’Appcelerator est différent. Toujours à partir de code JavaScript, il va en fait compiler ce code en code native grâce à son framework qui fait office de passerelle entre les composants instanciés en JavaScript et le résultat qui est du code natif Cocoa/Android. Vous allez donc utiliser les mêmes objets pour les différentes plateformes, les mêmes composants et le même code, à quelque nuances près évidemment, pour ensuite lui dire de compiler/transformer ça pour Android ou pour les appareils iOS. Vous aurez à la fin une application native, avec les composants et l’interface natifs du mobile visé, ce qui sera entièrement transparent pour l’utilisateur !

For mobile, it’s all native – appcelerator vs phonegap vs native (février 2012)

Contrairement Appcelerator, avec Phone Gap, le javascript n'est pas compilé en code natif. Il est tout simplement intégré dans un UIWebView (ou autre crontôle webkit pour d'autres plateformes). Ceci a des implications importantes que vous devez comprendre :

  • UIWebView n'est pas performant, votre application ne sera jamais autant performante qu'une application native.

Développer des applications natives sur toutes les plateformes est plus cher, sans doute. Mais sans natif, les UI ne sont pas ergonomiques.

PhoneGap et jQuery Mobile : tuto connexion serveur distant (janvier 2012)
Tutoriel vidéo Appcelerator Titanium : Développer une application mobile (juillet 2011)

Tutoriel vidéo pour découvrir comment créer une application mobile en utilisant appcelerator titanium

Quelle stratégie de mobilité multi-plateforme ? (juillet 2011)

Les différentes plateformes mobiles proposent toutes des environnements de développement bien conçus et intuitifs pour les développeurs, offrant des possibilités très pointues : services en tâche de fond pouvant se réveiller lorsque l’on passe à proximité d’un point géographique précis, interaction avec l’agenda, le carnet d’adresses, pilotage du GPS, de l’appareil photo,etc.

Les Solutions multiplateformes

Pour éviter d’avoir à réécrire plusieurs fois la même application sur diverses plateformes, il existe des solutions, qui obligent à des compromis.

On ne peut pas mécaniquement adresser plusieurs plateformes en même temps et en tirer parti à 100%. Toutefois, en fonction du besoin de l’entreprise, le compromis peut se révéler très intéressant.

Aucune solution n’est idéale. Tout dépend des besoins, des attentes des utilisateurs, de la manière dont l’application sera utilisée, etc. Afin d’y voir plus clair, une approche plus détaillée des solutions les plus intéressantes s’impose.

On peut distinguer 3 façons de réaliser de l’applicatif mobile :

  • applications natives,
  • application web HTML5,
  • application multiplateforme packagée.

L’application native reste spécifique

Si l’on considère les principales plateformes, les langages et APIs à maîtriser, on se rend compte de la complexité de la tâche.

  • Android : Java JDK,
  • iPhone : ObjectiveC,
  • Symbian : C++,
  • Blackberry : Java J2ME (Java 2 Micro Edition)

Des frameworks JavaScript pour interfaces graphiques

  • PhoneGap, est un conteneur d’application web. Il permet d’écrire son application en HTML et JavaScript, et de l’afficher dans la fenêtre d’un navigateur, sans la barre d’adresse. L’utilisateur ne voit pas qu’il s’agit d’un navigateur. PhoneGap met également à disposition du JavaScript et des APIs pour accéder au smartphone : géolocalisation, prise de photo, stockage des données…
  • Appcelerator Titanium, est très particulier, puisqu’il permet de générer des applications réellement natives pour Android et iPhone, sans écrire une seule ligne de code Java ou d’Objective C. La programmation se fait en JavaScript et un compilateur transforme ce code en code binaire à destination des plateformes Android et iOS.
  • Mono Touch et Mono Android, permet d’écrire facilement des applications iPhone ou Android en langage C#. Le code dédié à l’interface graphique ne pourra pas être réutilisé entre les deux plateformes, mais la logique métier peut être partagée.
Anciens articles

Le meilleur langage pour le développement cross-platform est-il le C++ ? Embarcadero prévoit une résurgence du C++ dans le mobile

I'd really love to be able to write for mobile in C# which I'm very familiar with. I just can't imagine why Xamarin has made it so cost prohibitive.

MonoDroid/MonoTouch might be a good place to start looking. Both compile to native binaries on their respective platforms, but are largely useless for UI work. What if in the future you wanted to do something cool with your app that isn't supported by the super abstract cross platform toolkit? Dropping to native code will be difficult, unmaintainable and you'll be wishing you went the native route to begin with.

cross development android iphone

MonoTouch is Mac Only

Mono :

Windows Phone 7 ou 8 : quelle plateforme faut-il privilégier pour son application mobile ?

Mono plateforme

Android / iOS

Android

iOS

...

Langages

  • Android : Java, C, C++
  • iOS : Objective-C, C, C++
  • WP : C#, VB.NET, F#, C, C++

Ressources développeurs mobiles

siteduzero.com
developpez.com

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

Fil des commentaires de ce billet