+1

That's actually a very good question.

The content provider is just another data source for the repository so I agree with your decision.

I will place the service on the presentation layer, is a services folder, it will trigger a use case to sync the data using just a repository implementation. I think that the intent service is just another way of inputing data in the system.

One of the things that concerns me is that these components cannot run in sequence.

In the current implementation, when the UI asks for data the following take place

• the Presenter invokes the UseCase
• the UseCase will ask the Repository
• the Repository implementation will hit the server if needed (if there is no cached data) and will return the results back to caller

In case a Service is used, the workflow could be the following

• the Presenter invokes the UseCase
• the UseCase will ask the Repository
• the Repository implementation will return the data querying the local database. In addition, it will start the IntentService to fetch new data from the REST service
• the REST data are saved onto the database

After that the UI should be informed about the changes and update its contents.

We can accomplish this by using a ContentObserver but in that case, the presentation layer is bound to a concrete data implementation (ContentProvider), so I don't think this is a good idea.

Another option, is that the data layer keeps a reference to the Subscriber (UseCase) and when needed (new changes saved onto the db) informs him again. The UseCase in turn will notify the Presentation's Subscriber which will ask from the View to update.

@alexandru-calinoiu I agree that the Service could be placed in the presentation layer. For instance, the user may need to manually refresh the data, so the Presenter can start the Service.

I will comment on this part:

the Repository implementation will return the data querying the local database. In addition, it will start the IntentService to fetch new data from the REST service

I don't understand why is a IntentService needed?

The way I've done this in the past is using a reactive, with rxjava, have a Repository implemetation that return Obeservable and subscribe to this, I have an example of this here

@alexandru-calinoiu I haven't looked at your example in great detail but I would use an IntentService along with a SyncAdapter if I wanted to sync my data regularly without necessarily the need to display the "new" data to the UI at that moment.

good explaination @BillBosiolis. i think this repo should have a branch that represents how to deal with databases because many of us is using database in everyday project.

And what about CursorLoaders, where do they belong?
How should I pass Cursor from data layer (where content provider belongs) to presentation layer (where cursor adapter belongs)?

+1

@BillBosiolis, I try to follow the approach presented at Google I/O 2010 talk "Android REST client applications", which is the same approach used by Udacity Android Nanodegree course.

Basically you can use:

• The ContentProvider as a facade to the REST API, so they would be the application domain.
• The ContentResolver would be the Interactor (or Control Object, as defined by Ivar Jacobson).
• The CursorAdapters and ViewHolders would just be stupid binders to your View that should not required to be tested, as mentioned by Uncle Bob.

+1