Support multiple OBA servers in different regions

[onebusaway]

Support multiple OBA servers in different regions

[paulcwatts]

Work is being done in this branch:
https://github.com/paulcwatts/onebusaway-android/tree/feature/MultiRegion

[barbeau]

Just an fyi for those following this ticket - I'll be picking up work on this issue.

[barbeau]

Working technical details for the OTP Server Directory, as well as OBA Mobile App changes, are here:
https://github.com/OneBusAway/onebusaway/wiki/Multi-Region

[barbeau]

Equivalent edits are also taking place with OBA Windows Phone app (See https://onebusawaywp7.codeplex.com/workitem/19392#)

[barbeau]

As of 5/16/2013, one of the last major features that needs to be implemented is the initial fetch of regions from the Regions REST API on first app startup after install. This needs to be woven into the existing startup logic, and will add additional latency to startup because of the need to fetch info over the network. Therefore, we need to find a way to show the user that this fetch is happening.

One option is a splashscreen.

After some googling it seems that the design pattern of using a splash screen, and especially a splashscreen in a separate Activity, is something to be avoided.

Android docs:
http://developer.android.com/design/patterns/help.html
http://developer.android.com/training/articles/perf-anr.html

Various articles:
http://cyrilmottier.com/2012/05/03/splash-screens-are-evil-dont-use-them/
http://blog.iangclifton.com/2011/01/01/android-splash-screens-done-right/

Also, none of the Google Android apps (Maps, Google+, Voice, Play, Music, etc.) use splash screens, but just indeterminate progress dialogs within fragments (it appears), presumable with AsyncTasks in the background. Chrome uses a progress bar just under the URL text box, presumably since it’s easier to count the progress of rendering page components.

Advantages of using something like a AsyncTask with a progress dialog include not having to worry about the Activity stack, etc., and it would also be reusable within other Activities/Fragments as well. I think it also gives the user a more uniform experience, since they can see the main OBA screen in the background while we’re loading, instead of throwing them to a separate splash screen.

So, as of right now, our plan is to do an initial implementation that’s similar to the OpenTripPlanner (OTP) Android app using a AsyncTask and ProgressDialog.

OTP Android on Google Play:
https://play.google.com/store/apps/details?id=edu.usf.cutr.opentripplanner.android

OTP Source that fetches OTP regions info on startup:
https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/blob/master/src/edu/usf/cutr/opentripplanner/android/fragments/MainFragment.java#L402

[barbeau]

Documenting discussion between Paul and I re: how to handle starred and recent stops/routes lists on region switch. Per below discussion, current plan is to add a new database column.

---

Asking the user to restart the app is mostly just a precaution, because the backup is copying over the DB file while it could potentially be using it. I'm not sure if we want to be doing this often, because I suspect it could be possible to corrupt the user's DB.

Another option is adding the region ID as a column in the database. When they are saved, the ID of the current region is saved. When they are displayed in a list, we display only those that match either the current region or NULL (for compatibility with existing users).

Obviously this won't handle every case, but it may work for now. Eventually it might be easier to be able to have every activity be able to specifically set the region/context in its requests.

Paul

---

Paul,
Just realized that we haven’t discussed how to handle the starred and recent stops and routes lists in the context of a region switch. Currently, they just remain on the screen, and if the user taps on them they get the “Sorry that stops wasn’t found” message, which obviously isn’t good.

The easy approach is just to wipe them clean on region switch, but that seems lazy.

How about we use the Backup feature on region switch to save and restore these items?

For example if we are switching from Region A to Region B, we would:

1.  Backup the starred/recent stops and routes for the Region A to a file “db_A.backup”
   

2.  Try to restore from a file “db_B.backup” if it exists
   

I noticed that after executing a restoring a backup in the current OBA app, it asks the user to restart the application. Assuming this is a reasonable approach, what would we need to do to refresh the application state without restarting the app?

Sean

[barbeau]

An issue not discussed above is how to handle inserting or querying stops/routes when Application.get().getCurrentRegion() == null. Current region can be null when the user enters their own custom API URL via Preferences->OneBusAway API Server.

Setting regionId when inserting stops/routes is obvious - when stops/routes are inserted and the current regionId is null, the regionId should be set to null.

Seems we have two options for querying routes/stops when current region is null:

1. If the current region is null, we should return all stops/routes saved in the database (including those with regionId == null).
2. If the current region is null, we should return stops/routes where regionId = null.

I'm leaning towards 1 above. Its likely that only power users/admins/developers will be using this feature, and we should err on the side of showing them too much info rather than too little. One potential use case for why we should return all stops is a OBA Server Admin testing on a new OBA server version (i.e., a production OBA instance already exists in the same area). Admin could use recent/starred stops/routes saved on the device from the production server (that have a regionId) to test on a test server with a custom API URL (where the current region would be null).

Or, if we want 2 above, we strictly only show stops/routes that were viewed or starred either while a custom API URL is entered or before the app was updated to a new version that supports regions.

@paulcwatts what do you think?