Deuxième chronique de “dans les coulisses d’une app”. Après l’introduction de la semaine dernière, attaquons les choses sérieuses avec une première chronique consacrée au développement, et que nous avons découpée en deux parties. Et chose promise, chose due, cela commence tout nu sous la douche.

Alors que l’eau coulait sur sa peau diaphane et nue..

Juin 2013 : alors que je conseille et développe en entreprise, je bricole depuis presque deux ans des applications Android dans mon coin. J’ai débuté plusieurs projets mais ils sont tous trop gros pour être terminés rapidement.

Il me faudrait quelque chose d’assez simple pour être développé en quelques jours ou semaines, afin de tester et mettre en place tout ce dont j’aurai besoin pour de futurs projets.

Je vais prendre ma douche et, alors que l’eau coule, je me dis que je n’ai jamais trouvé une appli qui me fournisse mes statistiques CPU et mémoire comme sur mon PC.

HOLY MOTHER OF GOD ! Je n’ai qu’à m’en programmer une !

Grosso modo, l’idée originale

48 heures chrono

L’idée me plaît tellement que je prends à peine le temps de me sécher pour me ruer sur mon PC. Je fais alors une petite recherche sur stackoverflow pour vérifier la faisabilité du bouzin.

C’est le site sur lequel tous les développeurs vont. Il se présente comme une immense FAQ bien plus pratique que de la documentation classique. Vous tapez votre problème ou ce que vous voulez faire, et il y a une chance sur une pour qu’un développeur vous apporte une réponse satisfaisante avec pile les 10 lignes de code qui vont bien ! En 5 minutes à peine, j’ai la confirmation : Android étant basé sur Linux, il suffit de taper deux ou trois commandes hyper connues.

Dix minutes de vélo et je suis au Node, mon espace de coworking : en 2 h le prototype est plié ! À moi la gloire et la richesse ! À  cette allure, ma petite appli va sortir dans quelques semaines (et encore je vois large).

Il a fallu en effet quelques semaines :  35, pour être précis…

 

8 mois !

Mais comment peut-on mettre 8 mois pour afficher 42 sur un écran ?

D’abord, évacuons tout de suite deux trois contraintes dues à ma situation personnelle. Depuis juin, j’ai, quitté mon entreprise et rejoint une coopérative d’indépendants, travaillé sur d’autres projets Android (qui eux aussi devraient sortir “rapidement”), été papa pour la deuxième fois, conseillé des entreprises. Il y a tout simplement des semaines où je n’ai pas touché au projet et d’autres où je travaillais sur un autre aspect que le code. Au doigt mouillé, cela fait perdre trois à quatre mois.

Oui, mais il en reste quatre !

Certes, être développeur est bien plus facile qu’être illustrateur, mais il est quand même difficile de faire comprendre que des choses très simples côté utilisateur peuvent être très complexes côté développement. C’est un des objectifs de cette chronique.

Quand on fait toutes les trois secondes une opération qui en prend cinq…

L’exemple tout simple : on est vers juillet-août, et mon prototype est assez avancé. Mais il y a un souci. Les résultats sont incohérents ; parfois, ça pédale dans la choucroute… Bref, c’est bizarre. Je me lance pour ce que je crois une demi heure de tests pour voir d’où cela peut venir…

Eh bien, cela m’a pris 8 heures ! 8 heures ! De quoi finir avec les yeux rouges devant le PC à 23 h pour savoir d’où cela venait !

J’ai été obligé d’ajouter des tonnes de lignes spéciales un peu partout dans le code pour que l’app soit en mode “verbose”, c’est-à-dire qu’elle me détaille tout ce qu’elle fait.

Tout cela est hyper long et frustrant : si on met trop de lignes, on a tellement d’informations que l’on s’y perd, si on en met pas là où  il en faut, on manque de ce qu’on veut.

Il m’a donc fallu l’équivalent d’une journée de travail pour comprendre que la commande qui permettait d’obtenir l’occupation processeur (le fameux 42) prenait environ 5 secondes à s’exécuter. Or, selon la configuration, on la lance toutes les 1, 3 ou 5 secondes.

Et les effets sont dévastateurs :

• Avec 3 secondes, la valeur par défaut,  le système s’encroûte tranquillement en cachette. D’où les huit heures pour trouver le problème.
• Avec 5 secondes, il y une chance pour que vous lanciez un nouveau calcul au moment où le dernier se finit, ce qui…donne des résultats rigolos du type : CPU 122 %…
• Avec une seconde comme paramètre, le système est très rapidement surchargé. Au bout d’une minute, vous avez lancé le calcul 60 fois et il ne s’est exécuté que 12.

48 sont en attente et cela va en empirant… C’est ce qui m’a permis de voir d’où venait le problème.

