mercredi 30 décembre 2009

W3C Widget : La solution au dilème webapp/natif iphone/natif android ?

Le dilemme du moment...

Le grand interrogation du moment dans le petit monde du développement mobile est le choix des technologies. Il était une époque pas si lointaine, où, il faut bien l'avouer, le développent mobile était guère palpitant et cela n'intéressait pas énormément de gens. La faute à l'absence de 3G et de matériel peu performant certainement, la faute aux apis utilisés peut être aussi : Il y avait bien J2ME, l'api Windows CE, et quelques autres frameworks qui n'étaient pas satisfaisant, ni pour les développeurs, ni pour les utilisateurs : trop de différences entre les implémentations (J2ME), ou standard trop fermé (Windows CE).
Avec le succès de l'iphone, le marché juteux a fait s'intéresser beaucoup de sociétés au développement sur téléphone et beaucoup ont investis dans l'écriture d'applications iphone, pour "être présent sur ce nouveau segment". Jusque là, tout va bien.
Oui mais voilà, android est de plus en plus présent et... ça serait dommage de ne pas être sur ce segment... Sauf que cette fois, tout le monde est un peu plus frileux, faut il réinvestir ? Ne peut-on pas faire des choix plus pérènne qui puisse nous permettre d'être présent sur toutes les plateformes.

HTML 5 au secours du développeur mobile

Il y a bien une solution séduisante : faire un site internet version mobile, adapté à l'utilisation au doigt, aux petites résolutions, et aux connexions internet peu performantes. On a tout de même certaines interrogations :
Avec l'HTML5, je vais pouvoir avoir faire des animations sympas, utiliser la géolocalisation, mais comment vais je faire si j'ai besoin d'utiliser l'appareil photo, les contacts du téléphone, être prévu lors de l'arrivé d'un SMS ? Pour beaucoup, il n'y a pas ces besoins, c'est donc une solution intéressante.
Il y a quelques problèmes cependant :
 - Performances pour certains cas d'utilisation (jeux ?)
 - Pas présent sur le "market" du téléphone, donc on se prive d'une certaine simplicité d'accès.
 - L'application n'est pas réellement "installée", l'utilisateur n'a pas la sensation de s'approprier l'application et ne sait pas trop si ça va fonctionner en mode "non connecté" quand il sera dans la campagne profonde ou à l'étranger sans forfait data par exemple.
- Il n'y a pas de raccourci dans la liste des applications. Il y a les favoris sur tous les navigateurs et la possibilité de créer un raccourci sur le Home sous android mais c'est à l'utilisateur de leur faire et c'est un peu compliqué...
- Ne fonctionne pas en "en tache de fond" donc pas de notifications par exemple.

Qui dit mieux ?

Tout ça, c'est assez gênant il faut bien l'avouer. Il y a plein de frameworks qui émergent de partout pour essayer d'unifier tout ça. Mais standardiser, c'est difficile, il faut trouver le consensus, faire l'unanimité, il faut avoir un certain pouvoir, être écouté.
Je suis suis tombé sur une spécification du W3C au hasard de mes recherches sur internet qui s'appelle Web Widgets. Beaucoup y voit une façon de créer en HTML des petits cadres à incorporer dans un portail, sur un bureau, etc... Cela consiste en un fichier Zip contenant des fichiers html, css, ... avec un fichier xml de description. C'est en quelque sorte un mini site web "offline". Il semblerai que le W3C ait une vision beaucoup plus large de la chose... Et j'y vois un certain potentiel également. Et pourquoi cela ne pourrait pas être des applications pour mobiles ? Dans les W3C Widgets, on déclare des "features", se sont en quelques sortes des "api javascript non standardisés" que l'on s'attend à avoir à disposition lors de l'installation du widget. Voilà une porte ouverte à toutes les fonctions natives, sensors et autres équipements des téléphones.

