Kategorie: Fortschritt

Am Ende der letzten beiden Tage hatten wir das Gefühl echt guten Fortschritt gemacht zu haben. Bis auf ein Ticket, das wir, nachdem es bereits geschlossen war, wieder öffnen mussten, haben wir alle Aufgaben abgeschlossen.
Rein funktional ist nicht so viel dazugekommen. Dafür ist unser funktionale Rahmen, in dem wir uns bewegen und an dem wir neue Funktionen andocken, wieder gewachsen, stabiler geworden und wird immer flexibler.

Im Backend haben wir ein komplett neues Format eingeführt. Jeder Call liefert nun nicht mehr einfach die requesteten Daten zurück, sondern es gibt ein Standardformat. Das Standardformat enthält die folgenden Informationen:

• Pfad – den aufgerufenen Pfad
• Timestamp – den Timestamp des Requests
• Http Status Code – der Http Status Code, wie 200, 403
• Result Error Code – ein von uns einführter Fehlercode, den wir UI-seitig auswerten können
• Message – eine beliebige Meldung, die angezeigt werden kann
• Value – der requestete Wert

Das ermöglicht uns mehr Flexibilität, um auf Fehler zu reagieren.
Neben Anpassungen im Backend mussten unsere Retro-Calls angepasst werden. Damit ist es jetzt möglich zu prüfen, ob das Anlegen eines Teams möglich ist. Falls nicht, bekommen wir nun heraus, was das Problem war und können eine sprechende Meldung für den Benutzer anzeigen. Bspw. ist es nicht mehr möglich mehrere Teams mit dem gleichen Namen anzulegen.

Anschließend wollten wir weiter an dem UI arbeiten und eine Navigation zwischen den Screens einbauen. Dabei ist uns ein Video von „Coding in Flow“ in die Hände gefallen. In diesem Video wird die Verwendung des neuen NavControllers erklärt. Über einen NavGraph ist es möglich die Navigation zwischen Fragments zu modellieren. in Android Studio sieht es wie folgt aus:

Es gibt ein Start-Fragment (Home), das nach dem Start angezeigt wird. Von dort aus kann entweder auf das Fragment CreateTeamFragment oder auf TeamDetailsFragment navigiert werden und von CreateTeamFragment wieder zurück auf das TeamOverviewFragment. Eine coole Neuerung. Damit war allerdings unsere API für das Navigieren zwischen Fragments hinfällig und wir haben es durch die neue Funktionalität ersetzt. Ein kleiner Umbau, der das Coding aber vereinfacht hat. Vorher wurde ein Navigation Request an unsere äußere Activity gebubbelt. Jetzt wird er direkt von unserem Fragment bzw. vom zugehörigen View-Model ausgeführt.

Bei der ganzen Implementiererei ist uns aufgefallen, dass wir häufig Abbrüche durch invalide, abgelaufene oder fehlende Refresh-Tokens hatten. Ergebnis war, dass die App nicht mehr lief. Umständlich mussten wir einen Logout triggern, um die Anwendung wieder zum Laufen zu bringen.
Um das Problem zu lösen haben wir recht viel Zeit investiert. Das Ergebnis ist eine deutlich stabilere Anwendung, die automatisch den Login-Screen anzeigt, wenn Requests zum Backend nicht mehr ausgeführt werden können oder das Refreshen des Tokens nicht mehr möglich ist.

Insgesamt eine coole und produktive Woche.

Diese Woche sind wir wieder nicht ganz so weit gekommen, aber man muss auch sagen, dass wir beide nicht komplett da waren, also weniger Zeit hatten und bei mir stand ein Update vom Android Studio auf 4.1 an, ohne dass die Emulatoren mich nicht haben testen lassen: Das Tor zur Fehlermeldungs-Hölle..

Aber insgesamt hat es trotzdem Spaß gemacht. Man sieht mittlerweile auch mehr in der App. Seit dieser Woche ist es möglich, ein Team anzulegen. Es macht sich immer mehr bemerkbar, dass sich die ganze bisherige Arbeit in die Frameworks gelohnt hat. Dem Team-Model ein Motto hinzuzufügen hat maximal eine Viertelstunde gedauert.

