Acknowledged

Request - specify if WatchUi.View.onUpdate() is required or optional

If onUpdate() calls would allow differentiating between updates that are required and that are optional, it would allow avoiding unnecessary repainting.

For example, if a watch face does not require updating every second (by showing just HH:MM), then 59 repaints every minute in high-power mode go to waste.

On the other hand, if the OS wipes the screen clean for some reason, then onUpdate() obviously must execute.

The request is to change onUpdate to include an extra parameter to specify if the update is optional or not:

onUpdate(dc as Graphics.Dc, required as Boolean) as Void

This would help writing more power-efficient code.

Parents
  • I'm not against this kind of change in principle, but the exact suggested implementation (adding a new parameter to onUpdate()) is not feasible, bc it would break backwards compatibility with all existing code. Passing too many (or too few) arguments to a function is a runtime error, and a compile-time error (when the type checker is enabled). (As a matter of fact, Garmin's own API has an issue related to Garmin code passing in the wrong number of arguments to a CIQ callback method.)

    I think Garmin would need to provide another overridable function to the View class named onUpdate2() (or whatever you want to call it), with the new signature / behavior you specified.

    The default implementation of onUpdate2() could look like this:

    function onUpdate2(dc as Graphics.Dc, required as Boolean) as Void {
      onUpdate(dc);
    }
    If you want the new behavior, override onUpdate2() in your app and do your update there. If your app also overrides onUpdate(), it won't be called by the framework (but you can call it yourself, if necessary).

    I do feel like this would be difficult for Garmin to document properly (*) and hard for new devs to understand. (* the existing docs for "normal stuff" aren't perfect.)

    It would also open up some issues if someone overrides a View-derived class that overrides onUpdate2(). They may try to override onUpdate(), only to find that it doesn't work.

    Maybe a better solution would be to simply add the information you want to Graphics.Dc.

    > On the other hand, if the OS wipes the screen clean for some reason, then onUpdate() obviously must execute.

    I'll also point out, as others have, that it's not just screen clearing that necessitates redrawing the whole screen in onUpdate(), notifications (like the move alert) can also cover up part of your app's screen. If we really want to get in the weeds here, maybe to be *really* power efficient, we would want to know *which region of the screen* needs to be redrawn.

Comment
  • I'm not against this kind of change in principle, but the exact suggested implementation (adding a new parameter to onUpdate()) is not feasible, bc it would break backwards compatibility with all existing code. Passing too many (or too few) arguments to a function is a runtime error, and a compile-time error (when the type checker is enabled). (As a matter of fact, Garmin's own API has an issue related to Garmin code passing in the wrong number of arguments to a CIQ callback method.)

    I think Garmin would need to provide another overridable function to the View class named onUpdate2() (or whatever you want to call it), with the new signature / behavior you specified.

    The default implementation of onUpdate2() could look like this:

    function onUpdate2(dc as Graphics.Dc, required as Boolean) as Void {
      onUpdate(dc);
    }
    If you want the new behavior, override onUpdate2() in your app and do your update there. If your app also overrides onUpdate(), it won't be called by the framework (but you can call it yourself, if necessary).

    I do feel like this would be difficult for Garmin to document properly (*) and hard for new devs to understand. (* the existing docs for "normal stuff" aren't perfect.)

    It would also open up some issues if someone overrides a View-derived class that overrides onUpdate2(). They may try to override onUpdate(), only to find that it doesn't work.

    Maybe a better solution would be to simply add the information you want to Graphics.Dc.

    > On the other hand, if the OS wipes the screen clean for some reason, then onUpdate() obviously must execute.

    I'll also point out, as others have, that it's not just screen clearing that necessitates redrawing the whole screen in onUpdate(), notifications (like the move alert) can also cover up part of your app's screen. If we really want to get in the weeds here, maybe to be *really* power efficient, we would want to know *which region of the screen* needs to be redrawn.

Children
No Data