What role should an Android service play in an MVP template?

Question

I am developing an Android application that performs human activity recognition.

It basically works: the service constantly reads the accelerator data and saves the recognized activity (i.e. walking, working) in the database. The user can see all recognized actions in the ListView in action (accesses the database). Each user table in the database has a pa_goal field (the goal of physical activity), which the Service reads from the database and performs some checks.

The user, of course, can change this goal from his activities. Since I will implement the MVP architectural pattern.

I'm not sure where to put the service? This, of course, is not a View. Any tips?

Answer 1

In pure architecture, which I assume you are using MVP, there is an idea to separate the structure from the business logic. This, in fact, is what a normal lead allows.

In this case, this is not the opinion you are dealing with, but the principle is similar. You don’t want all your business logic or application logic to mix in the Android code, when you can divide them into more cool, more general classes of responsibility. Therefore, I would say that although this is not a representation, you should still have a class like a presenter (it might be better to be called a controller or manager).

This class will be a POJO that will control how your service behaves, which is easily tested with standard junit tests and service mocks. This class and service can then be placed in its own package of functions and interact with external models in the same way as your presenters.

So, in general, the role of another function of your application is that sites along with other functions (which usually represent only the views in my experience).

Hope that helps

Answer 2

This article helped me in a similar situation, although it may not be exactly yours, the idea is the same:

https://android.jlelse.eu/android-bound-services-and-mvp-12ca9f70c7c7

Basically, the author works on the fact that a related service is closely related to activity and adds additional life-cycle challenges to it.

Answer 3

I am in the same situation. Finally, I decided to do something like this:

Actions or fragments are not available, they do not know anything about MVP, but I'm going to use the event bus, for example Otto, to send signals / events, So:

My classes, which are produced by some Leader, do not know anything about the Android context, but they will have the MvpView interface, only with onAttachPresenter and onDetachPresenter.

A class that extends Service will have a Presenter attribute and implement some MvpView interface with onSucess, onError, onStart, onComplete or something similar, and the same events for Otto (onSucessEvent, onErrorEvent, onStartEvent, onCompleteEvent).

Therefore, when I need to do something, the action or fragment will start the service, the service will "start" or talk to the Leader and when the leader finishes successfully, it will call mvpView.onSuccess () and save the information inside the local database with SQLite (possibly storeIO) and finally, the Service will call Otto and transmit a signal (without any data), possibly onComplete. Finally, the signal will be captured by my UI (possibly a fragment) and get all the information inside the database in SQLite.

So, when onSucess happens, the user interface will show the latest and best data, but if onError happens, then (at least) will show some information (or not, if you want), telling the user: "there was a problem, but at least you can see something, bot onSuccess and onError will throw onComplete in the end.

I do not know if this is the best solution, but in this case I think that I will not deal with the life cycle of actions or fragments and do not care about onSaveInstance and do not restore data when the user rotates the device. It will always receive the latest data inside the database, and if something happens (there is no Internet connection), you can at least show something when you receive the onComplete signal.

Some facts that I still think are:

• The leader will not be a single class
• The host knows nothing about the Context, but yes with the MyApplication class
• What happens if on the same screen (Fragment) you have different services with different sides in AccessEvents? Just use some action as an identifier to identify them.
• Never make an Activity Snippet implement MvpView, you have to deal with the life cycle.