• Replies 49 replies
  • Subscribers 28 subscribers
  • Views 5940 views
  • Users 0 members are here
Options
Related

System 7 questions

j.nygaard CPH DK
9 months ago

Couple of Questions for Garmin, related to System 7:

1) Have you considered skipping API 5 and 6, and go straight to 7, to make System and API level line up??? There is plenty of confusion with the whole API vs system  level as is.

2) Have you considered making a way to select the compile version in the manifest or something?? System 7 seems to bring some (needed/nice) changes to core stuff, so there is no backwards compatibility with old System 4/5/6, right??? If one just needs to quickly fix a bug in an old app, might not make sense to update the code. Would be nice if the level was selected in the project, rather than only in the SDK manager.

3) Is there a list of which devices will get System 7 support? Surely VENU 3 and VA5 is on the list right? 

  

  • 8 months ago in reply to andyj713

    The most efficient way would be to iterate through the array once, keeping track of the min/max value as you go.

  • 8 months ago in reply to Kyle.ConnectIQ

    I understand how this cannot be implemented compiler-only.

    Well, I'd be excited if this functionality is added for 3.4.x devices (I have a Fenix 6s Pro, which is still a very solid device that I'd like to see receiving this kinds of core upgrade still). I've implemented my own sort, but obviously it would be way more efficient to have a native implementation. Pretty please?

  • 8 months ago in reply to Lasse
    Lasse said:
    The most efficient way would be to iterate through the array once, keeping track of the min/max value as you go.

    Yeah and it's fairly trivial (in terms of effort and code size) to write. I'm sure andyj713 already has an implementation anyway.

    My point being, native sort is a huge win compared to native array min/max, which would be more of a nice-to-have.

  • 8 months ago

    I note it will now be possible to call the communications module in the foreground for data fields. Will it also be possible to call the authentication module in the foreground? Since both are essentially web calls with a supplied callback function.

  • 8 months ago

    So, no one has an answer about onPartialUpdate on amoled devices? If the answer is no, is there any hope that Amoled devices will ever have 1 second updates on dimmed screen? The pre requisites are met, if not, stock watch faces wouldn't update data every second.

  • 8 months ago in reply to Bruno Bragança

    If there was a change with onPartialUpdate, I would have expected something in either the System 7 announcement or the change log in the 7.0.0 (now 7.0.1) SDK/

    When onPartialUpdate was first announced, it wasn't available on older devices (and still isn't), as the display was different to handle only updating the clip region, and there is that 30ms time limit.  I doubt the AMOLED displays have that and the time might be above the 30ms even if they did.

    With native watch faces on an AMOLED device, I see them hide the seconds after a timeout just like with CIQ watch faces.  I've not seen any native ones that shows seconds all the time,

  • 8 months ago in reply to jim_m_58

    Hi Jim, thanks one more time for answering me. I re-checked my device (Venu 2) now and all but one stock watch faces don't update seconds every second, instead they hide the indicator. I attached a video of the only one that keep showing and updating seconds. But all of them that shows heart rate keep showing heart rate and it's updated every second while the screen is dimmed.

  • 8 months ago in reply to Bruno Bragança

    Remember that native watch faces aren't written using CIQ and may do things that can't be done in CIQ

  • 8 months ago in reply to jim_m_58

    Yeah, unfortunately... But IMHO there's nothing that couldn't allow CIQ to do this thing. The hardware is there, I'm not wanting for a device without a soundspeaker to play audio. I really want to believe that Garmin has a very good reason to not release this feature for amoled devices, something like it's impossible to meet power budget with CIQ compiler, whatever.

  • 8 months ago in reply to Bruno Bragança

    On the flip side, if native watch faces can have per-second HR updates on an AMOLED device without violating Garmin's anti-burn-in protocol, why wouldn't they use that for always-on seconds instead? Is it because seconds use more pixels? You'd think the end user would notice and appreciate always-on seconds more than per-second HR updates.

    Don't get me wrong, I think per-second HR updates are more "useful" (*) than always-on seconds (although I'm happy to have both on my MIP 955.)

    (* as in I like to see my HR change instantly although in reality I know it's useless lol.)