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
  • 199,015
  • 33
  • 367
  • 565
LevelRin
  • 81
  • 1
  • 5
  • 1
    And then there is the middleground of having PWAs and https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API and https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Re-engageable_Notifications_Push – Thomas Junk Dec 14 '21 at 09:54
  • Are the smartphone app and the desktop in the same (local) network? Maybe you don't need an internet at all. – Bergi Dec 14 '21 at 19:12
  • @Bergi That's a good point. Users will probably use the same network. However, I'm particularly interested in how other desktop apps work over the internet. Also, I'm not sure if using the same local network makes a big difference in the solution. – LevelRin Dec 15 '21 at 05:10
  • A local network would allow the smartphone app to directly connect to a server opened by the desktop app, possibly after using some form of automatic service discovery. If the two devices are on different networks, you will usually need some intermediate server (or [TURN](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) setup) that both can connect to, to traverse firewalls and NAT gateways that typically only allow outgoing connections. – Bergi Dec 15 '21 at 08:52

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,566
  • 4
  • 14
  • Thanks, so it seems it's normal to follow the general web approach for desktop applications. I was wondering if other approaches are the norm such as the push notification mechanism for mobile applications. – LevelRin Dec 14 '21 at 06:38
  • Mobile devices are "Out There" and "always on" the network and so are far more "reachable" by the servers that are trying to "push" things to them. [Corporate] desktops are generally hidden behind Firewalls that block anything being "pushed" to them from outside. This is why /polling/ is still considered a perfectly reasonable option for such machines. – Phill W. Dec 14 '21 at 12:20
  • 4
    Push notifications for mobile devices are often done on the phone network level, not on the normal networking level. That means the power consumption can be extremely low, just like for a phone that accepts phone calls at any time. That only works when you have a device with an actual SIM card. – gnasher729 Dec 14 '21 at 13:09
  • 4
    @PhillW. Phones still get push notifications when on WiFi / behind a corporate firewall. So that doesn’t explain it fully – Tim Dec 14 '21 at 16:13
  • Mobile, desktop, and web apps often use the same communication techniques (HTTP and WebSockets), as this makes it easier to develop and maintain all versions of the application. – Barmar Dec 14 '21 at 16:17
  • @Tim, even when a mobile device is on a WIFI network, it's still connected to the cellular service, which is how it would get those push notifications. I'd bet that if you lost cell signal, but managed to keep your WIFI signal, the push notifications would end. – computercarguy Dec 14 '21 at 16:24
  • 7
    Push notifications still work without a SIM card or cellular service. The difference is that mobile devices have OS-level push notification services, where (e.g.) Apple or Google deliver notifications to devices on behalf of applications. Individual mobile apps just tell the OS they're interested in receiving notifications and the infrastructure is provided by the platform. More recently, similar services are available for some desktop OSes, such as [WNS](https://docs.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview). – Zach Lipton Dec 14 '21 at 16:38
  • 5
    @computercarguy 100% that's not how iOS's push notifications work. I assume Android is the same. But I regularly get push notifications via WiFi when out of range of GSM. It must be the case it's internet only, because Apple sells WiFi-only iPads, which definitely get push notifications. *"Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection"*. There are some GSM-only "notifications" which can look like push notifications (public health alerts, severe weather, etc) but that's the exception. – Tim Dec 14 '21 at 17:20
  • 3
    iOS devices can receive notifications over cellular even if connected to WiFi (and even if WiFi is blocked) AND can receive notifications over WiFi if no cellular. – jcaron Dec 14 '21 at 18:12
  • 5
    @computercarguy Apple's push notification works by having the device (iPhone, iPad, Apple Watch etc.) poll Apple's server using a TLS connection (a TLS encrypted TCP/IP connection just like HTTPS). The difference with desktop apps is that it is not YOUR SOFTWARE that makes the poll request but the OS itself that polls for ALL installed apps. This central polling allows push notification to save power. See Apple's own docs: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1 – slebetman Dec 14 '21 at 18:15
  • 2
    @computercarguy Basically Apple's push notification works by having your server PUSH data to Apple's server and your iPhone PULL data from Apple's server. Apple manages how the data gets from Apple's servers to the device and an API manages how the data gets to your app. – slebetman Dec 14 '21 at 18:18
  • 2
    "*Client sends his address to the server, then the server can connect.*" sounds weird, can you clarify? Also I don't see why the client would need to "send" its internet address - the server does automatically receive it as the sender address. – Bergi Dec 14 '21 at 19:17
  • @Bergi You are right. As i wrote, that rarely works. Yep the client can inform the server about his address by any request (a ping would be enough), but as soon as a vpn, firewall or something similar is in between, problems can/will occur. Therefore this is more a theoretical approach, just to mention it (in rare circumstances this may be a solution), then an approach i would advise in general – JanRecker Dec 14 '21 at 21:06
  • Because we are talking about a desktop app none of these tricks are required. The client can simply connect to the server and leave the connection open. When something happens, the server can tell the client using the open connection. Web apps and mobile apps only have more limited ways to communicate, but this is not one! – user253751 Dec 15 '21 at 00:02
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).

user253751
  • 4,864
  • 3
  • 20
  • 27
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
  • 10,595
  • 1
  • 26
  • 29