Android Question B4A V 8.30 and Android 8+ Services Lifecicle

You have to use
Sleep(0)
Service.StopAutomaticForeground
After complete job

Ok, but

Pooya1 said:

You have to use
Sleep(0)
Service.StopAutomaticForeground
After complete job

Click to expand...

Ok but @Erel recomended to put sleep (0) and Service.StopAutomaticForeground in Start service section which would automatically detect the job completion and stop the service. The question is: Service.StopAutomaticForeground will detect that the service is waiting for a jobdone callback or will stop it before and cause a new Service_Create event when JobDone is called?

Marcos Alves said:

Ok, but

Ok but @Erel recomended to put sleep (0) and Service.StopAutomaticForeground in Start service section which would automatically detect the job completion and stop the service. The question is: Service.StopAutomaticForeground will detect that the service is waiting for a jobdone callback or will stop it before and cause a new Service_Create event when JobDone is called?

Click to expand...

No Service.StopAutomaticForeground say to android that app's service is complete and stop foreground service
Sleep is short interrupt for force Service.StopAutomaticForeground and it is good use it

Pooya1 said:

No Service.StopAutomaticForeground say to android that app's service is complete and stop foreground service
Sleep is short interrupt for force Service.StopAutomaticForeground and it is good use it

Click to expand...

Ok, Sleep(0) pauses the service... and allows a call for a sub in service to start, registering that the service hasn't finished yet. If you call StopAutomaticForeground before sleep(0) maybe there is no chance to run a sub called by an intent , push service or callsubdelayed, before the service be stopped.
But the doubt about http service remains.. remember that httpjob runs in other thread. then, for main thread of app when a service calls httpjob it's done and finished... that's because the jobdone callback runs the Service_Start again... but if StopAutomaticForeground doesn't detect that httpjob is still running in other thread, we could have one of the behaviors:

1. Service is destroyed after StopAutomaticForeground and is created again by httpjob callback... this isn't good because if the routine that calls httpjob is in the create section, we will have an eternal and dangerous loop...

or

2. When http job callback raises, it's generated an error because the service is destroyed and the jobdone routine doesn't run....

The only reasonable situation is to detect that the service is still waiting for jobdone and remains running until finish the jobdone routine... of course that to do this StopAutomaticForeground must to detect that there is an external call being waited for a service subroutine and only stops the service after the callback target routine runs (when working with multi threaded systems we use to do this with semaphores and flags...) .
The question: is this behavior implemented in StopAutomaticForegorund call?

Automatic foreground mode is not relevant here. A service enters automatic foreground mode when the app is in the background and the service is started from a receiver. Examples: calling StartServiceAt, start at boot or push notifications.

You should never have a JobDone sub. You need to learn to use Wait For instead.

If you want to make sure that the service is not being destroyed until the request completes then you need to call Service.StartForeground before the request and stop it after the request.
Another option is to move the call to the starter service (or a class initialized from the starter service) which is never destroyed unless the process is destroyed.

Erel said:

Automatic foreground mode is not relevant here. A service enters automatic foreground mode when the app is in the background and the service is started from a receiver. Examples: calling StartServiceAt, start at boot or push notifications.

You should never have a JobDone sub. You need to learn to use Wait For instead.

If you want to make sure that the service is not being destroyed until the request completes then you need to call Service.StartForeground before the request and stop it after the request.
Another option is to move the call to the starter service (or a class initialized from the starter service) which is never destroyed unless the process is destroyed.

Click to expand...

You mean that it's safer to change all calls those use JobDone in services by wait for ? I'm already using waitfor clauses for requesting authorizations at runtime but wasn't thinking to change legacy services codes those are using JobDone... If an http service spends no more than 5 seconds to do the callback, what is the chance to have the sercice killed by os?

Erel said:

Automatic foreground mode is not relevant here. A service enters automatic foreground mode when the app is in the background and the service is started from a receiver. Examples: calling StartServiceAt, start at boot or push notifications.

You should never have a JobDone sub. You need to learn to use Wait For instead.

If you want to make sure that the service is not being destroyed until the request completes then you need to call Service.StartForeground before the request and stop it after the request.
Another option is to move the call to the starter service (or a class initialized from the starter service) which is never destroyed unless the process is destroyed.

Click to expand...

By the way... What happens If a service is called again when it's still paused by a waitfor clause? The startservice call will be queued until the sub finishes after the waitfor?

Marcos Alves said:

You mean that it's safer to change all calls those use JobDone in services by wait for ?

Click to expand...

It is simpler to use wait for.

Marcos Alves said:

By the way... What happens If a service is called again when it's still paused by a waitfor clause?

Click to expand...

The service is not paused when it is waiting for an event.

Marcos Alves said:

If an http service spends no more than 5 seconds to do the callback, what is the chance to have the sercice killed by os?

Click to expand...

Very small.

Thanks @Erel ... I'll pay attention to your comments to consider changing to waitfor... I have an app with more than 10 services constructed over the JobDone logic (because JobDone was the only resource that existed in the past...) ... I know that waitfor is simpler to implement but change this quantity of services and its logic will not be simple ...

Again, thanks for your answers! You're always present ! Your job and the assurance you are always maintaining and giving feedback for the community is what makes B4X the best framework in the world.