Hier ist lange noch nicht Schluss:
Zwar ist die App an sich stabil und schick, hat vielleicht auch ein wenig zu bieten, aber sie ist unter der Haube
- wenig testbar,
- skaliert nicht gut, da sie nur aufwändig erweiterbar ist
- und sie ist auch nicht besonders gut wartbar, da sie keine feste Architektur vorgibt und man sich in diesem Projekt so gut wie jede Klasse angucken muss, um herauszufinden, welche Komponente was macht.
Aushilfe kann da eine gute Architekturbasis bieten. Hier gilt an sich: Es gibt keine silver Bullet Lösung und die Architektur muss an die gewünschten Ergebnisse angepasst werden.
Eine besonders, auch bei uns, beliebte Variante ist die Verwendung von ViewModels, einem Datenkonstrukt, das intern LiveData- verwendet, um Datenpakete zu verwalten und sie der UI zur Verfügung zu stellen, wenn ein entsprechender Lifecycle der Ansicht es erlaubt und Model-Daten sich ändern. Dadurch wird der Akku geschont. Außerdem werden so Daten unabhängig von der Ansicht gemanaged und entsprechende Codestücke sind testbar, ohne die UI selbst dabei testen zu müssen. Vor allem bei Geräte-Rotationen, die für ein Neu-Bauen der UI sorgen, können dann Daten geschickt zwischengespeichert werden und diese
ViewModels sorgen dann für weniger unnötiges Neu-Laden oder Initialisieren.
ViewModels sind Teil der Architecture Components, die Google veröffentlicht hat um genau diese architektonisch anstrengenden Aufgaben besser aufzuteilen - Die zu Grunde liegende Architektur nennt sich dann MVVM - Model-View-ViewModel, wobei die "View" Activities und Fragmente bedeuten.
Eine andere interessante Library nennt sich Databinding. Diese lässt sich im Modul-Gradle File einschalten (databinding true) und erzeugt aus jedem XML File eine Binding Klasse. Die Klasse sorgt dafür, dass im XML setter und getter definiert werden können, die bei Datenänderungen automatisiert aufgerufen werden können. Über weitere Binding Adapter können beliebige UI-Elemente auf Datenänderungen nach den Vorstellungen des Entwicklers reagieren.
Hier gehts zum Databinding
Bei größer werdenden Apps sollte bedacht werden, dass viele Komponenten miteinander verbunden sind und die Abhängigkeiten voneinander immer komplizierter werden.
Mit Dependency Injection Frameworks wie Dagger oder Koin werden diese Dependencies aufgelöst und per Annotationen oder Moduldefinitionen genau bestimmt.
Einzelne Komponenten werden so testbarer, da sie vereinzelter für sich stehen können. Abhängigkeiten werden dann injiziert oder per Konstruktor übergeben. Durch ihre Beschaffenheit kann man unterschiedliche Komponenten injizieren und so durch das Abändern einer Injizierung komplett andere Funktionalitäten implementieren, ohne andere Klassen anfassen zu müssen. Ein typisches Beispiel ist so zum Beispiel die Anbindung von einer Testdatenbank und nicht einer produktiven.
Bei JamitLabs verwenden wir sehr häufig eine Mischung aus allem Vorgestellten, da sich die Komponenten hervorragend kombinieren lassen. So benutzen wir eine MVVM Architektur mit Databinding und nutzen Dependency Injection.
Besonders in der Mobilen Entwicklung ist es interessant auf Datenflüsse sofort reagieren zu können.
Beispielsweise sind UIs oft so reaktiv, dass sie bei Statusupdates sofort unterschiedliche Anzeigen auslösen sollten - oder beim Wechseln der Konnektivität gleich bescheid geben sollten, dass ein Gerät gerade offline ist und wenn es wieder online ist.
Sowas lässt sich zwar mit Listenern und Callbacks in einzelnen Fällen sauber lösen, wird aber unleserlich und schwer nachzuvollziehen, wenn viele Daten sich ändern.
Hier bietet sich besonders das reaktive Programmierparadigma an mit Observern und Observable Daten - Prinzipien, die an sich ViewModels und Databinding teilweise auch schon umsetzen.
Besonders beliebte Frameworks für die Umsetzung ist RxJava bzw. RxKotlin.
Vielen Dank für deine Teilnahme!
Weiteres Interesse oder Fragen? Melde dich doch bei JamitLabs direkt!