How to prevent a widget to revert to the watch page after 59 seconds

This is a designed behavior of the product and is not likely to change. Widgets are best used for "quick glance" types of applications. The watch-app type will be better suited for applications that require running for extended periods without interaction.

Ok, here is a real case (now that I have a device to test on!). I have a widget that does a makeJsonRequest and then display the returned data. It works fine in the simulator, but on an actual device, which is paired to a phone that uses the same wifi as my PC, many times, the data isn't back before the widget reverts to the clock face.

What if, in something like resources.xml, there was a way to set a "revert time", so that a widget would remain displayed longer?

This IS a "quick glance" type of widget, but the data for it may take a bit! (the makeJson/phone/internet/and back)

On the vivoactive (fw 2.40) it reverts back to the watchface after 10 seconds BTW, not a minute. At 15 or 20 seconds, I think it would work consistently as even at 10 seconds, it often works.

@Brian. I hacked up a CIQ widget, that gets about 200 bytes of data from a server on the same network as my phone (literally, I can turn my chair and be at the server's keyboard). With that, the 10 second revert on the vivoactive seems to work, but this is far from real world. I'm guessing that if I used the cell network instead of wifi with my phone, I'd start seeing failures.

A 10 second revert seems low for any widget that doesn't have all it data locally, and it my case it would be impractical to cache the data on my phone for somethings that's only looked at a few times a day. (if the phone pulled the data every 15 minutes, 24/7 that (usually ignored) data traffic builds up!)

Update: when I switch to a 4G net on my phone, I usually get the data, and if I do, it's only displayed for a second or so before it reverts to the watchface. Maybe if the permissions for comm extends the "revert" timer on the vivoactive from 10 seconds to 30 seconds?

I know some timeout extension when a JSON request is made has been discussed. If it were my choice, I think simplest short term solution would be to just have a 1 minute timeout for widgets on all the products.

Ultimately I think this is under the control of the product team, but we will certainly be lobbying for a solution that works well with the ConnectIQ features. Using communications permissions to bump the timeout is a reasonable suggestion.

Ultimately, I hope our efforts to remove some of the latency from the BLE link are successful because 10 seconds is (in my opinion) pushing the boundary of a usable widget.

Using the mobile libraries allows use of the direct comm, which uses the mailbox system. Using that method would allow for periodic data updates independent of running the widget, but it is a more complex solution for the user and the developer. Implementing widgets in such a way does "waste" data, but I sure wouldn't call it impractical. The weather widget I use on Android updates every 30 minutes, even though it is only accessed a few times a day. I think this is pretty typical practice.

In fact what I'm building is a weather widget! (one that doesn't use GPS, but a specific weather station ( there are thousands in wunderground)). With my android, yes, it grabs data every 30 minutes or so, but it also displays the temp on the top status line, so you have something like temperature there and fairly current when ever you unlock the screen. But when you open the weather app it gives you much more timely data.. In the case of a widget, you have to take a specific action to see it, and it's actually data that is updated on the website I get it from about once a minute.(and therefore, the widget should be more precise)

Now if I could build a watchface that included the temp (so the temp would be visible most of the time), caching makes a lot of sense!

jim_m_58++ for Wunderground. :)

Yup Brandon, you can't get better weather info for where you live, that when you have a weather station in your own back yard. In the vivoactive forum, there is interest in a WU widget (I've mentioned it there), but I need to wait for a means a user can define a weather station, and what WU calls a "API KEY" (needed to access the JSON data) The keys that are free have a limit on the number of requests allowed, so it isn't something I'd want to hard code for everyone. And I don't want to pay for a key so that everyone can use the same one!

This came up because the standard weather widget causes some confusion, as unless the VA has your current GPS location, the data is wrong, and sometimes very wrong. One case someone mentioned, the widget said it was 60 outside, while it was actually 30 degrees colder and snowing....

I need to wait for a means a user can define a weather station, and what WU calls a "API KEY"

Can't use use the TextPicker to allow the user to enter the weather station and api key on the device directly?