Complete
over 4 years ago

WERETECH-8476

Display bug from firmware update or SDK? Fenix 6x Sapphire misreporting screen shape (probably)

I have three products that all use logic based on screen shape and obscurity flags to layout the screen.

They seem to work well until I released an upgrade recently... changing SDK 3.1.5 to SDK 3.1.6 despite the known issues in debug environment because I wanted to support the newer watches. This immediately resulted in a bug report from a customer. So I downgraded to SDK 3.1.5 and the bug persisted.

As the identical (seriously) code used to work and now doesn't with both the newer and the older SDK, I have to put this down to external factors.

The customer confirms that there was a system update between his using my DataField and his noticing the bug. Therefore, it looks probable that the firmware might be at issue.

For reference, the following conditional breaks on Fenix 6s Sapphire and didn't previously..

var settings = System.getDeviceSettings();

var isSemiRound = settings.screenShape == System.SCREEN_SHAPE_SEMI_ROUND;
if (!isSemiRound && obscurityFlags == (OBSCURE_RIGHT | OBSCURE_LEFT | OBSCURE_BOTTOM | OBSCURE_TOP)) {
 // THIS SHOULD MATCH THE FENIX 6S
} else {

  // THIS SHOULD NOT MATCH THE FENIX 6S

 }

The code is misreporting so that it displays for a square layout when it should display for a round one.

I am at a loss to know what to do here. 

PLEASE HELP!

9635560
  • Former Member
    Former Member over 5 years ago in reply to Stephen.ConnectIQ

    It was a quick change for me and I’ve already deployed. Waiting on a response from the user who reported the issue. I’ll post back as soon as I here

  • over 5 years ago in reply to 9635560

    There is nothing funny about your concerns. There is obviously an issue one way or another. At this point it looks like there are 2 possible situations here:

    1. The API docs are just wrong (which would imply that there is also a fenix 6 fw bug).
    2. getObscurityFlags() is truly only valid in onUpdate().

    If this second case is the reality, the template would need to be changed, and any app created from the template is invalid which is a major issue. We have time scheduled to discuss this issue more deeply, but in passing conversation, without looking into the code, the impression is that the API doc's are likely incorrect. With that being said, someone decided to include that line in the API docs, and they must have had a reason, so this is still up in the air.

    Without looking into it yet, this is all just speculation, but I wanted to give you an update.

  • over 5 years ago in reply to Stephen.ConnectIQ

    Hi Former Member,

    Not wishing to be funny, but are you sure the docs are actually correct?

    For example;

    1. Try creating a new "Complex" DataField using the Garmin SDK, then look on lines 15 and 16 of the sample code _PROVIDED_BY_GARMIN_:

        // Set your layout here. Anytime the size of obscurity of
        // the draw context is changed this will be called.
        function onLayout(dc) {
            var obscurityFlags = DataField.getObscurityFlags();

    2. What conceivable purpose would onLayout have if it weren't to layout the screen and how could one possibly layout the screen without knowing what shape it is?

    In all seriousness, please can you raise a ticket internally to verify that line in the documentation as it is extremely suspect and, if it were correct, would probably invalidate a substantial portion of the fields actually live on the store - anything built based on the Complex DataField template, for example.

    G

  • over 5 years ago

    I thought I posted this already, but I'm not seeing it. Apologies if this is a duplicate post:

    Where are you calling getObscurityFlags()? I just noticed in the API docs that "Use of this method is only valid during the call to onUpdate()." 

    https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi/DataField.html#getObscurityFlags-instance_method

  • over 5 years ago in reply to 9635560

    Thanks I see how your code snippet is working now. I had to refresh on how bitwise or actually works :) 

    Also, thanks for clarifying that this was on an Asia device. There are differences between the Asia devices, so it is possible this issue is only seen on those devices, which I wasn't using when I originally tested for this issue. We will take a look on that specific device/fw combination for this issue.