Tutoriel Android : Apprendre à utiliser Retrofit, OkIo, OkHttp et Moshi

Android2ee

Mathias Seguy

L'objectif de ce tutoriel est de vous expliquer l'ensemble des composants qui constituent RetroFit. Vous aurez ainsi une compréhension profonde et complète de sa structure et de son utilisation. Nous verrons ainsi Okio, la brique de base qui sert à la lecture et à l'écriture des données (que ce soit dans un fichier ou un socket). Nous verrons OkHttp qui permet la mise en place de la communication HTTP et nous ferons un détour par Moshi qui est le convertisseur JSON naturel à utiliser avec Retrofit pour convertir vos chaînes de caractères JSON en objet et vice versa.

Les versions dont parle ce tutoriel sont Retrofit 2.0, OkHttp 3, Okio 1.6 et Moshi 1.1.

Cet article est fortement inspiré des conférences données par Jake Wharton à Montréal et à New York en 2015 : disons simplement que je n'ai rien inventé.

- https://www.youtube.com/watch?v=WvyScM_S88c, Jake Wharton, DroidCon Montréal 2015

- https://www.youtube.com/watch?v=KIAoQbAu3eA, Jake Wharton, DroidCon NewYork 2015

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum : Commentez

- Titre : Tutoriel Android : Apprendre à utiliser Retrofit, OkIo, OkHttp et Moshi

- Auteur : Mathias Seguy

- Parution : 27 juin 2016

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2016 Winjerome. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Okio 1.6 : Lecture/écriture facile de fichiers et de flux

- I-A. Build Gradle

- I-B. Pourquoi JavaIo est désespérant ?

- I-C. L'interface Source pour lire les données

- I-D. L'interface Sink pour écrire les données

- I-E. Relation entre Sink et Source

- I-F. La classe Buffer, un simple pointeur

- I-F-1. Principes approfondis

- I-F-2. Exemple concret d'écriture et de lecture dans un fichier

- I-F-2-a. Pour l'écriture d'un fichier

- I-F-2-b. Pour la lecture d'un fichier

- I-F-2-c. La cerise sur le gâteau

- I-F-3. Les décorateurs

- I-F-3-a. GzipSink, GZipSource

- I-F-3-b. Custom décorateur

- I-F-4. Pour résumer

- II. OkHttp 3.0

- II-A. Build Gradle

- II-B. Principe

- II-C. Création du client

- II-D. Requête de type GET

- II-E. Requête de type POST

- II-F. Requête de type PUT/DELETE

- II-G. Faire une requête asynchrone

- II-H. Télécharger une image

- II-I. Ajouter un intercepteur

- II-J. Ajouter un intercepteur pour zipper automatiquement ses requêtes

- III. Moshi 1.1

- III-A. Build Gradle

- III-B. Écrire avec Moshi

- III-C. Lire avec Moshi

- III-D. Utilisation d'un adapter pour l'analyse automatique

- IV. Retrofit 2.0

- IV-A. Build Gradle

- IV-B. Principe

- IV-B-1. Instanciation d'un Service Retrofit

- IV-B-2. Appels synchrones ou asynchrones ?

- IV-B-3. L'objet Response

- IV-B-4. Annuler vos appels quand ils n'ont plus lieu d'être

- IV-C. Annotations

- IV-C-1. Les annotations @GET @PUT @POST @DELETE @Path @Body

- IV-C-2. Les annotations {@Multipart, @Part} et {@FormUrlEncoded, @Field}

- IV-C-3. Les annotations @Query, @QueryMap

- IV-C-4. L'annotation @Header et plus généralement la balise Header

- IV-D. Mise en place de l'authentification avec Retrofit

- IV-E. Mise en place des convertisseurs pour Retrofit

- IV-E-1. Convertisseur natif

- IV-E-2. Pourquoi utiliser Moshi comme convertisseur ?

- IV-E-3. Convertisseur spécifique (custom converter)

- IV-F. Call et CallAdapter personalisé

- IV-F-1. CallAdapter personalisé : exemple d'un ErrorHandler

- IV-G. Retrofit : mise en place du Logging

- IV-G-1. Logger natif

- IV-G-2. Logger spécialisé

- IV-H. Un conseil sur les URLs

- V. Bibliographie

- VI. Conclusion

- VII. Remerciements

I - Okio 1.6 : Lecture/écriture facile de fichiers et de flux

Okio est la brique élémentaire, elle permet la lecture/écriture des données.

I-A - Build Gradle

Il vous suffit de rajouter la dépendance vers Okio dans votre fichier gradle.build :

1. dependencies {

2. compile fileTree(dir: 'libs', include: ['*.jar'])

3. compile 'com.android.support:appcompat-v7:22.0.0'

4. compile 'com.squareup.okio:okio:1.6.0'

5. }

I-B - Pourquoi JavaIo est désespérant ?

Prenons l'exemple de la lecture d'un flux de données provenant d'un socket. Pour effectuer cette opération, il faut utiliser un ByteArrayInputStream qui possède une taille fixe de Buffer. C'est l'enfer à analyser, les données n'étant pas formatées pour respecter la taille du dit Buffer. Ainsi certains blocs de données se retrouvent sur deux Buffer différents.

En essayant d'être plus malin que le ByteArrayInputStream, on se dit que l'on va utiliser un pointeur pour analyser les données. Certaines données dépassent toujours du Buffer, on va alors augmenter sa taille à la volée…. ce qui amène un processus complexe et non adapté.

On peut aussi essayer d'utiliser des décorateurs pour s'aider mais le DataInputStream n'analyse pas le texte, l'InputStreamReader lui n'analyse pas les objets et utiliser les deux en même temps n'est pas non plus possible car les Buffer sur lesquels ils s'exécutent sont distincts.

On peut en conclure que, pour la lecture d'un flux, l'InputStream :

- possède un comportement non adapté, voire inconsistant ;

- oblige l'utilisateur à déterminer son besoin de stockage (doubler la taille du buffer en cours d'analyse en fonction des données reçues) ;

- est peu flexible et adaptable ;

C'est ainsi que Jesse Wilson et Jake Wharton ont décidé de créer une librairie spécifique pour effectuer une lecture/écriture de données plus pertinentes que celle fournie par le système : bienvenue à Okio.

I-C - L'interface Source pour lire les données

Une interface simple et épurée pour la lecture des données avec seulement trois méthodes.

1. public interface Source extends Closeable {

2. /**

3. * Removes at least 1, and up to {@code byteCount} bytes from this and appends

4. * them to {@code sink}. Returns the number of bytes read, or -1 if this

5. * source is exhausted.

6. */

7. long read(Buffer sink, long byteCount) throws IOException;

9. /** Returns the timeout for this source. */

10. Timeout timeout();

11. /**

12. * Closes this source and releases the resources held by this source. It is an

13. * error to read a closed source. It is safe to close a source more than once.

14. */

15. @Override void close() throws IOException;

16. }

Il n'y a qu'une seule méthode de lecture, read, qui possède en paramètre le Buffer. Celui-ci peut ainsi être partagé entre plusieurs sources de lecture et/ou d'écriture. C'est tout simple mais c'est une révolution pour la lecture de nos fichiers.

Le méthode timeout permet de récupérer le timeout de la source.

Et enfin, la méthode close pour clore la source.

I-D - L'interface Sink pour écrire les données

Une interface simple et épurée, encore, avec uniquement quatre méthodes.

1. public interface Sink extends Closeable, Flushable {

2. /** Removes {@code byteCount} bytes from {@code source} and appends them to this. */

3. void write(Buffer source, long byteCount) throws IOException;

5. /** Pushes all buffered bytes to their final destination. */

6. @Override void flush() throws IOException;

8. /** Returns the timeout for this sink. */

9. Timeout timeout();

11. /**

12. * Pushes all buffered bytes to their final destination and releases the

13. * resources held by this sink. It is an error to write a closed sink. It is

14. * safe to close a sink more than once.

15. */

16. @Override void close() throws IOException;

17. }

Le design étant le même que pour la classe Source, il n'y a qu'une méthode d'écriture qui possède en paramètre le Buffer sur lequel elle écrit (et peut ainsi le partager avec d'autres Source et Sink).

La méthode flush purge le Buffer et envoie toutes les données à leur destination finale.

Les méthodes timeout et close sont identiques à celles de l'objet Source.

I-E - Relation entre Sink et Source

Ces objets, Sink et Source, ne font que déplacer les données ; ainsi Source lit à partir d'un Sink (déplace le flux sortant vers un flux entrant de lecture) et Sink écrit les données à partir d'un source (déplace le flux entrant vers un flux sortant).

En effet, la méthode read de la classe Buffer est la suivante :

1. @Override

2. public long read(Buffer sink, long byteCount) {

3. if (sink == null) throw new IllegalArgumentException("sink == null");

4. if (byteCount < 0) throw new IllegalArgumentException("byteCount < 0: " + byteCount);

5. if (size == 0) return -1L;

6. if (byteCount > size) byteCount = size;

7. sink.write(this, byteCount);

8. return byteCount;

9. }

Je ne mets pas l'exemple de la méthode write, il est monstrueusement plus complexe.

I-F - La classe Buffer, un simple pointeur

C'est la classe à comprendre et qui explique le fonctionnement de Okio.

I-F-1 - Principes approfondis

Nous allons comprendre la classe Buffer par l'exemple, pas à pas.

L'instanciation d'un Buffer ne fait que créer un objet qui pointe vers un espace mémoire. En interne il est associé avec un SegmentedPool (un pool de byte[]) qu'il utilise pour lire et écrire ses données. Pour l'exemple que nous déroulons, nous supposons que ce pool possède des tableaux de 32 octets.

Ainsi :

1. Buffer buffer = new Buffer();

ne fait qu'allouer le Buffer qui alloue son pointeur, rien de plus.

Maintenant écrivons dans le Buffer :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

Le Buffer a récupéré un tableau d'octets du SegmentedPool et l'a utilisé pour écrire les données dedans. Puis il a incrémenté son attribut limit pour lui donner la valeur 19 qui est le nombre de caractères insérés.

Continuons d'écrire dans le Buffer :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

Le Buffer incrémente son attribut limit avec le nombre de caractères insérés. Cette limite ne dépassant pas la taille du tableau (32), rien ne se passe.

Continuons d'écrire dans le Buffer :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

4. buffer.writeUtf8("Thanks a billion");

Le Buffer regarde la chaîne qu'il doit écrire et s'aperçoit que cela dépasse la taille du tableau d'octets vers lequel il pointe, du coup il récupère un nouveau tableau au sein du SegmentedPool et écrit dans ce dernier.

Voilà pour les principes d'écriture, abordons la lecture.

Maintenant, lisons les six premiers caractères du Buffer :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

4. buffer.writeUtf8("Thanks a billion");

5. buffer.readUtf8(6);//returns Thanks

La valeur retournée par cette lecture est « Thanks » et le Buffer incrémente son attribut position, qui est sa position courante pour la lecture.

Continuons la lecture :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

4. buffer.writeUtf8("Thanks a billion");

5. buffer.readUtf8(6);//returns Thanks

6. //read the rest of the first segment

7. buffer.readUtf8(24);//returns Jake WhartonThanks Jake

La lecture renvoie « Jake WhartonThanks Jake » et l'attribut est incrémenté jusqu'à 30. Le Buffer réalise que sa position et sa limite sont égales. Il considère donc que le premier tableau est consommé et le restitue au SegmentedPool.

C'est une des premières et grandes optimisations qu'effectue Okio ; en effet, il ne réalloue pas de mémoire ni n'en désalloue. L'écriture et la lecture sont transparentes pour l'utilisateur de l'API, la gestion des tableaux d'octets étant effectuée par la classe Buffer sans que l'utilisateur ait à s'en soucier.

Abordons maintenant l'un des points dont M. Wharton est le plus content, qui est le partage de cette mémoire entre Buffer. Imaginons que vous souhaitiez à ce stade changer de lecteur de flux. Si vous étiez en train de travailler avec JavaIo, vous auriez dû réallouer de la mémoire, copier le contenu du premier InputStream dans le second et lire le second. Bref, du gaspillage de mémoire et de CPU.

Avec Okio, tout est optimisé, si vous déclarez un nouveau Buffer pour récupérer le flux, aucune nouvelle allocation de mémoire n'est effectuée, seul un changement de pointeur est fait :

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

4. buffer.writeUtf8("Thanks a billion");

5. buffer.readUtf8(6);//returns Thanks

6. //read the rest of the first segment

7. buffer.readUtf8(24);//returns Jake WhartonThanks Jake

8. //then create a new buffer

9. Buffer otherBuffer = new Buffer();

Comme nous l'avons vu, instancier un Buffer ne fait qu'instancier un pointeur.

Maintenant écrivons le flux du premier Buffer dans le second.

1. Buffer buffer = new Buffer();

2. buffer.writeUtf8("Thanks Jake Wharton");

3. buffer.writeUtf8("Thanks Jake");

4. buffer.writeUtf8("Thanks a billion");

5. buffer.readUtf8(6);//returns Thanks

6. //read the rest of the first segment

7. buffer.readUtf8(24);//returns Jake WhartonThanks Jake

8. //then create a new buffer

