Bonnes pratiques, Android – Un résumé des bonnes pratiques pour le développement d’application mobile sous Android

by Posted on

Un article consacré aux “Best Practices” dans le développement d’applications Android, provenant toujours de la même source Futurice.

1. Utiliser Gradle

L’utilisation de Gradle est un pré-requis. Il vaut mieux oublier Ant, plus limité et verbeux. En effet, avec Gradle :

  • Créer différentes variantes de votre application
  • Exécuter facilement des tâches sous forme de script
  • Gérer les dépendances
  • Bref simplifiez-vous la vie…

Par ailleurs et non des moindres, le plugin Gradle est activement soutenu et développée par les équipes Google. On aurait tort de se priver d’une telle aide.

2. Structure des projets, Gradle encore

Là encore, qui est In, qui est Out ?
La traditionnelle structure de projet proposé par Ant & Eclipse est à abandonner au plus vite et il est fortement conseiller de rejoindre la structure de projet proposé par la combinaison Gradle & Android Studio.

La structure de projets type Gradle selon Futurice

		├─ library-foobar
		├─ app
		│  ├─ libs
		│  ├─ src
		│  │  ├─ androidTest
		│  │  │  └─ java
		│  │  │     └─ com/futurice/project
		│  │  └─ main
		│  │     ├─ java
		│  │     │  └─ com/futurice/project
		│  │     ├─ res
		│  │     └─ AndroidManifest.xml
		│  ├─ build.gradle
		│  └─ proguard-rules.pro
		├─ build.gradle
		└─ settings.gradle

La différence principale est que dans une structure “Gradle”, chacune de ressources est séparée dans un répertoire. Ce qui permet par exemple de gérer distinctement les ressources nécessaires à une version payante ou gratuite de votre application.

Par ailleurs, gérer l’application dans un répertoire de haut niveau permet de faire la distinction avec les librairies utilisées par votre application. Le fichier settings.gradle est présent pour conserver les références à ces répertoires de librairies , fichier auquel se réfère app/build.gradle.

3. Configuration de Gradle

3.1 Structure général
Le plus simple est de “play by the book” comme disent les anglophones en suivant
Follow Google’s guide on Gradle for Android
http://tools.android.com/tech-docs/new-build-system/user-guide

3.2 Exécution de tâches via des scripts
Mieux vaut utiliser Gradle qu’une collection de scripts en Shell, Python….etc
Une documentation complète vous indique la marche à suivre.
Source : Writing Gradle build scripts

3.3 Gestion des mots de passe
La solution est de créer un fichier gradle.properties qui sera automatiquement importé par Gradle et pourra donc être appelé dans le fichier build.gradle.

3.4 Gestion des dépendances
Il est grandement souhaitable d’utiliser Maven pour la gestion de dépendances que d’importer directement les fichiers jar.

Source : Android Maven Plugin – android-maven-plugin

Il faut absolument éviter de laisser le soin à Maven de gérer dynamiquement les versions des dépendances. Mieux vaut une gestion manuelle des dépendances via Maven qui garantie un environnement de développement stable, prédictif et reproductible.

4. IDEs et editeurs

Le choix d’un éditeur reste un choix personnel, toutefois cette éditeur doit respecter la structure du projet qui est celle des projets Gradle.

Bien évidemment, le choix se porte naturellement vers Android Studio, qui est en adéquation avec Gradle, c’est du google made de bout en boit. Android Studio fournit un environnement stable et adapté au développement Android.

Source : Android Studio

5. Libraires

Voilà une partie qui est intéressante, le choix de librairies est déterminant. Voilà l’assortiment proposé par Futurice.

5.1 Les librairies JSON (JSON libs)
A première vue, la première librairie à sélectionner judicieusement lorsque vous concevez une application “API-centric”, c’est la librairie qui va convertir des objets en JSON et inversement. Futurice en fournit une “shortlist” qui font le taff :

  1. Jackson est une librairie bien connue pour le parsing de JSON
    http://wiki.fasterxml.com/JacksonHome
  2. Gson est une alternative tout à fait acceptable à Jackson
    https://code.google.com/p/google-gson/

Libre à vous de choisir la librairie de votre choix, Jackson semble avoir les faveurs de Futurice notamment sur les 3 aspects suivants : le “streaming”, le “in-memory tree model”, et le traditionnel “JSON-POJO data binding”.

Deux autres librairies alternatives aux deux précédentes :

5.2 Les librairies de réseau (network libs)
L’autre aspect une fois la conversion JSON objet effectué est bien la performance optimale des requêtes faites au serveur. Il existe des solutions éprouvées à étudier très sérieusement pour répondre à cette problématique primordiale.

Parmi les librairies, il existe Volley ou Retrofit. Volley fournit aussi tout le “câblage” nécessaire au chargement et à la mise en cache des images. La trio gagnant selon Futurice serait Retrofit, Picasso pour le chargement des images et le cache des images et OkHttp pour l’optimisation des requêtes HTTP.

Les 3 librairies Retrofit, Picasso et OkHttp sont produites par la même société, donc l’articulation entre les 3 est plutôt évidente.

OkHttp peut aussi être utilisé avec Volley.

D’autres librairies (libs) sont recommandées, notamment RxJava, qui se trouve être une librairie développée par Futurice ! En substance RxJava est une librairie dit de “Reactive Programming”, grosso modo pour gérer des événements asynchrones. Futurice préconise aussi quelques précautions à l’usage de RxJava, puissante mais déroutante.
A lire à cette égard, quelques-uns de leurs articles de blog :

Une autre librairie Retrolambda qui permet d’utiliser une syntaxe d’expression lambda dans Android et dans d’autres plateformes pre-JDK8. Pourquoi ? C’est l’assurance de maintenir un code concis et lisible particulièrement si vous utilisez un style fonctionnel avec RxJava par exemple.

5.3 Les librairies de réseau (methodlimitation)
Selon la définition même du site officiel d’Android, ce chiffre de 65 536 représente le nombre total de références qui peuvent être invoquées dans le code dans un seul fichier bytecode Dalvik Executable (dex).
C’est un peu un plafond de verre, il faut donc éviter d’utiliser trop de librairies au risque d’accroitre inutilement le nombre de méthodes et donc de vous rapprocher du même coup de cette limite fatale. Futurice préconise d’utiliser un nombre limité de librairies ainsi que de se servir d’un outil de décompte pour rester en deçà du chiffre fatidique. A bannir, l’utilisation de la librairie Guava, dans la mesure ou elle possède 13k méthodes.

On marque une pause dans le déroulé des sujets traités. En effet, Futurice s’intéresse aux sujets parfois controversés entre les développeurs : l’architecture des projets, la gestion des resources… Chacun de ces sujets doit être en effet discutés toutefois c’est aussi à la discrétion du développeur, en espérant que celui-ci choisisse les bonnes pratiques. je vous invite vivement à lire cette partie si vous souhaitez entamer la création ou la refonte d’une application Android.

6. Test frameworks

La framework de test du SDK Android est encore à ses balbutiements, notamment au regard des test UI (User Interface).

Android Gradle implémente actuellement une tâche nommé connectedAndroidTest qui exécute les tests que vous avez créés avec JUnit, via une extension de JUnit au travers des helpers d’Android. Il existe une procédure pour la mise ne place de ces tests dont voici les principaux liens :

N’utiliser Robolectric que pour les tests unitaires. En effet, Robolectric est un framework qui fournit des tests déconnectés du terminal. L’avantage est que cela accroit considérablement la vitesse de développement. Toutefois, bien qu’adéquat pour des tests unitaires dans un modèle MVC, les tests sous Robolectric sont incomplets et imprécis quand il s’agit de tests UI (User Interface).

Pour les tests UI, Robotium facilitera l’écriture de ce type de tests. Robotium vous sera bénéfique en raison de la profusion des “helpers” susceptibles d’analyser les vues et dans le contrôle de l’écran.

Les cas de test devront aussi simple que cela :

solo.sendKey(Solo.MENU);
solo.clickOnText("More"); // searches for the first occurrence of "More" and clicks on it
solo.clickOnText("Preferences");
solo.clickOnText("Edit File Extensions");
Assert.assertTrue(solo.searchText("rtf"));

7. Emulators

Une fois n’est pas coutume, on va citer un article précédent de ce site qui présente Genymotion. Cet émulateur Android fera amplement l’affaire à défaut d’avoir les vrais terminaux.

8. Proguard configuration

ProGuard est majoritairement utilisé sur de projets Android afin de réduire, de “obfuscate” le code, en clair l’obscurcir pour le protéger !

Il est habituel de configurer Gradle à utiliser ProGuard lorsque on “build” une apk pour la production.

Il existe aussi un autre outil nommé DexGuard, très puissant pour l’optimisation et l’obscurcissement du code. C’est disons la version payante de ProGuard.

9. Utiliser Stetho

Stetho est un ambitieux projet, soutenu par Facebook, pour le debogage des applications Android qui s’intègre parfaitement avec la suite des Developer Tools de Chrome.

Il est possible avec Stetho de ce que vous faites habituellement à l’aide de Developer Tools de Chrome pour un site web à savoir inspecter l’app pour mesurer l’activité réseau, les bases de données SQLite ou les préférences partagé par votre application.

Bien sur un conseil, assurez-vous que Stetho est uniquement disponible dans un build de développement et dans la build de production.

En savoir plus

Published by Bruno Flaven

Bruno Flaven has been a Project Manager in a wide variety of Internet business applications both in Mobile and in Desktop for 20 years now. You can find more information about his professional life on his personal website (www.flaven.fr) or his linkedin profile: https://fr.linkedin.com/in/brunoflaven. He is currently working In France Media Monde (FMM) mostly on mobile applications (iOS and Android). He is currently P.O for a Backoffice project made with Symfony. He also made few trainings to facilitate the handling of the tools that he helps to make.

Related Posts