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.
La solution devra être compatible avec le maximum de PDA suivants : IPhone, BlackBerry, Windows Mobile et (en anticipation) Android.
**Site Web mutualisé pour mobiles
**
De plus en plus de salariés disposent de PDA au sein de leur société et la première idée lorsque l’on souhaite toucher une population équipée d’appareils mobiles est un site Web dédié.
Même si le temps du WAP est loin, il n’est pas encore possible de s’affranchir complètement des contraintes des PDA (taille de l’écran, volumétrie des données échangées). C’est pourquoi un site Web standard et un site dédié aux mobiles continueront de cohabiter.
L’assertion "Le navigateur est le nouvel OS" est ici quelque peut prise en défaut.
Evidemment c’est plus simple si l’on s’adresse à une population équipée d’un seul type d’appareil car sinon se pose le problème de la compatibilité des navigateurs mobiles entre eux.
Les navigateurs pouvant être très différents même lorsqu’ils sont basés sur le même moteur.
Par exemple les versions peuvent diverger d’un OS à l’autre (WebKit pour IPhone et Android) et les fonctionnalités différer d’un OS à l’autre (SAFARI sur IPhone OS propose des fonctionnalités spécifiques).
Voici actuellement les navigateurs équipant les PDA :
- Android : Chrome (WebKit).
- IPhone : Safari Mobile (WebKit).
- Windows Mobile : Pocket Internet Explorer ou Internet Explorer mobile.
- BlackBerry (BlackBerry browser (navigateur propriétaire))
Le W3C a publié un guide réunissant toutes les meilleures pratiques pour le développement d’applications mobiles :
- 60 règles sont définies (http://www.w3.org/TR/mobile-bp).
- 4 niveaux de sévérité (critical, severe, medium, low)
- 6 catégories : Respect des standards, limitation des appareils mobiles, graphisme, taille des pages, réseau, offline)
Une extension à ces recommandations a ajouté de nouvelles règles et approfondit certaines des règles de base (http://www.w3.org/TR/mwbp-guidelines)
Ces recommandations sont très proches de ce qui ce fait pour l’accessibilité d’un site et des normes AccessiWeb
Enfin un validateur online a été mis à disposition (http://validator.w3.org/mobile/).
Afin de ne pas avoir autant de version d’un site que de navigateurs disponibles, la meilleure solution est donc d’installer le même navigateur sur l’ensemble du parc.
Navigateurs multi plateformes
SAFARI-CHROME : WebKit (http://WebKit.org)
WebKit est déjà présent sur IPhone et Android et est annoncé sur Blackberry.
Ce moteur de rendu est moderne (support HTML5), léger et respecte la plupart des standards (Cf. test Acid3 : en.wikipedia.org/wiki/Acid3#Mobile_browsers)
TouchFaces (http://www.primefaces.org:8080/prime-showcase/touch/index.jsf) est un sous projet de PrimeFaces. C’est un framework JSF qui intègre des fonctionnalités Ajax et de push.
TouchFaces est principalement destiné aux applications IPhone mais l’ensemble des navigateurs utilisant le moteur de rendu WebKit sont supportés.
TouchFaces est basé sur jqTouch (jquery).
Par rapport à la version desktop Il y a bien évidemment des composants spécifiques à la version mobile (GPS, navigation, etc.)
Opera : PRESTO (http://www.opera.com/mobile)
Opera étant le navigateur mobile le plus utilisé, c’est aussi un choix judicieux, d’autant plus qu’Opera vient d’annoncer la mise à disposition d’Opera Mini sur l’Apple Store (portage vers Phone OS, toutes les fonctionnalités ne sont pas implémentées).
On attend avec impatience la réponse d’Apple.
Deux versions sont disponibles :
- Opera Mini (application java) qui utilise la compression pour optimiser l’affichage des pages Web
- Opera Mobile (application native) qui utilise un plugin Opera Turbo pour optimiser l’affichage des pages Web
Opera Turbo utilise aussi la technologie de compression mais utilise encore d’autres astuces pour optimiser la vitesse :
- Les vidéos ne sont pas automatiquement téléchargées (il faut cliquer dessus).
- Les images sont "allégées" (l’original reste consultable à la demande).
Les pages affichées sur ces versions mobiles d’Opera transitent par une ferme de serveurs d’Opera.
Le fait de transiter par les serveurs Opera pouvant être un frein important dans le cadre d’une application intranet (confidentialité des données).
NB : Les flux cryptés ne transitent pas par les serveurs d’Opera afin de garantir la confidentialité des données et de ne pas ‘effrayer’ les utilisateurs.
Plateformes supportées :
Opera Mini : BlackBerry – Windows Mobile – Android – IPhone (en cours de validation).
Opera Mobile : Windows Mobile
Cas Flash
S’il est impossible d’installer le même navigateur sur l’ensemble du parc. Pourquoi ne pas confier au plugin Flash la lourde tache de la compatibilité ?
Seulement Flash n’est pas supporté sur IPhone et ne le sera probablement jamais si l’on en croit les dernières déclarations d’Apple, par contre Flash Player 10.1 est annoncé courant 2010 sur les autres plateformes.
Au mieux il est possible de lire les vidéo Flash sur IPhone. Il faut ‘jailbreaker’ l’appareil et installer un plugin qui vous permettra de regarder des vidéos au format ‘flv’ (http://joemaller.com/2008/01/12/itransmogrify)
Devant le blocage d’Apple, Adobe réagit en proposant Flash CS5 (http://labs.adobe.com/technologies/flashcs5/appsfor_iphone) qui permet la migration d’application Flash vers les technologies natives de l’IPhone (code natif ARM).
Il y a donc une phase de cross compilation qui convertit les applications Flash en applications purement IPhone.
Cette technologie semble surtout intéressante pour les applications existantes.
Il n’y a pas qu’Adobe qui se démène à essayer d’implémenter Flash sur la plateforme IPhone. D’autres initiatives existent comme Gordon (http://wiki.github.com/tobeytailor/gordon), runtime Flash implémenté en Javascript.
Mais ici l’approche est différente puisque la cible n’est pas Objective C mais Javascript et HTML5. Une application Flash est donc "Webisée".
L’avantage est que les technologies utilisée sont standards et que c’est open source (licence MIT).
Les navigateurs supportés sont Firefox, Chrome et Safari.
La encore cette solution concerne surtout les applications Flash existantes (sinon quel intérêt de ne pas développer directement en Javascript et HTML5 ?).
HTML5 (et CSS3)
Certaines améliorations apportées par HTML5 semblent clairement destinées aux applications mobiles (offline, animations plus légères, etc.).
L’avenir des développements sur mobile est probablement HTML5 dès que le support sera plus complet (Cf. compatibilité actuelle des principaux navigateurs du marché (http://www.quirksmode.org/compatibility.html).
A noter qu’Apple sponsorise Sproutcore (http://www.sproutcore.com), un des premiers framework HTML5.
SproutCore est un framework Javascript libre, publié sous licence MIT par la société Sproutit.
Il s’agit d’un framework écrit en Ruby qui génère du HTML et du Javascript afin de rendre plus interactives les interfaces utilisateurs dans le navigateur web.
Ce framework aide à construire des applications Web riches (Menus, barres d’outils, le glisser-déposer, la localisation) tout en proposant une architecture MVC.
Parmi les autres frameworks HTML5-CSS3, on peut citer :
- 52Framework (http://www.52framework.com)
- lessFramework (http://lessframework.com)
NB : Aucun de ces frameworks n’est réellement destiné aux navigateurs mobiles.
Enfin on peut noter l’effort de certains aficionados de GWT afin de fournir un framework capable de générer du HTML5 ainsi qu’une version spécifique à WebKit (toutefois la plupart des librairies sont encore en version beta voire non disponibles).
Plus d’informations ici : gwt-mobile-webkit (http://code.google.com/p/gwt-mobile-webkit).
Conclusion
Tout comme pour les applications Web classiques, Il n’y a pas de solution permettant l’uniformisation des développements Web. La situation est même rendue plus difficile par l’absence de frameworks Javascript prenant en charge les spécificités des navigateurs.
Même si certaines applications doivent forcement être natives (notamment celles qui accedent au données de la carte SIM), il est tout a fait possible de créer une application Web exploitant les particularités des mobiles (géolocalisation, gestion de l’écran tactile) le tout en Javascript.
