There are web services that can be used to accomplish this, for example the Google Distance Matrix API, MapQuest RouteMatrix, Bing Route Data. Need to investigate API limitations...

More interestingly, there is an offline solution called graphhopper: https://github.com/graphhopper/graphhopper/blob/0.5/docs/android/index.md

I'm thinking that the OSM data for Greenville will be small enough to package in to the app and search without a huge performance hit. Will need to test on a crappy phone to confirm.

Where users can adjust polling interval, zoom settings, etc

Button that opens email app to leave feedback

Route colors are now sent from server - use them when present instead of preset values.

Need to investigate. Maybe some inconsistent data is being returned from the API? Not sure why this would only happen one time on one device. DateTime parsing error.

Will be used for branding and to access the menu. The menu will be used to switch to the schedule view and to access settings.

Integrate Fabric Crashlytics for in app analytics tracking
https://docs.fabric.io/android/answers/overview.html

Address this:

Hello Google Play Developer,

We're writing to let you know that the apps listed at the end of this email may be affected by an upcoming platform change.

Action required: If your app requires GPS hardware to operate properly, you will need to explicitly add the "android.hardware.location.gps" uses-feature to your manifest.

What’s changing

We’re making a change on October 15th, 2016 that will affect apps targeting API version 21 (Android 5.0, Lollipop) or higher that use ACCESS_FINE_LOCATION but don't explicitly have the "android.hardware.location.gps" uses-feature. Going forward, these apps will be available to install on devices that don't have GPS hardware. In most cases this won't be an issue since Wi-Fi and Cell-ID based location provides high enough fidelity for the typical operation of these apps. However, any apps that require GPS hardware, such as GPS navigators, should explicitly add the "android.hardware.location.gps" uses-feature to their manifest.

If your app requires GPS to function properly and you do not include android.hardware.location.gps in your manifest declaration, your users may have a poor app experience.

Also, if you’re using the fused location provider and wish to receive the most accurate location samples from GPS (i.e. with PRIORITY_HIGH_ACCURACY), you must include the "android.hardware.location.gps" feature in your app’s manifest to ensure that Google Play only distributes your app to devices with GPS sensors.

You can read more about this change in the Android Developers Help Center.

Regards,

The Google Play Team

Up to 20 affected app(s) and version(s) are listed below. If you have more than 20 apps in your catalogue, make sure to check each app for this issue.

com.codeforgvl.trolleytrackerclient 15

Only happening in some cases... so add a null check since this is just a UX aid

Was just doing some testing on the production app and it appears that the Schedule page is not responsive (Pixel 1)

Not sure what could cause this. Seems to have something to do with SupportMapFragment.onCreateView

Not shown in screenshot: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.io.File.mkdir()' on a null object reference

@ajhodges details in http://Fabric.io, but has triggered 10 crashes on 5 users

Currently only displaying the first route

Some people prefer it. Could put this in the settings

The changes we made in #42 have made it so the routes are not cached by the client, so depending on the Android lifecycle, sometimes when you open the app after it has been in the background for some time the map will be blank for a few seconds while it reloads.

The original behavior was that the old version of the trolleys/routes were shown and then it updated as soon as the new data was available. I think we should either try to find a way to preserve this while avoiding #42 or come up with a good loading indicator to show the users that the latest route/trolley data is being pulled.

To provide a better UX, consider updating routes on every quarter hour, and if data is more than 15 minutes old.

hackgvl/trolley-tracker-ios-client#20 (comment)

Use the last x number of trolley updates to determine the trolley's direction. Maybe show the direction the trolley is travelling when the trolley is selected.

One the drivers suggested that they use the consumer app to see where the other trolley is so they can better time the driving and we don't get into the situation where two trolleys are basically following each other around the loop.

Seems like a pretty good idea. The one question Greenlink had was, "how much data would be used if they kept the app running for an entire day."

The other thing was we'd have to change the app to keep the device screen on at all times. A positive for this would be that we at least know the device would be on.

Any other thoughts?

CC: @ajhodges

Either by expanding a listitem when it is selected or via a popup. Would be nice to let users see what a route is going to look like and what stops it has.

Load the current routes and trolley data, making use of the progress bar

(instead of a route preview)
Note to self: using the app after a beer or two helps uncover basic UX issues ;p

Improve error handling, timeouts for API interaction, let user know about connectivity issues

Instead show the schedule view. Or if there is a scheduled route currently active, show an error message about trolley communication issues.

When the user selects the trolley, the ID is shown. For consistency and more information, show the trolley name as sent from the server.

The trolley schedule isn't showing at the moment on my phone, but it shows up in the webapp just fine.

I opened the app today (Friday 1/8 around 1pm.) during the lunch route and it said there were no trolleys and to check schedule.

I then went to the map view and saw the trolley running. So, it seems the app is not pulling the route info for the Friday lunch route.

Need logos, screenshots, a 'feature image', app name, app description for the play store listing.

Accessible by selecting a stop twice or dragging up on the bottom bar to expand the stop view. Will show details of a stop, including description, route name, picture, maybe points of interest, and hopefully eventually an ETA for the next trolley

Sometimes elements from the live map will flicker through to the route preview fragment. The most consistent way I can reproduce it (it is very intermittent) is to select a running trolley on the tracker map, then open a route preview and pan around a little bit.

Right now routes are hardcoded. Need to pull the current route(s) from: http://api.yeahthattrolley.com/api/v1/Routes/Active

Then use http://api.yeahthattrolley.com/api/v1/Routes/:id to load route shape and stops

Note to self: consider using a splash screen while loading initial route/trolley data.

Refresh 'stale' route data... maybe if more than 2 hours have passed since the last update?

Change needed to support the new trolleys being added. Color will be defined on the back end.

I think this probably ties in with #17. Seems like the call to the API came back with null. Need better exception handling.

Looks like I am not handling the case where the schedule is empty. Related to #17

Should display the trolley schedule and highlight the active or next route

Went ahead and published the app as a beta on the play store. Needs a good bit of work (and I already know of one bug where the app crashes) but I figured people would want to try it out at our meeting tomorrow (8/25).

Here's the link to opt-in and download: https://play.google.com/apps/testing/com.codeforgvl.trolleytrackerclient

Need to implement onSaveInstanceState

Show a loading indicator or other visual cue to let user know when updates occur. Shouldn't be annoying since updates happen frequently.

When the app is re-shown, don't show old (>2min old) location data

Exception while loading data in the SplashScreen. Probably just need to handle cases where the API returns no data.

Integrate Fabric Crashlytics for tracking issues and crash rates for our app
https://docs.fabric.io/android/crashlytics/overview.html