Retrofit 2.0 + RxJava manejo unificado de excepciones de solicitudes de red
El contenido de este artículo se basa en el análisis de RxJava 2.0 y Retrofit 2.1. Consulte Rxjava + Retrofit para conocer varias habilidades que necesita dominar: almacenamiento en caché de Retrofit, procesamiento unificado de la existencia de la red, manejo de excepciones y problemas de devolución de resultados.
La siguiente es una lista específica de dependencias para agregar.
Los siguientes errores son comunes en las solicitudes de red. Podemos notificar al usuario sobre excepciones específicas a través de mensajes emergentes de Toast y cargar la interfaz de usuario correspondiente. Además de esto, la información de excepción específica facilita la resolución de errores en el proyecto.
Entonces la pregunta es, ¿cómo determinamos el tipo de excepción?
Esto comenzará con el formato de los datos devueltos por el servidor.
Normalmente solicitamos dicha devolución.
La convención de datos de devolución del lado del servidor puede tener el formato anterior. Tal vez el significado del código específico sea diferente, que puede comunicarse con el personal del lado del servidor y cambiarse de manera flexible.
No diré mucho sobre la configuración básica de Retrofit. Aquí hay una explicación detallada de cómo encapsular los datos devueltos por el servidor y usar RxJava para manejar mensajes de error.
Encapsular datos de retorno
Para los datos de retorno del servidor anteriores, debemos hacer algunos juicios sobre el código. Si el código no es 200 (suponiendo que 200 significa que la solicitud se realizó correctamente en la red). ), se lanzará una excepción. Por lo tanto, creamos una nueva clase BaseResponse correspondiente a la estructura de datos anterior.
Esta es la clase base para todas las entidades y los datos pueden ser de cualquier tipo.
Luego necesitamos preprocesar el resultado devuelto y crear un nuevo ExceptionHandle. El preprocesamiento no es más que juzgar si los datos devueltos son verdaderos según el método BaseResponse isOk(). Si es verdadero, se realizará el procesamiento normal. De lo contrario, se generará una excepción y ExceptionHandle se procesará más para determinar de qué tipo. de excepción lo es. ¿Qué tipo de excepción es la excepción? Saltemos la lógica anterior y veamos cómo determinar qué tipo de anomalía es.
Determine el tipo de excepción
Consulte el código fuente para obtener más detalles.
Puede devolver una excepción con información específica del tipo de excepción a través de ExceptionHandle.handleException(Throwable e).
Ahora que sabemos cómo saber si se produce una excepción y cómo determinar el tipo de excepción, necesitamos descubrir cómo poner la excepción en un controlador. Lo siguiente que debemos resolver es cómo pasar la excepción al onError (Throwable e) del observador para manejar la excepción.
En el proceso de entrega de excepciones, el primer paso es determinar si los datos devueltos por el servidor son una excepción. Si no es una excepción, los datos se devuelven. es arrojado. Esta vez incluye un proceso de conversión de datos para convertir el objeto BaseResponse en un objeto de tipo de datos, por lo que es necesario utilizar el operador map().
HandleFuc implementa la interfaz Function
Si no hay excepción, no se ingresará al segundo paso. Si ocurre una excepción, debe realizar el segundo paso, que consiste en juzgar la excepción y luego pasar la excepción devuelta por ExceptionHandle.handleException (Throwable e) a onError () para su procesamiento.
La clave es: cuando se lanza una excepción, se debe terminar la llamada al método onNext() y se debe llamar al método onError(). Si no continúa procesando y solo sigue los pasos anteriores, aunque se llamará al método onError(), no se juzgará la excepción y no se cancelará el método onNext().
Entonces, ¿existe una buena manera no solo de cancelar el método onNext(), sino también de realizar un juicio de excepción y llamar al método onError()?
RxJava es poderoso y, naturalmente, tiene una manera de hacer esto, y onErrorResumeNext() puede hacerlo. Para onErrorResumeNext(), simplemente puede entender que cuando ocurre un error, otro Observable reemplazará al Observable actual y continuará enviando datos.
El parámetro pasado en onErrorResumeNext() puede ser una interfaz funcional. De esta manera, podemos generar un Observable en Función, realizar una lógica de juicio de excepción y llamar al método onError().
El proceso de implementación es el siguiente:
Hasta ahora, hemos implementado la lógica de juicio y entrega de excepciones. Esto nos permite extraer información específica del estado de la excepción en el método onError() y manejarla en consecuencia.
El proceso general es: map() realiza la conversión de tipos de datos y detecta excepciones. Si es normal, devuelve datos de tipo datos. Si es anormal, onErrorResumeNext() determinará el tipo de excepción y pasará la excepción.
La operación anterior cerrará la red. Cuando se realiza una solicitud de red, si no hay red, se generará una excepción y luego se detectará una excepción específica y Toast solicitará el tipo de excepción para que el usuario sepa qué salió mal.
Referencia de demostración:/maiduoduo/RetrofitRxJavaException.