The thoroughness of my response was remarked upon so I thought I'd share it here to let everyone know my thoughts.
AFAIK the only guaranteed way of forcing a (confirmation?) message box when leaving an app, via the public SDK, is by overriding the back button. (There may of course be undocumented or private APIs that exist for this though)
Obviously overridding the back button behaviour will only take effect when leaving the app by pressing the back button.
Leaving the app in any other way will cause the application level events to be triggered and these cannot block indefinitely (and actually only have a few seconds to run) as to do so would risk compromising the OS. Imagine for instance if you could throw up a message box when someone left an app for any reason (and cancel the navigation dependent upon the result) this would enable the creation of an app that could prevent the user EVER leaving the app. This would be the equivalent of being able to override the other hardware buttons or stop someone launching another app from system UI (E.g. Toasts, notifications or answering incoming calls)
There may be a few cases such as LOB apps where this may be desirable but it doesn't make sense in terms of a general purpose, consumer focused, mobile operating system.
Typically apps try and force a confirmation on exit to avoid accidentally closing the app. There are a few motivations behind this.
- The company behind the app isn't familiar with the OS and closing apps via the back button and so they assume the users won't be either. - Coding for this just reinforces uncertainty in the system and an inconsistent experience across apps.
- The navigation model within the app is confusing and users aren't always clear where they are in the app and so don't realize they're exiting by pressing back. - This is an IA issue and should be solved with better UX design.
- Users often close accidentally and have to relaunch the app, which is very slow. Confirming closing is faster than restarting the app and so seen as beneficial. - The better solution here would be to improve startup/launch time. This would also help all users of the app and not just those who close the app accidentally.
The other reason I've seen for wanting to confirm application exit is if there is entered but unsaved data. In this scenario it is normally better to automatically save it (login credentials being the usual exception) and then restore it, or ask the user if they want it restored when the user returns to the app. The nature of the data, the app and how they return to it can also have an impact on what is most appropriate here.
Sorry I can't be more explicit but I hope this helps.
If I can help further or you want to discuss specific scenarios, please get in touch.
I quickly uninstall any app that does this all the time. It's just bad design IMHO.
ReplyDeleteYes, I agree. However needy designers might rationalise using this anti-pattern to themselves, it's really only ever about their desire to try and ignore the user's choice to leave their app. People aren't stupid enough to close apps by accident. And apps that try and force people not to close them by using nag dialogs often just get uninstalled by users that have better things to do with their time than repeat clear instructions.
Delete