21

! For the sake of simplifying things I will refer to Windows Store applications (also known as Metro or Modern UI) as "app" and to common desktop applications as "application" !

I believe this is still one of the most unclear yet important questions concerning app-development for developers who already have established applications on the market: How to manage communication between apps and applications on a Windows 8 system? (please let's not start a debate on principles - there're so many use cases where this is really required!)

I basically read hundrets of articles in the last few days but still it remains unclear how to proceed doing it right from the first time. Mainly because I found several conflicting information. With my question here I'd like to re-approach this problem from the viewpoint of the final Windows 8 possibilities.

Given situation:

  • App and application run on same system
  • 1:1 communication
  • Application is native (written in Delphi)
  • Administrator or if required even system privileges are available for the application
  • In 90% of the use cases the app requests an action to be performed by the application and receives some textual result. The app shouldn't be left nor frozen for this!
  • In 10% the application performs an action (triggered by some event) and informs the app - the result might be: showing certain info on the tile or in the already running and active app or if possible running the app / bringing it to the foreground.

Now the "simple" question is, how to achieve this?

  • Is local webserver access actually allowed now? (I believe it wasn't for a long time but now is since the final release)
  • WCF? (-> apparently MS doesn't recommend that anymore)
  • HTTP requests on a local REST/SOAP server?
  • WinRT syndication API? (another form of webservice access with RSS/atom responses)
  • WebSockets (like MessageWebSocket)?
  • Some other form of TCP/IP communication?
  • Sharing a text file for in- and output (actually simply thinking of this hurts, but at least that's a possibility MS can't block...)
  • Named Pipes are not allowed, right?

There are some discussions on this topic here on SO, however most of them are not up-to-date anymore as MS changed a lot before releasing the final version of Windows 8. Instead of mixing up old and new information I'd like to find a definite and current answer to this problem for me and for all the other Windows application and app developers. Thank you!

Cole Tobin
  • 9,206
  • 15
  • 49
  • 74
CodeX
  • 717
  • 7
  • 23
  • I wouldn't count on being able to communicate via a local file, either. AFAIK, WinRT and the desktop currently share the same security token, but a split-token system similar to UAC would be sensible and might well be introduced in future versions of Windows. (NB: I'm *speculating* here, this isn't based on information received.) Besides, if MS do any sort of auditing of Windows Store apps, wouldn't you get kicked out once they noticed what you were doing? – Harry Johnston Sep 10 '12 at 20:06
  • @Harry Well I guess there's no way around trying it out... It's actually very sad to see how unwise MS treats this whole scenario of bringing applications and apps together. On the one hand they try to marry both worlds in one device - while pointing out that this is actually the best reason to choose a Win8 tablet. On the other hand they do everything to keep those worlds most possible apart. How foolish is that? Beats me. – CodeX Sep 12 '12 at 23:46

1 Answers1

11

If you are talking about an application going into the Store, communication with the local system via any mechanism is not allowed. Communication with the local system is supported in some debug scenarios to make app development easier.

You can launch desktop applications from Windows Store applications with file or protocol handlers, but there is no direct communication.

So, to reiterate the point... communication between WinRT and the desktop is not allowed for released Windows Store applications. Communication between the two environments is allowed in debug only.

The PG has posted in different places reasons for why communication is not allowed, ranging from security, to the WinRT lifecycle (i.e., you app gets suspended - how does that get handled re: resources, sockets, remote app, etc. -- lots of failure points) and the fact that Store apps cannot have a dependency on external programs (i.e., I need your local desktop app/service for the app to run, but how do I get your app/service installed? You cannot integrate into the Store app. You can provide another Store desktop app entry, but that is a bad user experience.) Those are high level summaries, of course.

Jeff Brand
  • 5,623
  • 1
  • 23
  • 22
  • 2
    It can be done through a file - that's not blocked. Not saying its pretty, but it is possible. I also thoug a named pipe would work, but Im not sure on that. – Dominic Hopton Sep 09 '12 at 20:41
  • 1
    Jeff, how sure are you on this? The ridiculous thing is that one cannot try it out because the behavior is apparently different for development and installed apps from the store... And since there are lots of useful use cases for this scenario, saying "Not possible" is basically not a solution. In the end developers will really work around this by passing commands and results through text files in localStorage. Is that really the only solution MS would allow? – CodeX Sep 09 '12 at 21:19
  • @DominicHopton correct on files, though that is not really direct communication :) AFAIK named pipes do not work. That is based on statements made by the PG earlier. Perhaps something changed, but I am not aware of any changes. – Jeff Brand Sep 09 '12 at 22:20
  • @CodeX I am 98.72356% sure. :) Unless a change slipped into RTM that I missed, that has always been the position of the PG for a long time. Understood there are a lot of useful scenarios, but no communication is my understanding. You can find some discussions around the web from the PG on why they have done this. I edited answer above to include some reasons. Sorry that it not the answer you wanted, I will pass feedback along for consideration in future releases. – Jeff Brand Sep 09 '12 at 22:29
  • The behavior should be the same - the one exclusion is loop back, which one manually enable. If you wanna test it, don't enable it. If all else fails deploy the package rather just letting VS F5 deploy. – Dominic Hopton Sep 10 '12 at 03:37
  • A couple of days ago Embarcadero released Delphi XE3 which comes with a component named "MetropolisSvc / TLiveTile". Please have a look at its [description](http://docwiki.embarcadero.com/RADStudio/en/Live_Tile_Support_for_Metropolis_UI_Applications). Quote: "MetropolisSvc: This service application is a local REST service, and communicates between your application and your Live Tile." How does it work then if no local communication is allowed? They use it for communication with the app tile but I don’t think there’s a difference to the app itself. – CodeX Sep 10 '12 at 07:50
  • @CodeX Did a quick scan... Metropolis UI is not a WinRT app... it is a desktop app that looks like a WinRT UI app. From the site... "Only Metropolis UI desktop applications are supported in XE3. Metropolis UI mobile applications (and WinRT) are not currently supported. " XE3 is specifically not supported in WinRT apps - notice only their desktop applications support XE3. XE3 is a way for desktop apps to create/update a custom "LiveTile" on the Start screen - it not communication between WinRT and the desktop. – Jeff Brand Sep 10 '12 at 13:07
  • @Jeff You're right with "Metropolis UI is not a WinRT app", however I wasn't talking about "Metropolis UI" but about "MetropolisSvc". They should work independantly. As for my understanding the live tiles on the start screen run in the same (or at least similar) context as the WinRT apps, don't they? So why are the tiles then allowed to communicate with a local webservice? They're located in the "Modern/Metro" world but somehow communicate with a service in the desktop world. Are you saying that tiles and apps have different permissions? – CodeX Sep 10 '12 at 13:31
  • @CodeX No, tiles themselves are not WinRT apps. For example, I have a tile for Outlook, Word, etc - but those are native apps. Start Tiles are kind of just icons on steroids. From what I can determine, and I could be wrong, the XE3 stuff is just creating a custom "icon" that is created to look like a Tile, if that makes sense. At the end of the day, there is no communication between the MetropolisSvc and WinRT. That is why their docs say you cannot use MetroplisSvc with a WinRT app. – Jeff Brand Sep 10 '12 at 14:38
  • @Jeff There are two types of tiles. Static tiles and live tiles. While the first ones are basically shortcurts in a sqared tile form (they can be created by and for every desktop program as well), the latter ones are more apps than just icons. They have different layouts and settings for updates - but are actually limited to pre-defined preferences as they can't contain _everything_. Maybe that's the reason they're allowed to get their info updates from localhost? I quote again: "This service application is a local REST service, and communicates between your application and your Live Tile." – CodeX Sep 12 '12 at 23:22
  • @CodeX that would go against everything I know about communication between the two environments. I have not seen a single application that works that way. I think they are generating custom Static tiles that they just replace via the service to mimic a Live Tile. Their own docs specifically state their service DOES NOT work with WinRT applications. – Jeff Brand Sep 13 '12 at 00:19
  • I'm surprised by the black and white answer - one of the examples given was app communication with a locally hosted webserver...is this seriously not possible? – lightw8 Apr 19 '13 at 04:19
  • The reasons you mention for disallowing access to local services apply exactly the same for services hosted on the internet, but those are allowed. From the perspective of managing the interactions, whether the service is local or on the internet is transparent. – Darrel Miller Jul 10 '13 at 21:22
  • IT should be mentioned that all limitations only apply if you try to distribute your app over the store. Sideloaded apps can communicate with a local service. – quadroid Nov 21 '13 at 09:35
  • How about App to App communication using the [Share mechanism](https://msdn.microsoft.com/en-us/windows/uwp/app-to-app/index) - using it, maybe send JSON or XML data for example – msanjay May 05 '16 at 10:59