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.
I don't understand that page at all. It doesn't explain why the app was rejected or why they can't use the native iOS pushing. In fact, I'm quite unsure of what is unique about their use-case for push notifications that is different than... any other similar task in iOS.
The iOS push notification service works by having a remote server determine when a push notification needs to be displayed to the user. The only way for Sparrow to do this would be to store the gmail credentials of every user who uses their application on a server (instead of each individual users iPhone). This would obviously introduce a lot of security considerations that Sparrow don't want to have to deal with.
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.
When Apple announced the various background task "modes" available (push, call placing, audio recording/playing, task completion) I immediately noticed that one use case was missing, and that's something like cron/at. Just like Apple allows tasks to run for a few moments for completion, they could allow tasks to run at scheduled times or intervals for a very limited time span, and maybe limit the number of apps/triggers allowed.
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.
The point is not that it can't be done securely, it's that they don't want the hassle of being responsible for a large amount of sensitive information. By not storing the information in the first place they can guarantee that they won't be hacked and have their customers data stolen.
Let's hope they get some traction petitioning for an acceptable method to send push notifications: https://news.ycombinator.com/item?id=3706993