Android - efektywna komunikacja z serwerem.

Witam,
Piszę aplikacje, która poviera z serwera JSONA i wyświetla liste linków ktore ktos doda w panelu. Obecnie mam klase Model i ServerConnector. Gdy MainActivity chce wyswietlic liste pytam Model o dane, ten jesli ma zapisabe dane to mu je zwraca, a sam uruchamia metode do pobrania danych w ServerConnectorze, ktory za pomocą OKHTTP asynchronicznie pobiera JSONa i jak pobierze woła callback w Modelu, ktory zapisuje w SharedPrefererences caly JSON i woła callback w MainActivity, ktory wtedy parsuje JSON z Modelu. Czy robie to dobrze? Jak ktos mobilnie dodaje link to dodaje do JSONa element i znowu parsuje. JSON caly czas jest w pamieci jako String. Czy powinienem cos poprawic. Cala komunikacja z serwerem odbywa sie POSTem.

Zamiast OkHttp użyj Retrofita. OkHttp jest dość "niskopoziomowy". Retrofit używa OkHttp pod spodem i pozwala elegancko obsługiwać REST-owe API definiując je całkowicie w interfejsie. W Retroficie możesz użyć callbacków, ale osobiście polecam użycie tam RxJavy ze względu na schludniejszy kod, lepszą obsługę błędów oraz odpowiedzi z serwera i możliwość płynnego łączenia wyniku z innymi obiektami typu Observable. Jeżeli wiesz, że serwer zwróci niewielką ilość danych i dane przechowujesz tylko do odczytu, to SharedPreferences do przechowywania JSON-a jako String będą dobrym rozwiązaniem.

Danych mało nie będzie bo może być to nawet 30, 40 linków, i każdy zawiera id, date, i tytuł. Dodatkowo mogę w apce edytować, dodawać i usówać dane. Obecnie jak takie coś wystąpi to edytuje json, zapisuje jako string i znów parsuje. Na bazach tego nie chciałem robić bo za każdym razem jak użytkownik odświeży to bym musiał resetować baze i od nowa wczytywać albo sprawdzać których jeszcze nie ma i wtedy taki dodawać. Czy jest lepszy sposób.

Nie wiem, jak wygląda Twoja aplikacja od środka, ale jeśli edytujesz dane na urządzeniu, a nie tylko je odczytujesz, to możesz rozważyć użycie bazy danych SQLite. Ewentualnie, jeśli naprawdę nie chcesz używać SQLite, to możesz spróbować alternatywnych rozwiązań typu Paper (https://github.com/pilgr/Paper).