• Railcar8095@lemm.ee
    link
    fedilink
    English
    arrow-up
    3
    ·
    9 months ago

    Imagine you have 20 apps that can send receive notifications from remote (messaging apps, offers, updates…). That would require each app to be active in the background and pulling updates. That’s a massive battery drain.

    Instead, the apps send the notifications to Apple/Google, and the OS checks for all of the apps. The apps don’t need to be awake (the OS could show the notification or wake the app) and there’s only one service checking for the ml notifications.

    It’s a massive oversimplifying and probably I made some mistakes, but that’s my understanding. Hopefully somebody can correct me.

    • Steve@communick.news
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      Apparently that’s how it works.

      I’d imagine a notification service on the phone that can receive or pull from all the various sources on behalf of the apps installed. That way the app servers don’t need to hand the data to Apple/Google servers. It just seems like an extra step.

      • Railcar8095@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 months ago

        Well, the problem is that every would need to have their own server with notifications waiting to be pulled (imagine your phone goes offline) and they need to be beefy enough to answer potentially thousands of requests per second. Almost impossible for small devs.

        There’s also additional battery need, as it’s many calls and payloads, and if a server is slow it can affect all the other notifications. Plus more area of attack.

        Not impossible, but I don’t think it’s the direction things will go.