locked
How would you do the equivalent of a photoshop plugin in a Metro style app?

    Question

  • With photoshop, you can extend the functionality via plugins.

    It looks like plugins are not allowed for a Metro style app.

    A share contract looks like it is close, but it doesn't return the data back to the source app.

    How can a metro app pass data to another app and then get the updated data back?

    Monday, March 26, 2012 7:00 AM

All replies

  • Hi,

    Share contract is the first option to share data across apps. However, when your share target app receives content from a source app, that content is immutable—you can't change it. But your app can play as both source app and target app to exchange data.

    Otherwise, network communications using an IP loopback address cannot be used for interprocess communication (between two different apps) since this is restricted by network isolation. You can use loopback only for testing or debugging purposes.

    In general, traditional IPC mechanism is not available for Metro Style App.

    • Marked as answer by dlenihan Wednesday, March 28, 2012 7:53 PM
    • Unmarked as answer by dlenihan Wednesday, May 16, 2012 8:01 PM
    Tuesday, March 27, 2012 5:36 AM
  • I am afraid, without the help of a online service backend this is currently not possible.

    MSFT missed the opportunity to allow apps to declare their own "charms" or "contracts" other apps could use to communicate with them.


    • Edited by phil_ke Tuesday, March 27, 2012 2:04 PM
    Tuesday, March 27, 2012 2:03 PM
  • Could you explain what you want to develop?

    Do you want to develop a (1) Plug-in (this is what I understand) or make an (2) App, that can use plugins?

    For (1), the user will install a plug-in but has no idea which app will work with this plug-in. Only a plug-in does nothing from a users perspective.

    For (2), your app has no idea what plug-ins are installed. The user also has no idea, which plug-ins work well with the certain app.

    If you think about the tablet experience, you will find that plug-ins break the encapsulation approach - which is what people have found to prefer (see ipad).

    The concept of plug-ins like DSP (sound effects) work only on desktop. The regular Joe cannot understand what the dependencies are to make it work. The point is to reduce complexity for the user. Generic plug-ins don't help in this case.

    Something that could work is like Firefox, where the plug-ins are managed by the App. However, I understand, this is not what you want(?).

    - Paul

    Tuesday, March 27, 2012 2:49 PM
  • I could see how making the source app also be a target would allow data to leave and then come back updated. From a UI perspective, it seems a little clunky.

    For example:

    1. Select image data in source app

    2. Use share charm to get list of apps that can take image data

    3. Select target app

    4. Manipulate image data in target app

    5. Use share charm to find apps that can take updated image data

    6. Select source app

    Done! Source app has updated image data from target app.

    With a traditional plugin architecture, it is much simper:

    1. Select image data in source app

    2. Run plugin within source app

    3. Manipulate image data

    Done! Source app has updated image data

    Is there a more direct way to do this? It seems like the source app should be able to pass its information to the target app so that steps 5 and 6 can be handled automatically. Is this possible?

    Tuesday, March 27, 2012 3:40 PM
  • I am investigating what it would take to develop an app that can be extended by 3rd party software.

    The app would function like photoshop in that new functionality can be added via plugins.

    I want to understand/prototype the recommended way to get the desired behavior of a plugin (both the app and the plugin) in Win8.

    Tuesday, March 27, 2012 3:46 PM
  • Any component used by the app would need to be included and uploaded to the Store by the app developer in the Appx package. There is not a way a 3rd party could separately upload components to the Store that can be used in your Metro style app.

    You might want to take a look at leveraging in-app offers, or simply updating the app periodically with all the current 3rd party components you have received.

    Enabling trials and in-app offers in your Metro style app
    APP-123T
    Speakers: Arik Cohen

    Thanks!


    David Lamb


    Tuesday, March 27, 2012 5:44 PM
    Moderator
  • Is the share contract the only way two metro apps can send data back and forth?

    Tuesday, March 27, 2012 6:01 PM
  • Two apps that are not in the same Appx package should communicate via Contracts. As phil_ke mentioned, you could also implement some type of extensibility model in a service your app communicates with over the internet.

    David Lamb

    Tuesday, March 27, 2012 6:23 PM
    Moderator
  • Or you could, in an WinJS app at least, load scriptlets (like Greasemonkey or nodejs packages) from the Internet to extend your app.

    The idea would be that the user can browser a server sided repository and select scripts he want to use that extend the app. Or he could point to local scripts (via filepicker) that the app should use. Of course the scripts could only operate with the same permissions the app is running under.

    The BingMaps actually uses this model, as the SDK only provides the module loader mechanism and you load live code from the Internet when the app is running (see Bing SDK examples).

    Since the Bing SDK uses this model I hope its a valid way for non MSFT apps too, to extend their functionality beyond app store updates.


    Tuesday, March 27, 2012 6:46 PM
  • I don't think you can do what I want with an app acting as both a source and target.

    Consider the example I gave before:

    1. Select image data in source app
    2. Use share charm to get list of apps that can take image data
    3. Select target app
    4. Manipulate image data in target app
    5. Use share charm to find apps that can take updated image data
    6. Select source app

    The problem is with step 5. Once you initiate a share contract, trying to bring up the share contract a second time cancels the current share contract.

    I think the real answer is something more like this:

    1. Select image data in source app
    2. Use share charm to get list of apps that can take image data
    3. Select target app
    4. Manipulate image data and store in an output file provided via share contract
    5. Source app receives updated data by reading from output file

    Hopefully there is a way for the source app to know when the target app has completed its work so it knows when to read the output file.

    
    
    
    
    Wednesday, May 16, 2012 8:40 PM