On Fri, Oct 26, 2012 at 2:23 AM, Tim wrote:
> Dear Nageswararao,
>
> Could I suggest you have a look at the MobiForms Advanced Edition mobile
> development suite for Android?
>
Can we keep the marketing stuff off the mailing list? You can always
reply directly to person who requested information
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 apps
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 fol
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
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 messag
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 c
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 deta
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, se
Ola,
Porque voce nao experimenta o TotalCross?
www.totalcross.com.br
abraços,
Guilherme
On 8 set, 21:21, Andrews 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
--
You received th
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
> 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 t
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
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 wrote:
> Hi,
>
> im doing debug with my mobile. My code works in the past, but now is n
41 matches
Mail list logo
