Comm.makeWebRequest Bug - when sending boolean parameters

We'll look into this. I'm assuming you're using the 2.2.1 SDK?

yes 2.2.1

Yes, I'm using 2.2.1!

A test using 2.1.5 showed the same result.

The bug happens when I'm using the device simulator. I did not run a test on a real device so far.

I see the same behaviour if I use 1.2.11 with makeJsonRequest

It is actually much worse than what is being reported. It looks like Lang.Double and Lang.Long values are omitted entirely when using both makeWebRequest() and makeJsonRequest(). Given the following parameters...

var params = {
"Number" => 1,
"Long" => 2l,
"Float" => 3.0,
"Double" => 4.0d,
"Boolean" => true,
"String" => "abc"
};


I see this when sending them with a get request...

> 2016-11-12 21:41:49 > GET /?Double=&Long=&Number=1&Boolean=1&Float=3&String=abc HTTP/1.1
User-Agent: Mozilla/5.0
Host: localhost:8081
Accept: */*
Content-Type: application/x-www-form-urlencoded


If I change the http method to a PUT/POST, which causes the parameters to be sent in the body, I see what appears to be malformed JSON...

> 2016-11-12 21:50:54 > PUT / HTTP/1.1
User-Agent: Mozilla/5.0
Host: localhost:8081
Accept: */*
Content-Type: application/json
Content-Length: 72

{"Double":, "Long":, "Number":1, "Boolean":1, "Float":3, "String":"abc"}


Travis

Thank you Travis for clarifying!!

I've updated this ticket to include the steps from Travis and pushed down the line to be fixed. Thank you as always for helping us find things to fix!

-Coleman

Do you have an idea when can we expect a solution for this problem?

I was looking for someone who had the same problem and found this post.
I've had the problem with json boolean values when using makeWebRequest method.

As Stenninger asked, we'll have a solution soon?
Thanks in advance.

Hey Everyone,

I wanted to give you an update on this. We have done the investigation and work on our side and have now pushed the next portion of the fix to the the Garmin Connect team involved. Unfortunately, it's a bit of a waiting game on that now, but I wanted to keep you all up to date.

-Coleman

I tested it yesterday (06.02.2017) again, using v2.2.4.
But the problem is still existing!