7

I would like to display something on my desktop by tapping a button on my mobile app.

For example, there is a "show cat" button on my mobile app. When I tap that button, a new window should be opened and display a cat picture on my desktop.

The scenario is a bit similar to Zoom. The desktop application is idle (from the user's perspective) most of the time. When someone calls me, the Zoom application suddenly displays a UI and notifies me.

To solve such a problem, I think the desktop application needs to be notified that some events have occurred like a user tapping the button on the mobile app or someone calling me.

One approach I can think of is that making the desktop application listen to a port like a web server. When the user taps the button on the mobile app, it can send an HTTP request to the desktop application.

I want to know if there are other approaches. Is my approach sounds normal enough? Is there a standard approach to such a problem?

I understand that "notifying the desktop application" may not be specific enough. Perhaps I may need to take different approaches for each OS such as Windows, macOS, or Linux. I need to support multiple operating systems so some unified approach is preferable but not mandatory.

Doc Brown
  • 218,378
LevelRin
  • 81

3 Answers3

24

Be aware that to be able to send an information, the sender needs to know the target. Normally the client knows the server. But the server has no clue about the clients until they try to connect.
Therefore you first have to establish a connection to the server, THEN the server can send data to the client.

In generell, there are a lot of ways to do that.

  • Client polls on a regular basis. "Is there anything new?", few seconds later "Is there anything new?"
  • Client makes a "long polling" request (request with an extreme high timeout). The server does not immediately answer it but "stores" the request to answer it as soon as something new happens. When the timeout of the client kicks in, he just sends the long polling request again and the server switches to the new one.
  • Client sends his address to the server, then the server can connect. Works rarely, because the client quite often does only know the local address (local network), but not the internet address.
  • For polling, you can use any bidirectional connection to the server (such as TCP or WebSockets (based on TCP)), then the server can push data over this connection.

In your case, the app and the desktop client will very likely get dynamic IP addresses and may even be behind routers which will even more disguise their addresses. Therefore you will very likely need a third central instance (a server) where both can connect to and which will then arrange the communication between mobile app and desktop app

JanRecker
  • 1,584
4

The client can simply connect to the server, identify itself, and leave the connection open without doing anything special. When something happens, the server can send some data to the client.

Nothing more complicated is needed. Except - don't forget to use TLS.

Because almost everyone uses NAT at the moment, you can't make your app listen to a port. Well, you can, but connections from the Internet won't get to the port.

There is no need to use polling or long polling. These are patterns designed for HTTP where the browser forces you to send a request and get a response. With a plain old TCP socket where you aren't forced to use HTTP, you can just send whatever you want whenever you want in whichever direction you want.

To make sure the connection is still working, you could send a heartbeat message every so often. TCP connections should time out after a while if they get disconnected - so your app can detect the connection loss and open a new one - but the timeout varies by OS and can sometimes be quite long (10 minutes).

Stack Exchange Broke The Law
  • 5,417
2

It should be noted that native apps may have an OS-level push notification API on desktop, just as they do on mobile.

https://docs.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview

The Windows Push Notification Services (WNS) enable third-party developers to send toast, tile, badge, and raw updates from their own cloud service. This provides a mechanism to deliver new updates to your users in a power-efficient and dependable way.

While that does relieve you of the requirement to handle a lot of connections from desktops, and Microsoft pay for the traffic, it's also pretty complicated.

Non-cloud approaches - directly across the local network - are possible, but then you have to work out how to do discovery. "Bonjour" build over multicast DNS (mDNS) is one possibility. DLNA is pretty much designed to send cat pictures and especially cat videos between local devices, although I've never quite seen it "just work".

Other design considerations: how far apart should the linked devices be linked? Do you need it to still work if they're in the same room but on different WiFi networks?

pjc50
  • 15,223