The Note Pad example is pretty good for URI content matching. Basically, you define one or more URIs for a ContentProvider. Don't think of them as "URLs", just think of them as strings with a particular format. Using web domains in them is a easy, nearly foolproof way to ensure that each URI is unique. For example, I can safely use the content URI content://database.lancaster.dambusters.gmail.com because that's my unique GMail address.
Patterns come in when you want a ContentProvider to return different things depending on the exact URI. In the Note Pad sample (*not* the tutorial), there are 3 patterns corresponding to 3 "forms" of data: a list of notes, a single note, or a set of notes compatible with the LiveFolder widget. The "list of notes" form is set up in the code and the manifest so that it returns a set of records. The single note returns exactly one note, and I forget offhand what LiveFolders does. Let's look at the first two. For set of notes, you just specify a "base" URI. The Provider returns all the notes in the database that match your criteria. For a single note, you specify a pattern that is the "single note" base URI with a note ID number appended to it. The ID number is the value of the "_ID" column for the record you want. The Provider returns that particular note. As written, the Provider can also filter the note by selection criteria. If you look in the code for the Provider, you'll see that it defines a UriMatcher. You use UriMatcher.addUri() to match an "authority" (a base URI without a specific pattern) and a pattern to a value. When a URI comes in to the query() method, you use UriMatcher.match to match the incoming URI to a pattern. The method returns the value that you associated with the pattern in addUri(). The UriMatcher is defined in a static block at the end of the code. As a note, you can use "?" in a pattern as a wildcard to match any string, and "#" to match any number. The "#" is used to match a single note in Note Pad. The Note Pad code is hard to understand because it's designed to accept alternate actions. This allows other apps to access the ContentProvider by specifying the proper authority and MimeType. You can ignore this, basically. The mime type tells the calling app what it's gonna get back from the Provider. If the type is vnd.android.cursor.dir, then the calling app knows it may get back more than one row, whereas if it gets back cursor.item, it gets back only one item. Incoming Intents have to specify a mimeType so that they exactly match Note Pad's intent filters. For example, an app that sends an Intent with action.GET_CONTENT but mime type vnd.android.cursor.dir won't match any of Note Pad's intent filters. The elkmeister. On Aug 25, 4:04 am, Arpit <[email protected]> wrote: > Thank you all for answering and guiding me with the design. I wanted > to know whether multiple tables can be part of a content provider. I > have one database and my requirement is to share the DB across > application and hence the Content Provider. > > And after normalizing my tables, I realize a single content provider > will be sufficient to handle all the tables in my db. Though I am > struggling a little with URI matching concept, so trying some code > like NoteList example. Once I run my own code, may be i will > understand better. > > Thanks for the info, it help me a lot with the design. > > Regards, > Arpit > > On Aug 24, 10:51 pm, "A. Elk" <[email protected]> wrote: > > > > > There are two considerations: database design and application design. > > > Database design is much too big of a topic to summarize in a single > > thread! But in short, one wants to normalize the data and do joins to > > combine data from different tables. > > > Application design in Android suggests that a ContentProvider isn't > > necessary for private data. Basically, if you don't want to let other > > applications look at your data (or modify it, or delete it) by > > themselves, then you don't really need a ContentProvider. Of course, > > you can have one if you want. You lose a bit of security, since the > > data becomes "public", although you can keep pretty much private by > > using an obscure URI. > > > Also, it's best to have one database per ContentProvider. If you find > > yourself trying to associate more than one database with the same > > ContentProvider, your design may be suspect. Remember that a single > > database can contain address data, book data, and people data, if the > > domain is library management. On the other hand, you may choose to use > > the built-in Contacts provider for people/address and your own > > ContentProvider for books. > > > In short, there's no one answer, except that you aren't limited to one > > table per ContentProvider, one database per ContentProvider, or one > > ContentProvider per Android application. A ContentProvider has some > > overhead, but I'd opt for one per database rather than worry about the > > overhead. > > > On Aug 24, 9:17 am, Kostya Vasilyev <[email protected]> wrote: > > > > A ContentProvider is queried (and updated) using a URI, which > > > specifies the kind of data to work with. This might look like this: > > > > content://<provider>/counties > > > content://<provider>/counties/<country_id> > > > > content//<provider>/counties/<country_id>/cities > > > content//<provider>/counties/<country_id>/cities/<city_id> > > > > Or even like this, in addition to the above: > > > > content://<provider>/books > > > content://<provider>/books/<book_id> > > > > A helper class, UriMatcher, can be used in ContentProvider > > > implementation to quickly and easily determine what kind of data a > > > request URI refers to - whether it's counties, or cities, or a country > > > by its id (in the examples above). > > > > One the kind of data that the URI refers to is known, it's quite logical > > > to store each kind of data in its own table (e.g. country / city). > > > > I also think it makes sense to implement separate ContentProviders for > > > unrelated sets of data. > > > > In the example above, if you're not linking books to cities, you might > > > have: > > > > content://name.Arpit.GeographyData/counties > > > content://name.Arpit.GeographyData/counties/1 > > > content://name.Arpit.GeographyData/counties/1/cities > > > > ...etc... and: > > > > content://name.Arpit.Library/books > > > content://name.Arpit.Library/books/1 > > > content://name.Arpit.Library/books/2 > > > > -- Kostya > > > > 24.08.2010 20:01, Arpit пишет: > > > > > Hi All, > > > > > All the example codes, tutorials or video I see, there is always one > > > > ContentProvider per SQL Table with the SQLiteOpenHelper extension > > > > defined as a private static class... > > > > > Is it some sort of standard design...to have one ContentProvider per > > > > SQL Table? Or I can define one generic ContentProvider and use its > > > > instance for ever update? > > > > > Is there some issue with that? > > > > > Could anyone please help as my application has like 5-6 tables. > > > > > Regards, > > > > Arpit > > > > -- > > > Kostya Vasilev -- WiFi Manager + pretty widget > > > --http://kmansoft.wordpress.com -- 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
