London Bus Pal

London Bus Pal v.4.4.5

Consolidated notes for 4.4.4 and 4.4.5:

β€’ Dynamic updates of bus route info and bus stop info – all of the latest bus route changes should hopefully now reflect in the app. 🚍

β€’ Route sequences will still load, even if no data is available from TfL (for example, on route 301). ▢️

β€’ Library updates to ensure the app is always as fast as possible and using your phone as efficiently as possible. πŸ“š

β€’ A few minor bug fixes. πŸ›

London Bus Pal

London Bus Pal v4.4.3

This is a fairly big update where the app will now dynamically be able to update route and bus stop information. All changes:

β€’ Dynamic updates of bus route info and bus stop info – all of the latest bus route changes should hopefully now reflect in the app. 🚍

β€’ Library updates to ensure the app is always as fast as possible and using your phone as efficiently as possible. πŸ“š

β€’ A few minor bug fixes. πŸ›

London Bus Pal

London Bus Pal v4.4.2

This was a fairly small update from a feature perspective. All frameworks and libraries were updated from 4.4.1 to ensure the app is as fast and bug-free as possible.

No new features were added.


GoDaddy hosting upgrade

My back-end API’s are all running on a GoDaddy hosting account. Until yesterday, I was using one of their shared servers and the response times started to bother me.

The median response time for a call was about 760ms, which is bad in API terms. What is worse for me, is the disparity – the quickest results tended to be around 500 to 600ms, but then other calls would take up to 4 or 5 seconds to complete. I have some heartbeat checks which does nothing other than return a response, so these should be super-quick, but they were not.

I had a look around the internet and determined that part of my problem was that I had chosen one of the slowest frameworks out there (Slim v3) to build my API. To prove whether it was the framework or my server, I did two things: created a blank heartbeat which doesn’t use the framework (basically just “echo ‘ok’;”) and then also setup node.js to check the speeds. The results pointed to the server, not the choice of framework. Apart from requests within a few seconds of each other, “cold” requests would always take around 500ms.

Upgrading to business

The decision was made to upgrade to business hosting. Surprisingly little information is available on GoDaddy’s upgrade process other than a bunch of complaints about it not working. I was really unsure about how seamless it would be as I didn’t want to be spending the whole day troubleshooting. I half-did a bunch of backups and paid over the money.

About 20 or 30 minutes later, things were done. A quick check of my API’s showed that everything was running and everything appeared to have just worked…or so I thought.

The main two issues which happened to me were that my MySQL database was really slow after the transfer and my WordPress blog stopped working. The blog was fairly trivial to fix as some permissions had changed during the move (not sure why only on for my WordPress installation as everything else remained intact).

One other side issue which happened is that I didn’t disconnect one of my terminal connections. It became clear after a few small tweaks that I was on the old server, not the new.

Slow database

To be fair, most of yesterday is now just a bit of blur, but I noticed the slow database and tried to fix it. In my own inexperience, I ended up locking a bunch of tables (by running optimize on it repeatedly, renaming a 2GB table etc) and things just completely died on me.

A thorough search of the internet helped to kill of most of the processes which had locked up my tables. Stubbornly, two tables remained and I couldn’t see what was locking it, but generally everything else was resolved and my database was running ok apart from the two tables I couldn’t access.

The last suggestion is to just restart the MySQL service, but I do not have the access to do this, so I decided to phone GoDaddy support. I know people complain about them a lot, but I’ve previously had to deal with them (after they killed my SSH access) and it was a painless affair.

Just shoot me instead

The call wait time was short enough and I was soon answered by someone American sounding who seemed eager to help. I explained that I have two tables which are locked which means I cannot access them. This first got interpreted as me forgetting my password; no, I can access the database, I have two tables which are locked.

The things which frustrated me on the call were:

  1. The technician clearly managed to access my database as he called out my table names (this becomes important in a minute).
  2. The technician did not understand what a table lock meant or how to tell that a table was locked. Due to his own lack of knowledge, he kept trying to check with me if what I was saying was really the case or if I’m just another idiot user. Due to this, he had to escalate to his supervisor.
  3. My total database size is around 2GB and I have 2GB of RAM available to me on the server. They repeatedly tried to insist that I simply had to buy more RAM as this was not sufficient due to my database size. I wasn’t having any of it and just kept on refusing.
  4. I asked the technician if they were able to just restart the MySQL on that server and he then said that his supervisor just did this. I checked this and he did not restart the service. He kept explaining to me that it was the MySQL that was restarted, not the server. Yes, I was looking at it and I could see that MySQL was running for 18 hours already.
  5. He then told me that his supervisor suggested that I upgrade to a package with more RAM as my database was inaccessible due to a lack of RAM. I can see the memory usage on my server and only around 300MB was used. He now claimed that he was unable to access my database at all, despite reading me back my own table names earlier. Only two tables were locked, everything else was fine (I checked this in several ways: directly on MySQL, through some API calls and then also checking my logs of external calls with perfectly good responses).