9. Buffer otherBuffer = new Buffer();

10. otherBuffer.writeAll(buffer);

Le second Buffer pointe maintenant vers le tableau d'octets et c'est tout. Il n'y a pas eu d'allocation mémoire, pas de copie des données et il continuera, s'il effectue d'autres opérations, à travailler avec le même SegmentedPool. N'est-ce pas magique ?

I-F-2 - Exemple concret d'écriture et de lecture dans un fichier

Oui mais dans la vraie vie, je fais comment pour lire et écrire avec cette API ?

Et bien c'est juste magiquement simple.

I-F-2-a - Pour l'écriture d'un fichier

C'est très facile et similaire à ce que vous faisiez avant, vous trouvez votre fichier, le créez au besoin et écrivez dedans.

La classe Okio possède un constructeur pour les Buffer, les Source et les Sink, il suffit de l'utiliser.

1. /** * Write a file */

2. private void writeCachFile(String str) {

3. //open

4. File myFile = new File(getCacheDir(), "myFile");

5. try {

6. //then write

7. if (!myFile.exists()) {

8. myFile.createNewFile();

9. }

10. BufferedSink okioBufferSink = Okio.buffer(Okio.sink(myFile));

11. okioBufferSink.writeUtf8(str);

12. //don't forget to close, otherwise nothing appears

13. okioBufferSink.close();

14. }

15. }

Il faut bien sûr faire attention à toujours fermer le Buffer.

I-F-2-b - Pour la lecture d'un fichier

Pour la lecture, c'est identique : on trouve le fichier et on le lit.

1. /**

2. * Read the file you just created

3. */

4. private void readCachFile() throws IOException {

5. //open

6. File myFile = new File(getCacheDir(), "myFile");

7. if(myFile.exists()) {

8. try {

9. BufferedSource okioBufferSrce = Okio.buffer(Okio.source(myFile));

10. str = okioBufferSrce.readUtf8();

11. Log.e("MainActivity", "readCachFile returns" + str);

12. okioBufferSrce.close();

13. } catch (IOException e) {

14. Log.e("MainActivity", "FileNotFoundException occurs", e);

15. str = " occurs, read the logs";

16. } finally {

17. txvCach.setText(str);

18. }

19. }

20. }

I-F-2-c - La cerise sur le gâteau

Le bonus qui est bien normal mais qui fait plaisir est que Okio.source() et Okio.sink() acceptent en paramètre les types suivants :

- File ;

- Path ;

- InputStream pour source() /OutPutStream pour sink() ;

- Socket ;

Vous avez à votre disposition toutes les méthodes qui vont bien pour la lecture/écriture (readInt, readLong, readUtf8, readUtf8LineStrict, readString… et pareil pour l'écriture).

Alors, elle n'est pas belle la vie ? Et merci qui ? Merci Jake Wharton et Jesse Wilson pour leur travail sur cette API.

Ah oui, et puis si j'en chope un en train de manipuler des InputStream dans leurs applications Android pour effectuer de la lecture/écriture, vous savez quoi, je lui coupe les ongles trop courts :) comme ça à chaque fois qu'il utilisera le clavier, une petite douleur lui rappellera « Utilise Okio pour écrire ou lire » :=)

Nous verrons plus d'exemples par la suite.

I-F-3 - Les décorateurs

Dernière fonctionnalité dont je souhaitais vous parler : les décorateurs.

I-F-3-a - GzipSink, GZipSource

Il y a deux décorateurs importants associés à Okio qui sont GZipSink et GZipSource, ils permettent de compresser le flux avant de l'écrire et de le décompresser avant de le lire et cela de manière transparente. Pour cela une seule ligne suffit :

1. private void zipWriteReadJakeSample() {

2. // Open

3. File myFile = new File(getCacheDir(), "myJakeFile");

4. try {

5. // Then write

6. if (!myFile.exists()) {

7. myFile.createNewFile();

8. }

9. Sink fileSink = Okio.sink(myFile);

10. Sink gzipSink = new GzipSink(fileSink);

11. BufferedSink okioBufferSink = Okio.buffer(gzipSink);

12. okioBufferSink.writeUtf8(str);

13. // Don't forget to close, otherwise nothing appears

14. okioBufferSink.close();

15. // Then read

16. myFile = new File(getCacheDir(), "myJakeFile");

17. GzipSource gzipSrc = new GzipSource(Okio.source(myFile));

18. BufferedSource okioBufferSrce = Okio.buffer(gzipSrc);

19. // if you want to see the zip stream

20. // BufferedSource okioBufferSrce=Okio.buffer(Okio.source(myFile));

21. str = okioBufferSrce.readUtf8();

22. } catch (FileNotFoundException e) {

23. Log.e("MainActivity", "FileNotFoundException occurs", e);

24. } catch (IOException e) {

25. Log.e("MainActivity", "IOException occurs", e);

26. } finally {

27. txvJakeWharton.setText(str);

28. }

29. }

Et voilà, vous avez compressé vos données avant de les écrire et les avez décompressées avant de les lire. Quand on pense que sous Android le problème de l'espace est un problème crucial, je vous engage à compresser avec cette méthode tout ce que vous écrivez sur le disque.

I-F-3-b - Custom décorateur

Il est facile de créer son propre décorateur, pour cela il vous suffit d'étendre la classe Sink ou Source ou les deux en fonction de votre besoin, puis d'utiliser un Sink pour rerouter l'écriture ou un Source pour rerouter la lecture. Je vous montre un exemple pour l'écriture :

1. public class SinkDecoratorSample implements Sink {

2. /**

3. * Sink into which does the real work .

4. */

5. private final BufferedSink sink;

7. /**

8. * The constructor .

9. */

10. public SinkDecoratorSample(Sink sink) {

11. if (sink == null) throw new IllegalArgumentException("sink == null");

12. this.sink = Okio.buffer(sink);

13. }

15. /**

16. * Removes {@code byteCount} bytes from {@code source} and appends them to this.

17. *

18. * @param source

19. * @param byteCount

20. */

21. @Override

22. public void write(Buffer source, long byteCount) throws IOException {

23. try {

24. Log.e("SinkDecoratorSample", "write has been called");

25. // Find the bytearray to write

26. ByteString bytes = ((BufferedSource) source).readByteString(byteCount);

27. // Here there is an instanciation

28. String data = bytes.utf8();

29. Log.e("SinkDecoratorSample", data.length());

30. // Do the real job

31. sink.write(bytes);

32. } catch (Exception e) {

33. Log.e("SinkDecoratorSample", "a crash occurs :", e);

34. }

35. }

37. /**

38. * Pushes all buffered bytes to their final destination.

39. */

40. @Override

41. public void flush() throws IOException {

42. sink.flush();

43. }

45. /**

46. * Returns the timeout for this sink.

47. */

48. @Override

49. public Timeout timeout() {

50. return sink.timeout();

52. }

54. /**

55. * Pushes all buffered bytes to their final destination and releases the

56. * resources held by this sink. It is an error to write a closed sink. It is

57. * safe to close a sink more than once.

58. */

59. @Override

60. public void close() throws IOException {

61. sink.close();

62. }

63. }

Rien de bien méchant.

Le point clef est le BufferedSink que vous utilisez pour faire le vrai boulot. Le constructeur n'utilise qu'un Sink pour vous permettre de les enchaîner lors de la construction.

La méthode write mérite un instant d'attention :

1. public void write(Buffer source, long byteCount) throws IOException {

2. try {

3. //find the bytearray to write

4. ByteString bytes = ((BufferedSource) source).readByteString(byteCount);

5. //here there is an instanciation

6. String data = bytes.utf8();

7. Log.e("SinkDecoratorSample", data.length());

9. //do the real job

10. sink.write(bytes);

11. } catch (Exception e) {

12. Log.e("SinkDecoratorSample", "a crash occurs :", e);

13. }

14. }

En effet, on obtient les données à partir de la Source initiale mais en la lisant, on la vide, il faut donc récupérer son contenu, faire notre traitement, puis demander au Sink décoré d'effectuer l'écriture en lui repassant les données.

Pour utiliser ce décorateur, il vous suffit de lui fournir votre Sink initial :

1. Sink initialSink=Okio.sink(myFile);

2. SinkDecoratorSample decoratedSink=new SinkDecoratorSample(initialSink);

3. BufferedSink okioBufferSink = Okio.buffer(decoratedSink);

4. okioBufferSink.writeUtf8(str);

5. //don't forget to close, otherwise nothing appears

6. okioBufferSink.close();

I-F-4 - Pour résumer

- Sink et Source bougent les données.

- Buffer et ByteString portent les données.

- Okio vous permet de créer les éléments Sink, Source et Buffer dont vous avez besoin.

II - OkHttp 3.0

OkHttp est un client HTTP, basé sur Okio pour la lecture/écriture du flux de données. Son objectif est de prendre en charge la communication avec le serveur.

Vous allez me dire que vous utilisez HttpClient/HttpUrlConnection et je vais vous répondre que c'est une mauvaise pratique, utilisez OkHttp à la place, cela vous évitera quelques bugs. Allez jeter un œil à cet article (https://packetzoom.com/blog/which-android-http-library-to-use.html), il vous explique l'historique des clients HTTP sur Android (qui est une vraie misère). Sachez juste que depuis Android 4.4, OkHttp est l'implémentation de HttpUrlConnection dans Android.

Donc, pour être compatible et propre sur toutes vos versions en utilisant le même code, OkHttp est le bon choix. Un autre choix est une erreur en fait.

II-A - Build Gradle

Il vous suffit de rajouter la dépendance vers OkHttp dans votre fichier gradle.build :

1. dependencies {

2. compile fileTree(dir: 'libs', include: ['*.jar'])

3. compile 'com.android.support:appcompat-v7:22.0.0'

4. compile 'com.squareup.okhttp3:okhttp:3.0.1'

5. }

II-B - Principe

Le principe est identique à ce que l'on a toujours fait avec nos communications HTTP. On crée un client HTTP, puis on utilise ce client pour effectuer nos requêtes (POST/GET/PUT/DELETE). Ces requêtes doivent être effectuées de manière asynchrone. Ainsi soit vous êtes déjà dans un thread différent du thread main (le thread IHM) auquel cas vous pouvez exécuter votre requête directement, soit vous êtes dans le thread main, auquel cas, vous effectuez votre requête en fournissant un CallBack. La requête est alors automatiquement exécutée dans un autre thread et le résultat vous est renvoyé dans votre CallBack.

Le principe est évident et sa mise en place avec OkHttp l'est aussi, merveilleux monde qui est le nôtre.

II-C - Création du client

La création du client est simple, vous utilisez le Builder fournit par la classe OkHttpClient et vous obtenez un client.

Il y a une bonne pratique à respecter : il vous faut ajouter un fichier de Cache à votre client. Pour cela, il suffit de créer un fichier dans votre dossier de cache, de lui donner une taille, d'instancier l'objet Cache associé (il sera automatiquement géré par le LruCach, trop bien joué) et de le passer à votre client HTTP lors de sa construction.

Ensuite, nous le verrons plus tard, il est possible d'ajouter des intercepteurs à votre client. Cela permet d'intercepter la requête pour effectuer un traitement, typiquement pour faire du log.

Le code est donc le suivant :

1. OkHttpClient client=null;

2. private  OkHttpClient getClient(){

3. if(client==null) {

4. //Assigning a CacheDirectory

5. File myCacheDir = new File(getCacheDir(), "OkHttpCache");

6. //you should create it...

7. int cacheSize = 1024 * 1024;

8. Cache cacheDir = new Cache(myCacheDir, cacheSize);

9. client = new OkHttpClient.Builder()

10. .cache(cacheDir)

11. .addInterceptor(getInterceptor())

12. .build();

13. }

14. //now it's using the cache

15. return client;

16. }

Maintenant, il ne nous reste plus qu'à l'utiliser.

II-D - Requête de type GET

Il faut deux éléments pour faire une requête GET :

- un client OkHttpClient, pour la communication ;

- une requête Request, de type get.

1. String urlGet = "http://jsonplaceholder.typicode.com/posts/1";

3. private String getAStuff() throws IOException {

4. Request request = new Request.Builder()

5. .url(urlGet)

6. .get()

7. .build();

8. //the synchronous way (Here it's ok we are in an AsyncTask already)

9. Response response = getClient().newCall(request).execute();

10. int httpStatusCode=response.code();

11. String ret = response.body().string();

12. //You can also have:

13. //Reader reader=response.body().charStream();

14. //InputStream stream=response.body().byteStream();

15. //byte[] bytes=response.body().bytes();

16. //But the best way, now you understand the OkIo

17. //because no allocation, no more buffering

18. //Source src=response.body().source();

19. //you should always close the body to enhance recycling mechanism

20. response.body().close();

21. return ret;

22. }

Un bonne pratique est aussi de vérifier le statut code de la réponse, vous avez une liste de ces codes ici : https://http.cat/ (enjoy :))

II-E - Requête de type POST

Le principe est le même que pour un get, à la différence qu'il vous faut un corps pour votre requête, ainsi trois paramètres sont nécessaires :

- un client OkHttpClient, pour la communication ;

- une requête Request, de type post ;

- et un corps RequestBody pour le contenu de votre requête.

1. String urlPost="http://jsonplaceholder.typicode.com/posts";

2. String json="data: {\n" +"    title: 'foo',\n" +"    body: 'bar',\n" +"    userId: 1\n" +"  }";

3. MediaType JSON= MediaType.parse("application/json; charset=utf-8");

5. private String postAStuff() throws IOException {

6. //            RequestBody body = RequestBody.create(JSON, file);

7. //            RequestBody body = RequestBody.create(JSON, byte[]);

8. RequestBody body = RequestBody.create(JSON, json);

9. Request request = new Request.Builder()

10. .url(urlPost)

11. .post(body)

12. .build();

13. Call postCall=getClient().newCall(request);

14. Response response = postCall.execute(); //you have your response code

15. int httpStatusCode=response.code();

16. //your responce body

17. String ret=response.body().string();

18. //and a lot of others stuff...

19. //you should always close the body to enhance recycling mechanism

20. response.body().close();

21. return ret;

22. }

Pour la partie JSON, ne vous enflammez pas, nous allons voir Moshi dans quelques paragraphes. Ce n'est pas comme ça qu'il faut générer son contenu JSON.

II-F - Requête de type PUT/DELETE

C'est identique à une requête de type POST, il faut juste, dans le Builder de la requête utiliser la méthode put ou delete et non plus post.

II-G - Faire une requête asynchrone

Pour effectuer une requête asynchrone, il suffit d'utiliser la méthode enqueue et non plus execute sur votre objet Call :

1. String urlPost="http://jsonplaceholder.typicode.com/posts";

2. String json="data: {\n" +"    title: 'foo',\n" +"    body: 'bar',\n" +"    userId: 1\n" +"  }";

3. MediaType JSON= MediaType.parse("application/json; charset=utf-8");

5. private String postAStuff() throws IOException {

7. OkHttpClient client = new OkHttpClient();

8. RequestBody body = RequestBody.create(JSON, json);

9. Request request = new Request.Builder()

10. .url(urlPost)

11. .post(body)

12. .build();

13. Call postCall=getClient().newCall(request);

14. postCall.enqueue(new Callback() {

15. @Override

16. public void onFailure(Request request, IOException e) {

17. // Failed

18. }

20. @Override

21. public void onResponse(Response response) throws IOException {

22. //Succeeded

23. }

24. });

25. }

Dans la méthode onFailure du CallBack vous gérez l'exception (et oui, la requête a raté) et dans la méthode onResponse vous effectuez le travail que vous souhaitiez faire.

Notez qu'il vous faut vérifier le statut code de votre réponse dans la méthode onResponse, un 404 n'est pas un échec, ni une exception.

II-H - Télécharger une image

Je vous montre un exemple assez courant pour télécharger une image.

1. String urlGetPicture = "http://jsonplaceholder.typicode.com/photos/1";

3. public Bitmap urlGetPicture() throws IOException {

4. Request request = new Request.Builder()

5. .url(urlGetPicture)

6. .get()

7. .build();

8. Call postCall = getClient().newCall(request);

9. Response response = postCall.execute();

10. if (response.code() == 200) {

11. ResponseBody in = response.body();

12. InputStream is = in.byteStream();

13. Bitmap bitmap = BitmapFactory.decodeStream(is);

14. is.close();

15. response.body().close();

16. // Now do a stuff, for example store it

17. return bitmap;

18. }

19. return null;

20. }

C'est tout simple comme code.

Juste pour information, si vous souhaitez l'enregistrer (pour faire du cache et ne pas avoir à la re-télécharger à chaque fois par exemple) :

1. /**

2. * How to save a Bitmap on the disk

3. * @param fileName

4. * @param bitmap

5. * @param ctx

6. * @throws IOException

7. */

8. private void savePicture(String fileName,Bitmap bitmap, Context ctx) throws IOException {

9. //Second save the picture

10. //--------------------------

11. //Find the external storage directory

12. File filesDir = ctx.getCacheDir();

13. //Retrieve the name of the subfolder where your store your picture

14. //(You have set it in your string ressources)

15. String pictureFolderName = "Pictures";

16. //then create the subfolder

17. File pictureDir = new File(filesDir, pictureFolderName);

18. //Check if this subfolder exists

19. if (!pictureDir.exists()) {

20. //if it doesn't create it

21. pictureDir.mkdirs();

22. }

23. //Define the file to store your picture in

24. File filePicture = new File(pictureDir, fileName);

25. //Open an OutputStream on that file

26. FileOutputStream fos = new FileOutputStream(filePicture);

27. //Write in that stream your bitmap in png with the max quality (100 is max, 0 is min quality)

28. bitmap.compress(Bitmap.CompressFormat.PNG, 100, fos);

29. //The close properly your stream

30. fos.flush();

31. fos.close();

33. }

II-I - Ajouter un intercepteur

Les intercepteurs sont très utiles pour effectuer un traitement systématique sur chaque requête envoyée. Un bon exemple est de systématiquement compresser son flux sortant (de même côté serveur) pour économiser de la bande passante et de le décompresser quand on reçoit la réponse.

Dans l'exemple qui suit, nous mettons en place un intercepteur de type logger.

Pour ajouter un intercepteur, il suffit de l'indiquer lors de la construction de votre client OkHttpClient :

1. OkHttpClient client = null;

3. private OkHttpClient getClient() {

4. if (client == null) {

5. //Assigning a CacheDirectory

6. File myCacheDir = new File(getCacheDir(), "OkHttpCache");

7. //you should create it...

8. int cacheSize = 1024 * 1024;

9. Cache cacheDir = new Cache(myCacheDir, cacheSize);

10. client = new OkHttpClient.Builder()

11. .cache(cacheDir)

12. .addInterceptor(getInterceptor())

13. .build();

14. }

15. //now it's using the cach

16. return client;

17. }

Il ne vous reste plus qu'à implémenter votre intercepteur :

1. public Interceptor getInterceptor() {

2. return new LoggingInterceptor();

3. }

5. class LoggingInterceptor implements Interceptor {

6. //Code pasted from okHttp webSite itself

7. @Override

8. public Response intercept(Chain chain) throws IOException {

9. Request request = chain.request();

10. long t1 = System.nanoTime();

11. Log.e("Interceptor Sample", String.format("Sending request %s on %s%n%s",

12. request.url(), chain.connection(), request.headers()));

14. Response response = chain.proceed(request);

16. long t2 = System.nanoTime();

17. Log.e("Interceptor Sample", String.format("Received response for %s in %.1fms%n%s",

18. response.request().url(), (t2 - t1) / 1e6d, response.headers()));

20. return response;

21. }

22. }

Pour cela, rien de plus simple : vous créez une classe qui implémente Interceptor et vous surchargez sa méthode intercept.

Dans cette méthode, pour obtenir la requête originale, il vous suffit de la demander au paramètre chain. Pour l'exécuter, il vous suffit d'appeler la méthode proceed du paramètre chain en lui repassant la requête. Et autour de cet appel à vous d'effectuer le travail que vous souhaitez faire.

Dans l'exemple, nous faisons du log.

II-J - Ajouter un intercepteur pour zipper automatiquement ses requêtes

Une vraiment bonne pratique est de compresser vos flux entrant et sortant pour économiser la bande passante de votre utilisateur. Cela se fait en quelques lignes de code.

Tout d'abord il faut ajouter cet intercepteur à votre client OkHttpClient.

1. OkHttpClient client = null;

3. private OkHttpClient getClient() {

4. if (client == null) {

5. //Assigning a CacheDirectory

6. File myCacheDir = new File(getCacheDir(), "OkHttpCache");

7. //you should create it...

8. int cacheSize = 1024 * 1024;

9. Cache cacheDir = new Cache(myCacheDir, cacheSize);

10. client = new OkHttpClient.Builder()

11. .cache(cacheDir)

12. .addInterceptor(getInterceptor())

13. .addInterceptor(new GzipRequestInterceptor())

14. .build();

15. }

16. //now it's using the cach

17. return client;

18. }

Ensuite il vous suffit de le définir :

1. /**

2. * This interceptor compresses the HTTP request body. Many webservers can't handle this!

3. */

4. final class GzipRequestInterceptor implements Interceptor {

5. @Override

6. public Response intercept(Chain chain) throws IOException {

7. Request originalRequest = chain.request();

8. if (originalRequest.body() == null

9. || originalRequest.header("Content-Encoding") != null) {

10. return chain.proceed(originalRequest);

11. }

13. Request compressedRequest = originalRequest.newBuilder()

14. .header("Content-Encoding", "gzip")

15. .method(originalRequest.method(), gzip(originalRequest.body()))

16. .build();

17. return chain.proceed(compressedRequest);

18. }

20. private RequestBody gzip(final RequestBody body) {

21. return new RequestBody() {

22. @Override

23. public MediaType contentType() {

24. return body.contentType();

25. }

27. @Override

28. public long contentLength() {

29. return -1; // We don't know the compressed length in advance!

30. }

32. @Override

33. public void writeTo(BufferedSink sink) throws IOException {

34. BufferedSink gzipSink = Okio.buffer(new GzipSink(sink));

35. body.writeTo(gzipSink);

36. gzipSink.close();

37. }

38. };

39. }

40. }

Pour que cela marche, il suffit de redéfinir un objet Request, avec comme MimeType le type gzip et comme contenu le corps (RequestBody) initial compressé. Pour compresser le RequestBody, rien de plus simple, vous utilisez Okio et son décorateur GZipSink.

Je vous laisse l'écriture de la décompression du flux de manière automatique en exercice :). Il vous suffit d'appliquer le GZipSource au body de la réponse renvoyée par chain.proceed, comme avec le LoggingInterceptor.

Ces deux exemples d'intercepteurs sont sortis de la librairie, je n'ai pas inventé le code :).

III - Moshi 1.1

Moshi est un parseur Json-Object qui est bâti sur Okio, il n'y a donc pas d'allocation mémoire lors de l'analyse, pas de recopie de données. L'encodage et le décodage UTF8 est optimisé. Et son utilisation est triviale.

Nous verrons tout d'abord comment lire et écrire avec Moshi « à la main », ce que vous ne ferez que rarement. Cela explique le lien entre Okio et Moshi et vous montre aussi que c'est simple. Puis nous verrons que Moshi possède des Adapters qui vont effectuer ce travail d'analyse en une ligne de code, ce qui est l'utilisation nominale de Moshi.

III-A - Build Gradle

Il vous suffit de rajouter la dépendance vers Okio dans votre fichier gradle.build :

1. dependencies {

2. compile fileTree(dir: 'libs', include: ['*.jar'])

3. compile 'com.android.support:appcompat-v7:22.0.0'

4. compile 'com.squareup.moshi:moshi:1.1.0'

5. }

III-B - Écrire avec Moshi

Pour écrire avec Moshi, il vous suffit d'obtenir un Okio.Sink. Cela tombe bien, nous savons en créer facilement à partir d'un fichier, nous en récupérons un aussi lors de l'utilisation de OkHttp (nous avons aussi vu que nous pouvons ajouter des Decorators à ce Sink et là tout devient possible). Ensuite il suffit d'y écrire son objet, comme on fait avec JSON depuis que JSON existe.

Dans l'exemple ci-dessous, on écrit dans un fichier.

1. public void writeJson(Context ctx) {

2. //open

3. File myFile = new File(ctx.getCacheDir(), "myJsonFile");

4. try {

5. //then write

6. if (!myFile.exists()) {

7. myFile.createNewFile();

8. }

9. BufferedSink okioBufferSink = Okio.buffer(Okio.sink(myFile));

10. //do the Moshi stuff:

11. JsonWriter jsonW = new JsonWriter(okioBufferSink);

12. writeJson(jsonW);

13. //you have to close the JsonWrtiter too (else nothing will happen)

14. jsonW.close();

15. //don't forget to close, else nothing appears

16. okioBufferSink.close();

17. } catch (FileNotFoundException e) {

18. Log.e("MainActivity", "FileNotFoundException occurs", e);

19. } catch (IOException e) {

20. Log.e("MainActivity", "IOException occurs", e);

21. }

22. }

Ainsi, on récupère un fichier, puis un Sink sur ce fichier en utilisant Okio et on instancie un JsonWriter à partir de ce Sink. Le processus d'écriture est détaillé dans la méthode writeJson que nous allons voir.

Il faut bien faire attention à clore le JsonWriter et le Sink. Si vous oubliez de les clore, rien ne se passera (enfin si, une fuite mémoire).

La méthode writeJson ci-dessous montre comment écrire un fichier JSON avec Moshi :

1. private void writeJson(JsonWriter jsonW) {

2. try {

3. jsonW.beginObject();

4. jsonW.name("Attribute1").value("Has a Value");

5. jsonW.name("Attribute2").value(12);

6. jsonW.name("Attribute3").value(true);

7. jsonW.name("AttributeObject").value("AnotherObject")

8. .beginObject()

9. .name("Attribute1").value("Has a Value")

10. .name("Attribute2").value(12)

11. .name("Attribute3").value(true)

12. .endObject();

13. jsonW.name("Array")

14. .beginArray()

15. .value("item1")

16. .value("item2")

17. .value("item3")

18. .endArray();

19. jsonW.endObject();

21. } catch (IOException e) {

22. e.printStackTrace();

23. }

24. }

