1ère réunion du PAUG

C’est ce mardi 23 novembre que s’est tenu la 1ère réunion du Paris Android User Group. Si vous n’avez pas entendu parler de l’organisation de cet événement, c’est normal : le nombre de place étant limité à 40. Si il y avait eu beaucoup de communication sur les blog/forum, il n’y aurait pas eu de place pour tout le monde. Le thème de la soirée est "L'ergonomie des applications Android et 2 présentations seront faites.
La soirée commence par un rapide tour de présentation où chacun expose en quelques mots qui il/elle est et le but de leur présence ce soir. En grande majorité, les gens sont des développeurs Android mais aussi quelques curieux. qui viennent pour découvrir Android. Quant à la principale motivation à assister à la soirée, elle est tout simplement de venir à la rencontre de la communauté.

1ère partie :

La première présentation commence avec Nicolas Chambrier, consultant/architecte chez Clever Age, qui vient nous parler de la mise en place de la Quick Action Popup.
Il y a quelques mois de cela, Google a réalisé pour Twitter un client Android. Cette application a marqué les esprits pour son aspect design et ergonomie. Alors qu’Android était critiqué pour ses interfaces “moches”, Twitter for Android arrive et se présente comme un modèle à suivre. Bien que Google ait annoncé qu’elle serait open-source, on attends toujours ….
Ce modèle suit 3 grands principes :

• Action bar : A la place de la barre fine de titre, une barre plus épaisse qui contient les actions auxquelles l’utilisateur aura souvent accès. Pour les actions secondaires, profitons du fait qu’un Android contrairement à un IPhone possède un bouton menu. Il y aussi la touche “search” qui est un peu particulière. Elle sert à indiquer à l’utilisateur qu’une recherche est disponible dans l’application. Il aussi recommandé de rendre cette recherche accessible depuis le bouton “Rechercher” du téléphone. A ce propos, attention car bien qu’il soit disponible sur beaucoup de modèle, ce bouton est facultatif. Le Samsung Galaxy S par exemple n’en possède pas.
• Quick Action Popup : C’est un menu contextuel. Pourquoi pas de menu classique ? Tout d’abord parce que c’est plus joli mais aussi par ce que c’est moins encombrant et qu’au niveau visuel c’est moins stressant. Par contre, inconvénant : c’est plus complexe à mettre en place car ce type de composant n’existe pas dans Android.
• Voir toutes les zones de l’application : l’écran d’accueil de l’application affiche les différentes Activity. La navigation se retrouve ainsi simplifiée.

Même si Google propose des idées sur la façon d’organiser, il ne donne pas vraiment de conseils sur la façon de faire.
Il faut aussi savoir prendre du recul, joli est différent d’ergonomique : une application joli peut ne pas être du tout ergonomique et inversement. De plus nos applications n’ont pas forcément les mêmes besoins. Avant de se lancer, il faut bien réfléchir à comment rendre facile l’accès au différentes Activity et ne pas hésiter à crayonner sur papier ses idées.
La théorie, c’est bien beau, mais qu’en est il en pratique ? Nicolas nous livre maintenant un retour d’expérience sur son application : Horaire TER SNCF.
Elle a eu une refonte graphique complète en adoptant certaines des propositions. Cette refonte a été faite avec l’aide d’un designer qui comme pour une maquette web a réalisé un psd. Il ne restait plus qu’à découper cette maquette pour intégrer les images. Cette refonte adopte aussi les Quick Action Popup.
L’idée de ces Quick Action Popup, c’est de pouvoir mettre en place derrière un système de plug-in, pour étendre l’application, au cas où l’application remporte un immense succès. Le plus simple et de commencer par implémenter un simple menu. Il faut aussi se demander si c’est applicable, c’est vrai que c’est joli, mais si le reste est moche ….
Le mieux est de commencer par implémenter par un contextuel, quand c'est ok on fait les QAP.
Il faut aussi se demande sir c'est applicable. C'est joli mais si le reste est moche ….
Reste à voir comment implémenter. Et là, Google n’aide pas . Il faut donc aller voir du coté des initiatives personnelles :

• WHSFinder
• Simple Quick Action : Plus détaille et bon choix pour s’inspirer
• Lorenz
• DevoTeam Quick Actions : inspiré par WHSFinder, mais avec une doc
• Horaire TER SNCF, l’initiative de Nicolas

Pourquoi donc a t-il ré-inventé la roue ?

En réalité, ce n’est pas si compliqué à développer, une cinquantaine de lignes de code suffisent. Une autre raison est le besoin spécifique par rapport au système de plug-in.
Il y tout de même des contraintes : il faut des compétences graphiques et le layout est limité à un background.
Pour intégrer, c’est très simple, il suffit d’incorporer le jar dans son projet. Un peu de code suffira pour faire le reste.
Il existe aussi d’autres ressource comme GreenDroid de Cyril Mottier.

Les slides :

http://www.slideshare.net/naholyr/paris-android-user-group

2ème partie :

