HTML5 : quels enjeux pour la mobilité et le RIA ?

3 nouveaux séminaires techniques organisés et animés par Objet Direct, en juin :
« HTML5 : quels enjeux pour la mobilité et le RIA ? ».

Etat des lieux du marché, retours d’expérience et démonstrations au cours de ces séminaires Objet Direct, avec le témoignage de Speedinfo : Venez découvrir les nouveaux usages et les perspectives ouvertes par les applications HTML5 mobiles.

=> le 16 juin à Grenoble, le 23 juin à Lyon, le 28 juin à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Framework GWT : GXT vs SmartGWT

Si Google Web Toolkit est un excellent framework Web, il souffre d’un manque flagrant d’éléments graphiques et, bien qu’il existe des bibliothèques comme gwt-incubator, il est parfois très intéressant d’utiliser des frameworks bien plus complets se basant sur GWT. Suite au changement de licence de ExtJS et la fin de GWT Ext, on retrouve maintenant deux frameworks au dessus de GWT 2.0 : SmartGWT et GXT. SmartGWT est un wrapper de la librairie Javascript SmartClient vers GWT alors que GXT est une réelle surcouche à GWT.

La démo de GXT
La démo de GXT
La démo de SmartGWT
La démo de SmartGWT

J’ai l’occasion en ce moment de travailler sur GXT qui a été choisi par le client pour la migration de son application de GWT 1.5 + GWT Ext (devenu donc obsolète et non maintenu) vers GWT 2.0 et GXT. J’ai donc pu découvrir le code et l’architecture de GXT. A coté de ça, je suis allé comment fonctionnait SmartGWT et parcouru les différentes discussions sur internet.

Le choix entre ces deux frameworks est une étape cruciale et assez difficile. Les deux ont leurs détracteurs et leurs défenseurs.

Certaines personnes défendent même l’utilisation seule de GWT 2. Ces deux frameworks se marient d’ailleurs très mal avec le nouveau UIBinder. Cependant, comme le fait remarquer très justement un des contributeurs de SmartGWT, il faudrait plusieurs mois pour recréer les widgets qu’ils offrent.

La principale différence entre ces deux framework GWT est que GXT est purement Java et donc rentre dans la logique complète de compilation java en javascript de GWT alors que SmartGWT est un wrapper. C’est d’ailleurs cet élément qui amène le plus de détracteurs à celui-ci : lenteur, lourdeur du chargement initial, quid d’un changement de licence chez SmartClient – la librairie Javascript encapsulée, difficulté à étendre les classes pour répondre à des besoins particuliers… Google Web Toolkit ne peut pas optimiser le code javascript. Les contributeurs de SmartGWT plutôt actifs se défendent avec vigueur sur ces points 🙂

GXT serait lui moins complet et moins configurable sur l’apparence. D’après ce que j’ai pu voir en parcourant leurs exemples, je pense que c’est configurable avec l’utilisation de Template ()voir un très bon exemple ici)qui est un mécanisme très intéressant. En parcourant les exemples j’ai vu qu’il était possible de « templater » le rendu par exemple une liste pour créer un browser d’image. Je trouve le principe simple et bien flexible ! GXT est écrit en Java/GWT contrairement aux nombreux wrapper Javascript (SmartGWT en tête). Ainsi la compilation n’inoculera que les ressources nécessaires, le débogage se fait en java y compris dans les composants, l’extension de composant est beaucoup plus naturelle et se fait en java.
Cependant tout n’est pas rose sur GXT. D’abord le framework souffre d’un énorme problème au niveau de sa documentation. Si rentrer dans la logique de l’architecture n’est pas d’une complexité insurmontable, il va falloir se débrouiller avec la Javadoc et les exemples finalement pas si nombreux et complets. Pour moi, c’est clairement le point noir de GXT. Ensuite il existe des bugs (JSONLoader dont le templating ne sert à rien) et petites choses à savoir (mettre une taille dans une ColumnConfig pour la voir réellement apparaître !) qui font parfois perdre beaucoup de temps.
Ensuite de façon plus idéologique, GXT ne suit pas entièrement la logique de GWT. GXT utilise une logique MVC et non MVP préconisé par les ingénieurs de Google ainsi que des listener et non des handlers qui sont la norme depuis GWT 1.6.
GXT propose comme GWT Ext un manager central des composants graphiques lorsqu’ils sont référencés par un ID. Cependant c’est parfois difficile à utiliser car ils ne sont réellement référencés dans le manager que lorsqu’ils ont été rendu graphiquement (et pas simplement ajouté dans le constructeur). Par exemple les tabs items ne sont rendus que lorsque l’utilisateur clique sur les onglets correspondant.

Il faut aussi évoquer les problèmes de licences. Si SmartGWT se base sur SmartClient est donc hérite d’une licence LGPL. GXT est lui sous licence GNU GPL V3. Il faudra payer une licence si vous voulez utilisez GXT pour vendre un produit propriétaire ou si vous voulez un support actif de Sencha (l’entreprise derrière GXT).

Dans tous les cas, ces deux frameworks sont impressionnants et confirme l’intérêt porté à GWT ainsi que ces possibilités. La logique programmation en fait des frameworks relativement facile à appréhender (widget, layout, event) et le full Java permet d’être très productif. C’est encore plus vrai pour une personne ayant déjà une bonne expérience des clients lourds type Swing.

N’ayant pu creuser SmartGWT, je ne ferais pas de conseils définitifs. Cependant GXT est sûrement le meilleur choix pour des projets étant toujours sur GWT Ext.

Remarques additionnelle :
– SmartGWT est développé par le développeur de feu GWT Ext
– Il existe une autre librairie très intéressante : gwt-mosaic. Elle aussi en full Gwt.
– Il existe aussi la librairie Vaadin, qui prend aussi en charge la partie serveur.

Test d’Android App Inventor

Annoncé le 12 juillet dernier par Google, App Inventor est un projet visant à mettre le développement d’applications Android à la portée de tout le monde. Le projet permet de concevoir en ligne des applications Android avec une interface WYSIWIG (What You See Is What You Get) uniquement par drag’n drop. Il est librement inspiré d’un projet du MIT destiné à enseigner la programmation de façons visuelle et intuitive, Scratch.

Le projet est encore en bêta fermée, mais des invitations sont régulièrement distribuée et j’ai eu la chance d’en recevoir une dans ma boîte mail. Je vous propose donc un petit retour sur l’utilisation de ce nouveau produit Google.

Installation

L’installation est très simple, elle ne nécessite que d’avoir installé une version récente de Java sur son poste. Il n’est même pas nécessaire de posséder un téléphone sous Android, puisque l’utilisation d’un émulateur est possible. Fidèle à lui-même Google propose de développer son application Android via une interface web.

En réalité seule la partie vue de l’application peut être conçue en ligne. Pour la partie contrôle, elle est réalisée dans une application JavaWebStart nommée block editor. En effet, le projet propose de ne plus coder la logique dans un fichier source mais de réaliser un emboîtement visuel de bloc logique à la manière d’un puzzle.

Utilisation

La conception de l’interface se fait par simple glisser-déposer. Les composants classiques sont présents – Button, Label, Checkbox .. – ainsi que d’autres spécifiques aux téléphones tel que l’accéléromètre ou la localisation. Il existe aussi des composants qui font directement appels au système Android tel que le PhoneCall pour passer des appels ou le SpeechRecognizer pour utiliser les fonctions de reconnaissance vocales.

Malheureusement, il manque beaucoup de composants d’Android et il n’est pas possible d’utiliser ceux présents aussi finement qu’avec une programmation classique. Le point particulièrement bloquant est qu’il est impossible d’avoir plus d’un écrans. L’application devra donc se limiter à un seul écran …

Interface web d'Android App Inventor

La conception de la partie logique est la plus intéressante mais aussi la plus déroutante. Le “jeu” consiste à créer toute la logique de notre application en emboîtant les interactions de chaque composants. On retrouve donc tous les composants qu’on a  déjà positionné ainsi que d’autres “blocs” représentant les procédures, nombres, texte, listes et logique.

Blocks Editor d'Android App Inventor

J’ai d’abord trouvé cette nouvelle façons de “programmer” très facile et surtout très ludique. Il est vraiment simple de glisser les blocs “do” dans des blocs “when” et de construire ainsi très rapidement les interactions des boutons avec les autres composants. Un mini débuggueur est même intégré qui permet d’espionner des variables tout en testant sur le téléphone. Mais, tout comme dans un fichier source classique, avec le nombre vient la complexité. Après avoir ajouté de nombreux widgets et interactions je me suis retrouvé avec un espace de travail très fourni, et il était difficile de retrouver les variables à positionner dans les tests et autres procédures. Entre autre, c’est au final très désorientant pour quelqu’un qui connaît la programmation classique de créer sa logique visuellement.

