Body Battery NOT available when Watch face downloaded from store, but is when installed via .prg file locally. Any ideas? minApiVersion 3.2.0 Instinct APAC watch.

As an example from the real world (not the amateur hobbyist playground of Monkey C), I've worked at a startup which had 2 generations of a proprietary platform/framework.

- The first gen was based on javascript (no type checking)

- The 2nd gen was based on typescript (strict type checking) and a proprietary domain-specific type checked language

When I jumped aboard during the development of the first gen platform, I spent half my time fixing errors due to lack of null/undefined checks.

With the 2nd gen platform, such errors were simply not possible (in 99% of the cases).

I could've just spent all my time wagging my finger and telling my co-workers "don't forget to check for null/undefined!!!1!" but somehow the system architects thought it was more effective to simply use languages where it would be impossible (or very hard) to avoid handling null/undefined properly (as well as enforcing proper code with respect to other type-related issues)

FlowState said:

I said that the type checker can benefit all devs, including you and me. If you already write great code, the type checker can save you time, again as long as you are willing to work with it.

How?  When it complains about things that aren't bugs?

When I start a new project, I'll start with type checking on, but as soon as it starts to complain about things that aren't bugs, I turn it off

I already explained how.

jim_m_58 said:

When it complains about things that aren't bugs?

Like I said, you have to be willing to work with the type checker (i.e. write your code a certain way).

If you don't want to, that's fine. I'm not rewriting all my old apps to work with strict type checking either.

But that doesn't mean other devs (especially new devs) can't benefit from type checking.

"When I start a new project, I'll start with type checking on, but as soon as it starts to complain about things that aren't bugs, I turn it off"

Yep, that's your personal experience, and your decision to not use type checking.

FlowState said:

As an example from the real world (not the amateur hobbyist playground of Monkey C), I've worked at a startup which had 2 generations of a proprietary platform/framework.

And I started professional programming in 1980 after getting a 4 year degree in Computer Science with a specialty in OS and compiler design.

jim_m_58 said:

And I started professional programming in 1980 after getting a 4 year degree in Computer Science with a specialty in OS and compiler design.

Not sure what your point is?

You're not the only dev in the CIQ community or the world. I didn't say *you* are an amateur, I said CIQ is (mostly) for amateurs and hobbyists. That's clearly how outsiders see the CIQ store.

I'm simply saying that type checking has real world benefits, even if you don't see them.

Why do you think TypeScript exists (JavaScript + types)? Why has a type checker been added to Python?

Why do languages like Java and Rust exist with static strict typing built into the language itself?

I make arguments about other devs and the wider world, but somehow your arguments always circle back to you.

My anecdote about the startup wasn't meant to be a flex, I was simply relaying my own personal experience with a project that initially lacked type checking and eventually gained type checking, and trying to explain that the 2nd gen (with type checking) was better. A certain type of bug related to devs forgetting to check null values was almost completely eliminated due to the introduction of type checking.

Also, I've worked with lots of people from around your generation (maybe slightly younger, as they're still in the workforce), and I'm not sure why you think it's special that you started in 1980. When I was an intern and in my first year out of university, I taught them stuff about C that they didn't know despite having decades of experience with the language. I def learned a lot from them too, but they were definitely set in their ways. (Like one guy would use a decades-old IDE that was no longer updated, despite the fact that it had a ton of issues and limitations, and it would randomly crash.)

Which kind of tells me that experience is nice, but it isn't the end all and be all of everything.

One problem with too much experience is that you might refuse to try absolutely anything new.

Same as when Monkey C was new, you were excited to file bug reports and feature requests, and now you consistently push back against the same.

Wow.  You are so lost!  I look for work-arounds to bugs, as I've summited some that have taken over a year to fix!

FlowState said:

Same as when Monkey C was new, you were excited to file bug reports and feature requests, and now you consistently push back against the same.

Am I lost?

If I look at your old CIQ posts from the beginning (2015), I see lots of bug reports and "hey <CIQ team member I am on a first-name basis with>, wouldn't it be great if <useful feature was added>?"

However, within the last 7 years or so, any time someone files a bug report, your reply has been one of:

- "I don't see the problem". *when the problem is explained you after several pages of posts*: "Maybe this problem is visible under extreme circumstances, but it's not still not a real problem". Funny that more than once, Garmin has disagreed with you and actually fixed the problem.

- "Stop complaining"

- "I don't care about this issue"

- "Garmin won't fix this"

- "We have known about this problem in the forums for years"

