WatchUi.requestUpdate() twice ?

What is different if you call it twice?  Why call it twice before you return to the vm?

There are some cases where requestUpdate() is ignored, like in the glanceView on some devices.

I found that by calling requestUpdate() multiple times (2 or even much more) in a small "animation app" (*) causes the UI to be updated unnaturally fast in the simulator, as if each request is queued and serviced immediately.

(* The app scrolls some text by 2 pixels every time onUpdate is called -- a timer is used to trigger onUpdate() every 50 ms. When I changed the code to call onUpdate 2X every 50 ms, the text roughly scrolls twice as fast -- in the sim. When I changed the code to call requestUpdate 10 times, the text scrolls insanely fast.)

But when I sideload the app on to a real device, the text is scrolled at normal speed (as I would've guessed).

I'm not 100% sure, but I think multiple requestUpdates() are ignored on a real device.

I'm guessing this is a quirk of the simulator, and that in the real device, requestUpdate() sets a flag as opposed to queuing a request. (i.e. On a real device, calling requestUpdate() more than once in the same context should have no effect.)

Maybe someone from the Connect IQ team can confirm my guess?

Yes, if you have two queued, as soon as the 1st is done, the second one occurs.  If you want to space them out, use a timer and do one requestUpdate on the timer firing, so every 500ms or something.

I understand how to schedule updates with a timer, thanks.

What I'm trying to do is recreate what the OP is seeing, and also trying to compare the behavior in the sim to the real device.

It seems wrong that the sim processes multiple requestUpdate() calls much faster than a real device could (or would).

Whether I have 1 or 10 requestUpdate() calls in my "animation app's" timer method, the animation goes at the same speed on a *real* device. Whereas in the sim, 10 requestUpdate() calls make the animation go perhaps 10X faster than 1 requestUpdate() call -- certainly faster than any real garmin device could update the screen.

So I don't see any empirical evidence that multiple requestUpdate() calls make any practical difference on a real watch, compared to a single requestUpdate(). I guess I could use System.println() and output the system (up)time when each onUpdate() is called -- maybe I'll do that when I have some spare time.

I'm super curious what the Connect IQ team would say about this, tho.

EDIT:

Here's a link to a comment with my scrolling text animation sample:

https://forums.garmin.com/developer/connect-iq/f/discussion/258627/anybody-have-example-of-sliding-text/1235847#1235847

And here's the timer method in question:

 If I add multiple requestUpdate() calls here, I can make the animation go incredibly fast in the sim, but it makes no difference on a real device.

e.g.

The sim is just that and does things differently (and faster) than a real device.  To be safe, use a timer.

Wow you are really missing the point, aren't you?

I don't call requestUpdate() multiple times like that, ever, in a real app.

What I'm trying to do is figure out how it does work and how it should work, since the OP asked the question, and I'm curious.

 If I add multiple requestUpdate() calls here, I can make the animation go incredibly fast in the sim, but it makes no difference on a real device.

------

I was responding to this.

I mean, I could rephrase your comment as saying "don't call requestUpdate() multiple times, ever", which is fine. I actually agree with that.

But then it leads to the following questions:

1) Why does the sim update the screen faster if you call requestUpdate() multiple times, if it's not intended to work that way in the device?

2) Why isn't the doc clear about how requestUpdate() works (either way)?

My only conclusion can be that requestUpdate() is not intended to be called multiple times, that it doesn't do anything (noticeable) on the watch, and that the behavior in the sim is misleading. (i.e. I think this is an edge case that was missed in the sim.)

Either that, or multiple requestUpdates() *are* supposed to do something different, and the behavior in the sim is just wrong. (But I don't see any evidence of that in the device, with the small amount of testing I did).

RodolpheDumesnil so to be clear, I'm fairly sure that calling WatchUi.requestUpdate() multiple times on a real device only results in one onUpdate() call, because in my animation app, onUpdate() both updates the screen and changes the x-coordinate of an animation element.

So if onUpdate() was really being called more than once in a single context (for each requestUpdate()), there would be two possible ways this would look different than a single call:

- (onUpdate() is called and the screen is actually refreshed): the animation would run faster (more frames per second). This is what I see in the sim.

- (onUpdate() is called and the screen is not refreshed): the animation would run at the same frame rate, but the animation element would "jump" further across the screen per update than normal

Since I don't see either of those things happening in the real device, my educated guess is that calling requestUpdate() multiple times does nothing. (At least the way I tested it, by calling it multiple times in a timer callback.)