Android Question [solved] FCM push service using jetty

[udg]

Hi all,
I'm in the process of updating my FCM dispatcher hosted by a multi-purpose jetty server ran on a VPS.
Fundamentally, some desktop and mobile apps are allowed to send "packets" to an handler and, based on some internal rules, an FCM message is sent to a topic or a single device.

Reading the updated FCM tutorial, I have a few questions.

Token renewal
1. I've read that a token expires in 60 minutes. So, keeping track of the last time it was requested, I guess it will be safe to execute GetTokenValue after at least 30 minutes from last request instead of requesting it for each message.
2. InputStream. To get GoogleCredentials we have:
<code>
GoogleCredentials.RunMethodJO("fromStream", Array(File.OpenInput(FilePath, ""))
</code>
Would it be wrong to have a statement like
<code>
Private SAInputStream As InputStream = File.OpenInput(ServiceAccountFilePath, "")
'....
'Private Sub GetTokenValue (FilePath As String) As String
'...
Dim Credentials As JavaObject = GoogleCredentials.RunMethodJO("fromStream", Array(SAInputStream))
</code>
thus reading from the disk file just once?
3. In original code, could repeatedly calling File.OpenInput leads to memory leaks since nothing closes the stream? I understand that the original code is terminated after sending the first and only test message (ExitApplication in sub Send), but what about the above described use case?

FCM messages
While writing this post I can't recall where to read about different styles of messages. I've got some notes somewhere..
Hoping that Goggle didn't change that aspect too. Anyway, we will found it.

TIA

 

[Erel]

What happens if you call GetTokenValue every time?

Is it too slow?

 

[udg]

Actually I don't know. My concern is more about Google "getting upset" to receive many (not needed) Token refresh messages.
So I thought about reducing the number of times GetTokenValue is called.

Anyway, can you comment on points 2 and 3 above? I really don't know how InputStream works so they could be totally wrong.

Thank you.

 

[Erel]

It is a good idea to close the stream.

Unless you are sending massive amounts of messages then better to get the token each time. Don't worry about reading the file. It will be very fast.

 

[udg]

Attention: logical bug!
In post #1, point 1) the description as is would lead to a logical bug.
I write this for those who may like the idea, although @Erel clarified that, generally speaking, it's better to ask each time fo the token.
So, if you have not a very good reason to do it another way, stick to his advice.

The bug
If we just keep note of the time of the last token request, we could end up with a situation like the following:

• time_0 : first call to GetTokenValue and saving of time
• time +30: no call to GetTokenValue , the token should be valid. OK
• time +45: call to GetTokenValue (since 30 minutes are elapsed from last call), but the token received is identical to the current one. As for point 1) as is, we save this time as the new time_0
• time (original) +65 (i.e. new time +20): we don't call GetTokenValue since we are in the new "30 minutes slot" since last call, but Google invalidated the current token because 60 minutes are elapsed since it originally released it. Conclusion: our call to FCM will fail.

So, if you want to act along the lines of point 1) you should save both the Token and the time it was released then at time +45 (using the above example) you don't change the time because the retuned token is identical to the current (in use) one.
This way, when you arrive a time+65 you call GetTokenValue (as you did at time +45) but this time you will receive a new token. Now is safe to save again both token and time, starting the logical loop from the beginning.

Again, this post is intented just as a warning for those who quickly read post#1 and acted accordingly without a deeper analysis.

udg