Simple activatable activation type for custom args.

[dhoehna]

App Lifecycle allows multi-instancing via RedirectToActivationAsync in AppLifecycle. RedirectToActivationAsync requires AppActivationArgs which is the same object passed into the app during activation and allows apps to pass along the arguments to the new instance.

This is inflexible because apps can't communicate "why" activation was redirected.

For example, redirecting to a "Safe Mode" instance. The first instance could redirect to a new instance and use custom args to pass "SafeMode". The new instance could act on "SafeMode" and set itself up for running differently.

Here are two possible solutions.

1. Add a simple activation type that developers could construct to allow for custom arguments that inherits from AppActivationArgs.
2. Overload RedirectToActivationAsync to accept a string.

I like option 1 because AppInstancing code won't need any changes. Additionally this will help tests. Tests could activate an app with custom args to stress different code paths in the activated app.

The two proposed solutions are in no way a definite solution. I put down the propositions as a starting point for discussion. The scope of of the solution can expand or contract as needed. Further discussion is encouraged to find the best-of-all-world solutions.

EDIT: Added a blurb explaining the reasoning behind the proposed solutions.

[aeloros]

One other possible solution could be to just change the current properties AppActivationArgs to support being settable, and add a new ExtendedActivationKind either 'Custom' or 'UserDefined'. Currently these are readonly. We designed this specifically to be IInspectable rather than strongly typed or as IActivatedEventArgs, so that it could be more open ended.

With this solution the developer could embed the original args as a property on any object they wish. They would just be responsible for handling their custom type on the receiving end.

This is just brainstorming, and I'm sure there would be all sorts of investigation needed for any solution to be fleshed out. For instance, how do these solutions work WRT the deserialization of the IActivatedEventArgs?

Another possibility would be to say the arguments passed in are immutable, but instead provide a new field on AppActivationArgs that is settable. This would be an 'ExtendedData' field that could be developer defined. The drawbacks here are that if developers don't know how to ensure things are value marshaled, then they will have cross process lifetime issues. The redirecting process will likely exit very quickly, leaving a dead proxy object which will cause the new process to crash.

Lot's of things to think of here...

[YexuanXiao]

Is there any progress on this? I think custom kind should be allowed first, so that it can at least work with simplicity.