undefined | Better HN

0 pointsZanfa4y ago0 comments

Again, in a world of spherical cows this could work, but in reality it didn't.

I was an Android dev pre-5.0 and believe me, having lived through the s*tshow that was push notifications at the time, there's no way it would've worked any other way. Google's own SDKs were garbage and as with everything else they kept releasing new incompatible rebranded versions annually. Last I checked, the Firebase console for managing push notification subscriptions was still one of the worst SPAs I've come across.

You'd expect a thriving ecosystem of dedicated push notification providers to pop up and outcompete Google, but all of the 3rd party offerings were even worse, in terms of battery life, UX, reliability and even pricing.

It's unfortunate, but no developer cares about your battery life, because no user is going to switch away from using their app solely because of crappy power usage, so Google had to do exactly what they did.

Maybe in a decade or two, with new battery technologies, there won't be a physical limitation and this situation would play out differently.

0 comments

Andrew_nenakhov4y ago

> I was an Android dev pre-5.0

I was in Android dev since pre 2.0, developing an app which need to constantly run. The situation got worse since then, not better.

A thriving ecosystem of dedicated push notifications can't pop up because you can't go to Android settings and choose another push notifications provider. You have to rely on ugly crutches to even receive a push notification, and that is why they are 'even worse'.

joshuamorton4y ago

Can you explain how this would work, does this mean that every app needs to push all notifications to all PN servers? Like there's the Google one and a theoretical Samsung one, my app has to send all push notifications to both, right, since I don't know a priori which provider you use, and if it's a global setting all apps need to use the same one.

So you either need every app developer to maintain the list of all push providers or someone, presumably Google, to maintain the canonical list and the thing that manages sending them to all the push providers.

Oh and then there's the associated suite of privacy issues. Do you really want every push notification prouder to get even metadata about all of your push notifications?

So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.

curryst4y ago

Why on Earth wouldn't you just make it a setting on the phone and expose that to apps? Have the apps read it on startup, and save it as part of the user profile server side. It basically becomes an email address.

> So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.

They seem to do fine with email addresses. Again, I don't see why 'username@notification.provider.com' (or an alternative with auth embedded) would be absurdly hard for developers. Someone will write a 'SendPushNotification' function that parses out the domain to send it to and the auth to use and send it, just like we've done with email since forever.

Google will likely know where you're sending your notifications, but they won't manage sending them (though they could probably scrape the contents since they own the OS).

j / k navigate · click thread line to collapse