Le Scroll horizontal facile en 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 m'offre un composant ViewFlow qui aura un nécessitera un BaseAdapter pour réaliser l'affichage de chacun de ses écrans.

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

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.

Intégration du SDK Facebook dans une application 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 recommande 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

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 :
- La requête à effectuée, soit notre me/feed
- Les paramètre de cette requête.
- Le type de requête, soit du POST
- Un callback de réponse.
- 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.

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

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.

Sophiaconf 2010 - Android

1ère partie : Tout savoir sur l'évolution des 12 derniers mois et de l'année à venir

Aujourd'hui, pour cette 3ème conférance, c'est Arnaud Farine (Fondateur de eXpertise Android et rédacteur pour le site frandroid) qui débute.
Cette fois ci beaucoup plus de monde dans la salle, 190 personnes s'étaient inscrites.

1 an d'Android

Pourquoi 1 an ?
Tout simplement parce qu'il y a un an, Arnaud été venu présenter Android à une conférence ici, à Sophia Antipolis. Cette conférence était assez technique. Le but de la conférence ce jour, ne sera pas de faire la même, les notions de base comme qu'est ce qu'un intent, ne seront pas ré-expliquée.
Arnaud commence par rappeler quelques notions sur l'environnement : Qu'est ce qu'est Android, OHA, market, SDK, STK (Sim Toolkit), ...
La fragmentation commence à se montrer (résolution, matériel, ...). Le problème de la fragmentation vient des constructeur et opérateur qui souhaitent personnaliser le système.

Petit rappel sur Android aujourd'hui :

• 160 000 devices vendus par jour
• 70 000 applications
• 48 pays
• 1er système mobile sur internet (attention au chiffre fournit par Admob)
• 190 000 developpeurs
• 59 constructeurs

L'année dernière en juin, alors qu'il n'y avait seulement que 2 téléphones (G1 fream et le G2 Magic), il y a en aujourd'hui 30 et 20 tablettes. D'ici la fin de l'année, il devrait y avoir 60 smartphones et 50 tablettes.
Tous les opérateurs s'y sont mis.
Chez Bouygues, les 5 mobiles les plus vendus sont des téléphones sous Android. Si quelqu'un avait annoncé cela l'année dernière, personne ne l'aurait cru.
Grosse évolution aussi niveau performance : meilleure résolution, 2 fois plus de puissance et mais aussi le multitouch.
Sur le plan des applications, la progression aussi a été fulgurante :
Juin 2009 : 6000 applications (1500 applications par mois) avec des markets accessible au Etats Unis et Europe
Juillet 2010 : 80000 applications (14000 applications par mois) avec un market présent dans le monde entier
Les applications google aussi connaissent une bonne évolution : Google maps, Street View, Google navigation (depuis septembre au US, et depuis peu en France). Selon Arnaud, Google Navigation est un produit de bonne qualité, depuis qu'il s'en sert: le Garmin reste au coffre. Ce dernier ne semble pas inquiet face à ce concurrent, selon eux, car leurs puces sont plus performantes que celle de téléphone mobile. Garmin devrait sortir un GPS/Teléphone en alliance avec Asus.
Coté market, depuis l'année dernière, on a vu des android markets qui se développent et viennent combler les manques du google market (sur le contact d'un développeur par exemple).
C'est ainsi qu'est apparut un market où il est possible de payer avec son compte Paypal. Le moyen de paiement est d'ailleurs un des reproches qui est souvent fait au google market; les utilisateurs préféreraient une facturation opérateur. Au US, T Mobile l'a fait, et en France, Orange travaille dessus.

Améliorations des versions

Avec les différentes versions d'Android, sont venus leur lot de nouveautés et d'améliorations pour l'utilisateur mais aussi pour le développeur.

DONUT

Utilisateur	Développeur
Commande vocale (pas en fr) TTS (Text To Speech) Ergonomie revues Nouveau interface market Economie NRJ (voir ce qui consomme le plus) Nouvelle interface photo.vidéo Système de recherche intégré au mobile	Gestion résolutions Suppression de AbsoluteLayout (pour compatibilité différentes résolutions) SearchManager Api TTS (text to speetch) OnClick xml Optimisation du touch avec l'outil Gesture Touch ADT6

ECLAIR

Utilisateur

Développeur

Nouvelle interface Syncho multi compte avec exchange en natif Interfacemail tous les comptes Zoom numérique amélioré Applications d'effets Multitouch (des gens ont un peu ralé, google a libéré le code) Bluetooth 2.1 (à début juste pour oreillette,) Echange de données Amélioration navigateur internet Moteur de recherches sur ls contacts ou les MNS et appli autorisants Live Wallpaper Maps Navigation

Optimisation outils création IHM API live wallpaper API BT Gestion du signal réseau Gestion des changements de connexion Multitouch Modification gestion contact Support Chrome Webclient

FROYO

Utilisateur	Développeur
Amélioration UI Android market sur pc Communication Pc/Android (seulement sous chrome via extensions) Maj auto de tous les applis installées HTML5 et accès matériel Javascript 8 Tethering/ partage de connexion wifi Installation s'application sur SD Flash 10 (pas très satisfaisant). Pas testé Adobe Air 20% + rapide	Open GL ES2 InstallLocation (SD) Backup Manager (cloud), mais pas toutes les données. Reconnaissance Vocal Compression YUV API Camera modifiée (visu) / Exif Gestion de la sécurité Fill_parent (deprecated) vs match_parent

Bilan des évolutions : en 2009, 4 versions et en 2010, 3 versions. Ce rythme est jugé trop rapide de la part des acteurs qui n'ont pas le temps d'intégrer leur modifications avant qu'une nouvelle version ne sorte. Pour y remédier, Google a décidé de limiter les versions à une par an.
Les chiffres donnés par Google sur la répartition (à savoir 50% d'Android 2.1 en juin 2010) sont ils représentatifs du marché français ? Arnaud en tant que responsable sur Frandoid, avait lancé une grande enquête. Il semblerai ainsi qu'en France, il y ait 60 % de version d'Android 2.1

Et dans 1 an ?

Arnaud précise qu'il ne posséde que peu d'information à ce sujet, et pour ses prévisions, elles sont liées à son expérience et sa boule de cristal.

• Android 3.0 : nouvelle IHM,
• 150 000 applications
• 3 ou 4 ème OS smartphone et 1er OS sur les tablettes
• Diminution de la fragmentation,
• Nouveau matériel : TV, set top box commercialisé
• Google voice accessible en Europe
• Apparition de matérial 3D, de la vraie 3D sans lunettes
• Payement applications sur la facture opérateur
• Arrivée d'un ADT1.0
• Intégration du NDK dans le SDK, aujourd'hui c'est assez rébarbatif
• Plus d'accès au matériel via HTML5
• Présent dans les cursus d'écoles d'ingénieurs / université

Et pour finir, il note que le marché à changé au niveau de professionel. En 2008 personne ne savait ce qu'était Android.
Depuis fin de l'année dernière , la tendance s'est inversée, beaucoup de demandes de développements, consultating de haut niveau, ...
L'année dernière, alors qu'on demandait des portages d'application Iphone pour Android, maintenant, on rencontre de plus en le contraire : on développe d'abord une version Android avant de voir pour d'autres OS.

La présentation finie quelques questions de l'assistance :

• Les markets alternatifs ne risquent ils pas de créer de la fragmentation ?
  Non car c'est les même applications. De plus, ils sont réservé à une élite d'utilisateurs pour le moment.
• Quelle est la position de ChromeOS par rapport à Android ?
  ChomeOS est prévu pour les laptops, ce n'est pas les mêmes usage.

2ème partie : Retours d'expériences

GridPocket

C'est Filip Gluszak, CEO & co-founder de GridPocket, qui commence.
GridPocket est une start-up visant à offrir une aide à la maitrise de la consommation énergétique. Leur solution s'intègre dans la mouvance des compteurs dit intelligents et ont choisi Android. Le but de leur application mobile est le suivi de consommation, l'analyse de l'impact environnemental et les alertes état du réseau.
Avec des besoins initiaux qui étaient : la nécessité d'avoir un prototype rapidement, de démontrer l'interet de l'application aux clients et investisseurs et de préparer des trials avec des clients; ils ont donc choisi Android pour son nombre d'utilisateurs en grande croissance, une flexibilité en terme de programmation que IPhone et une différentiation par rapport à IPhone (leur donnant ainsi une avance technologique).
Leur bilan est très positif malgré quelques reproches :

• Emulateur peu efficace en lignes de commandes
• Pas de multitouch jusqu'à présent
• Performance SQLite limitée (getCount() très lent par exemple)
• Message erreur utilisateur peu efficace, difficile de débugger avec
• STK très limité
• Problème UI qui ont été résolu en passant en 1.6

Orange Labs

C'est maintenant au tout de Philippe Gilbert, Ingénieur R&D Orange Labs.
Un des utilisation que Orange Labs a pu faire avec Android est une interface pour le monitoring de bundles OSGI dans des devices livebox. Ils possédaient déjà une telle application mais sous forme web. Leur interrogation était de savoir comment l'application pourrait se porter sous Android ?
Leur interface web n'était pas portable en tant que tel.

Ils ont ainsi du refondre l'interface graphique en utilisant des composants graphique Android et des appels avec des services REST pour la communication coté serveur.

Au final :

• 10 000 lignes de code
• 4 Activities
• 1 mois et demi de développement pour une seule personne (code, test et intégration)
• Application full java
• Utilisation d'api REST
• Internationalisation

Les conclusions qu'ils tirent de leur développements :

Forces :

• Réutilisation composa,te et app java, pas de scenar de rupture
• Intégration + ue du ndevde composant
• Bon support (forum, blog, ...)
• Bonne intégration à Eclipse

Faiblesses :

• Il faut un peu de temps pour se familiariser avec les concepts de développement Android
• Recompilation de bibliothèques externes qui devient difficile lorsqu'il y a beaucoup de dépendances (ex SOAP)
• Peu d'outils

Tendances intéressantes

• html 5
• Automatic update + bug report
• Entreprise API

SAP

Et pour finir, Laurent Gomez et Stéphane Dupin, d'un département R&D de SAP.
Une de leur utilisation a été une application de prévision de consommation (énergetique, eau, ...).

Pourquoi avoir choisi Android ?

Parce que ça leur a eu l'air l'air sympa, communauté grande, plateforme ouverte.
Ils sont satisfait du mode émulateur qui leur procurait des performances égales à celles de leur device HTC Hero
Eux aussi trouve l'utilisation de lib externe peu pratique et niveau composant regrettent l'absence de composants de type charts.
Pour la communication avec le monde extérieur, les appels REST leur ont très bien convenu et recommandent cette manière de procéder.
Leur conclusion et que Android est prometteur mais encore jeune mais qu'il continue a développer dessus.

AndroidCampParis 1

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.