We have a UWP (Microsoft Store distributed) app that our customer would like to control through his software. The main goal is that the customer can control the app (as if a user would be interacting directly with it) and get real-time data out of the app (every ≈100ms).
Both the customer's software and our UWP app will be running on the same Windows 10 PC. Our app will be runnning on the background, with it's UI hidden to the user.
The customer's software can be either Win32 app or UWP app, not yet defined.
I have read about the different ways or "technologies" a UWP app could perform Interprocess communication, but it is difficult to grasp the advantages and disadvantages of each one.
At first sight, it would seem like AppServices could be a good solution, given it looks well documented, supports both Win32 apps and UWP apps, and seems to be the best fit for the restrictions a UWP app presents given that runs on a sandbox. On the other hand, the following comment of Stefan Wick MSFT has warned me about the speed performance of AppServices, which would go against the real-time communication requirement.
On the mentioned comment, COM is mentioned as the alternative way when real-time communication is desired. I have never used COM, so I don't have much information. But after some reading, I could summarize my findings in: it requires more work to implement than AppServices, and there's a limited subset of COM objects that could be used on UWP while keeping the app Microsoft Store friendly.
My main questions would be:
- how critical is the "speed performance" on AppServices mentioned by Stefan Wick? Would it be critical for an communication with a frequency of 10Hz?
- What kind of COM object could be used to communicate strings (or serialized objects as strings) between two apps running on the same PC? Is that COM object within the limited subset of COM objects available on UWP?
- Is there another way that I am not seeing of achieving the described goal?
