php-fcm
php-fcm copied to clipboard
EdwinHoksberg
FCM: Migrate from legacy HTTP to HTTP v1
Just really writing this as a note, and/or a place for a discussion about it.
So, at the moment we use the FCM API referred to as "HTTP", this is now described as legacy by google, the current one being "HTTP v1".
I didn't realise we were not using the latest version to be honest.
There are some good migration notes on... https://firebase.google.com/docs/cloud-messaging/migrate-v1
Some background on... https://firebase.googleblog.com/2017/11/whats-new-with-fcm-customizing-messages.html
I only noticed when a friend pointed out, on... https://firebase.google.com/docs/cloud-messaging/send-message ...there are two different methods, and this one is described as legacy.
On first glance, it could be a drop-in replacement, but it seems like you need the Firebase project name in the URL, which current users don't have in their configuration settings.
Well since the zombie apocalypse has hit us all maybe we have some time to provide migration path in the project. I think it should be easy enough to do as long as we can provide a user method to input their project ID. The bigger issue though might be the OAuth2 credentials and possibly having to provide instructions on how to set those up in fcm and in our project
Get Outlook for Androidhttps://aka.ms/ghei36
From: Andy Gaskell [email protected] Sent: Thursday, March 26, 2020 9:34:09 AM To: EdwinHoksberg/php-fcm [email protected] Cc: Subscribed [email protected] Subject: [EdwinHoksberg/php-fcm] FCM: Migrate from legacy HTTP to HTTP v1 (#23)
Just really writing this as a note, and/or a place for a discussion about it.
So, at the moment we use the FCM API referred to as "HTTP", this is now described as legacy by google, the current one being "HTTP v1".
I didn't realise we were not using the latest version to be honest.
There are some good migration notes on... https://firebase.google.com/docs/cloud-messaging/migrate-v1
Some background on... https://firebase.googleblog.com/2017/11/whats-new-with-fcm-customizing-messages.html
I only noticed when a friend pointed out, on... https://firebase.google.com/docs/cloud-messaging/send-message ...there are two different methods, and this one is described as legacy.
On first glance, it could be a drop-in replacement, but it seems like you need the Firebase project name in the URL, which current users don't have in their configuration settings.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/EdwinHoksberg/php-fcm/issues/23, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC4XUCIYFFH7AB3DZMCUSMDRJNKVDANCNFSM4LUHO62A.
Yea, no rush really, the older API hasn't had an end of life date set or anything.
Just thought I'd jot this down so it was kinda on the radar.
@AndyGaskell - for sending notifications, our methods allow for adding as many recipients via addRecipient and another method that allows for passing an array of recipients. Sending notifications allows for this. But are you aware of a FCM method that could allow us to send an array (or bulk) tokenIDs for the deviceInfo? I want to send a mass array of 1,000 tokenIDs to see which of those tokenIDs are no longer valid - and then remove them from my DB.
We need to constantly cull the database to determine which IDs are invalid, and then use alternate communication methods (sms/email) to reach those users.
Additionally, every time our app starts it validates/updates the users tokenID - now this happens regardless of whether or not the user has enabled/disabled push notifications from our app. We can check this every time the user starts the app - but what about if they disable push notifications and don't start up the app? Is there any known FCM method to check to see if the tokenID has turned off push notifications? Again, we need to update our DB so we know that even if the tokenID is valid, the user disabled push notifications - so then we can use an alternate communications method.
can somebody help to understand that , do we have to change payload's structure in order to send message if we are migrating from legacy HTTP to HTTP v1. Thanks
Yup, confirmed. June 20th next year. Clock is now ticking. @AndyGaskell - my projects are dependent on this repository; as it looks like others are as well. Lets have a chat about what we can do, add in developers and get this migrated to the new version.
Hi @rolinger
Yea, it'd be good to chat it through. Hopefully we'll be able to change the package and keep the interface the same. It'd probably be a jump from v1.2.0 to v2.0.0.
The notes on... https://firebase.google.com/docs/cloud-messaging/migrate-v1 ...make it sound not too bad to do.
We've still got nearly a year, but perhaps we could aim to have it done 6 or 9 months before the EOL, to give people time to update.