OBA mobile apps in app stores - Add Tampa as supported location?

[Sean Barbeau]

OBA mobile app developers,
This message is directed at the developers/maintainers of the "official" OBA open-source iPhone, Android, and Windows Phone 7 mobile apps.

We're currently deploying a OBA server instance in Tampa, Fl.  As part of this deployment, we'd like to make the OBA mobile apps available to Tampa transit users.

Would the current OBA mobile app developers consider adding a Tampa, Fl location to their currently deployed mobile apps in the respective app stores? 

Looking at this from a long-term maintenance perspective and a OneBusAway customer perspective, I think it would make the most sense to use the existing deployed apps and just add a Tampa location.  Otherwise, we're going to be forking each of the mobile projects for a Tampa-specific instance, and then having duplicate "OneBusAway Tampa" apps floating around in each of the app stores.

As far as I'm aware OBA supports this federated design, although I'm currently unclear as to where the knowledge of all the available OBA deployments is maintained.

Thanks,
Sean

Sean J. Barbeau, Ph.D.
Center for Urban Transportation Research
University of South Florida
bar...@cutr.usf.edu

[Brian Ferris]

I guess I'm still the owner of the iPhone app. In terms of making the
OneBusAway iPhone app work with any OneBusAway deployment, there is no
easy path. As I see it, the options are:

1) The current app is hard-coded to use http://api.onebusaway.org/,
which just provides info for Puget Sound as you're probably aware.
That said, OneBusAway was designed with a federated service model in
the back-end such that if you sent S. Morris Rose the url of your
federated transit data service, he could plug it into the service
registry and 60 seconds later every app using the current API would
magically have data for Tampa as well. Pretty cool! But there are
some issues with this approach. While this federated the transit data
bundle, all the UI components are still on UW's servers, which means
more load there and more administration work there. I'm not sure that
they ultimately want to be a global entry point for all OBA instances.

2) Have users of the iPhone app change their api server endpoint to
point to your API url. Doable through the app's settings panel, but
definitely a pain from a usability standpoint.

3) Fork the OBA iPhone app source and launch your own version. A fair
amount of work but then you control the experience.

4) Re-engineer the OBA iPhone app to use some global registry of
OneBusAway API endpoints to decide where it should get its data
automatically. There's a lot of work to make something like this
happen, including: 1) establishing some sort of global registry and 2)
modifying the iPhone app to use it. It's doable, but I'm not going to
lie that it's definitely fraught with some peril as well, so I just
bailed and went to Google where we are both the app and data backend
provider ; )

Either way, if anyone sees any value in pursuing an approach the
involves modifying the existing OBA iPhone app in some way, I'm
willing to do what I can to pass the reigns.

Brian


On Thu, Aug 16, 2012 at 9:06 PM, Paul Watts <paulc...@gmail.com> wrote:
> I'm the developer and maintainer of the Android app.
>
> Each OBA server is technically federated this way, but the apps (Android &
> iPhone, not sure about Windows Phone) are configured to access a single
> server instance. While you can edit the server URL, there's no user-friendly
> way of switching from one server to another based on location or agency, or
> "auto-configuring" the app based on location. And like you say, there's no
> knowledge of the OBA deployments worldwide.
>
> Beyond that, right now I provide the support for the app, so when people
> "email the developer" they email me. Although the new version of the Android
> app enables stop and trip problems to be reported through the API, a lot of
> people still email me directly. So there would have to be some way of
> sending support requests to different people depending on the region.
>
> This isn't to say that it's not possible to do, but there may be a broader
> conversation or larger work involved.
>
> Cheers,
> Paul

> --
> You received this message because you are subscribed to the Google Groups
> "onebusaway-developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/onebusaway-developers/-/TYvJJfIS1rQJ.
>
> To post to this group, send email to onebusaway...@googlegroups.com.
> To unsubscribe from this group, send email to
> onebusaway-devel...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/onebusaway-developers?hl=en.

[Barbeau, Sean]

Brian and Paul,
Thanks!

I think Brian puts forward a good enumeration of our options that could apply to all apps, not just the iPhone app.

Some comments:

1) #1 would be awesome, but I agree that having a centralized OBA server provider is probably ambitious given time/cost constraints that many are facing. Can anyone give an official Puget Sound response for this option?

2) I agree, I think this would be horrible from a usability perspective, and not really a realistic option