Et encore, heureusement pour moi, une fois le problème repéré, il ne m’a fallu qu’une demi journée pour changer de méthode et vérifier que tout se passait mieux. J’ai eu de la chance, la nouvelle méthode ne prend que quelques millisecondes de calcul et ne demande pas de tout recommencer à zéro…

Cet exemple est évidemment extrême mais il n’est pas rare de passer plusieurs heures pour localiser et corriger précisément un problème. Et ce plusieurs fois par semaine !

Cent fois sur le métier tu remettras ton ouvrage

Depuis que j’ai commencé à travailler sous Android, le système a connu la bagatelle de 26 mises à jour, dont trois majeures.

L’Action Bar (la seule partie nette de l’image ci dessous) que vous avez maintenant sur 90 % des applications est apparue il y a 3 ans avec Android 3.0.

Sauf que Google n’avait pas fourni de code pour les versions antérieures qui représentent encore 30 % du marché.

Pour assurer la compatibilité, j’ai donc dû utiliser une librairie nommée ActionbarSherlock (développée par Jack Wharton)  et recommencer suite à la version fournie par Google : ActionbarCompat.

Avec le temps, cela s’arrange et les nouvelles versions chamboulent de moins en moins ce qui a été fait. Mais on a toujours un peu l’impression de construire un château de sable sur une plage : il faut tout refaire à chaque nouvelle vague/version d’Android.

Bref, le métier de développeur peut être l’enfer mais aussi le paradis ; on en reparle la semaine prochaine !

 

BONUS STAGE 1 : Au fait, avec quoi développe-t-on une application sous Android ?

On en parle assez peu ,mais quels outils utilise-t-on pour développer une application sous Android ?

Première bonne nouvelle, vous pouvez parfaitement utiliser des outils entièrement gratuits.

Si vous dégottez un PC /Mac milieu de gamme d’il y a deux ou trois ans, vous n’aurez en tout et pour tout qu’à débourser 25 dollars (moins de 20 euros) pour diffuser votre appli mondialement (oui, oui mondialement) via le Google Play. Sans vouloir troller, ce n’est pas vraiment le cas sous iOS (c’est 80 euros…par an et vous devez absolument avoir un Mac).

Vous avez donc votre ordinateur, vous avez créé un compte développeur, il vous reste à choisir l’environnement de développement. Kézako ? Un logiciel qui vous fournit tout ce dont vous avez besoin pour programmer : de quoi écrire le code, le débugger, l’installer sur un téléphone portable ou l’exporter sur le Google play, des émulateurs, des outils pour tester votre code en profondeur, etc.

Google n’en fournit pas moins de deux pour Android. Rien ne vous empêche de travailler avec autre chose mais l’écrasante majorité des développeurs Android utilise un de ces deux environnements.

Le tendance du moment, c’est Android Studio qui est en version bêta. Si vous voulez briller en société, dites que vous travaillez avec : il marque beaucoup de points dans la communauté notamment grâce à son implémentation native de Maven, un outil très prisé de gestion de projets informatiques complexes.

J’ai personnellement essayé deux fois et je n’ai jamais accroché mais un de mes camarades du BAUG est beaucoup plus enthousiaste. J’utilise le “vieil” ADT (Android developper Tools) qui se télécharge (gratuitement donc) ici. C’est historiquement le premier environnement de développement proposé par Google.

Il est basé sur Eclipse et  je l’ai configuré pour correspondre à mes besoins.

Il n’est pas parfait, il y a encore de vilains bugs, mais il dispose d’une telle communauté que si vous tombez sur un bug, une requête sur Google et le problème est réglé en dix secondes.

La java du développement

En ce qui concerne le développement en lui même, Android a été conçu pour que les applications soient développées en Java. C’est un langage Objet de la même famille que le C et le C++ qui sont utilisés massivement par les développeurs depuis plus de 40 ans.

Si vous voulez avoir une idée de ce qu’est la programmation, je ne peux que vous conseiller d’essayer ce jeu dans lequel vous devez diriger un chevalier avec du code javascript, très proche du java. Cela vaudra toutes les explications du monde.

Pour en revenir à nos moutons, Google fournit toute une série de librairies de fonctions (on se contente de dire librairies) pour travailler avec vos smartphones. L’objectif de ces librairies est de vous faciliter le travail en appelant leurs fonctions pour les tâches les plus communes et essentielles : afficher du texte à l’écran, donner la date et l’heure, savoir si le WiFi est allumé, prévenir quand un appel est en cours, etc.

Pour information, ces librairies ne sont pas parfaites. Il manque des fonctionnalités essentielles, certaines fonctions ont un comportement bizarre, la documentation est perfectible. On trouve par exemple des fonctions sans… aucune explication : cette fonction compare, d’accord, mais comment ?

 

L’auteur de cette chronique, Pierre Benayoun, est président du Bordeaux Android User Group ; il développe et conseille sur Android depuis la sortie du HTC G1 (qu’il possède toujours !). Vous pouvez le joindre sur Twitter à cette adresse !

---