Suggestion: improve switching away from CPU-intensive widgets

Hello,
Some of us develop widgets that are CPU intensive - e.g. SunAlmanac (sun positions calculation), Authenticator (Time-based One-Time Password - TOTP - implementation) - and introduce a significant delay before the device responds to the key press to switch to the next widget. For those problematic widgets, the widget icon is displayed and the device stops responding to key press until the actual widget view replaces the icon, preventing one to quickly browse through to the next widget.
Could this behavior be improved ?
xample given:
- keep the "device input delegate" (widget switching) responding until the widget's view is actually displayed ?
- or delaying - a matter of a few hundreds of milliseconds - the running of such widgets (given an optional flag in their manifest) - just displaying their icon instead - such as to allow the user to continue browsing through ?
Best,
Cédric

jim_m_58 over 7 years ago

The app name/icon is displayed (on some watches) and you can move through the widget loop without actually starting the widget at that time. That's done by the firmware. In your case, it sounds like there's a delay between when you start and when you have info to display.

Have you thought about just displaying a splash screen when your widget first starts before you've got the data to display? In your case, it's only a short time, or the watchdog timer would kick you out

gasteropod over 7 years ago

Jim, I know the purpose of the icon was to allow you to move through the widget loop before the widget gets started, but this no longer seems to be the case on at least my 5X. I remember this being reported in another thread in the past too.

It seems that widget code does delay moving through the widget loop and I cannot scroll through the widget loop without the initial screen being shown just briefly after a delay where the icon is seen. I'll see if I can find that older thread reporting this.

Here is the thread I was thinking of:

https://forums.garmin.com/forum/developers/connect-iq/1250788-ciq-startup-delay-in-widget-loop

jim_m_58 over 7 years ago

If the problem is the blank screen while generating the data is the issue, I think a splash screen would help, as it wouldn't just be a blank screen. If the problem is that the widget is doing doing major when it first starts and it's hard to move through the widget loop, what about using a timer to delay the calculation until a few hundred milliseconds after the widget starts (again with a splash screen)?

CedricD. over 7 years ago

Thanks all for your responses.

Reading from Gasteropod link, I now understand that older versions/devices did implement this "delay-before-running" in the widget loop but it proved problematic for most widgets and users.
Ideally, being able to "opt-in" back to this mechanism via a manifest flag would be nice.
But the Jim's splash screen suggestion should do the trick just fine (actually "emulating" in CIQ what the firmware did for us beforehands).

Still a (tricky) question: is the delay introduced by the CPU being heavily used by the widget (and preventing device responding) or by some other firmware internals that blocks the switch until the initial view is fully rendered ?
If it's the latter, the splash screen could be used to trick that fimware internal (while the calculation is launched in parallel). Otherwise, we ought to just let it idling with a timer before launching the calc.

Best,

PUFFOLINO over 7 years ago

I am not sure if this behaviour has (only) to do with initial calculations, when scrolling up through all widgets on my Forerunner 935 I never was able to tune my own programs to show the behaviour like internal widgets. There's nearly no delay when switching from a garmin widget to the next one, but when even the simpliest widget I wrote so far needs a second or so until I am able to jump to the next one...

When adding a delay, scrolling throught widgets is even more horrible (at least on the FR935) - at least how I did it...

class Init extends app.AppBase
{
    function initialize_()        { AppBase.initialize(); }
    function initialize()        { var timer=new tmr.Timer(); timer.start(method(:initialize_),1000,false); }
    function onStart(state)        { }
    function onStop(state)        { }
    function getInitialView()    { return [new Main(), new myHome()]; }
}