Pamięć danych adaptera MVP

Question

Zajmuję się tworzeniem projektu zgodnego z architekturą MVP. Zwykle, gdy używam recyclerView, mój prezenter kontroluje dane adaptera. Ale teraz muszę zrobić adapter do recyklingu z danymi z pamięci podręcznej (lub czymś podobnym do pamięci podręcznej), rozmiar recyklera nie zależy od rozmiaru pamięci podręcznej, więc robię cache za pomocą HashMap gdzie klucz jest - pozycja recyklera, jeśli jest w nim jakiś przedmiot mapa następnie pokazuje dane, w przeciwnym razie pusty wiersz z czymś w rodzaju "dodaj wydarzenia" btn. I nie mogę sobie przypomnieć, gdzie jest miejsce dla tej pamięci podręcznej w takiej strukturze - Model (Dao lub coś w rodzaju CacheManager) lub w adapterze.

Pomysł pamięci podręcznej jest następujący: Mam pewne typy zdarzeń, które przechowują w bazie danych, każde wydarzenie modyfikujące zmienia je w db - więc pamięć podręczna musi być aktualizowana.

Podstawowe pytania: gdzie zachować tę pamięć podręczną i załadować ją do adaptera, jak mogę ją synchronizować ze zmianami w bazie danych.

P.S. Również próbuję użyć RX, więc jeśli można go rozwiązać - byłoby bardzo interesujące spróbować.

P.P.S Jeśli wzór repozytorium jest sposobem rozwiązania - witamy. Przeczytaj o tym kiedyś.

Answer 1

Twój problem nie brzmi jak jest to związane z RecyclerView.Adapter - i rzeczywiście nie należy próbować go rozwiązać w swoim Adapter: odpowiedzialność adapter ma działać jako most (lub „adapter” ;-)) między danymi a komponentem widoku. Nadanie jej większej odpowiedzialności zamieniłoby ją w coś, co nie jest wymienne z innymi implementacjami Adapter (tego nie chcesz!).

Najprawdopodobniej powinieneś znaleźć czysty sposób na streszczenie utrwalania danych. Pamięć podręczna w pamięci powinna wchodzić w tę abstrakcję. Wspomniałeś o strukturze repozytorium, to byłby dobry wybór IMHO.

Twój architektura powinna z grubsza wyglądać tak:

adapter -> repository -> |-> cache 
         |-> database 

Repozytorium łączy logikę dostępu do danych (DAO) Twój i obsługi pamięci podręcznej (Twój CacheManager). Repozytorium zawsze najpierw sprawdza pamięć podręczną, a następnie pobiera dane z bazy danych. Aktualizuje także pamięć podręczną, jeśli pobierane są dane nieużywane w pamięci podręcznej. Ponadto rejestruje aktualizacje w bazie danych. Gdy baza danych powiadomi o zmianie danych, repozytorium ma szansę zaktualizować pamięć podręczną i/lub przekazać powiadomienie do widoku. Ważną częścią jest to, że interfejs repozytorium ukrywa całą tę logikę; zapewnia tylko dostęp do danych.

Następnie należy znaleźć sposób, aby adapter działał z repozytorium. Sugeruję mechanikę Androida: Loader. W ten sposób otrzymujesz asynchroniczne ładowanie i prawidłową obsługę cyklu życia za darmo. Również ten ładnie oddziela adapter i repozytorium.

Jeśli potrzebujesz inspiracji, jak zastosować wzór repozytorium, zajrzyj do github googlesamples/android-architecture. Model Clean Architecture branch może być dla Ciebie odpowiedni.

Na marginesie: spróbuj znaleźć prawdziwe (niepowtarzalne) klucze danych. Używanie pozycji na liście danych jest zwykle złym pomysłem i w zależności od struktury danych spowoduje dziwne efekty uboczne w widoku.

Answer 2

Myślę, że to temat architektury. Rx jest poza tematem. Na przykład dla repozytorium, Rx jest po prostu sposobem na jego wdrożenie, a przez to rozszerzenie jego pamięci podręcznej.

Repozytorium Google udostępnia przykłady architektury.Jeden z nich zawiera przykład architektury z podstawowym MVP i repozytorium którzy zarządzają cache:

googlesamples/android-architecture/todo-mvp

Innym przykładem w tym samym repozytorium z Rx:

googlesamples/android-architecture/todo-mvp-rxjava

Możemy być widać tutaj, że te dwa przykłady mają ten sam schemat architektury: