WatchUi.requestUpdate() twice ?

For the millionth time I don't write code with multiple requestUpdates and I have no intention of doing so, in a real app.

I only did it in testing bc the OP brought it up. It's called intellectual curiosity.

That doesn't stop me from wishing the behavior of multiple requestUpdates to be well-defined and/or well-documented, now that I've seen how it works, and had my observations confirmed by Travis.

Just because you and I know not to call requestUpdate more than once doesn't mean that we shouldn't expect it to work in a consistent way.

jim_m_58 said:

As Travis said "but since both behaviors are technically allowed, I'm not sure it is a good idea to make a fix either way."

And a timer makes it a non issue, where you can control how often the updates occur.

In other words "multiple requestUpdates are a non-issue as long as you don't call requestUpdate multiple times".

Got it.

Then there should be no problem doing 1 or both of the following:

- Change the behavior in the sim so that multiple requestUpdates are folded

- Change the doc to tell ppl not to call requestUpdate more than once in the same context, because the behavior is undefined

Unless ofc the onus should always be on the CIQ dev to avoid any inconsistencies/pitfalls in the platform....

I honestly don't have a problem if Travis or any other Garmin employee says that (although I would appreciate a note in the docs to that effect -- e.g. "the behavior of multiple requestUpdate() calls is undefined".

You can spend the next 10 years finding small inconsistencies and complaining, but the whole issue of this thread is to get something to work, and it's something you admit you never use in a real app.

Well if you haven't noticed, the OP has solved their problem, so I guess the thread has served its purpose.

I wouldn't call this a small inconsistency when I can get an animation to run on my PC at probably 60-120 fps, when it could never do so on a real watch. I think it's highly misleading.

Sorry to say, but this kind of thing is part of a much larger pattern.

But I guess we can just ignore all the "frustrated developer" threads the same way we ignore the fact that Garmin itself said that they switched to VS Code because VS Code is very popular and Eclipse is hard to use. (It's right in one of the virtual dev conference videos, from Alpha Monkey himself).

See I don't mind if a Garmin employee says "WONTFIX" because that's their job and it may or may not be their call. It's just annoying to see the constant forum apologizing for recurring CIQ issues.

"It's a known issue"

"It will probably never be fixed"

"It could be fixed, but you would have to wait several months so you may as well give up"

"There are many forum threads about this"

"You don't have to use [broken pattern X] because [Y] works fine"

"It doesn't work that way in the real device"

"The sim is not an emulator"

Why not just admit something is a bug/issue/inconsistency and that it could be improved?

Whether or not it will be improved is a different story.

EDIT: Nothing personal towards any Garmin employees. I appreciate all the help in the forums and the attention given to bug reports. I'm sure that a lot of things are down to resources and priorities that are out of the control of anyone who posts here.

Also, my other point is that a simple doc change would solve this issue perfectly: "the behavior of multiple requestUpdate calls is undefined."

Then, when someone asks "what happens when I call requestUpdate() more than once", we can answer with confidence "you shouldn't do that as the behavior is undefined. There must be some other issue in your code that causes the 2nd requestUpdate() to make a difference."

Otherwise, maybe someone leaves that 2nd requestUpdate call in their code, but it causes the sim and real device to behave differently....

Thanks for the response!

Travis.ConnectIQ said:

Telling the user that calling WatchUi.requestUpdate() multiple times in the same 'context' is undefined behavior is definitely not the right way to go. In programming, undefined behavior means that there is no defined behavior (it could do absolutely anything, including crash the device or ignore the call entirely).

I think you're actually suggesting we update the docs to indicate that it is unspecified whether onUpdate will be called once for each request or such requests would be collapsed. This could also be called device-dependent behavior.

Fair enough, I should've said "unspecified behavior" instead of "undefined behavior" -- that's def my bad. Either way, the message would be that you don't want to call requestUpdate() multiple times.

Travis.ConnectIQ said:

That said, I hope the intent was for the requests to be collapsed. It is the right thing to do from both efficiency and correctness perspectives; I'm just not willing to commit to a solution at this time.

Agree 100%. Thanks again for the insider's perspective.