Hi everybody again!
So, advices here helped! Thanks!
After some research and testing this solutions seem to work OK:
I have only one!! writable sqlite db. (implemented using singleton as
some people suggested here)
Also, I've got some db code to synchronize write operations.
Only one thread can e
On Apr 7, 3:46 pm, Mark Murphy wrote:
> 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 id
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 Apr 7, 3:15 pm, Dianne Hackborn wrote:
>
> You are making this too complicated.
No, I am not.
>
> class StuffDatabase {
> SQLiteDatabase mDatabase;
> static StuffDatabase getInstance();
>
> }
>
> class OtherStuffDatabase {
> SQLiteDatabase mDatabase;
> static OtherStuffDatabase getInst
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 Apr 7, 11:22 am, Dianne Hackborn wrote:
> 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.
"The database"? I guess that would work if you only use ONE,
static
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
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 availability of the sdcard can be "shaky" at times e
That doesn't work if the launching activity has been removed from the
task (e.g. because Android needs more memory).
With your approach the db would be closed and the other activities had
no db access any more (the other activities could still be running).
Instead of spreading the db access code ac
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
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
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 all
"connections" are closed or should Application be sub-classed and the
db closed in onDe
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
On Apr 7, 9:23 am, Dianne Hackborn wrote:
>
> You should never open a database multiple times.
>
Let me make sure I understand this rule.
It seems reasonable to pass an intent:
+ A path to a database
+ A key to find information in said database.
Then the activity will create a list, form etc
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.
Kostya, how many users do use your app?
Cause my version works ok for me and for most my users. But some of
them keep getting such error.
I think, this problem is related to some devices, not every.
Or, may be some very specific cases.
Also, do your background threads use ContentProvider to inser
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
The problem is that when you "hold the cursor open" the database is
locked. That feature is not really applicable to a multi-threaded SQL
environment.
On Apr 7, 1:01 am, Evgeny Nacu wrote:
> Hi again!
>
> DanH, I use thread synchronization. It works well.
> But, as I told in my first post, there
C O N T E N T P R O V I D E R
On Apr 7, 4:01 pm, Evgeny Nacu wrote:
> Hi again!
>
> DanH, I use thread synchronization. It works well.
> But, as I told in my first post, there are some problems:
>
> The biggest problem: I can't use Cursor for my ListAdapter and
> ExpandableListAdapter
> I've got
Hi again!
DanH, I use thread synchronization. It works well.
But, as I told in my first post, there are some problems:
The biggest problem: I can't use Cursor for my ListAdapter and
ExpandableListAdapter
I've got to use something like ArrayAdapter, read all data from cursor
to java objects at one
A content provider won't provide any function over what you have now
-- it's just a different way to accomplish the same synchronization.
With SQLite you basically can't have two transactions going on at the
same time, so you must either use semaphores or some such to prevent
"collisions" or use a
Thanks to everyone!
I've heard that ContentProviders do not have such problem. May be
I'll try to use them, but I have many things to change.
Thanks for the suggestion.
Evgeny
On 1 апр, 05:11, gjs wrote:
> Hi,
>
> I (strongly?) suggest you wrap access to the sqlite3 database in a
> Content Pro
Hi,
I (strongly?) suggest you wrap access to the sqlite3 database in a
Content Provider if you are accessing concurrently (doing both
read&write) from Activity & Service - particularly if Service is in
different process.
Content Provider seems to manage concurrent access for you ok, without
havin
yes, semaphores are the way to go, especially for bulk write operations. it
helps if you read some of the data from the database into a buffer. Then you
can use the buffered data while the database update is processed, and the
users may not even notice.
--
You received this message because you
If you plan on using threads to access a database, then I believe there is
no other way to alleviate the exceptions being thrown *except* with some
sort of synchronization like you have. I do the same sort of things with my
databases and use semaphores to ensure exclusivity of my database.
As t
29 matches
Mail list logo
