Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Read about google push/apple push feature.
Every phone holds at least one websocket connection to thier push notification server, and they allow tother devs to use it.
Hazarth7105119dAn 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
daniel-wu268119dApp 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.
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...
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.