onUpdate Before Hide

I'd need an experiment to prove it, but it seems like the OS will call onUpdate just before onHide when a watch face is shutting down. I'd like a way to discern between an update when the app is shutting down and a "normal" update so I can avoid expensive drawing operations as the app is shutting down. This would help make the exit animations smoother. Has anyone else encountered this and come up with a solution? Thanks.
  • Former Member
    Former Member over 10 years ago
    My thinking was this.

    You are saying you can't catch the onHide before onUpdate. Although Travis has pointed out that perhaps onHide is not even called on a 920 for example, and may only be called in the simulator.
    So you want to interrupt onUpdate if onHide has been called shortly after onUpdate has been called, but before it has had a chance to finish.

    So I would log the times the functions are called. I would do this with empty functions, there is no need to process all your code in this discovery stage.
    If you can determine that onHide is being called within x ms of onUpdate then you know how long you need to run onUpdate before checking the flag to escape the function.
    Since you have said your update requires multiple ms processes you can probably work out the most appropriate place to place the flag check, which may well be half way through the onUpdate code.
  • I doubt you'll see the onHide before the onUpdate completes, as the calls are really serial, so onHide and onUpdate would never be running at the same time.

    Ask the Garmin CIQ folks how safe saving the DC is. Maybe you just need to save the DC every time onUpdate is called. They should be around here on monday.

    And even if you don't have battery concerns, it will still be better to do the "expensive" stuff only as often as really needed.
  • Former Member
    Former Member over 10 years ago
    That's why you stop onUpdate. And that's why you run it with no code, so that it can execute and then you can see how far behind onHide is. You may only need to break and loop without the timer.
  • Although Travis has pointed out that perhaps onHide is not even called on a 920 for example, and may only be called in the simulator.


    I just tried logging the onHide() and onUpdate() calls on my Vivoactive. I see the onUpdate() calls in the log, but no onHide() calls at all. I wonder if this is a bug?
  • And even if you don't have battery concerns, it will still be better to do the "expensive" stuff only as often as really needed.


    I agree with you there, which is why I am gating the partial updates based on how long it has been since the last update.
  • Former Member
    Former Member over 10 years ago
    I would presume that it's not a bug, rather that they have changed the behavior. My reasoning being that a new watchFace project in Eclipse doesn't have the onHide function included by default.
  • I would presume that it's not a bug, rather that they have changed the behavior. My reasoning being that a new watchFace project in Eclipse doesn't have the onHide function included by default.


    Looks like onHide() is still advertised at in the SDK 1.1.0 documentation for Toybox::WatchUi::View and at http://developer.garmin.com/connect-iq/developer-tools/user-interface/, right?
  • I see the onUpdate() calls in the log, but no onHide() calls at all. I wonder if this is a bug?


    I noted this in my previous post on this topic (920XT w/ 3.20 firmware). It seems to me that every call to onHide() should be paired to a call to onShow().
  • Former Member
    Former Member over 10 years ago
    I was betting on the odds. 2 [template, device] out of 3 [template, device, documentation].
  • I was betting on the odds. 2 [template, device] out of 3 [template, device, documentation].


    "Never tell me the odds." - Han Solo