How to know that the activity is running?

Question

Android

There is an android application that consists of a service and an activity.
The service is running (running) all the time, but the activity can be in 3 states: active on the screen, minimized and closed. So the question is how can the service track this (activity state)?

Answer 1

IMHO this is architecturally wrong. If you really need the service to know about it, it's better to make some kind of intermediary class between the activity and the service.

Answer 2

GavriKos was right about the architecture. And the intermediary class he mentioned is called ServiceConnection - it is used when binding an activity to a service. Context.bindService()/unbindService().
Also, "The service is running (running) all the time" is a highly debatable statement, not sure if you can ensure it's true.
If you describe the problem in more detail, you will be advised the correct solution.

Answer 3

State propagation is a typical problem with multitasking, whether it be multitasking in the OS, client-server or something else, fortunately it does not occur often, since the OS and application tools do a lot for us, but sooner or later it occurs in the next project, in one form or another.
Analytical thinking is needed here, but not simple, but with chronology in time and branching, one might say "analytical algorithmic".
It is possible that someone has developed more from birth, someone has less, but it is still necessary to develop it in any case, and in any case it is possible if you practice.
I will not give a ready-made solution to your problem, but I will describe how to solve such problems, I will try to show exactly on the example of Android and on yours, I have already solved them successfully, which means that if you focus on the plan I propose, then in the end decide and this one and another.
To begin with, you need to answer exactly these questions, that is, study the lifecycle for the Activity and for the Service.
This is done even without reading the documentation and source code, just simple experiments are carried out: the onCreate, onDestroy methods are overlapped and logging is put on them, then you do different actions (first of all, you need to look in the settings for what the user can manually complete separately from the rest, I will say so - Service is possible, Activity is not ), the onCreate, onDestroy methods themselves are not static, which means they are called in some instance, but it’s easy to figure out how to check whether this is the same instance or if a new one is created.
This can be called "analysis of the Android algorithm", the one in the Android API.
The next stage is "synthesis of different variants of our algorithm and their analysis", you need to imagine two coordinate lines in time - Service and Activity, and "scroll" all possible options in your head.
For example, you might have this idea:
1) Create a BroadcastReceiver in a Service.
2) Then from Service we start Activity.
3) It sends sendBroadcast at startup, and at the end too.
4) Service receives it and learns the state of the Activity.
Seems like the right idea.
But we know that the Service can be completed separately from the Activity and restarted, and Android will not notify the Activity in any way, which means that the following option is possible:
1) Create a BroadcastReceiver in the Service. It knows by default that the Activity is not running, and that's true ..
2) Then from Service we start Activity.
3) When it starts, it sends sendBroadcast(started), the previously launched receiver receives it, the result is that the Service knows that the Activity is running, and this is true .
4) But then the Service ends separately, which means the BroadcastReceiver too, then a new Service is started, but the Activity is not restarted and therefore it does not send a new sendBroadcast(started), and the second Service knows again by default that the Activity is not running, and now this is a lie , because it is still running from the first time.
I also recommend that you analyze your version with Preferences, if it does not contain such "bugs", then this is already good, despite the clumsiness. :)
Although not that clumsy, UNIX itself stores a lot in files, so what.
But such an analysis is more useful than just finding a ready-made solution in Android and hoping that you did everything right and that it will work (well, if that's the case at all).

Answer 4

I was looking for information on a similar problem, came across this question and a possible solution on stackoverflow with code example. I leave the link here , let it be in one place, maybe it will be useful to someone ...