android - example - ¿Por qué RxJava se utiliza a menudo con Retrofit?
rxjava example (2)
Para comprender esas ventajas, primero debe entender qué tan beneficioso es para su base de código adoptar Extensiones reactivas.
Composabilidad y transformación.
- Los streams ofrecen una interfaz muy composable. Le permite realizar operaciones de transformación (en la estructura y el tiempo del evento) y, básicamente, interactuar (como hacer dependencias o aprovechar el resultado / error de otro flujo) entre varias corrientes sin problemas. Aunque puede hacer esto con las devoluciones de llamada, si intenta implementar un caso de uso más complicado, que puede ser tan simple como 3 solicitudes, el código perderá su legibilidad muy rápidamente. Por otro lado, Rx te permite implementar escenarios muy complejos y aún así lucir suave.
Roscado y operaciones asíncronas.
- Rx le da un control muy granular sobre qué subprocesos se utilizarán para realizar el trabajo en varios puntos dentro de una secuencia. Para señalar el contraste aquí ya, el enfoque de llamada básica utilizado en Retrofit solo es programar el trabajo en sus subprocesos de trabajo y reenviar el resultado de vuelta al subproceso de llamada. Cuando se declara como una transmisión, la modificación no maneja el subprocesamiento y lo deja solo para usted, lo que le da el control.
Bibliotecas de rx
- Como puede que ya hayas visto, hay innumerables bibliotecas que aprovechan las extensiones reactivas e implementan varias funcionalidades como un flujo. Puede aprovecharlos fácilmente cuando trabaje con sus solicitudes.
Hay otras ventajas además de estas, pero se puede decir que es muy beneficioso volverse reactivo. Las solicitudes son un buen punto de partida para aprender a trabajar con flujos e introducir gradualmente más y más lógica de flujo en su base de código.
No es una sustitución. RxJava y Retrofit son una combinación perfecta, es por eso que, en primer lugar, hay compatibilidad nativa para Retrofit.
¿Cuál es el beneficio de usar Retrofit en combinación con Rxjava?
Pregunta
Retrofit Ya está en ejecución en el hilo de fondo. Entonces, ¿por qué necesita otra tarea de fondo RxJava?
Creo que lo más importante es evitar las devoluciones de llamada anidadas ( callback hell
).
por ejemplo) Callback hell (Retrofit)
public interface MyService
{
@GET("users")
Call<List<UserModel>> getUser();
@GET("userinfo")
Call<UserInfoModel> getUserInfoById(@Query("id") Integer id);
}
service.getUser().enqueue(new Callback<UserModel>() {
@Override
public void onResponse(Call<UserModel> call, Response<UserModel> response) {
//process UserModel
UserModel data = response.body();
//if you want user infomation from server
service.getUserInfo(data.getId()).enqueue(new Callback<UserInfoModel>(){
//... is callback hell!!
});
}
@Override
public void onFailure(Call<UserModel> call, Throwable t) {
//error handling
}
});
por ejemplo) Evite Callback hell (Retrofit + RxJava)
public interface MyService
{
@GET("users")
Observable<List<UserModel>> getUser();
@GET("userinfo")
Observable<UserInfoModel> getUserInfoById(@Query("id") Integer id);
}
service.getUser()
.flatMapIterable(list -> list)
.flatMap(user -> service.getUserInfoById(user.getId()))
.doOnNext(userinfo -> saveUserInfo(userinfo)).subscribe();
Si está utilizando RxJava
, puede usar Observable
para evitar esta situación.
Adicional
El fragmento de código anterior es solo un ejemplo.
De hecho, RxJava
contiene muchas más características relacionadas con los observe pattern
.
Adicional - Beneficio de la programación dirigida por eventos en Android (RxJava)
La mayoría de Android application
están construidas con el usuario o la interaction
datos. (por ejemplo, actualizaciones de GUI cuando se produce la interacción). Por lo tanto, los vemos como un set of events
y el diseño y la creación de una aplicación basada en esto es muy intuitivo y apropiado para eventos internos y externos.