makeWebRequest 201 response code with POST

One thing here is are you getting a 201 or a -201?  The codes that are negative numbers are defined in the API doc.

I'm going to guess and say it's a -201, and one case you'll see that (for now - it's a reported bug) is if you try to include a double or a long in the makeWebRequest with iOS.  If you have access to the server log, you'll also see the request doesn't make it that far.

Blimey, good catch! It is indeed a -201 code. I feel like someone at Garmin should get a demerit for using such a confusing code

I'll try changing the variables and see if I can fix it. Thanks again!

That's worked perfectly, thanks! I just casted my variables to floats and longs and we're all good. It's not even like the values needed to be the big versions so nothing lost in this solution.

Floats and numbers.  Longs are a problem with iOs.

For stuff with comm, it's good if you mention iOS/Android, as this is something that works fine on Android.

The negative is nice as you see right away it's from CIQ and not from the server.  And after a bit you know what they mean

I was one of the people that reported the problem with double, and in fact was talking to one of the Garmin folks at the summit this week, and it sounds like it's fixed, but not out to the world yet.

As you say, it's nice if you know it's there. They do have complete control over the "data" parameter though, so could just as easily return a string with actual information in it. looking up error codes was OK in 1994 but it's 2019 now and we can afford a few Bytes to be descriptive.

Sounds like I should have spent this weekend drinking wine instead, I may never have hit the issue if I delayed a bit

Numeric codes are far easier to use in code where you can react to the different errors.  And with a string, you also run into the translation thing.  -201 is the same in every language.

In CIQ, a few bytes can mean a great deal.  There's not a huge amount of memory here, when you consider what's available on the earlier devices - a Data field can be at most 16k on some, and on some with backgrounding, it's at most 32k for the background (code and data)

I agree about numeric codes, but there is a data payload there too, and it's coming from the mobile app so in theory device memory shouldn't make a difference. Luckily I'm old enough to remember what you can do with 16KB and it's practically a book! :)

Especially when you do comm from a background process, every byte is needed.  The practical limit for data is about 8k, and when the watch gets that it must be converted into a dictionary if it's json data, so there's an extra memory hit.

-201 and a few more you can see at times, but the most common with users might be -2 (a timeout).  As far as the phone is concerned, the request was sent, but nothing was heard back to the CIQ device.  This could be a loss of BLE (walking out of range) or maybe a loss of the cell connection

jim_m_58 said:

I was one of the people that reported the problem with double