• Replies 6 replies
  • Subscribers 18 subscribers
  • Views 1298 views
  • Users 0 members are here
Options
Related

onUpdate() & Bluetooth. Bug ?

phgerin
I noticed the following on my Fenix 5S+ and iPhone:

I have added a simple counter that displays the number of calls to onUpdate() on the top of my watchface.
Each time I toggle the bluetooth connection on my phone, I get an onUpdate() call. (the counter is incremented).
The watch is on my desk, no notification, no high power mode....

On the last 5hours of normal usage, I got 1000+ calls to onUpdate() (I didn't count the calls not inLowPower).
Is this a bug ? It really drains the battery.

Cant reproduce on the simulator, only the devices, sdk 3.0.9
  • In my mind, it is not a bug for onUpdate() to get called when the connection status is changed. Doing so allows a watch face to accurately display the current status of the bluetooth connection.

    If there is a bug here, it is that bluetooth is connecting/disconnecting 1000 times over 5 hours.
  • Thanks.
    On a Vivoactive 3, there are 8 onUpdate() calls when the connection changes.

    Is there a way to know which event triggered the onUpdate call (to avoid wasting resources) ?
    Maybe some callback function ?
  • Is there a way to know which event triggered the onUpdate call?

    No, there is no such callback.

    Typically you want to update the screen any time the onUpdate method is called. This is because the system can do things (like draw an overlay and animate it off screen) that will cause ugliness if you don't just update everything.

    If you really wanted to, you could cache the last update time and decide whether or not to update the screen based on how long it has been since the last update and any other factor you thought was important. The cost of checking a few flags should be minimal compared to the cost of redrawing the entire screen.
  • I'm doing some testing, and I'm seeing 6 onUpdate() calls when the bluetooth connection status changes. While this is not ideal, it doesn't seem like much of a problem provided that the bluetooth connection isn't getting dropped constantly.

    My vivoactive3m has been sitting on my desk running a test watchface that shows the number of times onUpdate() has been called (in each low and high power modes) as well as the bluetooth connection state and the number of detected state changes. The one state change I'm seeing happened when the watch face was first loaded, and it hasn't changed in over 35 minutes.

    I'm using a recent build of the vivoactive3m firmware and an iPhone6 running Garmin Connect Mobile 4.16.0.17community.garmin.com/.../1463341.jpg
  • Thanks a lot. Its not too bad for a Vivoactive 3, but its really bad for a Fenix (with metal casing) and a not so great bluetooth connection.
    Vivoactive 3: phone on my desk, moving inn ly house: 185 calls/hour.
    Fenix 5s+: same usage, 380 calls/hour.
    Of course, if my watch is on my desk with my phone everything is great.

    I'm already doing lot of tests to avoid unnecessary screens redraws, it would be great to knows which event triggered the onUpdate call (notification, bluetooth, move alert, ...).
    If my watch doesn't display the bluetooth connexion, this could save lot of power.

    Also, the bluetooth status could be tested in onPartialUpdate(), avoiding hundreds of screen redraws.
  • I'm already doing lot of tests to avoid unnecessary screens redraws, it would be great to knows which event triggered the onUpdate call (notification, bluetooth, move alert, ...).

    I could be wrong, but I don't think this is as useful as you might be thinking. If the system draws an overlay for a notification (move alert, bluetooth disconnect/connect, screen lock/unlock, ...) and you don't update the screen when requested, you risk display artifacts as the overlay animates itself off screen.

    Also, the bluetooth status could be tested in onPartialUpdate(), avoiding hundreds of screen redraws.

    I haven't looked to to see if there is a problem with onPartialUpdate(), but should be getting called every second except for the top of the minute. Unless onPartialUpdate() is getting called more frequently than that, there shouldn't be much savings to be had.