App Extensibility: Build an Ecosystem of Apps

Play App Extensibility: Build an Ecosystem of Apps

The Discussion

  • User profile image

    its great you finally address the problem of inter-process-communication. i just cant really appreciate the "awesomeness" of all of that as i know all this was already possible since 1997 with COM in a MUCH easier and elegant object-oriented manner. even plain old vb6 applications could do exactly that in just 2 lines of code with every com-enabled component like word,excel,powerpoint,hundreds of COM-libraries and other com-applications ....even the much older "object linking and embedding" was a ton more powerfull than what we have here today.from a technological perspective we really have turned back the clock to around 1996 with those mechanisms we have now for Apps. its better than nothing, but really not much better...sadly.

  • User profile image

    While this is great news, I think that extensions should be different from apps when it comes to managing them from the Settings UI. If there are only a few extensions it's not a problem, but if things really get componentized thanks to extensions, the list will explode and become cluttered, and it will be hard to recognize what's an app and what's an extension. There should be a separate list for extensions, maybe even ordered by categories (like "media extensions", "social extensions", etc.)

    Another question is: Will there be a mechanism for deferred loading of extensions? It would be great if, for example (to go with the demo), the binaries of the extension that enables grayscale won't be loaded into memory until its functionality is required (by clicking the button). That would keep the memory footprint low at startup time. Right now it looks like as soon as you enable an extension, its getting loaded into memory even if it is not going to be used.


  • User profile image

    Love the extensibility changes!! Not sure where to ask this or whether to ask at B817 but given the changes in triggers and background tasks just wondering how those changes will (if at all) apply to AppServices? In particular around the Single Process model and extended execution changes.

    1.. Unless I'm mistaken, currently to communicate between the Appservice process and host. The host needs to itself use an AppServiceConnection as they are separate processes. The Single process model we'll be able to use for trigger based background tasks would remove this restriction. Is this coming to AppServices as well?

    2.. Do all task instances (AppServiceConnections) for an AppService run within the same process?

    3.. AppServiceConnections currently have the same resource restrictions as trigger based backgroundtasks. ie 25 sec CPU time etc. Any changes as discussed in B817 coming to AppServiceConnection?

    Also no discussion in this talk on headless AppServices? Does that mean we won't be seeing this anytime soon?


  • User profile image

    I would love to see some more information on App Extensions! The msdn docs for AppExtension only show some methods for getting a PropertySet from the extension, and for accessing the shared public folder. But the main purpose of an extension is to provide functionality, right? So can we request a service interface from the extension and call methods on it? Does the extension run in-process?

  • User profile image

    @sevenacids: It depends on how you implement the extension. If you are loading content (script) from the public folder, then that depends on when you decide to "load" the content. In our example we loaded content when the extension was discovered. A better way would be to load the extension when it is used the first time, though that creates a performance tradeoff as it may cause a load delay. If you use App Services then the service background task is created as it is needed, so you only need to maintain the connection information / AppExtension object. We recommend using App Services for a lot of reasons described in the session.


  • User profile image
    Iuri Farenzena

    Will this Extensibility API be available on Windows 10 IoT Core?

  • User profile image
    Sibar Soumi

    You are using the LunchUriForResultsAsync method to call the Windows Photos app using the uri "" to have a photo cropped. Meanwhile, you are passing some parameters and receiving some results back.

    How did you know the input/output parameters that Windows Photos work with? Is there any kind of doc/reference to look these parameters up?

    It is not only about this specific app and this specific protocol, but in general many apps declare the property ReturnResults in their manifests as "always" or "optional", such as:


    This means, these apps are able to respond when called by other ones using LaunchUriForResultsAsync. But I could not find anywhere any kind of docs to the used parameters!

  • User profile image
    @Sibar Soumi:
    They know because they built the apps. There's no documentation but you can see all the supported protocols for your self from Settings->Apps->Default apps->Select apps by uri.
  • User profile image


  • User profile image
    Does this mean we can call Win32 APIs in the extensions?

Add Your 2 Cents