ERA report can only be replicated with brute force, any known issues with settings?

Hi,

I have started seeing an error report in ERA that I cannot make sense of. The error occurs on multiple Forerunner® 245 Music: 4.40 (which looks like the most recent FW) in two languages so far (English and Korean) using the latest version of the app and it occurs on a seemingly innocuous line where I write a value that has just been read from settings into a FitField without manipulating it.

I have pasted a code extract below:

// IN PROPERTIES
<property id="fieldValue" type="number">300</property>

// IN SETTINGS
<setting propertyKey="@Properties.fieldValue" title="@Strings.fieldValueTitle" prompt="@Strings.durationError">
	<settingConfig type="numeric" min="0" max="3000" errorMessage="@Strings.durationError"/>
</setting>

// IN APP initialize()
var type = FitContributor.DATA_TYPE_UINT16; 
var options = {};
options[:mesgType] = FitContributor.MESG_TYPE_SESSION;
options[:units] = loadStr(:unitSeconds);
var fieldValue = app.getProperty("fieldValue"); 
ff = session.createField(loadStr(:fieldTitle),fieldId, type, options);
ff.setData(fieldValue); // CRASHES HERE WITH "Error Name: Invalid Value" IN ERA LOG

The only way I can replicate the error is to hardcode "var fieldValue = null;"

I have previously seen behaviour where properties that are defined in properties.xml but not explicitly managed via settings.xml are lost, but that cannot be the cause here. My app both sets and manages the property in settings.xml and properties.xml complete with a valid default value. I have not been able to even input, let alone save, an invalid value into settings via any of the apps.

This is not even a new or recently introduced property! It has been there since the first release.

So...

Is this a bug that I need to do a bug report for, or is it that I need to introduce an additional level of paranoid coding to default my settings if they are null or not found?

Thanks,

Top Replies

Brandon.ConnectIQ over 3 years ago in reply to Brandon.ConnectIQ +1

https://forums.garmin.com/developer/connect-iq/i/bug-reports/getproperty-returning-null

All Replies

0 Brandon.ConnectIQ over 3 years ago

It would make sense to include null checks in case that's the cause, particularly since getProperty() can return null, but I'm concerned that there may be a firmware bug behind this since it's only been affecting Forerunner 245 Music. I would expect this to also appear on at least 245 (non-music) as well.

I'll create a bug report from this, and we'll do some additional investigation.

0 Brandon.ConnectIQ over 3 years ago in reply to Brandon.ConnectIQ

https://forums.garmin.com/developer/connect-iq/i/bug-reports/getproperty-returning-null

0 jim_m_58 over 3 years ago in reply to Brandon.ConnectIQ

I always null check stuff like this and include a default. The code in the new developer FAQ - readKeyInt() though my current version includes a try/catch for Application.Properties.getValue if that's used.

0 jim_m_58 over 3 years ago in reply to jim_m_58

A simple wrapper that also handles the cases where a value of the wrong type is seen (as has happened over the vears).

Getting a string when you think it's a Number for example.

0 jim_m_58 over 3 years ago

Are you sure you're seeing a null and not a an incorrect data type? (see my post about the new developer FAQ)

0 9635560 over 3 years ago in reply to jim_m_58

The value has only ever been defined as a numeric value with numeric settings input and a numeric default. It has been that way since 0.0.1 (and I'm now on 0.0.19). The only way this value is manipulated is by the user using settings UI of one of the Garmin apps.

TL:DR; If the value is anything other than a number, it is not my bug!

0 jim_m_58 over 3 years ago in reply to 9635560

Look at the new developer FAQ. This is exactly the case where a Number may not be seen as a Number.

My app uses app settings, and it sometimes crashes after changing the settings, but the rest of the time it works fine. What can cause this?

In the past, there have been issues where the client used to manage app settings, like Garmin Express or Garmin Connect Mobile, has returned a setting value with an unexpected type, so it's good practice to check a setting value to ensure it's the expected type. For example, this code will check for a null value and convert the value to a Number as long as it is not null. Otherwise, a default value is returned:

function readKeyInt(myApp,key,thisDefault) {
var value = myApp.getProperty(key);
if(value == null || !(value instanceof Number)) {
  if(value != null) {
   value = value.toNumber();
  } else {
   value = thisDefault;
  }
}
return value;
}

0 jim_m_58 over 3 years ago in reply to 9635560

It might not be your bug, but this first started happening right when app settings were introduced back in 2016 and easy to work around.

I do this check in ever app that does app settings.