Der Screen validiert die Eingabe und zeigt Fehler an. Es fehlt nur noch die Validierung für ein bereits existierendes Team. Etwas aufgehalten hat uns das Zurücksetzen der Fehlermeldung, bei der wir zuerst einen KeyListener gesetzt hatten und bei jeder Eingabe den Fehlerstatus im ViewState zurückgesetzt haben, was allerdings dazu geführt hat, dass der Cursor im Inputfeld an den Anfang gesprungen ist und das Feld laggy wurde. Das haben wir jetzt erstmal UI-seitig gefixt.

Die Navigation zwischen den Fragments ist auch nicht trivial, wenn man den Stack beeinflussen möchte. Wir wollten verhindern, dass man nach dem Anlegen eines Teams, nachdem man auf die Teamsübersicht zurückgeleitet wird, durch drücken der „Zurück“-Taste wieder auf dem Screen zum Anlegen landet, weil es quasi wie ein Pop-up behandelt werden sollte. Das Manipulieren des Stacks mit dem Entfernen des Anlege-Screens wollte nicht funktionieren, aber letztendlich hatten wir den Stack einfach falsch aufgebaut. Wir haben nach dem Anlegen die Teamsübersicht neu aufgebaut, anstatt zurück zu navigieren. Das sollte funktionieren. Testen konnte ich es allerdings noch nicht, da wir noch einen Bug haben, dass ein abgelaufener Refresh-Token keinen neuen Login triggert, weshalb man sich manuell ausloggen muss. Letzte Woche haben wir die Refresh-Token-Dauer auf mehrere Monate gesetzt, da wir uns an keine App erinnern können, bei dir wir uns nochmal hätten anmelden müssen, egal, wie lange man sie nicht mehr geöffnet hatte. Nachdem ich mich den ganzen Tag neu eingeloggt habe, dachte ich, ich importiere mir schnell die neuen Konfigurationen. Das hat mir jetzt den Keycloak-Server zerschossen..ein Zeichen, dass es nächste Woche weitergehen soll.

Mittlerweile ist das unser 18. Blogeintrag. Auch wenn wir unsere Fortschritte manchmal nur gering wahrnehmen und gerne schon weiter wären, kommen wir stetig Stück für Stück vorwärts.

Gefühlt endlos ziehen sich für uns die Themen Login, Authentifizierung mit Keycloak und AppAuth. Obwohl wir uns für diesen Sprint den Dialog für das Erstellen einer neuen Gruppe vorgenommen haben, drehten sich die letzten zwei Tage fast ausschließlich um die oberen Themen, weil uns immer wieder Probleme in die Quere kommen.

Am Montag haben wir den Mechanismus für das Laden, Speichern und Löschen des Keycloak Tokens auf dem Handy überarbeitet. Es scheint alles auf einmal viel einfacher und besser wiederverwendbar zu sein.
Außerdem haben wir begonnen das Format des Tokens zu überarbeiten, den wir über unseren Identitfy Provider zurückgeben. Jetzt haben wir 3 unterschiedliche Tokentypen. Klingt komplizierter, ist am Ende aber einfacher.
Auf der internen Seite haben wir einen Token, den wir nach dem Einloggen bei Keycloak zurückbekommen. Der zweite ist im Format, das wir vom Keycloak System erhalten, wenn wir uns einen neuen Token per Refresh zurückgeben lassen.
Nach außen sieht man von all dem aber nichts. Hier kommt der dritte Token ins Spiel, der wohl geformt und gut zu verwenden ist. Der Token, den wir aus dem Login- bzw. Refresh-Token erzeugen und nach außen weitergeben.
Damit hat AppAuth noch mehr seiner Daseinsberechtigung verloren.

Gebraucht haben wir die Änderung, um in der App zu prüfen, ob ein Token abgelaufen ist. Nur in diesem Fall lösen wir ein Refresh des Tokens aus, um so den Netzwerk-Traffic zu reduzieren.

Auf der Keycloak-Seite haben wir mit den ablaufenden Token gekämpft. Nach langem Rumprobieren wissen wir jetzt, welche Einstellungen wir verändern müssen, um die Dauer der Access- und Refreshtokens einzustellen. Vorher war es nicht so einfach ersichtlich.

