IntentService or what is the best way to separate logic and UI?

Question

Android

Greetings.
Now I am considering and trying to bring out a more sane pattern for separating the service, logic and UI + bridges (callbacks) between them.
I wanted to consult, what do you think about such a pattern or what can be improved?
1. The logic handler is displayed in the IntentService
2. In onHandleIntent we call / create the necessary objects or functions for processing the intent
3. The result of processing goes to the Bundle
4. The incoming intent in onHandleIntent always (well, almost) has a receiver: ResultReceiver
5. At the end of processing say receiver.send = RESULT_CODE with the processing result (Bundle)
The IntentService is started by registering a special action (somewhere a constant in the form of a String) in AndroidManifest.xml and calling startService code elsewhere ( our action + Intent with request data + ResultReceiver optional )
Of course, the question is what happens if Pause/Resume on Activity. Here you need something like register / unregister callback. Yesterday I was at Google, they just suggested there, to create a static list of listeners, well, in general, to implement the observer pattern, but I don’t really want to be tied to the service class.
In general, something like this, I hope for advice and tips. I have already tried a lot, which is scary, because there must be some good way, and not every time to invent something new. Thank you.
UPD:
Found that you can use the UI thread Handler as a bridge between the entire Messages queue. Actually, creating a Handler in the main thread is not a problem, and then just send a Message and that Handler with Handler.Callback, which will process the message, and there will be a callback. But still I think.

Answer 1

Judging by the description, you need an Observer. You can look at signal slots in Qt (just one of the implementations of the Observer plugin).

Answer 2

Dude, I went through this too. I wanted the logic to be behind some kind of facade, and the classes that implement it existed throughout the entire operation of the application. And the activities clung to them as they were created. The approach did not justify itself, since singletons are evil, and data transfer from the service is carried out through a Bundle, which introduces some restrictions. And if you pass a ResponseHandler to the Bundle, then singletons multiply ...
Therefore, I now use a kind of MVP for complex projects, where View is xml + activity with minimal code, and Presenter and Model are already created in the activity. in the presenter logic, and in the model - access to data - services and content providers. There is no facade as such.

Answer 3

habrahabr.ru/post/144275/