Hier kommt der Blog-Beitrag an diesem 35 Grad heißen Tag. Trotz der Wärme haben wir einiges geschafft.
Was macht das Logo? Wir sind immer noch dran. Derzeit probieren wir unterschiedlichen Farben aus. Generell haben wir aber immer noch Änderungswünsche. Auf dem Logo werden eine Waage und zwei Personen zu sehen sein. Allerdings kann die Anordnung auch als ein Gesicht interpretiert werden. Deshalb hatten wir noch eine Idee, die wir bereits als Anforderungswunsch angefordert haben, um das Logo noch eindeutiger zu machen.
Außerdem sind wir mit unserem neuen Ansprechpartner des Cyberforums in Kontakt getreten. Vielleicht können wir von dort noch etwas Unterstützung bekommen.
Peter
Auch diese Woche habe ich mit Retrofit und Spring Boot rumgespielt.
Da ich mit der in Memory Datenbank (H2) von Spring Boot arbeite, habe ich mir über Postman „Collections“ angelegt. Damit kann ein vorgegebener Satz an Requests auf einmal abgesetzt werden. Zum Befüllen der H2-Datenbank sehr geeignet – die ich sonst Request für Request per Hand abgesetzt habe. Supercool das Tool.
Was habe ich in Spring Boot gemacht? In Spring Boot haben wir nun die Möglichkeit zum Filtern von Felder und außerdem das Paging von Daten, sowie die Sortierung der Ergebnisse eingebaut. Um das Paging und Sortieren habe ich ein kleine API gestrickt, die wir mehr oder weniger generisch auch für weitere Entitäten nutzen können.
Es können jetzt bspw. folgende Abfragen gemacht werden:
Alle Personen der Seite 0 beschaffen, wobei mit einmal 3 Einträge zurückgegeben werden. Die Daten werden absteigend nach dem firstname und aufsteigend nach dem lastname sortiert.
http://localhost:8080/api/persons?pageNumber=0&pageSize=3&sort=firstname:desc,lastname:asc
Alternativ kann über den Parameter „order“ eine default Sortierreihenfolge angegeben werden. Die Default Sortierreihenfolge kann aber für jedes Attribut überschrieben werden. Im folgenden Beispiel würden z.B. alle Einträge, bis auf firstname absteigend sortiert werden. Das „:asc“ hinter dem firstname hat eine höhere Priorität als das default „order=desc“
http://localhost:8080/api/persons?pageNumber=0&pageSize=3&sort=firstname:asc&order=desc
In Retrofit gibt es nun ein neues Objekt PageRequestDTO. Das Objekt erhält das Ergebnis der Page-Anfrage. Dort sind nicht nur die Daten enthalten, sondern auch allgemeine Page Informationen. Beispielsweise ist es möglich auszulesen, auf welcher Seite ich bin, wie viele Einträge gelesen werden, wie viele Einträge und Seiten noch übrig sind. Bekommt man von Spring Boot alles geschenkt.
Außerdem haben Verena und ich uns der Retrofit-Generic gewidmet. Damit haben wir einen großen Teil des Retrofit Standardcodes gekapselt und können Abfragen mit nur wenigen Zeilen Code ausführen und auch das Ergebnis zurückbekommen. In der kleinen API müssen wir uns allerdings noch um die Fehlerbehandlung kümmern. Ein Webservice Request sieht bei uns nun wie folgt aus:
Die ServiceFactory erzeugt einen Service für IPersonDTOService. Dieser Service hat alle Methoden, um auf Personen zuzugreifen. Für die Ausführung des Calls wird der ServiceExecutor verwendet, der asynchron den Request absetzt, das Ergebnis in den gewünschten Typen umwandelt und zurückliefert. Deutlich kürzer als das bestehende Coding und wir können an zentraler Stelle ein default Webservice Call Fehlerhandling implementieren. Für Spezialfälle können wir eh weiterhin auf die Standardfunktionen zugreifen.
val personDTO = ServiceExecutor().execute(
ServiceFactory().createService(IPersonDTOService::class.java).findById(id)
)
Verena
Diese Woche habe ich mich weiter mit den Dagger Tutorials von Coding in Flow beschäftigt und angefangen, in der RestAccess-API den Service Locator durch Dependency Injection zu ersetzen.
Letztes Mal hatte ich mir ein paar Kotlin-Libraries angeschaut, um unsere Konfigurationen wie URIs, Client-IDs, Ports etc. hinterlegen zu können, damit wir nicht jeder das Coding anpassen müssen, sondern lediglich die Werte im Config-File anpassen und dieses immer wieder verwenden können. Letztendlich habe ich mich doch für eine herkömmliche Methode entschieden, ein properties-File anzulegen. Ich hatte auch zuerst die SharedPreferences in Android gefunden, habe allerdings gelesen, dass diese lesbar als xml abgelegt werden, was sich z.B. für unsere Keys nicht eignet. SharedPreferences könnten so mit einem gerooteten Handy angepasst werden. Deshalb haben wir jetzt ein Properties-File, welches mit der App kompiliert wird und mit weniger Aufwand ausgelesen werden kann als gedacht.