Section 3.6 of the Store Certification Requirements say this:

Your app must neither programmatically close nor offer UI affordances to close it. Windows 8 Process Lifetime Management closes Windows Store apps automatically.

Obviously, then, your app should haven’t close buttons on its canvas or in the app bar. What’s a little tricky is that an app should also avoid closing itself into anything but the most catastrophic circumstances. That is, if an app has detected that it simply cannot run because of corrupt state or such, then perhaps it can close itself (using MSApp.terminateApp, by the way, not window.close, as the former will give you the opportunity to provide information that will surface in the Windows Store Dashboard).

However, situations like not having network connectivity, or really any external condition from which the app can recover, are not ground for closing the app programmatically. I’ve seen some apps do this that clearly weren’t caught by the certification process: I’ll be running along just fine, then I lose connectivity, and then the app informs me of that with a MessageDialog and then closes itself. Ouch! I just lost whatever state I’d built up in the app, so when I restart I have to get back to where I was. This is a big no-no. In such cases, the app should let me know that I don’t have connectivity, but then give me a way to retry whatever I was doing (that is, an app bar command), when I connectivity has been restored.

In other words, be nice to your users and never assume that you should just up and quit because of some external condition. Again, if you detect an internal condition that would make it impossible for the app to continue running, that’s one thing. But if it’s an external condition that the user can remedy, give them the chance to do that and continue using your app.

I, for one, promise to give poor ratings to apps that I find don’t behave well in this way! 🙂

Comments are closed