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

    I feel like we've everything we can to help avoid this, and I feel like developers are doing everything they can to ignore us. Please, for the common good, don't ignore us.

    Sorry if this is a stupid question, but how do we avoid using AppBase.setProperty() and AppBase.getProperty() for old devices such as fr235? Are we meant to stop supporting those devices?

    Or should we only use older SDKs to build for those old devices? If so, that would mean either:

    - bifurcating apps to have separate versions for old and new devices

    or

    - hacking the export process to mix and match output from different SDKs

    What's the official recommendation for old devices?

Comment
  • over 1 year ago

    I feel like we've everything we can to help avoid this, and I feel like developers are doing everything they can to ignore us. Please, for the common good, don't ignore us.

    Sorry if this is a stupid question, but how do we avoid using AppBase.setProperty() and AppBase.getProperty() for old devices such as fr235? Are we meant to stop supporting those devices?

    Or should we only use older SDKs to build for those old devices? If so, that would mean either:

    - bifurcating apps to have separate versions for old and new devices

    or

    - hacking the export process to mix and match output from different SDKs

    What's the official recommendation for old devices?

Children
  • 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.