Back to the C

Que retient-on de cette sortie ? La très bonne initiative de l’iFund ($100M pour financer des éditeurs de logiciels iPhone), le mode de distribution simple et cohérent via l’AppStore (où 70% des revenus iront aux éditeurs) et enfin le fait qu’il faut se mettre (ou se remettre) à l’Objective-C

Et c’est bien là que le bât blesse : la pluralité des environnements de développement mobile. Si Adobe n’en a toujours pas basé sur Flex / AIR (on suppute fortement qu’il sera inclus à Flex Builder 4), on avait déjà Java, on se retrouve aujourd’hui avec Androïd, Silverlight Mobile et l’iPhone.

Cette diversité a des points positifs

• La technologie va être tirée par le haut du fait de la comparaison immédiate entre plates-formes
• Des développeurs ultra-spécialistes d’une plate-forme vont pouvoir valoriser leur expertise ; les développeurs multi-plates-formes vont s’arracher sur le marché du travail
• La concurrence va inviter les éditeurs des plates-formes à ne pas – trop – verrouiller leur environnement

Mais aussi des aspects négatifs

• D’un point de vue commercial, le développement d’une application mobile universelle va coûter son prix unitaire multiplié par autant de plates-formes !
• Les clients vont donc souvent devoir se positionner sur l’une ou l’autre en ignorant une partie de la communauté
• Beaucoup de beaux projets risquent de ne pas voir le jour ou être réservés à une élite (n’oublions pas que l’iPhone est encore un produit de luxe !)

En résumé, on retrouve tous les ingrédients d’un début d’une nouvelle ère, où les technologies, supports et marchés commencent à émerger… avant le ras-de-marée ?

Entre framework et pot-pourri technologique

Comme nous l’expliquions dans un précédent post, Microsoft et Adobe sont au coude-à-coude en matière de fusion entre applications desktop (comprenez, une application qui s’exécute sans navigateur, comme un exécutable) et applications web (comprenez, une application qui utilise des services et/ou du contenu en ligne).

Adobe sort du bois et nous dévoile une alpha de son framework Apollo, sous forme de concentré du savoir-faire d’Adobe et de sa filiale Macromedia : (X)HTML, AJAX, Flash, Flex, … tout y est ! Mais en plus, le framework gère nativement l’accès aux données locales de la machine hôte et en exploite les ressources graphiques (on peut s’attendre à l’avenir à une prise en charge semi-matérielle de certains traitements).

Le meilleur reste à venir

De nombreuses fonctionnalités complémentaires restent cependant attendues, permettant d’ancrer encore un peu plus le framework au système d’exploitation :

• Support natif du format PDF
• Intégration d’une API de gestion des états de connexion
• Support du glisser/déposer et du copier/coller
• Fenêtres lookées selon le système hôte
• Lancement automatique d’une application adéquate en cas de manipulation de certains fichiers
• Contrôle complet du menu contextuel de la souris
• Gestion de la transparence

Ces fonctionnalités implémentées, la frontière entre application traditionnelle et application web deviendra encore un peu plus fine, avec toutes les conséquences que cela comporte : déclin des modèles d’édition classique de logiciels (on pense en particulier aux suites bureautiques), mais aussi marginalisation des utilisateurs hors-ligne.

Pour découvrir Apollo en action, il suffit de se rendre sur cette page et de télécharger le runtime. Une démonstration technologique est ensuite accesible sur cette page et d’autres ici.

Il est encore tôt pour se prononcer en faveur de Windows Presentation Foundation et Apollo, tant les deux frameworks en sont à leurs débuts. Il faudra cependant ne pas manquer ce virage de la fusion applications web-desktop, qui montre l’avenir de l’édition logicielle, en apportant son lot d’avantages : multi-plateforme, fidélité du rendu, standards ouverts, évolutivité, non piratable…

Si d’aucuns pensaient que le débat était enterré – XML étant devenu au fil des années le standard incontournable de l’échange de données – un nouveau venu vient semer le doute dans les esprits.

Plus compact que XML et tout aussi intuitif

Nouveau venu, mais – à l’image d’AJAX – basé sur des standards anciens, JSON propose une structuration simple des données :

{« menu »: {

 "id": "file",  "value": "File",  "popup": {    "menuitem": [      {"value": "New", "onclick": "CreateNewDoc()"},      {"value": "Open", "onclick": "OpenDoc()"},      {"value": "Close", "onclick": "CloseDoc()"}    ]  }

}}

pour comparaison, son équivalent en XML :

<menu id= »file » value= »File »>

 <popup>    <menuitem value="New" onclick="CreateNewDoc()" />    <menuitem value="Open" onclick="OpenDoc()" />    <menuitem value="Close" onclick="CloseDoc()" />  </popup>

</menu>

Le débat

JSON a été vécu comme un cheval de troie pour les adeptes de XML. Certains parlent de retour en arrière ou encore de nivellement par le bas (pas de déclaration de jeu de caractère, ce dernier devant être connu à priori par exemple).

Effectivement, JSON est une structuration très simple, et n’est pas destiné à représenter des structures complexes fortement imbriquées. Il est plus difficilement interopérable, faisant abstraction des problématique de jeu de caractères et n’est donc pas destiné aux applications web ouvertes.

Ces limites définissent un cadre d’utilisation de JSON local, permettant des échanges moins lourd, plus rapidement codés, entre des entités connues à priori (par exemple, des modules d’une même application). XML garde sa superbe pour les échanges vers le reste du monde.

Ressources

Le site officiel de JSON décrit très simplement le formalisme. Pour les anglophones, cet article fait un point détaillé sur l’opposition entre JSON et XML.

Rappel des syntaxes de déclaration des DTD

HTML

HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

XHTML

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Pour plus d’information sur les différences de chacune DTD, je vous recommande cet article, en attendant la finalisation (puis l’implémentation) du XHTML 1.1 et du XHTML 2.0.

Les raisons de cet état de fait sont multiples :

• L’immense majorité des serveurs d’applications est aujourd’hui basée sur J2EE
• Certains serveurs d’applications intègrent nativement les couches de persistance des objets (ORM ou Object Relational Mapping) et de fonctionnement en grappe (clustering)
• Java reste dans l’inconscient des décideurs informatiques un langage plus robuste que PHP ou ASP.NET.

Des alternatives à J2EE existent cependant

L’idée reçue d’un PHP instable est aujourd’hui de plus en plus difficilement opposable tant de nombreux piliers du e-commerce en France et dans le monde fonctionnent sous cette technologie, avec des disponibilités tout à fait comparables avec des solutions J2EE.

De fait, Les applications PHP exploitent moins de couches logicielles que des applications Java ; pour un langage intrinsèquement tout aussi stable, les applications PHP sont donc peut-être plus disponibles ; leur maintient en production est dans tous les cas plus aisé.

Des contextes privilégiés

Si consolider un catalogue d’applications J2EE par une application web PHP n’a que peu de sens, la création ex nihilo d’une application web est l’occasion de se poser les bonnes questions quant au langage de développement.

Dans sa version 5, PHP propose par ailleurs un modèle objet très proche de Java ; avec un peu de rigueur dans la modélisation, il est tout à fait aisé de produire les mêmes fonctionnalités de reporting qu’une application J2EE.

En résumé, de nombreux avantages existent à développer une application web sous PHP :

• Leur hébergement est plus aisé, de simples directives visant la compilation de PHP sur le serveur d’hébergement sont à prévoir
• Leur disponibilité est comparable à des applications sous serveur d’application J2EE.
• PHP est très bien fourni en terme de programmation orientée service