Today we’re sharing an overview of our journey towards a common MixRadio codebase across our app portfolio. We’ll show you where we stand following the launch of the Nokia X device family, which ships with the brand new MixRadio app.
Shared code across the various client apps that make up the MixRadio experience has been one of our long term goals over the past year or so. When we began to expand onto different platforms we knew that duplicate effort was going to occur and so we came up with a plan. With the development of MixRadio for Windows 8, a target architecture was defined which we shared during Build 2013.
Progress towards the shared architecture has been an ongoing process and we have worked to bring more and more of the code into our common codebase.
Why common code?
So why do we want all our apps to be based on a common codebase? At a high level we offer the same service and overall experience across Lumia, Asha, Windows 8, Web and now the Nokia X. MixRadio is your own personal radio station which you can access across all your devices. This means that when we build a MixRadio app for a new platform a lot of the same basic functionality is required each time. Where there’s shared functionality, in many cases this could be implemented with shared code. There’s code that talks to our back end API’s to fetch mix data, code that manages user account sign in, code that manages offline station downloads and much more that could be shared.
Every time this code is required in a new app where there’s the potential to share code we have to balance two potential approaches. Should we learn from the previous development experiences, start this particular feature from scratch, but do it ‘right’ this time? Or should we try to reuse the code that we already have and continue to make incremental improvements through careful refactoring?
Comic by Manu Cornet of Bonkers World
Through repeated experience of trying different approaches we’ve made some important discoveries. New code that isn’t fully integrated to existing apps from the start simply doesn’t get adopted by them. On the flip side, with good planning, existing code that is reused in a new app is relatively straightforward to be shared successfully even if this means that the opportunity to create the ‘new shiny’ is lost.
Another benefit of reusing the existing code from a live app is that it is a product of many iterations. It contains subtle but important changes to fix the various bugs that have been identified throughout its life. It’s also a stepping stone to getting something new started. Weeks of development effort can be eliminated by starting with an existing codebase.
As well as these benefits when getting a new app started there’s ongoing benefits too. Want to change how a feature works? Instead of getting the change onto the product backlogs of three separate development teams wouldn’t it be easier to change the code in one place? All apps based off the codebase would then get the change simultaneously. The same also applies to fixing bugs. If a bug lies within a piece of common code then it can be eliminated from all apps with a single change.
Overall we believe that there’s a net benefit in using a carefully managed shared codebase. This is why we’ve been working towards our common architecture.
MixRadio common app architecture
A target architecture based on the MVVM design pattern was defined in order to share as much code as possible between our various client applications. MVVM facilitates separation of the UI from the business logic, and generally the UI is app specific whereas the business logic is common across our apps. Each application should contain the minimum amount of code, ideally only views and anything else that is specific to the platform of that particular client. The rest of the code – all business logic, ViewModels, and models should be shared code used by all apps.
Portable class libraries (PCLs) allow an assembly to run on multiple platforms, so not only the code is shared - but the compiled binary itself. All of our shared code is developed in PCLs. Although PCLs are limiting because they restrict the available APIs to the lowest common denominator of the target platforms, this also helps to prevent platform specific code from creeping in.
The journey towards this target architecture has been steady as we’ve balanced our ongoing feature delivery requirements with the requirement to re-architect our codebase while maintaining the quality of our products. Along the route there have been milestones where we can see clear progress from one point to the next. Each one corresponds to a new supported platform where with the development of a new app we’ve embraced and extended the reach of the shared code.
Before there was any common code vision there was a single app. The Nokia Music app for Windows Phone 7. This app evolved into a Windows Phone 8 application and we shared Windows Phone 7 assemblies between the two applications. We shared some views and ViewModels between these applications by using basic linked files in Visual Studio.
When development of the Windows 8 app was started the common architecture was defined. A common feature layer was implemented as the first step towards the target architecture. There was now a fully common layer between the two platforms. This common layer has already delivered many of the benefits of the target architecture. The common layer was implemented as a portable class library supporting Windows Phone 7/8 and Windows 8. At the same time we integrated both apps with the MixRadio API that we offer for public use.
With the development of the Nokia X app, we wanted to push our common layer forward, onto a non-Windows platform. We had previously investigated and shown a basic Windows Phone app running on other platforms using Xamarin. Xamarin provides a fantastic runtime and tooling support to deploy .NET code on platforms beyond Microsoft’s own. This means that our development teams can build for an entirely new platform with the tools that we know best and again reuse the shared code that we have been developing. Also with Xamarin’s recently announced partnership with Microsoft the platform now officially supports PCLs which makes it an even better fit with our target architecture and the existing common feature library.
After some investigation, we chose MvvmCross to be the MVVM framework underlying the MixRadio application. MvvmCross is in many ways the final piece of an ongoing puzzle. One of the major challenges of cross-platform development is how to abstract away platform specifics in a useful and effective way. MvvmCross proved to be a fantastic abstraction to hide many of the complexities of cross platform development while still leaving the full power of the native platform available to the app where required. Using this framework means we can focus our attention where it is of most benefit to us, on our product.
So have we arrived at the promised land? Of course there’s no silver bullet but we are at another major milestone on our journey. We now have an app built using our full target architecture in production and it is built on top the same common codebase as our existing apps.
The final step in our journey towards the common architecture is to throw out the legacy code from the Windows Phone and Windows 8 apps so they’re stripped back to existing PCL shared assemblies and then integrate them with our fully shared codebase. Now that the Nokia X has launched that’s the next major goal we’re striving towards and work begins now.