A developer’s guide to BBC News on Android
If you’re living in the UK — and for many of you around the world — you’ll probably recognise the staccato chime and burst of drums from your mobile, telling you that something important has happened in the world. Natural disasters, election results, the death of infamous celebrities, and royal nuptials; all these gifts of knowledge are delivered to you by the BBC News mobile app.
And, you won’t be alone. The News app has over 9 million users each week; that’s roughly equal to the population of London. The Android app, which we’ll put in the spotlight in this article, is available in a number of flavours, all built from a single codebase. Outside of the UK we offer an ad-supported version for global English-speaking audiences, as well as five other language variants: Arabic, Hindi, Mundo (for Spanish speakers in South America), Russian, and Welsh. Our users are loyal, too, with a third of visitors using the app daily.
We’re responsible for keeping people informed about what’s going on in the world around them, so our app has to be stable and reliable. It needs to be simple to use and accessible to all. But we also try to present our content in creative and engaging ways, which means taking advantage of new libraries and APIs as they become available.
Keeping things fresh
We release updates to the app each month, something we’d like to make even more frequent! This, together with A/B testing, allows us to evolve the user experience incrementally. Change is still controversial, but we aim to avoid alterations that are too wide-ranging — the sort of thing that’s provoked a slightly negative reaction in the past:
We’re committed to supporting the latest the platform has to offer, and try to target new Android versions as soon as they’re out of beta. This isn’t always a painless process. As an example: the Oreo update exposed issues with our use of content providers, and the new notification channel interaction model continues to present us with challenges. But this commitment to staying up-to-date allows us to deliver features like Launcher Shortcuts soon after release, as well as taking advantage of performance and stability improvements.
As developers, we try to keep our coding practices current, too.
Writing great code
Like many other Android teams, we find a lot that’s useful in the basic Android development environment, but think some parts can be improved. Hence we augment the standard toolkit with a range of open source libraries.
We make heavy use of RxJava in our asynchronous code. This gives numerous benefits when compared to standard Android patterns like AsyncTask. Chains of functional operators allow us to transform data with fewer side effects. Multi-threading is easy to implement, and straightforward to stub in unit tests. And errors can be properly handled. For network requests we combine RxJava with OkHttp to retrieve and cache data in a flexible, robust and performant way.
A complex app means complex object hierarchies to manage. Here the dependency injection framework Dagger (well, Dagger 2) helps us out. Components are either annotated directly or referenced in configuration classes, and Dagger does the hard work of generating the boilerplate code to instantiate objects. It also can provide and maintain singleton instances of classes, allowing shared state without the testability issues of a classic approach.
We’ve also introduced Kotlin to the project. New modules that don’t incorporate legacy code are being implemented entirely in Kotlin; older modules use a pragmatic mix. Even in areas using Java heavily we’re seeing benefits; for example, using data classes to replace code that would previously have been generated using annotation-based libraries (in our case, AutoValue).
However, third party libraries don’t just allow us to write better code. They can also allow us to deliver user-facing features in a richer and more efficient way.
Better features, built faster
A great example of this is the approach we’re taking to add motion to the app. While the Android animation API has improved hugely over time, adding movement to buttons and other parts of the user interface still involves significant effort and understanding.
Here we make use of Lottie. Created by Airbnb, Lottie renders After Effects files as native animations that are included as easily as traditional static assets, and can even be hosted remotely. This allows the designers — an integral part of our team — to create complex transitions between UI states using software they’re familiar with. The exported animation is then simply referenced by the developer in an instance of LottieAnimationView. This supports animator-like interactions, so the ability to start, pause, resume and cancel. It also lets us observe state changes using AnimatorListener and AnimatorUpdateListener.
Hence we can add animations quickly and precisely, and in a way that allows changes to be made easily in the future.
Onwards and upwards
Our lives as developers are not, however, without challenges. The codebase of the current app began life in 2013, and was first released in 2015. To put that in perspective, your phone at the time probably looked something like one of these:
The Android build plugin at the time lacked unit testing support, multi-module builds were slow and required a lot of bespoke configuration, and singletons were fashionably cool. Well, maybe not cool — but they were certainly heavily used! As a result the current team inherited a monolithic codebase with minimal unit tests and a fairly loose architecture.
As discussed earlier, we’ve introduced techniques and components into the project that weren’t available during the incubation of the original codebase. Singletons have been replaced with injected dependencies, and we’ve made a lot of progress towards a cleaner codebase that’s easier to test and more resilient to change.
We’re now embarking on a new phase. The project is being restructured based on clean architecture principles with clear layers of responsibility. Distinct software functions — so things like data retrieval, business logic processing, or presentation — are finding new homes in separate decoupled modules.
So why are we doing this?
A big motivator is the ability to scale. As consumption has shifted from desktop to mobile, so the size and needs of our user base have grown. This creates a perfect storm: app complexity, team size, and the number of new features required have all increased — and so too has the risk associated with making changes across a monolithic, tightly coupled codebase.
A modular approach allows change to happen in isolation, with behaviour changes limited by strong contracts between components. Functionality can be tested with much less complexity: stub implementations replace real dependencies, with no need to worry about their inner workings.
Modularisation has other benefits, too. We’re able to create our different app flavours in a more flexible way; optional modules — maybe even built by a different team — can be included in a particular language variant through composition. Build time is reduced through improved incremental compilation. And it’s consistent with the approach required to create Instant Apps, something we’re excited about trying out in the future.
And it’s goodnight from me…
So that’s a brief look at the way we do News on Android at the BBC. We’ve explored the way we write code, and the challenges we meet along the way. But it’s worth returning to the why: our users. Meeting the needs of a diverse audience can be tough, but will always be outweighed by the reward of delivering trusted news to a user base of millions around the world.
Plus, we get to work with some great people. Even the ones with Apple phones!
Wish you were here?
If you’re an Android Developer, and all this sounds like an interesting challenge — come and check out our available roles! We do percent time, go to conferences, and get lots of training, so there’s plenty of opportunity for growth. There’s also often cake!
