Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
An open socket really doesn't cost you that much. You can even configure your client/server for high delay heartbeats, and a single heartbeat is really just a byte that you send and receive every n seconds or even minutes if you want.
Then even the thread that keeps listening on that socket can eventually be scheduled away by the system to only wake up if the socket is used, as it is a blocking resource. So negligable amount of cpu and memory is even used.
I know Nothing about push notifications though, but if this is the way it is done, It's a good design -
App don't perform listening to notifications on their own. That would be a collosal waste of resources, as you said.
In case of Android (which is my personal experience), when we want to send notification, we send POST data to Google Firebase Cloud Messaging; and they handled the rest for us. So, in practice, our phone only listen to one source (which is Google) every other second.
On your App, you only need to make the event listeners. -
@magicMirror @Hazarth @daniel-wu interesting... So from what I gather, a connection like I described DOES in fact exist, but it is:
A) Not as resource expensive as I had assumed
B) Done at scale via service providers like Google to have the cost make sense -
@AlgoRythm @Hazarth
The open socket is expensive on mobile, but not for the reasons you might think.
It "revs up"/"revs down" the cellular radio communications when you are not covered by wifi. And that is very battery intensive. In addition, a push notification might trigger a "pull" event, as part of the "push"/"pull" paradigm for these type of notifications. The push notifications do not carry a large payload, and apps sometimes want to pull something large, like an image, or some huge and stupid JSON... -
@magicMirror that makes a lot of sense. What's the solution?
-
@AlgoRythm
There is no solution for the basic problem. You want notifications? Pay the battery price. However, G and A do optimize a bit, and reduce the radio cycle frequency by integrating better with the radio layer. Qualcom and Broadcom mostly. Both A and G are very aggresive about the background application behaviors for apps using the push/pull pattern. The pull stage increases the radio "rev up" duration.
So - if you are an app dev, you can multiple push instead of push/pull, or just wait until your app starts up, and then pull what you need.
When you install a program and you realize just beat a world record.
I've got a kinda basic networking question I can't quite figure out
How does a push notification work?
Like, on an Android app. A good example is an authenticator. Say I don't login to the service for 4 months.
Then, one day, I try to log into the web portal and it prompts me to accept the request on my authenticator app on my phone.
Immediately, there's a push notification on my phone.
Wtf.
Is there a socket open for 4 months? Does it send requests every few seconds for 4 months? I can't imagine that either of these options scale whatsoever: both horrendously waste bandwidth and server connections.
How the fuck does it work? I don't even have the first idea.
question
push notifs
apps
networking