Eine App ist schnell gebaut. Und kaum eine zeitgemäße App kommt ohne das Einbinden fremdbezogener Libraries als Dependencies aus. Doch was, wenn eine Bibliothek veraltet ist, die Anbieter den Support einstellen?
Wie halte ich meine App flexibel für Upgrades oder Ersetzungen der eingebundenen Dependencies und stelle sicher, dass weiterhin alle Funktionalitäten bereitstehen? Das sich daraus ergebende Alptraum-Szenario eines jeden Entwicklers lässt sich vermeiden!
Interfaces & Dependency Injection
Das erste Zauberwort heißt "Dependency Injection", das zweite, zugegeben weniger magisch klingende, "Interfaces". Doch wie genau funktionieren diese?
Statt direkte Abhängigkeiten jeweils direkt vor Ort zu erzeugen, also innerhalb der Klasse, in der sie verwendet werden, können wir mit Tools zum Dependency Management, wie etwa Dagger 2 für Android, unsere Dependencies in einem gesonderten Modul der App konfigurieren und bereitstellen. Damit haben wir an zentraler Stelle die Kontrolle und Übersicht darüber, welche Instanzen wir zu welchem Zweck und in welchem Kontext erzeugen und können sogar ihre Lebenszyklen festlegen. Diesen Aspekt werde ich in einem weiteren Artikel genauer betrachten.
Jede Funktionalität, die wir über eingebundene Libraries fremdbeziehen – die entsprechend austauschbar gehalten werden sollten – wrappen wir in einem Interface. Dieses legt die Funktionen (Methoden) fest, die eine Instanz der Klasse, die es implementiert, für unsere App bereitstellen muss. Bei technischen Änderungen bleiben die Interface-Methoden unverändert an den Schnittstellen; um die Details der Implementierung (Bibliotheken) kümmern wir uns in den spezifischen Ausimplementierungen des Interfaces.
Gewrappt ins Interface können wir dann an allen Stellen, an denen wir die Funktionalität verwenden, das Interface übergeben und durch die zentral-gesteuerte Dependency Injection die jeweils gewünschte Implementierung bestimmen. In Kombination ergibt sich damit eine leicht wartbare App, die auf Änderungen gelassen reagiert, da sie neue Bibliotheken ohne großen Aufwand flexibel integrieren kann.
Bessere Testbarkeit
Ganz nebenbei liefert die obige "Zauberformel" ein weiteres Plus: Da die verwendeten Instanzen zentralisiert gesteuert injecten, können wir zu Testzwecken an Stelle der echten Klassen Dummies oder Mocks einsetzen, ohne dass an verschiedenen Stellen im Code Veränderungen erforderlich sind, die diesen schnell unübersichtlich und schwerer wartbar machen.
Zeit einsetzen, um Zeit zu sparen
Jeder Entwickler, jede Entwicklerin kennt das: Man steht am Anfang der Entwicklungsphase, ist hochmotiviert und möchte einfach anfangen zu coden. Reflexartig scheut man davor zurück, mehr Zeit als unbedingt nötig mit dem drögen Entwurf zu verbringen. Doch aus Erfahrung kann ich sagen: Etwas Zeit für den Entwurf und eine ganzheitlich durchdachte Architektur zu investieren – es lohnt sich! Gerade wenn es um komplexere Apps geht, die eine Reihe von Dependencies haben, sparen wir die im Entwurf eingesetzte Zeit im Verlauf der weiteren Entwicklung zehnfach ein.
Ist das nicht viel zu viel Aufwand für eine kleine App?
Ein übermäßiger Zeitaufwand entsteht bei genauem Hinsehen meist vor allem dadurch, dass man am Anfang "schnell anfangen" will und im späteren Verlauf auf Probleme stößt, die beim Entwurf nicht berücksichtigt wurden. Doch Apps sind komplexe Softwareprodukte – egal, ob ein hochsicheres Enterprisebackend angebunden oder nur eine kleine Kundenbindungsapp entwickelt wird. Ein nicht zu Ende gedachtes Konzept rächt sich spätestens dann, wenn die App nachgerüstet oder erweitert werden muss.
Daher müssen wir uns bewusst entscheiden, ob wir eine langfristig erfolgreiche Anwendung entwickeln oder für ein schnelles Strohfeuer Geld – und Zeit – verbrennen möchten.
Fazit: Ein durchdachtes Konzept von Anfang an
Wahr ist, dass ein durchdachtes Konzept anfangs mehr Aufwand bedeutet. Statt am ersten Tag beginnt das eigentliche Coden erst nach der ersten Woche. Doch wenn wir es realistisch betrachten, kann dieser anfängliche Einsatz bezogen auf die Lebensdauer und Anpassbarkeit der App den deutlichen Mehrwert und einen Vorteil vor anderen Apps ähnlicher Art bedeuten.
Ihr möchtet eine dauerhaft erfolgreiche App, die flexibel auf veränderte Technologien reagiert und einfach testbar bleibt? Sprecht uns an – unser Mobile-Team zeigt euch wie.
Kommentare