There’s nothing that quite matches this community’s interests like open software in the service of transit. In a recent blog post, OneBusAway for Apple iOS maintainer Aaron Brethorst says that a complete rewrite of the software is ready for beta testing.
For most of you, know that beta testing will expose you to some bugs but help make the final product better.
For those of you who spend your lives gluing bits of software together, know that this new version is built on the ‘OBAKit’ library, which makes it much easier to build other real-time transit applications. There are certainly lots of rural transit agencies that don’t have the resources to deploy things of this nature, and this makes it easier for developers to apply their skills to help those in need.
How much different is it to write the code for iOS versus Android? I’m just curious, as I’ve never written any code for phones.
They’re pretty different. For starters, they’re written in different languages: Swift for iOS and Java for Android). Second, iOS and Android have wildly different notions about how apps should be structured, and how they should work.
But, lots of software developers have experience building both iOS and Android apps. I’d say that it’s easier to learn how to build an iOS or Android app if you already know the other platform than it is to learn your first programming language and platform.
OK, interesting. Not sure why it isn’t just written in Java for both, but I guess Apple does things differently (going back to the Objective-C days). So this means that the programmer has to write a lot more of the functionality of the app in each language — not just the stuff that is specific to the platform UI. I suppose in this case most of the code sits on the server, and is accessed by the same API, but it still means a lot of porting if you wanted the same features on both platforms. (Correct me if I’m wrong with that assessment).
It’s more the case that Android insists on Java while iOs is more flexible. There are frameworks like Cordova that allow you to target both from one codebase. The ultimate problem is that mobile is fragmented like PCs were in the 70s: every manufacturer has a different incompatible platform. There’s no IBM PC-like interchangeability with mobile, or Linux-like open-source OS that runs on all of them. And I’ve heard that even if there was a universal open-source OS available for phones, the cellular companies wouldn’t allow it to connect to their networks, so that would defeat the primary purpose of having a phone.
Mike, Android is an open source platform. That’s why Fire TV (and the old Fire Phone) or Microsoft’s new Duo can run Android apps without any modification to the app. There’s also Ubuntu for mobile but its not nearly as popular.
It’s more the case that Android insists on Java while iOs is more flexible
Java was designed from the beginning to be multi-platform. The code doesn’t actually compile to native code. It “compiles” to a Java “Byte Code”, which is just code that can be used on any “Java Virtual Machine” (or JVM). The virtual machine concept goes way back (to IBM mainframe days) and was designed with interoperability in mind. The Java byte code can work on any machine that has a JVM. This includes Windows, Macs, Unix, and probably a lot more.
I find it weird that iPhones don’t have a JVM, but I think the goal was to squeeze out the competition. There was a time when iPhones dominated the app world. Now, not so much. They still have a big enough share though to make them difficult to ignore, especially in the U. S.
That was related to a project I was indirectly related to, that wanted to build a Python mobile app. There was a way to do it on iOs but it hit a roadblock on Android due to its Java limitations. They ended up implementing it as Javascript.
According to this, you can compile Java code to Android, but it doesn’t exactly result in Java byte code (https://en.wikipedia.org/wiki/Comparison_of_Java_and_Android_API). It looks like it would require extra work for a build engineer, but an ordinary programmer could code “regular Java” with only a few differences (e. g. System.out does nothing). It is kind of like the old JVME in that respect (https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition). The biggest differences occur in the UI, which makes sense. It would make development relatively easy (again, after the build engineer did the tough work) by having different code (using different libraries) for each device, but sharing much of the code in common. That is, it would enable that if it was easy to compile Java code for iOS.
For Python, it looks like Kivy would work well (https://en.wikipedia.org/wiki/Kivy_(framework)). It is quite possible that wasn’t around (or wasn’t well established) when you worked on that project, Mike. I’m guessing things change fast in that world. All the more reason to have a good build engineer on your team (https://gradle.com/blog/build-engineer-challenges/). A good one would know all of this, and talk about all the different advantages and disadvantages of each approach.
Historically, the algorithm OneBusAway seems to have used to generate arrival times has always been very naive. It seems to work by taking the last known position of the bus and assuming that future progress matches exactly the paper schedule, with the assumption that the bus travels at a constant speed between timepoints. The “constant speed” assumption tends to result in the app consistently over-estimating travel times when the bus is on the freeway and under-estimating travel times when the bus is doing low-speed maneuvers, like getting into or out of a transit center.
Another common source of error is that the app often confuses the current actual position of the bus with the stop the bus most recently passed. For local routes, this doesn’t make much difference, but for express routes, it can make a very big difference. For instance, OneBusAway often considers the eastbound 545 to be sitting at the Olive/Boren stop while the bus is actually on I-5 or the 520 bridge and, only when the bus actually passes the next stop (Evergreen Point), does the position on the app update.
To compensate for all this, I use various kludges. I usually ignore the app’s estimated arrival times and instead just look at the position of the bus and generate estimates myself. For freeway-running buses, I also try to start following the route before the bus hits the freeway so I can infer when the bus actually reached its last stop before the freeway. To estimate progress on the freeway itself, I just switch over to Google Maps and look at the traffic report.
Ideally, all of these things I’m doing by hand can/should be done by the app itself so that the arrival-time predictions are more trustworthy. A simple automated mechanism to track accuracy of the predictions over time and make tweaks to the prediction strategy could accomplish this.
Ideally, Metro itself should be using actual travel-time data to automatically update its schedules, rather than depending on overworked humans to notice when a bus is consistently early or late at the same points along the route every single trip. For example, COVID has drastically reduced traffic congestion on may bus routes, but as far as I can tell, the schedule padding has not decreased. An automated mechanism to adjust scheduled running times to match actual running times would allow Metro to run the same schedules with fewer buses and save money.
In 2001-2002, Metro was using real time GPS to track its busses and report their approximate arrival times. The system was pretty awful, only marginally better than OBA in providing accurate data.
Currently I find Google Maps to be the best of all of them, but I have heard others find OBA to be better.
I am asking this question from a frequent rider point of view not a code writer.
Will the new improvements on make the snow schedule busses easier to see? Now please excuse me, I did not ride during our most recent storm. I have been distancing. But I was on the bus and light rail several times during the 2019 storm. None of the apps seem to be accurate. I used a text program to tell me if any bus would show up. I walked to more frquently used stops and found people getting off work. One woman was crying. She did not know of the text alert system. I helped about 3 or 4 people set it up on Roosevelt and Northgate Way going towards the transit center in a snow storm. Apperantly their bus commute was already 1.5 hours from QFC to their homes before the snow. Pretty effed up. It took them 3 hours to get home. But that was not the issue. They could not tell if any bus was showing up on that street. And I knew a bus was coming, but it did not show any bus tracking over any GPS. According to 2 apps, it showed our bus coming over Northgate Way, but it actually came via 125th and down Roosevelt. Thae app did not show any of that. That meant it missed about 13 stops, but showed it being ON TIIME at all those stops it skipped.
I know that having busses show up exactly on time is pretty nice and seeing it on the phone is pretty fun too. And the apps that show it are pretty cool also. But when it was needed to be even (kinda half way semi accurate), It is not.
If this IOS program can fix this, I’ll get a new phone, tomorrow at any price. But if it is just a fancier program, with better graphics that I already know how to use and estimate the arrrival tine then I am not really interested.
Plus I am aware that if all transit information is made public, and all apps use it, so my question above may be worthless. But I hope, bloggers can give me some useful info to spread, at least to my transit using acquaintances.
My apologies for the wrong number of stops missed in my comment. It was 6. But still feel it is an important view. Sorry.
I love many things about OBA. I’m not sure how much better it can be at disseminating arrival information as real-time bus positioning seems to be the least reliable part.
At some point, a more interactive or two-way system should be available — but that will require major changes. For example, it sure would be nice if drivers of buses after 8 pm knew to wait for riders from major transfer points like Link stations. I can see something like a reservation that expires after 4 or 5 minutes and drivers would only wait a minute or two unless the bus was way early. It’s very frustrating to watch a bus pass you by because the walk signal won’t change or you can’t catch the eye of a driver at 11:30 pm.
A simple arrival slow-flashing light posted on top of a bus shelter at a major transfer stop would seem to be all that’s needed. The light goes off when the bus pulls away or after 4-5 minutes — whichever comes first.
Hopefully there will be an Android version of the OneBusAway app in the future…
There is, it just doesn’t have this update (or it has a different update). As I was eluding to above, I’m not sure why the development paths have split (except maybe it is a very small team, and people work on what they want to work on).
Why is why that drivers loved driving the dual mode Breda’s and some didn’t like driving the breadas because they complained because of back problems and foot problems and loved seeing a MAN 60 footer! So what’s the difference between different bus companies 🙄