Acknowledged
20 days ago

fix documentation of min api level in Activity.SPORT_* and SUB_SPORT_*

The current documentation (both in SDK 7.x, 8.x) for Activity lists that Activity.SPORT_GENERIC was added to the SDK at api level 3.2.0. While I understand that this is the historic fact, I think it's misleading. The documentation of ActivityRecording lists all these constants as deprecated and "hints" that we need to use the constants in Activity. And if I understand how this works than these constants are replaced with their values at compile time, at least since SDK 7.x. So if I am correct then I can use Activity.SPORT_PADDLING in an app with min api level of 1.0.0. Right? So listing it as since api level 3.2.0 isn't really useful. In fact in a way it's harmful, because I am able to write this code:

var session = ActivityRecording.createSession({
	:name => "foo",
	:sport => Activity.SPORT_HIKING,
});

and run this (at least in the simulator) on D2 Bravo (CIQ: 1.4.4)

So instead the current value of since, I think it should list, as it does for just about any other class, method, constant the min api level where the devices are compatible with it. So in my opinion each of these constants in Activity should be listed with the same values as they are in ActivityRecording.

update:

To make things even more confusing I am even able to add:

:subSport => Activity.SUB_SPORT_COMMUTING

which is clearly since api level 4.1.6 and still run it on D2 Bravo in the simulator. Not sure if this is OK, how this would behave on a real device. Maybe this is a bug in the d2 bravo in the simulator?

flocsy🤠
  • 18 days ago

     we found some discrepancies between the documentation and the simulator (maybe also real devices?) for example according to the documentation Activity.SUB_SPORT_CASUAL_WALKING is from api level 4.1.6 only which would mean that fenix6 that has max ciq 3.4.5 shouldn't have this constant, but

    Activity has :SUB_SPORT_CASUAL_WALKING

    returns true in the simulator. It looks like similar misalignments are for other SPORT and SUB_SPORT constants as well.

    Is this enough to "report" it here, or should I open a new bug report?

  • 20 days ago

    > However there's still the question: what VALUE can be used on what device?

    If you take the docs at face value (see what I did there), you should be able to use all enums which exist for the API level that's available on the device.

    After all, if you disable optimization, then the enum value lookup would happen at runtime, and the enum that you use would have to exist on the device (as part of the CIQ portion of the firmware).

    e.g. If your app tries to use Activity.SUB_SPORT_COMMUTING, then in order for the app not to crash, the enum Activity.SUB_SPORT_COMMUTING has to exist on the device. If Activity.SUB_SPORT_COMMUTING exists on the device, then it stands to reason that it should work (otherwise why would it exist on the device?)

    This is why optimization really obscures the issue (as noted), because it allows enums to be used which *don't* exist on the device, by replacing enums with their values.

    Couple of notes:

    - if we don't believe the docs are strictly true (e.g. maybe some device excludes a given enum even though it has the requisite API level), then we could use has checks

    - Ofc none of this tells us which combinations of sport and subsport are valid, and what will happen if we choose a bad combo (maybe createSession() will crash?)

  • 22 days ago

    After thinking about this further. I now understand that depending on the compiler settings the current min api level in the documentation can make sense. However there's still the question: what VALUE can be used on what device?

  • 23 days ago

    > So if I am correct then I can use Activity.SPORT_PADDLING in an app with min api level of 1.0.0. Right? So listing it as since api level 3.2.0 isn't really useful. In fact in a way it's harmful, because I am able to write this code:

    ...

    > and run this (at least in the simulator) on D2 Bravo (CIQ: 1.4.4)

    Maybe the real solution is to change the optimizer so it refuses to optimize away enums in the API that wouldn't exist on the device. Ofc this leads to the question: what should it do instead?

    - return an error? probably a bad idea, especially if there's any chance the device could get the enum in the future. (it would mean that enabling the optimizer would produce semantically different code than disabling the optimizer, but ofc we've seen that with has checks already)

    - just leave the existing lookup in the compiled code? ofc this could lead to crashes (if the dev didn't use a has check). but then again, using an enum value that's not supposed to exist on the device could also lead to a crash

    Yeah, I can see a lot of problems with trying to make the optimizer "smart" when it comes optimizing API enums.

    I don't really have any good ideas here.