> since Mini was entirely client-side it would be feasible for a free version to exist.
It uses a server for bridging APNs to GCM. Sure, that could be maintained on a donation basis, but it’s not completely infrastructure-free in any case.
It uses a server for bridging APNs to GCM. Sure, that could be maintained on a donation basis, but it’s not completely infrastructure-free in any case.
So yes, it's absolutely possible for this app to be 100% client side and I wish Beeper would've done that to start, if for no other reason than to dispel the misinformation around that BPNs is somehow required for the core operation of the app.
To be fair, they probably thought making this explicit in their How It Works article would be sufficient.
I don't really follow the reasoning. If saving on power, data, and memory usage were more important than the ability to receive messages, it would follow that you were better off carrying around a cinder block than a phone.
And in this case, GCM actually creates potential vulnerability. This should be allowed, and if Google sees it as a problem, they should implement a system service to retrieve from APNs. I believe the API is public.
Backgrounding is problematic when devs do it wrong or disrespect the user, but this isn't one of those cases.
Android preventing background processes in this case is worse for the user.
That sounds extremely unrealistic. If nothing else, you already have GCM – I don’t think it deactivates the persistent connection even if you don’t have any notification registrations.
> Backgrounding is problematic when devs do it wrong or disrespect the user, but this isn't one of those cases.
But how would Google distinguish “disrespecting” from intentional use cases?
I’ve used Android for years, and uncontrollable background services were a big problem.
> unless GCM is considered a major battery drain (hint, it's not)
It’s as much a battery drain as APNs. The point is that I want as few of these persistent connections and background services as possible, and the ideal number is one.
I'm confused. GCM is Google Cloud Messaging. It's also known as FCM or Firebase Cloud Messaging. It is the Google Play equivalent of Apple Push Notification Service (APNs). It's job is just to provide a persistent connection for delivering push notifications.
> I don’t think it deactivates the persistent connection even if you don’t have any notification registrations.
It seems almost impossible to be running an Android phone that has zero push notification subscriptions registered.
> But how would Google distinguish “disrespecting” from intentional use cases?
Via app review and banning apps that abuse those use cases. It turns out you can also decimate the user's battery using the stuff Google still lets you do (like periodic background tasks), but we don't ban those things because otherwise your phone would be useless at that point. Of course both the periodic task system and the persistent background service both would show up in your battery usage statistics, so the user and the system would be plenty aware that the app is misbehaving. And of course Google Play Protect can send along that feedback back to the Play Store in both cases.
> I’ve used Android for years, and uncontrollable background services were a big problem.
Cool, I also have used Android for a long time! Started on the Nexus 5 back in 2013 and have used Android devices ever since.
> and uncontrollable background services were a big problem.
Hm, I wouldn't say they were a big problem but I guess I just used well behaved apps. Certainly restricting background behavior helped battery life, but at what cost?
What you might not realize is that there are a number of permissions that you can declare in the Android manifest that trigger the Play Store review to be... just a little more thorough about your apps behavior. This should be one of those permissions. Using it for a persistent connection to a messaging service is absolutely a valid use case for this sort of thing. That's not the kind of thing that caused battery problems on your older Android phones though.
This is also very analogous in App Store. You declare certain plist declarations that need to be justified, and cause your app to be more carefully reviewed.
[0] https://cs.android.com/android/platform/superproject/+/maste...
That sounds "very possible" to me. Apps can even pop up a dialog on first run instructing the user to disable battery optimization, and then load up that settings page when the user taps a button in the dialog. Certainly some people will be confused by it, still not know what to do, or not want to do it, but it's still quite possible.
And if the user won't do it, the app can still spin up a service with a foreground notification if they really want to keep things working decently well, and use Android's scheduled jobs mechanism to restart the service every 10 minutes (or however often) to catch cases where the service still ends up getting killed.