Ticket Created
over 3 years ago

WERETECH-9647

The whole getObscurityFlags controversy...

I thought I had submitted this bug earlier today, but it has disappeared.

Doing a search, there are numerous bug reports (at least some of them from me) concerning really irritating behaviour on getObscurityFlags with high end devices like Fenix 6x.

So, to get it out of the way:

1. Yes, I am aware that the docs suggest not relying on getObscurityFlags "Use of this method is only valid during the call to onUpdate()."

Toybox.WatchUi.DataField (garmin.com)

2. But I am also aware that the Garmin examples in the SDK not only use but ACTIVELY RELY FOR PROPER FUNCTIONING on a call to getObscurityFlags duting onLayout

3. And also that there is no conceivable purpose for onLayout if you cannot use it for actually doing the layout

4. I am also aware of workarounds such as setting a "layout changed" flag in onLayout which you can then respond to in onUpdate ... but that is a ludicrous waste of code and effort

So...

This bug is a plea to EITHER fix the documentation and firmware to support flags in onLayout OR explicitly FIX THE SAMPLE PROJECTS THAT GARMIN PROVIDE to eliminate the wrong use of flags.

But for reference, what triggered this, was observed behaviour on Fenix 6x.

using Toybox.WatchUi;
using Toybox.Graphics as G;
class TestObscurityFlagsView extends WatchUi.DataField {
    var inLayout;
    var inUpdate;
    // Set the label of the data field here.
    function initialize() {
        DataField.initialize();
    }
    function onLayout(dc) {
        // Docs say "Use of this method is only valid during the call to onUpdate()." 
        // But the standard Garmin example depends on using it here, and the _POINT_
        // of having an onLayout where you can't do layout kinda sucks.
        inLayout = getObscurityFlags(); 
    }
    function compute(info) {
        // But this should always be accurate.
        inUpdate = getObscurityFlags();
    }
    function onUpdate(dc) {
        var bg = getBackgroundColor(), fg = 0xffffff - bg;
        var tx = dc.getWidth() / 2, ty = dc.getHeight() / 2;
        dc.setColor(fg,bg);
        dc.clear();
        dc.drawText(tx, ty, G.FONT_LARGE, "L"+inLayout+" U"+inUpdate, G.TEXT_JUSTIFY_CENTER | G.TEXT_JUSTIFY_VCENTER);
    }
}
 

Build a datafield using that view class above, then try placing it at different locations. You will notice that: onLayout reports getObscurityFlags from the immediately prior drawn field (eg: it is WRONG).

Please can you do something to fix this inconsistency.

My preference is that you simply make getObscurityFlags work in onLayout so that we can also use onLayout the way it was intended. But if you cannot do this, for whatever arcane reason that setting a single integer number is not possible, then a second best would be for you to fix all of the SDK examples that use getObscurityFlags in onLayout and to then also put out a PSA about how all the developers who have ever based a field on the examples provided by Garmin should now fix it.

9635560