Currently, it's not possible to have one path of the provider backed by something other than the database, even though that should be possible. Ideally, one could have - say - a contact photo URI go straight to a filesystem instead of a database. This will require a bit of refactoring and maybe changing of the API, but is one of the goals for this framework.
To demonstrate this functionality, a simple filesystem path handler should be written which allows for storage / retrieval of content from a file, probably by returning a URI instead of the binary blob itself (it may be valuable to check out the way that Android implements the contact provider for this).
Currently, it's not possible to have one path of the provider backed by something other than the database, even though that should be possible. Ideally, one could have - say - a contact photo URI go straight to a filesystem instead of a database. This will require a bit of refactoring and maybe changing of the API, but is one of the goals for this framework.
To demonstrate this functionality, a simple filesystem path handler should be written which allows for storage / retrieval of content from a file, probably by returning a URI instead of the binary blob itself (it may be valuable to check out the way that Android implements the contact provider for this).