On Fri, Oct 26, 2012 at 2:23 AM, Tim t...@mobiforms.com wrote:
Dear Nageswararao,
Could I suggest you have a look at the MobiForms Advanced Edition mobile
development suite for Android?
snip
Can we keep the marketing stuff off the mailing list? You can always
reply directly to person who
This is some thing what m also working on to sync db best thing is use
content provider using syncAdapter in android
see one of my
post
http://ericmiles.wordpress.com/2010/09/22/connecting-the-dots-with-android-syncadapter/
database file size is android.database.sqlite.SQLiteDatabase has
Dear Nageswararao,
Could I suggest you have a look at the MobiForms Advanced Edition mobile
development suite for Android? The MAE includes the MobiForms Developer
and the MobiForms Sync Server. The MobiForms Developer is especially
designed for creating database oriented mobile business
SQL performance often relies on indexing and quantity of data. Generally
fields you join on are going to need to be indexed (as they appear to be
pk's). Without a where criteria, you're effectively going to end up with a
table scan on english words, and compounded by the joins.
I dont know
Those two devices might be using different sqlite versions. I've found from
my work that version 3.7 can be significantly faster than 3.6 for some
queries.
There are performance analysis tools built into sqlite, one is the usual
explain, the other is a low level virtual machine trace tool. You
that was it - i had forgotten to pk one id column in one of the join tables
- adding that and it's night-and-day - under 1 second, compared with ~30
before. thanks all for reinforcing that concept. very glad i didn't try
to convert the whole thing to a Java model.
--
You received this
When you see huge differences like this on joins it often means one of
the inner columns is not in an index _and_ there exists at least one
pair of tables being joined that won't fit in cache. So I'd bet the
difference between the two devices is SQLlite caching, which could be
either RAM available
the string datatype is called TEXT in sqlite.
to setup working tables see http://www.sqlite.org/lang_createtable.html
--
christoph polcin
www.christoph-polcin.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group,
Ola,
Porque voce nao experimenta o TotalCross?
www.totalcross.com.br
abraços,
Guilherme
On 8 set, 21:21, Andrews andyyc...@gmail.com wrote:
hi i am a student from Brazil and I am studying android. I would ask
if you could
share a material on Android and sqlite (CRUD). Thank you all
--
I implemented an database application on device. But i am unable to
find where the database file is stored on sdcard.
It's not stored on the SD card. Why do you think it should be there?
Does your phone have internal memory?
--
You received this message because you are subscribed to
Hi,
yeah my phone has internal memory, but how can i access the database file.
Thanking you,
Nagu.
--
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
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
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
C O N T E N T P R O V I D E R
On Apr 7, 4:01 pm, Evgeny Nacu evgeny.n...@gmail.com 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
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 evgeny.n...@gmail.com wrote:
Hi again!
DanH, I use thread synchronization. It works well.
But, as I told in my
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
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
2011/4/7 Evgeny Nacu evgeny.n...@gmail.com
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
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
On Apr 7, 9:23 am, Dianne Hackborn hack...@android.com 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
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
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
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
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
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
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
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
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
On Thu, Apr 7, 2011 at 12:18 PM, Emanuel Moecklin 1gravity...@gmail.comwrote:
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
On Apr 7, 11:22 am, Dianne Hackborn hack...@android.com 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
On Thu, Apr 7, 2011 at 2:04 PM, Nathan critter...@crittermap.com 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
On Apr 7, 3:15 pm, Dianne Hackborn hack...@android.com wrote:
You are making this too complicated.
No, I am not.
class StuffDatabase {
SQLiteDatabase mDatabase;
static StuffDatabase getInstance();
}
class OtherStuffDatabase {
SQLiteDatabase mDatabase;
static OtherStuffDatabase
On Thu, Apr 7, 2011 at 6:33 PM, Nathan critter...@crittermap.com 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
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
On Apr 7, 3:46 pm, Mark Murphy mmur...@commonsware.com wrote:
On Thu, Apr 7, 2011 at 6:33 PM, Nathan critter...@crittermap.com 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
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 garyjamessi...@gmail.com wrote:
Hi,
I (strongly?) suggest you wrap access to the sqlite3
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
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
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
Hi,
I (strongly?) suggest you wrap access to the sqlite3 database in a
Content Provider if you are accessing concurrently (doing both
readwrite) from Activity Service - particularly if Service is in
different process.
Content Provider seems to manage concurrent access for you ok, without
having
you could simplify your code by using openOrCreateDatabase
(DATABASE_NAME, Context.MODE_PRIVATE, null); instead. :) Maybe then
the problem will resolve itself.
Cheers,
Per Sandström
On Jan 29, 5:52 pm, Josema jose.maria.estr...@gmail.com wrote:
Hi,
im doing debug with my mobile. My code works
41 matches
Mail list logo
