[TIMOB-3036] exitOnClose is a world of confusion and mystery
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Low |
| Status | Closed |
| Resolution | Invalid |
| Resolution Date | 2017-07-10T22:36:46.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android |
| Labels | android, exitonclose |
| Reporter | Shish |
| Assignee | Ingo Muschenetz |
| Created | 2011-04-15T03:35:13.000+0000 |
| Updated | 2017-07-10T22:36:46.000+0000 |
Description
Having spent the last two weeks working on my first app, the one thing that seems to have caused more than half my troubles is exitOnClose. Not sure what can be done about it, but some things that I've noticed:
- exitOnClose doesn't exit the app on close, it just destroys all the event handlers, cancels all in-progress XHRs, and makes the app stop responding. It only exits if the closing window is the last window in the app. It's because of the not-actually-exiting behaviour that I spent so long being confused, not realising that exitOnClose was the source of my problems.
- tabGroups have exitOnClose=true by default. Not only is this confusing on its own (no other widget has it set), it also means that when combined with the above, having a login screen followed by a tabgroup, if you hit "back" to get back to the login screen, everything dies because the tabgroup tried to "exit". Again, this took a couple of days of banging my head on the desk before realising that a seemingly innocent operation (closing a tabgroup) was doing something I didn't ask for ("exiting" the app), and breaking everything in a way that made no sense (leaving the GUI functioning but with no events firing)
- close as in "user is on the login screen and hits the back button" and close as in "user logs in, moves to the main screen, the login screen is no longer needed and can be close()d" both trigger the behaviour. This makes it impractical to have a login screen which exits the app if closed with the back button, and does not exit the app when closed via close()
- during some experiments with modal windows, I somehow even managed to close an exitOnClose window, and my app closed but the widgets were still there, floating above my android desktop, god knows what happened there...
So in summary, please please please make exitOnClose exit the app when the window is closed, now matter how unclean the shutdown process. Having it half-exit, half-break the app in weird ways causes lots of pain when debugging seemingly unrelated functions.
Looks to be an Android-specific property.
This ticket does not follow the guidelines laid out in http://wiki.appcelerator.org/display/guides/Contributing+to+Titanium#ContributingtoTitanium-SubmittingBugReports"> Submitting Bug Reports. Even so, the "issue" is user and app design-specific rather than a Titanium issue. Propose that it be closed as invalid.
My apologies for being somewhat rambling in the initial report; I'm still pretty sure that "exitOnClose does not cause the app to exit when closed" is a titanium issue though
This flag was added for ONE explicit reason. For the cases where the Activity immediately above the splashscreen exits back to the splashscreen activity.
But it's set to true by default for tabGroups, so if you have a group that doesn't exit back to the splash screen (ie, there's a log-in screen in between), closing it triggers an unexpected undocumented "exit", and because it doesn't actually exit, the app ends up in a confusing zombie state.
For going back to the splash, it doesn't matter whether the app exits or zombifies. For going back to a login screen, zombifying is bad, exiting fully is good. Thus, if we want to support both cases, exiting fully is better. If we don't want to support the latter case, then it shouldn't be the default (It isn't even documented that it's true by default, so even after reading the manual, the behaviour is still unexpected).
My personal preference would be to make it work in both cases, and I don't see any downside to it working in both -- but if you really want it to only work in one case, please at least document the behaviour so developers know how to avoid it in the other.
Closing ticket due to time passed and lack of progress for a number of years. Please open a new ticket if there are any problems.