Is the 124kB limit forever?

Here's a question for Garmin.
Is the 124kB limit in CIQ2,3 a forever hardware limit or is it an arbitrary value that someone set, thinking "that should be plenty"?
I see that CIQ is somewhere in between Pebble, which had 56 Kb for compiled C code and WatchOS where there is effectively no limit (think scores of megabytes) for Swift code, and the Garmin watch does appear to have plenty of space for storing files. Not knowing anything of the device architecture, I can't know how appropriate the question is.
Is it possible, for example, that next year we'll see CIQ 4 with the capacity upped by a decimal point to 1.2Mb?
I'm just asking because I'm spending an inordinate amount of time and effort squeezing my app into the current space.

Alan.raceQs over 6 years ago

Lots of responses, many thanks, I'm working through them.

We are given memory budgets by device teams....

That confirms my original question, that the limit is hardware and not the whim of an engineer. I just wonder why the limit was so mean on the 124kB devices?

If you want to ensure that you're testing the same code path, you need to click Settings > Connection Type > WiFi > Not Connected prior to making the call to makeWebRequest.

I have just re-run the test in the sim on a f645m and fr935 . In both cases, Settings > Connection Type > WiFi > returns Connected. It runs on fr935 but fails on f645m with the -400 error.
I am running a canned test using exactly the same data in the makeWebRequest on both devices.

I'll look a the HTTP traffic on working vs failing tests to see if I can spot the differences.

Alan.raceQs over 6 years ago

I have had some experience with HTTP, but am a no expert. I have captured the trace from fail -400 on f645 and success on fr935 attached.
I wonder if the traffic before the GET is significant?
Otherwise I can't spot the difference except for the Set Cookie in f4935
I'm getting unhelpful errors when trying to upload the attachment ( http3.png, 794KB) so have put it on google drive:
https://drive.google.com/file/d/1uqVwQofc5DGmhSZxZ6I72kDbKDI3t4yA/view?usp=sharing

WillNorthYork over 6 years ago

RaceQs it's a little hard to tell from the screenshot, but it looks like the response content is JSON whereas the response Content-Type is text/html -- it should be application/json.

As Travis mentioned, if you explicitly set the response content type in the call, and the returned content-type does not match, the Wi-Fi stack will return an error.

The -400 response code occurs under three conditions:
You explicitly specify the content type of the response as an option to makeWebRequest(), and the server sends back a response with a Content-Type header that does not match.
You do not explicitly specify the content type of the response, and the server sends back a response with a Content-Type header that isn't known
You do not specify the content-type of the response, the server sends back a response with a known Content-Type, but the body of the message cannot be parsed for some reason.
Typically the issue is #1. You set :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON, but the server is sending back a Content-Type: text/plain header. Currently, the easy fix is to remove the :responseType option from the request.

If you're not explicitly adding responseType to makeWebRequest(), I can only speculate that, in this case, makeWebRequest() won't detect JSON content if the Content-Type is text/html (i.e. case 2 above), in which case you might need to get this fixed on the server side, or proxy it.

Alan.raceQs over 6 years ago

I am requesting JSON:

Comm.makeWebRequest(
            url,
             params, // 0 if not set
            {   :headers => headers,
                :method => Comm.HTTP_REQUEST_METHOD_GET,
                :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON
            },
            method(:receiveMarks)
        ) ;

and getting the same content back with both devices, so why would it succeed on fr935 and fail on fr645m?
Same response: success on fr935, fail on fr645m with or without
:responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON

I'll see if I can force Content-Type application/json at the server.

Alan.raceQs over 6 years ago

Interesting.
I changed the server to send "Content-Type application/json", and that fixed the problem.
Seems the fr645m is sensitive, but the fr935 is insensitive to this setting.
I've been in blissful ignorance until the new devices arrived.

Thanks for the advice.

WillNorthYork over 6 years ago

No problem.

Travis.ConnectIQ over 6 years ago

In both cases, Settings > Connection Type > WiFi > returns Connected.

By default this will be Connected for all devices with music support. As I said originally, if you want to disable the WiFi code path (and avoid this inconsistency) you need to change the value to Not Available before making the call to makeWebRequest().

I am requesting JSON .. and getting the same content back with both devices, so why would it succeed on fr935 and fail on fr645m?

I explained this above...

There are some differences in behavior when making requests over WiFi versus over Bluetooth.

If you want to avoid the problem in the short term, you can disable the WiFi code path in testing as I mentioned above. To fix the problem, you'll have to either update your service to produce the appropriate headers to match the actual content, or write a wrapper around the service you are accessing.

Alan.raceQs over 6 years ago

OK, All cleared up.
I did not fully recognise that these newer devices had their own WiFi. Sorry, I'm only recently re-acquaintng myself with the Garmin devices.
That explains why the behaviour differs.
The difference is now clear to me: the older devices are relying on HTTP connectivity from the phone which seems insensitive to the incoming headers , whereas the newer devices have their own WiFi capability which is sensitive. With WiFi "Not Connected" they operate the same, with WiFi Connected, they are using the device's WiFi.
So much to learn... so little time:(
Many thanks for your patient assistance.

jim_m_58 over 6 years ago

The thing is Travis, should a non music provider app ever take the code path for a wifi connection in the sim? That's not what happens on devices.

Travis.ConnectIQ over 6 years ago

That was my initial understanding, but that has been amended a bit. At this time, access to WiFi is passive for non-music app types. If the WiFi happens to be on at the time makeWebRequest() is called, the request would go out over WiFi.

I don't know of any plans, but it is possible that this could change in the future.