Androwish: when fires <<Terminating>> virtual event

[Harald Oehlmann]

I tried to find out how to get an information when an App is really
terminated.

The doc proposes the virtual event "<<Terminating>>.

I never see it, nor the typicall other ones in wm protocol:

bind . <<Terminating>> {InfoClose Terminating}
wm protocol . WM_SAVE_YOURSELF {InfoClose WM_SAVE_YOURSELF}
wm protocol . WM_DELETE_WINDOW {InfoClose WM_DELETE_WINDOW}

proc InfoClose {Event} {
set h [open [file join $::env(EXTERNAL_FILES) log_$Event.txt] w]
puts $h "InfoClose: $Event"
close $h
sdltk log info "TCL Event $Event"
puts "InfoClose: $Event"
}

Basically, none of the three upper events fire for me.

Test action is to press the Square button and whipe left the application
or press its "X" button in the top of the task view.

Any help appreciated.

Thank you,
Harald

[undro...@gmail.com]

Am Mittwoch, 10. April 2019 12:11:12 UTC+2 schrieb Harald Oehlmann:

Indeed the <<Terminating>> event seems not to get through to the script level. Timing maybe. However, the WM_DELETE_WINDOW can be seen when the window close button is pressed. When you wipe the app away, this seems to immediately terminate, which would require to handle a <<Terminating>> event (but see problem above).

If you need to persist some app state your best option is to handle this in
the <<WillEnterBackground>> virtual event.

HTH,
Christian

[Harald Oehlmann]

Thank you !

So, there is no absolute way to be warned about a termination.

Thanks !
Harald

[Rich]

I think not. It seems that when Android decides to terminate you (as
in the app), it removes the app in a way that is very similar to the
effect of issuing a "kill -9" to a process in Linux. No waiting, no
recourse, no chance to clean anything up, no chance to ignore the
request.

[Harald Oehlmann]

Thank you ! I hope, we get a <<WillEnterBackground>> in any case where
the application is terminated.

Thanks,
Harald

[Rich]

I'm less certian of this one, but I suspect that the answer may be a
reasonable yes here. My reasoning being that in order to receive
"WillEnterBackground" the app must be in the foreground. And I think
Android's "killer" targets backgrounded apps not the one foreground app
(for the obvious user experience reasons).

But I've also seen mentioned that the best cource of action for Android
apps is to assume that termination might be immenent at any moment and
program defensively to that assumption. Which means commit to storage
any user data as soon as the app. receives that data from the user.