Magistrala zdarzeń i cykl życia komponentów Android UI

Question

Szukałem idealnej architektury aplikacji na Androida i przeczytałem kilka świetnych blogów na ten temat.

1) http://www.mdswanson.com/blog/2014/04/07/durable-android-rest-clients.html

2) http://birbit.com/a-recipe-for-writing-responsive-rest-clients-on-android/

Oba posty opisać jak wykorzystać autobus zdarzeń dla komunikacji między komponentami Androidem (aktywność fragmenty, serwis).

Jeden, ale bardzo ważny temat nie został uwzględniony. Jak obsługiwać zdarzenia, które zostały opublikowane w komponentach interfejsu użytkownika, gdy zostały wstrzymane.

Na przykład: usługa publikuje wydarzenie po zakończeniu pobierania danych do działania. I w tej chwili aktywność jest wstrzymana. Ponieważ autobus zdarzeń jest wyrejestrowywany w funkcji onPause(), całkowicie tracimy to wydarzenie.

EvenBus z greendao oferuje stickyevents. Ale mogą one spowodować wycieki pamięci, jeśli nie zostaną usunięte.

Otto z kwadratu wprowadza wzór "Producer", który można wykorzystać zamiast lepkich zdarzeń.

Pierwsze rozwiązanie może spowodować wycieki pamięci, jeśli losowe zdarzenie nie zostanie usunięte ręcznie.

Druga wymaga przechowywania danych w dowolnym miejscu do czasu, a metoda producenta zwróci je subskrybentom. To rozwiązanie wydaje się bardziej poprawne, ale wymaga napisania więcej kodu.

Czy ktoś mógłby podzielić się pomysłami, jak rozwiązać ten skrajny przypadek? Wszelkie czyste rozwiązania?

Answer 1

Użyłem również bardzo eleganckiej architektury wykorzystującej EventBus. Jest to doskonałe narzędzie do oddzielania interfejsu użytkownika od warstwy biznesowej i komunikacyjnej, a także zapobieganie wykonywaniu zadań sieciowych lub db przez aktualizowanie interfejsu użytkownika, który został już zniszczony. Mógłbym o tym mówić przez cały dzień, ale skupię się na twoim problemie.

Używanie zdarzeń lepkich w większości przypadków i IMHO jest całkowicie w porządku. Tak, technicznie, jest to przeciek pamięci, ponieważ zdarzenie jest przechowywane w pamięci i nic poza tym, że eventbus go odwołuje ... jeszcze. Ale z definicji lepkie zdarzenia są technicznymi wyciekami pamięci, dopóki właściwie ich nie użyjesz? Więc jeśli uruchomisz swój fragment i użyjesz lepkiego wydarzenia, nagle, to już nie jest przeciek pamięci.

W każdym razie, bez zbyt religijnych, lepkich wydarzeń są całkowicie w porządku, o ile wydarzenie nie zawiera miliona rekordów lub dużych struktur danych, takich jak obrazy. Wtedy twoja teoria wycieku pamięci zaczyna mieć więcej sensu.

Co jednak naprawdę chcesz zrobić, to poprawić wyniki połączenia sieciowego w pamięci podręcznej? Więc ...

Proponuję wdrożenie inteligentnego i trwałego buforowania http. Robospice robi dla ciebie dużo tego po wyjęciu z pudełka. Możesz definiować klucze pamięci podręcznej, lokalizacje plików pamięci podręcznej i limity czasu cache - naprawdę fajne rzeczy. Spowoduje to usunięcie pamięci podręcznej z pamięci (np. Zdarzenia lepkiego) i do pliku znajdującego się dalej w warstwie komunikatów, która jest prawdopodobnie znacznie czystsza.