Als letztes hat Verena noch an dem Hinzufügen neuer Teams gearbeitet. Wir haben jetzt einen Button zum Hinzufügen. Schick und demnächst auch mit Funktionalität.

Am Ende des Tages lief unser Login schon besser als letzte Woche. Es ist nicht nur möglich sich einzuloggen, sondern beim Neustart der App erscheint der Login-Screen nicht, sofern ein alter Token vorhanden ist, der wiederverwendet werden kann.
Beim Rumspielen sind uns diesem Zusammenhang allerdings schon nach wenigen Minuten einige Tests aufgefallen, die wir derzeit nicht bestehen.
Was, wenn der Webserver nicht mehr erreichbar ist?
Was, wenn der User vom Keycloak System ausgeloggt wird und irgendwann neue Tokens anfordert?
Was, wenn der User sich einloggen möchte und der Webserver nicht online ist, aber eine Ressource requestet wird?

Daran werden wir nächste Woche weiterarbeiten und dann können wir uns mehr und mehr auf das UI konzentrieren :).

Pair-Programming FOR THE WIN! Vier Wochen nachdem wir angefangen haben, den User-Login in die App zu integrieren, heißt es jetzt endlich „Du kommst hier nicht rein“ für unsere Webservice-Calls. Aus der App heraus können nur noch Anfragen mit gültigem Token an unseren Webserver geschickt werden. Falls kein Token vorhanden ist, triggern wir erstmal einen Login, der AppAuth verwenden, um mit unserem Keycloak-Server zu kommunizieren. Ist der Login im Browser erfolgreich, erhalten wir einen Token mit entsprechenden Rollen und schicken damit nochmal die Anfrage raus. Das Ergebnis, unsere Teams-Liste, zeigen wir – jetzt „save“ – im UI an.

Diese Woche haben wir unter anderem mit dem MutableStateFlow gekämpft, wobei wir den Fehler gemacht haben, in der Registrierung des ersten Flows unsere Werte zu mappen und damit einen zweiten Flow upzudaten, anstatt die Flows aneinander zu ketten bzw. einen Flow zu verwenden und darin die Werte zwischenzeitlich umzumappen. Auch wenn wir React nicht mehr verwenden, haben sich die Einarbeitungsmonate heute doch noch bezahlt gemacht. Außerdem haben wir uns mit den Coroutinen auseinandergesetzt und bei uns etwas aufgeräumt, da wir diese unwissentlich etwas wild gespawned haben. Obwohl wir auch in den letzten Wochen viele Fortschritte gemacht haben, haben wir uns heute, da alles jetzt zusammen funktioniert, extrem darüber gefreut und haben uns ein Achievement auf dem Board gegönnt.

Zuerst die positiven Dinge: Der IdentityProviderAccess ist fertig gerefactored. Unser Webserver nimmt nun nur noch Anfragen mit validen Tokens entgegen. Provisorisch kann man sich in der App anmelden und den Header in den Retrofit-Calls mittles AuthorizationInterceptor mit dem Token befüllen. Nun sind wir beim Pair-Programming dabei, eine sauberere API um die Calls zu implementieren, um sicherzustellen, dass die App erstmal nur mit einem Token verwendet werden kann. Wir haben auch unsere gesamten Konfigurationen gesynct, damit wir unsere Ports, Keycloak-Realms, Postman-Collections und AccessTokens nicht immer umstellen müssen, da wir uns diese teilweise durch die Arbeit im gleichen Repository gegenseitig überschrieben haben.

Negative Punkte: Uns wurden diese Woche gefühlt viele Steine in den Weg geworfen. Peters Android Studio ist ihm beim Update um die Ohren geflogen, was mehrere Stunden in Anspruch genommen hat. AppAuth macht nach wie vor seine Probleme, aber da Peter nachgelesen hat, dass es sicherer ist, den Login von der App zu trennen und selbst Keycloak AppAuth empfiehlt, haben wir uns entschlossen, den letzten AppAuth-Bug später noch anzugehen, aber dabei zu bleiben und keine eigene Lösung zu implementieren. Oft verhält sich der Emulator unterschiedlich, manchmal bleibt nur noch ein kompletter Restart von so ziemlich allem, um dann herauszufinden, dass ein Fehler nicht an einer geänderten Implementierung selbst lag.

