WindowsAppSDK
WindowsAppSDK copied to clipboard
Support custom metadata field for optional packages (and possibly other type of packages)
Proposal: Support custom metadata field for optional packages (and possibly other type of packages)
Summary
Allow main package to selectively load optional packages by querying exposed custom metadata as available in app extensions, without the need to load the code from optional packages. This would immensely help apps with plugin architecture.
Rationale
- Application with plugin architecture currently have to expose interfaces to decide if the optional package implements certain services to be used by main application, which is slow and possibly ends up keeping the code in memory for long time.
- Custom metadata helps avoid loading the code.
- By keeping the mechanism of defining custom metadata same as app extension, developer are less burdened.
Scope
Capability | Priority |
---|---|
Allow optional packages to define custom meta data in a manner similar to app extensions | Must |
Important Notes
Example shared in the #81
We are creating an application that is divided into a main app and lots and lots of plugins. We would like to load plugins on demand when we connect a hardware device, detected by the main app. Main application queries the meta data of the hardware and invokes/load the appropriate plugin assembly matching the meta data (things like make of hardware, year manufactured, product code, firmware id, etc).
The plugins are currently optional packages (we can't use app extensions because plugins also have UI component and communication between main app and plugins in non-trivial). We would only like to load the plugin assembly when required, i.e. when the meta data matches. Currently we are using a json file to store the meta data per optional package, this require some boilerplate code and other things to ensure we always package the json file with the plugins.
It seems that the Extension provide the same functionality as we require, however within the manifest as you have described above. If we can get a similar option to define custom properties in the optional package, it would help everyone save writing some code and do testing.