E-mail Issues

Hi everyone,

My support e-mail account ( lakshbhasindeveloper@gmail.com ) has been behaving a bit strangely recently. I seem to have lost all e-mails from more than two weeks ago for some reason. I unfortunately hadn’t checked all of the support e-mails I had received from before then, so if you sent an e-mail and didn’t receive a reply, please re-email me! Sorry for any inconvenience; I’ll try to see if I can recover any e-mails.

For those of you who have been e-mailing me recently, I think I’ve been able to respond to you and help out. Thank you for your patience.

As a short update, my final school year will be coming to an end soon (within a month), so that will leave me more time for development and (at long last) an update. I’ve been keeping track of all of the suggestions I’ve received, so thank you to everyone who e-mailed in.

Till next time.

Countdown Maintenance

Periodically, TFL’s Countdown service goes down for maintenance. This is understandable since the service is still fairly new.

Usually, the Countdown system becomes unavailable on Sundays, so please be aware of that while using the app. In fact, today (February 5th), the system will be going down at 19:30, and will probably be inaccessible until Monday morning.

Please do not leave negative reviews about the app if TFL has taken down its essentials services for maintenance (e.g. the journey planner API or Countdown). You can check the status of Countdown here.

Note: If the app complains that TFL’s servers have been inaccessible for many days, please contact me. The format of the website might have changed, and that will affect how I pull data from it.

How to Get Alarms in the Background

Unfortunately, with iOS 5, Apple completely changed how “local notifications” are handled. Now, the user has to enable each app for local notifications if they want to receive alerts in the background. I only figured this out recently since it wasn’t documented very well, which is too bad.

You can follow the following steps to get your alarms working in the background:

  1. Go to the Settings app that comes with your iPhone
  2. Navigate to the “Notifications” section
  3. Find “London Bus Buddy” in your list of apps. Click on it to go to a more detailed page.
  4. Turn the “Notification Center” switch ON.
  5. Choose “Alerts” under the “Alert Style” section
  6. Turn the “Badge App Icon” switch ON.
  7. Turn the “Sounds” switch ON.

If you’re checking this on your iPhone, you should know that you can multitask by double-tapping on your home button (a few people aren’t aware of this, so I thought it would be worth pointing out). That way, you can look at these instructions while changing your settings.

Anyways, this should solve any problems you have with the alarm. Hopefully, this helps you out! If not, contact me with your questions.

Version 2.1 Waiting for Review!

Update January 30, 2012 at 22:00: V2.1 is out! Download it now!

With version 2.1, London Bus Buddy is poised to become the most comprehensive bus app on the App Store. And that too for free.

New features include:

  • Countdown (or “Next Bus”)
    • Powered by TFL, you can now see when your next bus is coming by entering a stop. You can check stops from a list of all 19,000 stops or look from a list of stops near you.
  • Online Journey Planning
    • Also powered by TFL, the online journey planner gives more accurate results than the offline one.
    • It lets you plan journeys from/to places of interest, addresses, postcodes, or stops.
    • It also lets you walk between stops, something the old journey planner couldn’t do. A walking map is available for each leg of your trip that involves walking (see the little map button).
  • Alarm fixes
    • Please follow the instructions on how to get the background mode working with alarms! An alert will show up the first time you try to set an alarm. Navigate to settings and follow the instructions closely. There should be a support post up soon about this.
    • Optimized the alarm a bit so it doesn’t try to find excessively accurate coordinates when you’re far away from your destination. The location manager becomes more accurate as you get closer to your stop.

Of course, these features do come with a performance overhead. Namely, startup time has gone up, since I now have to store stop codes for each stop at startup in order to use Countdown. As most users know, their first startup time is usually twice as long as any subsequent one; the reason behind this is that the first startup involves storing files in the documents directory and then reading them out (subsequent startups only need to do the latter).

Here is a list of average startup times based on a few devices I’ve tested on using a stopwatch:

  • iPhone 4S:
    • First startup time ≈ 13 seconds
    • Subsequent startups ≈ 8 seconds
  • iPhone 3GS:
    • First startup time ≈ 30 seconds
    • Subsequent startups ≈ 17 seconds
  • iPhone 3G: I haven’t tested on the 3G, but its hardware is becoming obsolete by this point.

Of course, it’s worth keeping in mind that the app is loading 20,000 stops into memory when it starts up!

As a final note, please inform me if these features behave oddly. Countdown and TFL’s journey planner may go down at times. They may change their formats too, which will completely mess up how I parse their HTML (as I mentioned before, there is no XML API for Countdown yet).

TFL (Actually Not) Off with API Data

UPDATE: I took another look at it, and it appears that TFL is giving its northing as 1,000,000-REAL_NORTHING (source), where REAL_NORTHING is the standard definition of northing based on the OSGB36 grid. I hadn’t noticed that beforehand. Maybe they do it to make all northings 6 digits?

The rest of the post I wrote on Tuesday is below:

I blogged yesterday about being unable to use the user’s current location in the Journey Planner API. I have managed to get around this issue by reverse-geocoding the user’s location (latitude/longitude) to an address, which works. The problem, however, wasn’t the reverse-geocoding (which is straightforward). The problem was that TFL did not recognize a lot of the addresses that were reverse-geocoded. After many hours of work, I built a small feature that clarifies the user’s inputs, in the same way that TFL does when a user gives an incomplete address. This feature works, but is dependent on TFL’s website staying the same (which will probably be the case), as it uses TFL’s “suggestions” to suggest more specific parameters.

For the moment, that has been taken care of. Unfortunately, I’ve encountered a new issue: eastings and northings. Eastings and northings are a form of coordinate system involving measured distances from a certain origin (in the east and north directions) along the Earth’s surface. It’s sort of like a grid map. For some reason, TFL prefers to use these over latitudes and longitudes, which is unfortunate for the rest of the world and for iPhones.

Having spent a long time understanding eastings and northings, as well as looking up ways to convert between the two programatically, I have managed to overcome that difficulty. I have a working piece of code that converts from northing/easting to latitude/longitude. However, it seems that TFL’s data for northings on its Journey Planner API is plain wrong. For example, for the postcode NW3 3HJ, TFL’s API gives the northing as 815532. However, using http://www.nearby.org.uk/coord.cgi?p=NW3+3HJ, I found the actual northing to be 184468. That’s a huge difference!

Somehow, the northings are correct in the rest of TFL’s feeds, just not in the journey planner API online. This is frustrating since I cannot accurately show a map between two points if I’m not given the right coordinates. If anybody could provide suggestions on how to correct this false northing, please let me know by commenting on this post. If someone from TFL (or a fellow developer) sees this, please let me know what I’m missing. Is the data supposed to be this far off?

Until next time (probably in 2012!)

Laksh Bhasin

Difficulties with Journey Planner and Countdown

UPDATE: In V2.1, I fixed the issues with using the user’s location. I simply used Google’s reverse geocoding service to generate postcodes or addresses. I was afraid of this since it is not very accurate, but it’ll have to do for now. Also, I’ve decided to go ahead and implement Countdown, in spite of the problems it might bring. The rest of my post from December 26 is below:

I’ve been playing around with the Journey Planner API recently and although it has its flaws (it gets confused between stops of the same name; a problem Bus Buddy had until recently), it does its job well. Effectively, it can allow for location-to-location planning. Bus Buddy currently only allows for stop-to-stop planning, since location-to-location planning is algorithmically very complex (due to the sheer number of footpaths possible). It would be a big step forward if the app could accomplish online planning through this API.

Unfortunately, I have reached a stumbling block. TFL’s online Journey Planner API is designed for websites with a front-end IP address. This is unfortunate for iPhone developers like me, who don’t have the servers to assist 100,000 users at a time. Luckily, I found a way around this, by using journeyplanner.tfl.gov.uk as the requester and asking for an XML-friendly output. This gives XML access to any computer with an Internet browser.

However, even with this, I have not managed to use latitudes and longitudes as inputs for the Journey Planner. This is obviously very important if a user wants to plan a journey from his/her location to another stop. For some reason, TFL says that this should work, and have posted an example link in their documentation PDF. Unfortunately, that link also does not work. The API gets confused when it is given a set of latitudes and longitudes. As long as this issue remains, it will be difficult to fully utilize the API’s power to help mobile users plan a journey from their current location (understandably a useful future). I would probably receive a lot of criticism for putting out a half-finished journey planner (one that lacks this capability), so I will have to wait.

Also, some Londoners may have noticed new apps on the App Store that tell you when your next bus is coming (using a feature called “Countdown”). They all make use of the following website: http://m.countdown.tfl.gov.uk/. However, there is currently no API available to access the data from “Countdown.” Thus, I feel very wary about just accessing the website and downloading what it outputs, which is probably what most apps are doing. What if the output format changes all of a sudden? That could leave thousands of Londoners stranded at night. It is best to wait for an official API from my point of view.

To resolve my problems with the journey planner and Countdown, I have tried to contact TFL through many channels. Since it is currently the holiday season, their response delay is understandable. If issues persist, I will try to reach out to senior TFL employees. It may take months for me to receive a useful response, gain access to the APIs, and implement everything. Robotics starts soon at school as well, which will be both exciting and time-consuming! For my users, that means any future changes may have to wait even longer.

I’m really sorry about this as always, and have seen the impact of a few sour reviews on my downloads. This doesn’t financially affect me much since all the ad revenue goes to charity, but I am disappointed that I don’t have the time to help as much as I should.

Happy holidays and thanks for tuning in!


V2.0 Waiting for Review

UPDATE AUGUST 31: Update 2.0 has been released!

Version 2.0 is waiting for review (i.e. Apple will soon have a look at it). There are still some changes I’d like to make in the future, but they may have to be put on hold until life becomes less busy.

As an important note: stop names have changed in a few cases in the app. When you’re planning a journey, take these into account when choosing the right stop. A good indicator is seeing which routes go through that stop or looking the stop up under the “Display” tab.

As an example, a journey from Swiss Cottage Stn / Avenue Road to some stop might show a different route from a journey starting at Swiss Cottage Station. These stops are right next to each other, but are recorded as having different routes running through them.

Users are asked to pay attention as TFL continues to change stop names and improve its database.