Was ging in diesem Sprint? In dieser Woche haben wir endlich richtiges Coding zu Papier gebracht. Wir haben an unserer App entwickelt. An der Deadline halten wir weiterhin fest. Endlich haben wir begonnen die umgesetzten Prototyp-Komponenten der vergangenen Woche und das erarbeitete Wissen der letzten Monate zu TeamSlimster zusammenzufügen.
Weil es mehr Spaß macht, weil wir Wissen so besser teilen können und weil jeder etwas Spezialwissen hat, haben wir die letzten Tage schön pair-geprogrammed.
Begonnen haben wir mit der Liste zur Anzeige von Teams. Teams in denen sich Benutzer zusammenschließen können, um gemeinsam an ihren Gewichtszielen zu arbeiten.
Bisher sieht diese Liste noch etwas unspektakulär aus. Aber unter der Haube haben wir das erste Mal Backend-Funktionalitäten, wie wir sie zukünftig nutzen wollen und Frontend-Technologien verbunden.
Im Backend haben wir in unserem Sprint Boot Projekt eine Entität „Teams“ eingeführt, für die sämtliche Instanzen zurückgegeben oder dessen Attribute gefiltert oder in Form von Pages zurückgeliefert werden können.
Im Frontend haben wir über Retrofit eine Serviceklasse implementiert, die sämtliche Endpunkte von „Teams“ des Backends ansprechen kann und daraus Data Transfer Objekte (DTO) erzeugt. Um Retrofit herum nutzen wir eine einfachere API von uns, die zwar noch nicht vollständig, aber die Verwendung einfacher macht.
Aus den DTOs erzeugen wir Daten Objekte (DOs), die wir später in einer Recyclerview zur Anzeige der Teams verwenden.
Die Recyclerview ist wiederum in einem Fragment eingebunden. Für die Fragments haben wir begonnen eine kleine, eigene API zu stricken, die mit Verenas Flow Konzept arbeitet.
D.h. jedes Fragment besitzt ein View-Model. Somit wird das Coding in Fragments, die dem UI-Layer angehören, auf ein Minimum reduziert.
Stattdessen werden sämtliche Daten aus dem View-Model bezogen (ViewState) und können zur Anzeige gebracht werden.
Sämtliche Benutzereingaben werden an das View-Model delegiert (Event).
Sämtliche Aktionen, die ein Ergebnis zur Folge haben, werden in ein Result des View-Models umgewandelt.
Nachdem das grobe Konzept, wie wir unsere Anwendung umsetzen wollen, steht, versuchen wir bestehendes Coding so umzustrukturieren, dass es einfach und möglichst intuitiv wiederverwendbar wird.
Was gab es sonst noch? Nach einem Review unseres Logs haben wir beschlossen eine weitere letzte Änderung an fiverr.com zu schicken. Und dann … gab es da noch eine allerletzte, letzte Änderung.