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.com>wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
