Okay, sure, if you are letting the user open and close databases then you
could have an arbitrary number open (if you are actually letting the user do
that). But then... you also already have the answer for when to close the
database.
For the vast, vast majority of Android applications, there wil
On Thu, Apr 7, 2011 at 6:33 PM, Nathan wrote:
> Would a shopping list application only allow you to have one shopping
> list, called default?
> A lame one would, yes.
A sensible implementation would use one database, with a "lists" table
to identify the lists, and foreign key relationships in the
On Thu, Apr 7, 2011 at 2:04 PM, Nathan wrote:
> "The database"? I guess that would work if you only use ONE,
> statically determined database.
> Since I don't have just one, I think I need a singleton hash table of
> opened databases, like I mentioned.
>
You are making this too complicated.
cla
On Thu, Apr 7, 2011 at 12:18 PM, Emanuel Moecklin <1gravity...@gmail.com>wrote:
> Using a singleton to open the database, where/when would you close the
> database?
> Should the singleton keep track of open connections from clients (the
> singleton would expose a close method) and close it when al
08.04.2011 0:42, Emanuel Moecklin пишет:
I would not recommend putting the db on sdcard.
I went down that path and it worked well for all the devices I tested
it on (>15 hardware devices and of course emulators).
It even worked well for the published app in the beginning but because
the availabil
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 q
Don't do that. Only open the database once. If you are not using a content
provider, implement a singleton that takes care of opening the database once
for all code in your app.
And let me be clear -- there is NOTHING wrong with the content provider
never closing the database. Nothing. That is
07.04.2011 21:39, Nathan ?:
As has been noted in these forums, a ContentProvider*never* closes a
database because is there is no call on its interface to do so.
The Linux kernel closes open files when/if the process is killed or
crashes, just like it cleans up other stuff.
SQLite, as no
Keeping an active cursor is *not* a problem. This is done all of the time.
The cursor just holds an in-memory copy of a window on the result set. The
only time it needs to look the database is when it is filling the window.
On the other hand, having a transaction open will keep the database loc
2011/4/7 Evgeny Nacu
> Kostya, how many users do use your app?
>
It's still in development, so about 30-50.
> Cause my version works ok for me and for most my users. But some of
> them keep getting such error.
>
Can you find out what those devices are? It might give you some further
ideas.
That's not what I'm seeing with my current project.
My UI code uses a LiveView with a CursorAdapter, and has background
threads that access and write to the database, sometimes using
transactions, sometimes not.
I've never seen a "database locked" exception, even when triggering a
background
11 matches
Mail list logo
