Mutualisation des développements Mobiles (Partie 2 : client natif)

Cette étude a pour but d’étudier les possibilités de mutualisation des développements à destination des mobiles, elle est décomposée en deux parties (sites Web et développement natifs).

La cible étudiée ici est orientée entreprise (en opposition à des sites internet grand public). La société connait le type de PDA déployé, les versions de l’os, le navigateur, etc.

Tout d’abord commençons par un état des lieux des technologies natives offertes par les différentes plateformes.

Etat des lieux des technologies

"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

Apple vient donc de modifier les conditions d’utilisation de son kit de développement pour l’iPhone OS 4.
Si l’on suit à la lettre la recommandation, il en ressort que les applications devront être développées nativement en Objective C ou bien en JavaScript.

Une lecture plus souple étant que les applications iPhone devront obligatoirement passer par un projet XCode et une phase en Objective-C, ce qui est déjà moins contraignant.
La plupart des frameworks présentés ci-dessous passent par cette phase et les quelques retours pour l’instant sont plutôt positifs. Les éditeurs se veulent très rassurant sur la pérennité de leur framework.

De toute façon si ses frameworks existent c’est que les éditeurs de smartphone proposent des API pouvant être appelées librement.

Préambule 2 : Redevances obligatoires

**iPhone
**Pour déployer et tester sur un vrai iPhone (pas jailbreaké) il faut impérativement passer par XCode, et donc un Mac Intel et accessoirement payer la redevance iPhone Developer Program 99$ même si le but n’est pas de déployé l’application par l’Apple Store.
En effet il faut un compte valide pour pouvoir créer un projet sous XCode.

BlackBerry
Pour pouvoir accéder aux fonctions systèmes d’un BlackBerry (file system, carte SIM, etc..), le code doit être signé.
Pour cela il faut s’acquitter d’une licence (Java Code Signing Keys) dont le prix est modeste (20.00$ par application)

**Symbian
**En fonction de la version de l’OS Symbian et surtout des protections mise en place par le fabricant de mobiles, seules les applications signées peuvent être installées ou avoir accès à certaines fonctionnalités.
Il n’y a pas de redevance à payer à Nokia mais auprès d’un fournisseur de certificats.

Les solutions basées sur les technologies Web

Des frameworks prétendent pouvoir unifier les plateformes de développement utilisées pour développer une application Web et les technologies utilisées pour les applications mobiles.
Le postulat est le suivant : un développeur maitrisant les technologies Web (HTML, CSS, JavaScript) doit pouvoir développer une application mobile sans pour autant apprendre de langages natifs.
Le but avoué étant d’être opérationnel le plus rapidement possible sur ces plateformes.
Ces frameworks mettent à la disposition des développeurs des fonctionnalités natives propres à certains smartphones telles la géo localisation ou l’accès aux contacts SIM, le tout en JavaScript (ou Ruby).
Si l’aspect d’une application développée ainsi diffère peu d’une application native, l’inconvénient de ces solutions est la limitation due à l’exécution de code au sein des navigateurs vis à vis de clients natifs (en attendant HTML5).

PhoneGap(Site Web)

L’idée est de fournir un container natif (écrit dans le langage supporté par le PDA) pour des applications Web écrite en HTML JavaScript, CSS.
Le container est un pont entre le JavaScript de l’application et les API natives du smartphone.

Un framework JavaScript (affichage des pages, services, etc..) est commun à toutes les plateformes.

Des frameworks JavaScript spécifiques à chaque plateforme sont utilisés pour les accès natifs (par exemple géo localisation, clavier virtuel, etc.).
Il y a donc des différences entre les cibles, cette dernière est obligatoirement définie lors de la création du projet.
Même si les technologies et les API sont très proches, il y a autant de projets que de cibles techniques.

Possibilité de persistance locale sur le PDA grâce à SQLite (non supporté sur BlackBerry).
***PhoneGap ***utilise le même principe que GWT, c’est à dire une seule page web dont le contenu change grâce à de l’Ajax (SPI).

Même si l’on parle d’applications natives, il n’y a pas de compilation technologies Web vers les langages natifs.
Seule la partie technique (le container) est compilé en langage natif, la logique applicative ainsi que les IHM restent telle que développées (HTML, etc..).

***PhoneGap ***intègre tout le contenu applicatif dans un dossier web.
Le contenu Web est chargé par une application native ne contenant qu’une fenêtre (HTMLView).
L’application est exécutée de manière autonome (sans utiliser le navigateur)
En effet une application Web normale n’a pas accès à l’ensemble des fonctionnalités pour des questions de sécurité.

Il est d’ores et déjà possible d’accéder en JavaScript aux services suivants à l’aide de ***PhoneGap ***:

• Géo localisation
• Vibration
• Accéléromètre
• Son (lecture)
• Support de l’accès aux contacts

Les prochaines fonctionnalités à venir sont les suivantes :

• Support de l’appareil photo.
• Support du téléphone.
• Accès au système de fichiers.
• Support des SMS.
• Enregistrement de son.

Pour chacune des cibles, un kit de démarrage (starter kit) est fourni sous forme d’un projet qu’il suffit de compléter.
Des simulateurs sont fournis pour chacune des plateformes évitant de déployer sur la machine cible pour tester (en tout cas trop souvent).

Le déploiement est manuel (SDK fourni), ***PhoneGap ***ne permet pas de se passer d’un ordinateur Mac pour déployer une application IPhone.

NB : L’outil ne viole pas les nouvelles règles d’utilisation de l’Apple Store (OS4).

Titanium Mobile(Site Web)

***Titanium ***(anciennement Appcelerator) est une plateforme libre pour développer des applications mobiles et de bureau en utilisant des technologies web (existe depuis 2008)
Elle supporte le développement d’applications pour iPhone (sous Mac OS avec le SDK seulement) et pour Android depuis Juin 2009.
Titanium Mobile permet aux développeurs web d’utiliser leurs compétences pour créer des applications natives pour iPhone et Android.

Titanium Developper permet de créer un projet de le packager et de l’exécuter (simulation).
Le développement se faisant dans votre IDE préféré

***Titanium ***inclut un outil de cross-compilation online qui demande un accès internet et un compte développeur.
Pour cela les fichiers source sont envoyés à une machine propriétaire côté serveur qui renvoie alors les binaires.
Un compilateur en ligne de commandes libre est aussi disponible (avec des restrictions fonctionnelles)

La compilation pour mobile est sujette à des exigences supplémentaires : Pour l’iPhone: Mac OS X et le SDK iPhone, et pour Android: le SDK Android et une plateforme (Mac, Windows ou Linux).

La dernière version du cross-compilateur de Titanium a été compilée par lui-même !

***Titanium ***propose un support des technologies Web basés sur les standards: HTML, CSS et JavaScript. 
Il est donc possible d’étendre les possibilités de l’application avec les principaux frameworks JavaScript et AJAX dont jQuery, YUI, MooTools, Scriptaculous.
Ce concept favorisant encore la réutilisation des compétences Web

Titanium fournit une API indépendante de la plateforme pour accéder aux composants UI natifs dont les barres de navigations, les menus, les boîtes de dialogues et les alertes, et des fonctionnalités natives des appareils dont le système de fichiers, le son, le réseau et une base de données locale.
Accès de l’API aux fonctions natives du mobile comme la géo localisation, l’accéléromètre et les cartes.
Extensibilité à travers des interfaces libres et des licences autorisant les développeurs à ajouter le support d’autres langages de programmation, de codecs multimédia et de fonctions spécifiques à l’appareil

Tout comme ***PhoneGap ***même si l’on parle d’application natives, seule la partie technique est compilé en langage natif, la logique applicative ainsi que les IHM restent telle que développées (HTML, CSS, etc.).

Cependant contrairement à PhoneGap, ***Titanium ***expose directement les API natives du smartphone en JavaScript (la signature des méthodes est la même que celle exposée par l’API).
Ainsi il faut s’attendre à des différences plus importantes entre les différentes plateformes, ***PhoneGap ***proposant des API plus génériques et communes à l’ensemble des plateformes.
En contrepartie l’exploitation des possibilités de chaque appareil semble plus profonde et plus extensible (rien ne vous empêche de créer votre propre fonctionnalité à partir des API exposées)

***Titanium ***utilise Webkit comme moteur de rendu (et donc s’ouvre à HTML5 et CSS3).

Il est possible de stocker des données localement grâce à SQLite de même l’accès au système de fichier est possible (iPhone / Android).
Pour les échanges entre le client et le serveur, HTTP est bien évidement possible mais aussi les Web Services (SOAP, REST).

NB : L’outil ne viole pas les nouvelles règles d’utilisation de l’Apple Store (OS4).
En effet pour pouvoir développer une application iPhone il faut :

