Android Long Integer lossy (native function parameter) casting conversion

[Informate]

I have searched and made sure there are no existing issues for the issue I am filing

• I have searched the existing issues

Description

The long integer conversion is not consistent between Android and iOS. Especially I found it in the Ti.Network.HTTPClient send method and in the alert function.
In Android the send method performs a data type conversion error on the POST request parameters, while on iOS the conversion is done correctly.
Also with the alert function the same problem is present.
The long integer seems to be casted to a double instead of remaining a long integer.
The long integer data type is wrongly converted to scientific notation format, corrupting for example timestamps generated by Date.now().

It appears that if the toString conversion is done at JavaScript level is correct, while if done at Java level is wrong!

FIXING WORKAROUND: Convert the long integer to String before passing it to the send method!

Expected Behavior

Consistent behaviour between iOS and Android.
Non lossy data transfer and integrity of long integer data types.

Actual behavior

Android wrongly converts long integer to float scentific notation.

Reproducible sample

alert(Date.now());

HttpClientInstance.send( { timestamp: Date.now() } );

FIXING WORKAROUND: HttpClientInstance.send( { timestamp: Date.now().toString() } );

Steps to reproduce

Just invoke: alert(Date.now());
But this works: alert(({ts:Date.now()}).ts+'');
because the conversion is done outside the function call.

Crate an instance of HTTPClient, and make a request with a long integer in the parameters of the first argument of the send method, for example using Date.now().

Platform

Android

SDK version you are using

12.3.0.GA

Alloy version you are using

No response

[m1ga]

Not have any solution here but I've set a breakpoint in the send method and I can see that the parameter that is passed to that method is already a double:

[Informate]

Not have any solution here but I've set a breakpoint in the send method and I can see that the parameter that is passed to that method is already a double:

Thanks for your great support, maybe the problem occurs even then when the object attribute is set? Can you confirm that you initially see the number correctly, and that it is not the debugger doing the conversion incorrectly?

[m1ga]

yes, I'm setting 12345678901 as a value (or Date.now()).

[Informate]

yes, I'm setting 12345678901 as a value (or Date.now()).

It seems to be Date.now() being cast to Double instead of Long then (Inside Java I suppose). But is working correctly when returned by Date.now() as toString() is doing right.

[m1ga]

correct. But it's all long numbers. With to String it will be a string so it doesn't need to convert it. But I don't know at which point the conversion is

[Informate]

correct. But it's all long numbers. With to String it will be a string so it doesn't need to convert it. But I don't know at which point the conversion is

No, the Debugger is doing wrong!! :-/
It's not only send, but also the alert function called with Date.now() to rise the error!
I suppose that: If the toString conversion is done at JS level is ok, while if done at Java level is wrong!

[m1ga]

I suppose that: If the toString conversion is done at JS level is ok, while if done at Java level is wrong!

I don't think it is doing a toString in Java as it still shows it as a number (double as you can see in the debug screenshot). But still: not a long as it should be.

[Informate]

I knew that JS try to fit all the datatypes in one putting pointers and other into the NaN space, but the long should not fit into a double NaN space. So I do not know what's happening...