Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The general recommendation is that apps do <em>not</em> provide their own close affordances. In your example, closing automatically in response to a loss of network connectivity will appear as if the app crashes under such conditions. As such, it may not actually pass Windows Store certification on that point along (see <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx" rel="nofollow">requirements</a>, section 3.2 about apps that end unexpectedly). Furthermore, section 3.6 prohibits apps closing themselves as already noted, so you'll fail on that as well.</p> <p>Calling window.close will generate a crash report that appears within the Windows Store dashboard, and will be logged as an app crash, in fact (this may end up counting against the app in the Store--not sure about that, but I wouldn't risk it). In this case, it's better to use MSApp.terminateApp because the crash report will be much more comprehensive (and you can include your own info). Still, MSApp.terminateApp should only be used for truly unrecoverable conditions.</p> <p>If you have a condition under which the app can't continue to run effectively, but isn't a crash, per se, like the loss of network connectivity, it's better to inform the user of that condition and let them decide whether to close the app (through Alt +F4 or the top-down swipe close gesture) in response. You should also detect when network connectivity has been restored and continue, of source. This way the app hasn't lost its state and can continue where it left off, thereby providing a contiguous user experience.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload