Diese Woche haben wir einen Großteil unserer Zeit darin investiert, unser Backend weiter mit Beispieldaten zu füttern, die über Builder zusammenkonfiguriert werden können. Damit hatten wir bereits letzte Woche begonnen und sind so gut wie fertig. Beim Starten des Webservers werden nun User, User-Achievements, Teams und zugehörige Achievements und Member angelegt. Dies passiert bisher noch Random, da wir unsere Builder so angelegt haben, dass man z.B. eine bestimmte Anzahl an Teams anlegen kann, ohne die kompletten Informationen anzugeben. Die nötigen Informationen werden dann Random aus einer Template-Liste ausgesucht und daraus einfache Teams erzeugt. Was uns hier noch fehlt ist eine Art Szenario, welches wir uns konfigurieren wollen, um bei jedem Start sinnvolle Beispieldaten zu erhalten, also z.B. der Test-User einem Team zugewiesen ist, welches über weitere Member und Achievements verfügt. Das haben wir uns für nächste Woche gelassen. Außerdem ist Max Müller als User verschwunden und unsere Meeresbewohner Stacey Starfish, Sherman Shark und Co. von früher sind wieder aufgetaucht und imitieren unsere User.
Die Team-Achievements werden nicht nur beispielhaft aufgebaut sondern haben auch Einzug in die App gehalten. Bei den Team-Details hatten wir bisher einen leeren Tab für die Achievements. Wir wollten schon alleine aus Konsistenzgründen dort die Achievements genauso anzeigen wie in der MyAchievements-Übersicht. Dazu haben wir das MyAchievement-Fragment abstrahiert und dann ebenfalls in der Team-Ansicht eingebunden. Somit hatten wir blitzschnell einen neuen Screen, worüber wir selbst etwas überrascht waren. An den Achievements wollen wir App-seitig in der kommenden Woche weiterarbeiten. Hier haben wir noch einige Ideen und haben uns gleich noch ein paar Backlog-Items angelegt, um sicher zu gehen, dass uns die Arbeit nicht ausgeht 😉
Da wir auf Templates für unsere Beispieldaten umgestellt haben, war es nicht schwierig, unsere bereits für die Achievements verwendeten Images nochmals für die Teams und User wiederzuverwenden. Nach dem Hinzufügen zu den Beispieldaten wurden diese prompt in der App angezeigt. In diesen Momenten müssen wir immer wieder schmunzeln, weil uns solche Dinge durch die monatelange, durchdachte Entwicklung und absolutem Frickelverbot geschenkt werden.
Außerdem haben wir uns nochmals mit unserem ServiceProvider befasst. Hier hatten wir aufgrund der Type Erasure zur Laufzeit an Flexibilität eingebüßt und mussten direkt auf die konkrete Klasse zugreifen. Das haben wir mittlerweile behoben, sind jedoch noch nicht hundertprozentig glücklich mit unserer Extension-Function auf dem IServiceProvider-Interface, da wir nun wieder zwei Methoden jeweils für get- und setService auf dem Interface haben. Vielleicht fällt uns hier noch eine bessere Lösung ein.
Und zu guter Letzt haben wir wieder ein bisschen etwas für die Dev-Usability getan. Bisher ist der Webserver gecrashed, wenn wir den Testmode aktiviert, bzw. im Umkehrschluss die Security deaktivert hatten, aber einen Endpunkt aufgerufen haben, der einen Principal erwartet, der dann nicht mehr mitgegeben wurde. Durch eine saubere Exception konnten wir sogar den Anblick unseres ErrorOverlays in der App genießen und uns wieder einmal über unsere ganze Vorarbeit in den letzten Wochen freuen.