insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Android

Fil des billets - Fil des commentaires

jeudi 26 mai 2011

Le Scroll horizontal facile en Android

Par Nicolas FRANCOIS le jeudi 26 mai 2011, 09:47 - Android

Dans un souci d'ergonomie, le scroll horizontal est bien appréciable, par exemple pour passer à l'écran suivant. Même si la fonctionnalité est utilisé, pour se déplacer entre les écrans du home, il n'existe pas de composants qui gère cela. Comme bien, souvent, c'est dans l'open source que l'on trouve une solution.
C'est sur github que j'ai trouvé View Flow for Android qui offre une solution simple à intégrer. En fin de compte, ce comportement de scroll horizontal, c'est une sorte de ListView à défilement horizontal où une cellule = un écran. C'est sur ce principe que se base cette api. Elle offre un composant ViewFlow qui nécessite un BaseAdapter pour réaliser l'affichage de chacun de ses écrans.

viewFlow = (ViewFlow) findViewById(R.id.viewflow);
viewFlow.setAdapter(new MonAdapter());



 <org.taptwo.android.widget.ViewFlow
                   android:id="@+id/viewflow" 
                   android:layout_width="fill_parent"
                   android:layout_height="fill_parent" 
                   app:sidebuffer="3"/>


Qu'est ce que ce sidebuffer ?
Il s'agit tout simplement du buffer des écrans chargés; ce qui permet de fluidifier le scroll. Avec la valeur 3, j'aurai jusqu'à 3 écrans à droite, 3 écrans à gauche ainsi que mon écran actuel, soit 7 écrans, qui sont chargés et en mémoire. Cette valeur, est à 3 par défaut.

Et si j'ai besoin d'écouter le changement d'écran ?
Ca tombe bien, il existe un ViewSwitchListener

viewFlow.setOnViewSwitchListener(new ViewSwitchListener() {
    public void onSwitched(View v, int position) {
        // Your code here
    }
});


Certains Home Android, affiche un indicateur de position afin de connaitre celui sur lequel nous nous trouvons. View Flow for Android offre aussi cette possibilité. A l'heure actuelle, il en existe 2

  • Cercle
CircleFlowIndicator indic = (CircleFlowIndicator) findViewById(R.id.viewflowindic);
viewFlow.setFlowIndicator(indic);


  • Texte
TitleFlowIndicator indicator = (TitleFlowIndicator) findViewById(R.id.viewflowindic);
indicator.setTitleProvider(myTitleProvider);
viewFlow.setFlowIndicator(indicator);


Je trouve cette api sympathique à utiliser, et espère y voir de nouvelles fonctionnalités.
Comme beaucoup pour beaucoup de projet sur github, les contributions sont les bienvenues, si vous avez des idées, n'hésitez pas.

mardi 5 avril 2011

Intégration du SDK Facebook dans une application Android

Par Nicolas FRANCOIS le mardi 5 avril 2011, 17:28 - Android

Cet article est une version écrite de la présentation que j'ai pu faire au BOF dernier de Sfeir.


Pourquoi ?

Faire connaitre son application est une problématique courante auquel est confronté le développeur Android. Donner un aspect "social" à son application peut être une solution. Facebook est aujourd'hui une référence absolue en matière de réseau social et peut donc contribuer à répondre à cette problématique grace aux services qu'ils expose pour les développeurs. Voici quelles fonctionnalités qui pourrait donner la dimension sociale voulue :

  • Publier sur son mur : exprimer son avis.
  • Organisation d'évènements et inviter des amis à y participer
  • Checkins : marquer sa position

Néanmoins l'intégration de Facebook dans une application Android peut susciter une certaine crainte de la part des utilisateurs :

  • Si je dois m'authentifier au travers de l'application, n'y a t-il pas un risque qu'on me vole mes identifiants ? De plus, le fait de devoir me rentrer mes identifiants va certainement freiner l'envie de l'utilisateur de s'exprimer
  • Cette application ne risque t-elle pas de d'acceder à mes informations pour les renvendre et ma boite mail va être innondées de spam ?


Quoi ?

Le SDK Facebook constitue une solution pour le développeur Android. En s'appuyant sur l'application officielle, la connexion est ainsi quasiment invisible. Celle çi fait seulement valider à l'application les droits dont dispose l'application sur le compte de l'utilisateur.

Ce SDK n'est qu'un simple adaptateur entre du code en java et la Graph API. Né dans l'esprit de Mark Zuckerberg, elle permet d'accéder et d'interagir avec les données Facebook. En terme plus courant, c'est simplement un ensemble de services REST produisant du JSon.

Imaginons que je souhaite publier sur mon mur, la documentation nous donne :

La requête à adresser sera : me/feed Et nécessitera l'autorisation de publication de flux.


Comment ?