Comme vous le voyez toutes les méthodes sont là. On commence par ouvrir un objet, on lui ajoute ses attributs, on peut lui ajouter un tableau de primitifs, un tableau d'objets, un objet… Bref, c'est trivial.

III-C - Lire avec Moshi

Pour lire avec Moshi, il vous suffit d'obtenir un Okio.Source. Cela tombe bien, nous savons en créer facilement à partir d'un fichier, nous en récupérons un aussi lors de l'utilisation de OkHttp. Ensuite il suffit de lire et reconstruire son objet.

Dans l'exemple ci-dessous, on lit le fichier que l'on vient de créer précédemment.

Tout d'abord, il nous faut récupérer le Okio.Source à lire :

1. public String readJson(Context ctx) {

2. Log.e("MoshiSample", "readJson called");

3. //open

4. File myFile = new File(ctx.getCacheDir(), "myJsonFile");

5. JsonReader reader=null;

6. StringBuilder strBuild=new StringBuilder();

7. String eol= System.getProperty("line.separator");

8. try {

9. //then write

10. if (!myFile.exists()) {

11. Log.e("MoshiSample", "readJson: file doesn't exist ");

12. myFile.createNewFile();

13. }else{

14. Log.e("MoshiSample", "readJson: File exists ");

15. }

16. //check the file by reading it using OkIo

17. BufferedSource okioBufferSrce = Okio.buffer(Okio.source(myFile));

18. strBuild.append("File content :" + okioBufferSrce.readUtf8()).append(eol);

19. strBuild.append("file read... now trying to parse JSon\r\n").append(eol);

20. okioBufferSrce.close();

22. //Build the source :

23. BufferedSource source = Okio.buffer(Okio.source(myFile));

Maintenant que nous avons l'objet Source, il ne reste plus qu'à l'analyser :

1. //Then read th JSon File

2. reader = JsonReader.of(source);

3. reader.beginObject();

4. while (reader.hasNext()) {

5. strBuild.append("peek :" + reader.peek()).append(eol);

6. switch (reader.nextName()) {

7. case "Attribute1":

8. strBuild.append("Attribute1 :" + reader.nextString()).append(eol);

9. break;

10. case "Attribute2":

11. strBuild.append("Attribute2 :" + reader.nextInt()).append(eol);

12. break;

13. case "Attribute3":

14. strBuild.append("Attribute3 :" + reader.nextBoolean()).append(eol);

15. break;

16. case "AttributeObject":

17. //Parse an object (same as here)

18. reader.beginObject();

19. strBuild.append("subobject " + reader.nextName() + " :"

20. + reader.nextString()).append(eol);

21. strBuild.append("subobject " + reader.nextName() + " :" +

22. + reader.nextString()).append(eol);

23. strBuild.append("subobject " + reader.nextName() + " :" +

24. + reader.nextString()).append(eol);

25. reader.endObject();

26. break;

27. case "Array":

28. strBuild.append("Array").append(eol);

29. reader.beginArray();

30. while (reader.hasNext()) {

31. strBuild.append("new item:" + reader.nextString()).append(eol);

32. }

33. reader.endArray();

34. break;

35. case "ArrayWithName":

36. strBuild.append("array with only name/values pairs").append(eol);

37. reader.beginArray();

38. while (reader.hasNext()) {

39. reader.beginObject();

40. strBuild.append("item : " + reader.nextName() + " :"

41. + reader.nextString()).append(eol);

42. reader.endObject();

43. }

44. reader.endArray();

45. break;

46. //others cases

47. default:

48. break;

49. }

50. }

51. reader.endObject();

52. reader.close();

53. okioBufferSrce.close();

54. } catch (FileNotFoundException e) {

55. Log.e("MainActivity", " FileNotFoundException occurs", e);

56. } catch (IOException e) {

57. Log.e("MainActivity", " IOException occurs", e);

58. } catch (Exception e) {

59. Log.e("MainActivity", " Exception occurs", e);

60. } finally {

61. Log.e("MoshiSample", "readJson over ehoeho !!!" + strBuild.toString());

62. return strBuild.toString();

63. }

64. }

Rien de bien compliqué : on parcourt notre structure en appelant la méthode hasNext, puis on demande le nom (nextName) et on récupère la valeur associée à ce nom (getString, getInt…). Pour les tableaux, les sous-objets, c'est le même principe.

Mais franchement, qui analyse encore ses fichiers JSON à la main ?

III-D - Utilisation d'un adapter pour l'analyse automatique

Les Adapters Moshi vous permettent de faire la conversion automatique de vos objets vers leur représentation JSON (et inversement).

Pour cela, rien de plus simple, il suffit de créer un objet Moshi et de l'utiliser pour créer les Adapters dont on a besoin. Pour chaque objet à convertir, il vous faut un Adapter :

1. Moshi moshi = new Moshi.Builder().build();

2. JsonAdapter<MyJsonObject> adapter = moshi.adapter(MyJsonObject.class);

Et voilà, c'est fini, vous avez créé l'Adapter associé à l'objet MyJsonObject. Il ne reste plus qu'à l'utiliser.

Pour l'écriture, il suffit de demander à l'Adapter d'effectuer le boulot en lui passant l'objet à convertir et le Sink dans lequel écrire :

1. public String usingAdapter(Context ctx) {

2. //open

3. File myFile = new File(ctx.getCacheDir(), "myJsonObjectFile");

4. try {

5. //then write

6. if (!myFile.exists()) {myFile.createNewFile();}

7. BufferedSink okioBufferSink = Okio.buffer(Okio.sink(myFile));

8. adapter.toJson(okioBufferSink, new MyJsonObject());

9. //don't forget to close, otherwise nothing appears

10. okioBufferSink.close();

Pour l'écriture (nous sommes toujours dans la même méthode), c'est pareil, l'Adapter fait tout le boulot pour vous :

1. //then read :

2. BufferedSource okioBufferSource = Okio.buffer(Okio.source(myFile));

3. myObj = adapter.fromJson(okioBufferSource);

4. } catch (FileNotFoundException e) {

5. Log.e("MainActivity", "FileNotFoundException occurs", e);

6. } catch (IOException e) {

7. Log.e("MainActivity", "IOException occurs", e);

8. } finally {

9. return myObj==null?"null":myObj.toString();

10. }

11. }

Comment dire ? Plus simple, tu meurs.

IV - Retrofit 2.0

L'objectif de Retrofit est de fournir un framework puissant qui vous permet de mettre en place une abstraction simple et cohérente pour vos appels réseaux, changeant votre API HTTP en interface Java.

Ainsi Retrofit :

- vous permet de déclarer votre couche réseau sous forme d'une interface ;

- vous fournit un objet Call qui encapsule l'interaction avec une requête et sa réponse ;

- vous permet de paramétrer l'objet Response ;

- offre de multiples et efficaces convertisseurs (XML, JSON) ;

- offre de multiples mécanismes pluggables d'exécution.

Bref, elle vous simplifie la vie au niveau de la couche réseau de votre application, tout en implémentant pour vous les bonnes pratiques d'abstraction et en vous permettant de personnaliser son comportement.

De plus, elle est bâtie sur Okio, OkHttp et peut utiliser Moshi pour convertir vos objets JSON.

IV-A - Build Gradle

Il vous suffit de rajouter la dépendance vers Retrofit dans votre fichier gradle.build :

1. dependencies {

2. compile fileTree(dir: 'libs', include: ['*.jar'])

3. compile 'com.android.support:appcompat-v7:22.2.0'

4. //compile 'com.squareup.okhttp3:okhttp:3.0.1'<-a bug here

5. compile 'com.squareup.retrofit2:retrofit:2.0.0-beta3'

6. compile 'com.squareup.okhttp3:okhttp:3.0.0-RC1'

7. compile 'com.squareup.retrofit2:converter-moshi:2.0.0-beta3'

8. compile 'com.squareup.okhttp3:logging-interceptor:3.0.0-RC1'

9. }

Par contre, comme vous le voyez, Retrofit a besoin d'OkHttp pour fonctionner.

Nous utiliserons aussi le Logging-Interceptor et Moshi dans la suite de ce chapitre, d'où leur présence dans ce fichier.

IV-B - Principe

Retrofit a pour objectif de simplifier la gestion de vos appels réseaux avec une interface, une instance de cette interface, appelée Service (mais ça n'a rien à voir avec les services Android) et un appel de type Call. Pour des raisons de clarté nous appellerons les instances de ces interfaces des services Retrofit.

L'interface vous permet de définir les requêtes :

1. public interface WebServerIntf {

2. @GET("posts/1")

3. Call<Post> getPostOne();

5. @GET("posts/{id}")

6. Call<Post> getPostById(@Path("id") int id);

8. @GET("posts")

9. Call<List<Post>> getPostsList();

10. }

L'instanciation de cette interface se fait via un objet Retrofit et permet de construire un service Retrofit qui est utilisé pour faire les appels.

J'ai regroupé, dans ces exemples, toutes les constructions de l'objet Retrofit, du service Retrofit et du client OkHttpClient dans une même classe nommée RetrofitBuilder :

1. public class RetrofitBuilder {

2. public static final String BASE_URL = "http://jsonplaceholder.typicode.com/";

4. public static WebServerIntf getSimpleClient(){

5. //Using Default HttpClient

6. Retrofit retrofit = new Retrofit.Builder()

7. //you need to add your root url

8. .baseUrl(BASE_URL)

9. .build();

10. WebServerIntf webServer=retrofit.create(WebServerIntf.class);

11. return webServer;

12. }

13. }

Les appels se font alors simplement :

1. public class BusinessService {

2. // Make the Rest Call

3. // OkIo, OkHttp and Moshi are behind

4. getPostOneCall = webService.getPostOne();

6. // So you need to make an async call

7. getPostOneCall.enqueue(new Callback<Post>() {

8. @Override

9. public void onResponse(Response<Post> response) {

10. }

11. @Override

12. public void onFailure(Throwable t) {

13. }

14. });

15. }

Il faut un nouvel objet Call pour chaque appel. Une fois que l'objet Call a effectué l'appel, il n'est plus utilisable. Vous pouvez cloner vos objets Call pour pouvoir « les utiliser plusieurs fois » avant cet appel.

Dans la suite de cet article, j'ai regroupé tous les appels au sein d'une classe qui se nomme BuisnessService. En effet, c'est une bonne pratique de ne pas effectuer ces appels directement dans vos activités ou vos fragments mais dans une classe à part. Si, de plus, cette classe suivait le cycle de vie de l'application et non pas celui de vos activités avec un système de caching, ce serait une bonne architecture.

IV-B-1 - Instanciation d'un Service Retrofit

De manière assez naturelle, vous mettrez en place un service Retrofit du type suivant :

1. public class RetrofitBuilder {

2. public static WebServerIntf getComplexClient(Context ctx) {

3. // get the OkHttp client

4. OkHttpClient client = getOkHttpClient(ctx);

6. // now it's using the cach

7. // Using my HttpClient

8. Retrofit raCustom = new Retrofit.Builder()

9. .client(client)

10. .baseUrl(BASE_URL)

11. //add your own converter first (declaration order matters)

12. //the responsability chain design pattern is behind

13. .addConverterFactory(new MyPhotoConverterFactory())

14. //You need to add a converter if you want your Json to be automagicly convert

15. //into the object

16. .addConverterFactory(MoshiConverterFactory.create())

17. //then add your own CallAdapter

18. .addCallAdapterFactory(new ErrorHandlingCallAdapterFactory())

19. .build();

20. WebServerIntf webServer = raCustom.create(WebServerIntf.class);

21. return webServer;

22. }

23. }

Nous avons construit pour instancier l'interface un objet Retrofit qui possède les caractéristiques suivantes :

- nous fournissons le client OkHttpClient qui est utilisé pour la communication HTTP (nous y reviendrons) ;

- nous définissons BASE_URL, l'URL racine pour tous nos appels ;

- nous ajoutons un ConverterFactory de type MyPhotoConverterFactory, un objet qui convertit spécifiquement les objets de type Photo ;

- nous ajoutons un ConverterFactory de type MoshiConverterFactory qui servira à convertir tous les objets (non Photo) automatiquement en utilisant Moshi ;

- nous ajoutons un CallAdapterFactory qui nous permet une gestion plus fine des erreurs rencontrées.

Nous verrons tous ces éléments un à un mais commençons par le client OkHttpClient et regardons comment le définir :

1. public class RetrofitBuilder {

2. @NonNull

3. public static OkHttpClient getOkHttpClient(Context ctx) {

4. // Define the OkHttp Client with its cache!

5. // Assigning a CacheDirectory

6. File myCacheDir=new File(ctx.getCacheDir(),"OkHttpCache");

7. // You should create it...

8. int cacheSize=1024*1024;

9. Cache cacheDir=new Cache(myCacheDir,cacheSize);

10. Interceptor customLoggingInterceptor=new CustomLoggingInterceptor();

11. HttpLoggingInterceptor httpLogInterceptor=new HttpLoggingInterceptor();

12. httpLogInterceptor.setLevel(HttpLoggingInterceptor.Level.BASIC);

13. return new OkHttpClient.Builder()

14. //add a cache

15. .cache(cacheDir)

16. //add interceptor (here to log the request)

17. .addInterceptor(customLoggingInterceptor)

18. .addInterceptor(httpLogInterceptor)

19. .build();

20. }

21. }

C'est un client OkHttpClient typique, il possède un Cache et nous lui avons ajouté deux Interceptors pour faire du logging. Un seul aurait suffi mais pour l'article, je rajoute le natif (HttpLoggingInterceptor) et un custom (CustomLoggingInterceptor).

Je pense que vous n'avez pas réalisé mais en quelques lignes de code nous avons fait un truc de dingues : toutes nos requêtes sont loggées, toutes nos erreurs sont traitées de façon centralisée, tous nos objets sont automatiquement convertis au format JSON (et vice versa) et nous avons une classe concrète pour effectuer les appels réseaux que nous avons définis dans notre interface.

IV-B-2 - Appels synchrones ou asynchrones ?

Il n'y a rien de plus facile avec Retrofit que de faire un appel synchrone ou asynchrone. Vous n'avez plus à définir dans votre interface d'appels si vous souhaitez effectuer le traitement de manière synchrone ou pas. C'était le cas dans Retrofit 1.* et c'est une grande amélioration de Retrofit 2.

Imaginez que nous ayons défini notre interface d'appels ainsi :

1. public interface WebServerIntf {

2. @GET("posts/1")

3. Call<Post> getPostOne();

5. @GET("posts/{id}")

6. Call<Post> getPostById(@Path("id") int id);

8. @GET("posts")

9. Call<List<Post>> getPostsList();

10. }

Nous reviendrons sur la déclaration de cette interface quand nous aborderons le chapitre « Annotations ».

Pour faire un appel, il vous faut un objet Call qui s'obtient simplement en le demandant à votre service Retrofit :

1. Call<Post> getPostOneCall getPostByIdCall = webServiceComplex.getPostOne();

Ainsi pour faire un appel synchrone (vous avez défini votre interface d'appels et votre service Retrofit, bien entendu), il suffit d'appeler la méthode execute sur cet objet :

1. Response<Post> response=getPostOneCall.execute();

L'objet renvoyé est un objet de type Response avec pour paramètre de généricité le type d'objet encapsulé dans cette réponse.

Pour effectuer le même appel de manière asynchrone :

1. getPostOneCall.enqueue(new Callback<Post>() {

2. @Override

3. public void onResponse(Response<Post> response) {

4. Log.e("BusinessService", "The call is back with success");

5. }

7. @Override

8. public void onFailure(Throwable t) {

9. Log.e("BusinessService", "The call failed");

10. }

11. });

Nous fournissons un CallBack. Si la réponse nous revient de manière normale nous passons par la méthode onResponse, si une exception est survenue durant le traitement, nous revenons dans la méthode onFailure.

À noter que vous pouvez très bien revenir dans la méthode onResponse avec une réponse de code 404… Il ne faut pas confondre une erreur d'exécution et une erreur dans la réponse. Une erreur dans la réponse assure justement une absence d'erreur d'exécution, vous n'avez pas votre résultat pour autant, on est d'accord.

IV-B-3 - L'objet Response

Un objet Response possède les attributs body, code, message, isSuccess, headers, errorBody et raw. Si nous affichons ces attributs nous obtenons les valeurs suivantes :

1. //This will log this information

2. //Analyzing a response Object

3. //Analyzing a response.code()=200

4. //Analyzing a response.message()=OK

5. //Analyzing a response.isSuccess()=true

6. //Analyzing a response.headers()=Connection: keep-alive

7. //                Content-Type: application/json; charset=utf-8

8. //                Server: Cowboy

9. //                X-Powered-By: Express

10. //                Vary: Origin

11. //                Access-Control-Allow-Credentials: true

12. //                Cache-Control: no-cache

13. //                Pragma: no-cache

14. //                Expires: -1

15. //                X-Content-Type-Options: nosniff

16. //                Etag: W/"1fd-jhjIa9s91vj8ZufojwdSzA"

17. //                Date: Thu, 21 Jan 2016 15:11:30 GMT

18. //                Via: 1.1 vegur

19. //                OkHttp-Sent-Millis: 1453389092618

20. //                OkHttp-Received-Millis: 1453389096044

21. //Analyzing a response.errorBody()=null

22. //Analyzing a response.raw()=Response{protocol=http/1.1, code=200, message=OK, url=http://jsonplaceholder.typicode.com/users/2}

Les valeurs changent (on est bien d'accord) en fonction du type d'appel, du serveur appelé, de sa réponse… mais ça vous donne une bonne idée de à quoi correspondent ces champs.

IV-B-4 - Annuler vos appels quand ils n'ont plus lieu d'être

Une dernière fonctionnalité bien utile de Retrofit est de pouvoir annuler les appels. Ainsi, s'ils sont liés au cycle de vie d'une activité, annulez-les dans la méthode onStop. S'ils sont liés au cycle de vie d'un autre objet, n'oubliez pas de les annuler quand cet objet meurt.

Par exemple, dans le tutoriel associé à cet article, ma classe BusinessService qui implémente les appels possède une méthode release qui est appelée quand mon activité passe dans onStop :

1. public void release() {

2. activity = null;

3. //you have to cancel your calls in onStop

4. getPostOneCall.cancel();

5. getPostByIdCall.cancel();

6. getPostListCall.cancel();

7. getUsersListCall.cancel();

8. getUserByIdCall.cancel();

9. getPhotoWithQueryCall.cancel();

10. }

IV-C - Annotations

Les annotations sont utilisées pour décrire votre interface d'appels, vos méthodes POST/GET/PUT/DELETE.

Je fais une petite digression sur ces 4 méthodes qui sont des normes du W3C pour votre culture générale (la mienne étant lacuneuse à ce sujet, je me dis que je ne dois pas être le seul) :

- GET : la méthode GET signifie récupérer toutes les informations (sous la forme d'une entité) identifiées par l'URI de la requête ;

- POST : la méthode POST est utilisée pour demander que le serveur d'origine accepte l'entité incluse dans la demande comme un nouveau subordonné de la ressource identifiée par l'URI de la requête ;

- PUT : la méthode PUT demande que l'entité incluse soit stockée sous l'URI de la requête ;

- DELETE : la méthode DELETE demande que le serveur d'origine supprime la ressource identifiée par l'URI de la requête.

Reprenons : ainsi les annotations sont utilisées pour décrire vos requêtes. Ainsi, le code et les explications de ce chapitre appartiennent à la classe :

1. public interface WebServerIntf {

IV-C-1 - Les annotations @GET @PUT @POST @DELETE @Path @Body

@GET @PUT @POST @DELETE sont les annotations principales qui définissent le type de la requête.

Nous les utilisons ainsi :

1. @GET("posts/1")

2. Call<Post> getPostOne();

3. @POST("posts")

4. Call<Post> addNewPost(@Body Post post);

5. @PUT("users/1")

6. Call<User> updateUserOne(@Body User user);

7. @DELETE("user/{id}")

8. Call<User> deleteUserById(@Path("id")int id);

Les types Post et Put doivent avoir un corps (Body) qui spécifie l'entité à traiter, ainsi ils utilisent la balise @BODY en paramètre pour passer l'objet Post au serveur.

Le balise @BODY permet ainsi de spécifier le corps de la requête. Il n'est pas rare que nous passions un corps à nos requêtes dans une méthode GET.

Vous pouvez passer un paramètre null pour un @Body sans que cela ne gêne, votre requête ne possèdera juste pas de corps.

L'encodage des objets passés en paramètre sera effectué en utilisant le(s) convertisseur(s) que vous avez définis lors de l'instanciation de votre objet Retrofit (celui qui permet d'instancier votre interface d'appels).

La balise @Path permet d'avoir des URL dynamiques qui seront résolues lors de l'exécution. Ainsi :

1. @GET("posts/{id}")

2. Call<Post> getPostById(@Path("id") int id);

permet de spécifier que le paramètre id passé en paramètre de la méthode getPostById servira à construire l'URL finale.

IV-C-2 - Les annotations {@Multipart, @Part} et {@FormUrlEncoded, @Field}

Ces annotations servent à définir le type Mime (le MimeType) de votre requête et de passer un ensemble d'éléments à votre serveur avec un formatage cohérent vis-à-vis de ce type Mime.

Ainsi pour définir une requête possédant plusieurs parties :

1. @Multipart

2. @PUT("photos")

3. Call<Photo> newPhoto(@Part("photo") Photo photoObject,

4. @Part("content") byte[] picture);

Pour définir une requête de type FormUrlEncoded :

1. @FormUrlEncoded

2. @POST("user/{id}/edit")

3. Call<User> updateUserWithForm(@Path("id")int id,

4. @Field("name")String name,

5. @Field("points")int point);

Pour aller plus loin dans la compréhension de ces types, je vous propose de jeter un coup d'œil à cette question sur Stack Overflow.

IV-C-3 - Les annotations @Query, @QueryMap

Ces annotations permettent d'encoder les paramètres en tant que query dans votre URL.

Ainsi si vous définissez votre interface ainsi :

1. @GET("photos/1")

2. Call<Photo> getPhotoWithQuery(@Query("data") int id,

3. @QueryMap Map<String,String>option);

Il vous suffit de l'utiliser ainsi :

1. HashMap<String, String> options = new HashMap<String, String>();

2. options.put("parameter1", "value1");

3. options.put("parameter2", "value2");

4. options.put("parameter3", "value3");

5. getPhotoWithQueryCall = webServiceComplex.getPhotoWithQuery(3, options);

Et la requête résultante ressemblera à cela :

1. http://jsonplaceholder.typicode.com/photos/1?data=3&parameter2=value2&parameter1=value1&parameter3=value3

Un cas particulier de l'utilisation du Query est lorsque l'on souhaite que les mêmes paramètres soient utilisés plusieurs fois. Il suffit alors juste de mettre une liste :

1. @GET("photos")

2. Call<Photo> getPhotoWithQuery(@Query("id") List<Integer> id);

Vous obtiendrez (en passant une liste à la méthode getPhotoWithQuery) :

1. http://jsonplaceholder.typicode.com/photos/1?id=3&id=2&id=1&id=4

Vous pouvez passer null à n'importe lequel de ces paramètres (@Query ou @QueryMap), le paramètre sera juste omis de la requête.

IV-C-4 - L'annotation @Header et plus généralement la balise Header

La balise @Header permet de rajouter des paramètres dans le header de votre requête.

Vous pouvez le spécifier de manière statique :

1. @Headers({

2. "Accept: application/vnd.yourapi.v1.full+json",

3. "User-Agent: Your-App-Name"

4. })

5. @GET("posts/1")

6. Call<Post> getPostOne();

Vous pouvez le spécifier de manière dynamique :

1. @GET("posts/{id}")

2. Call<Post> getPostById(@Header("Content-Range")String contentRange,

3. @Path("id") int id);

Il suffit ensuite de le passer en paramètre de votre méthode.

Enfin vous pouvez spécifier un header général à toutes vos requêtes mais pour ça il faut le rajouter au niveau de votre client OkHttpClient :

1. public class RetrofitBuilder {

2. OkHttpClient.Builder httpClient = new OkHttpClient.Builder();

3. httpClient.interceptors().add(new Interceptor() {

4. @Override

5. public Response intercept(Interceptor.Chain chain) throws IOException {

6. Request original = chain.request();

8. Request request = original.newBuilder()

9. .header("User-Agent", "Your-App-Name")

10. .header("Accept", "application/vnd.yourapi.v1.full+json")

11. .method(original.method(), original.body())

12. .build();

14. return chain.proceed(request);

15. }

16. }

17. }

IV-D - Mise en place de l'authentification avec Retrofit

Je n'expliquerai dans cet article que la mise en place d'une autorisation simple, vous fournissant quelques liens si vous souhaitez aller plus loin. L'authentification mériterait un bon gros article à elle seule.

Le principe de l'authentification simple est de rajouter une chaîne de caractères dans le header de vos requêtes pour permettre au serveur d'authentifier l'utilisateur. Il faut donc la rajouter au niveau du client HTTP à sa création. Cette création étant appelée lors de la création du service Retrofit, c'est cette méthode qui va calculer cette chaîne de caractères :

1. public class RetrofitBuilder {

3. // Basic credentials send to the server at each request */

4. private static String basicCredential = null;

6. // Retrieve an authenticated Retrofit webserver */

7. public static WebServerIntf getAuthenticatedClient(Context ctx, String name, String assword) {

8. String credentials = name + ":" + password;

9. basicCredential = "Basic " + Base64.encodeToString(credentials.getBytes(), Base64.NO_WRAP);

11. // Get the OkHttp client

12. OkHttpClient client = getOkAuthenticatedHttpClient(ctx);

14. // Now it's using the cach

15. // Using my HttpClient

16. Retrofit raCustom = new Retrofit.Builder()

17. .client(client)

18. .baseUrl(BASE_URL)//You need to add a converter if you want your Json to be automagicly convert

19. //into the object

20. .addConverterFactory(MoshiConverterFactory.create())

21. .build();

22. WebServerIntf webServer = raCustom.create(WebServerIntf.class);

23. return webServer;

24. }

25. }

La méthode getOkAuthenticatedHttpClient se contente de mettre en place le header pour toutes les requêtes.

1. @NonNull

2. public static OkHttpClient getOkAuthenticatedHttpClient(Context ctx) {

3. return new OkHttpClient.Builder()

4. .addInterceptor(new Interceptor() {

5. @Override

6. public Response intercept(Chain chain) throws IOException {

7. Request original = chain.request();

9. Request.Builder requestBuilder = original.newBuilder()

10. .header("Authorization", basicCredential)

11. .header("Accept", "applicaton/json")

12. .method(original.method(), original.body());

14. Request request = requestBuilder.build();

15. return chain.proceed(request);

16. }

17. })

18. .build();

19. }

Ces méthodes, dans mon exemple, appartiennent toutes deux à la classe que j'ai appelée RetrofitBuilder.

Maintenant il n'y a plus qu'à utiliser ce service pour exécuter toutes nos requêtes ayant besoin d'authentification.

La définition et l'appel HTTP n'ont pas changé, il n'y a pas de paramètre à passer à la méthode login.

Ainsi si je définis l'interface d'appels suivante :

1. public interface WebServerIntf {

2. @GET("users/authent")

3. Call<User>login();

4. }

Je peux alors simplement effectuer des requêtes authentifiées :

1. public class BusinessService {

2. // The call for authentification

3. Call<User>authentificateUserCall;

5. // The authenticated user

6. User currentUser;

8. // Should be called first when using authentificated request

9. public void initializeAuthentificatedCommunication(Context ctx,String name, String

10. password){

11. webServiceAuthenticated=

12. RetrofitBuilder.getAuthenticatedClient(ctx,name,password);

13. }

15. // An exemple of authenticated request

16. public void login() {

17. // Your service add credentials in the header, so just call login

18. authentificateUserCall=webServiceAuthenticated.login();

19. authentificateUserCall.enqueue(new Callback<User>() {

20. @Override

21. public void onResponse(Response<User> response) {

22. if(response.body()!=null){

23. //ok your user is authentificated

24. currentUser=response.body();

25. }

26. }

27. @Override

28. public void onFailure(Throwable t) {

29. }

30. });

31. }

32. }

Il vous est possible d'utiliser différents services Retrofit au sein de votre application. L'un fournira des requêtes authentifiées, l'autre non par exemple. Vous pouvez aller plus loin bien entendu. Et cela n'impacte en rien votre application, ni vos appels. En effet, lors de l'appel, vous utilisez n'importe lequel pour instancier votre objet Call en fonction de votre besoin.

C'est assez magique ces services Retrofit je trouve.

Pour aller plus loin concernant l'authentification, vous pouvez commencer par ces articles :

- https://futurestud.io/blog/retrofit-token-authentication-on-android ;

- https://futurestud.io/blog/oauth-2-on-android-with-retrofit ;

- https://futurestud.io/blog/retrofit-2-hawk-authentication-on-android.

Vous pouvez aussi jeter un œil à cette librairie dédiée justement à la mise en place d'OAuth avec Retrofit : https://github.com/AliAbozaid/OAuth2Library.

IV-E - Mise en place des convertisseurs pour Retrofit

Les convertisseurs servent à convertir vos objets Java dans le format qui va bien pour leur transport (Xml, Buffer, Json) dans un sens (Request) et l'autre (Response).

Vous devez les ajouter à votre gradle.build, ils ne font pas partie de la bibliothèque Retrofit.

IV-E-1 - Convertisseur natif

Il est préconisé d'utiliser Moshi comme convertisseur par défaut pour le format JSON car il utilise de manière native les Sink et les Source d'Okio sur lequel se base OkHttp. Il n'y a donc pas de recopie de Buffer, pas d'instanciation d'InputStream ou ce genre de gaspillage mémoire.

Pour dire à votre service Retrofit d'utiliser un convertisseur, il suffit de le déclarer lors de la construction de l'objet Retrofit :

1. public static WebServerIntf getSimpleClient(){

2. //Using Default HttpClient

3. Retrofit ra=new Retrofit.Builder()

4. //you need to add your root url

5. .baseUrl(BASE_URL)

6. //You need to add a converter if you want your Json to be automagicly

7. //convert into the object

8. .addConverterFactory(MoshiConverterFactory.create())

9. .build();

10. WebServerIntf webServer=ra.create(WebServerIntf.class);

11. return webServer;

12. }

Si vous ajoutez plusieurs convertisseurs, l'ordre de déclaration est important. Les convertisseurs sont interrogés un à un pour savoir s'ils doivent faire le boulot. Le premier qui dit oui l'effectuera. C'est basé sur le Design Pattern de la chaîne de responsabilité.

Vous avez un ensemble de convertisseurs natifs, disponibles et compatibles avec Retrofit :

Ci-dessous, vous avez la liste du moteur utilisé et de la dépendance gradle à ajouter à votre fichier gradle.build :

- Gson : com.squareup.retrofit:converter-gson ;

- Jackson : com.squareup.retrofit:converter-jackson ;

- Moshi : com.squareup.retrofit:converter-moshi ;

- Protobuf : com.squareup.retrofit:converter-protobuf ;

- Wire : com.squareup.retrofit:converter-wire ;

- Simple XML : com.squareup.retrofit:converter-simplexml.

IV-E-2 - Pourquoi utiliser Moshi comme convertisseur ?

Comme je vous le disais, Moshi est le convertisseur à utiliser par défaut si l'on manipule du JSON et la principale raison est l'allocation mémoire. En effet Moshi est le seul qui soit parfaitement compatible avec Okio, ce qui permet une utilisation des Sink et des Source natifs et évite une allocation mémoire pour les convertir en InputStream et ce à plusieurs niveaux.

Examinons un Call et commençons par la requête.

Dans ce schéma, la flèche rouge porte l'objet, la bleue porte le BufferSink dans lequel sont écrites les données.

Ce qui est important ici de bien comprendre, c'est que les interfaces entre les bibliothèques utilisées par Retrofit (Moshi et OkHttp) sont basées sur Okio. Ainsi les objets ne sont pas recopiés pour les passer entre ces librairies, elles utilisent naturellement le BufferSink créé par Moshi pour convertir cet objet. L'objet RequestBody ne fait qu'encapsuler le BufferSink et le ré-utilise. Il sera « consommé » lors de l'écriture réelle de l'information dans le Socket.

La réponse suit le même paradigme.

Il est important de comprendre la compatibilité profonde de ces librairies et l'économie de recopie des données qu'elle génère.

Ainsi, si vous travaillez avec du JSON, il est fortement recommandé d'utiliser Moshi (et aussi de compresser son flux avec un Adapter comme vu précédemment).

IV-E-3 - Convertisseur spécifique (custom converter)

Il est possible (et presque facile) d'ajouter son propre convertisseur à Retrofit. Pour cela, il vous faut l'ajouter à l'objet Retrofit lors de sa construction (comme précédemment) et le définir.

Définir un convertisseur Retrofit nécessite trois classes : une factory, un convertisseur pour la requête et un convertisseur pour la réponse. Vous pouvez en fonction de votre besoin ne mettre que le convertisseur pour la réponse ou la requête.

Nous allons examiner un exemple pour comprendre ce principe basé sur la conversion d'un objet Photo qui possède comme attributs principaux un identifiant, un titre et une URL.

Le principe est le suivant : la Factory reçoit un objet et regarde si elle doit le convertir et quel type de conversion doit être effectué (réponse → objet ou objet → requête). Si elle n'a pas à convertir l'objet, elle renvoie null, si elle doit le convertir, elle regarde le sens de conversion et renvoie le bon convertisseur.

La première étape est donc d'ajouter ce convertisseur (plus exactement la Factory) à l'objet Retrofit :

1. public class RetrofitBuilder {

3. // Using my HttpClient

4. Retrofit raCustom = new Retrofit.Builder()

5. .client(client)

6. .baseUrl(BASE_URL)

8. // Add your own converter first (declaration order matters)

9. // The responsability chain design pattern is behind

10. .addConverterFactory(new MyPhotoConverterFactory())

11. // You need to add a converter if you want your Json to be automagicly

12. // convert into the object

13. .addConverterFactory(MoshiConverterFactory.create())

14. // Then add your own CallAdapter

15. .addCallAdapterFactory(new ErrorHandlingCallAdapterFactory())

16. .build();

17. WebServerIntf webServer = raCustom.create(WebServerIntf.class);

18. return webServer;

19. }

Il faut ensuite définir la Factory :

1. public class MyPhotoConverterFactory extends Converter.Factory {

3. public static MyPhotoConverterFactory create(){

4. return new MyPhotoConverterFactory();

5. }

7. @Override

8. public Converter<?, RequestBody> requestBodyConverter(Type type, Annotation[]

9. annotations, Retrofit retrofit) {

10. //If it's a Photo instance then convert

11. if(type==Photo.class){

12. return MyPhotoRequestConverter.INSTANCE;

13. }

14. //else use the Chain of responsability pattern and return null

15. //the api will look at the next converter

16. return null;

17. }

19. @Override

20. public Converter<ResponseBody, ?> responseBodyConverter(Type type, Annotation[]

21. annotations, Retrofit retrofit) {

22. //If it's a Photo instance then convert

23. if(type==Photo.class){

24. return MyPhotoResponseConverter.INSTANCE;

25. }

26. //else use the Chain of responsability pattern and return null

27. //the api will look at the next converter

28. return null;

29. }

30. }

Elle étend la classe ConvertFactory et possède :

- une méthode create qui renvoie une instance d'elle-même ;

- une méthode requestBodyConverter qui renvoie le convertisseur « objet vers requête » si c'est le type d'objet qu'elle prend en charge et null sinon ;

- une méthode responseBodyConverter qui renvoie le convertisseur « réponse vers objet » si c'est le type d'objet qu'elle prend en charge et null sinon.

Il ne nous reste plus qu'à définir nos convertisseurs.

Le convertisseur « objet vers requête » :

1. public class MyPhotoRequestConverter<T> implements Converter<T, RequestBody> {

2. // Instance of the converter

3. static final MyPhotoRequestConverter<Photo> INSTANCE = new MyPhotoRequestConverter<>();

5. // MIME type of the request

6. private static final MediaType MEDIA_TYPE = MediaType.parse("application/json; charset=utf-8");

8. private Photo photo;

10. // Default PRIVATE empty constructor

11. private MyPhotoRequestConverter() {

12. }

14. // The real conversion from the Photo to it's json representation

15. @Override

16. public RequestBody convert(T value) throws IOException {

17. // Ensure the right object is passed to you

18. if (value instanceof Photo) {

19. photo = (Photo) value;

20. return new RequestBody() {

21. @Override

22. public MediaType contentType() {return MEDIA_TYPE;}

23. @Override

24. public void writeTo(BufferedSink sink) throws IOException {

25. writeRequest(sink); }

26. };

27. } else {throw new IllegalArgumentException();}

28. }

30. private void writeRequest(BufferedSink sink) throws IOException {

31. //do the Moshi stuff:

32. JsonWriter jsonW = JsonWriter.of(sink);

33. jsonW.setIndent("    ");

34. writeJson(jsonW);

35. // You have to close the JsonWrtiter too (otherwise nothing will happen)

36. jsonW.close();

37. // Don't forget to close, otherwise nothing appears

38. sink.close();

39. }

41. private void writeJson(JsonWriter jsonW) throws IOException {

42. jsonW.beginObject();

43. jsonW.name("albumId").value(photo.getAlbumId());

44. jsonW.name("id").value(photo.getId());

45. jsonW.name("title").value(photo.getTitle());

46. jsonW.name("url").value(photo.getUrl());

47. jsonW.name("thumbnailUrl").value(photo.getThumbnailUrl());

48. jsonW.endObject();

49. }

50. }

51. }

Cette classe étend Converter<T,RequestBody>, où T est le paramètre de généricité et n'est autre que votre objet. Laissez T et ne mettez pas votre type d'objet ou remplacez T par votre type réel, les deux marchent bien.

Il vous faut implémenter la méthode convert(T) qui renvoie une RequestBody. Pour cela, rien de plus simple, vous renvoyez un nouvel objet RequestBody dont vous surchargez les méthodes :

- contentType pour renvoyer le bon type MIME de votre requête ;

- writeTo pour écrire le contenu de votre requête.

Dans l'exemple, j'utilise Moshi pour écrire à la main le contenu de mon flux JSON dans la requête au moyen des méthodes writeRequest et writeJson. Il n'y a rien de transcendant, c'est pour l'exemple, je ne pense pas que vous ayez à traiter un exemple aussi trivial dans la vraie vie.

Le convertisseur de la réponse vers l'objet est tout aussi simple à mettre en place :

1. public class MyPhotoResponseConverter implements Converter<ResponseBody, Photo> {

2. //define an instance to retrieve the converter only once

3. static final MyPhotoResponseConverter INSTANCE = new  MyPhotoResponseConverter();

5. //default empty constructor

6. private MyPhotoResponseConverter() {

7. }

9. //The real conversion from the server response to the Photo object

10. @Override

11. public Photo convert(ResponseBody value) throws IOException {

12. return readJson(value.source());

13. }

14. //Read the source, build the object and return it

15. public Photo readJson(BufferedSource source) throws IOException {

16. if(source==null){throw new IOException();}

17. Photo photo =new Photo();

18. //Then read the JSon File

19. JsonReader reader = JsonReader.of(source);

20. reader.beginObject();

21. while (reader.hasNext()) {

22. switch (reader.nextName()) {

23. case "albumId":

24. photo.setAlbumId(reader.nextInt()); break;

25. case "id":

26. photo.setId(reader.nextInt()); break;

27. case "title":

28. photo.setTitle(reader.nextString()); break;

29. case "url":

30. photo.setUrl(reader.nextString()); break;

31. case "thumbnailUrl":

32. photo.setThumbnailUrl(reader.nextString()); break;

33. default:break;

34. }

35. }

36. reader.endObject();

37. reader.close();

38. source.close();

39. return photo;

40. }}

Cette classe étend Converter<T,RequestBody> où T est le paramètre de généricité. Dans l'exemple, j'ai changé T pour lui donner son vrai type Photo et vous montrer que cela marche aussi.

Il vous suffit alors d'implémenter la méthode convert(ResponseBody value) qui renvoie un objet de type T (ou ici du type réel Photo). J'appelle simplement la méthode readJson pour reconstruire l'objet Photo encapsulé dans le JSON et le renvoyer.

IV-F - Call et CallAdapter personalisé

L'objet Call encapsule votre appel réseau et la réponse obtenue. Retrofit vous permet de substituer l'objet Call avec les Observable de RxJava ou de Future de manière aisée. Mais gardez en tête qu'il est conçu pour les objets Call.

Comme nous l'avons vu, vous pouvez effectuer sur un objet Call soit un appel synchrone (méthode execute) soit un appel asynchrone simplement (méthode enqueue). La méthode execute vous renvoie directement l'objet, alors que vous fournissez un CallBack à la méthode enqueue pour réceptionner le retour.

Pour rappel, je définis mon interface d'appels comme cela :

1. public interface WebServerIntf {

2. @GET("posts/1")

3. Call<Post> getPostOne();

4. }

Et je l'utilise (de manière asynchrone) comme cela :

1. public class BusinessService {

2. // Synchronous

3. Post post=getPostByIdCall.execute();

5. // Asynchronous

6. Call<Post> getPostOneCall = webService.getPostOne();

8. // So you need to make an async call

9. getPostOneCall.enqueue(new Callback<Post>() {

10. @Override

11. public void onResponse(Response<Post> response) {

12. }

13. @Override

14. public void onFailure(Throwable t) {

15. }

16. });

17. }

Dans cet article, je ne vous parlerai pas des Observables (RxAndroid) et de Retrofit, c'est simple à mettre en place et pensé pour, mais là je vais rester concentré sur Retrofit.

Si vous souhaitez creuser le sujet, Jake Wharton a fait un projet d'exemple pour leur mise en place : https://github.com/JakeWharton/u2020

IV-F-1 - CallAdapter personalisé : exemple d'un ErrorHandler

Vous pouvez ajouter vos propres CallAdapter (utile pour la mise en place d'ErrorHandler ou autre en fonction de vos besoins). C'est ultra utile mais un peu fin à mettre en place…

L'objectif d'un CallAdapter personnalisé est de mettre en place un traitement plus sophistiqué que celui fourni nativement par Call et son CallBack qui ne possède que deux méthodes (onResponse et onFailure). Il peut y avoir de multiples besoins pour la mise en place d'un tel Design Pattern. L'un des plus fréquents est la gestion des erreurs réseau mais vous pouvez avoir d'autres besoins tout aussi valables.

Ainsi, pour comprendre la mise en place d'un CallAdapter personnalisé, nous allons mettre en place un ErrorHandlerCall basé sur ce principe. Nous souhaitons pouvoir automatiquement traiter les erreurs serveurs (404 et autres) qui ne sont pas une Failure de communication et reviennent ainsi dans la méthode onResponse si l'on ne fait rien.

L'objectif ici est d'avoir une classe Call qui nous permet de gérer ses types de retours plus finement ; ainsi nous voudrions pouvoir remplacer Call et son CallBack par un Call plus fin sur la gestion des erreurs. Nous voudrions un CallBack de ce type :

1. public interface ErrorHandlingCallBack<T>{

2. /** Called for [200, 300) responses. */

3. void success(Response<T> response);

4. /** Called for 401 responses. */

5. void unauthenticated(Response<?> response);

6. /** Called for [400, 500) responses, except 401. */

7. void clientError(Response<?> response);

8. /** Called for [500, 600) response. */

9. void serverError(Response<?> response);

10. /** Called for network errors while making the call. */

11. void networkError(IOException e);

12. /** Called for unexpected errors while making the call. */

13. void unexpectedError(Throwable t);

14. }

Nous pourrons ainsi avoir une gestion plus fine du retour serveur et des erreurs associées. L'idée de mettre en place un CallAdapter personnalisé est simple.

Nous allons mettre en place un Design pattern où :

- ErrorHandlingCallFactory : instancie l'objet ErrorHandlingCall si c'est le bon type de requête ;

- ErrorHandlingCallIntf : déclare les méthodes du Call que vous êtes en train de créer (faire attention à ce qu'elles ressemblent à celles de la classe Call pour ne pas perturber l'utilisateur) ;

- ErrorHandlingCall : implémente l'interface ErrorHandlingCallIntf et met en place toutes les méthodes utiles aux appels associées à la classe Call (cancel, execute, enqueue, clone…) ;

- ErrorHandlingCallBackIntf : déclare les méthodes associées aux traitements voulus ;

- ErrorHandlingCallBack : effectue le traitement voulu (ici le traitement des erreurs).

Comme je vous le disais, la mise en place d'un CallAdapter n'est pas triviale mais ça se fait. Nous allons examiner chaque classe pour mieux comprendre son comportement et ses responsabilités. Mais tout d'abord, commençons par la déclaration de notre CallAdpater.

Nous le définissions comme d'habitude, la méthode dans l'interface d'appels mais cette fois ci en précisant bien que le type de retour est un ErrorHandlingCall (notre Call):

1. public interface WebServerIntf {

2. @GET("posts/trois")

3. ErrorHandlingCall<Post> getPostOneWithError();

Pour l'instanciation, il nous faut prévenir le client Retrofit que nous avons ajouté un nouveau CallAdapter à la chaîne des adaptateurs lors de l'instanciation de celui-ci :

1. public class RetrofitBuilder {

2. // Now it's using the cach

3. // Using my HttpClient

4. Retrofit raCustom = new Retrofit.Builder()

5. .client(client)

6. .baseUrl(BASE_URL)

7. // add your own converter first (declaration order matters)

8. // the responsability chain design pattern is behind

9. .addConverterFactory(new MyPhotoConverterFactory())

10. // You need to add a converter if you want your Json

11. .addConverterFactory(MoshiConverterFactory.create())

12. // then add your own CallAdapter

13. .addCallAdapterFactory(new ErrorHandlingCallAdapterFactory())

14. .build();

15. WebServerIntf webServer = raCustom.create(WebServerIntf.class);

16. return webServer;

17. }

Ensuite, regardons le code de la Factory qui décide si elle doit renvoyer notre ErrorHandlingCall ou pas en fonction du type de retour attendu par l'appel :

1. public class ErrorHandlingCallAdapterFactory implements Factory{

2. @Override

3. public CallAdapter<?> get(Type returnType, Annotation[] annotations, Retrofit retrofit) {

4. //tricky stuff, not proud of, but works really

5. if(!returnType.toString().contains("ErrorHandlingCall")){

6. //This is not handled by you, so return null

7. //and enjoy the responsability chain design pattern

8. return null;

9. }

10. //this case is yours, do your job:

11. return new CallAdapter<ErrorHandlingCall<?>>() {

12. @Override public Type responseType() {

13. return responseType;

14. }

16. @Override public <R> ErrorHandlingCall<R> adapt(Call<R> call) {

17. return new ErrorHandlingCall<>(call);

18. }

19. };

20. }

22. }

La seule chose importante de cette classe est la méthode get qui doit renvoyer null si le type de retour attendu n'est pas votre ErrorHandingCall. Si le type de retour attendu est ErrorHandlingCall alors vous devez le renvoyer en surchargeant ses méthodes :

- responseType pour renvoyer votre responseType (on vous l'a passé en paramètre) ;

- adapt qui est la méthode clef ; elle vous permet de passer à votre ErrorHandlingCall le Call réel qui effectue l'appel réseau. En effet, sans lui, vous ne pourriez pas rerouter vos méthodes vers l'objet Call sous-jacent pour qu'il fasse réellement le boulot.

Maintenant, nous allons définir les traitements que nous souhaitons mettre en place pour notre propre Call, c'est-à-dire définir le CallBack que nous fournissons aux utilisateurs de l'ErrorHandlingCall.

Pour cela, nous les définissons dans une interface, laissant son instanciation à l'utilisateur final :

1. public interface ErrorHandlingCallBack<T>{

2. /** Called for [200, 300) responses. */

3. void success(Response<T> response);

4. /** Called for 401 responses. */

5. void unauthenticated(Response<?> response);

6. /** Called for [400, 500) responses, except 401. */

7. void clientError(Response<?> response);

8. /** Called for [500, 600) response. */

9. void serverError(Response<?> response);

10. /** Called for network errors while making the call. */

11. void networkError(IOException e);

12. /** Called for unexpected errors while making the call. */

13. void unexpectedError(Throwable t);

14. }

Maintenant, il nous faut définir les méthodes de votre objet ErrorCallHandler ; pour cela je préfère les définir dans une interface et les instancier dans une classe concrète.

La définition des méthodes dans l'interface a pour objectif de mettre en place l'ensemble des méthodes de la classe Call que vous aurez adapté à vos besoins. En effet, il vous faut répondre aux méthodes naturelles de celle-ci (cancel, enqueue, execute…). Les déclarer dans une interface vous permet d'avoir du recul sur votre code et de bien définir les responsabilités de votre classe Call :

1. public interface ErrorHandlingCallIntf<T> {

2. /**

3. * Mandatory

4. * To be called before execute or enqueue

5. *

6. * @param callBack

7. */

8. void initializeCallBack(ErrorHandlingCallBack callBack);

10. /**

11. * Synchronously send the request and return its response.

12. *

13. * @throws IOException      if a problem occurred talking to the server.

14. * @throws RuntimeException (and subclasses) if an unexpected error occurs

15. * creating the request or decoding the response.

16. */

17. Response<T> execute() throws IOException;

19. /**

20. * Asynchronously send the request and notify {@code callback} of its response

21. * or if an error occurred talking to the server, creating the request,

22. * or processing the response.

23. */

24. void enqueue();

26. /**

27. * Returns true if this call has been either {@linkplain #execute() executed} or {@linkplain

28. * #enqueue() enqueued}. It is an error to execute or enqueue a call more than once.

29. */

30. boolean isExecuted();

32. /**

33. * Cancel this call. An attempt will be made to cancel in-flight calls, and if the call has not

34. * yet been executed it never will be.

35. */

36. void cancel();

39. /**

40. * True if {@link #cancel()} was called.

41. */

42. boolean isCanceled();

44. /**

45. * Create a new, identical call to this one which can be enqueued or executed even

46. *  if this call has already been.

47. */

48. ErrorHandlingCallIntf<T> clone();

49. }

L'instanciation de cette interface par la classe ErrorHandlingCall est basée sur le Design Pattern du Decorator. ErrorHandlingCall va contenir un objet Call et rerouter les appels vers lui puis effectuer son propre traitement.

1. public class ErrorHandlingCall<T> implements ErrorHandlingCallIntf<T> {

2. /**

3. * The real call beyond the this call

4. */

5. private final Call<T> call;

7. /**

8. * The call back to use to give more granularity to the error handling to the client

9. */

10. private ErrorHandlingCallBack<T> errorHandlingCallBack;

12. /***********************************************************

13. * Constructor

14. **********************************************************/

15. /**

16. * Used by the ErrorHandlingCallAdapterFactory

17. *

18. * @param call

19. */

20. ErrorHandlingCall(Call<T> call) {

21. this.call = call;

22. }

24. /**

25. * Used by clone

26. *

27. * @param errorHandlingCallBack

28. * @param call

29. */

30. private ErrorHandlingCall(ErrorHandlingCallBack<T> errorHandlingCallBack,

31. Call<T> call) {

32. this.errorHandlingCallBack = errorHandlingCallBack;

33. this.call = call.clone();

34. }

36. /**

37. * Mandatory

38. * To be called before execute or enqueue

39. *

40. * @param callBack

41. */

42. @Override

43. public void initializeCallBack(ErrorHandlingCallBack callBack) {

44. errorHandlingCallBack = callBack;

45. }

47. /***********************************************************

48. *   implements interface Call<T>

49. **********************************************************/

51. /**

52. * Synchronously send the request and return its response.

53. *

54. * @throws IOException      if a problem occurred talking to the server.

55. * @throws RuntimeException (and subclasses) if an unexpected error occurs

56. * creating the request or decoding the response.

57. */

58. @Override

59. public Response<T> execute() throws IOException {

60. if (errorHandlingCallBack == null) {

61. throw new IllegalStateException("You have to call  initializeCallBack(ErrorHandlingCallBack callBack) before execute");

62. }

63. //then analyse the response and do your expected work

64. Response<T> response = call.execute();

65. int code = response.code();

66. if (code >= 200 && code < 300) {

67. //it's ok

68. return response;

69. }

70. //It's not ok anymore, return the response but make the errorCallBack

71. else if (code == 401) {

72. errorHandlingCallBack.unauthenticated(response);

73. } else if (code >= 400 && code < 500) {

74. errorHandlingCallBack.clientError(response);

75. } else if (code >= 500 && code < 600) {

76. errorHandlingCallBack.serverError(response);

77. } else {

78. errorHandlingCallBack.unexpectedError(new RuntimeException(

79. "Unexpected response " + response));

80. }

81. return response;

83. }

85. /**

86. * Asynchronously send the request and notify {@code callback} of its response

87. * or if an error occurred talking to the server, creating the request,

88. * or processing the response.

89. */

90. @Override

91. public void enqueue() {

92. if (errorHandlingCallBack == null) {

93. throw new IllegalStateException("You have to call initializeCallBack(ErrorHandlingCallBack callBack) before enqueue");

94. }

95. //do the job with the real call object

96. call.enqueue(new Callback<T>() {

97. /**

98. * Invoked for a received HTTP response.

99. * <p/>

100. * Note: An HTTP response may still indicate an application-level failure

101. * such as a 404 or 500.

102. * Call {@link Response#isSuccess()} to determine if the response indicates success.

103. *

104. * @param response

105. */

106. @Override

107. public void onResponse(Response<T> response) {

108. int code = response.code();

109. if (code >= 200 && code < 300) {

110. errorHandlingCallBack.success(response);

111. } else if (code == 401) {

112. errorHandlingCallBack.unauthenticated(response);

113. } else if (code >= 400 && code < 500) {

114. errorHandlingCallBack.clientError(response);

115. } else if (code >= 500 && code < 600) {

116. errorHandlingCallBack.serverError(response);

117. } else {

118. errorHandlingCallBack.unexpectedError(new RuntimeException("Unexpected response " + response));

119. }

120. }

122. /**

123. * Invoked when a network exception occurred talking to the server or

124. * when an unexpected exception occurred creating the request

125. * or processing the response.

126. *

127. * @param t

128. */

129. @Override

130. public void onFailure(Throwable t) {

131. if (t instanceof IOException) {

132. errorHandlingCallBack.networkError((IOException) t);

133. } else {

134. errorHandlingCallBack.unexpectedError(t);

135. }

136. }

137. });

138. }

140. /**

141. * Returns true if this call has been either {@linkplain #execute() executed} or {@linkplain

142. * #enqueue() enqueued}. It is an error to execute or enqueue a call more than once.

143. */

144. @Override

145. public boolean isExecuted() {

146. return call.isExecuted();

147. }

149. /**

150. * Cancel this call. An attempt will be made to cancel in-flight calls, and if the call has not

151. * yet been executed it never will be.

152. */

153. @Override

154. public void cancel() {

155. call.cancel();

156. }

158. /**

159. * True if {@link #cancel()} was called.

160. */

161. @Override

162. public boolean isCanceled() {

163. return call.isCanceled();

164. }

166. /**

167. * Create a new, identical call to this one which can be enqueued or executed even if this all has already been.

168. */

169. @Override

170. public ErrorHandlingCallIntf<T> clone() {

171. if (errorHandlingCallBack == null) {

172. throw new IllegalStateException("You have to call initializeCallBack(ErrorHandlingCallBack callBack) before clone()");

173. }

174. return new ErrorHandlingCall<>(errorHandlingCallBack, call);

175. }

176. }

Les points clefs de cette classe sont :

- le constructeur prend en paramètre l'objet Call sur lequel seront reroutées la plupart des méthodes ;

- la méthode enqueue utilise Call pour faire l'appel et effectue un post-traitement de la réponse pour rerouter vers son propre CallBack, l'ErrorHadlingCallBack ;

- la méthode execute effectue la même chose, appel puis post-traitement ;

- les autres méthodes ne font que se rerouter vers l'objet call.

Enfin il ne nous reste plus qu'à utiliser notre ErrorHandlingCall.

1. public class BusinessService {

2. // The call that handles errors

3. ErrorHandlingCall<Post> getPostOneWithErrorCall;

5. // The callBack that manages the errors when they appear

6. ErrorHandlingCallBack errorHandlingCallBack=null;

8. // Load a stuff with an errorHandlingCall

9. public void loadWithErrorHandlingCall(){

10. // First initialize your error handling callback

11. if(errorHandlingCallBack==null){

12. errorHandlingCallBack= instanciateErrorHandlingCallBack();

13. }

14. // Then instanciate

15. getPostOneWithErrorCall=webServiceComplex.getPostOneWithError();

16. // Initialize your errorCallBack

17. getPostOneWithErrorCall.initializeCallBack(errorHandlingCallBack);

18. // Make your call

19. getPostOneWithErrorCall.enqueue();

20. }

21. }

Vous avez remarqué que la méthode enqueue ne prend pas en paramètre le CallBack, en effet ce sont les méthodes de notre ErrorHandlingCall qui sont appelées et non pas celles de la classe Call. Il ne reste plus qu'à voir l'instanciation de notre CallBack, l'ErrorHandlingCallBack (toujours dans la même classe) :

1. private ErrorHandlingCallBack instanciateErrorHandlingCallBack(){

2. return new ErrorHandlingCallBack() {

3. @Override

4. public void success(Response response) {

5. Log.e("BusinessService", "Reponse is Success" + response.body());

6. }

8. @Override

9. public void unauthenticated(Response response) {

10. Log.e("BusinessService", "UNAUTHENTICATED !!!");

12. }

14. @Override

15. public void clientError(Response response) {

16. Log.e("BusinessService", "CLIENT ERROR " + response.code());

17. }

19. @Override

20. public void serverError(Response response) {

21. Log.e("BusinessService", "Server ERROR " + response.code());

22. }

24. @Override

25. public void networkError(IOException e) {

26. Log.e("BusinessService", "IOException ", e);

27. }

29. @Override

30. public void unexpectedError(Throwable t) {

31. Log.e("BusinessService", "Death Metal Error without roses ", t);

32. }

33. };

34. }

IV-G - Retrofit : mise en place du Logging

A priori on se dit, quand on souhaite mettre en place un système de logging, qu'il nous faut mettre un CallAdapter spécialisé. Le problème est, comme nous l'avons vu, que le CallAdapter n'accède qu'à l'objet Call et cet objet ne permet pas d'accéder aux requêtes sous-jacentes. En fait, il va falloir avoir une compréhension plus fine de Retrofit. En effet, la meilleure place pour faire du logging de nos requêtes et des réponses obtenues n'est pas la couche Retrofit mais la couche HTTP sous-jacente.

Pour faire cela, vous pouvez soit utiliser le logger natif conçu pour Retrofit : HttpLoggingInterceptor, soit faire votre propre logger.

IV-G-1 - Logger natif

Pour utiliser le logger natif, il vous faut rajouter sa librairie à votre gradle.build :

1. dependencies {

2. compile fileTree(dir: 'libs', include: ['*.jar'])

3. compile 'com.android.support:appcompat-v7:22.2.0'

4. //compile 'com.squareup.okhttp3:okhttp:3.0.1'<-a bug here

5. compile 'com.squareup.retrofit2:retrofit:2.0.0-beta3'

6. compile 'com.squareup.okhttp3:okhttp:3.0.0-RC1'

7. compile 'com.squareup.retrofit2:converter-moshi:2.0.0-beta3'

8. compile 'com.squareup.okhttp3:logging-interceptor:3.0.0-RC1'

9. }

Puis l'utiliser lors de l'instanciation de votre OkHttpClient :

1. public class RetrofitBuilder {

2. @NonNull

3. public static OkHttpClient getOkHttpClient(Context ctx) {

4. // Define the OkHttp Client with its cach!

5. // Assigning a CacheDirectory

6. File myCacheDir = new File(ctx.getCacheDir(), "OkHttpCache");

7. // You should create it...

8. int cacheSize = 1024 * 1024;

9. Cache cacheDir = new Cache(myCacheDir, cacheSize);

10. HttpLoggingInterceptor httpLogInterceptor = new HttpLoggingInterceptor();

11. httpLogInterceptor.setLevel(HttpLoggingInterceptor.Level.BASIC);

12. return new OkHttpClient.Builder()

13. //add a cach

14. .cache(cacheDir)

15. // Add interceptor (here to log the request)

16. .addInterceptor(httpLogInterceptor)

17. .build();

18. }

19. }

Vous pouvez lors de son instanciation définir son niveau de log.

IV-G-2 - Logger spécialisé

Dans ce cas, il suffit de créer son propre Interceptor et de logger les requêtes qui passent à travers lui :

1. public class CustomLoggingInterceptor implements Interceptor{

2. //Code pasted from okHttp webSite itself

3. @Override public Response intercept(Interceptor.Chain chain) throws IOException {

4. Request request = chain.request();

5. long t1 = System.nanoTime();

6. Log.e("Interceptor Sample", String.format("Sending request %s on %s  %s.",

7. request.url(), chain.connection(), request.headers().toString()));

9. Response response = chain.proceed(request);

11. long t2 = System.nanoTime();

12. Log.e("Interceptor Sample", String.format("Received response for %s in %.1fms%n%s",

13. response.request().url(), (t2 - t1) / 1e6d, response.headers()));

14. return response;

15. }

16. }

Une fois que vous l'avez défini, il ne vous reste plus qu'à le rajouter à votre client HTTP :

1. public class RetrofitBuilder {

2. @NonNull

3. public static OkHttpClient getOkHttpClient(Context ctx) {

4. // Define the OkHttp Client with its cach!

5. // Assigning a CacheDirectory

6. File myCacheDir = new File(ctx.getCacheDir(), "OkHttpCache");

7. // You should create it...

8. int cacheSize = 1024 * 1024;

9. Cache cacheDir = new Cache(myCacheDir, cacheSize);

10. Interceptor customLoggingInterceptor = new CustomLoggingInterceptor();

11. return new OkHttpClient.Builder()

12. // Add a cach

13. .cache(cacheDir)

14. // Add interceptor (here to log the request)

15. .addInterceptor(customLoggingInterceptor)

16. .build();

17. }

18. }

Et voilà.

IV-H - Un conseil sur les URLs

Une bonne pratique consiste à toujours terminer vos base url par « / » et dans vos @URL de ne jamais commencer avec.

Pourquoi ? Pour des raisons de résolution dynamique des URL par Retrofit. Ainsi si votre @URL débute par un « / », le système le comprendra comme une URL relative vis-à-vis du root de BASE_URL. S'il ne commence pas par un « / », le système le considèrera comme un chemin absolu à partir de votre BASE_URL.

V - Bibliographie

Les liens suivants ont été pour moi une source de compréhension de Retrofit, Moshi, OkHttp et Okio.

- http://inthecheesefactory.com/blog/retrofit-2.0/en

- https://github.com/square/retrofit/blob/master/samples/src/main/java/com/example/retrofit/ErrorHandlingCallAdapter.java

- https://gist.github.com/rahulgautam/25c72ffcac70dacb87bd#file-errorhandlingexecutorcalladapterfactory-java

- https://speakerdeck.com/jakewharton/simple-http-with-retrofit-2-droidcon-nyc-2015

- http://square.github.io/retrofit/

- https://futurestud.io/blog/retrofit-add-custom-request-header

- https://packetzoom.com/blog/which-android-http-library-to-use.html

Mais clairement, ceux associés aux conférences de Jake Wharton à New York et Montréal en 2015, ont été les liens qui m'ont fait comprendre Retrofit, OkHttp, Moshi et Okio. Cet article utilise énormément ces conférences (les schémas en particulier, le code aussi).

- https://www.youtube.com/watch?v=3WONuRSUHmw

- https://www.youtube.com/watch?v=KIAoQbAu3eA

VI - Conclusion

J'espère que cet article vous a plu, il est extrait d'une formation que j'ai mise en place « Ultimate Android » qui se concentre sur l'architecture Android. Normalement, suite à sa lecture vous devriez avoir pas mal de boulot sur votre application pour mettre à jour votre couche réseau et votre couche IO.

Ainsi, vous devriez :

- remplacer vos écritures et lectures disque par Okio et utiliser des Sink et des Source ;

- compresser tous vos flux (vers votre serveur mais aussi lors de l'écriture sur disque) ;

- utiliser OkHttpClient et ne plus utiliser DefaultHttpClient ;

- utiliser Moshi pour toutes les manipulations JSON de votre application ;

- remplacer votre couche de communication par Retrofit ;

- gérer vos erreurs réseaux via un CallAdapter spécifique ;

- effectuer vos logs de communication via un Intercepteur OkHttpClient.

Je vous remercie de m'avoir lu et je vous dis à une prochaine fois pour un nouvel article sur Android, à bientôt.

VII - Remerciements

Je tiens ici à remercier Winjerome pour la mise au format Developpez.com.

Je tiens aussi à remercier genthial pour ses corrections orthographiques.

Je remercie aussi Android2ee de me fournir le temps de vous écrire ses articles.