3) If we can't get other's help for option #4 (see below) in our project timeframe (public launch in January 2013), then our plan B would be #3, but we'd only have enough time to put out an Android app. I don't really like this option since I think it creates a lot of fragmentation issues both from a developer perspective (duplication of fixes/releases) and from a user perspective (multiple "OneBusAway" apps in the Market).

4) For our current project launching OBA in Tampa, assuming #1 isn't possible I think #4 that Brian outlined below (global OBA registry) would be preferable to us, although it does require work on behalf of the current OBA mobile app developers (or their proxies).

Individuals in our group have been working on an open-source OpenTripPlanner Android app (App - https://play.google.com/store/apps/details?id=edu.usf.cutr.opentripplanner.android, Code/Wiki - https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/wiki) that we're just soft-launching now, and we've had to consider the same global registry issue.

We settled on using a Google Docs spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0AgWy8ujaGosCdDhxTC04cUZNeHo0eGFBQTBpU2dxN0E&hl=en_US&authkey=CK-H__IP#gid=1), since it's easily editable/shareable, provides edit permissions, and can be read programmatically. On first execution the app hits the Google Doc and gets a list of OTP servers, their geographic bounds, their API entry points, and contact info for each server maintainer. This info is then cached locally to avoid hitting the Google Doc frequently, and occasionally refreshed. Here's the code that grabs the data from the spreadsheet:
https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/blob/master/src/edu/usf/cutr/opentripplanner/android/tasks/ServerSelector.java

We assume most issues are data issues, so the main feedback button in the app sends feedback to the server maintainer (known from the Google Docs spreadsheet). Latency doesn't seem too horrible so far. I assume that since Google is providing an official Google Docs API we won't have scalability issues (Brian? :) ). One issue that's become apparent with our OTP Android app is that some type of REST API version discovery is required, perhaps in a getServerMetadata() method or via a Google Docs spreadsheet entry, so one mobile app can deal with different versions of the REST API on multiple servers as OBA evolves.

We could try something similar to the above design with OBA apps, assuming no one wants to take on being a central OBA API provider as presented in option #1.

Thoughts?

Paul - would you be up for working on #4 for the OBA Android app? I don't know if you're up for potentially having to field more questions from a Tampa deployment, although assuming it's not an app issue you could always forward these to us or whoever HART decides will maintain the OneBusAway system.

Sean

[Sheldon A. Brown]

I have to admit #4 intrigues me as well. If we could get some
developers to help out with the work (I have zero Android/iPhone
experience -- and even less time sadly!) I could probably scrounge up
the hardware resources to make this happen. I'm assuming the registry
would do a simple re-direct to the actual OBA server and therefore
have minimal bandwidth and CPU requirements.

Sheldon

[Barbeau, Sean]

Sheldon,
I think what you're proposing is actually slightly different than the #4 I outlined. So, we'd have:
4a) Centralized OBA registry, where app retrieves list of OBA servers from registry once, and then app contacts individual onebusaway-api-webapp APIs servers directly for real-time info requests based on current location (This is how OTP Android currently works). For this design, each info request (after the initial registry retrieval) goes directly to the local onebusaway-api-webapp deployment.

4b) Centralized OBA registry and API entry point, where app sends real-time info request to centralized API which redirects (without app's knowledge) the request to the proper server onebusaway-api-webapp deployment (Sheldon's proposal). For this design, every info request would go through the centralized API entry point. This is different from #1 because each backend onebusaway-api-webapp is operated by the local OBA deployment, and the centralized API entry point simply does redirects (in #1, the onebusaway-api-webapp is centrally hosted).

Is 4b a fair description of what you have in mind?

[Sheldon A. Brown]

Ok, thanks for clearing that up Sean. Yes, I was thinking 4b) so
changes could be picked up more easily (like a OBA deployment in a new
region) but I suppose for that we could simply bump the version number
to force a new download and retrieval of the registry.

In that case I withdrawal the 4b) suggestion, 4a) is much simpler. So
if the Android already does this, we would simply need to implement it
for the iPhone app then? Who hosts and maintains the registry for the
Android then? Is that you Paul?

Sheldon

[Barbeau, Sean]

Sheldon,
The OpenTripPlanner (not OBA) Android app that we've (CUTR at USF) put together does this, but none of the OBA apps, including the OBA Android app, have been modified - they still points to the Puget Sound instance.