Tout d'abord, il faut télécharger le SDK. Celui fonctionnant sur le principe d'une library android, il suffit d'ajouter la dépendance nécessaire. Le SDK est fourni avec quelques exemples de manipulation de l'api. Il faudra aussi enregistrer son application sur Facebook. Déclarez vous en tant que développeur en donnant votre numéro de téléphone si cela n'est pas déjà le cas. La déclaration de l'application permettra permettra d'obtenir un identifiant d'application. Celui ci sera utilisé dans le code Android. Et pour finir la dernière étape : la création de la clé d'après le certificat qui signe l'apk :

keytool -exportcert -alias monApplication -keystore ~/.android/monApplication.keystore | openssl sha1 -binary | openssl base64

Pour les utilisateurs de Windows, il est recommandé de passer par un outil comme cygwin pour éviter des problèmes de génération avec openssl.

Sans cette clé configuré, il sera impossible à l'application d'accéder aux services Facebook. L'avantage est que même si le code Android est décompilé, il sera impossible d'utiliser le compte de l'application. L'inconvénient est que pour tester le bon fonctionnement, il faudra générer un apk signé à chaque fois que ce soit pour un téléphone, ou sur l'émulateur.

Il ne reste plus qu'à coder

Si votre application ne possède pas le droit d'accès à internet, n'oublier pas de le rajouter dans le fichier AndroidManifest.

<uses-permission android:name="android.permission.INTERNET"/>

La majeure partie du SDK est rassemblée dans l'objet Facebook Pour instancier cet objet, il suffit de lui passer en paramètre l'identifiant de l'application.

private static final Facebook mFacebook = new Facebook(FACEBOOK_APP_ID);

Un aspect primordial dans une application Android est la gestion asynchrone des tâches dès lors que l'on execute.

private static final AsyncFacebookRunner mAsyncFacebookRunner = 
                                         new AsyncFacebookRunner(mFacebook);

Lors sa tentative de connexion, le SDK envoie un intent à l'application officielle Facebook. Il est donc important de spécifier le code retour que devra avoir de cette activité, surtout si la votre utilise aussi ce mécanisme.

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
   if(requestCode == FACEBOOK_REQUEST_CODE){// Retour de login facebook
      FacebookFunctions.handleLoginResult(resultCode, data);      
   }
}

C'est lors de la demande de connexion que sera passé ce code retour. Cette demande doit aussi spécifier quelles sont les permissions requises par l'application.

private static final String PUBLISH_PERMISSION = "publish_stream";
private static final String[] PERMISSIONS = new String[] { PUBLISH_PERMISSION };
mFacebook.authorize(activity, PERMISSIONS, facebookRequestCode, new LoginDialogListener());

Quant à l'action de publication sur le mur, c'est une simple wrapping de requête web :

public static void publishCommentOnWall(String comment, PocRequestListener requestListener){
   final Bundle parameters = new Bundle();
   parameters.putString(GP_LINK_PARAM_FEED, ANDROID_URL);
   parameters.putString(GP_NAME_PARAM_FEED, "Android");
   parameters.putString(GP_PICTURE_PARAM_FEED, ANDROID_IMAGE_URL); 
   parameters.putString(GP_DESCRIPTION_PARAM_FEED, comment);  
   mAsyncFacebookRunner.request(GP_ME_FEED_URI, 
                parameters, GP_POST_REQUEST, requestListener, null); 
}

Les paramètres de la méthode request sont :

  1. La requête à effectuée, soit notre me/feed
  2. Les paramètre de cette requête.
  3. Le type de requête, soit du POST
  4. Un callback de réponse.
  5. Un objet quelconque de synchronisation qui sert à identifier les appels lorsqu'on en fait plusieurs en même temps. Il est facultatif.

J'ai moi même réalisé l'intégration de Facebook au sein de Keoli TV, une application Android permettant de donner le programme TV en temps réel, projet personnel sur lequel je travail avec quelques amis.

Le code complet est disponible ici

dimanche 28 novembre 2010

1ère réunion du PAUG

Par Nicolas FRANCOIS le dimanche 28 novembre 2010, 17:06 - Android

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

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 :
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.
Je profite de ce retour pour transmettre une demande. Les organisateurs sont à la recherche de salles de grande taille disponibles pour les prochaines rencontres. Si votre société/école en dispose, je vous laisse entrer en contact avec eux.
Pour ceux que ça intéresse, voici le google group :

samedi 9 octobre 2010

Fastcall Android

Par Nicolas FRANCOIS le samedi 9 octobre 2010, 22:47 - 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 là.

un commentaire

lundi 3 mai 2010

AndroidCampParis 1

Par Nicolas FRANCOIS le lundi 3 mai 2010, 21:45

Ce samedi 17 avril a eu lieu le 1er Android Camp Paris organisé par Sylvain Maucourt de Deveryware.