I had to just end the call after 44 minutes because this guy and his supervisor were completely useless. He was clearly out of his depth and instead of owning up to it, he started making up stuff like the fact that your entire database has to fit into the memory available on the server.

While I was on the call, I decided to just rework some of my database any way. The only annoying thing is that I’ve lost around 12 hours worth of data as the two tables in question, are used to store the collected data.

New day

I got up this morning and checked things out and the locks are gone and everything is going swimmingly again. Except for the fact that I redesigned half my database to work around the locked tables. It was a useful exercise any way since I was saving way too much data. (Yes, the one table in question makes up 1.7GB of the 2GB database).

I managed to do queries on it and it is all just fine. In fact…

Rechecking all of my heartbeats and health check, I noticed a few things:

  • The fastest responses times after I upgraded my package is now around 300ms – this compares to about 600ms for the fastest responses previously. This is a significant improvement.
  • The median response time is now down to around 350ms to 400ms down from 760ms. Given what I was doing on the server yesterday, I expect this to go down, as these measurements are all from the time while I was doing large numbers of database queries.
  • Checking this morning, some of my heartbeat responses are coming back below 100ms.
  • Most surprising is how fast the response is from Node.js – 22ms for a heartbeat – I might just migrate everything to use Node.js instead as this is the speed I am after.

Executive summary

Here is a summary on my feelings about GoDaddy:

  • Shared hosting is ok for absolute starters, but in hindsight, I should have just got started on business hosting.
  • GoDaddy is okay in terms of their offering and I feel much better about them after upgrading to the business package.
  • The company is being let down badly by their support staff. My call yesterday feels like a major run-in – it is also frustrating that both times I have called their support, they try to upsell to me. Support should be good at support, not sales.
London Bus Pal

It broke!

I have a post ready to tell you all about the new functionality that I launched for bus information, but during a migration to a better service today, it broke a bit. This doesn’t affect anything except for the additional bus information telling you which routes the buses run on historically. All the prediction stuff continues to be stable.

Once fixed, we will continue.

London Bus Pal

London Bus Pal v4.4.1

Version 4.4.x introduces more bus information into London Bus Pal.

Firstly, I tried to keep the design of all of the functionality to ensure that it is unobtrusive to users not interested in the information, but still easily enough to access for those who are.

Changes which can be observed in the main functionality:

  • When searching for a specific bus, type-ahead is now available and the app will make suggestions when you start typing either a bus registration number or a fleet number. The type ahead information will also indicate the fleet number and operator.
  • Rather than just displaying a “no information or not running” message which is unclear, if you search for a bus and it is not in service, the app will show you this message quite clearly now.

New bus information screens:

  • Once you have found a bus, whether in service or not, you can access the information screens. For in-service buses, an information icon is now displayed in the top right-hand corner and for out of service buses, a clear button is available to show you bus information.
  • On the bus information screen, there are three tabs available:
    • Assembly: this tab gives information about the fleet number and operator. If additional information is available about the bus assembly (such as engine, number of doors, chassis etc), it will be displayed here.
    • Usage: this tab will show you which routes the bus has been used on over the last 7 days. Please note that these are estimates based on information interpreted from TfL. These numbers should be used as indicative rather than specific.
    • Photos: the photos tab will show you publicly available photos from Flickr for this bus.

This functionality is in a pilot phase at the moment and subject to change. I have some rough plans on what I want to do with this functionality in future, but the purpose of this pilot is to see what the uptake is like and then maybe expand it out a bit further.

At the time of writing this, we have the information available for over 10,000 buses. Only around 750 of those have missing assembly details and I expect to start completing this over the coming months (of course, this will be an ongoing task).

Some plans for the future which I may look at are:

  • Bus lists of interest (rare workings, new buses, old buses and so on).
  • Personal bus lists – ability to put buses into your own personal groups; this can then later be used to see where all these buses are.
  • Route information – based on the information collected at the moment, it becomes possible to see how many buses are working any route at a point in time
  • Crowd-sourcing vehicle information – all fleet number and operator data is currently managed by myself; this is not sustainable in the long-run.
  • And many other ideas (some which I just don’t want to mention right now or others which might come from my users).

The roll out of this version is underway at the moment. I am expecting the Android roll out to be complete in a couple of days and iOS might take a little bit longer due to Apple’s requirements (and a technical issue which I experienced trying to create a build).

Development London Bus Pal

Flutter – the honeymoon is over

In January, I created a post where I sang Flutter’s praises over Android native. Three months later, does this still hold true?

First, let me give you a brief background. I launched my app back in 2013 on Android and the app has naturally grown from there. Late in 2018, I decided to do a full rewrite of the app in Flutter (with two things in mind: make the app more future-proof and ability to expand to iOS). I soft-launched on iOS in mid-December and went onto Android at the end of December. Despite a few hiccups (such as forgotten or missed features!), it generally went okay.

As of today, only about 6% of my Android user base is still on the old Android native app. I have around 2700 active users a day, so not massive, but it is a well-used app. Almost 4 months of constant hammering by users should give me a good flavour of what it is like to run a Flutter app in production.

What is still good?

