User Seting Data Types

This sure sounds like what's in the New Developer FAQ, point 10.

Wait there is an FAQ! Thanks all. And now it makes sense about the boolean, but I guess I expected a type mismatch error. toNumber symbol not found seemed to suggest to me that the method wasn't found. Anyway, I'll go read the FAQ now and I'm sure I won't need to post as often :-)

Yes, point 10 was a very frequent question when app settings were introduced back in CIQ 1.2.0. I can't even guess how many times Travis and I posted similar code for it.

readKeyInt() is in every app I have that uses app settings, and I have a similar readKeyBoolen() for those. With Application.Properties, there's a bit of a difference, as if a property doesn't exists, you don't get a null as you do with getProperties(), but it throws an exception, so I use try/catch for that.

update: This could also be connected to why in some apps, you see that only Garmin Express should be used to change settings. I've only ever seen the problem reported with GCM, and GE has just always worked correctly.

toNumber symbol not found seemed to suggest to me that the method wasn't found.

Well, in a way it wasn't, but I agree that the error message may have been misleading.

You may wish to file a bug report / enhancement request in the bug reports forum, asking for a more descriptive error message, such as "symbol not found for class X".

DaveBrillhart a slightly more efficient version (memory/code-space-wise) of that code. (In Monkey C, the ternary operator is more efficient than the corresponding if statement.)

// app is passed in for efficiency's sake
function getBooleanProperty(app, boolProp) {
return app.getProperty(boolProp) ? true : false;
}


One liners...

var User = { :lapFlag => true, :minRPM => 65, etc }

module UserSettings {
function getSettings() {
var uv, getP = Application.getApp();


uv = getP.getProperty("advPwrFlag_prop"); User[:advPwrFlag] = (uv != null) ? uv : User[:advPwrFlag];

uv = getP.getProperty("minRPM_prop"); User[:minRPM] = (uv != null) ? uv.toNumber() : User[:minRPM];

DaveBrillhart see my response above for code that is more efficient (memory/code-space-wise) for the boolean case.

The code you posted for the Number case really has no advantage over the code in the FAQ. Your code also misses the case when your property actually is a number in the first place. In that case, you're just ignoring the property, which is probably not what you wanted to do.

This might work better.
uv = getP.getProperty("numerical_prop");
User[:numerical_prop] = (uv != null) ? uv.toNumber() : null; // this assumes that uv is a string, number or float


I would argue that those are not one-liners. You can put any amount of code on a single line (including your entire program), but traditionally:
- Each statement (ending in a semicolon) goes on its own line
- The if condition goes on its own line

Those are really 3 liners. By cramming 3 lines of code onto one line, you are only making it harder to read and understand.

Thx! That is better. Except I'd resort to the default rather than null, and the toNumber() doesn't work for booleans. But I get the point. #alwaysLearning


uv = getP.getProperty("Value_prop"); User[:Value] = (uv != null) ? uv.toNumber() : User[:Value];

Thx! That is better. Except I'd resort to the default rather than null, and the toNumber() doesn't work for booleans. But I get the point. #alwaysLearning


uv = getP.getProperty("Value_prop"); User[:Value] = (uv != null) ? uv.toNumber() : User[:Value];

1) Yeah, the default value over null decision is def valid, especially since null may have no meaning for your app. And also because the only way you can receive null for a numerical property is when the user accidentally sets a non-numerical value in the GC app settings. (This is an issue which I have reported.)

2) If you're dealing with lots of properties, it might be better to use helper functions, especially if you've got all the extra error-checking and default value handling. It also makes your code more generic for anyone who is reading (and for your own reuse), rather than being specific for your app.

3) Yeah toNumber() doesn't work for bools, but the idea here is that you know how you defined your properties. If you really want to write very generic code (which takes up more memory), here's an alternative.


function getNumericalProperty(app, propName, defaultValue) {
var propVal = app.getProperty(propName);
return (propVal != null && !(propVal instanceof Lang.Boolean)) ? propVal.toNumber() : defaultValue;
}


Hopefully I haven't missed any other kinds of non-null properties (besides bool) which lack the toNumber() method. If I did, you would need to modify the function appropriately, if you are concerned about bullet-proofing your code. A different way to do it would be to explicitly check for Number, Long, Float, Double and String (and convert where necessary/desired) which would of course make the code even more inefficient. But for most apps it wouldn't matter.