4 ms·

Is it possible for every app developer to stop using FCM? Yes, in China. The result is a chaotic market. App devs will have to use multiple push machinism for

• ktosobcy 8y ago
  But do we really need "push providers"? The problem is (IMHO) that app developers don't know how to use the connection efficiently causing the radio to wake up constantly (IDLE socket connection has very low battery impact). Instead of pushing every darn detail queue less important ones and send them out when something more important arrives; your client app can signal the server, that app is in the background (or phone is going to sleep) to send less frequent updates. But - companies will abuse everything they can to notify users about absolutely everything. Currently I'm running phone without google play services and it works just fine (with exception of Viber, which can't deliver messages correctly without push services, but it's not that important for me).
  • richardwhiuk 8y ago
    As soon as you are maintaining multiple connections, battery life gets worse.
  • ucaetano 8y ago
    If you don't have a push provider mediating the many apps trying to get notifications, you end up in a tragedy of the commons scenario, where every single app will try to implement its own push service and will prioritize its own push service, quickly resulting in a race to the bottom where the device is constantly connecting to a different push service, draining battery and exhausting your data connection. It isn't very different from preemptive/cooperative multitasking.
    • iad 8y ago
      Why can't the device just chose a single wake schedule and communicate that to each push provider? Hopefully UDP can be used so there's no need for any keepalives or handshakes during the wake periods? Are clocks too unreliable or is there too much NAT because everybody's too lazy to implement IPv6 still?
      • izacus 8y ago
        This actually happens on Android (read about Doze mode), but the issue with your approach is that you don't get realtime delivery - only periodic sync. Which is actually less efficient, because the device must wake up on interval, activate the radio and poll for changes. FCM (and Apple push) run a single keep-alive TCP connection and incoming packets will cause radio and application process wakeup only when necessary. This change significantly improved Android battery life (remember that HN Apple lovers really loved to bash on Android battery life before this FCM push happened). The fact of the matter is that a lot of developers didn't care one bit about battery life and abused Android background services when there was no need to do so (e.g. schedule periodic wakeups to check for a preset alarm needed once 24 hours) and if we learned anything by this experiment is that you simply can't trust developers to respect users anymore.
        • nicoburns 8y ago
          Does the 1 tcp connwction notnrequire the radio to wakeup to receive pushes?
          • izacus 8y ago
            It does, but not really periodically - the radio is just listening and not transmitting until a packet comes. Then it wakes up the application processor to handle it.
            • int_19h 8y ago
              I guess the question is, if a single listening TCP connection is not a problem because everything can sleep until a packet arrives, what's the problem with multiple apps each opening such a connection?
  • floatingatoll 8y ago
    We need the core operating system to provide a push provider that we trust. Do we trust Google to act as a push provider?