Just Another Android App

Veuillez noter que ce projet n'est plus maintenu

Android Sample App avec architecture MVP

Exemple de projet qui affiche certaines images de l'API Dribble. Démontre des choses sympas que vous pouvez faire avec les bibliothèques modernes et l'outillage dans Android ces jours-ci.

Comme quelqu'un l'a dit sur Reddit: "Ce n'est pas sur-conçu, c'est juste un gratte-ciel sans la partie du gratte-ciel, juste les fondations :)"

Nouveaux ajouts:

• Plugin Android Gradle mis à niveau vers la v3.0.1
• Ajout de la prise en charge de la cuillère. Voir https://github.com/square/spoon pour plus de détails. Ajout du plugin Gradle pour cela. On peut exécuter les tests avec «Gradlew Spoon», puis ouvrir les rapports générés dans le répertoire «Build / Spoon».
• Ajout d'une capture d'écran lors de l'exécution de tests d'espresso dans Firebase
• Ajout de la couverture des tests pour les tests unitaires dans TeamCity CI Server
• Ajout d'un exemple d'autorisation d'exécution. Utilise la bibliothèque PermissionsDispatcher. Voir la classe RuntimePermissions Aactivity. (https://github.com/permissions-dispatcher/permissionsdispatcher)
• Restructuration des dépendances un bit, vérifiez le fichier de build.gradle et les dépendances.
• Ajout de la prise en charge des liaisons Android Dagger (Dagger V2.11)
• Ajout de la bibliothèque de factoire automatique le petit cousin de l'auto-valeur (https://github.com/google/auto/tree/master/factory) dans le projet pour aider avec l'injection assistée par Dagger (ce message l'explique assez bien: https://stackoverflow.com/questions/2279407/looking-for-an-exemple-forger-assistred)
• Ajout d'un test d'expresso à l'aide de la bibliothèque Okreplay (https://github.com/airbnb/okreplay) qui enregistre et rejoue les réponses du serveur. Voir com.example.features.dashboard.view.MainActivityOkreplaySpressOtest pour plus de détails.
• Ajout de la prise en charge des tests Firebase Cloud (Firebase.google.com/docs/test-lab/) via TeamCity! Désormais, chaque build de demande de traction / génération nocturne utilise le service pour exécuter des tests à expresso. Voir justeanotherAndroidApp_RuneSpressOtestSinfireBase.xml pour plus de détails.
• Ajout de la prise en charge de Burst Library (https://github.com/square/burst) pour les tests unitaires paramétrisés (voir com.example.util.stringutilstest pour plus de détails).
• Ajout de raccourcis d'application! Statique, dynamique et dynamique utilisé via la bibliothèque https://github.com/matthiasrobbers/shortbread! Pour plus de détails, veuillez consulter le bas de la classe d'applications, la Déclaration MainActivity @shortcut et le fichier shortcuts.xml.
• Ajout de 2 vérifications de charpie personnalisées sur les couleurs (vérifiez la classe non-MaterialColorsDetector et DirectMaterialPaletteColorusageDetector).
• Ajout d'une vérification de charpie personnalisée pour les couleurs codées en dur. (Vérifiez la classe HardcodedColorsDetector)
• Plugin gradle pour vérifier la taille de l'APK et échouer automatiquement à la construction si la taille APK est supérieure à une valeur spécifique (vérifiez le fichier build.gradle et gradle.properties pour la configuration et https://github.com/vanniktech/gradle-android-apk-size-plugin pour le plugin gradle réel).
• Ajout du support pour les scripts CI TeamCity commis dans VCS! Ils sont écrits dans Kotlin / XML (Vérifiez le dossier .TeamCity ou en savoir plus au bas de ce fichier)
• Ajout de Sherlock dans le projet afin que les développeurs (et QA) puissent avoir un accès facile aux exceptions qui se produisent (et les partager) via l'application (voir la classe d'application et le fichier build.gradle et https://github.com/ajitsing/sherlock pour le projet).
• Ajout de Traceur dans le projet qui permet d'afficher des stacktraces plus utiles avec Rxjava 2 (vérifiez la classe TraceUrtool et les autres classes connexes ou https://github.com/t-poon/traceur pour la bibliothèque).
• Ajout de la bibliothèque Chuck pour voir les appels réseau directement au téléphone. Voir https://github.com/jgilfelt/chuck pour la bibliothèque et la classe NetworkModule pour l'intercepteur supplémentaire.
• Désactiver les animations avant les tests d'espresso et les réactiver par la suite! (Voir Grant_animation_Permission.gradle et EspressOtesthelPer Class)
• Ajout des actions de Butter Knife (voir la classe des knons de beurre)
• Prise en charge des parties moqueuses de votre graphique de dague via la bibliothèque Daggermock (voir la classe MainActivityTest)
• Ajout de la disposition des contraintes! (Voir activité_main.xml)
• Ajout d'un planificateur RXJAVA qui informe Espresso via un comptage Resource sur quand faire une pause à l'exécution du test et attendre les tâches asynchrones à terminer (vérifier com.example.util.rx.rxilingscheduler)
• Projet amélioré pour utiliser le nouveau MVP MVP V3 !! Consultez https://github.com/sockeqwe/mosby pour plus de détails.
• Ajout de la prise en charge de la classe Rxjavaplugins, ce qui permet une priorité facile des planificateurs RXJava 2 dans les tests. Voir la méthode de configuration de la classe MainPresenteTTest.
• Ajout de quelques variations des carreaux de paramètres rapides. Voir https://medium.com/google-develovers/quick-settings-tiles-e3c22daf93a8 pour plus d'informations sur la fonctionnalité et la classe com.example.features.tiles.passiveleserviceonlytoggle pour la mise en œuvre (plus il y a quelques goodies dans le même package)

Contenu:

Bibliothèques:

• Rxjava
• Dagger 2 avec des exemples d'injection assistée et différents modules en fonction du type de construction. Prise en charge également Android Dagger v2.11
• Modifier 2 et mode MOCK RESTOFIT pour les constructions de débogage
• MOSBY MVP avec View State Support (V3!)
• Bois
• Valeur automatique et usine automatique
• Glisse avec un emballage
• Bouton de beurre
• Assertj pour les affirmations courantes
• Tissu (crashlytics et réponses)
• Rétrolambda
• Stetho
• Mandrin
• Sablé (https://github.com/matthiasrobbers/shortbread)
• PermissionsDispatcher pour les autorisations d'exécution (https://github.com/permissions-dispatcher/permissionsdispatcher)

Analyse statique:

• PMD (https://pmd.github.io/ - vérifiez le fichier static_analysis_java.gradle)
• CheckStyle (vérifiez le fichier static_analysis_java.gradle)
• Lint (vérification du fichier lint.gradle)
• Findbugs (vérifier le fichier static_analysis_java.gradle)
• Couverture de code Jacoco qui peut générer des rapports pour les tests unitaires, les tests d'espresso ou la combinaison des deux
• Un ensemble de règles d'inspection des IDE personnalisées
• Un module avec des règles et des tests de lunt personnalisés pour eux

Essai:

• Ajout de la prise en charge de la cuillère. Voir https://github.com/square/spoon pour plus de détails. Ajout du plugin Gradle pour la cuillère. On peut exécuter les tests avec «Gradlew Spoon», puis ouvrir les rapports générés dans le répertoire «Build / Spoon».
• Test Couverture exécutée dans TeamCity CI Server
• Espresso tests avec et sans simulation de serveur Web
• Mock Tests de serveur Web qui charge les réponses des fichiers JSON
• Tests robolécolaires
• Tests unitaires normaux
• OK intercepteur HTTP pour modifier l'URL de base dans les tests
• Ressources au ralenti
• Déverrouillage de l'écran pour les tests d'espresso (vérifiez la classe com.example.util.pressotestrunner)
• Prise en charge de la classe Rxjavaplugins, ce qui permet une priorité facile des planificateurs RXJava 2 dans les tests (vérifiez la classe MainPresenteTTest)
• Prise en charge d'un planificateur RXJava qui aide aux tests Espresso et à l'exécution de code asynchrone. (Vérifiez com.example.util.rx.rxidlingscheduler)
• Prise en charge des parties moqueuses de votre graphique de dague via la bibliothèque Daggermock (voir la classe MainActivityTest)
• Désactiver les animations avant les tests d'espresso et les réactiver par la suite! (Voir Grant_animation_Permission.gradle et EspressOtesthelPer Class)
• Ajout de Sherlock dans le projet afin que les développeurs (et QA) puissent avoir un accès facile aux exceptions qui se produisent (et les partager) via l'application (voir la classe d'application et le fichier build.gradle et https://github.com/ajitsing/sherlock pour le projet).
• Burst Library (https://github.com/square/burst) pour les tests unitaires paramétrisés (voir com.example.util.stringutilstest pour plus de détails).
• Ajout de la prise en charge des tests Firebase Cloud (Firebase.google.com/docs/test-lab/) via TeamCity! Désormais, chaque build de demande de traction / génération nocturne utilise le service pour exécuter des tests à expresso. Voir justeanotherAndroidApp_RuneSpressOtestSinfireBase.xml pour plus de détails.
• Ajout d'un test d'expresso à l'aide de la bibliothèque Okreplay (https://github.com/airbnb/okreplay) qui enregistre et rejoue les réponses du serveur. Voir com.example.features.dashboard.view.MainActivityOkreplaySpressOtest pour plus de détails.

Voir lié:

• Ajout de la disposition des contraintes! (Voir activité_main.xml)
• Ajout des actions de Butter Knife (voir la classe des knons de beurre)

Autre:

• Plugin gradle pour vérifier la taille de l'APK et échouer automatiquement à la construction si la taille APK est supérieure à une valeur spécifique (vérifiez le fichier build.gradle et gradle.properties pour la configuration et https://github.com/vanniktech/gradle-android-apk-size-plugin pour le plugin gradle réel).
• Icônes d'application séparées en fonction du type de construction
• Certaines sources avancées définissent la configuration pour diviser les tests
• Chargement de la configuration du projet à partir de fichiers de propriétés dans Android Manifest et Build.gradle
• Dossiers partagés pour certains types ou tests de construction
• Configuration de progrès de travail
• Annotations externes Android Studio (https://www.jetbrains.com/help/idea/2016.3/external-annotations.html)
• Annotations de niveau de package pour @Nullable et @Nonnull
• Intercepteur OKHTTP pour l'ajout de jeton AUTH aux en-têtes facilement
• Mode strict
• Plugin to Publish App sur le playstore
• Plugin Dex Count pour compter le nombre de méthodes dans l'APK
• Séparez l'arborescence de journalisation du bois pour Crashlytics. Voir com.example.tools.timbber.crashlyticStree
• Carreaux de paramètres rapides (voir com.example.features.tiles.passivetileServiceOnlyToggle)
• Ajout de Traceur dans le projet qui permet d'afficher des stacktraces plus utiles avec Rxjava 2 (vérifiez la classe TraceUrtool et les autres classes connexes ou https://github.com/t-poon/traceur pour la bibliothèque).
• Raccourcis d'applications! Statique, dynamique et dynamique utilisé via la bibliothèque https://github.com/matthiasrobbers/shortbread! Pour plus de détails, veuillez consulter le bas de la classe d'applications, la Déclaration MainActivity @shortcut et le fichier shortcuts.xml.

..et toutes sortes d'autres goodies!

TeamCity - Intégration continue

Le projet bénéficie de la fonctionnalité de TeamCity sur le stockage de la configuration du serveur CI dans Kotlin dans un système de contrôle de version. Voir https://confluence.jetbrains.com/display/tcd10/kotlin+dsl pour plus de détails. Les paramètres peuvent être trouvés dans le dossier .TeamCity dans le projet.

Construire des configurations:

Il y a 3 configurations de construction:

• Configuration de construction des «requêtes de traction» , déclenchée sur chaque demande de traction. Vérifie l'exactitude d'une demande de traction (généralement pour la branche «développer»). QA rapporterait l'APK pertinent à partir de HockeyApp créé par cette configuration de construction afin de tester manuellement la fonctionnalité / correction que la demande de traction introduit. Cette construction:
  • Exécute tous les outils d'analyse statique.
  • Effectue tous les tests unitaires pour tous les types de build.
  • Effectuez le nombre de méthodes pour tous les types de build.
  • Vérifie les doublons.
  • Construit des APK.
  • Exécute tous les tests Espresso sur le nuage de test de base de feu.
  • Télécharges APK sur HockeyApp.
  • Met à jour GitHub avec l'état du travail (succès / échec).
• La configuration de la construction de la «Nightly Builds », déclenchée tous les soirs à minuit sur la succursale «Develop». QA rapporterait l'APK pertinent à partir de HockeyApp créé par cette configuration de construction afin de tester l'intégration des fonctionnalités de l'application. Cette version est également déployée dans un groupe alpha de Playstore fermé à tester. Cette construction:
  • Effectue tous les tests unitaires pour tous les types de build.
  • Effectue le nombre de méthodes pour tous les types de build.
  • Vérifie les doublons.
  • Construit des APK.
  • Exécute tous les tests Espresso sur le nuage de test de base de feu.
  • Télécharges APK sur HockeyApp.
  • Les téléchargements publient APK sur un canal Alpha privé dans Playstore.
• La configuration de construction 'libère' , déclenchée sur chaque branche correspondant au nom de branche logique 'release / *'. QA chercherait l'APK pertinent de HockeyApp pour effectuer les tests finaux avant la version. Cette version est également déployée dans un groupe de playstore bêta ouvert à tester. Cette construction:
  • Exécute tous les outils d'analyse statique.
  • Effectue tous les tests unitaires pour tous les types de build.
  • Effectue le nombre de méthodes pour tous les types de build.
  • Vérifie les doublons.
  • Construit des APK.
  • Exécute tous les tests Espresso sur le nuage de test de base de feu.
  • Télécharges APK sur HockeyApp.
  • Les téléchargements publient APK vers la chaîne bêta publique dans Playstore.

Rapports:

Il y a aussi toutes sortes de rapports disponibles:

• Le rapport d'analyse statique de vérification montre tous les avertissements de contrôle du projet dans le projet. Sauverait généralement vide car il y a une politique de tolérance zéro dans le projet. Sur l'échec des constructions, il identifie les problèmes qui doivent être résolus.

• Les rapports de test unitaires pour tous les types de build affichent tous les tests exécutés avec des détails supplémentaires et Stacktraces si une erreur se produit. 2 Tableaux de bord, l'un est le rapport de test généré par TeamCity, l'autre est le rapport HTML JUNIT4 d'origine.

• Dex Method Counter Reports pour tous les types de build Affiche le nombre de méthodes pour chaque APK, ainsi qu'une visualisation de forage intéressante qui facilite les bibliothèques très faciles à repérer qui contiennent trop de méthodes. En tant que note, la libération généralement et les APK ont un nombre de méthodes plus faible dans ces rapports, car Proguard s'exécute dans ces types de build, en déshabillant des méthodes inutilisées.

• Le rapport d'analyse statique de Findbugs montre tous les avertissements Findbugs dans le projet. Sauverait généralement vide car il y a une politique de tolérance zéro dans le projet. Sur l'échec des constructions, il identifie les problèmes qui doivent être résolus.

• Le rapport d'analyse statique de peluche montre tous les avertissements de peluches dans le projet. Sauverait généralement vide car il y a une politique de tolérance zéro dans le projet. Sur l'échec des constructions, il identifie les problèmes qui doivent être résolus.

• Le rapport d'analyse statique PMD montre tous les avertissements PMD du projet. Sauverait généralement vide car il y a une politique de tolérance zéro dans le projet. Sur l'échec des constructions, il identifie les problèmes qui doivent être résolus.

• Il n'y a pas de rapport pour le moment pour les tests de cloud Firebase. Vous devrez entrer dans le journal de construction et localiser l'URL qui pointe vers le godet de stockage Google Cloud dans lequel les résultats sont enregistrés. Avec quelques modifications, on peut utiliser un seau de stockage personnel (payé), puis remettre les résultats du test dans TeamCity. Cet article aborde brièvement le sujet: http://building.usebutton.com/testing/cloud/android/ci/2016/04/20/teamcity-google-device-cloud/

Plugins TeamCity:

Quelques plugins TeamCity ont été utilisés pour me faciliter la vie:

• 'Advanced Shared Build Number': Voir https://java.nicholaswilliams.net/teamcityplugins/download un plugin qui vous permet de partager des compteurs de construction sur les builds. Comme ce compteur fait partie du code de version de l'APK, il est bon de les garder en synchronisation.
• 'Slack Notifications Plugin': Voir https://github.com/pegoo/tcslackbuildNotifier un plugin qui vous permet de publier des statuts de construction.
• 'Chuck Norris TeamCity Plugin': Voir https://github.com/dbf256/teamcity-chuck-plugin pas grand-chose à dire à propos de celui-ci ;-)

Notes:

• Public Beta Channel (https://play.google.com/apps/testing/com.justanotherandroidApp) peut ensuite (en théorie) être distribué à travers l'entreprise. Une chose que j'ai essayée a été d'ajouter le lien à une balise NFC et de suspendre cela sur le mur, afin que tout le monde puisse rapidement récupérer l'application bêta!

Hockeyapp

J'utilise HockeyApp pour sauver et (en théorie) distribuer les APK à l'AQ ou les parties prenantes. Voir https://hockeyapp.net pour plus de détails sur le produit. C'est à quoi il ressemble dans le tableau de bord du hockeyapp:

Comme vous pouvez le voir, il existe différentes versions pour les différentes configurations de build CI et tous les types de build. Les gars du hockeyapp ont eu la gentillesse de me fournir un compte gratuit pour démontrer l'utilisation de leur outil.

Playstore Avis dans Slack

Utilisation de Review Bot pour ceci (https://reviewbot.io/?utm_source=github&utm_medium=athkalia-Just-another-android-app) Pas grand-chose à dire, juste un outil super simple qui fait le travail. Quand une critique vient, il ressemble à ceci:

Feuille de route

• Passer à la dernière version de Gradle
• Authentification des empreintes digitales
• Bibliothèque

Soumettre PRS

Veuillez vous assurer que la commande gradlew check se termine avec succès avant de créer le PR. Cette commande exécute tous les tests pour toutes les variantes, plus les 4 outils d'analyse statique: peluche, vérification, PMD, Findbugs.

Liste de choses que je n'ajouterai pas, n'hésitez pas à contribuer si vous aimez l'une d'entre elles!

• Exécutez la couverture des tests dans les tests de cloud Firebase, récupérez les rapports (éventuellement les fusionner avec les rapports de couverture des tests unitaires) et remis en compte du serveur CI. Cela nécessiterait de payer un seau S3, et je ne suis pas certain de l'utilité de suivre cela pour être honnête.
• Automatiser les versions plus, comme le marquage des versions, la fusion pour développer, etc. Les exigences à ce sujet sont très spécifiques au projet, et étant donné qu'il peut y avoir des conflits, etc., ne vaut pas la peine d'automatiser pour l'instant.
• Captures d'écran automatique via l'outil "Fastlane - Screengrab" (https://github.com/fastlane/fastlane/tree/master/screengrab) Ils ne prennent pas en charge les fenêtres et je n'ai pas de mac :(

Toute demande de commentaires / traction est la bienvenue!

Vous pouvez m'attraper sur www.sakiskaliakoudas.com