For the OpenTripPlanner Android app, we just created a Google Doc spreadsheet for the central registry:
https://docs.google.com/spreadsheet/ccc?key=0AgWy8ujaGosCdDhxTC04cUZNeHo0eGFBQTBpU2dxN0E&hl=en_US&authkey=CK-H__IP#gid=1

...which we own but can be edited by anyone we give permissions to. Like all Google Docs its hosted on Google infrastructure. I was thinking we could do something similar for OBA.

[Sheldon A. Brown]

Ok, that makes more sense. Thanks again for the clarification.

Sheldon

On Wed, Aug 29, 2012 at 3:20 PM, Barbeau, Sean <bar...@cutr.usf.edu> wrote:
> Sheldon,

[Paul Watts]

I think this route makes sense, and we could pattern it on the OTP directory. The contact email would go a ways toward preventing me from getting email about Tampa problems.

I don't think this would prevent UX complexity in all cases. For instance, the OBA Android app doesn't *require* the user to provide their location, and in case we don't have it we guess they are somewhere in the middle of Seattle for the purposes of stop/route search. First time users we'd either have to have them wait for their location, or select from the list of OBA instances. A default search center would either specified in the directory or computed based on the directory's bounding box. Not too big of a step, but it's one that doesn't exist today.

[Barbeau, Sean]

Paul,
In the OTP Android app, on first execution if the app can't get location info, we show the list of agencies (retrieved from the registry) to the user for them to pick from.

I think from a UX perspective, showing the user the list of agencies from the registry on location failure is actually very similar to the current OBA Android app design. When I first looked at your OBA Android app in Tampa, it gave a message about not being in Seattle and gave me an option to stay where I was or pick from a list of areas in Puget Sound. At the time I thought it was doing some kind of API server selection related to system federation (which prompted my initial email), but after your comments on this thread I now realize that this is just for map centering (not OBA server API selection). As you say it requires an amount of engineering and software changes to make the new design work, but I think some of the changes would be fairly transparent to current OBA app users and provide an overall similar UX.

I'm game to set up a OBA registry spreadsheet patterned after the OTP directory, if you're up for giving it a test run in your OBA Android app. All the OTP Android app code is under Apache 2.0, so feel free to borrow from that project, which should contain most of the code you'd need.

Sean

-----Original Message-----
From: onebusaway...@googlegroups.com [mailto:onebusaway...@googlegroups.com] On Behalf Of Paul Watts
Sent: Wednesday, August 29, 2012 4:16 PM
To: onebusaway...@googlegroups.com

[Paul Watts]

Yeah, that dialog box is shown when we send a request to the OBA instance here and it returns an Out Of Range error. It's one of the many tricks and "help" that I needed to add because of user confusion. Another one is that when the app first starts up, we automatically center the map around Seattle before even asking for your location. I added that because on first launch the map was automatically placed somewhere in Tulsa, OK, and people sent me email asking why the app thought they were in Oklahoma.

Once you have the registry set up, I can take a look at adding the necessary changes to the OBA app. Just let me know.

[Sean Barbeau]

Paul and all,
I've created a Google Docs spreadsheet that we can use as a centralized OBA server directory to help OBA mobile apps interface with more than one server instance:
https://docs.google.com/spreadsheet/ccc?key=0AsoU647elPShdHlYc0RJbkEtZnVvTW11WE5NbHNiMXc

I've taken a first shot at what info would make sense to have for each OBA instance, although this is still considered rough draft form and can be changed.  The first worksheet is a description of the document, and the second worksheet is what is actually accessed by the mobile app.  I'd like to have this serve as a centralized resource for both the OBA and SIRI APIs to try and support some convergence down the road, so I've added a few columns to help support this.  But, feel free to edit/comment if needed.

Also, for those I've added with edit permissions so far, please update your server row with the correct contact info, for someone that would receive feedback for mobile app users for your OBA deployment.

If anyone else wants to add their own OBA server to help test the mobile app in their area, please let us know.

Thanks,
Sean

>> To unsubscribe from this group, send email to onebusaway-developers+unsub...@googlegroups.com.

>> For more options, visit this group at http://groups.google.com/group/onebusaway-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "onebusaway-developers" group.
> To post to this group, send email to onebusaway...@googlegroups.com.

> To unsubscribe from this group, send email to onebusaway-developers+unsub...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/onebusaway-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "onebusaway-developers" group.
> To post to this group, send email to onebusaway...@googlegroups.com.

> To unsubscribe from this group, send email to onebusaway-developers+unsub...@googlegroups.com.