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!

Parents
  • 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

Comment
  • 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

Children
  • 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?

  • >> "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