Android Question B4A V 8.30 and Android 8+ Services Lifecicle

[Marcos Alves]

Hello,

I have a doubt about life cycle in Android 8+ and B4A 8.3... see:

- Suppose that I have a Http call in a service like the code as follows:

Sub Service_Create

    Dim Job As HttpJob
   
    Job.Initialize("test",Me)
    Job.Download("http://test.com")

End Sub

Sub Service_Start (StartingIntent As Intent)
   
    Sleep(0)
    Service.StopAutomaticForeground 'Call this when the background task completes (if there is one)
   
End Sub

Sub JobDone(Job As HttpJob)
   
    If Job.Success Then
        Log("ok")
    Else
        Log("fail")
    End If
    Job.Release
   
End Sub

I have many questions:

- The StopAutomaticForeground will detect that service has finished and stop it BEFORE the http call back?
- If YES, the service will be restarted automatically and the callback will occur? BUT if the service was destroyed, when started the _Create will run again (If yes, we could have a problem with a double call here no?)
- And finally, considering all these questions, what is the correct way to rewrite a code like this to be compatible with all the versions of Android, including 8?

Please help! I'm really confused with the consequences of the Android 8+ behavior and callback routines in services...

 

[Pooya1]

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

 

[Marcos Alves]

Ok, but

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

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?

 

[Pooya1]

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?

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

 

[Marcos Alves]

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

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?

 

[Erel]

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.

 

[Marcos Alves]

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.

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?

 

[Marcos Alves]

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.

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?

 

[Erel]

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

It is simpler to use wait for.

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

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

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?

Very small.

 

[Marcos Alves]

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.