How is the default weather widget loading so fast?

Former Member over 8 years ago

Hello,

I made a widget that fetches (using Comm.makeJsonRequest) and displays data from a webservice. It works so far, but I have the problem that it takes uncomfortably long to load the web resource. Now, it looks like the Connect IQ API provides no way to preload anything for a widget. However, I also noticed that the default weather widget loads so fast, that it seems it has to somehow load it's information ahead of time. My question therefore is, does anyone know how the default weather widget able to do this? Is there some hidden API that is not public that allows this? Or is there some other trick I am simply missing? I want to achieve that speed as well.

jim_m_58 over 8 years ago

I believe the way native widget works is the weather data is cached on your phone by GCM. So the widget just to grab the optimized data from the phone and not the web.

With my weather widget, I do a makeJsonRequest() request and have the data on a va-hr in about 3 seconds (less on an Edge 520 1 or 2 seconds - it uses normal BT and not BLE), when using wifi and not a cell network. I expect some of the time has to do with how long it take your weather data provider to respond and how big the response is, so YMMV).

Update: just tried the va-hr and 520 on the cell network, and the times were about the same.

travis.vitek over 8 years ago

One important thing to consider is that the size of the response has a significant impact on performance. For example, OpenWeatherMap provides this data for a given coordinate...

{

  "coord": {

    "lon":139,

    "lat":35

  },

  "sys": {

    "country":"JP",

    "sunrise":1369769524,

    "sunset":1369821049

  },

  "weather": [

    {

      "id":804,

      "main":"clouds",

      "description":"overcast clouds",

      "icon":"04n"

    }

  ],

  "main": {

    "temp":289.5,

    "humidity":89,

    "pressure":1013,

    "temp_min":287.04,

    "temp_max":292.04

  },

  "wind": {

    "speed":7.31,

    "deg":187.002

  },

  "rain": {

    "3h":0

  },

  "clouds":{

    "all":92

  },

  "dt":1369824698,

  "id":1851632,

  "name":"Shuzenji",

  "cod":200

}

That data must be downloaded, transferred to the watch, and then decoded into Dictionary/Array/String/Number values and then passed to the user code (maybe not in this order). All of that is a ton of overhead if the only data you really need is the following...

{

  "cond":804,

  "icon":"04n"

  "temp":289.5,

  "min":287.04,

  "max":292.04

}

I'm fairly certain that you will find that writing your ConnectIQ app to communicate with a proxy service that filters out unnecessary data will cut down on the overall time that it takes for a request to be processed.

Travis

jim_m_58 over 8 years ago

If you do use Open Weather, two more pieces of info are important - name and dt. Name is the location, and dt is the timestamp of the data. In my testing, with OW, I'd see data that was hours old, and from a location pretty far away from the lat/lon I submitted. (this may vary by your location - I happen to live with a large city so it was a bit surprising)

Also, I only use GPS if there isn't a known location or the user requests to switch location, so I can skip that part most of the time.

dbrobert over 8 years ago

One important thing to consider is that the size of the response has a significant impact on performance.
<snip>
I'm fairly certain that you will find that writing your ConnectIQ app to communicate with a proxy service that filters out unnecessary data will cut down on the overall time that it takes for a request to be processed.

Travis is 100% correct. You will definitely NOT regret writing your own proxy to filter out any data you don't need (thus reducing the size of the data that is sent between the mobile device and the watch). I also took it a step further for my METAR/TAF widget and do all the unit conversion on the server to minimize the complexity and code required to be run on the watch.

Cheers,
Douglas