creez-des-applications-pour-android

7 Annexes
technique efficace consiste à nommer le package comme est nommé votre site web, mais à l’envers.
Par exemple, les applications Google sont dans le package com.google.
7.1.1.1.3 Arrêtez la journalisation Supprimez toutes les sorties vers le Logcat de votre application
(toutes les instructions du genre Log.d ou Log.i par exemple), ou au moins essayez
de les minimiser. Alors bien entendu, enlever directement toutes les sorties vers le Logcat serait
contre-productif puisqu’il faudrait les remettre dès qu’on en aurait besoin pour déboguer… Alors
comment faire ?
Le plus pratique serait de les activer uniquement quand l’application est une version debug. Cependant,
comment détecter que notre application est en version debug ou en version release ? C’est
simple, il existe une variable qui change en fonction de la version. Elle est connue sous le nom
de BuildConfig.DEBUG et se trouve dans le fichier BuildConfig.java, lui-même situé dans
le répertoire gen. Vous pouvez par exemple entourer chaque instance de Log ainsi :
if(BuildConfig.DEBUG)
{
//Si on se trouve en version debug, alors on affiche des messages dans le Logcat
Log.d(...);
}
7.1.1.1.4 Désactivez le débogage N’oubliez pas non plus de désactiver le débogage de
votre application ! Ainsi, si vous aviez inséré l’attribut android:debuggable dans votre Manifest,
n’oubliez pas de l’enlever (il vaut false par défaut) ou d’insérer la valeur false à la place
de true.
7.1.1.1.5 Nettoyez votre projet Il se peut que vous ayez créé des fichiers qui ne sont pas
nécessaires pour la version finale, qui ne feront qu’alourdir votre application, voire la rendre
instable. Je pense par exemple à des jeux de test particuliers ou des éléments graphiques temporaires.
Ainsi, les répertoires les plus susceptibles de contenir des déchets sont les répertoires
res/ ou encore assets/.
7.1.1.1.6 Faire attention au numéro de version Le numéro de version est une information
capitale, autant pour vous que pour l’utilisateur. Pour ce dernier, il permet de lui faire savoir que
votre application a été mise à jour, et le rassure quant à l’intérêt d’un achat qu’il a effectué si
l’application est régulièrement mise à jour. Pour vous, il vous permet de tracer les progrès de
votre application, de vous placer des jalons et ainsi de mieux organiser le développement de votre
projet.
Vous vous rappelez les attributs android:versionName et android:versionCode ? Le premier
permet de donner une valeur sous forme de chaîne de caractères à la version de votre application
(par exemple « 1.0 alpha » ou « 2.8.1b »). Cet attribut sera celui qui est montré à l’utilisateur, à
l’opposé de android:versionCode qui ne sera pas montré à l’utilisateur et qui ne peut contenir
que des nombres entiers. Ainsi, si votre ancien android:versionCode était « 1 », il vous suffira
d’insérer un nombre supérieur à « 1 » pour que le marché d’applications sache qu’il s’agit d’une
version plus récente.
On peut par exemple passer de :
472