Android Retrofi 2, las diferencias entre addInterceptor y addNetworkInterceptor para editar las respuestas

He estado intentando poner en práctica un interceptor (OkHttp 3.2 y Retrofit 2) para corregir la respuesta de JSON antes se vuelve como respuesta. El servidor que solicitamos datos devuelve datos diferentes depende del éxito o error y que hace difícil asignar los objetos.

Yo estaba tratando de hacerlo agregando el interceptor a Retrofit como un NetworkInterceptor, sin embargo la cadena devuelta no tenía formato.

@Override public Response intercept(Chain chain) throws IOException { Request request = chain.request(); Response response = chain.proceed(request); try { final String responseString = new String(response.body().bytes() ); LOGD("OkHttp-NET-Interceptor", "Response: " + responseString); String newResponseString = editResponse( responseString ); LOGD("OkHttp-NET-Interceptor", "Response edited: " + newResponseString); return response.newBuilder() .body(ResponseBody.create(response.body().contentType(), newResponseString)) .build(); }catch (Exception ex){ return response; } }

ResponseString tenía una cadena sin ningún formato comprensible.

Después de cambiar al interceptor normal, la cadena tenía formato a que era capaz de convertir a JSONObject.

¿Podría decirme alguien que son las diferencias entre las respuestas ?

Por qué esta línea new String (response.body (). Bytes ()); Volver contenido diferente?

Las diferencias están en los nombres. NetworkInterceptor engancha adentro en el nivel de la red y es un lugar ideal para poner la lógica del retry y cualquier cosa que no confíe en el contenido real de la respuesta.

Si lo que haces depende del contenido de la respuesta (como en tu caso), usar ApplicationInterceptor es más útil, ya que te da la respuesta después de que haya sido procesada por cualquier otra parte móvil que puedas tener, como un deserializador JSON. De lo contrario, tendría que implementar la deserialización de JSON dentro de la NetworkInterceptor que no tiene mucho sentido teniendo en cuenta que está hecho para usted por Retrofit.

Aclaración

Square tienen este útil diagrama en su wiki que muestra donde se encuentra cada tipo de interceptor

Diagrama del interceptor

Por lo tanto, la razón por la que recibe una cadena legible en ApplicationInterceptor es porque Square está intentando desacoplar los propósitos de los dos tipos de interceptor. No creen que deba tomar decisiones dependientes de la aplicación en NetworkInterceptor , por lo que no proporcionan una forma fácil de acceder a la cadena de respuestas. Es posible obtener ahold de, pero como he dicho, no quieren que tomar decisiones que dependen del contenido de la respuesta – más bien, quieren que tome decisiones basadas o el estado de la red, o encabezados, etc

El ApplicationInterceptor es donde quieren que tomes decisiones dependiendo del contenido de la respuesta, por lo que proporcionan métodos más fáciles para acceder al contenido de la respuesta para que puedas tomar decisiones informadas para volver a intentarlo, o al detallar en su wiki, reescribir las respuestas (Que creo que es lo que estás tratando de hacer).