Ok, here is my setup, just for grins.
I have one database object in the entire application, opened by the
content provider and never closed. The database is accessible as a
singleton (my own SQLiteOpenHelper type class that can put the DB on the
memory card).
The UI uses the CP for the few queries that are shown "live" (in list
views) so it can leverage the change notification mechanism built into
the framework.
For the all other database queries and updates, often made by non-UI
threads, I directly use the same database object.
The code that writes to the DB uses ContentResolver.notifyChange() to
trigger updates to live lists in the UI, as necessary. Doing this rather
than writing through the content provider gives me better control over
when and how these notifications are sent. It also makes it easier to
use transactions.
-- Kostya
07.04.2011 23:26, lbendlin пишет:
I close the databases in the onDestroy() of the launcher activity. I
also include code in other activities and services to check if the
databases have been closed, and then prevent these lenient lurkers
from trying to access them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
