Room persistence library and Content provider

I had the same question by the way. And I found a sample here which answers my question. Hope it does the same with you.

In short, this is in the DAO object which would be called from Content Provider's query() method.

/** * Select all cheeses. * * @return A {@link Cursor} of all the cheeses in the table. */@Query("SELECT * FROM " + Cheese.TABLE_NAME)Cursor selectAll();

Notice how it returns Cursor object. Other operations, you can see for yourself in more detail in the sample.

This here is choice number 3 in the answer by @CommonsWare, I think.

if I want to build up an app with local DB , I will now obviously choose new Architecture Components (live data , view model , room )

I would not use the term "obviously" there. The Architecture Components are an option, but not a requirement.

But If I want my DB datas accessible to other app , for instance To Widget How do I integrate Content Provider with Room ?

An app widget is unrelated to a ContentProvider. IMHO very few apps should be exposing databases to third parties via ContentProvider, and no apps should be using a ContentProvider purely for internal purposes.

That being said, you have a few choices:

1. Do not use Room, at least for the tables to be exposed via the ContentProvider

2. Use Room for internal purposes, but then use classic SQLite programming techniques for the ContentProvider, by calling getOpenHelper() on your RoomDatabase

3. Use Room in the ContentProvider, writing your own code to build up a MatrixCursor from the Room entities that you retrieve (for query()) or creating the entities for use with other operations (for insert(), update(), delete(), etc.)

Room Library does not have any particular support for Content Provider. You can only write Content Provider on your own and then use Room to query a database.

If you want to use Android Architecture Components and you want to work with SQLite based Content Providers, consider using Kripton Persistence Library: it allows to generate Live Data from DB queries, generate Content Provider for you, and much more. Least but not last: why do you have to write the entire SQL, when you need only to write the where conditions?

Just to be clear, I'm the author of Kripton Persistence Library. I wrote it because I didn't find a unique library that fit all my need in terms of persistence management (and yes, because I like to program).

I wrote an converted version of Google Content Provider Sample with Kripton. You can found it here.

Just to simplify the reading. With Kripton, you only need to define a DAO interface. Content provider will be generated by the annotations. The same DAO converted in Kripton will be:

@BindContentProviderPath(path = "cheese")@BindDao(Cheese.class)public interface CheeseDao {    @BindSqlSelect(fields="count(*)")    int count();    @BindContentProviderEntry    @BindSqlInsert    long insert(String name);    @BindContentProviderEntry()    @BindSqlSelect    List<Cheese> selectAll();    @BindContentProviderEntry(path = "${id}")    @BindSqlSelect(where ="id=${id}")    Cheese selectById(long id);    @BindContentProviderEntry(path = "${id}")    @BindSqlDelete(where ="id=${id}")    int deleteById(long id);    @BindContentProviderEntry(path = "${cheese.id}")    @BindSqlUpdate(where="id=${cheese.id}")    int update(Cheese cheese);}

The generated Content Provider exposes DAO's method with URIs. For clearification, I put here only the generated JavaDoc (always by Kripton).

More information about Kripton on its wiki, my site and on my articles .