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 in reply to FlowState

    We aren’t talking about removing functionality from existing devices here. Just removing from the new ones where usable alternatives exist.

    Devices that have the Storage or Properties modules should use them. Devices that do not can continue to use the AppBase.getProperty and .setProperty methods.

    That said, we provide at least two ways to do this. We have had support conditional compilation using jungle files and annotations for some time. If using a recent compiler version, we have branch elimination optimizations that can be used to write code that is essentially a compile-time branch.

    I can post examples later. I’m on mobile right now and getting ready to go for a mountain bike ride.

    I’m sorry to be venting here, but we are seeing very popular apps by competent developers that are still using these deprecated functions. Every time we try to remove these functions for a new device, we are rebuffed because it will break someone’s app.

    It is extremely frustrating.

Comment
  • over 1 year ago in reply to FlowState

    We aren’t talking about removing functionality from existing devices here. Just removing from the new ones where usable alternatives exist.

    Devices that have the Storage or Properties modules should use them. Devices that do not can continue to use the AppBase.getProperty and .setProperty methods.

    That said, we provide at least two ways to do this. We have had support conditional compilation using jungle files and annotations for some time. If using a recent compiler version, we have branch elimination optimizations that can be used to write code that is essentially a compile-time branch.

    I can post examples later. I’m on mobile right now and getting ready to go for a mountain bike ride.

    I’m sorry to be venting here, but we are seeing very popular apps by competent developers that are still using these deprecated functions. Every time we try to remove these functions for a new device, we are rebuffed because it will break someone’s app.

    It is extremely frustrating.

Children
No Data