[DlaczegoJaTuNieWidzeZadnejFlagi]

hej Mirosławy,

przy implementacji apek Androidowych często korzystacie z RxJava? Jaki ma to wpływ na architekturę aplikacji? Jedyna zmiana to odejście od listenerów na rzecz subskrybowania observerów?
Dzięki za odpowiedź

#android #programowanie #androiddev

[Mithrindil]

@DlaczegoJaTuNieWidzeZadnejFlagi: Rzadko bo inni w projekcie nie chcą się przekonać :( wg mnie to jest szczególnie przydatne przy łańcuchowych operacjach asynchronicznych - typu masz wykonać zapytanie do API które de facto składa się z 3 zapytań, np: Logowanie -> pobranie danych usera -> pobranie postów które user napisał. Wtedy bardzo rośnie czytelność kodu bo nie ma tylu callbacków w callbackach. Znam też osoby które preferują wykorzystanie RxJava do śledzenia zdarzeń kontrolek

[niezielony]

@DlaczegoJaTuNieWidzeZadnejFlagi: Ja używam architektury opartej na MVP i RxJavie właśnie, wygląda ona tak: https://github.com/ribot/android-guidelines/blob/master/architecture_guidelines/android_architecture.md
Ma swoje wady i zalety, ale póki co widzę więcej zalet, więc jeśli Cię zainteresowała to tutaj masz artykuł na jej temat: https://labs.ribot.co.uk/android-application-architecture-8b6e34acda65#.t4otv7qtm

[AndroidKuc]

@DlaczegoJaTuNieWidzeZadnejFlagi:
rxJava zawsze spoko, nawet bez MVP. Tak jak wspomniał @Mithrindil rxJava poprawia czytelność kodu w szaleństwach z wykonywaniem requestów jeden po drugim.
Użycie? ja używam w połączeniu z Retrofitem(REST), synchronizacja, inne "ciężkie rzeczy"(np Bluetooth), które puszczone w głównym wątku mogą ci przycinać apkę(dostajesz wtedy logi typu "Skipped 2137 Frames!").

Zamiast używać Threadów czy AsyncTasków można stworzyć własne rx.Observable i robić robote w callbackach, masz większą kontrolę nad tym czy coś

[PieceOfShit]

@AndroidKuc: liczba klatek jest przypadkowa ;D