Apple (almost for free): Being able to launch my app on Apple is definitely worthwhile. Revenue and use isn’t exactly where I want it to be, but I’m on the platform, so that is 100% further ahead than I was before Flutter. Apart from the nuances in terms of the iOS UX, I haven’t experienced any difference between the two platforms. It is great to do all of my development on Android and it just works on Apple.

Rapid developement: I have managed to add several new features to my app (including some fairly complex new features) which I would never have been able to achieve so quickly in Android native. And I also got this on Apple, almost for free. It may also be a sign of how well I architected my app, but this is also because Flutter and Dart allows this.

Community: The Flutter community is big and growing exponentially. Help is always at hand and I see new tutorials and walkthroughs coming out daily.

What’s not so good?

Dependency hell: I have found myself stuck in some dependency hell. I have one library which hasn’t updated and it causes a bad domino effect. I thought it was easier to manage in Dart, but appears not so. It took a fair amount of effort to unpick bit by bit and find the offending library.

Incomplete Google features: Further to the dependency hell I mention above, Google’s own features are still incomplete. Their maps are not usable yet, so I’ve had to use another package called “flutter_maps”, which is currently causing my dependency hell.

More incomplete Google features: AdMob is not really incomplete, rather just incompatible with the way that Flutter is meant to work. The library hasn’t been updated since February and I have to use awkward workarounds. I’ve had a really good explanation by Andrew Brogdon after I raised the issue on a Flutter Youtube video, but it is still frustrating that we are where we are with this. Nowhere.

Null handling: I’m not sure if it recently changed or if I just didn’t notice before, but I preferred the way that Dart handled nulls in that it won’t fatally blow up and just carry on. I had some really bad issues recently where it would just stop running parts of my code when I accidently tried doing something with a null. No errors, no nothing. It would literally just skip the rest of the function without throwing anything. It took hours to unpick and I would honestly have preferred the app to just crash instead.

Instability: I started using the stable channel of Flutter, so that I could keep up to the latest versions of Flutter, but without too much risk of things going wrong. Unfortunately, a fairly bad regression issue has appeared and it is causing some frustration (mostly just that Samsung decided to suspend my app).

Other weird bugs: This issue has appeared most than 4000 times in my app for more than 350 users. It has proven impossible for me to reproduce, but I can see it happening. I’ve had a number of other weird issues also occur. A more stable framework would not have these sorts of issues.

Do I still prefer Flutter?

Absolutely, I still prefer Flutter. I know that on balance, it appears from the above lists that I have more complaints about Flutter than praise, but this is not accurate. I simply recognise the current flaws with Flutter, but I still believe that the future is bright. Using Flutter, I believe that I can keep on expanding my app and giving my users all of the great experiences they are after.

Development London Bus Pal

Monetisation – the results

It’s been a while since I posted here, mostly because I’m busy behind the scenes with huge new features. It will take a while, so I can’t promise or really say anything yet.

Today I had to do a bit of housekeeping and had a look at how sales were doing. It’s has been about 2.5 months since I started my in-app purchases, so I can finally start to see how these are performing in comparison with ad revenue and sales revenue. The breakdown in percentage from 1 February until today is as follows:

  • Advertising revenue: 95.7%
  • In-app purchases: 3.2%
  • Mobile app sales: 1.1%

The thing which is not obvious here, is that there hasn’t been any obvious drop-off in advertising revenue, although, it would be very difficult to tell, since advertising revenue is a little bit volatile any way. Revenue is up by 3% vs the previous 28 days, but it can be down 5% next month for reasons beyond my control.

I see in-app purchases as an additional revenue source, rather than cannibalising my advertising revenue.

Another interesting metric I could look at, is how Android compares to iOS, however, my iOS take up is still fairly low, so it would be an unfair comparison. I simply don’t have enough data points to really say.

Feel free to get in contact if you want to know more – I’m always happy to talk to other developers and share any experiences I may have had. Back to work for me then…

London Bus Pal

London Bus Pal v4.3.1

The next release is here. I fixed a few small issues which I picked up on the journey planner (for example, if you asked for a route where it wasn’t possible to see it on a map, it would mostly just break!).

For the rest of it, I spent a lot of time testing small intricate details of the app to make sure it works well. Through this, I picked up a few small issues which I also fixed.

  • Journey Planner improvements and bug fixes. πŸ—ΊοΈ
  • Small bugs fixes including one where the routes were not properly sorting in the route list. πŸ›
  • Continuous updates to ensure the app is always as fast as possible and using your phone as efficiently as possible. πŸ“š
London Bus Pal

London Bus Pal v4.3.0

This version brings the beta version of the new journey planner to you and a few small fixes:

  • β€’ Journey Planner is here – it is very much in beta phase, but should be very usable! Let me know if you experience any issues. πŸ—ΊοΈ
  • Small improvements to ensure very efficient battery use. πŸ“š
  • Mostly minor bug fixes and one major one where routes were broken. πŸ›
  • Please don’t forget that you can support me by leaving a rating in the app store 🌟 or by removing ads for a small donation in the settings menu πŸ’·