Voici par exemple la création et l’affichage d’une liste :

Manipulation d'une liste avec Blocks Editor

Et son équivalent en code java :

List<String>; mousquetaires = new ArrayList<String>({“Athos”, “Porthos”, “Aramis”});
mousquetaires.add(“D’Artagnan”);

StringBuilder sb = new StringBuilder(“Les mousquetaires du roi : ”);
for (String mousquetaire : mousquetaires) {
    sb.append(mousquetaire);
}

Clairement, pour quelqu’un qui connait les concepts d’une liste en java c’est beaucoup plus rapide d’écrire un code source. Toutefois, pour une personne qui n’a jamais vu un bout de code, alors là c’est vraiment intéressant pour apprendre les concepts de programmation et des structures logiques.

Conclusion :

App Inventor possède de nombreuses idées très intéressantes. La conception visuelle de la partie logique met le développement à la portée des non-informaticiens. Pour les informaticiens, cela permet de réaliser des prototypes fonctionnels très rapidement en quelques clics. Enfin, il est possible d’utiliser App Inventor instantanément et sur n’importe quelle plateforme et de déployer son application sur son téléphone sans être redevable d’une licence.

Il paraît cependant improbable de pouvoir développer de vraies applications professionnelles avec cet outil à l’heure actuelle. Les limitations par rapport à un développement classique en Java sont bien trop grandes. Il est d’ailleurs impossible d’exporter un projet réalisé avec App Inventor sous forme de code Java pour le reprendre de façon classique par la suite sous Eclipse.

App Inventor risque donc de se cantonner à de petites applications développées par des particuliers pour s’amuser avec leur téléphone et apprendre les bases de la programmation. En cela,  le projet de Google est une bonne chose s’il permet de démocratiser le développement auprès de personnes créatives mais rebutées par le code.

Par contre, ne risque-t-on pas de voir fleurir prochainement sur l’Android Market des tonnes d’applications baclées ? Mais peut-être est-ce un plan de Google pour rattraper Apple dans la course éffrenée aux plus grans nombres d’apps …

En tout cas le projet est une belle démonstration technique notamment par l’utilisation de GWT pour l’interface web et reste à surveiller. Peut-être qu’après le TDD, le DDD, le MDD verra-t-on arriver le DnDDD (Drag’n Drop Development Driven) ? 🙂

Des tutoriaux vidéo pour wiQuery !

Wiquery intègre jQuery avec le framework web Apache Wicket

L’équipe de wiQuery est fière de vous présenter ses premiers screencasts vidéo. Le projet wiQuery intègre les technogologies JavaScript jQuery et jQuery UI avec le framework web java Wicket. WiQuery est sponsorisé par odlabs, le label open source d’Objet Direct.

Au programme, Julien Roche nous propose deux vidéos :

  1. Comment installer wiQuery dans une application existante (version anglaise)
  2. Utilisation du composant tabs, un composant UI pour la gestion d’onglets (version anglaise)

Plus d’infos sur notre site web et notre google code !

A bientôt pour de nouvelles vidéos, et un grand bravo à Julien pour ses tutoriaux !

Flex, technologie incontournable du Web 2.0

3 nouveaux séminaires techniques organisés par Objet Direct, en partenariat avec l’éditeur Adobe et XRCE (Xerox Research Centre Europe) : présentation de l’écosystème Flex, retours d’expérience sur la techno et la plateforme Adobe Flash et démonstrations RIA, multimédia, embarqué, temps réel, supervision, 3D…

Comment intégrer Flex de manière industrielle au sein de vos applications ou de votre SI ? Quelles incidences sur les tests unitaires, l’intégration continue, les métriques de qualité du code ? Quels composants sélectionner pour construire votre architecture Flex ? Comment se positionne Flex sur son marché ? Sur quels types d’applications utilise-t-on avantageusement Flex ? 

