Zarządzanie danymi aplikacji mobilnych

Question

Moje pytanie dotyczy jednego punktu - Zarządzanie danymi w aplikacji mobilnej. Stworzyłem aplikację mobilną, w której dane pochodzą z serwera. Dane obejmują zarówno tekst, jak i obrazy. Poniżej przedstawiono kroki robie tego:

Pierwsze uruchomienie:
1. Data Server dostać.
2. Zapisz dane serwera w bazie danych Sqlite.
3. Pokaż dane Sqlite.

Następne uruchomienia:
1. Pokaż dane Sqlite.
2. Pobierz dane serwera w tle.
3. Usuń poprzednie dane Sqlite.
4. Zapisz nowe dane serwera w bazie danych Sqlite.
5. Pokaż dane Sqlite.

Mam kilka pytań na temat tych kroków:
1. Jest to właściwe podejście? Innym sposobem może być pokazywanie danych za każdym razem z serwera, ale to nie wyświetlałoby danych bezpośrednio na ekranie (w zależności od szybkości Internetu).
2. Pomyślałem również o porównaniu danych Sqlite z nowymi danymi serwera. Ale stanął przed wielkim wyzwaniem. Nowe dane serwera mogą mieć nowe rekordy lub usunięte rekordy. Ponadto nie mogłem znaleźć odpowiedniego podejścia do porównania każdego pola bazy danych z danymi JSON.
Więc jakie jest najlepsze podejście do porównywania danych lokalnych z danymi nowego serwera?
3. Za każdym razem, gdy usuwam dane Sqlite i wstawiam nowe dane, a następnie odświeżam ekran (który ma UITableView), miga on przez sekundę, co jest oczywiste. Jak uniknąć tego problemu, jeśli przestrzegane są kroki 3, 4, 5?
4. 4. Jak powinienem kontynuować aktualizację danych w przypadku, gdy wracam na ekranie za każdym razem, gdy aplikacja staje się aktywna? Jestem bardzo świadomy NSOperationQueues lub przy użyciu GCD o to chodzi. Ale co jeśli jestem szalony i chodzę tam iz powrotem na ekrany od nowa. W kolejce pojawi się numer NSOperations.

Answer 1

Wyzwaniem jest synchronizacja danych na serwerze, co już wcześniej zrobiłem i jeśli możesz poświęcić na to czas, powiedziałbym, że to najlepsze rozwiązanie.

Możesz potrzebować dat utworzenia i modyfikacji na serwerze i obiektach lokalnych, aby je porównać - pozwoli ci to zdecydować, które obiekty dodać, zaktualizować i usunąć. Jeśli serwer wyśle ​​tylko ostatnio zaktualizowane obiekty, można zaoszczędzić dużo ruchu i poprawić wydajność (ale usunięte obiekty będą trudniejsze do wykrycia).

Jeśli dane są zmieniane tylko na serwerze, to łatwiejsze, gdy aplikacja może zmienić dane również staje się bardziej skomplikowana (ale wygląda na to, że nie jest to przypadek). Zależy to oczywiście od złożoności bazy danych.

Jeśli nie chcesz w to inwestować, po prostu pobierz wszystkie dane za każdym razem, nawet jeśli nie jest idealny! Zamiast pokazywać stare dane i migać je, możesz po prostu sprawić, by użytkownik odczekał 2-3 sekundy podczas wchodzenia, podczas gdy otrzymasz nowe dane.Lub zamiast tego możesz pobrać dane tylko podczas uruchamiania aplikacji, więc kiedy przejdziesz do tego kontrolera widoku, będzie on już gotowy.

Jest to złożony problem, że każdy stoi w pewnym momencie, więc jestem ciekaw, co inni ludzie będą sugerować :)

Answer 2

Jak o tym:

1. Jeżeli istnieją dane w SqlLite, obciążenie do „in-memory” kopiuj i pokazać mu
2. obciążenia tle nowych danych serwerowych
3. usuwanie starych danych SQLite, jeśli istnieje (należy pamiętać, że w pamięci pozostaje kopia)
4. zapisać nowe DAT serwera a do sqlite
5. załaduj nowe dane sqlite do kopii "w pamięci" i pokaż ją.

Jeśli dane nie został znaleziony w kroku 1, wyświetli ekran „Ładowanie” do użytkownika podczas etapu 2.

robię założenie, że dane z SqlLite jest wystarczająco mały, aby zachować kopię w pamięci, aby pokazać w twoim widoku UITable (Widok UITable zawsze pokazywał dane z pamięci).

Możliwe jest łączenie kroków 4 i 5, jeśli dane są wystarczająco małe, aby pomieścić dwie kopie w pamięci w tym samym czasie (można utworzyć nową kopię w pamięci i zamienić z widoczną kopią po zakończeniu).

