ContentProvider Wasted Potential

This article is part 11 of 11 in the series Android Development

This is only a short post in the series, and the aim is to let off some steam on the wasted potential in ContentProvider. I love ContentProviders. They’re the same sort of thing as a virtual filesystem layer (VFS): an interface, that lets people come up with ingenious ways of using it.

When it comes to VFS, Linux has FUSE, an additional abstraction layer that lets people write filesystem code — that is, deep system code — as simply as writing applications. The ease of use allows for plenty of innovation in this sector.

ContentProviders are similar: they provide a simple but flexible interface for accessing and/or providing data. Beautiful stuff!

In Android, a lot of things are tackled via URIs — the nice thing about URIs is that they already encode information about how to access stuff (the scheme) and who will provide it (the authority). Therefore, URIs and ContentProviders are a match made in heaven. Right?

Well… kinda. ContentProviders are limited to serving data via the content:// URI scheme. In itself, that’s not a problem, but it requires all client code to be aware that there’s multiple sources to get data from, i.e. the file system, ContentProviders, the Web, etc. In order to simplify client code, you can have an API that accepts any URI, and translates back to a single interface that the client code can use for them all.

Android does contain such a thing, via the ContentResolver — for example via the openFileDescriptor() function, to stick with the whole filesystem theme of this post.

Now it’s only a question of all apps using that ContentResolver instead of trying their own URI/scheme handling. Fair enough if not all developers do so.

But Google’s own Android engineers should. Yet there’s a fair amount of examples where that’s not happening in the Android source code.

What a waste of potential. You create something awesome, and then don’t even use it yourself. What sort of adoption rate do you expect, then?