Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GeoTrace: Add a selectable GPS accuracy threshold. #2891

Merged
merged 27 commits into from
Feb 21, 2019

Conversation

zestyping
Copy link
Contributor

@zestyping zestyping commented Feb 19, 2019

Overview

This PR lets the user specify an accuracy threshold for GPS points. In automatic recording mode, points will only be recorded if they meet the accuracy requirement.

The selection is made in the trace settings dialog. In order to prevent this dialog from getting too unwieldy, the existing interval spinners (number and time unit) are combined into one spinner (time interval). Thus, there is one spinner for the interval and one spinner for the accuracy threshold.

With this change, the user gets feedback on the GPS status at the top of the screen:

  • Whether the GPS sensor is searching or has acquired a fix
  • GPS accuracy
  • Whether the accuracy meets the threshold

And the user gets feedback on the collection status at the bottom of the screen:

  • Number of points collected so far
  • Whether recording is active
  • Recording mode, auto or manual
  • Automatic recording interval and accuracy threshold, if applicable

Guidance for reviewers

This PR is based on top of #2890. Only the commits after fc28c04 are part of this change.

I recommend reviewing the commits one at a time.

  • 40a27ac brings all the settings into a consistent pattern: each piece of UI state has a corresponding member field (recordingMode, recordingActive, intervalIndex); there are listeners on the relevant UI elements that update these member fields; and the updateUi() method updates all the UI elements from the member fields. This ensures that the member fields are kept in sync with the UI at all times; thus, saving and restoring state is simply a matter of putting the member fields into the instance state bundle. The items in the interval spinner are generated programmatically so that we don't have to do more translations when we change the available options.

  • 691636c replaces magic numbers with meaningful constants.

  • d886925 introduces filtering by accuracy.

  • cb88981 adds a spinner for the accuracy threshold, following the same pattern as the one for the interval.

  • 89aedca and 843447b add the lines of text above and below the map to give feedback to the user.

  • The remaining commits fix linter complaints.

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

I've tested GeoTrace manually in the emulator and on a phone:

  • Simulating changes in GPS accuracy level
  • Setting accuracy requirement to None
  • Setting accuracy requirement to a positive value
  • Changing the collection interval and confirming it is used correctly
  • Rotating the screen while automatic collection is occurring and confirming collection continues at the proper interval
  • Backspacing to delete points and confirming the status text is updated correctly
  • Clearing the trace and starting over with different settings

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

I had a few options for how to use string resources in the settings dialog. I considered using a string array for all the items in the interval and accuracy spinners, but ultimately decided to use <plural> so that it would be easiest to translate into other languages. Consequently, the items in the spinners are generated programmatically; this makes it easy to reconfigure the spinners without requiring new translations.

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?

This provides new functionality that's very useful for tracing roads, drains, and other linear geographic features.

This PR touches the existing code for selecting the recording interval and changes the way the recording interval is stored, so that's a regression risk. It does greatly simplify how the recording interval is handled, though, which should make the code easier to maintain. The change actually had the side effect of fixing a subtle bug that causes automatic recording to stop when the screen is rotated (because the recording is restarted before the recording settings are restored). Now that the trace settings are handled in a uniform way, this problem has gone away.

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

This can be tested using the GeoTrace widget in "All widgets".

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

getodk/docs#968

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

@zestyping
Copy link
Contributor Author

Here's a screenshot of the updated settings dialog:
2019-02-19 11-32-54

And this is the recording screen, showing the GPS feedback and collection feedback:
2019-02-19 11-31-57

@yanokwa yanokwa added this to the v1.21 milestone Feb 19, 2019
@cooperka
Copy link
Contributor

Tip: use https://github.com/opendatakit/collect/pull/2891/files/fc28c04..67d020b to view just the changes from this PR.

Copy link
Contributor

