Under Review
over 2 years ago

bug: compiler 4.1.6 included broken parts of the 4.2.0 Beta 1 with -l 3

I just found that sdk 4.1.6 included parts of 4.2.0 Beta 1 that other bugreports reported recently as breaking some apps. More interestingly this inclusion wasn't mentioned in the announcment on 4.1.6.

See: https://forums.garmin.com/developer/connect-iq/i/bug-reports/sdk-4-2-0-beta-1-won-t-compile-appbase-getproperty

import Toybox.Application;
import Toybox.Application.Properties;

function setConfig(key as PropertyKeyType, val as PropertyValueType) as Void {
    MyApp.setProperty(key, val);
}

java -Xms1g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -jar /home/gavriel/Garmin/ConnectIQ/Sdks/connectiq-sdk-lin-4.1.6-2022-11-04-17f8cfdf3/bin/monkeybrains.jar -o bin/MyApp.prg -f /home/gavriel/Garmin/MyApp/monkey.jungle;/home/gavriel/Garmin/MyApp/barrels.jungle -y /home/gavriel/Garmin/developer_key.der -d fr235_sim -w -l 3

ERROR: fr235: /home/gavriel/Garmin/MyApp/source/Config.mc:17,4: '$.Toybox.Application.AppBase.setProperty' is deprecated.

  • I don't think this is a bug, but by design.

    I have to admit I agree with this.

    (Meaning I agree it's by design. I don't think the design is super well-thought out tho.)

  • -l3 is STRICT so you get an error fo things that on l1 or l2 might only be a warning

    Another condescending proclamation consisting of something that literally everybody here knows.

    I don't think this is a bug, but by design.

    I have to admit I agree with this.

    Strict typing gives you comfort that you will have less runtime errors, it should not refuse to compile your code because you use a deprecated feature

    Agreed. At the very least:

    1) There could be a flag to ignore the use of deprecated features

    2) There could be an annotation to ignore warnings/errors on the current/next line

    However, I think the *real* problem here is that as per the linked thread, some devs don't think getProperty() should have been deprecated at all, because there's no replacement that does what they want. I'm inclined to agree, but I can't stop Garmin from deprecating whatever they want (and they probably have good reasons for doing so).

    There's also the very good point that getProperty() is only deprecated for newer devices. For older devices, it's the only option and therefore it's unequivocally wrong for the compiler to flag its usage as an error, unless they have a way of *not* doing so when you build the project for older devices.

    If I'm understanding all of this correctly, basically the consequence of this bug is that you won't be able to use STRICT type checking for any older device that needs to call getProperty().

    Since Garmin implemented type checking to help us improve our apps (and therefore improve their own Connect IQ ecosystem), seems like they dun goofed here. This kind of thing will either prevent us from using strict type checking or prevent us from supporting older devices (maybe they don't care about the latter thing.)

  • I think the opposite.  It should flag things that could go away and are depreciated so they can be fixed/changed.  Don't like it?  Use something not as strict!.

  • Strict typing gives you comfort that you will have less runtime errors, it should not refuse to compile your code because you use a deprecated feature

  • And it will if you aren't using STRICT!