Die dritte Woche in Folge, in der wir uns viel Zeit für bestehende Konzepte und APIs genommen haben. Zum einen wollen wir Dagger zum Injecten nutzen und Retrofit für den Zugriff auf Webservices.
Außerdem haben „wir“ das Thema App Logo vorangetrieben. Am Montag haben wir unserem Logo Dealer des Vertrauens eine Nachricht geschickt und keine 24 Stunden später hatten wir die ersten 3 Entwürfe im Postfach. 100% zufrieden waren wir auf Anhieb nicht, haben aber einen Entwurf als unseren Favoriten auserkoren. Unsere Änderungswünsche haben wir direkt zurückgeschickt und warten gespannt auf Rückmeldung, um das fertige Logo in einem der nächsten Blog-Beiträge präsentieren zu können.
Verena
Der Kampf ging diese Woche weiter: „Die Rückkehr von AppAuth“. Mittlerweile ist das Setup von Keycloak und AppAuth abgeschlossen und Webservices können auch bei mir mithilfe eines Berechtigungstokens aufgerufen worden. Nachdem alles lief, ist mir aufgefallen, dass das Ersetzen von RxJava durch die Coroutines auf Anhieb funktioniert hat. Ein absolutes Plus für Kotlin. Das nächste Ziel wäre, die Aufrufe einfacher zu gestalten und gewisse Informationen in eine Config-Datei auszulagern, damit für unsere jeweilige lokale Installation nur noch die eigenen Konfigurationen verwendet werden und das Coding davon unberührt bleibt. Für die Config hatte ich mir mehrere Libraries angeschaut, die ich auf https://www.kotlinresources.com/ gefunden habe. Auf der Seite sind Github-Repositories durchsuchbar. Allerdings war bis jetzt keine Library davon so einfach nutzbar wie in der Beschreibung versprochen, weitestgehend bugfrei bzw. wird überhaupt noch gepflegt.
Außerdem hatte ich angefangen, mir Dagger2 als Dependency Injection Framework anzuschauen und habe dazu eine Tutorial-Serie von Coding in Flow angefangen.
Peter
Vorrangig habe ich mich mit Retrofit beschäftigt und indirekt noch einmal das Thema Coroutinen gefestigt.
Retrofit als Library vereinfacht den Zugriff auf Webservices. Für den einen oder anderen mag es vermessen klingen es mit Spring Boot Web zu vergleichen. Aber das Konzept hinter Retrofit ist vergleichbar und ebenso eingängig wie das von Spring Boot Web. Es wird mit stark typisierten Objekten gearbeitet. Kein JSON oder XML. Stattdessen kümmert sich Retrofit um die Befüllung des http Headers, den Aufruf der Webservices, die Konvertierung von JSON / XML in das gewünschte Objekt Format und umgekehrt. Dafür ist ein Service Interface zu definieren – das Pendant zum Webserver. Durch Annotationen kann zwischen GET, POST, PUT, DELETE Requests unterschieden werden. Retrofit übernimmt dabei die Generierung einer Klasse zum Interface.
Ein Service könnte wir folgt definiert werden.
interface IPersonService {
@GET(„persons“)
fun findAll(): Call<List<Person>>
@GET(„persons/{id}“)
fun findById(@Path(„id“) id: Long): Call<Person>
@POST(„persons“)
fun addPerson(@Body person: Person): Call<Person>
}
Die Annotation gibt die http Method an. Über das Literal (hier „persons“) wird die Ressource angegeben, die abgerufen werden soll. Der Aufruf erfolgt über die zugehörige Kotlin Funktion (bspw. findAll()) . Das Ergebnis ist ein Retrofit-spezifisches Objekt vom Typ Call, das später aufgerufen werden muss, um den eigentlichen Rest-Call durchzuführen. Über eine Callback-Methode kann das Ergebnis (die Response) des Calls ausgewertet und verarbeitet werden.
Quellen und Videos gibt es im Netz reichlich. Nicht vergessen die Permission „Internet“ zuzuweisen.
Das war es von meiner Seite :).