Pour cette partie, c’est Ludovic Perrier, qui nous parle d’Ergonomie et Design sur Android.
Cette présentation se veut très générale, il n’y aura pas de code, juste quelques règles et du bon sens que l’on acquière en développant. Tout cela est extrait de son livre en cours de rédaction. Ce dernier est co-écrit avec Cyril Mottier et devrait être disponible en fin d’année chez DigitBook.
Pourquoi faut il s’attacher au design et à l'ergonomie ?
Tout simplement pour rendre l’application utilisable. Il ne faut pas perdre de vue qu’il faut garder le look&feel Android. On voit parfois des applications qui possèdent un bouton retour tout comme une application Iphone... Ce qui ne sert à rien, un téléphone Android possède un bouton retour. L’utilisateur peut être exigeant et vouloir la même application que sous IPhone, il n’est pas toujours évident de lui faire comprendre que ce n’est pas ce qu’il de mieux pour l’application.
Coté lanceur d’application, Google a très peu évolué ses roms depuis le début. Les roms constructeurs quant à elles proposent parfois un modèle assez différent. Samsung propose par exemple pour son Galaxy S un fonctionnement assez IPhoneLike avec son défilement horizontal.
Coté navigation matérielle, c’est assez hétérogène, on peut ainsi trouver : clavier physique, trackbal, trackpad, tactile, bouton physique optionnel, ….
Ce sont des facteurs auxquels il faut prêter attention : le trackpack ne possède pas de diagonale, sous certains modèle la pression sur 2 boutons en même temps ne fonctionne pas, bouton “rechercher” est facultatif, les boutons ne sont pas toujours placé au même endroit. D’où l’importance dans ce dernier cas de laisser la possibilité à l’utilisateur de paramétrer les boutons si l’on s’en sert (cas d’un jeu).
Il est important d’aller à l'essentiel, de fournir uniquement ce dont l’utilisateur a besoin. Pour les autres besoins, il est toujours possible d’utiliser des boutons d’actions. Les splash screens, c’est pour iOS, sous Android, il existe d’autre technique, comme un chargement en arrière plan.
Et pour finir quelques règles d’or :

• L’utilisateur doit pouvoir annuler une action, il faut donc faire des requêtes annulable. En effet, si l’on lance une action dont on ignore l’action, il est assez gênant ne peut pas pouvoir la stopper.
• Le mode plein écran est déconseillé : il ne faut pas oublier que notre application n’est pas seule. Il faut penser au notification que laisse les autres comme par exemple : réception d’un mail ou d’un sms.
• A partir d’environ 4 activités, un écran dashboard est conseillé, c’est moins fouillis.
• Il faut adapter l’interface à chaque état (selectionné, pressé, focus, ….). Ainsi, l'utilisateur se rends mieux compte de ce qu’il fait.
• Le scroll est une action assez lassante, il ne faut pas trop en abuser. Mieux vaut sectoriser si l’on a beaucoup de données.
• Une application intuitive n’a pas besoin d’aide. Qui n’a jamais été agacé par le trombone de Word ?
• Il faut penser à M Tout le monde, se mettre à sa place. Il est difficile de faire une application qui plaît à tout le monde.

Les slides :

https://docs.google.com/present/view?id=0AessGL44h9tEZGdzdzY3YmNfMjgwY2ozNDRtZms&hl=en&authkey=CP2draQK

Comme beaucoup d’évènements, c’est autour d’un pot que se termine la soirée. Il sera la scène de diverses discussions comme la possibilité de créer un évènement semblable sur Lyon, les widget; ou encore des démonstrations d’une application de réalité augmentée de chez DiotaSoft.

Pour ceux que ça intéresse, voici le google group :

http://groups.google.com/group/paris-android-ug

Retour sur le Paris JUG d'Octobre

Ruby On Rails - Point de vue d'un javaiste

Cette 1ère partie nous est présentée par Christian Blavier de chez Octo.
Java, c'est plein de belles promesses. C'est comme un hamburger plein de beaux ingrédients mais tellement que ça peut en devenir écoeurant : trop de couches, trop d'abstraction, on s'éloigne trop du html, ...
Ruby On Rails quant à lui est optimisé pour le plaisir des développeurs, c'est plein de bonnes idées.
On y retrouve une architecture MVC.
Etant basé sur Ruby, on y retrouve certaines facilités comme la manipulation de dates, les closures, ...
C'est aussi un framework fait pour le web :

• Quelques lignes suffisent pour y déclarer notre contrôleur. Si on souhaite du JSon, il suffit de l'indiquer, pas besoin de framework.
• Templating web : des gems comme ham et sass donne des facilités respectives en html et css
• Routage : Pour avoir des urls type REST, 1 seule ligne suffira dans le fichier de configuration de routage
• Active Record : Gère la persistance directement dans le modèle.

C'est aussi un framework fait par des agilistes pour les agilistes. Le test est au coeur du développement et il existe un outillage important pour aider dans la testabilité. Parmis eux : Mocha, Girl Factory, Time Cop, Cucumber, ...
Pour le déploiement, Heroku offre une plateforme qui permet de déployer gratuitement son application; et ça en une ligne de commande.

HTML5

Pour la deuxième partie, c'est Alain Duval et Cédric Beurtheret de Objectif Informatique.
La présentation démarre avec un rappel de la Genèse de Html5 puis un rappel de ses principales fonctionnalités.
Ils nous livrent aussi un retour d’expérience projet.
Au début, ils avaient utilisé Gears puis sont passé à html5 quand ce fut possible. Leur application est destinée à gérer la relation clientèle pour des commerciaux équipés de tablet pc possédant une connectivité 3g. Un zoom est fait sur 3 fonctionnalités :

• Web worker : C'est une API pour lancer une tâche de fond sans bloquer le navigateur.
• Cross window messaging : permet à deux fenêtres de communiquer entre elles, même si elles ne sont pas sur le même domaine.
• Web storage : du stockage de données locales dans le navigateur. Il est possible de travailler en mode synchrone ou asynchrone, mais la 2ème option est recommandée car plus performante. Par contre attention à la sécurité de vos données, la base locale ne permet pas l'utilisation d'identifiants.

