question

Justin avatar image
Justin asked

Is it acceptable to put AndroidPushID (and iOSPushID) in TitleData so it can be modified remotely?

Trying to setup the Firebase Push and was wondering, beyond the current provided documentation, is there an ideal place to hold the PushIDs in PlayFab Data for our title?

Is it acceptable to put AndroidPushID (and iOSPushID) in TitleData so it can be modified remotely?

Push Notifications
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Seth Du avatar image
Seth Du answered

You are free to store any information in title data and for keys like push notification keys, it is better to store them in TITLE INTERNAL DATA so that client APIs cannot access them.

Be aware that Title Data is a cached resource, and is only meant for use cases where it is not updated frequently.

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Justin avatar image Justin commented ·

"Be aware that Title Data is a cached resource, and is only meant for use cases where it is not updated frequently."

Can you elaborate on why that needs to be considered?

0 Likes 0 ·
brendan avatar image brendan Justin commented ·

Yes, Title Data should only ever be updated by an operation driven from the developer. So, updating the configuration data stored in Title Data for the game as part of an update or game tuning exercise, for example. More specifically, Title Data must never be updated as a result of a client action. The data in question is sharded and cached (so that all players can read it), so it should only be updated occasionally.

1 Like 1 ·
Justin avatar image
Justin answered

@SethDu and @Brendan

I discovered I had setup my PushNotificationsManager script incorrectly.

The OnTokenReceived event seemed to be happening after I was calling RegisterForPush. Obviously, it would fail and return without a pushToken. So I had manually hardcoded the Token, which i'm assuming would be unsecure, so thats why I asked about dropping that Token into InternalData.

After I discovered the flow was messed up I removed the hardcoded Token and it was retrieved dynamically as intended.

Is there actually a reason to capture the Token?

Should each login allow the FirebaseMessaging.TokenReceived += OnTokenReceived event to be called and then run the RegisterForPush? (seems unneeded)

...or should I be caching the Token and checking if the player is already registered somehow?

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Seth Du avatar image Seth Du ♦ commented ·

Hi, I have created a new project to test Android Push Notification via following this tutorial:

The test was successful and there is only one issue when implementing dependencies in Gradle,(the documentation may be outdated because the iteration speed is fast) when clicking Add FCM to your app button in FireBase assistant, make sure configuring like below:

implementation 'com.google.firebase:firebase-core:16.0.3'
implementation 'com.google.firebase:firebase-messaging:17.0.0'

In my point of view, there is no need to manually capture or set the token as the class is encapsulated well in order to handle most of the cases. Some functions in FooAppFirebaseInstanceIdService.java class file in the tutorial is about handling the token in different circumstances, please have a look at this part. In terms of FirebaseInstanceIdService, you need to check the official doucumentation, however as it indicates, this class will be deprecated and see the documents for more details.

Moreover, FireBase is already beyond our support scope and you can send threads at FireBase official community forum for detailed technical supports.

0 Likes 0 ·
Justin avatar image Justin Seth Du ♦ commented ·

Thanks Seth. I'll give that a look.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.