views:

226

answers:

1

I have years of experience with Microsoft .NET development (primarily C#) and have been working to come up to speed on Android and Java. So far, I've built a small application with a couple screens and a working content provider.

All of the examples I've seen for developing content providers typically work with a single table, so I got the impression that this was the convention.

I built a couple more content providers for other tables and ran into the "Unknown URI" IllegalArgumentException when I tried to test them. The exception is being thrown by one of my content providers, but not the one I was intending to call.

It appears that my application is using the first content provider in the AndroidManifest.xml file, which now has me wondering if I should only have a single content provider for the entire application.

Are there any best practices and/or examples for working with multiple tables in an Android application? Should I have one content provider per table or only one for the entire application? If the former, how do I resolve URIs to the proper provider? If the latter, how do I keep my content provider code from being polluted with switch statements?

+4  A: 

99% of Android applications do not need content providers.

Content providers have one primary use: inter-process communication. If you are:

  • expecting other developers to access your content providers, or
  • are integrating to Android in places that require a content provider (e.g., search suggestions for the Quick Search Box)

then, and only then, do you implement a content provider.

Otherwise, all you are doing is adding overhead to your application and making your code more difficult to maintain.

So, if your application is one of the 99% that does not need content providers, just get rid of the one you have and access your content by some other means (e.g., SQLiteDatabase).

CommonsWare
Makes sense. I scrapped the content providers and just went with a DBAdapter class. My code is a lot cleaner and more like the business objects I'm used to working with. Thanks for the help.
Andrew Dyer