Après quelques semaines d’utilisation, je commence à me faire une idée des capacités de la plateforme et de ses qualités ert défauts! Et il y a de quoi parler, à commencer par l’émulateur. Ce dernier m’a semblé de prime abord de très bonne facture, mais il s’impose vite la conclusion suivante: l’émulateur propose des performances catastrophiques! Le PC sur lequel je développe est un portable Athlon XP 3000+, ok il n’est pas tout neuf, mais cela reste honorable, étant donnée que l’ordinateur dispose de 1,5Go de RAM et d’un disque 5400 tpm, les performances restent donc correctes. Cependant, dès que l’émulateur est lancé, le pourcentage d’utilisation CPU monte à 95 % très facilement et le pc ne répond pas vraiment bien (C’est le moins qu’on puisse dire) . Ce qui me trouble le plus reste les performances des programmes exécutés sur l’émulateur. Je ne suis pas arrivé à des performances correctes sans faire des concessions importantes sur le design applicatif et encore avec difficulté.

Je comprend l’angoument autour de la plateforme, mais également pourquoi on voit si peu de programmes disponibles (Je ne pense pas que ce soit lié au concour Android de Google uniquement). La source du problème n’est pas tant dans la plateforme que dans les performances de l’émulateur qui ont de quoi dégouter du développement sur Android et pousser à explorer les progrès fait sur J2ME et les JVM MIDP de Sony et Nokia qui semblent d’ailleurs très intéressant.

Même si les constructeurs proposent des machines performantes, il va falloir que Google fasse un effort sur son émulateur pour proposer des performances acceptables sur son émulateur. Dans le cas contraire, il se pourrait que certains développeurs soient rebutés. Pour l’instant j’en fait parti.

Autre bémol et de taille: c’est l’obscurantisme des API de la plateforme et le peu d’explications qu’on peut trouver. On est bien trop amené à essayer de deviner comment utiliser les API.  Les API étant complètement nouvelles, elles obligent le développeur à un apprentissage nouveau. De plus les API sont complexes et accrobatiques à utiliser. Souvent élégantes dans le concept, il faut tout de même avoir de bonnes notions de développement pour les exploiter correctement.

j’appuye cette petit analyse sur un retour d’expérience réel , j’ai essayé d’exploiter des API REST simples et cela me pose trop de difficultés pour en rendre le développement sympathique: j’ai plus tendance à m’arracher les cheveux entre la complexité des API et les performances de l’émulateur.

Gageons que la plateforme est encore jeune, et des best practices Android simples et efficaces  apparaitrons, mais pour le moment ce n’est pas la panacé. Et un travail urgent est à faire sur les performances de l’émulateur. Pour am part, le constat est simple: j’arrêtele développement Android ou bien j’achète un nouveau PC…

Un dernier mot: Je suis en 1280 et l’émulateur prend une grande partie de mon écran! C’est quand même assez embêtant. Google est capable de penser des API complexe, mais pas à un détail aussi simple.

A noter: les JVM de Sony et de Nokia embarquent aujourd’hui tout un ensemble d’extensions intéressantes, sur lesquelles je reviendrais un autre fois, mais qui permettent de développer facilement aujourd’hui des applications intéressantes sans vraiment de difficultés particulières. Les problématiques d’antant n’existent plus vraiment sur MIDP aujourd’hui.

Depuis quelques jours, j’ai un W910 de Sony, et il faut dire que je suis impressionné par les progrès effectués et la diversité des API MIDP proposées (Sensor API, Content handler API, MMAPI, Bluetooth API, …). De plus, les JVM sony, par exemple, en sont à leur 8ème génération, ce qui en fait un choix de plateforme proposant de nombreux avantages (performances, stabilité, support d’API étendues, …) et un choix pour le moment bien plus sûr qu’Android.

Ma conclusion, est donc la suivante: comme de nombreuses personnes, je suis rentré dans le jeu des Buzz (IPhone /Android), mais rien ne vaut les valeurs sûres telles que MIDP ou le DotNet CF ou bien la plateforme de dev Symbian ou Palm. Attendons donc quelques mois que la plateforme Android murisse et que les premiers modèles sortent avant de trop en dire sur Android. N’oublions pas, entre autre, pour le moment qu’Android repose sur une plateforme Linux qui n’est compatible ni Symbian, ni Windows Mobile, ni Palm. Le marché est de ce fait extrêmement restreint. De la même manière que l’Iphone, le marché Android risque de rester une niche un certain temps. L’arrivée de l’IPhone et d’Android ne font que segmenter le marché et rendre la tâche plus difficile pour les sociétés travaillant dans le domaine de la mobilité. Il existe au bas mot 6 plateformes importantes: Midp, Windows Mobile, Symbian, Palm, l’IPhone et Android!

