gcm.jar v1.0.2 to FCM migration questions

[Jake]

I am currently working on a project using the deprecated gcm.jar (GCM version 1.0.2) and I want to update to the new Firebase Cloud messaging platform but have some questions about doing so. The google documentation about transitioning is about transitioning from the newer instanceID based version of GCM(3.0) to FCM and it seems straightforward since they both used the same instanceID implementations. The old gcm.jar uses registration tokens and it's not clear if the migration to FCM is as seamless as the documentation states that it is for v3.0.



After reading the documentation and exhausting my google search skills I still have questions about making the change.

Does importing the gcm project into the firebase console invalidate the current API key? I don't want to break notifications for existing users if I have to update the api key used on the server side. If so, can I create a new FCM project for the same application so that I can implement FCM for new client versions but maintain the current GCM implementation for current client versions?

I know that the transition from instanceID GCM to FCM doesn't require any server changes. Will I need to change my server/database implementation for registration tokens? (Do pre-instanceID tokens have the same format as the current tokens?)

Thanks,

Jake

[Diego Giorgini]

On Mon, Dec 12, 2016 at 9:12 AM Jake <jadelg...@gmail.com> wrote:

I am currently working on a project using the deprecated gcm.jar (GCM version 1.0.2) and I want to update to the new Firebase Cloud messaging platform but have some questions about doing so. 

Does importing the gcm project into the firebase console invalidate the current API key? I don't want to break notifications for existing users if I have to update the api key used on the server side.

Importing a project in the firebase console should NOT invalidate the current API-key.

unfortunately in the past we had issues around this, and we could not help too much since those keys are managed by the Google Cloud team.

I would suggest to be ready to update the api-key in your server, in case something goes wrong.

As long as you can update the api-key in the server you should not break notifications for existing users.

 

If so, can I create a new FCM project for the same application so that I can implement FCM for new client versions but maintain the current GCM implementation for current client versions?

You can create a new project, but you will receive a different sender-id / api-key.
This means that you will need to keep track which token was generated by which version, and use the correct API-KEY when sending to the specific version.

I know that the transition from instanceID GCM to FCM doesn't require any server changes. Will I need to change my server/database implementation for registration tokens? (Do pre-instanceID tokens have the same format as the current tokens?)

pre-instanceID tokens are shorter than the InstanceId tokens.

please configure your DB to be flexible on the size of the token.

[Jake]

Diego,

thank you for clarifying the API key issue. I know ideally we wouldn't have to change it but it's good to know we should be alert when migrating the project. The current database will allow us to store tokens of various lengths so things should be ok there.

If I update the endpoint from the GCM endpoint to the FCM endpoint on my server I could still send requests from devices that use the old gcm registration, correct?

Additionally, If I understand correctly from the documentation the request body format is the same between the old version of GCM, the current version of GCM, and the new FCM so I really shouldn't have to make any changes to my server implementation, right?

Thanks,

Jake

[Diego Giorgini]

On Mon, Dec 12, 2016 at 1:17 PM Jake <jadelg...@gmail.com> wrote:

Diego,

thank you for clarifying the API key issue. I know ideally we wouldn't have to change it but it's good to know we should be alert when migrating the project. The current database will allow us to store tokens of various lengths so things should be ok there.

If I update the endpoint from the GCM endpoint to the FCM endpoint on my server I could still send requests from devices that use the old gcm registration, correct?

Correct. Both the endpoints point to the same internal infrastructure. 

 

Additionally, If I understand correctly from the documentation the request body format is the same between the old version of GCM, the current version of GCM, and the new FCM so I really shouldn't have to make any changes to my server implementation, right?

Correct.  Only note:

the "notification-messages" require the client to have a recent* sdk.

if you send a notification-message to an old app it will be received as a normal "data-message"

*recent = current GCM or current FCM

https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages 

 

On Monday, December 12, 2016 at 1:36:21 PM UTC-5, Diego Giorgini wrote:

On Mon, Dec 12, 2016 at 9:12 AM Jake <jadelg...@gmail.com> wrote:

I am currently working on a project using the deprecated gcm.jar (GCM version 1.0.2) and I want to update to the new Firebase Cloud messaging platform but have some questions about doing so. 

Does importing the gcm project into the firebase console invalidate the current API key? I don't want to break notifications for existing users if I have to update the api key used on the server side.

Importing a project in the firebase console should NOT invalidate the current API-key.

unfortunately in the past we had issues around this, and we could not help too much since those keys are managed by the Google Cloud team.

I would suggest to be ready to update the api-key in your server, in case something goes wrong.

As long as you can update the api-key in the server you should not break notifications for existing users.

 

If so, can I create a new FCM project for the same application so that I can implement FCM for new client versions but maintain the current GCM implementation for current client versions?

You can create a new project, but you will receive a different sender-id / api-key.
This means that you will need to keep track which token was generated by which version, and use the correct API-KEY when sending to the specific version.

I know that the transition from instanceID GCM to FCM doesn't require any server changes. Will I need to change my server/database implementation for registration tokens? (Do pre-instanceID tokens have the same format as the current tokens?)

pre-instanceID tokens are shorter than the InstanceId tokens.

please configure your DB to be flexible on the size of the token.

--
You received this message because you are subscribed to the Google Groups "android-gcm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-gcm...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-gcm/4a655da5-8edc-4b73-abfc-275f0115faff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jake]

do messages default to data messages if the type is unspecified?

Thanks,

Jake

[Diego Giorgini]

On Tue, Dec 13, 2016 at 8:13 AM Jake <jadelg...@gmail.com> wrote:

do messages default to data messages if the type is unspecified?

The type of the message is specified by the payload you are sending.

If you are using the "notification" key in your request, then you are sending a notification-message.

If you are only using the "data" key in your request, (and no "notification" key) then you are sending a data-message

 

To view this discussion on the web visit https://groups.google.com/d/msgid/android-gcm/89d046c2-9b4e-4bb2-bace-22952c404ab1%40googlegroups.com.

[Massimiliano]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
LOAN DEAL
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7529 555638