I think the issue here is that it isn't really "push" they want to do. From what I can tell, they want to do is simply "run all the time so we can keep a connection open to receive new messages immediately". Which, to be fair, is pretty similar to what Apple does for their push notifications.
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.
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).
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.
Yeah: what we really want is a way to strictly limit Sparrow's permissions, so they can only see new mail as it is passed in, and maybe only just enough for something like push. However, that's really on Google's end to implement, and I'm not sure just how much interest they have in third party Gmail-specific mail clients.
Re push, I use an IMAP client called K-9 Mail on Android which has support for IMAP IDLE, which is basically the IMAP version of push. It keeps a constant connection open to my IMAP server and is immediately informed of any new mail. I have not noticed any reduction in battery performance since moving from 15 minute polls. I still get 1.5 to 2 days use out of it (HTC Desire Z).
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.
> I have not noticed any reduction in battery performance since moving from 15 minute polls.
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.
sure, K-9 Mail works fine and implements everything correctly. But what happens when you have 4 or 5 apps that start polling constantly for updates because they don't want to deal with push notifications? I think Apple opening up this functionality would be a mistake that's open for abuse by other developers.
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.