In diesem Sprint haben wir uns hauptsächlich um die Anbindung des Keycloak-Systems – unserem Identity Provider – gekümmert. Damit wollten wir eine weitere fehlende und umfangreiche Komponente unserer TeamSlimster App hinzufügen. „Wollten“ ist Präteritum? Fertig sind wir damit nämlich nicht geworden.

Generell ist das Ziel:

1. Sich mit einem Usernamen und Passwort einzuloggen
2. Den gelieferten Token von Keycloak einem Webservice Request zum Backend-Server mitzuschicken
3. Dort anhand des Tokens den User authentifizieren
4. Die angeforderten Daten zusammen sammeln
5. Und das Ergebnis in unserer App anzuzeigen

Gestern (Montag) haben wir mit Pair Programming begonnen. Wir haben unsere Library „Identity Provider Access“ um eine Logout Funktion erweitert. Diese Library verwendet immer noch „AppAuth“ als Dependency, die uns schon in der letzte Woche Probleme bereit hat. Einen Logout bietet sie gar nicht an – soweit ich weiß. Wir sind also hingegangen und haben unsere Retrofit-Kenntnisse ausgepackt und die Funktion runterprogrammiert.
Ganz so lief es dann doch nicht. Erst einmal haben wir mit Postman rumgespielt und alle Request Parameter so befüllt, dass zumindest Postman den eingeloggten User ausloggt.
Erst im zweiten Schritt haben wir den Logout-Retrofit-Service implementiert. Auf Anhieb hat es nicht funktioniert. Logisch. Dem Body einfach die Client-ID und einen Token übergeben? Damit ist es nicht getan. Denn dabei werden bspw. Hochkomma nicht escapt. Aber Dank unserem Buddy Stackoverflow haben wir das Problem in den Griff bekommen. Logout funktioniert!

Verena

Da wir Probleme beim Einbinden zweier unserer Module hatten, habe ich mich ein bisschen in Gradle und wie Dependencies konfiguriert werden eingelesen. Die transitiven Dependencies, das Gegenteil zu direkten Dependencies, die man per „implementation“ hinzufügt, wie z.B. unser ConfigPropertiesReader, der in einem unserer Module verwendet wird, können offensichtlich nicht aufgelöst werden. Peter hatte herausgefunden, dass die einzige Möglichkeit, diese zu nutzen, ist, sie ebenfalls als direkte Dependency in unserer App anzugeben. Mal sehen, ob wir hier noch eine andere Lösung finden. Ich bin noch über „resolvable und consumable configurations“ gestolpert und werde mir das nächste Woche nochmal anschauen.

Peter

Nachdem wir die Logout-Funktion umgesetzt hatten, habe ich mich an die Token-Refresh-Funktion gemacht. Vom Keycloak System soll über den Refresh-Token ein neuer Access-Token samt zugehörigen Refresh-Token beschafft werden.

Ich bin genauso vorgegangen wie damals, vor 24 Stunden, erst mal mit Postman ran pirschen, die Attribute ausfindig machen, die wir benötigen und wie sie zu befüllen sind. Dabei habe ich festgestellt, dass der Request Body für den Logout komplett anders befüllt werden muss als der vom Token-Refresh. Statt die Attribute mit einem & zu verknüpfen, mussten sie nun als Value-Pair Liste übergeben werden. Gut, aber auch das hat Retrofit unterstützt – Hashtag FormUrlEncoded –.

Und ab da ging es etwas bergab. Ich bin so ein Update-Futzi. Darf man was updaten, update ich es. Verena hatte in der Vergangenheit schon schlechte Erfahrungen mit Android Studio und Updates gemacht. Die wollte ich einfach auch sammeln und habe frecher Weise auf „Update“ geklickt. Das Ende des Liedes waren mehrere Neuinstallationen von Android Studio, Caches löschen, SDKs-updaten, Lizenzen aktualisieren, Plattformen installieren. Was auch immer.

