Mutualisation des développements Mobiles (Partie 1 : Site Web)

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 :

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. 

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn
Blabla

8 réflexions au sujet de « Mutualisation des développements Mobiles (Partie 1 : Site Web) »

  1. Intéressant ce post!

    Mais comme d’habitude pas un mot sur Symbian / OSS Browser (WebKit), qui est quand même beaucoup plus présent que android.

    1. Effectivement Symbian est beaucoup plus présent que les autres acteurs (voire même que tous les autres acteurs réunis).

      En effet selon une étude Gartner, Symbian OS détiendrait 46 % du marché mondial en 2009 (contre seulement 20 % pour BlackBerry).

      Mais combien d’applications professionnelles ont été développées sur cet OS ?

      La gamme de mobiles Symbian est très vaste et tous les appareils ne sont pas aptes à une utilisation pro.              

      Et surtout quelle est la présence réelle de Symbian dans les entreprises européennes et américaines (l’inde est de très loin le premier marché de Nokia) ?

      Charge à la communauté des développeurs Symbian (très active) de nous convaincre de l’intérêt de cet OS dans le cadre d’une utilisation pro.

      1. En effet il y a un manque d’applications professionnelles sur Symbian (et d’applications en général, même si la tendance est en croissance). Et la tendance actuelle de Nokia est plutôt de se rapprocher du grand public.

        Par contre je me rapelle de statistiques de connexions des smartphones dans les différents lieux en Novembre 2009 (je n’ai pas la source donc c’est à croire ou à laisser). Et l’appareil le plus utilisé dans les aéoroports français est le N95, bien devant l’iPhone, au contraire des connexions dans d’autres lieux. Cela veut sans doute dire qu’il y a une forte utilisation du Nokia en milieu professionnel.

         

        Sinon pour Flash CS5 ça à l’air mort, Apple a vite réagis avec leurs nouvelles règles pour empêcher la migration vers de l’objective-C

        1. Je suppose que ta remarque sur Flash concerne la nouvelle politique de développement Apple (IPhone OS 4.0)

          Extrait :
          "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 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 multi plateformes passent par cette phase).

          Tous sauf un qui, vous l’aurez deviné est flash CS5, le code généré étant du code natif ARM et non de l’objective C comme je l’indiquais à tort.

          De toute facon il s’agit là de règles pour pouvoir être diffusé via l’Apple Store et ne concernent donc pas les applications d’entreprise internes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*