Gyroscope values in Sensor::Info

I never use any min API level other than 1.2.  For specific features I control functions based on targets and use "Has" for some things.

Nick said:

Ok - so for the time being it's possible to test some basic code on the f6pro for example, until the VM updates and system 5 update occurs, and then it should be available on all the devices listed?

Yes, but only for users with the devices in question which actually receive the 3.3 update. (This is where you would want to set your minimum API level to 3.3, assuming that your app cannot work without a 3.3 feature, so that users which haven't received the update yet won't see it in the store.)

Examples where a device would not receive the 3.3 update (even if it's eligible):

- (obvious case) User hasn't updated their device firmware (because they haven't synced in a while). (Then again it would be hard to download a CIQ app without syncing) (perhaps a more realistic case would be that they answered "no" to the "update firmware?" prompt on the watch, for whatever reason.)

- User's device is from the APAC region (Asia/Pacific). Garmin APAC devices usually lag behind in updates

jim_m_58 said:

I never use any min API level other than 1.2.  For specific features I control functions based on targets and use "Has" for some things.

Sure I get that, and I do the same, but Garmin obviously implemented that feature for a reason -- it gives app authors the ability to hide their app from users in the store whose device model is eligible for a given API level, but haven't received it yet, for whatever reason.

Simple example: Someone writes an app which is useless without gyroscope data and they want to release it for F6Pro.

Seems to me that using the "min API level" feature is the only way to hide the app from F6Pro devices which haven't received the 3.3 update yet (e.g. they have an APAC device or they just haven't updated yet for whatever reason.)

Setting a min API of 3.3 could cause issues for 4.0 devices that haven't gotten the 4.1 VM, with APAC Venu2/2s being a probable example.  APAC FW can come some time after World Wide. 

With "has" you can alert the user and not just have the app crash.

jim_m_58 said:

Setting a min API of 3.3 could cause issues for 4.0 devices that haven't gotten the 4.1 VM, with APAC Venu2/2s being a probable example.

That was exactly the problem which I raised above. That's why I think a "min API level" of 3.3 should really be:

- 3.3 for 3.x devices

and

- 4.1 for 4.x devices

Maybe that's how Garmin will implement it? Idk. Perhaps that's what the option will look like in the future:

Min API Level: "3.3/4.1"

jim_m_58 said:

APAC FW can come some time after World Wide. 

Yup, that's what I said above, which is why I think min API level (if properly implemented) could be useful in certain situations. Unless you're implying that "min API level" is not a feature that devs should use, at which point I would question why it exists.

jim_m_58 said:

With "has" you can alert the user and not just have the app crash.

So you would let a 4.0 user download an app that absolutely requires a 3.3/4.1 feature such as gyroscope data, then inform them that the app won't work when they open it?

Or would it be better for Garmin to allow the app to be hidden from such users in the store?

And this has come up a few times over the years, and why I use a min SDK of 1.2, and include "has" to check things.  Also, if you use has, when a device gets the needed FW, it will start working without need of publishing anything new,

If you write something that uses Weather and set a min SDK of 3.2, even though the f5+ devices have 3.2, they don't have Weather. so having a "has" will protect against crashes.

jim_m_58 said:

And this has come up a few times over the years, and why I use a min SDK of 1.2, and include "has" to check things. 

jim_m_58 said:

If you write something that uses Weather and set a min SDK of 3.2, even though the f5+ devices have 3.2, they don't have Weather. so having a "has" will protect against crashes.

Good example, my 935 is old so I forgot about that nuance since none of my apps support weather.

Maybe Garmin should rethink "min API level" then, and allow apps to declare various "required" features like Weather or Gyroscope in the manifest, so they can be filtered in the store that way. The huge downside here would be the additional complexity.

Or at the very least, Garmin could deprecate "min API level" or warn people not to use it.

Maybe it's just me, but it doesn't seem very developer friendly to have a foundational feature like "min API level" but actually using it is unofficially discouraged.

I mean Garmin even says this:
https://developer.garmin.com/connect-iq/connect-iq-basics/

System versus API Level

Connect IQ uses two versions[1]: the API level and the system number.

The API level is a three number (major.minor.micro) version that dictates the potential APIs that a device supports. As stated above, not every device supports every API, but if a product is at or below an API level it is guaranteed to not support an API.

The system number is a single digit number that is associated with a minimum API level. The system number communicates the set of devices that meet the minimum API level.

Actually, by their definition, the system number should be associated with *multiple* minimum API levels. e.g. For system 5:

- min API for 3.x devices is 3.3

- min API for 4.x devices is 4.1

Maybe "min API level" should become "min system level" in the manifest.

I realize it doesn't solve the weather problem you raised, but perhaps it would go further to making the "min API level" feature more useful.

jim_m_58 said:

Also, if you use has, when a device gets the needed FW, it will start working without need of publishing anything new,

This seems like a non sequitur, if we're comparing "has" to "min API level" -- you don't need to publish anything new if you set min API level to "X" and a device gets "X", either.

But I guess we've already established that min API level is not useful in several circumstances. That's a different argument though.

If you have an existing app, chances are you don't want to change min API or System.  In the case of something like body battery or stress, you just don't display it if it fails the "has".  A good example is the fr245 that doesn't support "floors" but for about everything else(FW level,etc), it's just like a 945.

Can anyone help me whith how to get to the f6pro preview in eclipse? Or is this not available yet?

I tried using the Venu but it doesn't recognize sensorData.gyro