Et pour finir, nous avons le droit à une belle démo dédiée au JUG montrant ces 3 fonctionnalités : une page qui affiche des message twitter. Les messages sont récupérés par une web worker et stockés en base locale le tout avec une fenetre de log gérée par le cross window messaging. Pour montrer le bon fonctionnement, quelques personnes envoient des tweets qui apparaissent sans avoir à rafraîchir la page.

Play!

Et pour la dernière partie, c'est au tour de Nicolas Martignole et de Guillaume Bort.
Play est un framework qui fait de plus en plus parler de lui que ce soit sur les blog mais aussi dans des conférences comme Jazoon et même JavaOne.
Tout d'abord, il faut savoir que Play! n'est pas basé sur l'API Servlet qui est comme une muti-prise sur laquelle on a branché un tas d'appareils successivement.
L'analogie du McDo est prise comme exemple : là bas, vous faites la queue jusqu'à ce qu'une équipière prenne votre commande puis court dans tous les sens pour vous la préparer et vous l'apporter. Pendant ce temps là, elle ne peut pas prendre d'autre commande
Par contre, Play! c'est comme Starbuck. Les commandes ne sont pas prises par ceux qui préparent ce qui permet de répondre rapidement à une demande client.
La philosophie de Play! est assez proche de celle de Grails avec quelques fonctionnalités en moins comme les finders dynamiques.
On va avoir une url propre (ex : http://www.express-board.fr/user/sfeir/27) fini tout ces paramètres uniquement techniques. Une url se doit d'être lisible, bookmarkable et partageable.
Si on veut pouvoir monter en charge sans devoir mettre en place de réplication de session, le serveur doit être stateless. C'est à sens que les informations de session sont stockées dans le navigateur dans un cookie crypté de seulement 3Ko.
Play! n'est pas client side, c'est pourquoi son ihm se sert des langages du web : html/css/js
C'est comme un couteau suisse, c'est fullstack.
Là où en java, on a l'habitude d'une certaine complexité liée à l'intégration de différents frameworks entre eux, Play! propose de prendre le problème différemment. Un problème compliqué a t il besoin d'une solution compliquée ?
Play aide à la productivité en ayant un serveur sans état : pas besoin de le redémarrer pour ajouter/retirer des fonctionnalités, lorsqu'une erreur se produit en mode dev, elle s'affiche lisiblement dans le navigateur, ...
Et cela s'illustre dans la démo, en quelques minutes et très peu de code Guillaume contruit un formulaire pour ajouter des éléments à une liste de todos, et ce juste avec un éditeur de texte et aucun redémarrage. Tout cela est possible parce que Play ne se base pas les fichiers .class mais sur les fichiers .java.

Fastcall Android

A Sfeir, nous aimons la technologie, et Android en fait évidement parti.
J'ai développé avec mon collègue Clément Griffoin une application basée sur une idée de celui qui est à la fois notre directeur technique et notre directeur des opérations : Didier Girard. Lorsqu'on a beaucoup de contacts dans son répertoire, il devient fastidieux de retrouver celui que l'on veut : que de mouvements de pouces de bas en haut pour faire défiler sa liste.
Fastcall vous propose d'en écomiser !
Confucius disait qu'une image vaut mille mots, je vous épargne un long discours pour vous en expliquer le principe :



Et voilà, en 3 coups de pouces, nous pouvons appeler notre ami Blaise Lucas bien qu'il soit l'un de nos 1000 contacts téléphoniques.

Si vous souhaitez tester notre application :



Puisque nous aimons et croyons en l'open source, cette application est bien sûr soumise à ce principe :

http://code.google.com/p/fastcall-android/

Nous sommes donc à l'écoute de vos propositions, problèmes rencontrés, ...

Et pour les twittos, suivez la.

Konami GWT

Connaissez vous le code Konami ?
Il s'agit d'un code spécial utilisé dans de nombreux jeux de l'éditeur de jeux video Konami. Pour accéder à des options secrètes, il fallait effectuer la séquence suivante sur sa manette : haut, haut, bas, bas, gauche, droite, gauche, droite, b, a. Pour plus d'infos, je vous laisse lire l'article wikipedia.
Vous ne voyez pas le rapport avec GWT ? J'y viens... Certains développeurs web ayant été bercé par ces jeux dans leur enfance ont eu l'idée d'incoporer ce code dans leur site. C'est ainsi que nous les retrouvons sur certains sites que vous connaissez : free.fr, Google Reader, JQuery, ... (essayez, vous verrez) Parmis eux on retrouve bien sûr http://konamicodesites.com où l'execution de ce code est indispensable pour accéder à son contenu.
Pour déctecter l'exécution de ce code, il faut donc surveiller quelles sont les touches appuyées. C'est en javascript que celà se fait. Nous y voilà, personnellement, je préfère l'utilisation de gwt à celle de javascript. Je vous propose de voir comment nous pourrions l'implémenter. Lorsque l'utilisateur va effectuer la séquence de touches, une action devra être déclenchées. C'est le principe d'un handler. Nous aurons donc une interface de ce type :

/**
 * Handler for the Konami Code.
 * @author Nicolas François
 *
 */
public interface KonamiHandler {
        
        /**
         * Call when the konami code is performed.
         */
        void onKonamiCodePerformed();

}

Ensuite on va devoir surveiller les touches au niveau de la plage. Le principal problème est qu'il n'existe pas de de handler à rattacher au niveau de la page. comme on peut On en trouver sur un TextBox. On va donc s'intéresser aux évènements natifs du navigateur, les NativePreviewEvent. Pour cela, nous allons implémenter l'interface NativePreviewHandler. Celle ci, va réagir à l'ensemble des événements navigateur : aussi bien les touches clavier et la souris, mais aussi tous les évènements comme le onload, onblur, onchange, ... D'autre part, nous allons devoir si les dernières appuyées pressées correspondent à la séquence. Pour celà, nous allons enregister les dernières saisies sous forme de chaine ascii, la comparer à la séquence voulue et si elle est bonne appeler la méthode de notre handler. Ce qui nous donne :

/**
 * Konami code monitor.
 * 
 * @author Nicolas François
 *
 */
public class Konami {

        /**
         * The konami code sequence in ascii.
         */
        private final static String KONAMICODE_SEQUENCE = "38384040373937396665";
        
        private final KonamiHandler konamiHandler;
        private String lastInputs = "";
        
        
        /**
         * Constructor with the konami handler.
         * @param konamiHandler
         */
        public Konami(KonamiHandler konamiHandler){
                this.konamiHandler = konamiHandler;
        }

        /**
         * Start the konami code execution monitoring. 
         */
        public void start(){
                final NativePreviewHandler nph = new NativePreviewHandler() {

                        @Override
                        public void onPreviewNativeEvent(NativePreviewEvent event) {
                                if(event.getTypeInt() == Event.ONKEYDOWN){
                                        lastInputs+= event.getNativeEvent().getKeyCode();
                                        if(lastInputs.length()>KONAMICODE_SEQUENCE.length()){
                                                lastInputs = lastInputs.substring(lastInputs.length()-KONAMICODE_SEQUENCE.length());
                                        }
                                        if(KONAMICODE_SEQUENCE.equals(lastInputs)){
                                                lastInputs = "";
                                                konamiHandler.onKonamiCodePerformed();
                                        }
                                }
                        }
                };
                Event.addNativePreviewHandler(nph);
        }               
}

Bien sûr, cette action n'est pas du tout évoluée, c'est à vous de libérer votre imagination.
Je vous propose cette implémentation avec konami-gwt. Si vous souhaitez l'utiliser dans votre projet gwt, il vous suffit de déclarer son module dans votre fichier *.gwt.xml.

Mvp4g

Depuis la conférence Google I/O 2009, le pattern architectural MVP fait parler de lui à un point où un grand nombre de framework open source s’est répandu, chacun proposant son implémentation plus ou moins élaborée. Tous contiennent au moins la gestion du présenteur et ensuite on y trouve ou non un event bus, une gestion de l’historique, injection de dépendances, pattern action, ....

C’est sur google code que j’ai découvert Mvp4g qui couvre une bonne partie de ses fonctionnalités.

Pour vous le faire découvrir, nous allons reprendre le code de l’application de gestion de contacts de l’article de google sur le mvp :

Pour cet exercice , nous prendrons la dernière version de mvp4g qui vient l’être releasée ainsi que de ses dépendances :

• mvp4g-1.2.0
• commons-lang 2.4
• commons-configuration 1.6
• gin 1.0
• guice 2.0
• aop-alliance.

Comme pour n’importe quel bibliothèque gwt, il faut la déclarer dans notre fichier gwt.xml :

<inherits name='com.mvp4g.Mvp4gModule' /> 

Maintenant, faisons un tour d’horizon des modifications que nous allons devoir apporter :

• La partie Model ne changera pas : Mvp4g ne couvrant pas l’Action pattern, nous ferons appel au méthodes exposée en rpc tout comme dans le code original.
• La partie Presenter, elle sera une des parties qui changera le plus : nous devrons étendre une classe du framework et répondre à son contrat.
• La partie View ne changera que très peu : nous n’aurons qu’à changer l’interface implémentée.
• L’Event Bus : un des autres gros changement. Mvp4g propose en effet son propre modèle avec un système d’évènements haut niveau assez souple.
• La gestion de l’historique, là aussi tout est à refaire.
• L’Entry Point : Avec mvp4g, nous n’avons pas forcément besoin d’en écrire un ...

A cela, nous rajouterons une injection de dépendances via gin qui n’est pas dans le code original. C’est aussi dans cet esprit que se configure mvp4g. Que ce soit pour lier les différents composants ou spécifier le comportement dus bus ou de l’historique. Elle peut être soit réalisée en xml ou par annotations. J’ai préféré l’utilisation des annotations.
J’imagine que le point sur l’entry point, vous a laissé perplexe mais attention ce n’est pas parce que nous n’allons pas en écrire un que nous n’en aurons pas. C’est justement parce que l’application s’assemble en fonction des annotations que cette partie peut devenir générique. Nous utiliserons donc celui que nous propose mvp4g en incluant cette ligne dans le gwt.xml :

<entry-point class='com.mvp4g.client.Mvp4gEntryPoint' /> 

Pour les plus curieux, voici le code qui y correspond :

Mvp4gModule module = (Mvp4gModule)GWT.create( Mvp4gModule.class );
module.createAndStartModule();
RootPanel.get().add( (Widget)module.getStartView() );

Et c’est tout. Le code étant assez simple, il se comprend de lui même. Tant que nous n’aurons qu’un seul module gwt, il nous sera suffisant.
Passons maintenant au centre névralgique de notre application : le bus évènementiel. Dans une application mvp4g, il est indispensable. C’est bien sûr par lui va passer la distribution des événements haut niveau mais aussi quelques autres notions liées comme la gestion de l’historique et surtout l’action “start”.
A 3ème ligne de l’entry point, vous aviez sans doute remarque le getStartView. Il n’y a rien de magique, c’est par la configuration du bus que nous la connaîtrons.
Allez, mettons nous en route , pour coder notre bus. En fait, nous n’aurions rien à implémenter puisqu’il s’agit d’une interface. Elle devra néanmoins étendre l’interface EventBus de mvp4g et être annotée :

@Events( startView = RootView.class) 
 public  interface  ContactsEventBus extends EventBus { 
 
 } 

C’est sur l’annotation @Events que nous définissons RootView en tant que vue chargée s’affichant au démarrage. Fidèle à son nom, elle sera notre vue racine. Mvp4g conseille de disposer d’une telle vue qui servira de container aux autres vues. Comme toute vue dans un modèle MPV, elle sera statique et sera associée à un présenteur. L’interface qui servira de contart avec le présenteur sera celle ci :

public  interface RootViewInterface { 
      Panel getBody(); 
 } 

et l’implémentation sera la suivante :

public  class RootView   extends   Composite    implements  RootViewInterface { 
 
    private   SimplePanel body = new SimplePanel(); 
 
    public RootView() { 
        VerticalPanel mainPanel = new VerticalPanel();
  mainPanel.add(body); 
  initWidget(mainPanel); 
    } 
 
    @Override 
    public Panel getBody() { 
        return body; 
     } 
 
 } 

Le présenteur quant à lui sera de la forme suivante :

@Presenter( view = RootView.class ) 
  public  class RootPresenter    extends   BasePresenter<RootViewInterface, ContactsEventBus> 

Là encore, nous avons du code assez simple à comprendre . Nous annotons le présenteur pour qu’il puisse être détecté par mvp4g et étendons la classe BasePresenter<V, E extends EventBus> pour nous permettre d’interagir avec la vue mais aussi avec notre bus. De la même manière, nous aurons : un ContactsPresenter et un EditContactPresenter avec des vue telle qu’on les a dans le code original.
Nous avons déjà la base de notre application mais pour l’instant, elle ne fait rien. Dans notre cas, nous voudrions qu’au lancement, la liste des contacts soit affiché. Tiens, nous tenons un évènement haut niveau et nous voudrions qu’il soit lancé au lancement... C’est encore une fois le bus qui va s’en occuper, encore un fois par une simple annotation.
Puisque nous voulons lister, nous allons créer un évènement “list” tout simplement. A la différence du mvp proposé par google dans l’article, nous n’aurons pas à créer une classe héritant de GwtEvent et de lui associer une handler. Nous allons seulement ajouter une méthode qui porte le nom de cet évènement à l’interface de notre bus :

@Start 
@Event(handlers = ContactsPresenter.class) 
void list(); 

C’est grâce à l’annotation @Start que l’évènement sera lancé au lancement client de l’application et sera délégué à notre ContactPresenter. A noter que dans notre cas, nous n’avons qu’un seul handler. Il aurait été tout à fait possible d’en avoir plusieurs en les séparant par une virgule.
Il nous reste à implémenter la réaction du présenteur face à cet évènement. Le modèle évènementiel de mvp4g repose sur une convention simple : pour un méthode XXX du bus, le présenteur devra implémenter une méthode onXXX tout simplement. Bien qu’il ne soit pas possible à s’assurer de la concordance entre l’évènement est sa méthode réceptrice lors de la compilation java, ce contrôle est réalisé lors de la phase de compilation gwt.
Revenons à notre cas, nous aurons donc une méthode onList() dans notre ContactsPresenter :

public  void   onList(){ 
 
    contactsService.getContactDetails(  new AsyncCallback<ArrayList<ContactDetails>>() { 
 
  @Override 
  public  void   onSuccess(ArrayList<ContactDetails> result) { 
   doList(result); 
  } 
  
  @Override 
  public  void   onFailure(Throwable caught) { 
   eventBus.errorMessage(ErrorMessages.RPC_CALL_FAILED); 
  } 
 
    }); 
 
 eventBus.changeBody(view.asWidget()); 
 
 } 

Pour déclencher un évènement haut niveau, il suffit d’appeler la méthode associée du bus. C’est ce que nous faisons par exemple avec le changeBody qui permet à la vue ContactView de devenir active.
Nous pouvons aussi transmettre une valeur ou plusieurs valeurs lors du déclenchement de l’évènement. Nous rencontrons ce cas pour l’édition :

@Event(handlers = EditContactPresenter.class) 
void   edit(  String id); 

Vous avez aussi sûrement remarqué, l’appel au service rpc. Sa déclaration est très simple, nous utiliserons l’injection GIN par une simple annotation sur son setter :

@Inject 
public void  setContactsService(ContactsServiceAsync contactsService) { 
 this.contactsService = contactsService; 
} 

Quant à la phase de binding des événements bas niveau par les présenteurs, elle est est analogue à celle du code original : nous n’aurons qu’à implémenter la méthode bind().
Nous aurons par exemple :

view.getAddButton().addClickHandler(new ClickHandler() { 
    public  void   onClick(ClickEvent event) { 
  eventBus.add(); 
 } 
}); 

Si vous avez peur de ne pas savoir où vont vos évènements, l’annotation @Debug sur le bus vous aidera en loggant en console ce qui se passe autour du bus. Il existe 2 modes de LogLevel : SIMPLE et DETAILLED, par défaut ce sera la première valeur. Regardons ce qui se passe dans les 2 modes sur un évènement edit .
Tout d’abord en mode simple :

16:47:05.355 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: edit || param(s): 18
16:47:06.551 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: changeBody || param(s): [...plein de html...]

et en mode détaillé :

16:50:53.187 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: edit || param(s): 18
16:50:53.751 [INFO] [contactsmvp4g] com.sfeir.contacts.client.presenter.EditContactPresenter@640782 handles edit
16:50:54.052 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: changeBody || param(s): [...plein de html...]
16:50:54.058 [INFO] [contactsmvp4g] com.sfeir.contacts.client.presenter.RootPresenter@16e4f00 handles changeBody

Intéressons nous maintenant à l’historique. Mvp4g utilise la notion de convertisseur d’historique. Ce qui signifie que nous devrons implémenter la façon dont les évènements seront convertis en url et vice et versa. Nous allons devoir implémenter l’interface HistoryConverter<E extends EventBus> et comme toujours l’annoter. Notre application étant relativement simple, nous n’en aurons qu’un seul mais sachez qu’il est tout à faire possible d’en avoir plusieurs. Pour répondre à son contrat, nous devrons implémenter les 2 méthodes suivantes :

• convertFromToken( String eventType, String param, E eventBus ) : réaction lors d’une url tokenisée.
• isCrawlable() : indique si le l’url sera crawlable en renvoyant un booléen.

La gestion de l’historique viendra se greffer sur le bus événementiel. Pour gérer l’historique, nous rajouterons :

@Events( startView = RootView.class,  historyOnStart = true ) 

Réfléchissons d’abord un peu. Sur quoi aimerions nous avoir une historique avec des urls identifiables ? J’en vois 3 :

• La liste des contact
• Ajout d’un contact
• dition d’un contact. Idéalement, il serait intéressant d’avoir un paramètre permettant d’identifier le contact que nous éditons.

Le modèle d’historique de mvp4g utilise un token situé après un "#" dans l’url. Ce token correspond tout simplement au nom de l’évènement. Nous avons aussi la possibilité d’assigner un valeur à ce dernière en le placant derrière un "?".

Exemple : #token?value

Cette solution convient à notre exigeance de mieux marquer l’url lors de l’édition d’un contact . Pour lier, un évènement à notre convertisseur d’historique, il suffit de lui assigner sur le bus :

@Start 
@InitHistory 
@Event(handlers = ContactsPresenter.class,   historyConverter=ContactHistoryConverter.class ) 
void list(); 

L’annotation @InitHistory sert à marquer quand l’historique doit être initialisé. Celle est obligatoire si vous voulez utiliser l’historique. Revenons à notre convertisseur :

@History 
public  class   ContactHistoryConverter   implements HistoryConverter<ContactsEventBus> { 
    @Override 
 public  void convertFromToken(  String   eventType,   String param, ContactsEventBus eventBus) { 
  if (“edit”.equals(eventType)){ 
   eventBus.edit(param); 
  } else if (“add”.ADD.equals(eventType)){ 
   eventBus.add(); 
  } else if (“list”.equals(eventType)){ 
   eventBus.list(); 
  } 
    } 
 
 @Override 
 public  boolean isCrawlable() { 
  return   true; 
 } 
} 

La première méthode est assez claire : nous appelons la méthode correspondante au token avec une particularité pour edit où nous nous servirons de la valeur en paramètre du token comme paramètre edit.
Même si l’IDE ne signale aucune erreur, la compilation gwt en provoquera. Il nous faut la réciproque de la méthode convertFromToken : c’est à dire indiquer quelle sera la valeur du paramètre d’un token. Ainsi, pour chaque évènement XXX historisé , il nous faudra une méthode onXXX qui renvoi une valeur sous forme de chaîne de caractères. Nous aurons ainsi par exemple :

public  String   onEdit(  String id){ 
 return id; 
 } 

public  String   onList(){ 
 return ""; 
} 

Un reproche possible à faire à mvp4g est
Un des reproches possible à faire est l’assemble dynamique et instanciation des composants. Nous n’avons pas toujours besoin d’en disposer au moment au l’ont accède à l’application. Dans notre cas, nous n’avons pas besoin d’édition d’un contact tant que n’a pas cliqué sur un contact. Rassurez vous, la construction paresseuse est là. Pour cela, nous allons changer la super classe pour LazyPresenter<V extends LazyView, E extends EventBus>. En plus de cela, notre interface de vue devra étendre l’interface LazyView. Cela va perturber un peu notre code et des erreurs de compilation vont s’inviter. Avant de les corriger, intéressons nous à la classe LazyPresenter et en particulier sa méthode bind()

final  public  void bind() { 
 view.createView(); 
 createPresenter(); 
 bindView(); 
} 

Voilà la clé de nos corrections :

• Les constucteurs de vue et de présenteur deviendront respectivement createView() et createPresenter()
• La méthode bind() du présenteur deviendra bindView()

Personnellement, j’ai remarqué qu’après ses modifications, le lancement était plus rapide.
Le principal avantage d’un découpage mvp est la testabilité. Notre présenteur étant décorélé de problématique d’affichage, il sera alors plus simple de le tester. En effet, en mockant la vue, les services et le bus, nous pourrons nous concentrer nos tests sur la logique métier. De plus avec le système évènementiel haut niveau de mvp4g, il est simple de tester la réception d’un événement.
Un aspect qui peu rebuter les plus intégriste du modèle mvp est la gestion évènement de haut niveau spécifique de mvp4g et principalement ses performances. Quelles sont elles ? Le wiki du projet répond à cette question :

Les performances semble honorables. Bien sûr, tout produit vante ses performances, mais bon joueur les tests sont disponibles.
La question à se poser avant tout est de savoir ce que l’on teste exactement. En observant le code, on voit qu’un évènement est lancé est attrapé par son réceptacle. Rien de plus. Pour éviter un conflit entre les deux, un test se fait en temps : d’abord mgp4g puis gwtEvent.

Pour la partie benchmarking, j’ai réalisé depuis le lien appspot les même tests sous 3 navigateurs dans leur version courante :

• Chrome 6
• Internet Explorer 8
• Firefox 3.6

Mes résultats diffèrent, mais attention cela ne signifie pas les résultats sur la page mvp4g sont faux. En effet, pour avoir reproduit ces même tests sur différentes machines possédant le même navigateur, j’obtenais des résultats avec une différence assez importante (jusqu’à x 10 entre un bon pc fixe et un simple netbook) :
Voici mes résultats pour 1000 évènements lancé :

	mvp4g	gwt
Chrome 6	31	122
Internet Explorer 8	477	3609
Firefox 3.6	206	312

Ces résultats vont dans le même sens, c’est à dire que le modèle événementiel de mvp4g est plus rapide que celui de gwt.
Bien sûr, GWT 2.1 va arriver avec son modèle MVP intégré. Quand il sortira, on pourra re-comparer les temps de réaction événementielle. En attendant, sa sortie vous pouvez vous amuser au mpv avec mpv4g, qui propose bien d’autres fonctionnalités encore comme les filtres d’évènements, la gestion du multi-module, ....

Sophiaconf 2010 - Ruby On Rails

En tant que développeur java, il est important de regarder de temps à autre ce qui se fait chez les voisins afin de ne pas rester sur une certaine vision, voir comment une problèmatique se résoud dans une autre communauté.
Rails aura 2 conférences, une pas technique et l'autre technique.

Pourquoi Rails est génial ?

La première partie est faite par Camille Roux, jeune développeur qui pratique le développement Ruby depuis 1 an et a 3 ans de développement web derrrière lui. Pour les plus curieux, son site perso : http://www.camilleroux.com
Une question importante de se poser avant tout est : Qu'est ce qu'un bon framework ?
Camille nous présente un nuage important de critères, parmis eux : pas cher, rapide à développer, utilisé par beaucoup de monde, sécurisé, ...
Rails répond à tout ces critères.

Le langage à la base de Rails est Ruby, un langage interprété, multiparadigme (aussi bien object que procédural). Ruby a été crée pour être "un langage pour les hommes, pas pour les machines". En plus d'être multiplateforme, il est aussi multi-implémentation :

• Ruby, la plateforme de base
• JRuby, pour nous les développeurs java qui voulons réutiliser toutes nos bibliothèques
• Rubinus, plateforme très prometteuse

Quelques chiffres sur Ruby :

• 14 000 gem (librairies pacakgé et facile à utiliser)
• 185 000 projet sur github
• 10 ème langage le plus utilisé

Ruby est assurement un langage incontournable.
Ruby On Rails est un framework basé sur ce langage. On peut l'appeler ROR ou Rails pour les intimes. Ce framework a été initié par un développeur au nom imprononcavle que toute la communauté nomme DHH.
Rails posséde une philosophie basé sur le fameux "convention over configuration". On ne veut pas passer du temps du temps sur la config de divers fichiers (parce que c'est assez chiant à faire), on préfère obéir à des conventions comme nommer sa table de la même façon que son objet par exemple. Un point de cette philosophie est l'agilité : on aime le déploiement facile, et l'abondance de test.

Qu'est ce qui est si génial en Rails ?

• Projet construit : on ne se casse pas la tête. Un autre avantage est qu'il sera plus facile à intégrer un nouveau developpeur car il connait déjà les conventions.
• Migration : on créer un classe qui décrit les tranformations
• Active record : les méthodes d'opérations comme save sont appelées sur l'objet lui même
• Scafolding : Génération de code MVC. Très pratique pour une développer rapidement et facilement une interface d'admin
• 
  Environnement : Rails permet d'en définir facilement plusieurs : test, dev, prod, autant qu'on veut... On peut aussi avoir des gems spéciaux pour un env (test par exemple, log différents, base différente bien sûr, ...)
  
• 
  Sécurité : il est facile d'ajouter de la sécurité à son application rails
  
• Javascript : Prototype est disponible. Rails donne une certaine abstraction dans l'utilisation de javascript, il est pa exemple possible de faire un bouton de rafraichissement sans faire de javascript, rails le gère pour nous.
• Test : Avec Rails la partie test est très importante et fait parti du projet. Une partie des tests sont générés à la création du projet. Rails permets d'avoir du code testable tout au long du projet.

D'ici environ un mois, sortira Rails 3 :
Rails 3, c'est la fusion de Rails 2 et de Merb
Cette fusion des 2 projets donne un résultat très confortable au développement.

Au programme de cette 3 ème version :

• Modularité
• Bundles
• Performance
• Support du html 5

Certains reprochent à Ruby d'être lent. Qu'en est il vraiment ?
Il faut d'abord savoir qu'il y a beaucoup de benchmark qui disent beaucoup de choses, et sont parfois contradictoire. Selon de bons benchmark, il serait à la hauteur de python et de php.
Mais les performances sont elles vraiment si importantes ?
Après tout, ce qui est le plus important, c'est la vitesse de développement, la fiabilité, la facilité de maintenance. De plus, Ruby est soutenu par une communauté. On peut ainsi trouver un gem pour chacun de ses développement.
La forte présence de cette communauté permet un appentissage facilité par des forms, des tutoriaux, des screencast, des conférences comme celle çi, et bien sûr des livres

Qui utilise Rails ?

Beaucoup de sites, dont Yellow Pages (les pages jaunes américaines), White Pages, Brightlite, Github, ....
Notons que la plupart de ces sites, sont à fort traffic et que rails tient la charge.
Il y aussi des entreprises comme Amazon qui dont du ruby, même si on ne sait pas vraiment ce qu'il en font.

Au niveau hébergement, il y a aussi de bons services cloud :

• Engine Yard : Permet de déployer sur Amazon EC2 et S3, de redimensionner à chaud le volume de machine. Pour déployer, il suffit de lui indiquer où est le repository github du code. Il permet aussi de faire le suivi de l'activité et de faire des backup
• Heroku : 2 lignes de commandes suffisent à déployer gratuitement. Lors du déploiement, il s'occupera de télécharger les gems et leur dépendances. On pourra aussi régler le volume de machines ou s'occuper de la configuration des machines. Bien sûr, toutes les possibilités ne sont pas toutes gratuites.

Et pour le suivi de votre application, New Relic s'occupe du monitoring.

Exemple d'un succès de Rails :

Yellow Pages, un site web à très fort traffic : 1500 req/sec.
Il y a quelques années, ils étaient en JavaEE avec des EJB et connaissait des problèmes de design et de scalabilité. Le code était de 125 000 lignes et ne contenait aucuns tests.
En 2007, ils ont adopté Rails et ont refait entèrement leur site avec.
Pour des performances égales, leur code est passé à 20 000 lignes en comptant les tests.
Cette refonte, a pris 3 mois avec une équipe de 5 développeurs.
Rails est un framework qui plait, c'est d'ailleurs pour celà qu'il est copié : Grails ou Play!
Dans la salle quelques retours disent qu'ils n'est pas facile de faire du Ruby/Rails sur Windows. Git ne facilite pas non plus le problème.

Camille nous dira que Git n'est pas tout obligatoire, mais qu'il s'agit d'un produit que la communauté ruby adore.
Et pour finir, selon Camille, être développeur Ruby, c'est comme être un guerrier avec un sabre laser : ce sont des passionnés qui en font et qui font vivre.

Acte 2

Pour la 2ème partie de double présentation, c'est au tour de Maxime Menant de s'y coller. Jeune aussi, développeur de 25 ans et qui travaille avec Camille. Il nous fait aussi part de l'adresse de son blog : http://blog.maximemenant.fr
"On vous a dit pourquoi c'est génial, maintenant on va vous le montrer"

Ruby qu'est ce que c'est ?

• Libre
• 100% objet
• Interprété
• Multii-Paradgime
• Syntaxe proche langage naturel
• Code compact
• Méta programmation et c'est surtout ce qui fait sa puissance

Nous voyons d'abord les bases du langages : variables, contantes, accesseurs, boucles, condition, symboles, tableau, hashmaps, définition de classe, mixins.
Je ne rentrerai pas dans les détails sur ces derniers points. Ruby offre un certain confort d'écriture.
Comme il l'a été dit, il existe plusieurs implémentations :

• JRuby
• IronRuby : pour .net
• MacRuby : Objective C , maintenu directement par Apple
• Rubinus, la nouvelle jvm ruby.

Nous voyons un exemple de JRuby de création d'une frame et de son affichage. Le code mélange de Java et Ruby. Dans ce seule l'instantiation change :

frame = java.swing.JFrame.new()

Le reste sera comme en java.

Zoom sur les Gems.

C'est un peu comme des .deb : ça s'installe facilement (gem install XXX) et ça installe aussi les dépendances. Bien qu'il existe beaucoup dendroits où en trouver, la référence est http://www.rubygems.org

Rails s'appuie sur 2 principes :

• DRY : Don't Repeat Yourself
• Convention Over Configuration

Au niveau architecture, on s'appuie sur les principes de REST et de MVC.
S'en suit, un coding live, où Maxime développera une application de gestion de tâches pour d'un projet.
Le code sera bien sûr codé sous Rails 3 dont la release finale verra bientôt le jour.
En ligne de commande, le projet est crée avec toutes sa structure.
Une autre ligne suffira à créer une entitée Projet avec son interface d'administration et ses tests.
Bien sûr, par défaut, il n'y a pas de validation. Ces régles se définissent facilement et rapidement dans le code. Des "validates" seront ainsi posé sur la présence ou la taille de certains champs.

Et pour sécuriser ? 2 lignes suffiront.

Cette présentation est assez convaincante de la puissance de Rails. On voit aussi, que Play! S'en inspire beaucoup et en tire ce qu'il y a de bon. Ce dernier était d'ailleurs lui aussi à la sophiaconf, présenté par Nicolas Leroux, mais malheureusement en parrallèle de cette session.

Sophiaconf 2010 - Keynote du grand vendredi

Comme toute journée de conférence, cette journée commence par une keynote animée par les 2 organisateurs de cette journée : Stéphane Epardaud et Nicolas Leroux, tous deux leaders du Riviera JUG.
Un rappel sur l'organisation, ces journées de conférence ont étés organisées en partenariat entre :

• Barcamp
• Opencoffee
• Inria
• Riviera JUG
• Telecom valley

Aujourd'hui, 12 conf et barcamp où il y aura des ateliers. Le programme ne se veut pas seulement java, il y a la présence de Rails par exemple. Durant ces 5 journées de conférences, ce sera un total de 900 (dont 434 uniques) seront venues. Petite blague, sur nos conférences à Paris : "Ne comparons pas avec eux, ils sont nous sommes minimum 200 à chaques fois".
Rappel aussi sur le RivieraJUG, né en 2009 et celà grace à Antonio Goncalves qui avec le Paris JUG a montré que c'était possible. Aujourd'hui c'est déjà 12 soirées qui ont organisées.
Cette keynote aura un intervenant spécial : Patrice Coste de Red Hat. C'est en effet eux qui nous offre le buffet du midi, ce qui nous évite des sandwichs fait par Stéphane et Nicolas. C'est coiffé d'un chapeau rouge que Patrice fera sont intervention et nous présentera Red Hat et son activité. Red Hat est un gros contributeur à l'Open Source, entre autre par JBoss.
Et pour finir, Stéphane et Nicolas adressse un merci à tout le monde aussi bien aux sponsors, qu'aux intervenants mais aussi aux simples participants.