1. Installer le SDK Titanium sur un MAC
2. Utiliser XCode pour concevoir et développer le projet

Pour l’iPhone, le code généré (celui du container) est de l’Objective C (parfois C et C++).

***QuickConnect ***(Site Web)

Il existe autant de versions que de mobiles supportés :

1. QuickConnectiPhone
2. QuickConnectAndroid/Nokia/Linux/Windows/Palm.
3. QuickConnectBlackberry

Plus de détails sur les possibilités de chacune des versions RoadMap : Roadmap.

Le fonctionnement est très similaire à ***PhoneGap ***et ***Titanium ***:

• Des librairies JavaScript exposent le fonctionnement natif de l’appareil.
• Le framework fourni le code technique à la base de toute application, le développeur se concentre sur l’IHM et la manipulation des données.

Pour cela, le développeur crée l’interface en HTML et CSS et implémente la logique applicative en JavaScript (coté client).
Le serveur est en charge de la fourniture des données métier, Java EE et PHP sont supportés
Particularité commune aux projets ***PhoneGap ***et Titanium, aucun serveur distant n’est requis pour héberger les fichiers JavaScript, HTML et CSS car ils sont stockés sur le client.
Ainsi si une application existante expose déjà des services appelables par le client, alors aucun impact coté serveur.

Synchronisation entre le client et le serveur grâce au framework Enterprise Synchronization :

• Appel de web services distants.
• Ajax (JSON).
• Permet d’accéder à une base SQLite locale mais aussi distante.
• Dans ce cas les SGBD suivants sont supportés (MySQL, Oracle, Sybase, Microsoft SQL Server).

On peut travailler sous XCode et générer l’ensemble des cibles (Eclipse est aussi supporté).
On peut même utiliser Dashcode, l’outil d’Apple pour la création de sites Web.

Rhomobile(Site Web)

***Rhomobile ***se veut une offre complète et plus professionnelle que les trois projets précédents (qui sont peut être plus destinés au développement d’applications grand public).

En effet l’offre comprend :

1. ***Rhodes ***(framework)
2. ***RhoSync ***(synchronisation)
3. ***RhoHub ***(IDE)

***Rhodes ***est un framework open source dont le but est d’offrir la possibilité de développer rapidement des applications natives pour les principaux smartphones du marché (iPhone, Windows Mobile, RIM, Symbian et Android).
***Rhodes ***est basé sur Ruby et inspiré par Rails (on y retrouve des notions similaires avec des différences dans l’implémentation).

Ce sont de vraies applications natives ayant donc accès aux fonctionnalités telles le GPS, PIM contacts et camera.
Pas de support audio et vidéo pour l’instant.

Le déploiement varie selon les plateformes :

• Ainsi un interpréteur Ruby est intégré à une application destinée à l’iPhone : du Ruby est déployé sur l’iPhone
• A l’opposé pour les plateformes java, XRuby est utilisé (XRuby compile du code Ruby en classes java) : seul du Java est déployé.

Le développeur produit afin de créer une application :

• Du code Ruby.
• Du code HTML et des commandes contenues dans des fichiers .rb and .erb (HTML templates ERB, notion familière des développeurs RoR).

Tout comme ***PhoneGap ***et ***Titanium ***les applications ***Rhodes ***sont des applications Web qui s’exécutent localement.

A la différence de ces derniers le navigateur local est utilisé et c’est le code Ruby ou Java (et non JavaScript) qui permet d’accéder aux fonctionnalités natives de l’appareil.

***RhoSync ***est un serveur destiné aux applications d’entreprise.
Il facilite notamment la synchronisation des données entre le PDA et le back office.

Rhom est un framework de mapping objet – persistance utilisé pour persister les données (localement ou a distance) ainsi que pour synchroniser les données entre le serveur et le PDA.
Ainsi RhoSync gère simplement le offline, les données sont téléchargées localement pour consultation et modification la synchronisation est gérée par le framework.
Si l’adaptateur n’est pas disponible il est très simple d’en développer un (sur le principe CRUD, il suffit d’implémenter 4 interfaces).
RhoSync est compatible avec le push mail BlackBerry Enterprise Server et iPhone 3.0
***RhoSync ***masque aux développeurs la complexité des connexions réseau (établissement de la connexion, reprise sur erreur).
Pour les échanges entre le client et le serveur, HTTP est bien évidement possible mais aussi les Web Services (SOAP, REST).

