Of course I've already wasted another few bytes to secure against this behaviour...

Sometimes (e.g. Weather.observationLocationPosition) you don't have chance to check QUALITY_* and you have only values.

_psx_ I understand, but my point is that right now you should be able to use the Position.QUALITY_* value to determine whether the position is valid.

This issue has been raised before, and I've brought it up for discussion again, so it's possible we may decide to set the position to null if we have a "not available" quality at some point, but that won't likely happen soon since it is a potential breaking change to the API. (Plus, there may be reasons it was decided to not set it to null that I'm not aware of.) 

Brandon.ConnectIQ

Sometimes is 180, 180 sometimes 0,0 sometimes null so it means system sets this values knowing about QUALITY_XXX, so question is why system doesn't sets it always to null?

I have to check always null and it should be enough to know if value is valid.

_psx_ Are you checking the Activity.Info.currentLocationAccuracy value before relying on the position info? The expectation is that the location accuracy should show a Position.QUALITY_* value, which can be 0 to indicate "not available".

If you're checking that and it's not reporting something you can rely on, let me know. Otherwise, I would expect you to get a position of [0,0] and a location accuracy of 0 and know that the location is invalid.

island, sea, mountains... it doesn't matter because [0,0] it's the valid gps position so shouldn't mean 'no data' especially there is a null