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?
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?
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?
Last edited: