I just inherited an Android app project as a (technical) product manager that uses a 5 second timer to poll a remote URL to see if some work initiated by the app has finished. My initial reaction of course was to suggest to replace this with a push/notifications mechanism, preferably Android's built in GCM, so the work is removed from the app on the phone and put on the server side.
Surprisingly I met resistance from the development team. A former product manager (my predecessor) seems to have explicitly requested the implementation to work this way. Unfortunately, he wasn't big on documenting his decisions, so I now have to try to retrace which reasons could have led to this decision to justify a change in the implementation. I came up with the following pro and contra list:
No way to know if push notification was successfully delivered
Sure there is: have the device hit your server upon receipt of the push message. You might need to do that anyway, if the payload is bigger than 4K.
Scaling push notification delivery can be a pain
It works for fairly large user bases (e.g., RememberTheMilk), and that was even before the XMPP based persistent socket solution.
Are there any other reasons to avoid Push Notifications and use Polling for this usecase?
GCM has no service level guarantee. GCM is Android-specific; you might consider a wrapper around it, like Amazon SNS, if you are looking for something that will handle other client operating systems. Push solutions involving third parties, like Google, means that your raw push message payload will be visible to those third parties' servers; please use suitable app-level encryption if this is a concern (and it should be).
Are there any other reasons to avoid Polling and use Push Notifications for this usecase?
A five-second poll makes $BABY_DEITY
cry.