=> le 15 octobre à Lyon, le 22 octobre à Paris, le 26 novembre à Grenoble, 9h-11h30 (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Quoi de neuf dans Flex 4 beta et Flash Builder 4 beta ? (suite)

Comme annoncé dans mon précédent article, voici une description des nouveautés/caractéristiques principales amenées par Flash Builder 4:

  • Son nom a changé, pour sonner plus « flashy », car il aurait du s’appeler Flex Builder 4 (du nom de son prédécesseur). Cela  pour devenir l’environnement de développement de la plateforme Flash
  • Echanges simplifiés entre la partie design et le code « entreprise » grâce à Catalyst : nouveau logiciel « passerelle » permettant de définir les composants et leurs interactions à partir des éléments graphiques produits sous la Creative Suite (Photoshop, Fireworks ou Illustrator en version CS4) et ceci sans écrire de code. Le code généré peut ensuite être intégré sous Flash Builder
  • Développement orienté données
    • Simplification de la description des services utilisés par le biais d’une zone dédiée dans l’éditeur
    • Simplification du binding sur un composant graphique par le biais de drag&drop
    • La gestion des données au sein de l’éditeur est de bien meilleure facture qu’auparavant: création de code de paging, ou encore génération des fonctions de CRUD
  • Productivité et test
    • Le debugger a été amélioré: il incorpore désormais un évaluateur d’expression ainsi que des breakpoints conditionnels (pour les features les plus importantes)
    • Le refactoring permet désormais de renommer/déplacer une classe sans se soucier de son usage (fini le Ctrl+Shift+G)
    • Génération automatique des getter et setter ainsi que des gestionnaires d’events (c’est surtout ce dernier qui est apprécié car les getters/setter en AS ne sont pas très utilisés)
    • Info bulles affichant la doc ASDoc
    • Un TCP/IP monitor dédié (monitoring des connexions réseau, plus besoin de passer par Firebug ou Wireshark)
    • Le support de Flex Unit « à la sauce JUnit » complètement intégré à l’IDE

Sources principales:

(Article écrit avec l’aide de Rémi Patriarche)

RIA : Quoi de neuf dans Flex 4 beta et Flash Builder 4 beta ?

2009: Adobe lance les nouvelles versions de ses produits constituant leur plateforme Flash, notamment les produits tournés vers les applications d’entreprise: le framework Flex 4 et l’IDE Flash Builder 4. Quelles en sont les nouveautés/caractéristiques principales ?

Je vous propose de commencer par Flex 4:

Sources principales:

Dans mon prochain article, je traiterai des nouveautés apportées par la version 4 de Flash Builder (anciennement nommé Flex Builder)

(Article écrit avec l’aide de Rémi Patriarche)

.NET RIA Services

Ceux qui ont assisté à la formation en soirée sur Silverlight ont eu un avant gout de .NET RIA Services. Ce framework risque de grandement améliorer la productivité des développements d’applications RIA en .NET.

Quelles sont les réponses apportées par ce framework aux problèmes classiques d’applications RIA ?

– Je ne veux pas réécrire des classes de mon domaine (suivant le modèle Value Object)
– Je ne veux pas écrire le code technique de synchronisation des données entre les deux tiers pour de simples manipulations de données (CRUD)
– Je veux pas réécrire des classes Helper
– Je ne veux pas réécrire mes règles de validation décrites par annotations sur les classes de mon domaine
– Je ne veux pas réécrire mes requêtes LINQ
– Je veux pouvoir travailler simplement sur du CRUD ou des services
– Je veux pouvoir me baser sur le mécanisme d’authentification/autorisation défini sur le serveur

Je présenterai plus en détails ce framework dans le wiki ou dans un autre post et vous ferai part de mes premiers essais.

La preview est disponible sur le site de Microsoft. Cette version nécessite Silverlight 3 qui est en beta 1.

GWT 1.6.2 RC disponible

GWT 1.6.2 RC est disponible en téléchargement, cependant Google lui annonce un cycle de vie très court. Peut être que d’ici 2 à 3 semaines l’équipe GWT annoncera enfin leur nouvelle release stable.
La migration vers cette nouvelle release aura apparemment un certain coût, certaines API sont devenues « deprecated » étant donné que la gestion des évènements a été entièrement revue dans cette release.

L’autre grande nouveauté est l’utilisation du serveur embarqué Jetty et non plus Tomcat en mode Hosted…

Affaire à suivre donc…