Ceci est la 2nde partie d'un lot de 7 tutoriels.
Vous pouvez repartir de l'étape précédente ou tirer la solution contenue dans le tag 1-Initialization
La solution de cette partie est disponible sur le commit 2-Timber_Stetho_StrictMode.
Nous avons actuellement un projet Hello-World sans fioritures. Avant d'aborder le coeur de l'application, nous allons compléter l'outillage avec Stetho, Timber et le Strict Mode.
Rappel : utilité des outils
Timber, le logging pour développeur fainéant malin
Créé par Jake Wharton, cet outil de logging est diablement simple (et efficace). Son utilisation se fait en deux étapes :
- Initialisation au plus proche du démarrage de l'application,
- Appel des méthodes statiques de la classe Timber.
On peut ajouter des "Tree"(s) à notre instance Timber. Par défaut, aucun n'est ajouté. Le "DebugTree" détecte automatiquement la classe d'appel et s'en servira comme identifiant de Tag.
Stetho, pour inspecter sa base de données facilement
Android intègre nativement SQLite 3 comme base de données. En revanche, aucun outil n'est fourni pour inspecter son contenu. Stetho, une librairie développée par Facebook, permet de regarder ce que contient une base de données SQLite via Google Chrome desktop:
En revanche, stetho ne permet pas de faire des requêtes SQL ni de manipuler les données.
Strict Mode, pour prévenir la surconsommation
Strict Mode prévient les accès indésirables au disque / réseau dans le main thread. Il aide aussi à détecter la surconsommation de lectures / écritures.
Ajout des dépendances gradle
Ajouter les dépendances suivantes dans app/build.gradle :
Activation des outils
Stetho et Timber nécessitent d'être initialisés au niveau de l'application. Nous commençons donc par créer une classe Application personnalisée qui viendra remplacer celle par défaut :
- Dans fr.ippon.androidaacsample.coinsentinel, créer une classe "CoinSentinelApp".
- La remplir avec le contenu suivant :
- Nous redéfinissons la fonction onCreate. Nous activons ces outils qu'en développement. Pour cela, nous vérifions que la configuration de build est DEBUG.
- StrictMode peut avertir le développeur via des logs (penaltyLog()) ou stopper l'application (penaltyDeath()). Consultez le lien suivant pour plus d'informations.
La seconde étape est de s'assurer que notre application utilise notre classe personnalisée au lieu de celle par défaut. Dans app/src/main/AndroidManifest.xml, ajouter la ligne suivante dans le noeud "application" :
Depuis l'API 21, des backups de l'application sont faits automatiquement. D'après la documentation, ils incluent :
- Les Shared Preferences.
- Les fichiers stockés dans le stockage interne de l'application
- Les fichiers de base de données .
- Les fichiers stockés dans le stockage externe de l'application.
Ces données sont poussées (dans la limite de 25mo) sur le Google Drive de l'utilisateur. Un répertoire spécifique est créé pour l'application.
Dans notre cas, nous n'en n'avons pas besoin. Nous faisons au plus simple, nous le désactivons :
Votre manifest doit maintenant ressembler à ceci :
Vous pouvez désormais inspecter l'application dans Google Chrome.
Conclusion
Bien que non nécessaires, ces outils sont utiles (essentiels) pendant le développement. La prochaine étape est la configuration de l'injection de dépendances. Nous utiliserons Dagger 2.
