Announcement

Collapse
No announcement yet.

Is the 124kB limit forever?

Collapse
X
  • Time
  • Show
Clear All
new posts

  • 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.
    raceQs sailboat racing app.

  • #2
    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.
    My Connect IQ Apps in the Store
    Facebook - Instagram -
    Twitter

    Comment


    • #3
      So it's a hardware limitation?
      Is there a reference for the memory capacity of different devices?
      raceQs sailboat racing app.

      Comment


      • #4
        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.
        My Connect IQ Apps in the Store
        Facebook - Instagram -
        Twitter

        Comment


        • #5
          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:
          Code Name web request result
          fenix 5 / quatix 5 success
          forerunner 645 success
          forerunner 645 Music responseCode:-400
          fenix 5 plus responseCode:-400
          fenix 5 S success
          fenix 5S Plus responseCode:-400
          fenix 5X / tactix Charlie success
          fenix 5X Plus responseCode:-400
          fenix Chronos success
          Forerunner 935 success
          vivoactive HR success
          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.

          raceQs sailboat racing app.

          Comment


          • #6
            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:
            1. 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.
            2. 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
            3. 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.

            Comment


            • #7
              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

              Comment


              • #8
                Originally posted by Travis.ConnectIQ View Post
                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

                Comment


                • #9
                  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.
                  My Connect IQ Apps in the Store
                  Facebook - Instagram -
                  Twitter

                  Comment


                  • #10
                    Originally posted by WillNorthYork View Post
                    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.

                    Comment


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

                      Comment


                      • #12
                        Lots of responses, many thanks, I'm working through them.
                        Originally posted by Travis.ConnectIQ View Post
                        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?
                        Originally posted by Travis.ConnectIQ View Post
                        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.


                        raceQs sailboat racing app.

                        Comment


                        • #13
                          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/1uqV...ew?usp=sharing
                          raceQs sailboat racing app.

                          Comment


                          • #14
                            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:
                            1. 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.
                            2. 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
                            3. 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.
                            Last edited by WillNorthYork; 11-05-2018, 06:41 PM.

                            Comment


                            • #15
                              I am requesting JSON:
                              Code:
                              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
                              Code:
                               :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON
                              I'll see if I can force Content-Type application/json at the server.
                              raceQs sailboat racing app.

                              Comment

                              Working...
                              X