Jetpack Compose für Retailer: Entwicklung eines Shopping Cart

In unserem ersten Blogbeitrag zu „Jetpack Compose“ haben wir die wichtigsten Gründe für den Einsatz des populären Android-Toolkits aufgezeigt. Dazu gehörte auch die Aufbereitung über das theoretische Wissen zu den Prinzipien und Konzepten zu Jetpack Compose. Schlussendlich haben wir uns auch mit der Implementierung in bestehende Architekturmuster beschäftigt.

Im zweiten Teil der Blogserie zu „Jetpack Compose“ haben wir dann die Best Practices im Umgang von stateful und stateless Composable- und Preview-Composable-Funktionen aufgezeigt. Überdies veranschaulichten wir die Kommunikation mit einem ViewModel als State Holder. Dabei ging es auch um mögliche Gefahren von unbewusst erstellten Anti-Pattern. Es wurde erklärt, wie solche Fallstricke durch präventive Gegenmaßnahmen verhindert werden können.

Das in den Kapiteln 1 und 2 erarbeitete Wissen bildet die Grundlage für die Entwicklung und Implementierung eines vollständigen Features mit Jetpack Compose. Vor allem in Retail Apps spielt Jetpack Compose seine Stärken aus. Hier können neben einzelnen Elementen auch Listen dargestellt werden, in denen sich sowohl Listen- als auch Listenelementoperationen durchführen lassen. Das ist vor allem von Vorteil, wenn reaktives Verhalten zur Laufzeit erforderlich ist.

Ein zentrales Feature, das in zahlreichen Retail-Apps wiederzufinden ist, ist der Shopping Cart. Dieses Produktmerkmal wird als eine der Hauptanwendungen in unzähligen Retail-Apps eingesetzt. Es ist maßgeblich für die Nutzererfahrung verantwortlich. Tatsächlich bestimmt die Qualität der Shopping Cart häufig über den Erfolg oder Misserfolg einer Retail-App und somit auch über Wohl und Wehe eines Unternehmens.

Vor der Entwicklung des Shopping Carts erheben Entwickler typischerweise die funktionalen und nicht funktionalen Anforderungen vom Fachbereich. Die Ansprüche werden außerdem mit dem Requirements Engineer abgestimmt, bevor sie zur Entwicklung freigegeben werden. Nachfolgend beschreiben wir in einem fiktiven Szenario die funktionalen und nicht funktionalen Anforderungen.

Aus Nutzersicht wurden folgende nicht funktionale Anforderungen an den Shopping Cart erhoben:

Im Laufe des agilen Projektlebenszyklus ist es wahrscheinlich, dass neue Funktionen bzw. Change Requests auf den Warenkorb einwirken. Es kann notwendig sein, den Shopping Cart mit weiteren Funktionalitäten auszustatten.

Denkbar wäre beispielsweise, dass ein Reklamations-Feature implementiert wird, in dem viele gleiche Artefakte aus dem Shopping Cart wiederzufinden sind. Aus Entwicklersicht (und indirekt auch aus Unternehmenssicht) besitzen folgende nicht funktionale Anforderungen einen hohen Stellenwert:

Für den Shopping Cart unserer User Story erarbeiteten wir folgende Akzeptanzkriterien:

Nachdem sich die relevanten Stakeholder, der Requirements Engineer und das UI/UX-Team fachlich abgestimmt haben, ist der vorläufige Designentwurf für den Shopping Cart veröffentlicht worden.

Das User Interface wurde derweil in die Komponenten Header, Listen-Content und Footer aufgeteilt. Entsprechend können die jeweiligen Composable-Funktionen losgelöst voneinander entwickelt werden. Im nächsten Step werden sie analog zu einem Baukastensystem orchestriert. Durch diesen Schritt besitzt das Entwicklerteam kompakte und übersichtliche Composable-Funktionen, die leicht wartbar sind und bei Bedarf erweitert werden können. Zu guter Letzt vereinfacht sich die Nutzung von Preview-Composable-Funktionen, was die punktuelle Fokussierung erhöht.

Durch die kombinierte Nutzung von stateless und stateful Composable-Funktionen ist eine feingranulare Wiederverwendung bestimmter Komponenten des Shopping Carts möglich. Beispielsweise könnten Entwickler:innen für die Reklamation die Komponente Listen-Content ganz einfach “recyclen”.

Neben der Wiederverwendung von Komponenten können und sollten in Jetpack Compose wiederkehrende UI-Elemente verwendet werden. Nach Abstimmung mit dem UI/UX-Team wurde festgestellt, dass folgende UI-Elemente des Shopping Carts auch in anderen Teilen der Anwendung wiederzufinden sind:

Hierfür wird ein Designsystem-Modul erstellt, in dem die wiederkehrenden UI-Elemente als Composable-Funktionen mit konkreten und sprechenden Namen versehen werden. Diese sollten nach Möglichkeit nicht zu generisch sein.

Abschließend legen die Verantwortlichen dann noch bestimmte Abstände, Schriftgrößen und Farben fest. Diese werden in der gesamten Anwendung genutzt, um ein konsistentes Look-and-Feel zu gewährleisten. Die entsprechenden Werte hinterlegen wir mit sprechenden Namen im Designsystem.

In diesem Blogbeitrag wurden die Anforderungen an den Shopping Cart vorgestellt. In einem technischen Refinement gaben wir Infos für eine mögliche Aufteilung in den einzelnen Komponenten. Weiterhin haben wir erklärt, wie für in der Anwendung wiederkehrende UI-Elemente ein Designsystem-Modul erstellt wird. Mit diesem Vorgehen ist eine intuitive Wiederverwendung der Elemente möglich.

Im nächsten Blogbeitrag der Jetpack-Compose-Serie der adesso mobile solutions wird unser neuer Shopping Cart implementiert. Das geschieht auf Grundlage der im vorherigen „Jetpack Compose”-Blogbeitrag erwähnten Best Practices, sowie auf Basis der Ergebnisse aus dem technischen Refinement.