Acknowledged

On-top-of-map square data fields NOT in simulator nor device reference

I have been receiving ERA reports, from which I could tell that my app crashed due to unexpected ObscurityFlags=0 (square field) in the round device fr970. A kind user reported to me that it happens for fields on-top-of map.

I learned that these on-top-of-map, also for my own new Fenix 8, are square and in various layouts: 1, 2, 3 and 6 fields layout. Great feature for sure! But the problem is that these layouts are not in the simulator nor in device reference. And I assume these square on-top-of-map are in many more of the latest devices!? I remember the on-top-of-map layouts for my epix2 were in fact represented in sim, but not these new square data fields in fr970 and fenix8. So, an omission I assume? Or should they not report ObscurityFlags=0? Reason I ask: For the 2 fields layout it seem sometimes ObscurityFlags=0 and sometimes ObscurityFlags=1 or 4 (as I would expect).

Since I tweak my data field for absolute max font size for every possible data field, I’m dependent on knowing/simulating the various possible layouts, incl. on-top-of-map. So PLEASE fix!

Note: the “6 fields” mode on-top-of-map is cool, would be nice to be able to simulate as well, although I for one could live without.

Furthermore, I have a while ago got a similar crash caused by ObscurityFlags=0 for fr265. Same problem?

Hr. Mortensen
Parents

  • Just my 2 cents but I've always subscribed to the software dev maxim "be strict in the output you produce and lenient in the input you accept" (paraphrased). This is the guiding principle that allowed the internet to get big. (Otoh, I think it also led to original design of javascript :shudder:)

    I think this especially applies to Connect IQ, where we know that not all behaviour is simulated or documented.

    Iow, it might be better if your app has some kind of fallback (graceful or otherwise) when it encounters unexpected obscurity flags, as opposed to simply crashing.

    For example, if I made an ios app that works with ios devices of various screen sizes, it would be a terrible UX if the app crashed because the code didn't account for some old or rare phone model with a very small screen size. In the worst case, I would want the app to maybe not work so well (with some visual/functionality issues).

    As a concrete example, my favourite pace calculator for iOS hasn't been updated in many years, so it doesn't look quite right on big phones (which have been around for a long time now) - the app doesn't fill the whole screen. But it still works (it just looks funny).

Comment

  • Just my 2 cents but I've always subscribed to the software dev maxim "be strict in the output you produce and lenient in the input you accept" (paraphrased). This is the guiding principle that allowed the internet to get big. (Otoh, I think it also led to original design of javascript :shudder:)

    I think this especially applies to Connect IQ, where we know that not all behaviour is simulated or documented.

    Iow, it might be better if your app has some kind of fallback (graceful or otherwise) when it encounters unexpected obscurity flags, as opposed to simply crashing.

    For example, if I made an ios app that works with ios devices of various screen sizes, it would be a terrible UX if the app crashed because the code didn't account for some old or rare phone model with a very small screen size. In the worst case, I would want the app to maybe not work so well (with some visual/functionality issues).

    As a concrete example, my favourite pace calculator for iOS hasn't been updated in many years, so it doesn't look quite right on big phones (which have been around for a long time now) - the app doesn't fill the whole screen. But it still works (it just looks funny).

Children
  • in reply to flowstate

    I fully agree to the principle! And my approach has indeed been giving me problems, this is not my first report on the sim/documentation not matching real world devices. But the whole point with my Apps is that they are optimized for people with poor eyesight and hence need max font sizes possible. I have gone through great length, incl using custom fonts font this purpose. At the same time I wish to have my App work in devices with little memory for data fields, so I ended up having custom design for every field in sim. It actually works well most of the time, except in this case. 

Copyright © 1996-2025 Garmin Ltd. or its subsidiaries