***RhoSync ***peut aussi fonctionner comme un référentiel des données de Synchronisation pour les smartphones.
Il conserve les données d’entreprise et celles qui ont été transmises à chaque PDA.

***RhoHub ***(actuellement en beta) est un IDE online
Il permet donc d’écrire des applications ***Rhodes ***depuis un simple navigateur.
L’avantage étant que dans le cadre du développement d’applications mobiles multiplateformes, les développeurs n’ont pas besoin d’avoir chacun des environnements nécessaires (OS et SDK)
Ils sont simplement installés sur le serveur.

**iPFaces (Site Web)

***iPFaces ***est un framework dédié mobile qui mélange deux concepts

• Un vieux concept : celui du client-serveur
• Un concept plus récent : les technologies Web

Un client est déployé sur le mobile, il est principalement en charge de l’affichage des pages
La logique applicative et la définition des vues sur le serveur

La partie serveur est une application Web écrite en ASP, JSP ou PHP.

Le choix de la technologie coté serveur conditionne évidemment les développements :

• ASP.Net : Composants .Net directement utilisables dans Visual Studio
• Java : Tag library classique pouvant être utilisée dans une JSP
• PHP : Librairie PHP à inclure dans les projets

Techniquement, une grande partie de l’application est libre (logique applicative, persistances, validation, etc.), seules les vues sont imposées (iPFaces views). En effet les vues sont stockées sur le serveur au format XML.

De fait une application existante peut être adaptée sans réécriture de la logique applicative.
***iPFaces ***est compatible avec Spring et utilise Maven (compatibilité vérifiée).

Un client web spécifique est utilisé par IPFaces, il doit être installé sur le mobile pour l’exécution.
L’avantage est qu’une fois installé il suffit de remplir l’url de l’application pour immédiatement l’utiliser (pas de déploiement de code sur le mobile).
De plus le client est spécifique à une plateforme et communique au serveur la plateforme ainsi que sa version.

Les échanges entre le client et le serveur se font en HTTP(s)

Les fonctionnalités offertes sont similaires aux autres frameworks GPS localisation, photo, boussole, etc.

NB : le client ***iPFaces ***est disponible un peu partout sur le net et notamment téléchargeable gratuitement sur l’Apple store.

• La partie cliente est entièrement libre.
• La partie serveur l’est aussi en cas d’utilisation non commerciale

Les langages de programmation

Le postulat est le suivant : un développeur doit pouvoir développer une application mobile en utilisant un seul langage de développement quelque soit les cibles mobiles visées.
Evidemment les éditeurs proposent des kits de développement mais même basée sur une technologie identique, la mise en commun des développements est très difficile
Par exemple BlackBerry et Android s’appuie sur Java pour leurs développements et pourtant la façon de coder une application est totalement différente.

MoSync (Site web)

***MoSync ***est un framework open source (GPL) dédié au développement d’applications mobiles
Parmi les investisseurs on retrouve des personnes de MySQL (Les deux projets sont basés à Stockholm)

Le langage de développement est C\C++
L’IDE est Eclipse et des plugins maisons (actuellement ces plugin ne sont disponibles que sur OS Microsoft)

Le développement n’est pas typé en fonction de l’appareil cible, le code est donc commun quel que soit la cible.
***MoSync ***propose des librairies C\C++ en plus des librairies standards.

Plateformes : Android, Java ME, Symbian S60, Windows Mobile, Moblin,
Plateformes annoncées : iPhone and Maemo.

Pour démarrer il suffit simplement de télécharger MoSync IDE et de commencer à programmer en C/C++

De part sa nature ***MoSync ***est plus adapté aux graphiques, son, Bluetooth, accès réseau (par opposition aux IHM).
Même si ces éléments ont une implémentation différente entre les différentes plateformes, il est plus facile d’en standardiser l’utilisation que la partie graphique ou il faut plus facilement connaître les spécificités de chaque plateforme (menu, taille de l’écran, etc.) pour pouvoir coder correctement.

***MoSync ***dispose de deux runtimes distincts en fonction de la cible visée (C++ et java).
Il peut donc être troublant de coder en C++ pour finalement installer du Java

Toutes les fonctionnalités ne sont pas opérationnelles sur toutes les plateformes, cependant la fonction existe mais renvoie un code d’erreur en cas de non disponibilité.
La même version peut donc être déployée sur toutes les plateformes (du code devra tester la disponibilité ou non de la fonction sur la plateforme).

3 types de ‘Core’ sont proposés.

