Android | 5 pratiques dev qu’il faut arrêter maintenant !

Post Tags

Pretty Posts

By Sosta - November, 30th 2014

Ohayo,

Le monde des developpeurs est vaste ! On y trouve des espèces vraiment variées (perso je fais partie de la garde de la nuit :D) .. Je parle pas de la différence entre développeurs Web, Mobile ou etc. Non je parle de certains concepts dans lesquels certains sont encore prisonniers volontaires… Sur Android, voici quelques pratiques encore faites et qui devraient vraiment cesser, raison à l’appui:

Utiliser les AsyncTask : les asyncTask sont faits pour effectuer des traitement en dehors de la main Thread. Sur les trois méthodes d’une asyncTask, seule “doInBackground” est traitée dans un Thread différent, ce qui veut dire qu’un asyncTask garde une référence avec l’activité qui l’a lancé. Si donc pour une raison quelconque l’utilisateur quitte l’activité ou qu’il change l’orientation de son mobile (amenant l’activité à se détruire puis se recréer), la méthode “OnPostExecute” qu’il devra appeler n’existera pas causant une belle exception. Le lien tacite qui existe entre l’AsyncTask et l’activité qui l’a lancée rend vulnérable cette fonctionnalité. Utilisez là pour des requêtes brèves et toutes rapides, c’est encore tolérable; mais pour de bonnes taches de fond, utilisez les services !

Utiliser les sorties java standards (system.out.println et system.err.println) pour déboguer : Elles sont comme leur noms l’indiquent: des sorties standards java, oui oui les mêmes que vous utilisiez pour afficher du texte en exécutant vos codes java. Bien qu’elles soient “prises en compte” par le système Android et affichés en tant que logs, vous n’avez aucun contrôle sur elles. En effet,vous ne pouvez pas définir le type de log qu’elles génèrent (debug, info, warning, etc) et pire si vous les utilisez, vous n’avez aucun moyen d’empêcher qu’elles soient visibles sur votre appli en production (proguard n’y fera rien). Du coup, si vous êtes du genre à tout logger, il suffira à un quelqu’un de brancher son device à un IDE et de se faire reconstituer toute votre architecture. Utilisez donc la classe Log, elle a été créée pour ça.

Effectuer plusieurs appels réseau : Plus vous en ferez, plus votre application consommera de l’énergie. Faites en moins, et pour autant que possible effectuez toutes vos opérations en un jet au lieu de les échelonner ou d’en faire à tout bout de champ. Cette vidéo résume en très bien l’intéret. Si vous devez synchroniser vos données, pensez aux SyncAdapters ou raisonnez juste en fonction de l’état de la batterie (faible/en charge) et de l’heure…

Le splashscreen : oui oui, vous l’avez peut être déjà entendu, le splashcreen est tout simplement une mauvaise pratique et va à l’opposé de l’expérience utilisateur sur Android. Pas la peine de vous faire un exposé, je m’en vais tout simplement vous faire don de ceci et surtout de cela. Agréable lecture

Ajouter un bouton retour (back button) : généralement en haut à droite pour être conforme à iOS j’entends dire… Sauf que ce sont deux OS différents et que tout device Android, aussi chinois soit-il possède déjà un bouton retour tandis qu’un iPhone n’a qu’un seul bouton. Il est donc logique qu’une appli iOS propose un bouton retour à ses utilisateurs, mais totalement abruti de faire pareil sur Android. Un peu de respect pour chaque plateforme..

J’espère bien vous avoir donné des arguments suffisants pour mettre fin à ces pratiques; si vous ne vous sentez pas concernés eh bien j’aurai quand même réussi à vous voler 5min de votre temps, et ça c’est d’une satisfaction incroyable ! A très bientôt !!