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
Parents
  • over 5 years ago in reply to Former Member

    Hi,

    I don't recall seeing any update for this, so please can you confirm:

    Can I continue to use getObscurityFlags() in onLayout() - which would seem to be a prerequisite for any layout tasks at all or does Garmin need to update the SDK, rework and replace the "layout" code in the standard example, and then send out a note to get every single developer on the ConnectIQ forum to verify and rebuild their apps? (Without checking, I estimate this problem would affect roughly 90% of my fields...).

    And, incidentally:

    >> "wrapped it in a bool so i only call it one time after onlayout has been called"

    This is a total non-runner for anybody building for any layout other than full screen. See: forums.garmin.com/.../bug-with-latest-simulator-onlayout-for-different-layouts

    Thanks,

    G

Comment
  • over 5 years ago in reply to Former Member

    Hi,

    I don't recall seeing any update for this, so please can you confirm:

    Can I continue to use getObscurityFlags() in onLayout() - which would seem to be a prerequisite for any layout tasks at all or does Garmin need to update the SDK, rework and replace the "layout" code in the standard example, and then send out a note to get every single developer on the ConnectIQ forum to verify and rebuild their apps? (Without checking, I estimate this problem would affect roughly 90% of my fields...).

    And, incidentally:

    >> "wrapped it in a bool so i only call it one time after onlayout has been called"

    This is a total non-runner for anybody building for any layout other than full screen. See: forums.garmin.com/.../bug-with-latest-simulator-onlayout-for-different-layouts

    Thanks,

    G

Children
  • over 5 years ago in reply to 9635560

    Still getting ERA reports about getObscurityFlags causing a crash in onLayout, no updates received on this ticket.

    What is the purpose of getObscurityFlags that is only relevant for layout if it can't be used in onLayout? 

    What is the status of this ticket?

    If everything based on the monkeyc SDK example needs to be changed, when will that be flagged and the monkeyc example project changed?

    TL;DR; Has anything changed?

  • over 5 years ago in reply to Former Member

    >> "re my fix.  the ticket you reference, which i hadn't seen, shows an example directly calling getobscurity in onlayout.  so not really sure if that is valid.  circular reference and all that."

    I may have been too obscure;

    That was one of a series of tickets raised by a number of developers because it is impossible to test anything other than the first layout displayed in SDK if you have any kind of "I'll take the first value I receive and treat it as gospel" approach.

    EG: When the "onLayout" was optimised for the SDK to it meant that we could not test anything other than the first layout on screen. Ditto, if you place it on a conditional, it means that we can only test the first layout on screen.

    G

  • Former Member
    Former Member over 5 years ago in reply to 9635560

    the SDK 100% needs to be updated.  the one bad review i have for my app is because i followed that SDK example.

    re my fix.  the ticket you reference, which i hadn't seen, shows an example directly calling getobscurity in onlayout.  so not really sure if that is valid.  circular reference and all that.  Slight smile

    all i can directly is since i made that change (with the bool flipped back on in onlayout, then off once i call getobscurity in onupdate), i haven't had any more complaints from users.  so it *seems* to work as best i can tell. well, without buying a $700 watch to test it myself anyhow