System 7 questions

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?

Top Replies

All Replies

FlowState 8 months ago in reply to peterdedecker

peterdedecker said:
"here the explanation about this (difference between system and API level)"

the system version was supposed to make it easier, but if we're honest it hasn't made so, it confuses people, it confuses developers and it even confuses people within Garmin.

Yet some denied it's confusing (even in the same thread where they were confused about it.)

I think the main reason CIQ System Level was invented was because Garmin wanted to continue to bring new features to old devices without incrementing their major CIQ version number. (As we know, Garmin historically hasn't delivered new CIQ major versions to existing devices -- until now.)

e.g.:

System 4 = CIQ 3.2 (for CIQ 3.* devices) and CIQ 4.0 (for CIQ 4.* devices)
System 5 = CIQ 3.3 and CIQ 4.1
System 6 = CIQ 3.4 and CIQ 4.2

They wanted a way to group to the two sets of firmware versions together with a simple label.

Of course, this does become confusing and ambiguous when you have documentation which says something like "since CIQ 3.4", because that doesn't capture the full story, which would be better described as: Since CIQ 3.4 for CIQ 3.x devices, and since CIQ 4.2 for CIQ 4.x devices

Then there's the fact that minSdkVersion in the manifest has the exact same problem as the documentation: if you specify a minApiLevel of 3.4 (for example) it does not exclude 4.0.* or 4.1.* devices, so you can't select devices based on system level.

And now there's the fact that apparently existing devices (such as epix Pro (Gen 2)) will be getting a new major CIQ version (5.0.0), breaking with past tradition.

Another break with past tradition is that it seems System 7 is *only* CIQ 5 (*), as opposed the previous system levels which always encompassed two sets of firmware versions and devices.

(* although of course the announcement only implies that without stating it outright -- Kyle's follow-up comment in this thread seems to confirm that)

If the system level scheme is supposed to be so important:

- why isn't it explicitly documented? e.g. how come the short list I typed up above doesn't appear anywhere in Garmin's documentation?

- why isn't it indicated in the docs in addition to API level?

- why can't it be selected in manifest.xml?

- why isn't it explained properly to journalists and end users? (Try reading about CIQ System Level in the comments sections of any of the review sites.)

I think the answer to all of those questions is that Garmin knows that the System Level scheme is too complicated to explain concisely to various audiences (even developers), so they won't do it.

If System 7 is only going to be all 4.2.x devices (and no 3.4.x) devices, then I agree this would've been a great time to jump ahead to CIQ 7, and also to potentially retire the System Level scheme altogether.

It all depends on whether the firmware update track is going to apply to single set of newer devices going forward, or if it will split it into 2 (or more) again in the future.

Bruno Bragança 8 months ago

To be honest, the only thing I wanted is onPartialUpdate on amoled devices. I find it VERY frustrating to see stock watch faces updating hr every second with dimmed display and while I have to hide half of the elements because they can't be updated. Unfortunately this feature is not in the announcement.

To be even more honest, I've read the full announcement of the version 7 and didn't find anything that would be as nice as this.

Kyle.ConnectIQ 8 months ago in reply to Lasse

Lasse said:
Is backwards compatibility also supported for the new "Tuple" type?
Meaning: can I use this for typing in my code and still compile for any device?

Yes, typles will compile for any device.

andyj713 8 months ago in reply to Kyle.ConnectIQ

Not to point out the obvious, but space is mostly an issue with the older devices like my FR235 that won't see this anyway. So what's the real benefit? Will my Fenix 7x firmware get upgraded to CIQ 5?

Kyle.ConnectIQ said:
Previously, resource identifiers in the Rez module were typed as Symbol, but in the System 7 SDK they are now typed as Toybox.Lang.ResourceId. This applies to all devices and not just API 5.0.0 devices.

And what difference does this make? If I have several images, and I choose one at run time for the watch face, how do I reference it? It's easy with the ternary operator and symbols, will this be even easier?

jim_m_58 8 months ago in reply to andyj713

andyj713 said:
Will my Fenix 7x firmware get upgraded to CIQ 5?

What Kyle said is:

We'll be updating the announcement with the full list, but it should be all 4.2.x devices

Kyle.ConnectIQ 8 months ago in reply to andyj713

andyj713 said:
And what difference does this make? If I have several images, and I choose one at run time for the watch face, how do I reference it? It's easy with the ternary operator and symbols, will this be even easier?

The samples in the Beta SDK have been updated to use ResourceId. Take a look at them and see if they clear up your question.

andyj713 8 months ago in reply to Kyle.ConnectIQ

So, you first need to do this (which for some reason doesn't quite work right because type checking is disabled):

    (:typecheck(false))
    private function getBitmapResourceId(symbol as Symbol) as ResourceId {
        return Rez.Drawables[symbol] as ResourceId;
    }

Which looks a lot like wrapping a symbol into a ResourceId. Then do this:

            var icon_symbol = mMessages[text_symbol] as Symbol;

            var icon  = getBitmapResourceId(icon_symbol);
 
            WatchUi.showToast(title, { :icon => icon });

Before you could just use icon_symbol, but now we've added some complexity to wrap the symbol into a type. I'm still not seeing the "better" part.

Lasse 8 months ago

Kyle.ConnectIQ

System 7 is adding a much missed native sort implementation (Array.sort), which is great.

Is there a chance this will be backported to v1.0.0 as it is done with ResourceId and Tuple? I think it has always been a glaring ommission in the CIQ API to not have a native sort implementation, especially considering the limited compute/memory of certain devices.

If not Array.sort itself, I would advocate to at least adding Lang.Comparator, Lang.Comparable and its implementations in the core types (String, Number etc). This would already make it much more consistent and easier to implement sort implementations.

Kyle.ConnectIQ 8 months ago in reply to Lasse

Lasse

The devices that run CIQ 1.x are no longer updated, so we aren't able to back port these APIs to them. Tuple and ResourceId are backwards compatible since there isn't a native backend to them and are handled by the compiler.

andyj713 8 months ago in reply to Lasse

Lasse said:
System 7 is adding a much missed native sort implementation

What I've always wanted is a min and max value in an array. This would make clipping boxes for partial updates way easier. Any chance of this, or will we need to resort to the slightly less direct way of sorting then grabbing the first and last elements?