【问题标题】:Communication between Windows Store app and native desktop applicationWindows 应用商店应用程序和本机桌面应用程序之间的通信
【发布时间】:2012-09-02 17:31:54
【问题描述】:

!为了简化起见,我将 Windows 应用商店应用程序(也称为 Metro 或 Modern UI)称为“应用程序”,而将常见的桌面应用程序称为“应用程序”!

我相信对于已经在市场上建立应用程序的开发人员来说,这仍然是关于应用程序开发的最不清楚但最重要的问题之一: 如何在 Windows 8 系统上管理应用程序和应用程序之间的通信? (请不要就原则展开辩论 - 有很多用例确实需要这样做!)

在过去的几天里,我基本上阅读了数百篇文章,但仍然不清楚如何从第一次开始就继续这样做。主要是因为我发现了几个相互矛盾的信息。 带着我的问题,我想从最终的 Windows 8 可能性的角度重新解决这个问题。

鉴于情况:

  • 应用和应用在同一系统上运行
  • 1:1 交流
  • 应用程序是本机的(用 Delphi 编写)
  • 应用程序可以使用管理员或系统权限(如果需要)
  • 在 90% 的用例中,应用程序请求应用程序执行的操作并接收一些文本结果。应用程序不应因此而被搁置或冻结!
  • 在 10% 的情况下,应用程序执行一项操作(由某些事件触发)并通知应用程序 - 结果可能是:在磁贴上或在已运行且处于活动状态的应用程序中显示某些信息,或者在可能的情况下运行应用程序/带来它到前台。

现在“简单”的问题是,如何做到这一点?

  • 现在真的允许本地网络服务器访问吗? (我相信这不是很长时间,但现在是自最终版本以来)
  • WCF? (-> 显然是MS doesn't recommend that anymore)
  • 本地 REST/SOAP 服务器上的 HTTP 请求?
  • WinRT syndication API? (使用 RSS/atom 响应的另一种 Web 服务访问形式)
  • WebSockets(如MessageWebSocket)?
  • 其他形式的 TCP/IP 通信?
  • 为输入和输出共享一个文本文件(实际上只是想到这会很痛,但至少这是 MS 无法阻止的可能性...)
  • 命名管道是不允许的,对吧?

在 SO 上有一些关于这个主题的讨论,但是其中大多数都不再是最新的,因为在发布 Windows 8 的最终版本之前 MS 发生了很多变化。我没有混淆新旧信息我想为我和所有其他 Windows 应用程序和应用程序开发人员找到这个问题的明确和最新的答案。谢谢!

【问题讨论】:

  • 我也不指望能够通过本地文件进行通信。 AFAIK、WinRT 和桌面当前共享相同的安全令牌,但类似于 UAC 的拆分令牌系统将是明智的,并且很可能会在未来的 Windows 版本中引入。 (注意:我在这里推测,这不是基于收到的信息。)此外,如果 MS 对 Windows 应用商店应用程序进行任何形式的审核,一旦他们发现你不会被踢出你在做什么?
  • @Harry 好吧,我想没有办法尝试一下……看到不明智的 MS 如何处理将应用程序和应用程序结合在一起的整个场景,这实际上是非常可悲的。一方面,他们试图在一个设备中结合两个世界——同时指出这实际上是选择 Win8 平板电脑的最佳理由。另一方面,他们尽一切努力使这些世界尽可能地分开。这是多么愚蠢?打败我。

标签: windows microsoft-metro windows-runtime communication


【解决方案1】:

如果您谈论的是进入 Store 的应用程序,则不允许通过任何机制与本地系统进行通信。部分调试场景支持与本地系统通信,让应用开发更轻松。

您可以使用文件或协议处理程序从 Windows 应用商店应用程序启动桌面应用程序,但没有直接通信。

所以,重申一点……WinRT 和桌面之间的通信对于已发布的 Windows 应用商店应用程序是不允许的。仅在调试时允许两个环境之间的通信。

PG 在不同的地方发布了不允许通信的原因,从安全性到 WinRT 生命周期(即,您的应用程序被暂停 - 如何处理资源、套接字、远程应用程序等)。 - 很多故障点)以及商店应用程序不能依赖外部程序的事实(即,我需要您的本地桌面应用程序/服务才能运行该应用程序,但是我如何安装您的应用程序/服务?你不能集成到 Store 应用程序中。您可以提供另一个 Store 桌面应用程序条目,但这会带来不好的用户体验。)当然,这些都是高级摘要。

【讨论】:

  • 它可以通过一个文件来完成 - 没有被阻止。不是说它漂亮,但它是可能的。我也认为命名管道会起作用,但我不确定。
  • 杰夫,你对此有多大把握?荒谬的是,人们无法尝试它,因为从商店开发和安装的应用程序的行为显然不同......而且由于这种情况有很多有用的用例,所以说“不可能”基本上不是解决方案.最后,开发人员将通过 localStorage 中的文本文件传递命令和结果来真正解决这个问题。这真的是 MS 允许的唯一解决方案吗?
  • @DominicHopton 在文件上正确,尽管这不是真正的直接通信:) AFAIK 命名管道不起作用。这是基于 PG 之前的声明。也许有些东西发生了变化,但我不知道有任何变化。
  • @CodeX 我有 98.72356% 的把握。 :) 除非我错过了 RTM 中的更改,否则这一直是 PG 长期以来的立场。明白有很多有用的场景,但没有交流是我的理解。您可以在 PG 的网络上找到一些关于他们为什么这样做的讨论。我在上面编辑了答案以包含一些原因。抱歉,这不是您想要的答案,我会在以后的版本中传递反馈以供考虑。
  • 行为应该是相同的 - 一个排除是环回,一个手动启用。如果您想测试它,请不要启用它。如果一切都失败了,请部署包,而不是让 VS F5 部署。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-05-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多