Dc glitches black sometimes, not in simulator

    function onUpdate(dc as Dc) as Void {
      var now = System.getClockTime();
      var hour = now.hour;
      var min = now.min;
      var nowg = Gregorian.info(Time.now(), Time.FORMAT_SHORT);
      var day = nowg.day;
      var month = nowg.month;
      var year = nowg.year;
      var curDtStamp = getDtStamp(year,month,day);

      // save power if cache is intact
      if(bgCache&&wfCache&&bufferWfHr.equals(hour)&&bufferWfMin.equals(min)&&curDtStamp.equals(cacheDtStamp)) {
        onPartialUpdate(dc);
        return;
      }

This has come up over and over again throughout the years, but regardless of the behaviour in the simulator, you have to redraw the entire screen in onUpdate().

Some devices will clear the screen before calling onUpdate(), others will not. Additionally, it's possible for system popovers/toasts to partially obscure your app temporarily - in this case your app has no idea that this has happened, and if you don't redraw the whole screen in onUpdate(), the system toast will stay on the screen.

See:

 Screen being cleared on onUpdate 

https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-some-newer-devices-clear-the-screen-on-every-view-update-simulator-behaves-differently?pifragment-706=5  

 Persistence of the Dc content between calls to onUpdate() 

https://forums.garmin.com/developer/connect-iq/i/bug-reports/vivoactive-4-clears-screen-before-onupdate?CommentId=97d0c585-da4d-4146-a1e3-013e2e62b8b6  

Travis.ConnectIQ, a member of the Connect IQ team had this to say:

You should just do what is the most compatible.. make no assumptions and clear the screen yourself when onUpdate is called.

--

beva said:

The strangest thing is that it doesn't seem to happen in the always active state, where onPartialUpdate is directly called by the system.

I'm guessing that it's because the screen *isn't* cleared before calling onPartialUpdate() (for an obvious reason: if it was cleared, then that would defeat the purpose of onPartialUpdate in the first place).

I will say it's too bad that the sim doesn't model the "worst-case" / realistic scenario where the screen is cleared before calling onUpdate(). Ofc we all know it's way too much to ask for the sim to model the real device behaviour, but that isn't even necessary here. We just need the sim to do the worst possible thing here (screen is cleared before onupdate()), so that devs will be forced to write their onUpdate() code to handle that case.

Instead, the sim *doesn't* clear the screen before calling onUpdate, but the devices do, and we've had years of devs running into this exact problem over and over again.

beva said:

I'll push my bg and wf buffer to the whole screen if not in always active mode should do the trick?

Bro the easiest thing to do is to clear the screen in onUpdate(), like the quoted CIQ team member (Travis.ConnectIQ) said. From what they didn't say, we can infer that this should be done in all cases (regardless of whether the MIP device is in always active mode or not).

That would force you to redraw everything in onUpdate(), ofc.

If you don't want to do that, it's up to you, but don't be surprised if there's some edge case where your app doesn't work as expected. I already mentioned one edge case: when the system draws something like a popover or toast on top of your app. In that case, if you don't redraw the part of the screen that the system drew on, the system popover won't go away. (Or at least that's the conventional forum wisdom anyway. I think someone may have actually seen this issue, but in the context of a CIQ device app.)

I opened a bug report for the misleading and unhelpful behaviour in the sim:

 Sim should probably clear the screen before onUpdate() is called, to handle the worst-case scenario for real devices, and to put an end to multiple years of new devs asking "why does the real device clear the screen before onUpdate()?"  

Well I don't think it should, as it doesn't happen in 99,9% of the time on the real devices. It would be nice if it would do it at random base simulating this glitch.

I thought it might save some battery life not redrawing the complete screen every second if only the second changes, just like it is in always active mode, that probably is coming to  amoled too.

I have the whole thing in a buffer without the second hand so for now I just draw the complete buffer and not only the lines of the part of the previous second hand. 

beva said:

It would be nice if it would do it at random base simulating this glitch.

No, that would be even worse than not doing it all imo.

If the sim isn't going to model the device exactly, then it should choose the behaviour that leads devs to write correct code.

I don't know why you keep calling this a glitch and assuming that it's random, rather than accepting that it's just the way some devices work (and it's done on purpose).

Calling it a glitch implies that it might be "fixed", but accepting that it's intentional suggests that it won't change.

You don't have to listen to me, I'm literally nobody. This is the closest thing to an "official" statement that I know of:

forums.garmin.com/.../vivoactive-4-clears-screen-before-onupdate

It does not clear the screen if you don't, so it would encourage developers to not do this, what would be even worse than not drawing the complete screen but only the changed part.
I only called it a glitch as it can not be reproduced and does not happen often and tried to give it a descriptive name.

I am not talking about the group of devices that clear the screen, but about devices using the framework that would not.