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.

jim_m_58 over 6 years ago

It varies by device for a device app. For example, on a 645m and plus devices, it's over 1meg today. It's based on how much memory is available on the device.

Alan.raceQs over 6 years ago

So it's a hardware limitation?
Is there a reference for the memory capacity of different devices?

jim_m_58 over 6 years ago

It might be in the UX guide, but the best reference is the SDK - either by running different targets and looking at the bottom line in the sim or looking at devices.xml is the SDK.

Alan.raceQs over 6 years ago

I couldn't find any reference in the UX guide, so have slogged though the devices in the sim and have found the memory size as you described.
However, I'm getting an unexpected result from makeWebRequest on most of the large memory devices,
Here's my result: [TABLE="border: 1, cellpadding: 1, width: 500"]
[TR]
[TD]Code[/TD]
[TD]Name[/TD]
[TD]web request result[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5 / quatix 5[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]forerunner 645[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]forerunner 645 Music[/TD]
[TD]responseCode:-400[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5 plus[/TD]
[TD]responseCode:-400[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5 S[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5S Plus[/TD]
[TD]responseCode:-400[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5X / tactix Charlie[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix 5X Plus[/TD]
[TD]responseCode:-400[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]fenix Chronos[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]Forerunner 935[/TD]
[TD]success[/TD]
[/TR]
[TR]
[TD] [/TD]
[TD]vivoactive HR[/TD]
[TD]success[/TD]
[/TR]
[/TABLE]

Any idea why the fr645m, fenix5plus, fenix5splus and fenix5xplus all fail with Response code -400 on the makeWebRequest?
I'm doing a controlled test keeping all other variables fixed, in order to monitor actual memory usage.

Travis.ConnectIQ over 6 years ago

The devices you mention all have WiFi support. There are some differences in behavior when making requests over WiFi versus over Bluetooth. We're trying to find and eliminate all of them, but there is still work to do.

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 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.

Travis.ConnectIQ over 6 years ago

Back to your original question... I don't really understand what you're asking.

We are given memory budgets by device teams. If a new device came out tomorrow and we were told we could have 256MB or RAM for ConnectIQ, then you'd probably have access to all 256MB when that device was made available. That said, I don't really understand how this helps you develop an app today for hardware and software that is currently available.

Additionally, you don't need to build a test app to find out what the memory limits are. You can just take a peek at ${SDKROOT}/bin/devices.xml and look for memory_limit. These are the limits that we've been given. We enforce them in the simulator and on devices.

Travis

WillNorthYork over 6 years ago

The devices you mention all have WiFi support. There are some differences in behavior when making requests over WiFi versus over Bluetooth. We're trying to find and eliminate all of them, but there is still work to do.
...
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.

But FR645 and FR935 have Wi-Fi support, and yet they return a different value than FR645M/F5Plus etc. So it can't be WiFi vs Bluetooth.

Then again, the F5X and F5XPlus seem to have the same amount of RAM (at least judging by the app memory limits), so it can't be memory size either. Both of those watches also seem to support Wi-Fi.

Maybe the real issue is with devices that support music. Looking at that list, it seems that every device which fails supports music, and every device which succeeds does not support music. It would be interesting if VA3 and VA3M were also tested in the same way

jim_m_58 over 6 years ago

CIQ wise, there is access to wifi on music device (to download music in music provider apps) while there isn't CIQ access to wifi on non-music apps.

That said, my apps that do makeWebRequet calls are working fine on music devices in the sim, so it seems that there's something with the parameters or options (or maybe the site) RaceQs is using. In the sim, you might see something interesting in "file>view HTTP traffic" and comparing a working vs a non working device.

It could also be that the calls will work fine on a device, but you see an error in the sim.

Travis.ConnectIQ over 6 years ago

But FR645 and FR935 have Wi-Fi support, and yet they return a different value than FR645M/F5Plus etc. So it can't be WiFi vs Bluetooth.

If you run the simulator with the fr645 or fr935 and you go to the Connection Type menu as mentioned above, the WiFi menu item is *disabled* for these devices. This is because the WiFi support I'm talking about is only available to devices with music.

And to be clear, you would see the the -400 error for WiFi and not Bluetooth if the Content-Type headers are mismatched and the message body could still be parsed using the content type specified by the :responseType option. Again, this typically occurs when the server sends a Content-Type: text/plain header with JSON formatted response body.

RaceQs could verify this by using cURL to show the web response.

WillNorthYork over 6 years ago

jim_m_58 Travis.ConnectIQ thanks for the clarification. Sorry for assuming/jumping to conclusions