Android Question resumable sub and Sleep vs. app pause/resume?

[Dave O]

How does a resumable sub using Sleep interact with the activity pausing and resuming?

For example, I'm working on a poker app that uses sleep(250) to pause between each player's bet. Works great while the app is running.

However, if I switch out of my app while it's stepping through the players, then return to the app, the sub doesn't appear to resume.

(If I was using the old method of timers, I would pause/resume the timer when my app was paused/resumed.)

Thanks!

 

[Erel]

If the activity was not destroyed then the sleep will be resumed when the activity is resumed. If the activity was destroyed then it will not be resumed.

Example

Sub Activity_Click
   Log("cs click")
   Sleep(1000)
   Log("after")
End Sub

cs click
after
cs click <-- click on the home button
** Activity (main) Pause, UserClosed = false **
sending message to waiting queue (sleep)
running waiting messages (1)
after <-- resumed
** Activity (main) Resume **
cs click
after
cs click <------- click on the back key
** Activity (main) Pause, UserClosed = true **
sending message to waiting queue (sleep)
** Activity (main) Create, isFirst = false **
running waiting messages (1)
Sleep not resumed (context destroyed): anywheresoftware.b4a.shell.DebugResumableSub$RemoteResumableSub <--- not resumed
** Activity (main) Resume **

 

[ilan]

If the activity was not destroyed then the sleep will be resumed when the activity is resumed. If the activity was destroyed then it will not be resumed.

Example

Sub Activity_Click
   Log("cs click")
   Sleep(1000)
   Log("after")
End Sub

cs click
after
cs click <-- click on the home button
** Activity (main) Pause, UserClosed = false **
sending message to waiting queue (sleep)
running waiting messages (1)
after <-- resumed
** Activity (main) Resume **
cs click
after
cs click <------- click on the back key
** Activity (main) Pause, UserClosed = true **
sending message to waiting queue (sleep)
** Activity (main) Create, isFirst = false **
running waiting messages (1)
Sleep not resumed (context destroyed): anywheresoftware.b4a.shell.DebugResumableSub$RemoteResumableSub <--- not resumed
** Activity (main) Resume **

Would it be the same with a timer?

I assume yes right? If activity was destroyed the timer will be initialize again on app start and the tick event will start if you call it. So the difference is that if you enable the timer on app create it will be working even if app was destroyed but with the sleep function it will not.

I guess he could solve it by creating a file on app pause and when he return he can check if file exist then sleep() again

(Would be nice to take a sleep now. It is cold outside )

 

[Erel]

No. A Timer should be a process_global variable. It will continue to tick when the activity is recreated.

Note that this sleep behavior is intentional as in most cases you do not want the previous code to run if the activity was destroyed.

 

[ilan]

No. A Timer should be a process_global variable. It will continue to tick when the activity is recreated.

Note that this sleep behavior is intentional as in most cases you do not want the previous code to run if the activity was destroyed.

How can that be? If the app was destroyed everything should be again initialized or am i wrong?

Firstime should also be true,right?

 

[ilan]

Destroy i mean like calling "ExitApplication" or closing all apps that run in background. How can a process_global variable still be active?

 

[LucaMs]

activity was destroyed

If the app was destroyed

 

[ilan]

Thats the same luca

 

[LucaMs]

Thats the same luca

No. You can "destroy" an Activity (using Activity.Finish) but the process (app) is still alive.

 

[udg]

How can that be?

Oversimplifying, I would say that Activities run in a process and that the process is generally still alive when you exit your last activity. If you launch again your app soon after you closed it, FirstTime will be False.

 

[ilan]

No. You can "destroy" an Activity (using Activity.Finish) but the process (app) is still alive.

Oversimplifying, I would say that Activities run in a process and that the process is generally still alive when you exit your last activity. If you launch again your app soon after you closed it, FirstTime will be False.

There is a misunderstanding.

Destroy mean apllication is gone.

Activity.finish send activity to background.

If we talk about destroy that means (at least in my poor english) activity (or process or app, call it how you want) was destroyed and removed from background. There is a big difference if you call activity finish or click the home button. Both will send your avtivity to background but Mr.dave used the word "destroy" and not pause or finish!

 

[LucaMs]

Activity.finish send activity to background.

Wrong. Activity.Finish destroyes the Activity. An Activity in background (when you start a different activity or Home is pressed) "restarts" from Activity_Resume; an Activity destroyed restarts from Activity_Create.

 

[LucaMs]

mr.dave used the word "destroy"

if I switch out of my app

"switch out" is not so clear, to me .

However, if using a timer everything works fine, why create problems instead of using it?

 

[ilan]

Wrong. Activity.Finish destroyes the Activity. An Activity in background (when you start a different activity or Home is pressed) "restarts" from Activity_Resume; an Activity destroyed restarts from Activity_Create.

No thatis not true.

Activity finish or back key will not destroy (kill) your activity they willsend it to background to the activity stack and resuming will call activity create with firsttime false!!!!

Homebutton is a different story.
It is correct that it will return on activity resume without creating again the acitivitybut you cannot define back key or activity.finish as "destroy" for me destroy means kill.

I guess we all are right but the difference is how we define the word "destroy"

For me it means like kill.

See this: https://developer.android.com/reference/android/app/Activity.html

 

[ilan]

Ooops sorry erel used the word destroy
I need a coffee

 

[LucaMs]

Yes, destroy, kill, terminate... but the important question is whether you are killing an activity or the process. This is the fulcrum in Erel's answer.

No thatis not true.

I was pointing out this statement of yours (even if I understood that you know the difference well):

Activity.finish send activity to background

because activity.finish "kills-destroyes" the activity, not just send it in background.

 

[Dave O]

The most common situtations I'm thinking about are when the user switches to another app (e.g. an message notification that needs a reply) and then switches back to my app. So it's probable that my app is still in the background (not destroyed).

I understand Erel's code example showing the difference between background and destroy, but I'm still seeing my resumable sub not resume when I switch out and back into my app. I think I need to experiment with it more (probably with a simple example app) to really understand what's happening.

 

[ilan]

The most common situtations I'm thinking about are when the user switches to another app (e.g. an message notification that needs a reply) and then switches back to my app. So it's probable that my app is still in the background (not destroyed).

I understand Erel's code example showing the difference between background and destroy, but I'm still seeing my resumable sub not resume when I switch out and back into my app. I think I need to experiment with it more (probably with a simple example app) to really understand what's happening.

Use a timer and problem solved

 

[LucaMs]

Use a timer and problem solved

However, if using a timer everything works fine, why create problems instead of using it?

(from THE other thread )

nobody forbids you to use timers again in situations like these

 

[Dave O]

If I can use Sleep(), that gives me a more elegant solution than a timer does (and makes it easier to follow the program flow when I revisit the code later).

But if Sleep doesn't work out, it's back to a timer, agreed.