In September 2017 I made a post on Reddit that, unknown to me at the time, would cause me to have a massive project on my hands.
I’d been living in Edinburgh for nearly a year and the Transport for Edinburgh app didn’t support the Apple Watch meaning I had to take my phone out every-time I just wanted to check one bus. I had my “How hard can it be?” moment and decided I’d make one for myself. A quick Google search turned up the Transport for Edinburgh API and within a few days I had an API key.
I started simple, I knew if I did it in PHP I could return JSON data to the app and make my life miles easier as I’d done plenty of work with PHP. Fast forward a few evenings and my vision was coming to life
The iOS app was non-existent, I was simply running the app to the Watch via Xcode, I decided to show off my achievement on Reddit and what came next I didn’t expect. Comments came in telling me that it looked cool and that they’d happily download the app. Problem. To launch an app on the App Store back then an iOS counterpart was necessary. I’d never written an iOS app in my life and the very basic Watch app was my first venture into Swift.
Let the work begin then. After a lot of research, reading Stackoverflow posts, a mild amount of swearing, a fair few late nights and app crashes later and on October 3rd the below screenshot was taken before being released on the iOS app store two days later.
The first ever release of EdiTravel. It’s horrible, isn’t it? Also, you have worked out that image correctly, I knew so little code and hadn’t worked out the logic enough that you were limited to three stops – This actually stemmed from the Watch app code and logic, I originally designed the Watch app to show the three closest stops for speed and ease of use. A drastic rethink was needed, this wasn’t functional nor user friendly.
Two weeks later and I’d worked out a way to show more than one stop, having a scrolling wheel at the top of the screen allowing you to get the nearest ten stops – Hey, it was better than nothing, I was in full time training for a new job and had never coded in Swift before the project. It’s still not good enough though, right? Fine, let’s fast forward a month to 2.0.
Much better right!? You’ll see there’s a tap for More Stops, it’s not really changed much since then, it displayed a map with all the bus and Tram stops, you could select one and then view the screen above for that stop. Finally, a way to let users find a stop for themselves and not rely on some cruddy limit!
I took a trip to Princes Street one day using my app and discovered a really, really big issue with this that had been there since the first release. I was looking to find out when the next 26 was.
25 in 0 minutes 12 in 2 minutes 31 in 2 minutes
Hmm. 🤔 It’s in… er… oh. That’s not good. Back again once more to the drawing board. The Service Updates page had been using a UITableView that would load a dynamic number of rows depending on how much data was given to it. Now there was an idea. Commence 3.0
The first screenshots of 3.0 appear in early January, over two and a half months since our last one.
Initially the plan was to return to having multiple stops from the homescreen. As you can imagine, this caused complete confusion. A 12 to Seafield in 19, 20 and 21 minutes. Scratch that. Let’s go back to the idea from V2 where we had a stops map. Yep, that works, let’s make them expandable if you want more information, yes, that works! This version actually was the first test for a feature that only launched in the middle of this year – Interchanges. If you were at a location where multiple routes departed from, for example the Gyle Centre, you’d see all the buses leaving from the Gyle Centre and not just your nearest stop! So what happened to that feature? Why did it disappear for over a year? Changes. A lot of changes were made on the server code and database that broke this feature beyond repair at that point and the code had to be totally scratched.
February 2018 saw the testing of Train Stations and getting directions to a location via the Google Maps API. March 2018 and the design had taken a drastic change for the better but still hadn’t been released to the public
Live locations, bus speeds, a map with their location and an Estimated flag were all added in. March saw the design of the Stops page change to the directional circles as they are today and in May the app was launched to the app store with a gleaming new design, a UICollectionView along the top, the Search now out of Beta and renamed to ‘Get Directions’ and the ability to click on a departure, view its live route and departure time to each stop on its route
I was finally happy with the design. I was finally happy with the performance. I was finally happy with the way it worked and how simple it was to navigate. There was just one remaining niggle. Whenever a new route or bus stop was added, I had to push out a new software update, this information was stored in a file in the app build and so to update it meant needing to update the app, something which has now been fixed. Unfortunately our story goes a bit quiet at this point in terms of releases and UI changes, a bunch of bug fixes and performance improvements was all that really happened over the next year.
Behind the scenes however, the biggest changes since the app launch were happening, a brand new API was being built. Bermane. Bermane is the beating heart of EdiTravel, without it the app is nothing and empty. Bermane is where all the requests from the app go to, a single, centralised API that feeds out to, at present, five different API’s depending on what it is you are doing. Bermane queries the relevant API, parses the data into JSON and returns it to you, the user. The app then handles that response and deals with it as needs be. The great thing about this is none of the requests sent to the third-party API’s can be narrowed down to a single user as they all come from Bermane. All the calls to Google Maps of-course provide your current coordinates if that is where you choose to come from and where you are going to but beyond that good luck using that to identify a singular person in the world. All the PHP & Server headers are going to be that of Bermane.
Bermane is only just getting started, plans to build back up end points are well underway as it further geographical expansion beyond Edinburgh, London and the National Rail service. Bermane is full of scripts you will never know run, it notifies me via Slack if an issue occurs with a query, if a bad response is received, it sends me a message. Like this for example
Bermane - Third Party Issue Issue is Glasgow Queen Street Low Level Stop is GQL. Message was: An error has occurred.
All I know is that someone requested Glasgow Queen Street Low Level and that the API threw a hissy fit at it. All I need to do now is simply investigate why. If my API goes down, a different service pings me a message
Monitor is DOWN: EdiTravel API - Reason: Connection Timeout
So, as you can see, what started out as a fun little post on Reddit to show off what I had done, turned into quite the journey over the last two years. I’ve only just scratched the surface.