Open aaronbrethorst opened 7 years ago
I bet I could do this pretty easily and without a lot of battery impact by geofencing the destination. here's a library that looks like it could help with the geofencing: https://github.com/benzamin/BBLocationManager
FWIW, we have "destination reminders" on OBA Android that is effectively this feature: https://github.com/OneBusAway/onebusaway-android/blob/master/DESTINATION_REMINDERS.md
It's actually a generalized port of some of our previous research at USF designed to help individuals with intellectual disabilities use public transportation by providing precise reminders of where to exit the transit vehicle. There is a description of the project with a YouTube video here: https://www.usf.edu/news/2019/federally-funded-technology-eases-fears-for-riders-too-nervous-to-take-the-bus.aspx
Battery impact is definitely a concern when using GPS, but we ended up relying on GPS because of precision and accuracy requirements. We also designed an algorithm to detect the exact vehicle departure from the stop prior to your destination stop, which is patented by USF - but we convinced USF to allow us to use the algorithm and open-source the software within OBA. If you're interested in checking out the algorithm and the main navigation logic it's in this class: https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/main/java/org/onebusaway/android/nav/NavigationServiceProvider.java
We also collected a lot of GPS data and annotated each trip on the exact coordinates that should trigger our "Get ready" and "Exit the vehicle now" audio/vibration reminders and implemented unit tests based on this data (so we know if any changes to the nav logic breaks behavior on real data). That data might be useful for automated testing on iOS regardless of the exact implementation of the feature, and is all the nav_trip*.csv
files here:
https://github.com/OneBusAway/onebusaway-android/tree/master/onebusaway-android/src/androidTest/res/raw
...with the navigation unit tests being implemented here: https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/androidTest/java/org/onebusaway/android/nav/test/NavigationTest.java
A key concern on Android is the variability of GPS/location quality depending on devices, so we also built a feedback feature into the app so that users in the real-world could give us a thumbs up or down and notes on how the algorithm performed in the wild, with the data (user feedback and GPS log of trip, optionally) being uploaded to Firebase. To be honest, though, this hasn't been active as a USF research project for a while so we haven't done much with the user feedback yet. It would be cool to have this kind of feedback data for iOS too, although I would imagine that device variability concerns aren't as great on iOS. See this page for more details on how the feedback feature is implemented.
For many riders, I think the precise algorithm we implemented is probably overkill and those users would be happy with even a large geofence surrounding the destination stop. There are definitely riders, including those with intellectual disabilities, that appreciate the increased accuracy and precision though.
This is a tracking task that needs to be fleshed out and split into multiple subtasks.
I've been asked by users on several occasions to let them better track when they are approaching their final destination. I can imagine this might be decomposed into a few different stories:
Look into the location manager region monitoring capabilities to see how these might be done: https://developer.apple.com/reference/corelocation/cllocationmanager
This library would be useful and save me some trouble here: https://github.com/malcommac/SwiftLocation