Simple math help

You should be checking for currentSpeed being null. Maybe try:

return (info.currentSpeed != null) ? info.currentSpeed * 3.6 : 0;


null inputs considered harmful

I ran into the same thing and came up with the same solution.

This strikes me as broken. Current speed for an un-initialized device should not be null, it should be zero. There is no meaningful difference between these two things from a user perspective.

My concern is that I have to check for abnormal input conditions that don't make any sense and almost never occur.

Thats just wasted power and reduced runtime.

Actually, in the SDK Documentation for Activity.Info it says this:

A class containing information about the current activity. The fields in this class may return null so you should null check a value before using it.

One example for speed is "null" means it doesn't have the speed yet, while "0" means it has a speed and it's zero.

You want to check everything in Activity.Info for null, as that will be the state before recording starts and possibly a second or two after. (averageXXX seem to come a bit later).

Actually, in the SDK Documentation for Activity.Info it says this:


One example for speed is "null" means it doesn't have the speed yet, while "0" means it has a speed and it's zero.

You want to check everything in Activity.Info for null, as that will be the state before recording starts and possibly a second or two after. (averageXXX seem to come a bit later).

It sounds like we need a better API. Explicitly checking all these things for conditions that apply only .0001 percent of the time just wastes power and runtime.

Maybe some hack like this:

var realdata = null;
if ( realdata == null ) {
if ( info.totalAscent != null && info.elapsedDistance != null && info.averageSpeed != null ) {
realdata = true;
return(0);
}
else {
// Do actual computation
}

The null value is a sentinel and it has a very specific meaning. When info.averageSpeed is null that means that no average speed data is available. This is very different from a value of 0, which means that speed data is available but it indicates you are not moving.

Technically, the API could have adopted other sentinel values and accomplished the same thing. For example, using a negative value for average speed, or a heart rate of 255. Even if these sentinels were used, you still need to make the appropriate checks to ensure you are calculating a valid result.

If you want to avoid a crash, then set the values to something non-null if they are null. The amount of power you are using to check a condition is going to be tiny relative to all of the other moving parts.

Travis