Backing out of a UWP mobile app quits the apps instead of suspending

[haroldma-zz]

Package info

• Platform: Mobile
• Prism version: 6.1.1
• Windows 10 SDK version (if applicable): 10586

Repro steps

Open an app with Prism, click the back button.

Expected: The app is suspended and can be resumed by opening it.
Actual: The app is shut down completely. Opening it starts it from scratch.

[kyse]

Not sure if this is related so forgive me if this looks like a hijack, but I noticed in my xamarin forms app, when trying out things on my android phone in debug mode, if I start up the app, and hit the back button from the main page (navigating on initiailization to masterdetailpage/navpage/mainpage), I get a message saying the app has stopped. When opening the app again, I get the splash screen, ie the app closed instead of suspending. In the process of trying a few things like using IConfirmNavigation CanNavigate returning false on the master and nav pages, but this probably isnt the solution.

[briannoyes]

@kyse Prism for XF has a completely different implementation of the nav stack based on the platform nav, so probably unrelated to this one.

[bartlannoeye]

We should see what the guidance in Windows 10 is, it's not so strict anymore as it was in Windows 8/8.1.

[JerryNixon]

Maybe I can help

Windows Phone 8

Windows.Phone.UI.Input.HardwareButtons.BackPressed

The platform assumed your application had only one frame and would auto-wire up the BackPressed button to back navigation. When the BackStack was empty, the application would terminate. Manually handling BackPressed and setting e.Handled to true would prevent this behavior, but it would also prevent an app from certification in the Windows Phone Marketplace.

Windows Phone 8.1

System.Windows.Navigation.NavigationService.PauseOnBack

Behavior varied if you wrote a Silverlight app or a Universal app. Silverlight apps continued to behave like Windows Phone 8. Universal apps also behaved like Windows 8 apps, except for the optional PauseOnBack property that, when set to true, when the BackStack was empty, the application would suspend instead of terminate. It was opt-in and the default was false.

Windows 10 Mobile on Phone

Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested

UWP requires the developer to handle the back button. There is no auto-wire up for any frame, as the platform makes no assumptions about the app. If BackRequested is not handled, and e.Handled is not set to true the platform will Suspend the app and auto-navigate to the next app. In addition, apps running on the desktop are Suspended when they are minimized.

ExtendedExecutionSession

Windows.ApplicationModel.ExtendedExecution.ExtendedExecutionSession

With Windows 10 1511 (November Update/Threshold 2/10586) the platform introduced extended the ExtendedExecutionSession which allowed developers to manipulate Suspension behavior. This provided for real time location apps, and extra time during suspension (using SaveData). In Windows 10 1707 (Anniversary Update/Redstone 1/14393) the platform enabled the Unspecified extended type which would prevent an application from Suspending when minimized or swapped by BackRequested's behavior.

Template 10

https://github.com/Windows-XAML/Template10/tree/master/Template10%20(Library)/Services/ExtendedSessionService

In Template 10, we automatically enter every app into an Unspecified extended session when it is launched and automatically request a SaveDate session when it is suspended. This provides a far more WPF-like life-cycle to an app. More importantly, this does not short circuit the nature of UWP since extended session still takes into account user behavior and system resources based on internal heuristics the developer cannot manipulate.

And that's how it works.

[bartlannoeye]

Thanks for the info @JerryNixon. I'll try to have a look at this during the final week of the year.

[brianlagunas]

Closing as Prism for UWP is no longer applicatible to the current version of Windows. We are aligning with Template 10.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.