Il y avait certes eu un Android-"Dev"-CampParis1 mais cette fois-ci, le barcamp se voulait plus général.
Nous étions 3 à de Sfeir à participer à cet événement.

Le barcamp a commencé de manière détendue autour de pizzas offertes par Deveryware. Cela a été l'occasion de faire connaissance avant de rentrer dans le vif du sujet. Parmis la trentaine d'affamés, il y avait entre autre Jean Luc de jbmm, Pierre-Yves ou encore les fondateurs du site Standroid... et bien d'autres personnes encore. Chacun a pu sortir son appareil, le comparer, donner ses impressions...
Jean Luc, testeur pour Archos, nous a montré un nouveau firmware "3D" pour archos. Un jeu de course de vaisseaux type Star Wars I a servi de démonstration. Le contrôle se faisant par l'accéléromètre : incliner à droite ou à gauche pour tourner. Le jeu n'est pas évident à prendre en main, il faut certainement de l'habitude. Quant aux performances graphiques, elles étaient tout à fait honorables. Nous avons vu aussi voir un htc desire, petit frère que Nexus One qui ne diffère que la Sense, la surcouche de HTC.

Une fois le ventre bien rempli, nous avons commencé le barcamp proprement dit de façon traditionnelle : présentations à tour de rôle puis établissement du programme pour l'après midi. Il y avait des profils très différents : le bloggeur, le développeur qui fait de l'android quotidiennement, le développeur amateur ou même le néophite qui vient voir si android serait un bon investissement technique pour sa société.
Certains sujets se dégagent par rapport à d'autres comme le market (certaines personnes présentes étudient l'idée de lancer un market alternatif dénommé Appoke) et html5. Les sujets ont été séparés en 2 catégories correspondant aux 2 salles à notre disposition même : développement et hors-développement. Cela n'a pas empeché certains de faire des aller-retour entre les 2 salles.
En ce qui nous concernent, nous avons assisté au sujet développement.
Voici un aperçu des thèmes abordés :

Performances

Un retour d'expérience de Pierre-Yves conseille Jackson pour la génération de JSon, le gain de performance serait énorme.
Les nouveaux devices comme le Nexus One sont très performant. Quelqu'un nous parle par exemple de son application qui marche très bien sur son Nexus, mais qui très lente sur le HTC Hero d'un ami à lui. Celà peut être un danger, car on ne se rend pas forcément compte des performances si l'on teste sur son Nexus. C'est pourquoi, certains testent sur leur "vieux" Magic.
Le cycle de vie des Activity est sujet à problème pour certaines personnes. En particulier, la rotation de l'écran qui provoque la perte des données. Des solutions sont abordées allant des choix de conception à des astuces permettant de sauver des données (voir les tutoriels disponibles ici).
Le débat sur l'optimisation a été nuancé. Il faut savoir trouver un juste milieu entre recherche de la performance et maintenabilité. L'augmentation des performances des nouveaux processeurs ainsi que l'éventuel JIT de Froyo, permettront de s'autoriser plus de design pattern java classiques.

Industrialisation et outils

Pierre Yves nous parle de Roboguice, qui apporte la possibilité de faire de l'injection de dépendances sur la plateforme android. Son utilisation a un certain surcout, peu génant dans beaucoup de cas. Il permet notamment de s'affranchir de code n'apportant que peu de plus-value comme la récupération des composants déclarés dans les layouts.
Peu de développeurs présents ont exploré le terrain de l'industrialisation, signe qu'il y a encore de quoi faire de ce coté là.

WebApp, HTML, GWT

Nous avons résumé ce qui avait été dit au HTML 5 Meetup sur les "device API". Ces API interessent beaucoup les developpeurs mobiles alors que le premier SDK de l'iphone, pourtant orienté web, était un échec. Etait-ce trop tôt ?
Les apports de GWT dans le développement mobile ont aussi été abordés. On a évoqué "Modding" l'api open-source de SFEIR qui permet de faire du développement GWT pour mobile.

Market

Alexandre nous parle de son api open source : android-market-api qui permet entre autre de rechercher sur l'android market en fonction de critères comme mots clés, commentaire, ... Pour celà, il nous explique comment il a rétro-ingénieurer les échanges faits avec le market. Derrière une compression gzip et un encodage en base64, des chaines de caractères était lisibles. Le reste était basé sur protobuf.
Bien que les échanges soient optimisés, il reste tout à fait possible de les lire.
Nous nous sommes interrogés sur la stratégie de Google au sujet de ce market. Google a fait le sien, celui de référence, d'autres seraient tout à fait possible.

Fragmentation

