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.

flocsy🤠
Parents
  • over 1 year ago

    From a refactoring standpoint it might have seemed like the best option to split Properties from Storage, but this was a big mistake from a backwards compatibilty poiint of view.

    It's simply not rhe right choice for something which is as widely used as AppBase.getProperty/setProperty. 

    I (still) don't think it's a good option to force a wrapper onto the developer or force the developer to use excludedannotations. It unnecessarily litters code.

    Mistakes and frustrations aside, I also don't see why it is such a big problem to keep the api around? What's the big deal....???

    And if for whatever reason you really want to get rid of geproperty loigic surely there must be a way that it's not frustrating for anyone. Why not have the wrapper functionaliy inside the virtual machine?

    Or alternatively it might even be easier to do the remapping while you are assembling the different prg files. Just write other opcodes/instructions while assembling the prg depending on the device api level? This doesn't sound like a hard thing to do.   

Comment
  • over 1 year ago

    From a refactoring standpoint it might have seemed like the best option to split Properties from Storage, but this was a big mistake from a backwards compatibilty poiint of view.

    It's simply not rhe right choice for something which is as widely used as AppBase.getProperty/setProperty. 

    I (still) don't think it's a good option to force a wrapper onto the developer or force the developer to use excludedannotations. It unnecessarily litters code.

    Mistakes and frustrations aside, I also don't see why it is such a big problem to keep the api around? What's the big deal....???

    And if for whatever reason you really want to get rid of geproperty loigic surely there must be a way that it's not frustrating for anyone. Why not have the wrapper functionaliy inside the virtual machine?

    Or alternatively it might even be easier to do the remapping while you are assembling the different prg files. Just write other opcodes/instructions while assembling the prg depending on the device api level? This doesn't sound like a hard thing to do.   

Children
No Data