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.
There are two inaccuracies in my title: firstly, Flutter is Android native, but we will be talking about developing Android native apps using Java versus Flutter app in Dart; and secondly, one isn’t really better than the other, but in my circumstances, one approach was definitely better than the other.
A brief introduction
The important information about my background which you should know:
I published an app in 2013 and I think it has been moderately successful. Not a Candy Crush, but it hasn’t died yet and people are using it daily.
I rebuilt this app and it has feature parity with the old one – it does exactly the same thing the old one did (I know, because I’ve had users point out to me where I have forgotten how the “old” app worked). From their point of view, it just seems like I updated the look and feel a bit.
Development is a hobby rather than a job (although I work with development teams, but not as a developer). Java and Dart were both self-taught and never used in a professional environment for me. (I learned C++ at uni and have a long history with languages like BASIC, Pascal, C and Visual Basic).
So my qualification to make these statements come from building the same production app in both Java and Dart with limited experience. Let’s dive right into some comparisons:
Java vs Dart
Both languages are very similar and I feel fairly comfortable using both. I was a bit hesitant with learning Dart, but it felt completely natural after being quite used to Java (I’ve dabbled a bit with Python and PHP and I found it much easier to quickly adapt into Dart comparatively).
Doing asynchronous work in Java is a bit more of a hassle compared to Dart. Dart’s syntax makes it very easy (except that in Flutter, you build methods cannot use the asynchronous syntax).
I also got into Dart and Flutter when Dart 2.0 was out, so the language was cleaned up for Flutter, so no annoying “new”‘s everywhere.
And then, Dart either seems to handle nulls a bit better or I have burned myself enough in Java to be handling it better myself. But it feels like Flutter protects you a little bit as you don’t have a mini-explosion every time you forget to handle a null.
The only negative point for Dart, but this more a Flutter thing, is that you end up with lots of brackets everywhere – more than usual. And maybe quite a lot of commas too.
As a language, I prefer Dart as it is a bit more to the point and feels like it is made for what I want to do.
Material design
I spent a good number of weekends implementing material design at the start of 2015. It had only been announced in June the previous year, so it was still relatively new and there wasn’t too much help available in terms of libraries. I remember having to style everything by hand, measuring margins and constantly referencing the material design specs.
Flutter basically gives you material design out of the box. I actually hadn’t realised how “not material design” my app was until I rebuilt it using Flutter. (Of course, I don’t know if you now get some better help in Android native, but it felt really good that the design system I wanted to use was immediately available to me rather than having to sit and figure out margins, padding, shadows, rounding and so on, on my own.)
Getting a material design look in Flutter was effortless compared to doing the same thing in Java.
XML vs code
When you work with Java, a lot of layouts, strings and random values will reside in XML instead of code. This should make scaling with large teams easier as there is a separation of concerns and a designer can pick up the XML files and edit them without having to know code. As nice as this is, I don’t like it for a smaller project. And then, you end up having to reference the XML in code any way, and you always wonder why you can’t just do it all in code (maybe you can?). It felt like things got messy having to work in XML and then use LayoutInflater to build the things I just build in XML to start with.
On the flip-side, I miss one thing: Strings.xml. This allows for easy translation and just having everything nicely in one place. I have seen a way to do it in Flutter, but it didn’t immediately make sense to me. I never actually translated my app, so it’s probably over-engineered, but equally don’t feel too happy with the strings just sitting all over the place. (I should probably at least just create a static class to put all my strings in…but that’s for another day).
Because I definitely prefer being able to have complete control over my layouts, I prefer the Flutter approach where it is all in code. The XML approach would have been more useful for WYSIWYG editors, but they never worked too well for me and I didn’t feel completely in control. And the fact that it would try and display even the smallest layout in the editor. It was just odd.
Hot reload
The lack of WYSIWYG layout editor in Flutter is made up for by having hot reload. It can do some strange things at times (or in my app if I change things which are done right at start-up, hot reload doesn’t work), but it is great for making layout changes and being able to see it immediately. This is not available when using Java and slows down the process a bit.
Fragments vs widgets
I’m calling out fragments here, but it really should be, “Widgets vs the Android kitchen sink”. Everything in Flutter is a widget – this makes it very predictable on how it will work and easy to move around and plug in somewhere else. It took me minutes to take my existing layout for phones and adapt it for tablets where I wanted side-by-side views of two different screens.
Adapting my app for tablets in Java was a complete nightmare. Again, things might have changed, but I had to use fragments. I had two fragments and it just felt awkward trying to deal with it differently between tablets and mobiles. Because everything is a widget in Flutter – this sort of thing is quite straight-forward to achieve.
This is the layout I tried to achieve on tablets with content on the left and a map on the right
It’s worth pointing out, that even after all of that work with fragments, the app stopped working on tablets at some point and I just never had the courage to want to try and fix it again. Until Flutter came along…
Flavours
I have three different flavours in both my set ups. The Flutter one would not have been as straight-forward to set up since I had to go and muck around in the Android code – but since I have done it before, it was pretty much copy and paste. If I was new to this, I can imagine it would have been pretty difficult to figure out as you have to change files you don’t normally deal with.
One of my flavours has a different applicationId which I can use in Flutter code to distinguish, but two of them don’t and I cannot easily and without some workarounds detect in code which flavour is which.
I would prefer it if there was an easier way to deal with flavours in Flutter, but it barely handles it at the moment.
Dependencies
For both Java and Dart, dependency management is quite straight-forward. Dart feels a little bit more light-weight and straight-forward – I have many more dependencies in my Java app for Android support libraries which I didn’t need in Dart (due to Flutter).
Due to not having to worry about the support libraries I prefer Flutter for dependency management, but I’m sure this might be why the APK’s are so big.
APK sizes
This was almost a deal breaker for me, and even though the production APK’s are quite a bit smaller than the debug ones, this is Flutter’s worst point for me by far.
The Java APK is 4.07MB and the Flutter one is 10.03MB.
Due to the large initial size of the Flutter APK (I started somewhere around 18MB), I had to be aggressive in terms of making images as small as possible, reducing the size of my static data database and be very careful with dependencies. Both APK’s are Proguarded/Minified. My Flutter APK is only that small due to a dedicated effort to try and get it as small as possible. If I put the same effort into the Java one, I’m sure I would get it to be a bit smaller.
Android Studio vs VS Code
I moved from Eclipse to Android Studio and liked it in the beginning, but it was quite heavy on the processing side. I’ve killed a laptop battery due to it and I’m fairly sure the heat Android Studio has generated in the past might have fried a few laptop components too. I now use a desktop, but Android Studio is still quite heavy-weight and it just feels too clunky.
Even though I use Android Studio from time to time due to wanting to use the layout inspector as an example, I prefer spending my time in VS code.
Maturity
We have to touch on maturity here. Because Java Android has been around for years, you have access to tons of libraries and many resources. Getting stuck shouldn’t happen for long and you’ll be helped quite quickly. All the libraries have had years to stabilise and shouldn’t give you problems (well, you’d think so at least).
On the other hand, Flutter is still fairly new. I’ve had specific issues with libraries crashing my app because despite claiming to be version 1.1+, version 1 just meant it was their first publication. I’ve also had issues with libraries being incomplete. It’s worth pointing out that in both cases, I found suitable solid alternatives, so I haven’t been left with nothing.
This is probably set to get worse for now as many libraries are still experimental or beta. As these libraries are upgraded, I’m probably going to have to rewrite large chunks of code. (Although, my Java code is probably in that situation now as I haven’t upgraded libraries for about 6 months).
Wearables
Neither app had a wearable version, but it was an option for me when I was working in Java. Flutter doesn’t support this yet, so if I had any plans to also have a wearable version, it isn’t currently possible.
I’ll mention it here only because it is also in the category of I don’t have it, but had the option and lost it – widgets. I believe that Flutter doesn’t yet support home screen widgets on Android, but this I cannot confirm.
Flutter’s best feature for me
So I’ve saved the best for last – Flutter gives me something I’ve wanted since 2013, but due to many issues, like time constraints, willingness and ability to learn, having to work on a Mac, I just never could build an iOS app. Flutter gave me this for free. Of course I had to set up a Mac in order to test it, but it just worked – pretty much out of the box with no code changes whatsoever (working is of course different to being usable – I’ve done a post on Flutter on iOS for Android developers about my lessons I’ve learned).
I’ve broken into a whole new market due to Flutter, so this is for me, the main reason that Flutter is better than using Java Android.
Summary
This is all my opinion based on my own use case, but hopefully you can find some useful bits in here if you are deciding whether to use Java for Android for Dart for Flutter. The checkboxes simply point out which is better at supporting the feature than the other – in most cases features are supported in both.
Feature
Android
Dart & Flutter
Language – both languages are very similar, but Dart makes asynchronous development a bit easier and handles nulls better
Java
Dart
Material design – I had to hand-craft material design when I worked in Java, it came out of the box with Flutter
✅
XML strings – having Strings all in one place and an easy way to translate them was useful in Java. It’s possible in Dart and Flutter, but not without some hand-crafting.
✅
XML layouts – I disliked having to manage my layouts separately in Java and prefer the control I get in Flutter.
✅
Hot reload – only available in Flutter and turns your emulator into an almost WYSIWYG layout editor
✅
Widgets – everything being a widget in Flutter simplifies things a lot and makes it clear and predictable how they will interact with other widgets
✅
Flavours – this isn’t completely baked in, but supported by Flutter. I would prefer the ability to know programatticaly which flavour is being used and not have to fiddle around the Android source to set it up.
✅
Dependency management – pubspec.yaml feels more lightweight than a build.gradle and I don’t have to worry about all the support libraries just to build an app
✅
APK size – based on what you get for it, I feel that the Flutter APK is probably still too bloated
4.07MB
10.03MB
Android Studio and VS code. I prefer VS code as it is more light-weight and doesn’t try and cook my processor, although I switch to Android Studio from time-to-time for things like the layout inspector.
✅
Maturity – it would be unfair to say that Flutter is incomplete, because it is possible to build a production-ready app with it, but some things will be a bit harder to do due to it still being relatively new.
✅
Wearables – not supported in Flutter yet, but I expect it will happen if wearables are still popular in a couple of year’s time.
✅
Ability to build for iOS – this is the winning point for me about Flutter. I no longer have to fear that I’ll have to learn Swift or Objective-C. It makes me sleep better at night.
I was reading a post on Reddit which had some interesting statistics about Android OS versions and the speed (or tardiness really) of updating to the latest OS versions.
Of course the post is focused on individual phones, so it becomes difficult to get a sense of how many people are using the latest version of Android. So I decided, as I do, to check my own app for how version distributions have changed over the last four months. Here is a side by side comparison of the charts (the sample sizes are around 2500 users in both sets):
Of course – this doesn’t tell the full story either. It isn’t clear whether the shifts are due to software upgrades on the same phones, or whether users have just got new phones – or whether they are completely different users, but it paints a picture.
Something else to keep in mind when looking at this, is that my app is geographically biased towards London. So it isn’t representative of Android OS distribution across the world, or even Europe, it is very centred on London.
Here is the same data represented as a bar chart – just for a different perspective:
I first published my app in September 2013. I am still iterating on the app, with 4.0.9 being my latest published version and 4.1.0 under development. With the benefit of time, things have become clearer and there are some things I wish I knew upfront (these are just a collection of thoughts, which I think an Android publisher should think about). (I only first published to the Apple App Store in December 2018, so have no real experience yet – this post is all about Android).
This is just a random list of thoughts on my experiences over the years – things I have done or some times things I wish I had done.
Old versions
In 2019, I’m still seeing app versions being used out in production which became obsolete in 2015 (2.1.1 was used on 6 January 2019 when 2.1.2 was published on 13 January 2015). It is really difficult to control app versions once they are published. Either have a strategy to force users to upgrade, or make sure that your app will stand the test of time. With the latter, I mean, don’t put in layers in your app which will break in 5 years time when you no longer maintain that service (for example, you deprecate a Firebase datastore or move to a different cloud provider). Version 1.0.0 of my app still works exactly the same as it did on the day I built it. And whilst that is pretty good, consider whether you would want to say that 5 years later when the whole world has moved on.
It is simply impossible to easily force upgrades, unless you force it in your app. While many upgrade fairly quickly, many don’t. It’s been over two weeks since I’ve launched version 4 of my app – yesterday’s stats show that at least 27.5% of my users still haven’t upgraded.
This might seem insignificant, but it becomes a big problem when you discover a breaking bug for example. Think carefully whenever you publish a new version of your app – it will be out there forever. I have done some “panic publishing” where it is just one fix on top of another to the point where the app is very stable. But, while the panic was underway, people installed the “bad versions” and never upgraded again.
Multiple app stores
This is probably easier now than it was in 2014. Back then, there were some viable alternatives to the Google Play store (to the point actually where a significant amount of my initial traffic was actually from a different app store). At some point, my app was on 6 or 7 different app stores. This might be slightly contributing to the number of older version of my app still circulating – over the years, app stores have changed named, sold on their inventories, closed down and I’ve found my app on app stores where I’m fairly sure I never published. Think very, very carefully if you are considering publishing to alternative app stores – is it really worth the effort? (At the time I thought it was, but it was a complete waste of time – if I were to do it again today, my Android app would only go on one, maybe two app stores).
Monetisation strategy
This is another one which has changed over the years. When I got started, most publishers who couldn’t sell a subscription service would monetise by having a free app and a “pro” version of the app. Thankfully, the problems introduced by having two app versions were not compounded by doing this on multiple app stores. I only followed the two app approach on the Google Play store.
I have had many people download the free version and I have good number of daily users. For my “pro” version (which is just a paid for version with the ads removed), the traffic is neglible. To the point where it would make absolutely no difference to my bottom line if I unpublished that app tomorrow. The problem with the “pro” version I have, is that people paid for the app out of loyalty, so I feel obligated to return that loyalty.
Having a free and paid for version also raises the question – do I launch new features to my paid customers first or to my free users? Usually, I end up using my free users as the guinea pigs to basically prove the app is stable first before rolling it out to my paying users, but is that really what they paid for?
Lately, I’ve been thinking more about paid for versions and how to monetise them better. I have come to the conclusion that in the app market, apps which are constantly being updated and improved, should not be sold, but subscribed to. A user who paid 0.79p in 2015 (to whom I am very thankful) are getting a really good deal 5 years later as they have a much better app and have paid very little for it. As a publisher, it feels slightly skewed that I could compete on price with another app, but it’s all about what we are delivering at that point with no promise of what is in the future. I want to look at moving to a subscription model – you sign up and pay for what you get at that point and if you are happy with what you get in the future, you can continue paying, otherwise you stop.
Crash reporting
Things really changed for me when I put in some crash reporting in my app. You can test all you want, but there are always the really strange devices out there or strange combinations of hardware and software. My app only started picking up when I put some crash reporting in place and I could see if users were experiencing issues.
User experience
There are many apps out there which simply seem like containers for ads and some incidental content. This is not sustainable in any way shape or form. I have seen these apps come and go – they might have made more income in the week or two they were on the app store than I did, but 5 years later, my app is still around and getting great reviews. Don’t fall into the trap. Design an app with really good user experience in mind and then add in the monetisation you want, but don’t let it distract from good user experience. You might not get the high RPM’s from having inobtrusive ads, but you will get loads more traffic if you have a good app, which will pay off in the long run.
Your users do not download your app for the ads – it is not a feature for them, don’t let your app just become a billboard.
Keep things up to date
I went through times where I neglected my app for long periods of time. Making even the smallest change would be such a headache because I would have to upgrade all my libraries and then everything would break. If I just kept up to date and upgraded as I went, it would not be so daunting. When GDPR came around, I had to spend a significant amount of time trying to upgrade libraries and see what would break where. I am going to try to at least do that this year!
Listen to your users
Read every single word your users write to you. Users who take the time to write feedback, whether good or bad are helping you out. By listening to their feedback, you could be making the experience better for others in future. One user’s feedback acted on could mean 500 fewer uninstalls next month. Don’t ignore your users – you created the app for them after all.
May 2018 has been a really long and frustrating month in terms of updates to London Bus Pal. I would never have imagined just how much effort I would need to put into my app when I thought that I was free from any GDPR requirements.
I was on holiday and I saw some emails from Google and then also saw an article on The Register (https://www.theregister.co.uk/2018/05/10/google_gdpr_consent_klaxon/) which pretty much made it clear that I would have to do something. Upon return from my holiday, I immediately got on the internet and started reading all kinds of horror stories of people building entire consent databases and having to come up with really intricate ways to obtain and store consent. It felt like it was overkill and like it was completely against what I thought the spririt of GDPR was (less data, not more!). The panic started to set in as it seemed like this was a much bigger beast than I had anticipated and I started studying the regulation itself, rather than just reading blogs based on third-hand information. At least it turned out that I was right and that GDPR was meant to limit and reduce the amount of data we process, not process more data because of it.
After reading the regulation and no consent SDK being available yet from Google, I decided to build my own pages to manage this in the app. I settled on the following requirements:
Location permission – I already had to obtain these due to Android requirements and my app works fine without it. I decided to still build a screen to tell users about it and that they can revoke permissions if they want.
Ads – this was the main reason I built this, because it felt like Google was willing to stop us from using AdMob if we did not do something to gain consent. To be honest, I understand where they are coming from as they would be held responsible if they didn’t insist on us doing something. The consent isn’t to consent to ads or not, it was basically to use personal data to personalise ads or not. More on this later!
Crash reporting – as I didn’t consider capturing crash reports as a legitimate enough reason to keep my app going, I decided that I had to gain consent to store crash reports.
There is very little else that I do with data – I just take a location or bus route or bus stop request, get the relevant data and show it back to the user. I really have no interest in obtaining data I don’t need.
So I built my GDPR consent screens and I ran into a bit of trouble. My crash reporting and analytics tools are bundled together really. If I switch one off, I have to switch both off. I then decided to change the wording for crash reporting to something along the lines of tracking expected and unexpected behaviour (the former being analytics and the latter being crash reporting). I had some issues with the analytics, so I then had to go and find each use and check if I could use it or not before posting something as I didn’t use standard methods everywhere.
Due to the GDPR consent screens being one of the first screens and having to test with different permutations, I decided to just do some manual testing instead of expanding (and fixing) my automated tests.
I changed my AdMob settings to select my own technology providers and I published version 3.2.6 on Wednesday morning, two days before GDPR was due. Things sort of looked normal, my ad revenue seemed unaffected and even though I could see a bit of a drop in users reported through my analytics tool, the users who still opted to keep crash reporting and analytics on, still had a 100% stability rate.
Over the next two days I noticed some 1-star reviews, two of them were removed before I could get to them and it just looked like someone trolling the updated GDPR screens. But there were some legitimate ones too and I started to investigate. I noticed on the Play Store that my app stability had decreased since the GDPR release and I found some specific pieces of code I missed! If someone had chosen to turn off analytics, I still had some instances where I was trying to track events and it would crash the app. I asked the users to contact me to give me more detail to help my investigation.
Rushing to get a fix out, I made sure I found all of the uses, fixed it and I released version 3.2.7 on Saturday morning. I received another 1-star review saying that the app was broken – this review was left for version 3.2.7 and I also received an email from one of my users who confirmed the same. Frustrated, I decided to take the nuclear option and remove all of my GDPR updates (by reverting the code back to version 3.2.5) and then just serving non-personalised ads.
I have now scrapped the idea of requesting consent for crash reporting and analytics since I believe that this is actually crucial information for the app to work based on the nightmare I had. I was trying to stick to the “letter of the law”, rather than the spirit of the regulation. The data I am collecting does not contain enough information to personally identify anyone and I’m happy to have it go under scrutiny.
Today I watched as my revenues plummeted. This is either due to only serving non-personalised ads or the fact that it’s a bank holiday in the UK. It’s probably a combination of both – I can see my click-through ratio has gone down and so has my CPC. So I made another attempt at implementing a quick consent request so that I can at least get personalised ads back on for some of my users.
Effectively, all of the work I have done to implement GDPR in version 3.2.6 and 3.2.7 had to be undone and I started from scratch. This time also, I have taken a softer approach and just made it a pop-up where you can choose Yes, No or Later – similar to my rating pop-up. (I still used all of the saved consents from version 3.2.6 and 3.2.7 if it worked, so at least people won’t be annoyed with more pop-ups!).
I’m going to package version 3.2.9 now and publish it to all the app stores. I am hoping that this is the final version for GDPR and that I can finally get onto other things. If you are a user who was impacted by my GDPR disaster, I can only apologise!!!
I was hoping to get this out there quicker, but rather late then never!
This week I added some map views of all the data to London Bus Pal. There are four “distinct” views of data in the application, but only three maps are interesting (seeing a single bus stop isn’t the most interesting view!).
Multi-stop view
If you switch to the map view from a list with multiple bus stops on, you will get a view similar to this. It shows you markers of all the stops near you with their “letter” indicators on, it there are any. This is a really useful view to see any bus stops in the area or near somewhere else you might be going (try searching by post code). Tapping any of the markers will give you the name of the stops and where it goes – if you tap on the information box that appears, you will then be taken to the screen to see the estimated arrival times for all buses serving that stop.
Bus prediction view
The next view that is possible is one showing you a list of all stops for any specific bus over the next 30 minutes and the number on the marker indicates how many minutes the bus is expected to take to get there.
Bus route view
The last view I want to show you, is the bus route view. This is a calculated route based on all buses for that route over the next 30 minutes showing their stops. Red markers indicate one direction and blue markers indicate another direction. The pins are also arranged so that you can get an idea of which way the bus is going (I will add some arrows soon!)
If you don’t have London Bus Pal yet, you can download it from the Google Play Store: https://play.google.com/store/apps/details?id=com.mulder.buspal
My first Android application was launched on 6 September 2013. It’s called London Bus Pal.
I’ve had the idea for quite some time, but just never got around to doing it. Finally, over the summer, I sat down and gave it a go.
The idea was for a bus time predication application which you could just open and it would know what you were looking for without complicated set ups. It should just load it up and it show you what’s nearby.
I went off and built much of the application which can be seen today. You could see all stops near you and then drill through items to see specific buses, stops and even routes (the route functionality only came later).
One issue I had, which took a while to sort out, was that the way in which I calculated distance, did not take into account roads, so in my case at home, my nearest bus stop, wasn’t the quickest one to walk to. So I decided to calculate the walking route for each stop near me and then show the closest ones to me in that way. Unfortunately, this ended up being a really slow process and I actually had to remove this feature. It was definitely going to add to the cool factor for this application, but sometimes you just have to make a call and say, it’s not worth it!
So what did we end up with:
Stops near me – when you open the application or tap on the home button, the application tries to find your location and shows you all the bus stops in the area with all of their arrival times in the next 30 minutes. (This does not work if your location could not be determined – there are many reasons for this). You can expand and collapse all the stops and if you tap on a bus, you get taken to the bus view (see below).
Specific bus view – when you tap on a bus in the stops near me or bus stop view, you get taken to the specific bus view which will show you the route details and bus registration number at the top. You then get a view of the expected time of arrival at all the stops for the next 30 minutes. This is a useful view for me to keep open and refresh from time to time once I am on the bus, just to check progress. (A slightly hidden feature is when you see a bit of a thicker line between two stops – this means that the bus changed direction between these stops and it will be heading back to where it came from).
Bus stop view – this is similar to the stops near me view, except you only see a single bus stop. It simply shows you the next buses for any stops for the next 30 minutes.
Bus route view – this is a fairly unique view which I haven’t seen available on many other applications. First, to access it, tap on the bus route details on the top of the specific bus view or enter a route number in search. This gives you an overview of all the stops on the route, in route order and it shows you when the next bus is due at each of the stops. It’s quick to see if there is a gap in the service anywhere between stops using this view!
Search functionality – this acts as a “short-cut” to many of the views mentioned above. By entering a post code, or GPS co-ordinates, you will get the stops near me view (but for the entered location), enter a bus stop number (which you can see on the side of the bus stop) for the bus stop view of that bus, enter a bus route number for the bus route view and enter the bus registration number to find a specific bus (I have to point out that this does not work on customised number plates and I believe that some of the New Buses for London have custom number plates).
I decided to stick with this core feature set for now and get the application out there. There are still many features which I think would make the application truly great, but these will have to wait a while as I only have ten fingers to type with! As it stands, the feature set is very usable and I use this application constantly and very seldom use any of my competitor applications.
Some of the features I will be working on in the coming weeks and months include (if you are reading this in the future, be sure to check out the latest feature set of the application as this would hopefully not always be work in progress):
Bus stop notifications – sometimes TfL puts out alerts or notifications for specific bus stops or routes. London Bus Pal doesn’t currently display these, so it’s difficult to know if there are any issues affecting your local stop.
Map view – being able to see bus stops on a map, especially for the stops near me feature would really add great value to the application. Sometimes I am also on a bus and I wonder if I could get off early or I am just on a strange route and I want to see which stop I should use. Being able to see that on a map would be a lifesaver!
Strip-maps (maybe) – this would just be a cool feature to have – to see buses on a strip map. I’ve got some really cool ideas for this.
Bookmarks or favourites – most applications have this and they tend to be useful. We all have our favourite stops and it’s always great to have these ready. Hopefully the “stops near me” facility partly fulfils the requirement for this feature until it is actually implemented.
If you came across this blog and don’t know what I am talking about, you live in London (or sometimes travel to London) and you have an Android phone, then why not download London Bus Pal: https://play.google.com/store/apps/details?id=com.mulder.buspal.