Le problème de la fragmentation du marché est abordé. D'après les derniers chiffres, les devices en 1.5, 1.6 et 2.0 représentent chacun un tier du marché. Il est donc bien difficile d'ignorer ces anciennes versions qui représentent une part importante.
Nous parlons aussi rapidement de Froyo, la version 2.2 de Android, qui sortirait en mai et de ce qu'elle pourrait apporter.

Palm

Bien que ce ne soit pas de l'android, ceux qui avaient une expérience sur le developpement WebOS ont donner leur retour. Arrivée tardive hors des états unis, stratégie du constructeur mal comprise, difficulté à attirer des développeurs. Certains aspects comme la protection des données personnelles protègent plus l'utilisateur au détriment des possibilités pour le développeur.

Conclusion

C'est vers 18h30 que la journée se termine ....
Je crois que tout le monde est reparti des infos intéressantes, des anectodes ou des astuces de développement.
Bref une journée enrichissante !

Nous remercions encore Sylvain et sa société pour l'organisation de cet événement.



Par Alexandre et Nicolas.

2 commentaires

mercredi 2 décembre 2009

Le Motorola Droid (Milestone) débarque en France

Par Fabien Baligand le mercredi 2 décembre 2009, 00:09 - Java

Ce soir, j'ai pu assister à la soirée de présentation officielle du tout nouveau Motorola Droid (nommé Milestone en Europe), à l'occasion de sa commercialisation en France, et ce, dès ce soir.

Ce smartphone est un des plus attendus parmi les andro-phones : beaucoup y voient (espèrent) le tant attendu iphone killer. Pour preuve de sa popularité, à sa sortie aux états-unis (le 6 novembre), 250 000 exemplaires ont été vendus la première semaine...
Autre facteur faisant que ce téléphone attire l'attention (et pas des moindres) : il s'agit du premier téléphone équipé de Android 2.0.

Trêve de teasing, passons aux faits !

La présentation est lancée par Jacques Rames, président de Motorola France, qui nous annonce que :

  • Motorola a fait le choix d'Android en 2008, pour simplifier le développement multi-plateformes en interne et pour la facilité de déploiement d'applications (comparé à l'App Store d'Apple bien entendu).
  • Le Milestone est le deuxième téléphone Android de la marque et le début d'une longue série : Motorola projète de sortir pas moins de 10 smartphones Android en 2010, et souhaite devenir leader dans le domaine des smartphones (comme beaucoup me direz-vous).
Suite à cela, rueducommerce, qui sera - pour au moins les quelques semaines à venir - le vendeur exclusif du Motorola Milestone en France, nous annonce les tarifs :
  • à partir de 89 euros avec un forfait chez Bouygues Telecom ou SFR
  • beaucoup plus cher chez Virgin Mobile ou Orange (à partir de 189 euros et 219 euros !)
  • 549 euros le téléphone nu, sans abonnement
  Pour ceux qui le souhaitent, vous pouvez dès maintenant réserver ce téléphone en pré-commande chez rueducommerce. On nous a annoncé le début des livraisons mi-décembre (pour que tout le monde puisse avoir un joli Milestone sous son sapin de Noël ;)
Soit dit en passant, et ça aussi c'est Noël, jusqu'à fin décembre, pour le même prix, rueducommerce offre 60 euros d'accessoires en plus : un support multimédia (pour servir de mini-chaine hi-fi), et un support voiture (pour servir de GPS). Voir photo ci-contre.


