[android-developers] Re: Query about Content Provider queries...
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 somecs...@gmail.com 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 mmur...@commonsware.comwrote: 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! --~--~-~--~~~---~--~~ 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 this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
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 somecs...@gmail.com 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 somecs...@gmail.com 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 mmur...@commonsware.comwrote: 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 hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
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 hack...@android.comwrote: 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 somecs...@gmail.com 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 somecs...@gmail.com 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 mmur...@commonsware.comwrote: 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 hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
No, that would expose the implementation behind the content provider more than we want. For your own content provider you can fairly easily define your own URI schemes that allow arbitrary joins or such across tables or other things, but we don't plan on this becoming a general facility that all content providers must allow. On Thu, Jan 15, 2009 at 7:07 AM, A T somecs...@gmail.com wrote: I have one quick question and one maybe not-as-quick question: 1. Will we be able to employ more robust SQL(ite) queries on content providers with future releases? For instance: joins, distinct, count, max, etc? 2. Why isn't this possible now? I understand the concept of DB table abstraction and the reasoning behind it, but why not still provide some roundabout way of doing these operations (without storing the content in a local SQLite table, of course)? Thanks AT -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
Thanks for your response. I really don't mean to push the issue, I'm just afraid that you misunderstood my question. In terms of existing providers, if I need to do, say, a DISTINCT query, I would have to either load the table into my own provider/SQLite DB and do it there by executing an arbitrary SQLite query, or use a content provider query and operate on the cursor manually. Both approaches are not as efficient as allowing us to directly do the distinct query to the provider itself. I just have a hard time understanding why there aren't overloaded query methods that allow for certain arguments, as there are with the SQLite packages (e.g. having a boolean for DISTINCT). UNLESS you're saying that we can actually extend the functionality for existing providers and implement the query ourselves? If that's the case, that would be great, but I don't see how to do that from looking at the API spec... Thanks again, AT On Thu, Jan 15, 2009 at 1:00 PM, Dianne Hackborn hack...@android.comwrote: No, that would expose the implementation behind the content provider more than we want. For your own content provider you can fairly easily define your own URI schemes that allow arbitrary joins or such across tables or other things, but we don't plan on this becoming a general facility that all content providers must allow. On Thu, Jan 15, 2009 at 7:07 AM, A T somecs...@gmail.com wrote: I have one quick question and one maybe not-as-quick question: 1. Will we be able to employ more robust SQL(ite) queries on content providers with future releases? For instance: joins, distinct, count, max, etc? 2. Why isn't this possible now? I understand the concept of DB table abstraction and the reasoning behind it, but why not still provide some roundabout way of doing these operations (without storing the content in a local SQLite table, of course)? Thanks AT -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
In terms of existing providers, if I need to do, say, a DISTINCT query, I would have to either load the table into my own provider/SQLite DB and do it there by executing an arbitrary SQLite query, or use a content provider query and operate on the cursor manually. Generally speaking, the former is impossible, since you won't have access to the database (e.g., security), if there even is a database, which is far from a given. Both approaches are not as efficient as allowing us to directly do the distinct query to the provider itself. Content providers do not need to use SQLite as a data store. They could use flat files, Web services, third-party object databases, SD card directory trees, random number generators, etc. There is a subset of content providers that will use SQLite as a data store. What Ms. Hackborn is suggesting is that those content providers could offer distinct, etc. via their own exported Uri pattern. What you seem to be proposing is to force developers to implement all the SQL options for data stores that aren't SQL, which may not be a popular answer. I just have a hard time understanding why there aren't overloaded query methods that allow for certain arguments, as there are with the SQLite packages (e.g. having a boolean for DISTINCT). Again, content providers do not need to use SQLite as a data store. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
Ok, I did not realize that. I had made the assumption that they were all DB-based. My real goal here was to just figure out the best (i.e. quickest) way to do some operations that are not possible with the given content provider methods, but at the same time avoid localizing them and then re-uploading the to their native data stores. The reason I don't want to localize them is that I am trying to provide a replacement service for an existing service on the phone, so it must operate on the native content provider, otherwise it is not nearly as useful. It needs to be fast, which it currently isn't if a lot of data is present, which is common with this particular content. I need to access and update the content relatively often (at least as often as the app is started), so faster is better. If it was a rare occurrence, it wouldn't be a terrible problem if it was a little slow. Anyway, I guess I will have to figure out some other way, then. If anyone has any suggestions, I welcome them :) Thank you, Mark, for your explanation. AT On Thu, Jan 15, 2009 at 3:57 PM, Mark Murphy mmur...@commonsware.comwrote: In terms of existing providers, if I need to do, say, a DISTINCT query, I would have to either load the table into my own provider/SQLite DB and do it there by executing an arbitrary SQLite query, or use a content provider query and operate on the cursor manually. Generally speaking, the former is impossible, since you won't have access to the database (e.g., security), if there even is a database, which is far from a given. Both approaches are not as efficient as allowing us to directly do the distinct query to the provider itself. Content providers do not need to use SQLite as a data store. They could use flat files, Web services, third-party object databases, SD card directory trees, random number generators, etc. There is a subset of content providers that will use SQLite as a data store. What Ms. Hackborn is suggesting is that those content providers could offer distinct, etc. via their own exported Uri pattern. What you seem to be proposing is to force developers to implement all the SQL options for data stores that aren't SQL, which may not be a popular answer. I just have a hard time understanding why there aren't overloaded query methods that allow for certain arguments, as there are with the SQLite packages (e.g. having a boolean for DISTINCT). Again, content providers do not need to use SQLite as a data store. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
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! --~--~-~--~~~---~--~~ 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 this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Query about Content Provider queries...
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 mmur...@commonsware.comwrote: 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! --~--~-~--~~~---~--~~ 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 this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
