Obsługa tabel i kursorów SQLite w systemie Android

Question

Mam trudności z optymalizacją kompatybilności wstecznej, złożonością i sprawdzonymi metodami obsługi baz danych SQLite w systemie Android. Znalazłem dwa nie przestarzałe sposoby zarządzania bazami danych SQLite oraz kursory:

• bezpośrednio przez android.database.sqlite
• ContentProvider, CursorLoader i LoaderManager

próbuję zaprojektować przyszłej realizacji w bazie dowód. Oznacza to, że chciałbym wdrożyć najlepszą praktykę promowaną przez Google. I found a tutorial po implementacji ContentProvider i LoaderManager.

Jeśli podążam za propozycjami Larsa Vogelsa, mój kod zostaje wysadzony duplikacjami i niepotrzebną złożonością. Ma to sens w przypadku niektórych tabel w mojej bazie danych. Ale nie ma sensu implementować tego dla tabeli mapowania z trzema polami (na przykład). Ponadto mam problemy z ActionbarSherlock i interfejsem oddzwaniania LoaderManager (istnieje rozwiązanie, ale podwoiłoby to moje klasy obsługi danych).

Bezpośrednia obsługa bazy danych i kursorów za pośrednictwem android.database.sqlite powoduje problemy z zarządzaniem zasobami (zamykanie kursorów!) I sprawia, że ​​jestem odpowiedzialny za obsługę zadań.

Moje pytania:
Jak się obchodzić bazy danych SQLite w Android?
Kiedy idziesz dalej i wdrażasz ContentProvider i LoaderManager?
Jak zachować zgodność z poprzednimi wersjami?

Moje obecne podejście:
Stworzyłem klasę, która oddziela bazy danych we/wy (poprzez android.database.sqlite) z działalności. Wszystkie metody otwierają i zamykają kursory, których używają podczas wykonywania (poza moimi działaniami) i zwracają obiekty lub dane w razie potrzeby (zamiast kursora). Operacje we/wy są wykonywane w AsyncTasks. To podejście wydaje się bardzo przestarzałe.

Answer 1

Niedawno miałem ten sam zwykły dylemat dostawcy sqlite/content i wygląda na to, że dostawca treści jest najczęstszym podejściem do rozwiązania problemu.

Nawet jeśli official doc stwierdza, że ​​

Nie trzeba rozwijać swój własny dostawcę jeśli nie zamierzamy podzielić się swoimi danymi z innymi aplikacjami

dodali opcję mają unexported dostawców treści przy użyciu

android:exported="false" 

Wszystkie książki czytałem, w tym Reto Meier P rofessional Android Development 4, sugerujemy korzystanie z dostawców treści.

Co więcej, kosztem dużej ilości kodu standardowego można zapomnieć o problemach wielowątkowości i otwartego kursora.

W każdym razie, muszę powiedzieć, że największą zaletą, jaką daje komonent dostarczający zawartość/program ładujący kursor, jest to, że program ładujący jest automatycznie powiadamiany o każdorazowych zmianach danych.

Jeśli używasz zwykłego sqllite, musisz zaimplementować pewien sposób, aby klasy klientów były powiadamiane za każdym razem, gdy dane zmieniają się w tle. Na przykład użyłem rozgłoszeń do powiadamiania o wszelkich działaniach, które tabele zostały zaktualizowane w intentservice.

W końcu byłem trochę rozczarowany całą powielaną wersją kodu i postanowiłem napisać skrypt w języku Pythona, aby wygenerować dostawcę zawartości w moim miejscu, używając tylko opisu modelu danych. Prawdopodobnie musisz zmodyfikować wygenerowaną klasę (lub lepiej, aby ją rozszerzyć), ale myślę, że oszczędza to sporo czasu. Można go znaleźć here

Wnioski:

• jeśli chcesz eksportować dane do innych aplikacji (nie tak często), trzeba iść do dostawcy treści
• jeśli chcesz obserwować dane/aktualizuj ui, ponieważ twój zestaw danych może zostać zmieniony w tle, dostawca treści + program ładujący jest bardzo wydajny
• jeśli masz wstępnie załadowany zestaw danych i może aktualizujesz go w tym samym działaniu, które wyświetla dane lub potrzebujesz wykonywać proste operacje z twoją ta bles, może sqllite klasa helpera wystarczy