Just Another Android App

Bitte beachten Sie, dass dieses Projekt nicht mehr gewartet wird

Android -Beispiel -App mit MVP -Architektur

Beispielprojekt, bei dem einige Bilder aus der Dribble -API angezeigt werden. Demonstriert einige coole Sachen, die Sie mit den modernen Bibliotheken und dem Werkzeug in Android heutzutage machen können.

Wie jemand auf Reddit sagte: "Es ist nicht überbetont, es ist nur ein Wolkenkratzer ohne den Wolkenkratzerteil, nur die Grundlagen :)"

Neueste Ergänzungen:

• Verbessertes Android Gradle Plugin auf v3.0.1
• Unterstützung für Löffel hinzugefügt. Weitere Informationen finden Sie unter https://github.com/square/spoon. Auch das Gradle -Plugin dafür hinzugefügt. Man kann die Tests mit "Gradlewo Spoon" durchführen und dann die generierten Berichte im Verzeichnis "Build/Spoon" öffnen.
• Das Screenshot -Griff hinzugefügt, während sie Espressomestests in FireBase durchführen
• Die Testabdeckung für Unit -Tests auf dem TeamCity CI -Server hinzugefügt
• Ein Beispiel für die Laufzeitgenehmigung hinzugefügt. Verwendet die Berechtigungsdispatcher -Bibliothek. Siehe RunTimePermissions -Klasse. (https://github.com/permissions-dispatcher/permissionsDispatcher)
• Umstrukturierte Abhängigkeiten ein wenig, prüfen Sie Build.gradle -Datei und Abhängigkeiten.gradle -Datei
• Unterstützung für Dolch -Android -Bindungen hinzugefügt (Dolch v2.11)
• Die Auto-Faktorik-Bibliothek fügte hinzu, der kleine Cousin von Auto-Value (https://github.com/google/auto/tree/master/factory) in das Projekt, um bei der Dagger-assistierten Injektion zu helfen
• Einen Espresso -Test mit der Bibliothek von OKREPLAY (https://github.com/airbnb/okreplay) hinzugefügt, die Serverantworten aufzeichnet und wiederholt. Weitere Informationen finden Sie unter com.example.features.dashboard.view.mainActivityokreplayeStressotest.
• Unterstützung für Firebase Cloud-Tests (Firebase.google.com/docs/test-lab/) über TeamCity! Jetzt verwendet jeder Pull -Anfrage/ nächtliche Build/ Release -Build den Service, um Espresso -Tests auszuführen. Weitere Informationen finden Sie unter justanotherandroidapp_runespressotestsinfirebase.xml.
• Unterstützung für die Burst -Bibliothek (https://github.com/square/burst) für parametrisierte Unit -Tests (siehe com.example.util.StringUtilstest für weitere Details).
• App -Verknüpfungen hinzugefügt! Statisch, dynamisch und dynamisch über die https://github.com/matthiasrobbers/shortbread Library! Details finden Sie unter der App -Klasse, MainActivity @ShortCut Deklaration und Shortcuts.xml -Datei.
• 2 weitere benutzerdefinierte Lint -Überprüfungen um Farben hinzugefügt (nicht immaterielle CLORIALCOLORSDECTECTORS und DICIREMATEIALPALETECOLORUSAGEDETECTORS).
• Es wurde eine benutzerdefinierte Lint -Prüfung für hartcodierte Farben hinzugefügt. (HardcodedColorsDetektor der Klasse der Klasse)
• Gradle-Plugin, um die APK-Größe zu überprüfen und den Build automatisch zu bestimmen, wenn die APK-Größe mehr als ein spezifischer Wert ist (überprüfen Sie die Datei Build.gradle und Gradle.Properties für die Konfiguration und https://github.com/vanniktech/gradle-android-apk-size-plugin für das eigentliche Gradle-Plugin).
• Die Unterstützung für Teamcity CI -Skripte, die in VCS begangen wurden! Sie sind in Kotlin/XML geschrieben (teamCity -Ordner überprüfen oder am Ende dieser Datei mehr lesen).
• Sherlock in das Projekt hinzugefügt, damit Entwickler (und QA) einen einfachen Zugriff auf Ausnahmen haben können, die über die App auftreten (und diese freigeben) (siehe App -Klasse und die build.gradle -Datei und https://github.com/ajitsing/sherlock für das Projekt).
• Traceur in das Projekt hinzugefügt, das es ermöglicht, mehr nützliche Stacktraces mit Rxjava 2 anzuzeigen (die Traceurtool-Klasse und die anderen zugehörigen Klassen oder https://github.com/tspoon/traceur für die Bibliothek).
• Die Chuck Library fügte hinzu, um Netzwerkanrufe direkt am Telefon zu sehen. Weitere Informationen finden Sie unter https://github.com/jgilfelt/chuck für die Bibliothek und die NetworkModule -Klasse für den hinzugefügten Interceptor.
• Deaktivieren von Animationen vor Espresso-Tests und wiedererstimmen sie anschließend! (Siehe Grant_animation_permission.gradle und Espressothelper -Klasse)
• Butterknife -Aktionen hinzugefügt (siehe Butterkniagenklasse)
• Unterstützung für die Verspottung von Teilen Ihres Dolch -Diagramms über die Daggermock -Bibliothek (siehe MainActivityTest -Klasse)
• Hinzufügen von Einschränkungen! (Siehe Aktivität_Main.xml)
• Ein RXJAVA -Scheduler fügte hinzu, der Espresso über eine Zählung über die Ausführung von Tests informiert und auf die Beendigung asynchroner Aufgaben warten soll (prüfen Sie, dass com.example.util.rxidlingsschoner) prüfen soll.
• Verbessertes Projekt zur Verwendung des neuen Mosby MVP V3 !! Weitere Informationen finden Sie unter https://github.com/Sockeqwe/mosby.
• Unterstützung für die Rxjavaplugins -Klasse hinzugefügt, die eine einfache Übersteuerung von Rxjava 2 -Schedulern in Tests ermöglicht. Siehe Setup -Methode der MainPresenterTest -Klasse.
• Es wurden einige Variationen der Schnelleinstellungen hinzugefügt. Weitere Informationen zur Funktion und die Klasse für die Implementierung finden Sie unter https://medium.com/google-developers/quick-setts-tiles-e3c22daf93a8 für Informationen zur Funktion und die Com.example.Features.

Inhalt:

Bibliotheken:

• Rxjava
• Dolch 2 mit Beispielen für unterstützte Injektion und unterschiedliche Module, abhängig vom Bauart. Unterstützung auch für Android Dagger v2.11
• Nachrüstung 2 und den Nachrüstmodus für Debug -Builds nachrüsten
• Mosby MVP mit Sichtweise staatlicher Unterstützung (v3!)
• Holz
• Autowert und Autofabrik
• Mit einer Verpackung gleiten
• Butterknife
• Für fließende Behauptungen durchsetzen
• Stoff (Crashlytics und Antworten)
• Retrolambda
• Stetho
• Futter
• Shortbread (https://github.com/matthiasrobbers/shortbread)
• Berechtigungen für Laufzeitberechtigungen (https://github.com/permissions-dispatcher/permissionsDispatcher)

Statische Analyse:

• PMD (https://pmd.github.io/ - Datei static_analysis_java.gradle) überprüfen
• CheckStyle (Überprüfung der Datei static_analysis_java.gradle)
• Lint (Überprüfen Sie die Datei Lint.gradle)
• FindBugs (Überprüfen Sie die Datei static_analysis_java.gradle)
• Jacoco -Codeabdeckung, mit der Berichte für Unit -Tests, Espresso -Tests oder die Kombination der beiden generiert werden können
• Eine Reihe von Inspektionsregeln für benutzerdefinierte IDE -Inspektionen
• Ein Modul mit benutzerdefinierten Fusselregeln und Tests für sie

Testen:

• Unterstützung für Löffel hinzugefügt. Weitere Informationen finden Sie unter https://github.com/square/spoon. Außerdem wurde das Gradle -Plugin für Löffel hinzugefügt. Man kann die Tests mit "Gradlewo Spoon" durchführen und dann die generierten Berichte im Verzeichnis "Build/Spoon" öffnen.
• Testabdeckung im TeamCity -CI -Server, der ausgeführt wird
• Espresso -Tests mit und ohne Mock -Webserver
• Mock Web Server -Tests, bei denen Antworten von JSON -Dateien geladen werden
• Robolectric Tests
• Normale Einheiten -Tests
• OK HTTP -Interceptor zum Ändern der Basis -URL in Tests
• Leerlaufressourcen
• Entsperren des Bildschirms für Espresso -Tests (Überprüfen Sie die Klasse com.example.util.espressotestrunner)
• Unterstützung für die Rxjavaplugins -Klasse, die eine einfache Übersteuerung von RXJAVA 2 -Schedulern in Tests ermöglicht (Check MainPresentertest -Klasse).
• Unterstützung für einen RXJAVA -Scheduler, der bei Espresso -Tests und asynchronen Codeausführung hilft. (Check com.example.util.rx.rxidlingsschallscheuter))
• Unterstützung für die Verspottung von Teilen Ihres Dolch -Diagramms über die Daggermock -Bibliothek (siehe MainActivityTest -Klasse)
• Deaktivieren von Animationen vor Espresso-Tests und wiedererstimmen sie anschließend! (Siehe Grant_animation_permission.gradle und Espressothelper -Klasse)
• Sherlock in das Projekt hinzugefügt, damit Entwickler (und QA) einen einfachen Zugriff auf Ausnahmen haben können, die über die App auftreten (und diese freigeben) (siehe App -Klasse und die build.gradle -Datei und https://github.com/ajitsing/sherlock für das Projekt).
• Burst -Bibliothek (https://github.com/square/burst) für parametrisierte Unit -Tests (siehe com.example.util.StringUtilstest für weitere Details).
• Unterstützung für Firebase Cloud-Tests (Firebase.google.com/docs/test-lab/) über TeamCity! Jetzt verwendet jeder Pull -Anfrage/ nächtliche Build/ Release -Build den Service, um Espresso -Tests auszuführen. Weitere Informationen finden Sie unter justanotherandroidapp_runespressotestsinfirebase.xml.
• Einen Espresso -Test mit der Bibliothek von OKREPLAY (https://github.com/airbnb/okreplay) hinzugefügt, die Serverantworten aufzeichnet und wiederholt. Weitere Informationen finden Sie unter com.example.features.dashboard.view.mainActivityokreplayeStressotest.

Ansicht verwandt:

• Hinzufügen von Einschränkungen! (Siehe Aktivität_Main.xml)
• Butterknife -Aktionen hinzugefügt (siehe Butterkniagenklasse)

Andere:

• Gradle-Plugin, um die APK-Größe zu überprüfen und den Build automatisch zu bestimmen, wenn die APK-Größe mehr als ein spezifischer Wert ist (überprüfen Sie die Datei Build.gradle und Gradle.Properties für die Konfiguration und https://github.com/vanniktech/gradle-android-apk-size-plugin für das eigentliche Gradle-Plugin).
• Separate App -Symbole entsprechend dem Build -Typ
• Einige erweiterte Quellen legt die Konfiguration zum Aufteilen von Tests fest
• Laden Sie einige Projektkonfigurationen aus Eigenschaftsdateien in Android Manifest und Build.gradle
• Freigegebene Ordner für einige Buildtypen oder Tests
• Arbeiten proguard config
• Android Studio Externe Annotationen (https://www.jetbrains.com/help/idea/2016.3/external-annation.html)
• Annotationen der Paketebene für @nullable und @nonnull
• OKHTTP Interceptor zum Hinzufügen von Auth -Token zu den Headern einfach
• Strenger Modus
• Plugin zur Veröffentlichung der App im Playstore
• Dex Count -Plugin zum Zählen der Anzahl der Methoden in der APK
• Trennende Holzprotokollierungsbaum für Crashlytics. Siehe com.example.tools.timber.craslyticsTree
• Schnelle Einstellungen Kacheln (siehe com.example.Features.tiles.PassivetileServiceOnlytoggle)
• Traceur in das Projekt hinzugefügt, das es ermöglicht, mehr nützliche Stacktraces mit Rxjava 2 anzuzeigen (die Traceurtool-Klasse und die anderen zugehörigen Klassen oder https://github.com/tspoon/traceur für die Bibliothek).
• App Shortcuts! Statisch, dynamisch und dynamisch über die https://github.com/matthiasrobbers/shortbread Library! Details finden Sie unter der App -Klasse, MainActivity @ShortCut Deklaration und Shortcuts.xml -Datei.

..und alle möglichen anderen Leckereien!

Teamcity - kontinuierliche Integration

Das Projekt profitiert von der Funktion von TeamCity, die CI -Serverkonfiguration in Kotlin in einem Versionskontrollsystem zu speichern. Weitere Informationen finden Sie unter https://confluence.jetbrains.com/display/tcd10/kotlin+dsl. Die Einstellungen finden Sie im Ordner .teamCity im Projekt.

Konfigurationen erstellen:

Es gibt 3 Build -Konfigurationen:

• Erstellen Sie die Konfiguration "Pull Requests" , die bei jeder Pull -Anforderung ausgelöst wird. Überprüft die Richtigkeit einer Zuganfrage (normalerweise für den "Entwickler" -Ast). Die QA würde die relevante APK von HockeyApp abrufen, die von dieser Build -Konfiguration erstellt wurden, um die Funktion/Behebung, die die Pull -Anforderung einführt, manuell zu testen. Dieser Build:
  • Läuft alle statischen Analyse -Tools.
  • Führen Sie alle Unit -Tests für alle Build -Typen aus.
  • Führen Sie die Methodenanzahl für alle Build -Typen durch.
  • Überprüfungen auf Duplikate.
  • Baut apks.
  • Führen Sie alle Espressotests in Firebase Test Cloud aus.
  • Laden Sie APKs in HockeyApp hoch.
  • Aktualisiert GitHub mit dem Status des Jobs (Erfolg/Misserfolg).
• "Nightly Builds " -Enbaukonfiguration, die jede Nacht um Mitternacht in "Develop" -Ag -Filiale ausgelöst wird. QA würde die relevante APK von HockeyApp abrufen, die von dieser Build -Konfiguration erstellt wurden, um die Integration von Funktionen der App zu testen. Dieser Build wird auch in einer geschlossenen Alpha -Playstore -Gruppe eingesetzt, in der Personen testen können. Dieser Build:
  • Führen Sie alle Unit -Tests für alle Build -Typen aus.
  • Führen Sie die Methodenzahl für alle Build -Typen durch.
  • Überprüfungen auf Duplikate.
  • Baut apks.
  • Führen Sie alle Espressotests in Firebase Test Cloud aus.
  • Laden Sie APKs in HockeyApp hoch.
  • Laden Sie die Release APK auf den privaten Alpha -Kanal in Playstore.
• "Releases" Build -Konfiguration, ausgelöst in jedem Zweig, der mit dem Namen "Release/*" entspricht. QA würde die relevante APK von HockeyApp abrufen, um die endgültigen Tests vor der Veröffentlichung durchzuführen. Dieser Build wird auch in einer offenen Beta -Playstore -Gruppe eingesetzt, in der Personen testen können. Dieser Build:
  • Läuft alle statischen Analyse -Tools.
  • Führen Sie alle Unit -Tests für alle Build -Typen aus.
  • Führen Sie die Methodenzahl für alle Build -Typen durch.
  • Überprüfungen auf Duplikate.
  • Baut apks.
  • Führen Sie alle Espressotests in Firebase Test Cloud aus.
  • Laden Sie APKs in HockeyApp hoch.
  • Laden Sie die Release APK in den öffentlichen Beta -Kanal in PlayStore.

Berichte:

Es gibt auch alle möglichen Berichte:

• Der statische Analysebericht für Checkstyle zeigt alle CheckStyle -Warnungen im Projekt. Würde normalerweise leer zurücklegen, da das Projekt eine Null -Toleranz -Richtlinie enthält. Bei fehlgeschlagenen Erstellungen wird die Probleme festgelegt, die behoben werden müssen.

• Unit -Testberichte für alle Build -Typen zeigen alle Tests, die zusammen mit zusätzlichen Details und Stacktraces durchgeführt wurden, falls ein Fehler auftreten. 2 Dashboards, einer ist der von TeamCity generierte Testbericht, der andere ist der ursprüngliche JUNIT4 HTML -Bericht.

• Die Dex -Methoden -Zählerberichte für alle Build -Typen zeigen die Methodenanzahl für jede APK sowie eine interessante Bohrer -Down -Visualisierung, mit der es sehr einfach ist, Bibliotheken zu erkennen, die zu viele Methoden enthalten. In dieser Hinsicht haben in diesen Berichten in diesen Berichten in der Regel veröffentlicht und QA -APKs eine kleinere Methode zählt, da Proguard in diesen Buildtypen ausgeführt wird und unbenutzte Methoden entzieht.

• Der statische Analysebericht für FindBugs zeigt alle FindBugs -Warnungen im Projekt. Würde normalerweise leer zurücklegen, da das Projekt eine Null -Toleranz -Richtlinie enthält. Bei fehlgeschlagenen Erstellungen wird die Probleme festgelegt, die behoben werden müssen.

• Der Bericht über statische Analyse von Lint zeigt alle Linuktwarnungen im Projekt. Würde normalerweise leer zurücklegen, da das Projekt eine Null -Toleranz -Richtlinie enthält. Bei fehlgeschlagenen Erstellungen wird die Probleme festgelegt, die behoben werden müssen.

• Der statische Analysebericht von PMD zeigt alle PMD -Warnungen im Projekt. Würde normalerweise leer zurücklegen, da das Projekt eine Null -Toleranz -Richtlinie enthält. Bei fehlgeschlagenen Erstellungen wird die Probleme festgelegt, die behoben werden müssen.

• Derzeit gibt es keinen Bericht für die Firebase Cloud -Tests. Sie müssen in das Build -Protokoll eingehen und die URL suchen, die auf den Google Cloud -Speicher -Bucket hinweist, in dem die Ergebnisse gespeichert sind. Mit wenigen Änderungen kann man einen persönlichen (bezahlten) Speicher -Bucket verwenden und dann die Testergebnisse wieder in TeamCity ziehen. Dieser Artikel berührt kurz das Thema: http://building.usebutton.com/testing/cloud/android/ci/2016/04/20/teamcity-google-device-cloud/

Teamcity -Plugins:

Ein paar Teamcity -Plugins wurden verwendet, um mein Leben zu erleichtern:

• 'Advanced Shared Build Number': Siehe https://java.nicholaswilliams.net/teamcityplugins/download Ein Plugin, mit dem Sie Build -Zähler über Builds hinweg freigeben können. Da dieser Zähler Teil des Versionscode des APK ist, ist es gut, sie synchron zu halten.
• 'Slack Benachrichtigungen Plugin': Siehe https://github.com/petegoo/tcslackbuildnotifier Ein Plugin, mit dem Sie den Baustatus auf Slack veröffentlichen können.
• 'Chuck Norris TeamCity Plugin': siehe https://github.com/dbf256/teamcity-chuck-plugin nicht viel zu sagen ;-)

Anmerkungen:

• Öffentlicher Beta -Kanal (https://play.google.com/apps/testing/com.justanotherandroidapp) kann dann (theoretisch) über das Unternehmen verteilt werden. Eine Sache, die ich ausprobiert habe, war, den Link zu einem NFC -Tag hinzuzufügen und das an der Wand zu hängen, damit jeder die Beta -App schnell holen kann!

Hockeyapp

Ich verwende HockeyApp, um die APKs an QA oder Stakeholder zu retten und (theoretisch) zu sparen. Weitere Informationen zum Produkt finden Sie unter https://hockeyapp.net. So sieht es im HockeyApp -Dashboard aus:

Wie Sie sehen können, gibt es verschiedene Builds für die verschiedenen CI -Build -Konfigurationen und alle Build -Typen. HockeyApp -Jungs waren so freundlich, mir ein kostenloses Konto zur Verfügung zu stellen, um die Verwendung ihres Tools zu demonstrieren.

Playstore -Bewertungen in Slack

Verwenden Sie einen Überprüfungs-Bot dafür (https://reviewbot.io/?utm_Source=github&utm_medium=athkalia-just-Another-Android-App) Nicht viel zu sagen, nur ein super einfaches Tool, das die Aufgabe erledigt. Wenn eine Bewertung kommt, sieht es so aus:

Roadmap

• Upgrade auf die neueste Version von Gradle
• Fingerabdruckauthentifizierung
• Leiterbibliothek

PRS einreichen

Bitte stellen Sie sicher, dass der Befehls gradlew check erfolgreich abgeschlossen wird, bevor die PR erstellt wird. In diesem Befehl werden alle Tests für alle Varianten sowie die 4 statischen Analyse -Tools ausgeführt: Lint, SchecksKyle, PMD, Findbugs.

Liste der Dinge, die ich nicht hinzufügen werde, können Sie gerne einen Beitrag leisten, wenn Sie eines davon mögen!

• Führen Sie die Testabdeckung in Firebase -Cloud -Tests aus, holen Sie die Berichte (können Sie sie mit Abdeckungsberichten der Unit -Tests verschmelzen) und geben Sie die Berichterstattung an den CI -Server an. Dies müsste für einen S3 -Eimer bezahlen, und ich bin mir nicht sicher, wie dies nützlich ist, dies zu verfolgen, um ehrlich zu sein.
• Automatisieren Sie Veröffentlichungen mehr, z. B. das Tagging -Veröffentlichungen, die Rückführung in die Entwicklung usw. Die Anforderungen dieser Umgebung sind sehr projektspezifisch und angesichts der Tatsache, dass es Konflikte usw. gibt, die sich für den Moment nicht automatisieren lohnt.
• Automatische Screenshots durch das Tool "FastLane - Screengrab" (https://github.com/fastlane/fastlane/tree/master/screengrab) Sie unterstützen Windows nicht und ich habe keinen Mac :(

Jede Feedback/Pull -Anfrage ist willkommen!

Sie können mich unter www.sakiskaliakoudas.com fangen