Anytime someone makes a feature request:

- "I don't know what that is"

- "Nobody has ever asked for this before"

- "People have asked for this many times over the years"

Funny how the last two points make opposite arguments for why people shouldn't make feature requests: either nobody has asked for it (meaning it's not important), or many people have asked for it (meaning if Garmin didn't give it to us before, they won't give to us now). In other words, nobody should ever ask for anything ever.

My favorite bug report that you repeatedly dismissed was when I posted that glance.liveUpdates was misconfigured as true for enduro's simulator.json.

First you misread my post, misunderstood what I was trying to say, and condescendingly explained what glance.liveUpdates means. (As if it wasn't clear from my post that I knew what liveUpdates means.)

A CIQ team member posted in the thread and said that this was indeed a misconfiguration and that they'd get it fixed.

Years passed and it wasn't fixed.

I bumped the same thread, asking when it would be fixed.

Ofc you had to chime in and say:

- it doesn't matter (not sure what the reasoning was here)

- if I care so much, I should edit simulator.json myself (again, dripping with condescension)

Finally it got fixed by the CIQ team.

So the baffling thing (apart from the consistent inability to read and understand other people's posts, not just mine), is why you had to expend so much energy telling me that my bug report was invalid. Don't you want the simulator (and device config) to be as accurate as possible?

Just because none of *your* apps care whether liveUpdates is true or false, doesn't mean the same is true for everyone else's apps. My app happened to have a glance that works completely differently whether live updates is true or false (and it had to be known at compile time), and I didn't want to apply a workaround to try to detect it at runtime. So it was important for me to know what the true value of liveUpdates was, for all devices with glances.

jim_m_58 said:

I look for work-arounds to bugs

Going back to reading comprehension, I was referring to all the times that you consistently dismiss bug reports and feature requests, posted by anyone except yourself. i.e. you literally say "that's not a bug", "maybe that's how it's supposed to work", "it's not important", "garmin won't fix that", etc., etc.

The most recent example is when somebody posted that Instinct 2's 1-field layout is wrong in the sim. You helpfully pointed out that the real Instinct 2 does not actually have a 1-field layout (I mean that sincerely), but then you went on to say maybe this is how the simulator shows that the layout is invalid (implying it's not a bug).

First of all, the device reference for Instinct 2 also shows the invalid 1-field layout (which probably isn't surprising, as I assume the device reference and SDK device config are generated from the source). Having a 1-field layout in the device doc when it doesn't exist in the real device sure seems like a bug to me.

Second of all, you act as if it's literally impossible for Garmin to avoid showing a 1-field layout for the simulator if it doesn't exist in the device. Newsflash: Garmin controls the code for the simulator, they can do whatever they want. They make the rules. Just because they don't have time to fix certain kinds of bugs doesn't mean they aren't bugs.

There's been many cases where you actively deny that something is a bug when it clearly is, and in many cases, when Garmin eventually fixes the bug. Another fairly recent example is when someone said that CIQ watchfaces disappear instantly (i.e. the screen clears) when you scroll away from them, as opposed to native watchfaces, which smoothly scroll off the screen. First you said you didn't see it, then when it was explained to you (after pages of posts), you said that it doesn't matter. Garmin apparently disagreed with you, since they fixed it anyway.

Anyway my original point was that enabling type checking and enabling api has check removal (both by default) are different kinds of issues:

- if type checking prevents your project from compiling then it’s an obvious problem that stops you from continuing unless you either fix your type issues or turn off type checking. It’s an in your face problem. And again, enabling or disabling type checking in itself does not change the behaviour of your app at runtime 

- api has check removal *silently* changes the behaviour of your app without warning. The flag isn’t even part of the VS code extension’s settings UI, unlike type checking. Furthermore, the default setting of “enabled” produces behavior that almost no dev wants (afaict)

Two completely different scenarios imo. This might come as to a shock, but many devs actually prefer typescript to plain JavaScript, which means there are devs who like type checking. Sure, there are also devs who prefer JavaScript without type checking. 

The difference is I doubt theres a significant number of devs who want the default behavior where api has checks are removed at compile time. 

The real reason is because GARMIN doesn't care about these old Asian models. They don't have the correct Asian system version.

Most Asian devices before fenix6 have this problem. This bug has been reported by many Asian developers, and you can even find similar problems in posts more than two years ago, but they have never been solved. Of course, turning off the detection is a solution.

But in fact, Garmin could have solved this problem in half an hour, but they didn't do it.