Alternative for ContentProvider

[rafaelekol]

You prepared a great example project. But I have one issue. Can we use alternative ways to observe data changes instead of ContentProvider. For example SQLBrite, or simple SQL query?

[tehmou]

@rafaelekol what is your concern with using ContentProviders?

To be honest, I do not have much experience using an SQLite database directly. My main concern would be using the same SQLite database from multiple processes simultaneously without a ContentProvider. There seem to be some stackoverflow threads saying it at least not straightforward (read/write locks producing errors) http://stackoverflow.com/questions/5248319/database-handling-with-2-processes and http://stackoverflow.com/questions/12407433/multiple-access-to-sqlite-database-in-android. Do you know if this is a limitation of directly accessing the SQLite database without ContentProviders?

[tehmou]

It seems that SQLBrite does also support ContentProviders as a source for observables, though of course it uses cursors internally. It might be an interesting option, even if it still requires the actual ContentProvider as well as the code to parse the query results.

[rafaelekol]

I haven't encountered such problems with SQLite yet, but thank you for advice.
For me ContentProvider seems to have a lot of boilerplate code, thats why I try not to use it.

[tehmou]

For the boilerplate I have an intermediate solutions that I am planning to extract into a library. It would at least make it cleaner to declare the ContentProviders. It might already be enough to make the architecture easily adoptable. However, I did notice that even in that case it might be a good idea to use SQLBrite and database Cursors instead of the onChange event.

I will look into using plain SQLite databases, though, as it might be an easy alternative. The other thing I am thinking is using in-memory databases that do not need a schema at all. If you do not need the caching or inter-process operability, it could be a good light weight solution for many apps.

[rafaelekol]

OK, I will check in-memory database solution too, meanwhile I found cool new library for database https://github.com/pushtorefresh/storio . I think it has big potential, especially with Reactive programming.

[tehmou]

Oh nice, that's sounds promising! We had an implementation of the in-memory store, but we replaced it with the ones that base on ContentProviders because of the revised architecture that is being updated. The plan is to do all the network requests in a separate service, which would mean it's not possible to use an in-memory one since it cannot be shared between processes. Maybe another example repository with a less ambitious architecture would be in place.

[yozh1que]

afaik this project makes emphasis on widget tools and widgets don't work with sqlite dbs directly, but through contentprovider api

[muyiou]

why not use okhttp-cache to cache data?

[tehmou]

@muyiou ContentProviders in this architecture are not only used for caching but also for propagating the updated data. Disk cache for http requests is usually enough for caching data between application launches, but the propagation mechanism would be actually quite difficult to implement.

On a side note, I had a chat with the maintainer of https://github.com/SimonVT/schematic and it seems it is the best solution available for declaring content providers in a convenient way with annotations. With the Schematic library it should be an acceptably low effort to implement a ContentProvider.

[AdrianoCelentano]

Just stumbled upon this
https://github.com/sockeqwe/sqlbrite-dao

[tehmou]

Resolved with pull request #73.