Ah, und wir hatten in unserer TeamSlimster App bereits eine kleine API für die etwas einfachere Nutzung von Retrofit. Da wir diese auch gut in unserer „Identity Provider Acccess“ Library gebrauchen konnten, habe ich sie in ein extra Paket gezogen, das wir nun überall in Form eines Github Repositories einbinden können.

In diesem Sprint lag der Fokus wieder aufs … Coden. Aktuell sind wir dabei den Login und die Anbindung an Keycloak – unserem Identity Provider – hinzubekommen. So richtig gelang es uns aber in diesem Sprint noch nicht. Zur Kommunikation mit Keycloak nutzen wir das Android Framework AppAuth. Da wir parallel auch Retrofit einsetzen, gibt es immer weniger Features, die wir von AppAuth nutzen. Außerdem haben wir eher damit zu kämpfen AppAuth richtig einzubinden. Verena kann dazu allerdings noch deutlich mehr berichten.
Was gab es sonst noch?
Unser Icon ist fertig :D. Das letzten, das wir von fiverr.com bekommen haben war unser Logo ohne Text und zentriert ausgerichtet. Unsere App haben wir dahingehend bereits aktualisiert.
Was ging noch? Im letzten Sprint haben wir am Design unserer App gearbeitet. Dabei ging es um die Kommunikation zwischen Activities und Fragments durch View Models, View States etc. Dafür haben wir heute begonnen etwas Doku in Form eines Klassendiagramms zu schreiben. So sieht sie im Kern momentan aus.

Last but not least haben wir uns überlegt, wo wir Dokumente zentral speichern. Nachdem wir OneNote für Notizen, Code Snippets und sonstige Informationen nutzen, haben wir uns für OneDrive entschieden, um Dokumente zentral abzulegen.

Verena

Der Feind hatte diese Woche einen neuen Namen – AppAuth. Eigentlich hat es ganz harmlos angefangen: Die RestAccess-Api wollte etwas gerefactored werden. Nachdem wir unsere Webservice-Calls nun mit Retrofit absetzen, braucht die RestAccess-Api sich nur noch um den Login/Logout zu kümmern. Doch schon beim Aufruf der alten App in einem Emulator, der mit einer relativ neuen Android-Version lief, kamen die ersten Fehler hoch. Es gibt wohl einen neuen Check, der diese Fehlermeldung produziert: „Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag”. Da unsere AppAuth-Version relativ alt war, dachte ich, dass ein Update auf die neueste Version nicht schaden könnte. Eineinhalb Tage später ohne lauffähige Version haben wir uns kurzzeitig überlegt, ob wir nicht doch auf AppAuth verzichten sollen, da die Konfiguration und Unterstützung bei der Fehlersuche ein Alptraum ist. Da wir aber auch die alte Version durch das Ändern des Contexts wieder zum Laufen gebracht haben, haben wir uns erstmal dafür entschieden, auf diese zurückzukehren. Der Login funktioniert, fehlen noch der Logout und der Refresh-Token, aber das muss bis nächste Woche warten.
Dann wollte ich „nur mal eben“ den ConfigPropertiesReader in die RestAccess-Api einbinden..funktioniert aber auch nicht mehr.
Die Woche in einem Wort: steinig

Peter
Ich habe mich gestern wie ein richtiger Entwickler gefühlt und hart gecoded. Die bestehenden Implementierungen für unser Backend Framework habe ich etwas aufgepimpt und abstrahiert. In relativ kurzer Zeit ist es nun möglich mehrere Endpunkte (findAll, findById, Add) für eine Entität hinzuzufügen. Für jede Entität stehen direkt Filter-Funktionen nach Felder, Sortierfunktionen und Paging zur Verfügung.
Werden weitere Endpunkte für alle Entitäten benötigt, können wir diese zentral ergänzen.

In diesem Sprint haben wir wieder schwer gecodet. Na ja, und uns von einem Problem zum nächsten gehangelt, diese oft als „vorerst nicht lösbar“ eingestuft und mit dem nächsten Problem weitergemacht.
Im Pair-Programming war das allerdings einfacher als alleine und irgendwas zwischen witzig, anstrengend und der Resignation nahe.

Nebenbei haben wir ein aller letztes Update, des letzten Updates unseres Logos bekommen. Statt des T’s für TeamSlimster im Logo, schwebt nun ein TS über den Personen im Logo. Damit sieht es weniger aus, als würde die linke Personen Thors Hammer in der Hand halten.

