Improve search, including integration of recent stops/routes feature

[barbeau]

• Implement recent routes/stops via search in action bar (see FTS tables) - see Searchable Directory legacy sample app.
• Use android:searchSuggestAuthority="${applicationId}.provider.ObaProvider">.
• Enable voice search.

[barbeau]

A related issue is adding address search - https://github.com/OneBusAway/onebusaway-android/issues/191.

[barbeau]

As mentioned above, I'd like to integrate the "recent" stops and routes feature into search when doing search improvements. In other words, by default when tapping on the "Search" icon, the drop-down list would have both recent stops and routes within it - something like:

(Google Drawing for above mockup is here)

As you type, the list would auto-complete and be updated to reflect choices close to what you're typing. "Recents" here would be defined both as what you've recently searched (using the Search widget), as well as what you've previously viewed in the app (this is what is currently visible in the recent stops/routes fragments).

We could potentially extend search to do real-time queries of the API as well as part of auto-complete.

[barbeau]

Showing recents in search view was also mentioned in this comment.

[bbodenmiller]

Was just about to post about this - the my routes item under the current menu seem out of place.

[bbodenmiller]

An issue I'm seeing:

• search for stop 515
• select stop
• select show on map

At this point stop is zoomed to but not highlighted. Should I file a separate bug for this?

[barbeau]

Was just about to post about this - the my routes item under the current menu send out of place.

Yup, this is now removed in the develop branch, and replaced by a "recent routes/stops" item. Placement of this isn't ideal either, but it's just a placeholder until we get improved search into place.

At this point stop is zoomed to but not highlighted. Should I file a separate bug for this?

Thanks for the reminder - I saw this but it dropped off my list. Just opened https://github.com/OneBusAway/onebusaway-android/issues/370 for this.

[barbeau]

From #391:

Currently when you do a search you are taken to a new view for the results. If you made a typo or want to update your search query, you must select back and redo the search. Would be great if the search bar remained on the results view.

The auto-complete would help with some of this prior to selecting enter to process the search, but after selecting enter we could definitely make the search widget available at the top of the screen when showing results. This is similar to how Gmail behaves - here's the screen after hitting enter for a search:

[barbeau]

@cagryInside implemented a nice custom drop-down for the issue reporting categories that we can re-use for this:

[barbeau]

FYI - Google now has a Places auto-complete widget that doesn't have a quota: https://developers.google.com/places/android-api/autocomplete

This helps for addresses and POIs (Walmart, Publix, McDonalds) but doesn't help us with GTFS stop and route names.

There is also a new Geocoder called Pelias - https://github.com/pelias/pelias.

It’s an open-source geocoder by Mapzen, and they’ve indicated they’d be willing to waive usage limits for us. We’ve been talking with them about research topics based on data they would collect from searches as well. A major advantage here is that they plan to integrate Transitland transit data into their indexing service as well – to my knowledge no other geocoder allows you to search for information coming from GTFS data, or has this in their roadmap. I haven’t seen any results from Pelias yet, though, so I don’t know what the currently quality is. I opened this issue on OTP Android about Pelias with more info - https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/issues/485.

Note there is an Android SDK for Pelias - https://github.com/pelias/pelias-android-sdk - although it currently requires API Level 15 and above (we're currently at 9).

[barbeau]

There is also a discussion here on the OBA dev list about improving OBA search server-side: https://groups.google.com/d/msg/onebusaway-developers/w0g5E8zVe60/IYeHG000CQAJ

Currently OBA server search only supports searching for stop_id and route_id.

[bbodenmiller]

It appears the programmatic Google Places autocomplete access also has no limit but requires additional verifications to unlock higher limits.

If Google Maps is any indication of the results autocomplete could return it does have stops but not routes.

[barbeau]

If Google Maps is any indication of the results autocomplete could return it does have stops but not routes.

Historically from what I have been able to tell, Google does it's own thing in Google Maps, so I'd be somewhat surprised if the geocoding results from the Places autocomplete widget that is available to us matches what we see in the Google Maps app. But it's possible.

[barbeau]

From some testing of Places autocomplete widget, which we're now using for origin/destination autocomplete for the trip planning feature, it does return GTFS bus stop names in auto-complete.