‐4198 Display sub meter accuracies using cm (redux)

The issue

Several strings are used to display GPS accuracy:

• gps_result by getGeoPointAnswerToDisplay in GeoWidgetUtils
• location_status_accuracy etc by updateUi in GeoPolyActivity
• location_accuracy by getAccuracyMessage in GeoPointActivity, and by formatLocationStatus in GeoPointMapActivity

The update

Each format string now needs two variants, for formatting accuracy as cm or m. So code using these strings has to look at the accuracy value so as to

• decide which format to use, and
• where the answer is cm, scale the value to match ie multiply by 100.

As suggested by @seadowg this is now encapsulated in a single method which returns the appropriate string; affected methods are adjusted to match.

?To avoid duplicating code for location_accuracy, getAccuracyMessage and formatLocationStatus now get their formatted string from getAccuracyUnitString in GeoUtils.

?Although truncateDouble is no longer called by getAccuracyMessage its logic is still required in a couple of places. So it has been made static and moved to GeoUtils as truncateDoubleValue, to avoid confusion with truncateDouble in GeoWidgetUtils.

Simulation

In addition to the formal testing described below, there was a need to simulate cm accuracy so as to confirm coverage of all occurrences in the UI.

Once again thanks @seadowg for pointing out this can be done very simply by intercepting ?

The form defined in geowidgets.xlsx can be used to test for suitable values.

Testing

The new code is tested by ?

---

Addresses #4198 (further reworking of #4866, #4966)

What has been done to verify that this works as intended?

See 'Simulation' and 'Testing' below.

Why is this the best possible solution? Were any other approaches considered?

Now improved and simplified - thanks @seadowg for your suggestions.

?See 'The issue' and 'The update' below.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

None?

Do we need any specific form for testing your changes? If so, please attach one.

geowidgets.xlsx used for development testing, see 'Simulation' below.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines