This week I got myself wondering when would be the best practical cases to use Services, Content Providers, and Model-View-Presenter pattern.
Although the SDK Documentation provides a recommendation on when to use each of these, I thought the content to be a little spread out. If you implement the MVP pattern, how should you connect your View to your Service, for instance?
I’m still experimenting and researching some ideas, but for the sake of hacking, I got some sense of how to put them together. Yes, I know it is basic stuff, but one should never be afraid of reviewing the basics, ¯_(ツ)/¯
Start off by getting things right
My first step was to search what other developers have been sharing about Service and IntentService. The name Service is, at least for me, misleading as it always made me think of a content provider that execute tasks in the background. I was getting it wrong, and the article above helped me understand what a
Service really is (besides official documentation).
So, if a Service is not a provider of content, but a more generic tool in our arsenal, understanding the usage of Content Providers become much more straightforward.
Still, in the Services Realm, it is good to have a refresher of the difference between processes and threads are. Simply put, according to documentation, a Process is the group of threads the application run onto, but there is a caveat in which one or more of the app’s components could run in different processes.
Threads that are not the main/UI thread are called worker or background threads. Nothing complicated with that, they are processes that should not execute UI code and run in parallel with the UI thread.
Now let’s start the quest
In a nutshell and if we ignore for now the JobScheduler usage recommendation starting from 5.0,
- If your task is simple, use simple tools: Don’t kill a fly with a bazooka. For merely pulling data from an API, use libraries like Retrofit that execute the remote job for you smoothly.
- Presenter should use an Interactor, meaning it delegates the data pulling job to another class and gets its results to render the view.
- Interactor will be the interface to all the remote communication and provides the Presenter with the data it retrieves either from Content Providers, SQL Databases or APIs.
- Interactor can give Presenter with more than just results. It can deliver back to the presenter messages of what is the stage of the request and partially feeding it until the request is finishing. It allows the Presenter to make the View show meaningful information regarding the step of the request to the user, and yet decouple the chain and make the code easily testable.
Am I wrong? Maybe. Is it the best approach? Perhaps not. Regardless, it has helped me in this week to organize the pieces that make an application and solve some misunderstandings I always had. As soon as I get an update on this, I come back 😉