From this, you can get hold of the incoming activation arguments. Test the ActivationKind, and if it’s ActivationKind.Launch, then the incoming IActivatedEventArgs will be a LaunchActivatedEventArgs. In your App class, you should handle this by overriding the OnActivated method. For the restart case, the app will be activated as a regular launch – just as if the user had closed the app manually and tapped its tile to launch it again – but including the arbitrary arguments supplied earlier (if any).

There are many different ways to activate an app: in addition to a regular launch activation, apps can choose to support file activation, protocol activation, share or picker activation and so on. If the request is granted, the app is terminated and then restarted. Restarting in the middle of one of those contract operations would certainly confuse the user. For example, you probably should not use it if your app was not originally launched by the user – for example, if it was launched as the result of a share or picker operation. Note that this is the only significant constraint, but you should use this API carefully. You’re unlikely to ever get the other result – unless something goes wrong in the platform. If you were to request a restart and then through some twist of logic managed to request it again before the system started the operation, then you’d get the RestartPending result, although this is an edge case. If the request is denied, the app would need to handle the failure – perhaps by waiting until it is in the foreground and trying again. This is why the API is framed as a request. If we were to permit a background task or minimized app to restart, the result would be unexpected to the user. When the app restarts, it restarts with normal UI – that is, as a normal foreground window. To mitigate privacy concerns, an app is only permitted to restart itself if it is in the foreground at the time it makes the request.

Result = AppRestartFailureReason.RestartPending ||ĭebug.WriteLine('RequestRestartAsync failed: ', result) If (result = AppRestartFailureReason.NotInForeground || In this sample app, we’re expecting the user to type in the name of a city.įoreach (ImageViewModel imageItem in imageListView.Items)Īwait CoreApplication.RequestRestartAsync(payload) You should do this validation on input, before passing it to RequestRestartAsync. If you do choose to accept input in this way, it is your responsibility to validate it correctly to make sure it conforms to whatever constraints you choose to impose. It takes a string parameter, which can be any string value you like – including input from the user or another external entity. The new API, RequestRestartAsync, is exposed as a static method on the CoreApplication object. When the user taps the Request Restart button, the app will terminate and restart itself, passing in the supplied arguments. The app provides a ListView of cities on the left, the currently-selected city on the right and a TextBox for providing arguments to the app when it is restarted.

Windows testview on restart