N’hésitez pas à faire part de vos impressions!

Share This

Pour rappel: le plugin maven ‘maven-android-plugin‘ propose ue intégration des outils Android avec Maven.

Après une courte utilisation du plugin en mode multi-modules, j’ai repéré un petit problème d’utilisation lorsque les commandes maven sont lancées depuis un projet parent. Ce problème hélas rendait très gênant l’utilisation en mode multi-module de maven. L’auteur a heuresement apporté les corrections nécessaire et le plugin est donc maintenant utilisable en mode multi-modules. Je conseille donc à tout le monde de l’essayer. Il a beau être dans la sandbox des plugins maven j’espère bien qu’il sera supporté à terme pour sortir de la sandbox et fournir un support complet Maven pour Android.

A noter: L’auteur du plugin indique uniquement le chemin du projet en utilisant un lien vers ViewVC, mais pour l’installer il faut bien le checkouter depuis un client subversion, puis l’installer en tapant la commande Maven: ‘mvn install‘. Cette URL est hélas visible nul part…

L’url svn du plugin est la suivante:

http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-android

Share This

Android est de prime abord un framework qui propose tout le nécessaire pour avoir une intégration avec les outils de développement traditionnels. Google propose, en effet, une intégration avec Eclipse via un plugin plutôt bien fait, et une intégration avec Ant.

Mais qu’en est-il de l’intégration d’Android avec Maven ? Un billet de ce blog en fait déjà mention (’Android + Maven, C’est déjà possible‘) : Shane Isbell a développé tout l’outillage maven nécessaire à cela.

Cependant l’intégration ‘Android + Maven’ avec Eclipse ne se rélève pas aisée pour autant et pour cause: le packaging maven est spécifique (Génération de fichiers Dex), des builders spécifiques existent pour eclipse, etc.

Pour avoir essayé plusieurs plugins d’intégration de Maven avec Eclipse et Android, j’ai peux conclure que tous ne sont pas adaptés!

Et en particulier Q4E qui présente de nombreuses lacunes. Je vous conseille donc d’essayer soit le plugin maven : maven-eclipse-plugin, qui propose une génération des fichiers nécessaires à Eclipse ou bien m2eclipse qui dans l’ensemble semble bien fonctionner si ce n’est la nécessité de supprimer la référence vers le JRE par défaut d’Eclipse inclus dans le classpath généré. Maven-eclipse-plugin posera plus de difficultés étant donné qu’il ne propose pas la génération de classpath avec un packaging spécial (android:dex) ce qui est au final très embêtant puisqu’il faut le confectionner soit même alors que c’est un des buts premier du plugin … De plus il est nécessaire d’ajouter les builder complémentaires à la main dans la configuration du plugin.

Share This

Utilisant Maven tous les jours, je me suis forcement intéressé de près aux solutions permettant d’intégrer de manière simple et efficace Maven avec Eclipse.

Pas plus tard que cette semaine la fondation Eclipse a officiliasé l’intégration d’un nouveau sous-projet visant à développer un support officiel pour Eclipse de Maven nommé : Eclipse IAM, abréviation de ‘Eclipse Intégation for Apache Maven’. Ce sous-projet n’est autre que le plugin Q4E, un plugin existant depuis quelques temps, et qui est proposé sur Google Code.

Cependant, il existe un autre plugin plus connu et surtout plus stable et plus réfléchi, il s’agit du projet: m2eclipse, qui est un plugin proposé sur CodeHaus. M2Eclipse existe depuis longtemps et propose de nombreuses fonctionnalités telles qu’un support des projets multimodules correct. Il existe encore quelques couacs (bug concernant le support des profils, pourtant bien mis en avant), mais globalement ce plugin représente aujourd’hui le meilleur support pour fonctionner en tout Eclipse.

Pour les puristes de la ligne de commande, il est possible d’utiliser maven-eclipse-plugin qui propose de nombreuses fonctionnalités, et qui est extrêment stable, mais qui souffre de certains manquent dans certains cas particuliers (Gestion de plugin spécifiques: Flex Builder, Android Platform, packaging spécifiques). Maven-eclipse-plugin est sûrement aujourd’hui une très bonne solution mais qui commence à se voir concurrencer par les plugins graphiques cités plus haut.

Share This

Une première application complète et fonctionnelle est sortie ce soir, il s’agit d’une application exploitant le système de micro-bloging ultra connu. Cerise sur le gâteau le code source de l’application est disponible sur le site de l’auteur!

Ce qui m’étonne le plus dans l’affaire, c’est qu’en regardant le code source de plus près, on s’aperçoit que le gentil développeur manie parfaitement le framework et ses concept malgré la quasi-existence d’exemple et de bonne pratique sur le web. Qui plus est il utilise même des fonctions qui ne sont pas documenté!Pas mal non?

Je fais référence à l’object RequestQueue qui traite les requêtes HTTP à haut niveau! Cette classe se trouve dans le package android.net.http.

• http://code.google.com/android/reference/android/net/package-summary.html

On note bien l’absence totale de documentation sur ce package, de plus une petite recherche sur Google montre bien une absence totale de documentation de cette classe sur le Web!

• http://www.google.fr/search?q=RequestQueue+android

En faisant un tour sur le blog de l’auteur pour récupérer les sources et lire le code, je m’aperçois qu’il à posté d’autres exemples pour le moins étonnant également, vu le peu d’info sur le net!

• http://davanum.wordpress.com/2007/11/21/
  (Pas de chance, je me suis fait grillé, cf: mon post d’hier sur mon développement utilisant Xml + Http. A noter que je n’ai pas utilisé les même techniques…)
• http://davanum.wordpress.com/2007/11/19/ (L’exemple montre comment afficher la localisation de StarBucks)
• http://davanum.wordpress.com/2007/11/15/ (Cet exemple ci montre comment trouver des pizza avec un GPhone ;) )
• http://davanum.wordpress.com/2007/11/14/ (Celui-ci montre comment envoyer un message par le protocole Xmpp)

En cherchant un peu d’infos sur l’auteur on se rend compte assez rapidement que ce n’est pas n’importe qui puisque c’est le co-fondateur (Davanum Srinivas) de la société WSO2. Toute personne qui s’y connaît un tant soi peu en stack web service Java, aura compris qu’il s’agit de la société qui s’occupe des développements d’Axis (entre autre). D’un coup on comprend mieux! (Désolé, j’utilise la stack XFire ou plutôt CXF maintenant).

• http://www.linkedin.com/in/davanum

Châpeau bas pour ces contributions!

Share This

Le lien d’une news qui me fait tiquer:

•  http://www.pointgphone.com/2007/11/android-sans-java-c-possible/

Et vous, qu’en pensez-vous? Trouvez-vous cela bien intéressant ?

Pour ma part, je ne comprends pas vraiment l’intérêt de la chose… Développer un programme C ou installer un package pour un système Linux: ok, je comprends bien (Et cela reviendra au constructeur du téléphone de le permettre ou non), mais tenter de se passer d’un framework sur un système qui est spécialement fourni comme support de base de ce framework, franchement je ne comprends pas vraiment bien la chose.

Un support d’accès natif est toutefois prévu, mais dans l’optique d’étendre les possibilités d’une application Android par exemple, via des appels système, et non  pour installer des outils tiers, à moins que cela apporte un avantage direct. Mais là encore, c’est au constructeur de définir le périmètre des fonctionnalités qu’il souhaite mettre à disposition dans son matériel.

De plus, Google a déjà incorporé un outil similaire à BusyBox dans son émulateur et sa plateforme en général qui est ToolBox! Il serait intéressant de connaitre la vision de Google à ce sujet: Linux est-il uniquement un support pour Android, ou bien est-ce un système destiné à être extensible par n’importe qui!

Share This

Je me suis essayé à développer une application test pour mieux cerner les capacités de la plateforme.

Il se révèle plutôt simple de développer avec Android, mais le manque d’exemple fait cruellement défaut. Cependant, on peut rapidement se débrouiller et trouver des solutions…

Je me suis donc amusé à charger un document XML d’un site internet bien connu des parisiens, et je l’ai affiché sous forme d’une liste. En voici le résultat:

Share This

Afin de compléter un peu la liste des ressources que j’ai pu trouver sur Internet à propos d’Android, je vous propose de nouvelles :

• http://ohadev.org et son forum, qui se veut un site de ressources pour développer des applications Android.
• http://www.androidapps.org, un site/blog qui se veut répertorier les différentes applications Android.
• http://androidguys.blogspot.com, un autre site discutant de la plateforme.

Le point commun de ces différents sites est la langue, ils sont tous 3 anglophones. Les sites anglophones ont tendance à fleurir souvent bien plus vite, cependant PointGPhone (http://www.pointgphone.com) est un site francophone qui semble plutôt bien fait, je vous conseille donc d’aller y faire un tour si l’anglais vous donne mal à la tête ! Le site présenté sous forme de blog fait une assez bonne synthèse des infos à propos d’Android. Il semble déjà avoir un lectorat régulier. Cerise sur le gâteau, il a design agréable et moderne.

Share This