Uwaga: Uwaga: Nie mówię tutaj o obsłudze błędów, ale sugerowałbym, aby nie usuwać danych sqlite, dopóki nie otrzymasz nowych danych do ich zastąpienia.

Takie podejście eliminuje również potrzebę określenia, czy jest to pierwsze uruchomienie, czy nie. Logika zawsze pozostaje taka sama, co powinno nieco ułatwić wdrożenie.

Mam nadzieję, że jest to przydatne.

Answer 3

Możesz robić to samo wydajniej dzięki MultiVersion Concurrency Control (MVCC), który używa licznika (rodzaj bardzo prostego "znacznika czasu") dla każdego rekordu danych, który jest aktualizowany po każdorazowym zmianie rekordu oznacza, że ​​potrzebujesz aby uzyskać te dane, które zostały zaktualizowane po ostatniej synchronizacji, co redukuje dużo nadmiarowych danych i przepustowości.

Źródło: MultiVersion Concurrency Control

Answer 4

To jest dobre pytanie.

Osobiście uważam, że pobieranie danych, przechowywanie lokalnie i późniejsze próby synchronizacji to niebezpieczny scenariusz. Łatwe do wprowadzenia błędów, opanowania < - problemy> Slave (jakie dane powinny być mistrzem, jeśli wiele urządzeń byłyby wykorzystywane itp)

Myślę, że coś takiego może być podejście robocze:

1. Chciałbym spróbować spojrzeć na możliwości leniwego ładowania danych z serwera na żądanie. Dzieje się tak, gdy użytkownik ma widok, który powinien wyświetlać dane, załadować te określone dane wraz z utworzeniem tego określonego widoku. Zapewnia to synchronizację danych.

2. Zwalczanie potrzeby przeładowywania danych z serwera z każdego widoku można wykonać, po prostu przechowując pobrane dane jako obiekty w pamięci (bez użycia SqlLite).Widok podejmie próbę załadowania potrzebnych danych za pomocą menedżera pamięci podręcznej i wyświetli go z pamięci, jeśli jest dostępna. Jeśli nie w pamięci, po prostu pobierz dane z serwera i dodaj je do pamięci podręcznej. Pamięć podręczna pamięci może być domowym menedżerem danych owijającym Dictionary przechowywanym na Tobie AppDelegate lub jakimś globalnym "Singeltonem", który otoczy zarządzanie pamięcią podręczną/przechowywanie i ładowanie danych.

3.Z leniwym załadowaniem pamięci podręcznej danych i pamięci należy upewnić się, że wszelkie aktualizacje (zmiany, nowe rekordy, usunięte rekordy) aktualizują model danych pamięci, a także przesyłają te zmiany na serwer, gdy tylko możliwy. W zależności od wielkości danych itp. Możesz zmusić użytkownika do oczekiwania, lub zrobić to bezpośrednio jako proces w tle.

4. Aby zapewnić synchronizację danych, należy upewnić się, że okresowo unieważnia się (usuwa) lokalne rekordy pamięci w pamięci podręcznej, a tym samym wymusza aktualizacje danych z serwera. Najlepszym rozwiązaniem będzie prawdopodobnie ostatni zaktualizowany znacznik czasu dla każdego rekordu w pamięci podręcznej. Tak więc okresowy unieważnik usuwałby tylko "stare rekordy" z pamięci podręcznej pamięci (jeszcze raz nie z serwera).

Aby zaoszczędzić serwer przed niepotrzebnym ładowaniem danych, dane powinny być nadal ładowane na żądanie, gdy użytkownik potrzebuje go w widoku, a nie jako część "unieważniania pamięci podręcznej".

5. W zależności od rozmiaru danych może zajść potrzeba "unieważnienia pamięci podręcznej". Może być tak proste, jak w przypadku przechowywania rekordów xx, rozpocząć usuwanie starych obiektów z pamięci podręcznej (nie serwera, tylko lokalnie na urządzeniu).

6. Jeśli synchronizacja danych jest absolutnie krytyczna, możesz rozważyć odświeżenie pamięci podręcznej pamięci dla rekordu, tuż przed zezwoleniem użytkownikowi na zmianę danych. Na przykład. gdy użytkownik kliknie "Edytuj" lub podobnie, pobierasz najnowsze dane z serwera dla tego rekordu. To jest po prostu upewnić się, że użytkownik nie będzie aktualizacji rekordu przy użyciu nieaktualnych danych i tym samym przypadkowo przesłanianie wszelkie zmiany dokonane zdalna lub na innym urządzeniu itp

-

moje zdanie na jej temat. Nie wierzę, że istnieje "idealny sposób", aby to zrobić. Ale chciałbym to zrobić.

Mam nadzieję, że pomoże to w przypadku niektórych pomysłów i inspiracji.