Présentation Android

Ce billet présente mon retour sur la demi journée de séminaire que j’ai pu suivre mardi chez nos confrères de Valtech Training animé par Olivier Penhoat.

Le marché du smartphone.

Android arrive sur un marché difficile étant donné la place prépondérante des OS historiques. Là où l’iPhone a percé avec insolence, révolutionnant les standards, Android peine à démarrer.

Dans un premier temps, n’oublions pas que l’on parle de deux sujets différents : d’un côté il y a toute une stratégie marketing avec un OS destiné à un objet unique, et de l’autre un OS disponible sur de multiples plateformes intégrant chacune des périphériques différents qu’il faut pouvoir orchestrer de façon identique.

De plus, cet OS n’est pas destiné spécifiquement aux smartphones comme on aurait tendance à le penser en premier lieu mais à une multitude d’appareils mobiles (tablettes, GPS, ordinateur de bord automobile, …).

Contrairement à ce que l’on peut penser à première vue, il semblerait que le marché à venir concerne ces divers appareils encore plus que les smartphones !

Google nous propose donc ici un système qui se veut ouvert :

  • Applications (internes et tierces) toutes logées à la même enseigne (accès à toutes les ressources)
  • Personnalisation poussée du bureau
  • Applications modérées à postériori
  • Pas d’IDE/OS imposé pour les développements
  • Développement sur des standards du marché (Java/XML)

Comment cela se présente-t-il ?

Le système

L’architecture est basée sur un noyau Linux récent, agrémenté des divers drivers fournis par les constructeurs. Ensuite il y a une couche de libraires dont le « runtime Android » contenant une VM optimisée (Dalvik), puis une couche identifiée comme le SDK Android permettant un accès via le langage Java aux développeurs.

Attention néanmoins, la VM Dalvik est assez spécifique :

  • Bytecode propriétaire
  • Fonctionne sur un registre et non une pile pour optimiser la mémoire.
  • Une instance de VM par processus.

L’outillage

Il est plutôt complet, on note entre autres :

  • Android Debug Bridge : envoi de commandes sur l’appareil (ou son émulation).
  • Un émulateur (permettant de simuler les différentes versions, matériels) avec déploiement à chaud.
  • Dalvik Debug Monitor Service : affiche notamment les logs de la VM.
  • Android Development Tools : plugin pour IDE au choix permettant de gérer une structure de projet Android et de mettre en place les IHM visuellement.

Composition d’une application

Le fichier manifest

Il sert de contrat pour l’application. Toutes les ressources que l’application va utiliser doivent y être déclarées : géolocalisation précise ou non, accéléromètre, appels, …

Une orchestration via des « intentions »

Les intentions sont très similaire à REST, il s’agit d’une ressource identifiée par son URI liée à une action simple (MAIN retourne à l’accueil, PICK sélectionne la ressource, EDIT …).

4 composants proposés comme cadre :

  • Les activités : le cœur de l’application, en général une activité est fortement liée à un écran.
  • Les fournisseurs de contenu : le nom est plutôt explicite, il va géré les accès aux différents contenus pour  donner un accès simplifié à l’application.
  • Les services : ce sont les processus lancés en tâche de fond, tournant même quand l’application n’a plus la main.
  • Les récepteurs d’intention : prennent en compte des évènements extérieurs (appel entrant).

Limites

La fragmentation

La première limitation vient de l’objectif même d’Android : la multiplication des appareils sur lesquels il est amené à fonctionner et donc des configurations différentes à gérer par le développeur, notamment les tailles d’écran, présence d’accéléromètre, …

On appelle cela la fragmentation et elle se multiplie encore avec les différentes versions d’Android proposées par les constructeurs : v1.5 : 30%, v1.6 : 54%, v2.0.1 : 15% …

Il faudra donc composer avec toutes ces configurations !

Android Market

La place de marché pour les applications Android, mis en place par Google souffre de nombreuses lacunes mettant un frein à son développement :

  • Mauvaise gestion des commentaires
  • Achat uniquement via le système de paiement Google (Checkout)

Conclusion

Olivier nous a fait une démonstration rapide et efficace de la mise en place d’une application Android. Le résultat est flagrant, il parvient très rapidement à afficher une carte Google Maps avec notre dernière position géographique donnée par le GPS …

Pendant la session, il nous a confirmé plusieurs fois que le développement était très simple malgré la fragmentation, qui est plutôt bien gérée par le SDK, pour faire des choses simples. Le pendant de ce système ouvert reste sa complexité quant on veut faire des choses qui sortent du cadre.

De plus, il ne faut pas oublier que l’on déploie une application sur un mobile et non un serveur d’application ! Il faudra donc, même si l’on travaille en Java, repenser notre façon de développer afin d’optimiser certaines structures de code.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *