Und wieder haben wir uns mit unserem Logo beschäftigt. Mittlerweile nimmt es Gestalt an. Es gibt noch eine Sache, die wir zu beanstanden haben und dann werden wir es im Blog posten.
Ansonsten hat in diesem „Sprint“ hauptsächlich jeder für sich gearbeitet und Verena hat ihre Erkenntnisse mit Dagger geteilt.
Peter
Ich habe mich erneut mit Retrofit beschäftigt. Was uns hauptsächlich noch gefehlt hat ist eine Möglichkeit, um die Authorization Information mit einem Retrofit-Call mitgeben zu können. Also entweder User-Credentials oder später einen Token, wie er von einem Identity Provider erzeugt wird. Auch hier hatte Verena bereits Vorarbeit geleistet und es ausprobiert.
In Retrofit ist das Mitgeben der Authorization Information relativ einfach.
Es gibt die folgenden Möglichkeiten:
- einem Webservice Call über eine Annotation @Header-Informationen mitgeben, die dem Http-Header hinzugefügt werden
- oder alternativ kann über das Client Objekt „OkHttpClient“ ein Interceptor übergeben werden. OkHttpClient ist das Standard Framework für Http-Requests, das auch von Retrofit verwendet wird.
Mit Hilfe des Interceptors kann der Http-Request um weitere Informationen erweitert werden.
Der Vorteil dabei ist, es muss nicht jedem Webservice-Call separat ein Header hinzugefügt werden, sondern es kann an zentraler Stelle erfolgen.
Wichtig dabei ist, die übermittelten Informationen zu encrypten. Die Implementierung zur Übermittelung von User-Credentials mit Hilfe eines Interceptors kann wie folgt aussehen:
class AuthorizationInterceptor : Interceptor {
override fun intercept(chain: Interceptor.Chain): Response {
val originalRequest = chain.request()
val username: String = "test"
val password: String = "test"
val base: String = "$username:$password"
val authorizationHeader: String =
"Basic " + Base64.getEncoder().encodeToString(base.toByteArray())
val newRequest = originalRequest.newBuilder()
.header("Authorization", authorizationHeader)
.build()
return chain.proceed(newRequest)
}
}
Die restliche Zeit habe ich mich mit Spring Boot beschäftigt. Die Übergabe von Benutzername und Passwort – zum Auslesen – war einfach.
Allerdings werden POST-Requests von Spring Boot verboten. Ich habe zwar Möglichkeiten gefunden das Verhalten zu unterdrücken, aber es soll unter Prüfung des Benutzers und seiner Berechtigungen funktionieren.
Da werde ich nächste Woche weiter machen.
Verena
Nach den zahlreichen Tutorials von Coding in Flow verwendet die RestAccess-API nun als unsere erste Library Dependency Injection mit Dagger2.
Eine Anmerkung dazu: Beim Verwenden von Dagger muss oft ein „Rebuild“ des Projektes durchgeführt werden, damit z.B. die Components anhand des definierten Interfaces generiert werden. Beim Definieren der Dependencies wird schnell mal z.B. eine Annotation vergessen und es kommt zu einem Build-Fehler.
Eine Sache, die ich gelernt habe, war, dass ein „Rebuild“ in Android Studio nicht die gleichen Fehlermeldungen produziert wie ein einzelner „Build“ über das Gradle-Menü. Taucht also z.B. eine kryptische Fehlermeldung wie diese auf:
„A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptExecution“
kann im Gradle-Menü über app->Tasks->build->build der einzelne Schritt ausgeführt werden, was bei mir z.B. für den gleichen Fehler diese zusätzliche Fehlermeldung ausgespuckt hat:
„error: @Component.Builder has setters for modules or components that aren’t required: [@org.jetbrains.annotations.NotNull com.outlivethesun.restaccess.dagger.IRestAccessComponent.Builder..”
Weitaus hilfreicher, da man hier auch auf die Stelle, an der der Fehler auftritt, hingewiesen wird.
Was die Testbarkeit angeht, können anstatt zusätzliche Test-Components anzulegen, auch einfach die Klassen separat geunittested werden, da ohnehin alles, was per DI hinzugefügt wird, auch von außen sichtbar ist. Vielleicht brauchen wir die Test-Components irgendwann, aber für jetzt passt es auch erstmal so.
Die Möglichkeit, die Konfigurationen über eine Properties-Datei auszulesen wandert gerade in eine separate Library.
