Oh, that's not the problem. That will only have to be done once -- the first time the app is run on a device. The rest of the queries and updates will be to and from my own database. The updates to the content provider will be done in the background, and it's ok if the data isn't up to date immediately upon creation/resuming. The user shouldn't have enough time to see incorrect data and quit the app before he sees it get updated, but it's ok if the incorrect data is seen for a brief period.
The thing is, that's what is happening now, but since the queries themselves take a long time, the user doesn't even get to see the incorrect data right away! There is an annoying lag in the program when it is created/resumed, and THEN it gets updated after another brief lag. If I can get rid of the initial lag, long updates done in the background are no problem. I think I have my answer, though. From what you said and with the queries I'm using, I think it will be faster. Thanks a lot for your reply! AT On Thu, Jan 22, 2009 at 12:36 PM, Dianne Hackborn <[email protected]>wrote: > It would be hard to say, it depends very much on what exactly you are > doing. In general direct queries on a database are quite fast, but it would > be hard to say how fast it will be to retrieve all data from an existing > provider and write it into your own database. > > > On Thu, Jan 22, 2009 at 8:52 AM, A T <[email protected]> wrote: > >> So, I'm working on an app that is accessing an existing content provider >> which holds a significant amount of data. I will be querying and updating >> this content provider frequently, and it has proven to cause noticeable >> delays due to the constraints that are required for these queries. I am >> wondering if it would be quicker to load the data into a local SQLite DB and >> use that to query/update, then commit the data less frequently (like when >> the app finishes). I'm hoping that since I can create custom tables and use >> raw SQL queries, the responses will be faster, and I can do the updating to >> the actual content provider in the background, when the user won't notice. >> >> Yeah, I could just try it rather than asking, but I also want to know if >> this is good practice for Android. Or maybe I'm thinking the wrong way and >> this is actually what you're supposed to do in a case like this? >> >> ...Also, I'm lazy and I didn't want to do all the work only to find out >> it's just as slow :P What can I say? >> >> Thanks >> >> >> >> >> On Thu, Jan 15, 2009 at 6:31 PM, A T <[email protected]> wrote: >> >>> You are right about that :) >>> Yeah, so, in other words, it doesn't sound like a problem I'm going to be >>> able to solve here and now, for the project I'm working on. >>> >>> Ok, no worries. I'm sure I'll figure something out. Thanks again for your >>> help! >>> >>> >>> >>> >>> On Thu, Jan 15, 2009 at 4:18 PM, Mark Murphy <[email protected]>wrote: >>> >>>> >>>> > Ok, I did not realize that. I had made the assumption that they were >>>> all >>>> > DB-based. >>>> >>>> Some will be, but I'm under the impression that ContentProvider was >>>> specifically designed not to force it. For example, some people are >>>> using >>>> ContentProvider to serve static Web content to a WebView, which IMHO >>>> doesn't fit a database pattern terribly well. >>>> >>>> > Anyway, I guess I will have to figure out some other way, then. If >>>> anyone >>>> > has any suggestions, I welcome them :) >>>> >>>> I'm sorry if I sounded too harsh in my previous response. >>>> >>>> Given time and effort, you could: >>>> >>>> -- Design a way for ContentProviders to support OPTIONAL additional >>>> interfaces that provide some of the hooks you seek >>>> >>>> -- Modify the built-in ContentProviders to support those interfaces >>>> >>>> -- Submit both as patches to Android and hope they are approved >>>> >>>> However, the keys are "time", "effort", "OPTIONAL", and "approved", none >>>> of which might line up with your near-term objectives... >>>> >>>> -- >>>> Mark Murphy (a Commons Guy) >>>> http://commonsware.com >>>> _The Busy Coder's Guide to Android Development_ Version 2.0 Available! >>>> >>>> >>>> >>>> >>>> >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