1. VM : machine virtuelle classique qui charge interprète et exécute du bytecode MoSync. Surtout utilisé pour le débogage
2. *Recompiler *: Le bytecode MoSync est recompilé en code natif au moment de l’exécution. Les possibilités de débogage sont déjà plus limitées.
3. *Generated *: Exécute simplement du code natif, il s’agit de l’application finale

On passe simplement d’un core à l’autre en régénérant l’application.

Les échanges avec le back office se font soit par Socket soit par HTTP.
Un émulateur est fourni pour chacune des cibles supportées.
Une liste complète des mobiles supportés est disponible (lors du choix de la cible au moment de la création du projet).

J2ME Polish(Site Web)

Le but de ***J2ME Polish ***est de profiter de la très large diffusion de java au sein des appareils mobiles (80 % environ) afin de proposer des technologies de développement ainsi qu’un environnement d’exécution commun à un maximum d’appareils.

Problème :

1. Java équipe plutôt les appareils bas de gamme.
2. J2ME est loin d’avoir convaincu les pros.

En effet J2ME c’est :

• Un développement basé sur les MIDlets
• Limitations par rapport à java SE
• Garbage collector sur un appareil pauvre en ressources CPU et RAM
• Enfin seul le SDK de l’appareil permettait d’accéder à certaines fonctionnalités

J2ME Polish est une suite d’outils conçu pour la création d’applications mobiles.
Même si c’est une extension de la plateforme J2ME (Java 2 Micro Edition) il supporte plus que le profil MIDP.

Liste des Plateformes supportées :

• MIDP
• Windows Mobile (licence supplémentaire)
• iPhone (licence supplémentaire)
• Android
• BlackBerry
• Palm
• Java SE

L’application est écrite une seule fois, charge aux outils d’adapter en fonction des PDA cibles (+de 150 PDA référencés).

Liste des modules :

• *Lush *: Ajoute des effets, des animations à une application J2ME (fichier CSS).
• *Janus *: outils de portage du code vers les différentes cibles.
• *Touch *: Gère la connexion du mobile avec le serveur.
• *Trunk *: Solution de persistance maison.
• *Marjory *: Liste des PDA compatibles.

Globalement :

• Support MIDP 2.0 plus certains composants spécifiques (par exemple des onglets).
• Ajout de composants MIDP 2.0 aux smartphones ne supportant que MIDP 1.0
• Localisation
• Personnalisation de l’apparence (CSS) afin de s’éloigner du look MIDP
• Compilation conditionnelle
• Une base de mobiles avec leur support des fonctionnalités J2ME Polish
• Syntaxe Java 5
• J2ME Polish s’appuie sur Ant pour les scripts

Bilan développements natifs multi plateformes

Pour les frameworks Web :

• Certaines fonctionnalités pas prisent en compte et nécessitent l’ajout de librairies JavaScripts tierces (multitouch iPhone)
• Limitation navigateur
• Délai d’apprentissage court car réutilisation des connaissances Web
• Les performances sont évidemment péjorées par rapport à un client développé en utilisant les technologies natives

Pour tous :

Le plus gros point étant que si les technologies utilisées sont mutualisées, les développements ne le sont pas réellement puisqu’il faut la plupart du temps créer autant de projets que de plateformes.
La réussite d’un projet mobile mutualisée dépendra beaucoup du type d’application souhaité et des plateformes ciblées.
Ces frameworks adressent surtout des applications simples dans leur interface et leur interaction avec le système.
De plus aucun des framework ne peut être atteindre les performances d’une application native et optimisée pour une seule plateforme.

Autre point négatif commun à toutes les solutions : une documentation encore succincte et insuffisante dans la plupart des cas. A noter toutefois des supports (forums) assez actifs.

***Rhomobile ***et ***IPFaces ***semblent être les solutions les plus abouties et les plus propices à une utilisation professionnelle.
***Rhomobile ***et ***PhoneGap ***sont les plateformes qui travaillent le plus en étroite collaboration avec Apple, on peut donc espérer une certaine pérennité de leur solution sur cette plateforme.

Par contre tous ces outils réduisent considérablement le temps de mise en production d’une application tout en respectant les standards.

Résumé

L’avantage étant ces données sont collectées en se basant sur les statistiques d’accès aux principaux sites internet professionnels ou publics (à la différence des statistiques se basant sur les ventes d’appareil).
On a donc une idée des PDA réellement adaptés à la navigation sur la toile ainsi que leur type d’utilisation (professionnelle ou privée).