GCM Depreciation

[jonnott]

Google have announced that GCM is being removed/switched-off a year from now, in favour of FCM (Firebase) only.

This codebase is already using the FCM endpoint URIs, but is there anything else that needs to change before April 2019? https://developers.google.com/cloud-messaging/android/android-migrate-fcm

Also, as GCM is being phased out, is there a case for renaming this to *_Fcm rather than *_Gcm? Or will that just cause a needless BC break? Is there a nice way to mitigate such a change?

Feel free to just close this issue if there's really nothing that needs addressing..

[weierophinney]

@mwillbanks Can you comment? I'm not sure where development in this component currently stands...

[mwillbanks]

@jonnott @weierophinney I think the best approach forward would be for someone that is interested in this component to rewrite it to the latest standards. The namespace should be changed, new approaches specifically with PSR-7 and possibly leveraging PSR-11.

I had originally planned to rewrite this component 2 years ago but provided the number of changes and my lack in current development on android I am not best in position to rewrite the component.

[jonnott]

@mwillbanks @weierophinney I don't see a need to rewrite it - the format of the server API and the endpoints aren't due to change (just the client-side Android SDKs must change), and I can confirm it's working just fine for me in production right now.

Just wondered if there were any small tweaks/improvements that might be useful, which a more involved Android dev might know about..?

Also, there's the question of naming, as the GCM service is being phased out (the component is using the Firebase FCM endpoints already anyway, so it's already effectively FCM not GCM).

If it needs namespace changes to bring it in line with other ZF components, that's probably a good idea. Would that mean a breaking change, or would composer take care of all that?

[mwillbanks]

@jonnott so the rewrite would mainly be for 2 specific reasons, 1 is to bring it in-line with other components using proper namespaces, PHP 7 type hinting, the latest PSR's, etc. The FCM endpoints technically work right now but the features of such are supported only by nature of non-breaking changes which means that the API is not particularly done well.

Also the dependencies of the ZF libraries are not necessary with most of the PSR's that now exist, meaning that the RequestInterface's could be leveraged instead to allow for different HTTP clients to be leveraged thus providing less dependencies and further developer choice.

It would certainly be a breaking change, but I would view that as a good thing. In that this component could be deprecated with a migration plan to a new component.

[camry]

@jonnott I am using this SDK and the client has not received a notification. However, my use of FCM is normal.

example: #36