Acknowledged
5 months ago

Compiler Bug: Typechecker does not accept ScanResult object for Applicaton.Storage

If i code

Storage.setValue("MyBLE_ScanResult", scanResult as ScanResult);    

the type checker complains that ScanResult is not an Application.PropertyValueType. 
That's true, but the API says that from v3.2.0 on it is possible to save a ScanResult with Application.Storage.

CYBERMAN54
  • 2 months ago

    > This seems to be fixed with SDK v7.3.0

    It hasn't been fixed afaict

    I tried to build the following code with the default type checking level, for fr955 with SDK 7.3.0:

       // this function is in the main app class which extends AppBase
        function foo() {
            var scanResult = null;
            Properties.setValue("MyBLE_ScanResult", scanResult as Toybox.BluetoothLowEnergy.ScanResult);  // line 45
            Storage.setValue("MyBLE_ScanResult", scanResult as Toybox.BluetoothLowEnergy.ScanResult);  // line 46
        }

    Result:


    ERROR: fr955: PATH/TO/SOURCE/MC:45,8: Invalid '$.Toybox.BluetoothLowEnergy.ScanResult' passed as parameter 2 of type 'PolyType<Null or $.Toybox.Application.PropertyKeyType or $.Toybox.Lang.Array<$.Toybox.Application.PropertyValueType> or $.Toybox.Lang.Dictionary<$.Toybox.Application.PropertyKeyType,$.Toybox.Application.PropertyValueType> or $.Toybox.WatchUi.BitmapResource>'.
    ERROR: fr955: PATH/TO/SOURCE/MC:46,8: Invalid '$.Toybox.BluetoothLowEnergy.ScanResult' passed as parameter 2 of type 'PolyType<Null or $.Toybox.Application.PropertyKeyType or $.Toybox.Lang.Array<$.Toybox.Application.PropertyValueType> or $.Toybox.Lang.Dictionary<$.Toybox.Application.PropertyKeyType,$.Toybox.Application.PropertyValueType> or $.Toybox.WatchUi.BitmapResource>'.

  • 2 months ago

    This seems to be fixed with SDK v7.3.0

  • 5 months ago

    https://developer.garmin.com/connect-iq/core-topics/complications/

    The sample code actually only shows retrieving a complication ID from storage, but my point stands.

  • 5 months ago

    I *think* the same issue exists for Complications.Id. The complications docs (in the general CIQ dev site, not the API docs) mentioned that a complication ID can be persisted to storage (and provided example code to do so). This originally did not work, but I think it might have been fixed at some point (other than the type checking aspect.)