C'est bien gentil, mais mon SMS, je l'intercepte comment alors ?

Il y a un framework dont l'origine n'est pas le w3c qui semble être parti sur cette piste : Bondi de l'OMTP (Open Mobile Terminal Plateform). A l'origine cela ne respectait pas la norme W3C Widget, ils s'y sont raccroché par la suite. Les gens derrière l'OMTP sont plutôt des fabricants de téléphones et des opérateurs : AT&T, Orange, Vodaphone, Ericsson,... Il y a donc une API javascript (oui, encore une) qui tente de standardisé l'accès aux ressources du téléphone. La techno a l'avantage de permettre d'utiliser du code non spécifique pour 90% de l'application : du html, du CSS et du javascript, le risque est déjà beaucoup plus réduit. Il faut bien l'avouer c'est assez élégant : on imagine par exemple pouvoir utiliser GWT pour générer ses pages html/javascript. Je n'ai pas bien compris s'il s'agissait d'une spécification ou d'une implémentation et éventuellement sur quelles plateformes l'implémentation serait disponible. L'autre avantage est aussi de pouvoir déployer une partie de ses pages "en ligne" sans pouvoir utiliser toutes les fonctions du téléphone et de proposer une version Widget plus évoluée en partageant du code commun.

Dans tous les cas, je trouve la piste intéressante et je suis certains qu'on va en entendre beaucoup parler en 2010 ! Je serai intéressé par créer une petite interface android pour lancer des W3C Widgets basiques en utilisant les bridges java/javascript fournis dans l'appli android et webkit pour voir ce que ça peut donner... peut être le sujet d'un prochain article...

Et vous, qu'en pensez vous, futur flop ou futur standard ?

Pour aller plus loin :
Introduction aux W3C Widgets
BONDI is all beachy with W3C
http://bondi.omtp.org

4 commentaires:

  1. Salut,

    bonne réflexion.
    Concernant le raccourci vers une page web sur l'écran, l'Iphone sait aussi le faire.

    Je pense que l'on est qu'au début de l'explosion du web mobile, mais je pense aussi que l'on a déjà beaucoup d'éducation à faire. Par exemple les sites qui vous redirigent vers la version mobile du site mais sur la page d'accueil... Quand on vient de cliquer un lien "bit.ly" ou autre depuis un smartphone, c'est vraiment frustrant.
    Il reste encore un ensemble de règles d'utilisabilité à définir aussi.

    Enfin sur l'aspect webapp/natif, je ne pense pas que HTML 5 va signer l'arrêt de toutes les applications natives (notamment pour les problemes de perf ou d'utilisabilité).
    Par contre son arrivée va peut être permettre de voir disparaitre une grande partie du flash inutile que l'on trouve sur le web....

    RépondreSupprimer
  2. Il aurait fallu que je définisse la notion de "natif". Par exemple on peut considérer que programmer en java sur android, c'est un développement "natif" puisque c'est celui qui a été conçu pour le développement sur la plateforme (mais ce n'est pas le langage natif du processeur ARM...)
    Les API standardisées sont de plus en plus haut niveau et couvrent de plus en plus de choses, les processeurs de plus en plus puissants. Je pense qu'on (= la très très grande majorité) ne développera bientôt quasiment plus "natif" de la même façon que l'on n'écrit plus d'assembleur x86 directement aujourd'hui.
    La standardisation des interfaces matériel/logiciel s'accélère et le niveau d'abstraction augmente avec des organismes comme le W3C ou le JCP qui semblent réussir à fédérer à un niveau mondial.

    RépondreSupprimer
  3. I get a lot of great information from this blog. Thanks for sharing this valuable information to our vision. You have posted
    a trust worthy blog keep sharing.
    Tableau Online Training

    RépondreSupprimer

  4. Hadoop online training in hyderabad.All the basic and get the full knowledge of hadoop.
    hadoop online training in hyderbad

    RépondreSupprimer