3 ms·
Because that would be a pull and not a push. Not that there is anything wrong with that, and in many use cases it would be a fine alternative. But sometimes yo
by mbreese 5y ago
Because that would be a pull and not a push.
Not that there is anything wrong with that, and in many use cases it would be a fine alternative. But sometimes you really do need to push data to the user even if they aren’t polling for it.
Pill reminders would be something that you’d want to push. You can’t be sure the user is running your app (even in the background), and the actual state changes are rare. So some kind of mechanism where the client doesn’t initiate the check would be better.
Using a long poll for email or slack or something like that can make more sense in some
scenarios.
- anon9001 5y agoPedantic, but: from the device's point of view, it's always a "pull". You can't "push" to something that's not publicly addressable. From your app's point of view, you receive a "push" from the OS.
- burnished 5y agoI think they are differentiating between systems that perform polling and systems that can receive interrupts (maybe not quite the right word here), I don't think that has anything to do with being publicly addressable here, in either case you sort of have to assume that devices can find each other before the difference even makes sense.