Concept of push notifications - why is it only on mobile platforms? OSX/Windows/Linux?

Question

At an operating system level, mobile operating systems support the notion of push notifications or a socket level 'persistent' communication with an app, whenever it is online.

Why have the major computer operating systems (OSX, Linux, Windows) embraced this idea at an OS level as a higher level abstraction. This can still be done in an app for sure.

Is there a difference in how we perceive something thats 'pushed' on to our mobile devices (with or without our knowledge) vs something that maybe 'pushed' onto our laptop or home pc?

Is it more to do with how the 'privacy' and permissions structure for an app is defined in a mobile OS as compared to how for a desktop app, its not that well-defined and its not that granular?

Answer 1

The term "push notifications" is only on mobile platforms. We had the concept long before smart phones, before even cell phones.

When you push you have data and you want that data to go somewhere else.

When you pull you don't have data and you want to get it from somewhere else.

Problem is: who is "you"? There is no push without a pull. No pull without a push. So why call it a push? It's about who's the active participant. We describe the transfer from that perspective.

When I load a web page I'm pulling down data. The web page is pushing to me. But since I decided when this was happening we describe my role in this. The pull role.

When I sit on a web page and watch comments pop up I didn't decide when they'd come to me. I was just sitting here. I didn't actively pull them. They were pushed.

Ajax is one way that sort of thing is accomplished. There are other ways but it predominates the web.

In the object world this trick is called events. The observer pattern lets you tell an object, hey, let me know when you change. I don't want to keep asking you. That is, actively pulling from you. I'd rather passively sit here waiting to hear from you.

Repeatedly asking/pulling, is called polling. If done poorly it has serious performance consequences. Polling the database, rather the using a messaging or queueing system is a good way to piss off your dba.

Long before any of that we had IRC. We pushed "notifications" to each other with every stroke of the enter key. Before that we had email. Again pushing "notifications" to each other.

The key element in all of this is, if you want to actively push something at me I have to have something ready to passively pull it. Or it goes nowhere.

My question was also more from a 'personalization' point of view and also 'privacy' point of view in the sense of why not as many Mac or Windows apps take this route of using notifications in a highly social and personalized world and how maybe there's still a mindset gap between a desktop OS vs a mobile OS. – FrailWords

Well there definitely is a mindset gap. Mostly because the expectations on a PC were set long ago and expectations change slowly after much kicking and screaming.

The fundamental difference is on a mobile platform each app has a mailbox that works whether the app is running or not. On PC's the app can receive notifications. I get plenty telling me it's time to update. Those "notifications" simply don't show up unless the app is at least running in the background. A big reason this hasn't changed is because it would piss me off. If I'm not using adobe reader right now I don't want to hear from it. So the reader can wait till i'm using it to annoy me.

Of course the flip side is that if notifications HAVE to go through a review process then there is an added check on how annoying they can be. I do like being able to turn notifications off regardless of how the app feels about it. That's only possible to enforce when the app can't simply do it's own notification system. On the PC I'm just used to needing to stop the app from running in the background to shut it up.