Bien, l'aspect marketing et commercial étant passé, passons au côté technique !
Alors, qu'a t-il dans le ventre ce fameux Milestone ? Voici ses principales caractéristiques :
  • un écran très grand de 3,7 pouces (tout en restant compact)
  • le support du multi-touch
  • un processeur puissant cortex A8
  • une mémoire vive conséquente de 256 Mo (comme l'iphone 3GS)
  • un clavier physique AZERTY coulissant (pas comme l'iphone ;)
  • un appareil photo 5 MegaPixels avec flash double LED et auto-focus
  • un enregistreur vidéo (annoncé de qualité DVD !)
  • un mémoire interne de 8 Go extensible à 32 Go
  • WIFI, Bluetooth, USB 2.0, Micro-SD
  • un GPS, et un logiciel GPS développé par Motorola (malheureusement valable que 60 jours. Après, il faut passer à la caisse)
  • équipé de Android 2.0
  • équipé d'un navigateur intégrant Flash 10 (on va en reparler...)
Vous l'aurez compris, la liste des caractéristiques est plutôt alléchante, et il me tardait d'essayer concrètement l'appareil, pour voir s'il était à la hauteur de son impressionnante plaquette. Vous allez le voir, j'ai eu des bonnes et des mauvaises surprises. Petit retour d'expérience :
  • Tout d'abord, l'esthétique (c'est le premier truc qu'on voit) : on appréciera son grand écran, ses 4 boutons tactiles assez jolis, et une épaisseur assez fine pour un smartphone embarquant un clavier. Néanmoins, je le trouve un peu trop rectangulaire (peu arrondi), et le clavier est assez austère en comparaison au dernier LG GW620.
  • L'écran : l'écran est assez grand, et réagit très bien (écran capactif).
  • Le multi-touch : très fonctionnel pour le zoom sur les photos, et sur les sites internet. Par contre, ne marche bizarrement pas sur les maps (contrairement à un iphone...). Pour cela, il faut double-cliquer.
  • Le clavier : si je ne le trouve pas très esthétique, il est pour autant très efficace, le toucher est agréable et réactif.
  • La rapidité/puissance : globalement, la navigation est fluide et précise (l'écran capacitif aidant). J'ai noté toutefois quelques ralentissements lorsqu'on est sur le slideshow de photos.
  • Les photos : très bonne qualité de photo, même dans un endroit sombre, le double-flash marche très bien, et pas de flou. Les photos sont ensuite partageables sur facebook, myspace, picasa, ...
  • Les vidéos : j'ai été bluffé par la qualité des vidéos prises ! De même pour le son. C'est fluide, de bonne résolution et il y a un stabilisateur d'image. J'ai vu notamment une vidéo d'une piscine où on voit tous les détails des vagues. Par ailleurs, les vidéos sont partageables sur Youtube d'un clic.

Mais, me direz-vous, on est sur un blog technique et orienté développement/technologies, non ? Alors parlons de la star de ce Milestone, Android 2.0 :
  • La recherche : première fonctionnalité testée, la recherche intégrée dans le système d'exploitation. Le test est faussé par le fait que le téléphone est pour ainsi dire vide, mais néanmoins c'est convaincant. En quelques lettres tapées, on retrouve les contacts, les applications, les musiques de notre téléphone. Puis on le voit, dans un deuxième temps, il va chercher sur internet pour compléter la liste. Les résultats sont rapides, très pratique !
  • MySign : voici typiquement l'application qui m'a beaucoup plu. On dessine une lettre au doigt (qui peut être en fait n'importe quel geste), et il ouvre l'application paramétrée ! Très rigolo, mais aussi très ingénieux comme système de raccourci. Ce qui est particulièrement intéressant, c'est qu'on peut définir nos propres gestes, et leurs applications associées.
  • Intégration de Flash 10 dans le navigateur : il s'agit là de ma grande déception. Annoncé partout sur les plaquettes de Motorola, lorsque l'on va avec le téléphone sur un site Flash comme http://beta.parleys.com, on obtient un joli message indiquant que Flash n'est pas supporté... J'ai essayé avec d'autres sites, même problème... C'était de loin la fonctionnalité que j'attendais le plus (notamment d'un point de vue performance), et là, j'ai été très surpris et déçu de constater que ce n'est même pas fonctionnel. Les commerciaux nous ont expliqué que ce n'était pas la bonne version, mais je n'ai pas trouvé leurs arguments très convaincants.
  • Vive GWT et l'HTML 5 : Par contre, une application GWT 2.0 et HTML 5, ça marche très bien ! La preuve avec cette superbe application développée par SFEIR (^^) et qui fonctionne très bien sur le Motorola Milestone.

2 commentaires

lundi 23 novembre 2009

La conférence "Innovation WEB" fait son retour

Par Vincent Bostoen le lundi 23 novembre 2009, 21:50

Le 4 décembre 2008, l'association GET (Google EFREI Technologies) organisait en association avec SFEIR une conférence sur les technologies Google.

Fort de son succès, une deuxième édition est programmée pour le 11 décembre 2009.

Cette année, il sera question d'Android, de Google App Engine, de GWT, de Google Wave et des standards du WEB (HTML5, CSS3, SVG).

Les intervenants de cette année seront Ludovic Perrier, Didier Girard et Patrick Chanezon.

Les conférences se tiendront de 13h30 à 16h30 dans les locaux de l'EFREI.


A la fin de la conférence aura lieu un cocktail, ce dernier sera suivi d'un atelier de développement Android organisé en association avec le Paris GTUG.

Pour plus d'informations, rendez vous sur le site de l'association.

lundi 16 novembre 2009

Soirée Google Des Paris JUG

Par hoshams le lundi 16 novembre 2009, 00:40 - Web 2.0

Android

AndroidCette soirée Google commence tout d'abord avec une présentation d'Android proposée par deux consultants d'Oxiane, Gabriel Kastenbaum et Stéphane Liétard. Les deux conférenciers ont d'abord évoqué les approches historiques et marketing autour des smartphones et d'Android avec quelques rappels :

  • le début des smartphones avec les technologies BlackBerry et ses fonctionnalités pushmail dès 2001-2002, iPhone en 2007,
  • les premiers modèles de smartphones s'appuyant sur Android en 2008,
  • les chiffres publiés par Gartner prévoyant que la plateforme Android prendra la deuxième place en 2012 derrière Symbian de Nokia et légèrement devant iPhone,

Et ont continué avec les aspects plus techniques en rappelant qu'Android est un système d'exploitation pour Smartphones, PDAs et autres terminaux mobiles. Il est basé sur un noyau linux allégé de son gestionnaire de données.Android vient avec sa machine virtuelle, DALVIK VM, spécialement conçue pour les systèmes embarqués ayant peu de ressources.

DALVIK offre la possibilité d'écrire des applications pour Android en Java. Les classes compilées sont transformées en .DEX et non en .CLASS (bytecode pour JVM classique). Ce format est spécialisé pour la DALVIK VM et est optimisé pour un terminal mobile. Aussi, l'ensemble des classes du JRE classique n'est pas supporté, mais l'essentiel y est.

Développer avec Android peut se faire simplement en récupérant le SDK Android et le plugin Eclipse associé. Toute application Android est définie dans un fichiers (android manifest) au format XML.

Une application sur Android est composée d'un ou plusieurs composants qui sont de 4 types:

  • Activity : Un écran de l'application,
  • Service : Un service qui tourne en tâche de fond,
  • Content Provider : Un fournisseur de contenus (souvent une base de données SQLite),
  • Broadcast Receiver : Réception d'un événement envoyé à toutes les applications (niveau de la batterie, réseaux, appel, sms, etc.).

Une application peut appeler un composant d'une autre application (exemple : ouvrir une page du navigateur ou la configuration du système), lancer un service d'une autre application, ou accéder aux données d'une autre application (exemple : accéder aux contacts).

Pour relier les composants entre eux, on passe par la notion d' "intent" qui encapsule les actions et données échangées. C'est ensuite Android qui s'occupe de trouver l'application à lancer pour l'Intent donné, il utilise pour cela le fichier android manifest où tous les composants de l'application sont enregistrés.

Et enfin, on a eu droit à une petite démonstration avec une application Android présentant une page et un bouton qui, en l'actionnant, affiche une autre application.

Pour plus d'infos : http://developer.android.com/index.html

Google App Engine, Groovy and Gaeylik

Google App Engine GroovyLa soirée continue avec la conférence Google App Engine proposée par Marc-Antoine Garrigue et Gaël Lazzari d'OCTO et Guillaume Laforge de Spring Source

Guillaume Laforge a commencé par la présentation de AppEngine en rappelant que c'est la Plateform as a Service (PaaS) de Google où on peut héberger ses application et y accéder via URLs. Google propose à l'application "hébergée" des APIs et fonctionnalités qui permettent de gérer le cache, email, XMPP, Cron, etc.

Les principales limitations de la plateforme sont :

  • pas de base relationnelle,
  • la durée d'une requête est limitée à 30 secondes,
  • le système de fichier est en lecture seule,
  • impossibilité d'utiliser des Threads,
  • pas de sockets natif,
  • certaines classes de l'API Java ne sont pas autorisées,
  • taille de fichier est limitée.

Les services de la plateforme App Engine sont gratuits jusqu'à un certain seuil. Les quotas au-delà desquels les services deviennent payants sont assez larges. Ils concernent le volume de données échangées, le nombre de requêtes, etc. Une interface d'administration permet de gérer les applications déployées, et via un tableau de bord de visualiser les statistiques et le graphe d'activités. Pas de base de données relationnelle classique pour la persistance de données mais une sorte de Hashtable/Bigtable. Par contre sur cette structure, Google propose des abstractions permettant d'utiliser JPA/JDO pour la persistance de données. Avec ce gestionnaire de données, le nombre d'occurrences retournées par une requête est limité à 1000. Il n'y a pas de support de transaction ni de possibilité de lancer des requêtes de type JOIN ou CONSTRAINT. En revanche on peut bénéficier des "facilités" permettant de gérer des entités hétérogènes de l'application dans une même structure de données.

Par la suite Marc-Antoine Garrigue et Gaël Lazzari ont présenté Groovy et Gaelyk. Groovy, langage dynamique basé sur Java, à présent peut fonctionner avec App Engine. Pour arriver à cette compatibilité, Groovy a modifié quelques lignes de codes après un travail en commun avec Google. Avec Groovy on peut faire des composants qui ressemblent à des servlets, les Groovlets ainsi que des pages Groovy Template Servlet.

Gaelyk, le Framework/boite à outils facilite le développement avec Groovy et aide le développeur à interagir plus facilement avec App Engine. L'application de démonstration FetchFeeds est plus qu'une simple application. Proposée en open source sous licence Apache, elle utilise bien sûr les technologies App Engine, Groovy et Gaelyk. Elle montre de plus comment implémenter les mécanismes subtils permettant de réduire l'utilisation de ressources et donc comment ne pas dépasser trop vite les quotas imposés par App Engine.

http://groovy.codehaus.org

http://gaelyk.appspot.com

Google Wave pour les développeurs

Google WaveAprès le buffet sympathique et classique des conférences Paris JUG, nous remontons de nouveau les quelques escaliers I.S.E.P qui nous mènent à la salle de conférence pour suivre la dernière conférence de la soirée.

Didier Girard le Directeur des Opérations et de l'innovation de SFEIR, et Salvador Diaz, consultant spécialisé dans les technologies Google, nous présentent le tout dernier outil collaboratif de Google, Google Wave.

À en croire les sondages à mains levées, la grande majorité des participants présents dans la salle développe en Java, a déjà développé en GWT et pour certains sur Android et beaucoup possèdent déjà un compte Wave !

La présentation débute par une revue des principales fonctionnalités de Wave suivi d'une série de démonstrations.

Google Wave est généralement présenté comme une plateforme de communication faisant la synthèse de messagerie instantanée, d'email et de wiki avec donc la possibilité de partager un même espace entre plusieurs intervenants, drag & droper des photos ou partager des données pendant une conversation, etc. Cet outil collaboratif est développé en GWT et apporte deux principales innovations qui sont la possibilité de créer et de déposer des gadgets dans une Wave et la possibilité de développer des Robots (Goldorak pour les intimes !), une sorte de servlet qui collabore à sa façon aux conversations.

En effet, un Robot est un automate que l'on fait participer à une Wave. Il peut se comporter comme n'importe quel autre participant et dès lors il peut modifier le contenu de la Wave, ajouter des participants, etc. Les Robots supportés par Wave sont déployés sur Google App Engine et communiquent en HTTP et peuvent être indifféremment écrits en Python ou en Java. En déployant un Robot sur AppEngine, Google crée implicitement une url de type http://application.appspot.com que wave va appeler pour le robot qui aura alors comme adresse mail : application@appspot.com. Pour illustrer les possibilités que Wave offre aux développeurs, Salvador et Didier ont proposé de nous faire trois démonstrations.

La première démonstration nous montre comment créer un gadget, le déployer sur App Engine et l'ajouter à une Wave. Il suffit de récupérer un wrapper, étendre un gadget et lui donner un titre. Le gadget créé dans la démonstration, n'est autre que le logo de Paris JUG qui se déplace dans tous les sens sur l'écran. Un simple copier/coller de l'url suffira pour l'ajouter à une Wave. Les autres invités de la Wave pourront dès lors le voir et interagir avec.

La deuxième démonstration consiste à créer un Robot qui va participer à une chaine de transmission et de traitement de SMS qui utilise les technologies Android, AppEngine, GWT et enfin Wave. Le jeu consiste à faire un sondage via SMS avec la salle sur la présence des participants à un prochain événement Paris JUG. Les participants envoient un SMS à un téléphone Android, le téléphone possède une application qui réceptionne tous les SMS du téléphone pour les envoyer sur un serveur AppEngine. Enfin, un gadget écrit en GWT et ajouté sur une wave va interroger régulièrement AppEngine pour afficher les SMS. Le Robot développé pour la démonstration est déployé sur App Engine. Pour recevoir le messge, il est abonné aux événements de la wave (modification d'un message, ajout d'un participant, etc.), s'il détecte une commande particulière (SEND(message;téléphone)), il va former le message que l'application Android vient scruter et envoyer en SMS. La salle participe activement en envoyant des SMS que l'on voit défiler avec les chiffres consolidés dans la "boite" Wave de nos deux conférenciers.

La troisième et dernière démonstration nous montre un exemple d'utilisation de Wave en entreprise. Il s'agit d'un outil collaboratif léger à base de gadgets de prise de congés. Le demandeur de congés rajoute les gadgets dans sa Wave et renseigne les jours demandés. Il invite ensuite son responsable et dès lors un mini workflow de prise de congés s'engage via le Wave entre le demandeur et le responsable qui doit valider la demande.

Ces trois démonstrations et l'explication de code qui a suivi, ont montré aux participants comment Wave peut se placer au sein des technologies Google et comment on peut assez simplement et sans besoin d'infrastructure complexes, mettre en oeuvre via ces technologies des applications techniquement complexes.

https://services.google.com/fb/forms/wavesignup/

http://code.google.com/intl/fr/apis/wave/

À la fin de la conférence, les Juggers qui le souhaitent peuvent demander leur nouveau compte Wave juste avant de se diriger vers la troisième mi-temps qui promet d'être riche en discussion.

2 commentaires

mercredi 10 décembre 2008

Devoxx 2008 - Android : rich clients

Par David MARTIN le mercredi 10 décembre 2008, 19:15 - Java

Android est aussi de la partie ici. Le buzz généré depuis ces derniers mois se doit d'être entretenu, surtout lorsque la plateforme est commercialisée depuis plusieurs semaines.

La présentation Filthy Rich Android Client s'est axée sur les fonctionnalités graphiques permises par Android. Cela concerne donc les manipulations possibles sur les images (Transformations, ...), ainsi que la partie animation.

Romain Guy, le speaker en charge de cette présentation, a passé en revue le principe de construction d'un écran, expliquant au passage quelques astuces d'optimisation (ne pas instancier d'objet dans les phases de 'painting', accéder aux attributs des objets directement plutôt qu'au travers les accesseurs - au diable les bonnes pratiques, sacrifiées sur l'autel des perfs sur ce coup :), désactiver le rendu du background du Canvas si celui-ci n'est jamais visible...)

Par contre, il n'a pas été question de la gestion plus poussée du hardware des terminaux (ou plutôt du terminal, car seul le G1 fait tourner officiellement Android à ce jour). Ces aspects sont certes moins sexy, mais entrent en jeu dans le développement d'applications professionnelles, ou tout simplement non graphiques.

Ce point mis à part, Android affirme ici son intention, s'il était encore nécessaire de le redire, de prendre une part non symbolique du gâteau partagé par les RIM, Nokia, Microsoft et assez récemment Apple, en proposant un environnement de développement susceptible de toucher une base de développeurs très large : celle des développeurs Java!

L'avenir est dans le mobile, tout le monde se prête à le dire !

mardi 25 novembre 2008

Rejoignez nous le 4 décembre !

Par Vincent Bostoen le mardi 25 novembre 2008, 20:07

SFEIR et l'association G-EFREI Technologies organisent une grande conférence le jeudi 4 décembre 2008 à l'EFREI.

Au programme, des présentations et des ateliers traitant de RIA, Cloud Computing et mobilité.

Parmi les intervenants, Didier Girard parlera des RIA via une présentation de GWT, Christian Fauré de Cloud Computing et Jieren Wu de mobilité avec Android.

L'évènement est gratuit et ouvert à tous, reservez dès maintenant votre place en remplissant le formulaire ci-dessous.

Pour davantage d'informations et savoir comment vous rendre à cet évènement, c'est par ici.

mercredi 24 septembre 2008

Le G1 (Google Phone) fait parler de lui

Par Pierre Mage le mercredi 24 septembre 2008, 01:28

Une news un peu geek pour annoncer la sortie prochaine (22 octobre 2008) du smartphone Google aux Etats-Unis pour un prix de 199$. Pour l'europe, il semblerait qu'il faille attendre avril 2009...

En s'attaquant à ce marché déjà fortement occupé par les l'iPhone d'Apple et les BlackBerry de RIM, Google fait encore une fois parler de lui :
Le Monde : Le Gphone veut la peau de l'iPhone
Libération : Google Phone : le G1 se dévoile en avance
Le Figaro : Le «Google phone» sortira fin octobre aux Etats-Unis
BBC : Google's Android mobile unveiled (avec une petite vidéo de démonstration)
El Pais : Es el turno de 'Google Phone'
Bizarrement il n'y a que dans mes feeds CNN que je n'ai pas lu cette info !

Il va être grand temps de se pencher sérieusement sur Android (la plateforme Java développée par Google sur laquelle repose le G1).
Pour avoir une petite idée quant aux possibilités de la plateforme Android, je vous propose de faire un tour sur la galerie du Android Developer Challenge.

un commentaire

samedi 21 juin 2008

TheServerSide Java Symposium - Jour 3

Par Olivier Gérardin le samedi 21 juin 2008, 01:58 - Java

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

  1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
  2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
  3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
  4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

 

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur MapReduce dans l'autre salle...

 

Dernière conf du matin, Michael Keith présente What's new in JPA 2.0. Les objectifs étaient multiples:

  • standardiser les propriétés
  • remplir les manques de l'ORM
  • rendre la modélisation objet plus flexible
  • fournir une abstraction du contrôle du cache
  • contrôle du verrouillage (locking)
  • fournir des "hooks" pour des frameworks propriétaires
  • améliorations JPQL
  • etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l'utilisation directe d'une API de persistence propriétaire.Au passage, la présentation a été agrémentée d'une page culturelle sur les oies du Canada...

 

Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils ont enlevé les machines à café !

 

L'après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d'un framework, cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou comment gâcher un bon sujet.

 

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l'interface d'une classe interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard propose d'inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML correspondant. Ansi on n'expose pas d'interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l'interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d'interruption volontaire ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

 

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d'hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n'ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s'y trouver demain...

Jeff conseille judicieusement d'utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l'intérêt pour la techno est évident. J'espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

 

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n'a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d'aujourd'hui, mais Java en restera probablement le centre de gravité...

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l'écran géant au centre ville...