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.

Improve this question
4
  • 1
    And then there is the middleground of having PWAs and developer.mozilla.org/en-US/docs/Web/API/Notifications_API/… and developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/… Commented Dec 14, 2021 at 9:54
  • Are the smartphone app and the desktop in the same (local) network? Maybe you don't need an internet at all. Commented Dec 14, 2021 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. Commented Dec 15, 2021 at 5: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 setup) that both can connect to, to traverse firewalls and NAT gateways that typically only allow outgoing connections. Commented Dec 15, 2021 at 8:52

3 Answers 3

Reset to default
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

Improve this answer
14
  • 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. Commented Dec 14, 2021 at 13:09
  • 4
    @PhillW. Phones still get push notifications when on WiFi / behind a corporate firewall. So that doesn’t explain it fully Commented Dec 14, 2021 at 16:13
  • 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. Commented Dec 14, 2021 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. Commented Dec 14, 2021 at 17:20
  • 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: developer.apple.com/library/archive/documentation/… Commented Dec 14, 2021 at 18:15
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).

Improve this answer
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?

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.