Services, Content Providers and MVP pattern

Software Engineering & Travel Journal

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,

  1. 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.
  2. Presenter should use an Interactor, meaning it delegates the data pulling job to another class and gets its results to render the view.
  3. 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.
  4. 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 😉

About The Author

Thiago Ricieri

I’m software engineer at Pluto TV, working on iOS, Android and Roku platforms. Personally interested in machine learning, algorithms, data science and tech industry. I travel a lot and take good pictures.

Add a comment

*Please complete all fields correctly

Related Posts

Anti-Patterns by Example: Premature Optimization
Donald Knuth wrote this quote back in 1973, and for over forty years software engineers have been debating its validity. Is it still applicable for nowadays?
2017 was the Year of Subscriptions: a Rough Draft
What was a utopia years ago, today is commonplace. But it is not new: the internet has widely increased its adoption. Telecoms have always used this model. What is your...
When I got a hand from Sherlock Holmes to help a peer in his problem
This week one of my peers was facing a problem with one of our APIs. He pinged the infrastructure team in Slack warning them about it, saying the API was...