Unsere letzten beiden Tage haben sich größtenteils um Forschung und das Schließen von Wissenslücken gedreht.
MVI (Model View Intent)
Ein wichtiges Thema ist dabei immer noch unsere App Architektur und welche Best Practices es speziell aus der Android Welt gibt.
Verena hatte hierfür bereits einiges an Vorarbeit geleistet und ein Beispiel implementiert. Nachdem wir das Thema in der Vergangenheit bereits diskutiert haben, gab es bei einem zweiten Blick auf die Architektur noch ein paar Ideen, wie wir sie für unsere Zwecke anpassen könnten. Im Speziellen geht es dabei um Android MVI (Model View Intent).
Die Idee dabei ist es pro View einen View State zu haben, der alle Informationen für diese View bereitstellt. Der State ist änderbar. Bspw. gibt es Events, die durch Benutzereingaben ausgelöst werden. Durch das Event werden andere Operationen getriggert (Intents – Absichten). Die Abarbeitung eines Intents kann wiederum zur Änderung des UIs führen. Dafür gibt es spezielle Results, die wiederum den View State verändern. Das wäre ein Beispiel für einen Flow. Ein Beispiel zu Android MVI Kotlin Coroutines & Flow findet ihr hier und ein Beispiel für die Testimplementierung von Verena hier.
Clean Architecture
Etwas abstrakter ist die Clean Architecture. Der Gedanke dabei ist es die unterschiedlichen Ebenen und die Kommunikation zwischen diesen Levels darzustellen.
Im Inneren befinden sich die „Entities“. Dazu zählt das Model und die Business Logic / Business Rules.
Um sie herum befinden sich Use Cases. Use Cases werden ausgelöst und verändern bspw. das Model.
Etwas weiter außen befinden sich Presenter, Gateways und Controller. Dazu zählt bspw. das View Model. Hier ist die Logik für die Kommunikation mit dem UI, der View, hinterlegt. In umgekehrter Richtung lösen bspw. Presenter Use Cases aus.
Ganz außen befinden sich Frameworks, Treiber, Devices, Datenbanken etc.
Charakteristisch für den Kreis sind zwei Prinzipien:
- Abstraktions-Prinzip: Je weiter innen ein Kreis liegt, desto abstrakter ist er. Und umgekehrt, je weiter außen ein Kreis liegt, desto konkreter ist dieser. Hier bedeutet es: je weiter innen ein Kreis liegt, desto weniger unterliegt er dem Einfluss der Veränderung äußerer Komponenten. Bspw. sollte das Ändern der Datenquelle / DB (ganz außen), keine Änderung der Business Regeln oder des Models nach sich ziehen.
- Abhängigkeits-Regel: Diese Regel besagt, dass jeder Kreis immer nur eine Abhängigkeit zum nächst inneren Kreis haben darf. Bspw. darf der Presenter (z.B. das View Model) lediglich abhängig von den Use Cases sein.
Ein gutes Beispiel ist das Clean Architecture Tutorial for Android: Getting Started.
Verena
Ich habe mir das nächste Kapitel im Designing for Behavior Change-Buch geschnappt, in dem es darum ging, Motivationen zu finden, die den User dazu animieren, auf eine bestimmte Weise zu handeln. In einem Abschnitt ging es um die Diskussion, ob man seine User „bestrafen“ sollte, wenn sie etwas nicht tun. Die generelle Antwort ist nein, aber ein interessanter Ansatz ist, sich User ihre Strafe selbst aussuchen/auferlegen zu lassen, also z.B. „Wenn ich X nicht tue, spende ich einen Betrag an eine Einrichtung, die gegen meine Prinzipien verstößt“. Ein weiterer Abschnitt ist darauf eingegangen, wie man Dinge, die so weit in der Zukunft liegen, dass sie für den Moment nicht motivierend sind, in die Gegenwart holt und hat Ansätze vermittelt, um „Das kann ich auch morgen noch erledigen“ zu überwinden und sofort tätig zu werden. Ein Beispiel dafür ist eine Software, um Menschen künstlich altern zu lassen und ihnen aufzuzeigen, welche Folgen ihre Lebensweise für die Zukunft hat. Für unseren Blog wussten wir nicht, ob ein Impressum notwendig ist, da keine persönlichen Daten dritter Personen gespeichert werden und es sich bei unserem Blog auch nicht um einen Internetauftritt eines Gewerbes handelt. Nach kurzer Recherche sind wir zu dem Schluss gekommen, dass wir damit wohl eine Grauzone betreten und haben das Impressum vorsichtshalber gelassen.
Peter
Größtenteils habe ich mich in das Thema App Architektur eingelesen.
Zweites Thema für mich war die Beantwortung der Frage: Wie können fremde Identity Provider in Keycloak eingebunden werden, welches für den Login in unsere App verwenden wollen. Da Keycloak Open ID Connect unterstützt, wollten wir zur Authentifizierung an die App auch Logins von Drittanbietern (wie Google oder Facebook) unterstützen. Damit ist es nicht erforderlich speziell für die App einen neuen Benutzer anlegen zu müssen, sondern es kann stattdessen ein bestehender bspw. Google Account verwendet werden.