Im letzten Sprint haben wir mit der Umsetzung des UIs für Achievements angefangen. In diesem Sprint haben wir uns an das Backend gemacht. Unser Ziel war es nicht nur dem Benutzer Achievements zuzuordnen, sondern wir wollen auch die Möglichkeit haben einem Team Achievements zuzuordnen. Letztendlich werden diese Achievements aber durch die Mühe von Benutzern erreicht. Deshalb haben wir uns überlegt Team-Achievements einzuführen, die über ein Team eingesehen werden können. Letztendlich wird aber jedem User – der an einem Team-Achievement mitgewirkt hat – auch seinem User Profil gutgeschrieben.
Die Umsetzung dafür war allerdings gar nicht so einfach, denn wir haben parallel auch User-Achievements und übergeordnet eine Achievement Klasse eingeführt. Außerdem gibt es Achievement Templates, die unserer Meinung nach ebenfalls in Team- und User-Achievement-Templates aufgeteilt werden müssen.
Ein Template ist eine Vorlage eines Achievements, dem Bild und Titel zugeordnet sind. Erreicht ein Team oder ein Benutzer ein Achievement-Ziel, wird das Template dem konkreten Team- oder User-Achievement zugeordnet. D.h. das konkrete Achievement hat einen Zeitstempel, wann das Achievement erreicht wurde und bezieht die Stamminformationen wie Bild und Titel aus dem Template.
Damit sollten wir fürs erste auch zukünftige Erweiterungen berücksichtigen können.
Das nächste größere Problem waren die Achievement-Templates. Solche Art Stammdaten hatten wir noch nicht. Bisher gibt es nur Bewegungsdaten wie ein neues Team, das ein Benutzer anlegen kann. Da wir aktuell noch mit einer In-Memory-Datenbank im Backend arbeiten, die bei jedem Neustart reseted wird, haben wir nach einer Lösung gesucht, die Achievement-Templates beim Starten des Webservers zur Verfügung zu stellen. Dank Spring Boot gar nicht so schwierig. Über die Annotation @PostConstruct kann eine Methode einer Komponente nach der allgemeinen Initialisierung des Servers instanziiert und ausgeführt werden. Über ein Verzeichnis können wir Bilder für Achievements bereitstellen. Wurde der Server gestartet, erzeugen wir Achievement-Templates, ordnen die Bilder zu, die wir im Verzeichnis bereitgestellt haben und speichern die Templates.
Nachdem wir dieses Problem gelöst hatten, wollten wir die Achievements aus dem Backend in der App zur Anzeige bringen. Nachdem wir einen Fehler im Backend gesucht haben, hatten wir die Idee unser Technical Error Overlay um Handlungsanweisungen zu erweitern. Denn Fehler wie: „Der aufgerufene Endpunkt ist nicht implementiert“ oder „Der Webserver ist nicht gestartet“ können häufiger auftreten. Warum nach dem Fehler suchen, wenn wir die Lösung des Problems schon kennen, nachdem wir danach gesucht haben.
Also haben wir mit dem Aufbau einer Wissensdatenbank begonnen. Tritt ein Fehler auf, der im Technical Error Overlay angezeigt wird, dann schauen wir nun in unserer Error Knowledge Database nach, ob es zu diesem Fehler bereits Einträge mit möglichen Lösungen gibt. Wenn ja, dann zeigen wir auch diese im Technical Error Overlay an.
Wir hoffen, dass uns das beim Beheben zukünftiger Probleme hilft. Wir finden es cool. Und außerdem ist es schön, dass wir uns um Themen kümmern können, die uns wichtig sind und nicht extern getrieben sind. Hier ein Beispiel:
Im nächsten Sprint werden wir mit der Anzeige der Achievements weiter machen.