Let's hope they get some traction petitioning for an acceptable method to send push notifications: https://news.ycombinator.com/item?id=3706993
However, allowing this would be a bad move. It'd mean that rather than once centralized connection that knows about the device's network state and can (at least try to) preserver battery life, you'd then have as many as one per each app, always open. (Once Sparrow does this, then why could any other app not?)
The real issue here is that, from their responses, it seems that Google doesn't have some sort of authentication method like that could be used to get access to just enough information to pass the push data to Apple — or, at least, not one (like OAuth) that doesn't need them to remotely store a username and password. If there was a way for them to get some sort of useless "token" to get the notifications themselves and pass them to Apple, I don't think the security issues would be anywhere near as severe (especially if it was an opt-in service). But I don't know if Google does that, and their responses don't seem encouraging that something like this would be possible.
Good point, that would be a much better solution. All they'd need is a web hook to let them know when there is new email for an account. They could use that to send a push notification with the correct badge count for unread messages.
That's what we should really be petitioning for.
If that database was unknowingly compromised there could be a lot of fallout. I think that's a much bigger concern than leaking passwords.
There's nothing inherently wrong with this on mobile devices. If Apple can't do it for iOS, that is a flaw in their design, or their thinking.
That's exactly the scenario we have with Android, and it's not a problem there...
Push should be less taxing on the battery, since you only really need to fire up the radio when new data is coming your way, save any overhead of ensuring the connection is still alive. Apple does the same for their notifications (and ActiveSync) for the same reasons.
> If Apple can't do it for iOS, that is a flaw in their design, or their thinking.
It's not really a flaw, just a different methodology that is reasonable given the design goals. If you want iOS to be like Android, why not just use Android? That's the beauty of competition – you are free to choose the best.
Alternatively, Apple provide an API that certain apps may use to regular check for updates by running code on the iPhone, but Apple are not allowing Sparrow to use this API.
This would cover many use cases, such as alarm clocks, calendar notifications, and various poll-based background checking like new email count, maybe even headers fetching, while retaining control of watt usage.
In the meantime, I suppose Sparrow could integrate with Prowl.