Podejście do aplikacji bazodanowej - sqlite

Darus224

Witam,

mam pytanie jakie jest najlepsze podejście do aplikacji bazodanowej, składającej się z kilku tabel.

Czy lepiej stworzyć jedną klasą obsługująca operacje na tabelach, czy też może lepiej jest tworzyć klasy dla poszczególnych tabel/encji i zawierać w niej metody do obsługi tych tabel.

Z góry dzięki za odpowiedź.

Jazotu

Zdecydowanie dla tabel. Powiedzmy że jedna 'tabela' przechowuje dane kontaktowe (adres, nr tel...) - żeby ją uzupełnić potrzebujesz odpowiedniej metody. Druga tabela może przechowywać całkiem inne dane i co wtedy zrobisz? musisz stworzyć nową metode do wpisywania rekordów, usuwania, edycji, itd..

Dzakus

Darus224, skorzystać z ContentProvidera i go poprawnie napisać. Wtedy nie korzystasz z żadnych dziwnych klass, ale z kontraktu, który co prawda ma klasy wewnętrzne, ale tylko z stałymi, a kod kontraktu jest dużo krótszy.

Darus224

Dzakus, poczytałem o ContentProvider i znalazłem taki fragment w dokumentacji:

"Decide if you need a content provider. You need to build a content provider if you want to provide one or more of the following features:

You want to offer complex data or files to other applications.

You want to allow users to copy complex data from your app into other apps.

You want to provide custom search suggestions using the search framework.

You don't need a provider to use an SQLite database if the use is entirely within your own application.".

Jak dobrze rozumiem to wychodzi na to, że głównie wykorzystuje się jeśli chcemy dzielić dane z innymi aplikacjami i im udostępniać. Wiec chyba zostanę przy standardowej metodzie z SQLiteOpenHelper.

Mam jeszcze takie pytanie, czy operacje typu CRUD na tabelach powinny być wykonywane w osobnym wątku czy też mogą być w głównym wątku UI, np. chcąc wczytać dane i uzupełnić ListView ?.

Dzakus

Darus224, to jest przestarzałe. Google teraz zawsze zaleca ContentProvider, co zapewnia, że działają Loadery, a zatem wczytywanie asynchroniczne i masz powiadomienia, gdy coś zmieni się w bazie danych. Po za tym tworzysz nową warstwę abstracji, które przy rozroście aplikacji ułatwiają pracę.

Wszystkie działania w bazie danych POWINNY być robione w nowym wątku. W przypadku ContentProvidera trzeba skorzystać z jednego interfejsu (LoaderCallbacks), a potem to już tylko getLoaderManager().initLoader(0,null, this); i gotowe. Jak dokonasz jakiś zmian w bazie danych to automatycznie ci odświeży, gdy poprawnie ContentProvider jest napisany. Przydatne zwłaszcza, gdy piszę się mechanizmy synchronizacji.

Darus224

Dzakus, dzięki za wytłumaczenie i będę z tym działał.

Jeśli chodzi o automatyczne wykrywanie zmian w bazie danych o którym wspomniałeś to do tego trzeba wykorzystać klasę ContentObserver ?

Jeszcze pytanko odnośnie ContentProvider, czy dobrze zrozumiałem, że najlepiej jest stworzyć jedną klasę rozszerzającą ContentProvider, a następnie przekazując jej odpowiednie URI wybieramy na jakich tabelach chcemy wykonać operację ? Pytam bo większość tutoriali opiera się na jednej tabeli i klasa dziedzicząca po ContentProvider zwykle ma nazwę podobną do nazwy tabeli po czym można by wnioskować, że należy tworzyć ContentProvider'y dla każdej z tabeli lecz nie wydaje mi się aby to było zbyt dobrym rozwiązaniem.

Dzakus

Darus224, tak. Tą klasę lub inną klasę, która korzysta z tej klasy. Przykładowo Loader: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/content/CursorLoader.java

Tworzysz jeden ContentProvider dla wszystkich danych. Przykładowo książka telefoniczna ma jedną. Spójrz na źródła Google iosched lub na źródła Androida.

Darus224

Dzięki Dzakus,

odnośnie ContentProvider nie wiem czy dobrze rozumiem znaczenie UriMatcher, klasa ta głównie pomaga w tłumaczeniu adresów URI na wartości Int ?

Dla przykładu jeśli mamy taki fragment kodu:

static final String PROVIDER_NAME = "com.example.provider.Books"; static final Uri CONTENT_URI = Uri.parse ("content://"+ PROVIDER_NAME + "/books"); static final String _ID = "_id"; static final String TITLE = "title"; static final String ISBN = "isbn"; static final int BOOKS = 1; static final int BOOK_ID = 2; private static final UriMatcher uriMatcher; static{ uriMatcher = new UriMatcher(UriMatcher.NO_MATCH); uriMatcher.addURI(PROVIDER_NAME, "books", BOOKS); uriMatcher.addURI(PROVIDER_NAME, "books/#", BOOK_ID); }

Głównie chodzi o blok static na końcu.

Czy wszystkie adresy tłumaczone w ten sposób

uriMatcher.match(argURI)

oznaczają konkretne nadane im wartości typu int ?

Czy środkowy parametr definiuje jak kończy się podany URI czyli w tym przypadku wszystkie z końcówką "books" mają identyfikator 1, a wszystkie z końcówką "books/[dowolna liczba calkowita]" posiadają identyfikator 2 ?

I jeszcze jedna rzecz bo spotkałem się z zagnieżdżaniem tych adresów URI, więc jeżeli mamy kilka tabel to dla nich przykładowe adresy nadajemy osobno np.

static final Uri CONTENT_URI = Uri.parse ("content://"+ PROVIDER_NAME + "/people"); static final Uri CONTENT_URI = Uri.parse ("content://"+ PROVIDER_NAME + "/books");

czy w taki sposób wyglądający na jakąś strukturę zagnieżdżoną:

static final Uri CONTENT_URI = Uri.parse ("content://"+ PROVIDER_NAME + "/people/books");

Dzakus

UriMatcher jest klasą do dopasowania Uri.

Definiujesz jakie masz wzorce:

uriMatcher.addURI(PROVIDER_NAME, "books", BOOKS);

a potem wykonujesz metodę match na obiekcie uriMatchera, co powoduje, ze po prostu przelatuje po wszystkich wzorcach (2 parametr metody addURI, jeśli dopasuje to zwraca parametr 3), który potem jest wrzucany do switcha i możesz równe zapytania budować w zależności od Uri.

W wzorcu # oznacza, że dopasowuje tylko cyfry, a * oznacza, ze dopasuje również tekst. Można równieź przekazać parametry w Uri przez QueryParameter, ale to już wyższa szkoła.

Wzorzec jest absolutny

books/# pasuje tylko do books/3, a nie pasuje do books/, ani calls/books/

Darus224

Jak postępować w przypadku operacji insert, delete, update w osobnym wątku. Bo w przypadku zwykłego select korzystam jak wspomniałeś z interfejsu LoaderCallbacks. A te pojedyncze operacje wykonywać w AsyncTask ?

Dzakus

Tak. Możesz też pomyśleć, czy w konstruktorze nie możesz mądrze danych przekazać.