@cooperka cooperka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general, mostly just code style feedback! This does some nice cleanup.

);
locationStatus.setBackgroundColor(Color.parseColor(
location == null ? NO_LOCATION_COLOR :
acceptable ? ACCEPTABLE_LOCATION_COLOR : UNACCEPTABLE_LOCATION_COLOR
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same nit about colons

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

<string name="geotrace_collection_status_paused">Points recorded: %d</string>
<string name="geotrace_collection_status_manual">Points recorded: %d (manual recording)</string>
<string name="geotrace_collection_status_auto">Points recorded: %1$d (auto recording, %2$d s)</string>
<string name="geotrace_collection_status_auto_accuracy">Points recorded: %1$d (auto recording, %2$d s, %3$d m)</string>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest making these strings more explicit, e.g. auto recording every X s, Y m accuracy. Have you tested what happens if they wrap to two lines in other languages?

Copy link
Contributor Author

@zestyping zestyping Feb 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! I fixed the layout to allow for the status lines to have variable height.

I'd like to try to get the English text to fit on one line, so I shortened your suggestion to recording every X sec; it seems like every X sec should be enough to imply that it happens automatically.

I also realized that it's better for the status line to say every 10 min instead of every 600 sec, so I added format strings for that case. As a result, the ? : expression for this string has gotten pretty big—I hope the formatting makes it clear enough?

@yanokwa yanokwa modified the milestones: v1.21, v1.20 Feb 20, 2019
@zestyping zestyping force-pushed the ping/accuracy-threshold branch from 67d020b to 297c98f Compare February 20, 2019 01:40
@zestyping
Copy link
Contributor Author

Thanks for the quick review, @cooperka! I think I've addressed all your suggestions.

Copy link
Contributor

@cooperka cooperka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though I didn't have time to test the actual behavior today. Would be great if @grzesiek2010 could weigh in too.

@yanokwa yanokwa requested a review from grzesiek2010 February 20, 2019 04:38
@zestyping zestyping force-pushed the ping/accuracy-threshold branch from cb9e426 to 4699d37 Compare February 20, 2019 20:04
@zestyping
Copy link
Contributor Author

zestyping commented Feb 20, 2019

Rebased onto the latest 2890.

To view all the changes from only this PR in one diff (i.e. only 2891, not 2890):
https://github.com/opendatakit/collect/pull/2891/files/fff268d6..11342e3

@zestyping zestyping force-pushed the ping/accuracy-threshold branch from 11342e3 to 44f72cb Compare February 20, 2019 20:15
@zestyping
Copy link
Contributor Author

zestyping commented Feb 20, 2019

Rebased onto master and resolved a merge conflict in colors.xml.

To confirm that the current change is identical to the one that @cooperka approved (cb9e426, see above) except for the merge in colors.xml, you can compare git diff 50b1d9f cb9e426 to git diff 3752395 44f72cb.

To view all the changes from only this PR in one diff (i.e. only 2891, not 2890):
https://github.com/opendatakit/collect/pull/2891/files/3752395..44f72cb

@cooperka
Copy link
Contributor

@opendatakit-bot label "needs testing"

@mmarciniak90
Copy link
Contributor

@zestyping I did not check a lot of cases because these changes are based on #2890 which needs to be fixed. I just want to let you know that the scroll is visible when it is not expected because all buttons are visible

@yanokwa yanokwa added the high priority Should be looked at before other PRs/issues label Feb 21, 2019
@yanokwa yanokwa merged commit 7fd83b7 into getodk:master Feb 21, 2019
@mmarciniak90
Copy link
Contributor

Tested with success

Tested on Android: 4.2, 4.4, 6.0, 7.0, 8.1

Verified cases:

  • green/red header
  • disabled GPS
  • manual/automatic recording
  • light/dark theme
  • ~80 points
  • rotating
  • Google/OSM Maps
  • accuracy sets to None

@opendatakit-bot unlabel "needs testing"
@opendatakit-bot label "behavior verified"

@yanokwa yanokwa removed the high priority Should be looked at before other PRs/issues label Feb 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants