Description:
I'm sending p2p notification similar to this:
{"p2p_notification":{"senderId":"MkCRZlyCLSd9kf3oByM5mcOSxrh1","timestamp":1559940935689}}
what the android client receives is this:
"senderId":"MkCRZlyCLSd9kf3oByM5mcOSxrh1"
Strings are working fine, but the number attribute is omitted. I can see that the data is sent correctly from onesignal website 'message report', it's something on the receiving end on Android.
iOS is working properly.
Environment
Latest version, 3.2.14 from npm
Steps to Reproduce Issue:
const data = { 'senderId': sender, timestamp: unixTime, action: action }
OneSignal.postNotification('test', { string: 'abc', number: 123 }, second_client_id)
Hello,
Thank you for reporting this. Sounds like a bug. Thank you for your patience while we reproduce and look further into this issue
Hello,
Taking a closer look at your code snippet, it looks like you aren't following the correct format. It should look something like:
OneSignal.postNotification({"en": "This is the message"}, {key1:"this", key2:"that"}, "81145769-e762-4ad1-89df-02aa4ef466a1");
Please see our docs for more info
@rgomezp That was just a simplification of the snippet, I have the correct format (just as you shown) in my application. It's definitely a bug.
@EskelCz ,
Try putting quotation marks around the number
@rgomezp Sure, I can make it a string and then parse int on the other side. That is what I use now as a workaround. The whole purpose of this issue was to avoid this operation.
Right, thanks for bringing up the bug. We will look into getting it fixed
Just curious, what device are you testing with and what's its CPU
One of the cheapest recent Androids, Xiaomi Redmi 6A. CPU is ARM Cortex-A53
After doing some testing, it looks like this happens with P2P notifications on Android devices. Numbers only get excluded if they are 64 bit numbers in additionalData
e.g: If the number is less than 2147483647 (largest possible 32 bit number) but greater than 9223372036854775807 (largest possible 64 bit number) then it will display correctly, with numbers > 64 bits shown in scientific notation
@rgomezp thanks for doing the testing. in my case it was indeed a 64bit number, to carry a unix timestamp from javascript's Date.valueOf(), which is precise to milliseconds.
I can probably reduce the precision to stay within 32 bits, but still, can this be changed, for the sake of consistency?
Yes. We have already made a note to change this for a future release. Thanks for finding this bug!