Android Question App endpoint

LucaMs

Expert
Licensed User
Longtime User
I was writing my question that you can read below the dotted line.

Then "I dropped" the question.

Then came this one:
Is there an app endpoint?
This would be the place to save the app state, when it is terminated voluntarily or by the operating system.

.................................................................................................


"old question"

I still have many doubts (as always) about the entry point of apps

I started to develop an app using B4A 4.30 (centuries ago :().

I thought of not having needs of service modules but at the end this was necessary, so there is a "sticky service" in this app.

From B4A 5.20 there is a new feature, the Starter Service.

My doubts:

If I'm not wrong, the S.O. shouldn't terminate the app process if there is an Activity in foreground.

Now, it seems that "THOSE damned S.O." can terminate an app which is in background; but not only, "they" can restart the app from the last "active Activity"! (the entry point should be the activity declaread as Main-Launcher in the Manifest file, I think).
This seems to be the behaviour for the App Resume, not for the "re-start".

Also, the Service Starter should help in these cases, but it can help holding global variables and their initializations, but what about which Activity will be restarted first?


A sticky service is somewhere between a regular service and a foreground service. Android will kill the process from time to time. However it will recreate it automatically (as soon as possible). For example if you want to track the device location you can use this option. The service (together with the process) will be killed however it will also be recreated again.

So:
I can not prevent operating system to terminate my app (thanks, Android)
I can not know which activity will be RE-started first.

What should I do? Write in each Activity_Resume:
"If the app was restarted by the S.O (but I cannot check it!), do this, else..."
?


What should I do? Go fishing? :mad:
 
Last edited:

LucaMs

Expert
Licensed User
Longtime User
I'll try to read also that thread, Ivan, but:

1) I read the PDFs 2 years ago
2) I suppose (only) that I will not find something about which activity will be restarted after an app is terminated by O.S. and how to check if it was the O.S. to terminate your app.

But I' try.
 
Last edited:
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
LogBook.

I read the first post in that thread and those are things that I know (certainly in the past I have also already read that thread, in this regard).
So, for now, it does not help me about the questions in this thread...

Now I have to read (again but better, I think):
Starting from v5.20 there is a new feature named Starter Service that acts as a single program entry point: https://www.b4x.com/android/forum/threads/starter-service-consistent-single-entry-point.57599/
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
This is my doubt:
The reason for those crashes is that the OS can start the process from a different activity or service. For example if you use StartServiceAt and the OS kills the process while it is in the background.

The process should start only when the Activity I set as Main-Launcher in the Manifest file starts. [Indeed, it is the opposite: when the process is started, this Activity starts].

I have never used services that start at Boot. I suppose that the Manifest will be created taking this into account and that this service will be the "process entry point".

StartServiceAt should be started by an Activity (then when the process is already started), or I'm wrong?
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
Thank you, Erel. I was writing:
StartServiceAt should be started by an Activity (then when the process is already started), or I'm wrong?

You can call StartServiceAt in Sub Service_Start to schedule the next time and create a repeating task (for example a task that checks for updates every couple of minutes).

- Run a service after boot. By setting the #StartAtBoot attribute to True, our service will run after boot is completed.

So I could have a service that starts at boot which can have a StartServiceAt in Sub Service_Start or which can start another service... etc.
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
Well:

I have one Sticky Service and many Activities.

The service is started by the Main Activity, which is the process entry point.

If the O.S. terminates the process, in my case, when the process will start again I can be sure that the Main Activity will start first. Is this right?

Thank you
 
Upvote 0

ivan.tellez

Active Member
Licensed User
Longtime User
If the O.S. terminates the process, in my case, when the process will start again I can be sure that the Main Activity will start first. Is this right?

NO.

To be sure about the entry point use the starter service.

it seems to me that the process will not killed.

In your device, with your current apps. Android will kill the process from yime to time, deppending on lots of things, like the amount of available RAM, running proceses, etc.
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
If the O.S. terminates the process, in my case, when the process will start again I can be sure that the Main Activity will start first. Is this right?

YES, if the OS kill the service, main will be your entry point
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
If the O.S. terminates the process, in my case, when the process will start again I can be sure that the Main Activity will start first. Is this right?
NO.

To be sure about the entry point use the starter service.
YES, if the OS kill the service, main will be your entry point

The reason for those crashes is that the OS can start the process from a different activity or service. For example if you use StartServiceAt and the OS kills the process while it is in the background.

It's all clear :confused::)
I think (or, better, hope) in my case I shouldn't have problems and if the process will start again the Main Activity will start first.
 
Upvote 0

lemonisdead

Well-Known Member
Licensed User
Longtime User
(Another option I did often use before the Starter service is a dedicated code module where Process Globals are declared and inside that module a Sub to check if they are already Initialized and initialize them if not. I did call that sub from each service/activity which could act as an entry point. In my opinion, crossing fingers or hoping that an app won't crash, is not a good option so the Starter service is the way to go even if you fear that people will see you are using B4A :))
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
(Another option I did often use before the Starter service is a dedicated code module where Process Globals are declared and inside that module a Sub to check if they are already Initialized and initialize them if not. I did call that sub from each service/activity which could act as an entry point. In my opinion, crossing fingers or hoping that an app won't crash, is not a good option so the Starter service is the way to go even if you fear that people will see you are using B4A :))

Ok, but I'm not "talking" about process variables, their initializations... I was "afraid" reading that a process could REstart opening first an Activity which is not the one you set as "entry point" in the Manifest file.

But I think that Erel means that this can happen in special cases, such as in his example (StatServiceAt).
 
Upvote 0
Top