Support custom metadata field for optional packages (and possibly other type of packages)

[harvinders]

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.

Open Questions

[stevewri]

@DrusTheAxe - is this in your area?

[DrusTheAxe]

Allow optional packages to define custom meta data in a manner similar to app extensions

One solution is to support a package-scope equivalent to <Extension Category="windows.appExtension"> and all that implies

1. Add support for package-scope manifested data, e.g.

   <Package>
   <Extensions>
       <Extension Category="windows.packageExtension"...>

2. Add APIs equivalent to Windows.ApplicationModel.AppExtensions and AppExtensionCatalog. Functionally the API could be similar (nigh identical?) except...

a. AppExtension.GetExtensionPropertiesAsync returns the package-scope <Extension>'s data rather than a per-app's <Extension> data.

b. Remove .AppInfo

Otherwise you could rename AppExtension[[Catalog]] to PackageExtension[[Catalog]] and get the desired result.

@harvinders would that satisfy the proposal?

[harvinders]

@DrusTheAxe. Yes, it would satisfy the need. Just wanted to understand why do you propose to remove AppInfo? seems like useful information to allow the main app to enquire.

[DrusTheAxe]

@harvinders sorry I overlooked your message. Let's fix that...

why do you propose to remove AppInfo?

Because package != application

A Package contains 0-100 applications so we need to get 'the list of apps', not 'the app'.

The obvious answer is to replace .AppInfo with .Package. But lo' and behold, AppExtension already has a .Package property!

Given a Package object you can get the list of apps it provides so today given AppExtension we can...

appextension.AppInfo
appextension.Package
FOREACH ale IN appextension.Package.GetAppListEntries()
    appinfo = ale.AppInfo

We can have the equivalent model with a PackageExtension object

packageextension.Package
FOREACH ale IN packageextension.Package.GetAppListEntries()
    appinfo = ale.AppInfo