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 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.

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

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

  • 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

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

    moving getobscurityflags into onupdate fixed the issue for me.  wrapped it in a bool so i only call it one time after onlayout has been called.   1000 lashes to whoever wrote that sample code with it shown running in onlayout