Peter

Ich habe mich etwas mit unserer neuen Account-API beschäftigt. Diese hatten wir bereits im Vorfeld designed und ich habe begonnen sie auszuprogrammieren, als Bibliothek in Github bereitzustellen – weil wir jetzt wissen, wie das geht, war das sogar relativ einfach – und in unserer App einzubinden.

Probleme hatte ich beim Design. Denn obwohl wir schon ein paar Sprints zuvor drüber gesprochen haben, war die API nicht richtig fertig.

Nächste Woche werde ich sie einbinden. Damit wird es möglich sein dem User einen Account zuzuordnen. Der Account wird ein spezieller Webaccount sein, der mit dem Keycloak User verknüpft wird.

Verena

Diese Woche kam mir stack overflow wieder einmal zur Hilfe. Obwohl wir schon mehrfach Packages auf Github veröffentlicht haben und Peter uns sogar ein Step-by-step-Tutorial in unserer OneNote-Schatztruhe angelegt hatte, hat sich der ConfigPropertiesReader dagegen gesträubt, als Library an die Öffentlichkeit zu gehen. Beim Publishen tauchte einer dieser ungooglebaren Fehler auf. Da blieb letztendlich nur stack overflow und ein hilfsbereiter User hat uns kurz darauf den Tipp gegeben, dass man Gradle-Build-Files per Logging debuggen kann.

println <Text/Variable/irgendwas>

gibt den gewünschten Output während der Buildphase aus und ermöglicht es so, Fehler einfacher zu finden. Wieder etwas dazu gelernt.

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.

Juhuuu, unser Icon ist fertig. Nach nur vielen Wochen ist unser Icon fertig. Danke an die Leute von Gigblast, die wir auf Fiverr.com gefunden haben und die uns keinen Änderungswunsch ausgeschlagen haben.Verena hat eine kleine Historie zur Entstehung des Icons vorbereitet.

Und so sieht es letztendlich aus:

Weil wir es nicht erwarten können die App fertig zu bekommen, haben wir das Release-Datum einfach mal auf Ende Oktober vorgezogen. Letztendlich soll das Datum uns dazu bewegen noch etwas fokussierter an der App zu arbeiten. Ein Großteil des Wissens über Technologien haben wir bereits aufgebaut und jetzt soll es ans Eingemachte gehen.

Verena

Das Logo haben wir gleich in die App und die Keycloak-Login-Seite eingebunden. Die Keycloak-Seite lässt sich einfacher konfigurieren als gedacht. Man kann sich ein neues Theme und die jeweiligen Ordner anlegen, die einen angepassten Style erhalten sollen, CSS-File anlegen und customizen und schon ist es fertig.

Um dem ganzen etwas Offizielles zu geben und ein Gefühl von Ansporn zu erzeugen, haben wir das Release-Datum für unsere App als Countdown in den Blog mit aufgenommen.

Wir haben uns außerdem Gedanken dazu gemacht, wie die App generell strukturiert werden sollte und welche Screens und Funktionalitäten bis zum Release unseres MVP’s nötig sind. Diese sind alle zunächst als Epics und Stories in unsere TODO-App geflossen.

Peter

Um mit der Entwicklung voran zu kommen, haben wir uns einen essenziellen Teil für die Verwendung der App herausgesucht und begonnen die Architektur dafür zu besprechen: die des Logins. Der Login ist insofern eine Herausforderung, weil er gleich als erstes auf alle möglichen Komponenten zugreift und die Grundlage für alle Activities bzw. Fragments darstellt. Über das UI muss bspw. geprüft werden, ob der User bereits eingeloggt ist, wenn nicht, muss ein Login Screen angezeigt werden. Die eingegebenen User Credentials müssen an das Keycloak System, dem Identity Provider, geschickt werden. Aus der Response wollen wir ein Account-Objekt erzeugen, das die Informationen (Authentifizierung- und Autorisierunginformationen) zum Benutzer hält. U.a. wird auch der JSON Web Token vom Keycloak System enthalten sein. Diesen verwenden wir später, um REST-Requests an den Webserver zu schicken.