Enhancement Request

Use Case:

It is possible for an app that is not listed in an app directory to register an intent listener with the DesktopAgent using the addIntentListener function. This means that the app (that is not listed in an app directory) will be included in the app resolver UI when an intent is raised. What is not supported is to specify the contexts that the app supports. This is supported by the app directory and it seems sensible that the same level of detail should be available to apps that register intent listeners rather than relying on the app directory.

Without the ability to specify the supported contexts the user could experience apparently broken applications. If they raise an intent with an unsupported context the app will still be listed in the app resolver UI but when the intent is sent to that app it will not know what to do with it and will either do nothing (which will appear broken) or will throw an error.

A number of different solutions were proposed to fix this during #1577

Propsal One

Implement a breaking change to add a new parameter to the existing function:

addIntentListener(intent: string, contextType: string | null, handler: IntentHandler): Promise<Listener>;

We could optionally support multiple contexts:

addIntentListener(intent: string, contextType: string | string[] | null, handler: IntentHandler): Promise<Listener>;

This would be a breaking change which is undesirable. We could make it a non breaking chagne by adding it as an overload:

addIntentListener(intent: string, handler: IntentHandler): Promise<Listener>;
addIntentListener(intent: string, contextType: string | string[], handler: IntentHandler): Promise<Listener>;

Overloads are fairly easy to handle in a Typescript / Javascript world but in other languages it might not be easy - we need to consider all platforms when making a decision.

Proposal Two

Add an additional function to the Desktop Agent that allows adding an intent listener with a context:

addIntentListenerWithContext(intent: string, contextType: string | string[], handler: IntentHandler): Promise<Listener>;

This allows us to add this functionality as an additive change (not a breaking change) and does not require function overloading.

Proposal Three

Add a new optional parameter at the end of the exisitng function:

addIntentListener(intent: string, handler: IntentHandler, contextType?: string): Promise<Listener>;

I don't think that this parameter order makes as much sense but it would mean we could make the change non-breaking.