Archive

Archives pour 08/2010

Quelle place pour le smartphone dans l’informatique d’entreprise ?

3 nouveaux événements techniques organisés et animés par Objet Direct, en octobre :
« Smartphone : et l’informatique devint mobile… ».

Venez découvrir les nouveaux usages et les perspectives ouvertes par le développement mobile, à partir des retours d’expérience concrets d’Objet Direct qui a conduit pour ses clients plusieurs projets très innovants.

=> le 19 octobre à Lyon, le 20 octobre à Grenoble, le 21 octobre à 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.

Categories: RIA Tags: ,

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) ? :)

Categories: Divers, Mobile Tags: , , ,