Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I can fully sympathize with this. We have an open-source app on Google play, and the amount of dirt flying at us from users is astounding. What makes matters more funny, app is a client, so most of the problem are related to improperly configured servers. Also, since Google play allows users to leave ratings, every jerk feels entitled to award you 1/5 rating for every minor glitch he experiences.

We have learned to ignore this, and adopted a policy that we just don't care about ratings. If the user is asking for help in a polite way, we help him however we can, for free. If he is an entitled jerk, we just mock him for being entitled.

Of course, then some start ranting how immature our behavior is are and how we must learn to treat our 'customers' better. Of course, right.



I am curious if your open source app is on F-Droid, and if so do you find a better class of user there?

Slightly off topic - I can understand that people publish on Google Play to get reach, but it's upsetting when open source projects make it their sole binary distribution mechanism. It is strange to mandate that the user adopt the model of centralized control by Google, when 3rd party binary distribution is just as well supported on Android as any other platform. This goes for any app, of course, but open source apps in particular ought to know better (and with F-Droid, need not even host the files themselves).


The app is on F-droid as well, but the audience there is much smaller. Also, F-droid apps can't use push notifications from Google,and it severely limits their capabilities.


Getting way off topic now, but I've heard this about Google's "push notifications" before - what's the technical restriction? Surely whatever Google is doing, anyone else can do? Anecdotally, using K9 mail and a GMail account on a Google-free phone, my emails invariably arrive instantly (to my great surprise - I expected periodic polling).


The technical restriction is that you need to have google apps installed and have a valid app certificate to use FCM (the current name of Google's push notifications).

As for alternatives. FCM (or, for that matter, Apple's APNS) requires a persistent connection between a device and push servers to work. Curiously, both Google and Apple seem to be doing this via maintaining a modified XMPP protocol. And this just can't be replicated by any other party: to maintain a persistent connection an app must work all the time and be active in the background, and both Google and Apple heavily suppress background app activity (google has some workarounds, but they become more and more restricted with each OS update).

All in all, I believe that this policy is begging for some antitrust action, so device owners could legally subscribe to alternative app stores and push notification providers. From what I know about XMPP, replicating a server part of a push service should not be insanely hard to do.


It also omes down to power consumption and special mobile protocols.

Keeping a TCP connection open on a mobile link requires occasional keepalive package exchange. That wakes up the mobile radio, which is quite power hungry if the device isn't doing anything else.

That radio wakeup is needed for each independent TCP connection's keepalives, so to minimise the power consumption of multiple idle app/notifier connections, you want them multiplexed over a single TCP connection.

Another factor is the ability to send the underlying event over a lower-level mobile protocol. The mobile base station is regularly exchanging with the handset anyway, to maintain a link which can carry station-to-handset events already and to monitor the link. The whole thing is very well optimised for the radio. So an occasional application event can be sent over that link as well without needing any extra keepalives or radio wakeups. That's the most power efficient thing to do in principle, assuming application events aren't happening often.

Unfortunately, having lots of independent push notification providers being used by different apps at the same time would be quite power hungry.

I think it would be great if a user could direct all the subscriptions through one or two services of their choice though, including an option to provide their own service URL that they run themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: