Revisiting an old post - Application.Terminate

Revisiting an old post - Application.Terminate

Rate This
  • Comments 3

Well, I already did that once today, but in doing so I realized I should address another old post (or two).

Yes, in Windows Phone 8 we have added the Application.Terminate method so that you can quickly exit your application in the case of insurmountable roadblocks such as the user refusing to accept the EULA or not signing into their account. As noted in the docs though, this is not a "clean" shutdown (you will not receive any navigation events nor any lifecycle events) so if you have any state to save, you need to save it first.

The guidance from the previous two posts still stands -- in general you should not need an "Exit" button in your app, nor should you normally need to terminate yourself -- but in the cases where you really really really need to, now you have a better option than just crashing.

  • The approach to dealing with pages that aren't places is not elegant. Putting a login page into a popup makes sense for sure, but it turns the app into a dog's dinner. The big impact is on either the user experience, or on the application bar.

    Specifically, the easy option is to make the login button a button control and tack that onto the end of a StackPanel that contains the UID and PWD text boxes. The problem with this is that the SIP covers the login button when entering a UID/PWD. The British Airways app is a good example of this. It's frustrating for the user.

    The harder option is to use the application bar for the login button. This means that every page's OnNavigateTo() does a check for Subject.IsAuthenticated(), and then butchers a pork chop into a beef steak, depending on whether the user is authenticated or not.

    It's not pretty, and Application.Terminate does little to mitigate the mess.

  • Michael - that kind of scenario is better served by the back-stack manipulation APIs. blogs.msdn.com/.../back-means-back-not-forwards-not-sideways-but-back.aspx

  • Hey Peter, thanks for the tip. That was my original approach, but is similarly fraught with IEDs and landmines. I guess I'm making life difficult for myself - my app won't work at all without an authN being done first. This means that users need access to the privacy policy, T&Cs and recourse if things go wrong (support/FAQ) before (and after) logging in.

    I tried bundling all these things into a single About page, but then had to manage the back stack in the same way that my popup approach manages the application bar - two logical back stacks. One for the unauthenticated login/about journey, and another for the authenticated journey.

    Maybe I'm trying too hard for a perfect experience, but there are sooo many apps in the store that, while useful, are deleted from my phone because their UI is so... obtuse.

    I've already blown 8 days on this, so hack or not, I'm going to see the popup approach through. It's looking promising. That said, you've pointed me at a resource I've not seen before (thank you) and I will revisit this when I'm feature complete or up against the wall.

    Thanks again.

Page 1 of 1 (3 items)