• Replies 8 replies
  • Subscribers 17 subscribers
  • Views 1221 views
  • Users 0 members are here
Options
Related

-403 VS -402

cmehmen
over 5 years ago

I'm making a webrequest and I'm currently getting a -403 response for my 935 ( I have about 13KB of free memory when I make this request), the JSON I'm receiving is ~4.7KB.

As stated in the API documentation;

NETWORK_RESPONSE_TOO_LARGE = -402
Serialized response was too large.
Since:
1.0.0
NETWORK_RESPONSE_OUT_OF_MEMORY = -403
Ran out of memory processing network response.
Since:
3.0.0

My questions are;

For a -402 response, What is the largest network response a watch can receive?

For a -403 response, is this an issue present with available memory on the device? say I have 5kb of free space but the network response is 6kb, is this what throws a -403?

Thanks

  • over 5 years ago

    Are you doing this in a background service of in the main app?

    Background processes have less memory than the main app  You can use Sys,getStstemStats().availableMemory in the background to see what you have there.

    And with 4.7kb, that's the number of characters in the json, and when it gets to the watch, it needs to be converted to a dictionary, and that takes more memory - possibly double  (and the number of entries in the dictionary can cause even more)

  • over 5 years ago in reply to jim_m_58

    I'm doing this in the main app. Okay, that makes more sense, thanks, Jim.

    Do you know if it possible to filter the request on the watch before this error occurs?

  • over 5 years ago in reply to cmehmen

    If you're tight on memory what others have done is set up a proxy that reduces what's sent to the watch.

  • over 5 years ago

    As said..

    • A -402 occurs when the raw response data is larger than the available memory (we didn't even have enough room for the raw text of the response).
    • A -403 occurs when the data was small enough to fit into available memory but converting it to the expected output format failed because of lack of memory.

    In your example you have 5K of memory available and the response that comes back is 6K; I'd expect a -402. If the response was 4K and we try to convert that response to JSON and that fails because the in-memory JSON representation has overhead you'd get a -403.

    If you are running out of memory trying to get a web response, the typical solution is to find a way to reduce the size of the response. This can often be done through data pagination, filtering, or in some cases using a proxy to filter/reduce/convert the data to a more efficient format.

  • over 5 years ago in reply to Travis.ConnectIQ
    Travis.ConnectIQ said:
    This can often be done through data pagination, filtering, or in some cases using a proxy to filter/reduce/convert the data to a more efficient format.

    When you say filter, are you referring to the filter in the API, would that filter out the information in time?

    Thanks, Travis, your replies are always very detailed and helpful.

  • over 5 years ago in reply to cmehmen

    That would be filtering by  the server providing the data, so you don't get as much.  Say requesting 3 days worth of data instead of 5.

  • over 5 years ago in reply to cmehmen
    cmehmen said:
    When you say filter, are you referring to the filter in the API, would that filter out the information in time?

    Sorry I wasn't clear about that... I mean something like what is talking about.

    Typically a web service returns a bunch of data that your application does not need. Sometimes a service will allow you to provide a parameter that tells it what data you are interested in as a request parameter (e.g., data=age,height,weight) or to request a window of data (e.g., start=4&count=2 to request two items starting at the fourth). If the service doesn't provide this, you can sometimes setup a web service front-end that takes a request from your ConnectIQ app, makes the request from the original web service, and then cuts out the data that you don't need.

    By eliminating unnecessary data in the response, your application will perform better (downloading large JSON documents over a BLE connection can be painfully slow) and you'll avoid the dreaded out-of-memory errors that you're bumping into.

    The downside is that you may have to learn a new language and figure out hot to setup a hosted web service.

  • over 5 years ago in reply to jim_m_58

    Here for example of what you could do in darksky - tell it to exclude things to reduce what you get back:

    var param={"exclude" => "minutely,hourly,daily,alerts,flags"};