-403 VS -402

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)

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?

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

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.

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.

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

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"};