Prism: [UWP] How necessary is fine-grained application activation extensibility?

[bartlannoeye]

We're currently looking into changing and extending some of the parts of Prism for UWP. One of the things we're currently not 'complete' is handling all application lifecycle events. Over the last few months, the most used ones were added in multiple PRs, but it's our intention to support them all.

Right now we provide the user to plug his own code into each of the available events (with some of them calling others):

• OnLaunchApplicationAsync
• OnActivateApplicationAsync
• OnResumeApplicationAsync
• OnSuspendingApplicationAsync
• OnActivated
• OnShareTargetActivated
• OnFileActivated

Add in a few more events that we're not handling yet, and things get very complicated to keep track what to implement and what not as an application developer.

The idea is to bring back all activation events to a single method (passing in the eventargs), keeping us with:

• OnStartApplicationAsync (covering all Launch/ActivateXX)
• OnResumeApplicationAsync
• OnSuspendingApplicationAsync

Having the eventargs for activation should be enough to switch on and if necessary to write your code in case of e.g. a file activation. The only thing we did now was calling the placeholder method and then OnActivated, so Prism-wise we're not missing out on anything.

Is this sufficient or do you see a case where you still feel the need for more specialized plug-in methods that you can't handle yourself? (On a sidenote: OnInitializeAsync will most likely stay, as some initialization tasks like IoC have to be done matter what the lifecycle event is).

[brianlagunas]

I prefer the single method approach. Template 10 also discovered this is better and moved away from the individual method approach.

[brianlagunas]

I'm closing this issue since the question has been answered :)

[lock[bot]]

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.