Using Kotlin Multiplatform to build apps for cars

um so yes my name is Joe I'm a mobile engineer here at octopus and I work on the octopus electr app um I'm going to be sharing with you a little bit about how we use cotlin multiplatform to build apps for not only mobile but also car so I'm sure many of you will know a little bit about octopus energy already but unless you drive an electric vehicle you may not have heard of octopus Electra so our goal is to build the biggest and best public charging Network for Ev drivers and to do that we need to meet our users where they are and often for us that means in their car so around a year ago we launched apps for Android automative OS uh Android auto and apple carplay uh building on top of a multiplatform architecture we use for our mobile apps so in this talk I'll be be covering a bit of background on our journey with Coty multiplatform we'll be looking at how we use it for Development Across mobile and car and an example of what this looks like on Android auto and carplay so our journey with coton multiplatform started in September 2020 with our initial commit to the electr project um and it was a pretty bold commit uh for starters Alpha One of compose 1.0 uh so a bit risky and there's been some bumps along the road but overall this has worked out really well for us um so composers matured into Google's um recommended toolkit for building uh UI on Android and we're 100% composed so no no Legacy layout xmls for us um similarly uh perhaps less innocuous but equally daring uh we're using cotland multiplatform in version 1.4.0 so you may think 1.4.0 sounds pretty stable to me well cotland multiplatform didn't actually go stable until over three years later in version 1.9.2 and in a way it still like still feels like fairly early days for cotland multiplatform with some exciting changes and improvements coming up in uh in 2024 including uh cotlin to to Swift support which is likely to bring some nice improvements to the developer experience on on iOS so obviously uh adapting sorry adopting these tools from from an early stage uh hasn't been without its challenges but we've we've grown to love cotlin multiplatform and others are loving it too so here's just a couple of real world success stories of uh some pretty large companies using cotlin multiplatform to build apps that are used by millions of users worldwide um it's also worth mentioning that although this talk is primarily focused on the on the RSE app the the main uh octopus energy app with with over 2 million monthly active users is also using cotland multiplatform in a similar way so yeah it's been proven to work at scale um so why is cotland multiplatform gaining traction well one reason it's because in my view is because it's suitable for for all sorts of projects so it's a flexible option for crossplatform development you don't need to go all in and in fact you can use it as sparingly as you wish so for example prior to joining octopus uh I worked on a project where we were using cotland multiplatform for a small self-contained piece of business logic and then on the other end of the spectrum with Advent of compose multiplatform some are now using cotlin across the full stack of their multiplatform apps uh on electroverse we've opted for a middle ground we're sharing as much logic as possible but keeping the UI native and we kind of view this is is the best of both worlds um so one of the one of the key questions when evaluating a crossplatform tool is how do we Implement platform specific logic so in cly multiplatform we have a couple of options which um start off with the expect and actual mechanism so in our common source set in the cotlin multiplatform module we say that we're expecting an implementation of this function within the source sets through each platform so this allows us to use Android and iOS platform apis within the cotlin multiplatform module so for example here we are using uiit which is a a native iOS framework within cotlin code um which can be quite a novel concept if if you've only worked on Purely native projects uh for more complex scenarios it can be more convenient to use platform specific implementations of an interface so to do this we can define an interface in the cotlin multiplatform module then Define implementations in the app modules so on iOS the implementation will be in Swift rather than in cotlin so this is generally the approach we use on electroverse for platform specific logic and particularly when we're we're using Swift only dependencies on iOS as these are not yet supported in cotland multiplatform so moving on to architecture there 101 ways to architect a mobile app um we've chosen to follow a clean architecture which is strongly inspired by Google's guide to app architecture um and although this guide is Android specific we find it works really well in a in a multiplatform project as well so in the nutshell we have a data layer who uh determines how our app creates stores and changes data our domain layer sits between the UI and data layers and is responsible for encapsulating our business logic and our UI layer's role is to display the application data on the screen so for us the data layer the the main layer and the view models all live within a cotlin multiplatform module we call this our shared layer so we're left with a thin layer of UI which is kept native on each platform and this approach works really well for us uh we have a relatively small team of mobile Engineers who are able to deliver features end to endend across multiple platforms also sharing a large percentage of our c-base helps us to ensure we have consistent business logic across platforms while still enabling us to build uis which look and feel great on each platform so taking taking a look at our project structure uh prior to adding car apps and it it starts off pretty straightforward so we have a a cotlin multiplatform shared layer where the bulk of our code lives um then we have app modules for Android and iOS where our thin u a lives so what happens to all this when we add car platforms into the equation well initially our plan was to pretty much keep keep the same thing so we add a new app module for Android automative OS as that is a standalone app Android auto and carplay are embedded in the Android and iOS app modules um however there's a a few things we need to consider when when building apps for car so most importantly as developers we must um avoid driver distraction at all costs so this is quite a different Paradigm to to mobile where many apps are kind of built to be distracting um and this is this is semi enforced by requiring developers to use templates for their UI so in our case we use the navigation templates uh there's also a requirement that app developers keep task flows to five steps or fewer and this is enforced by the runtime um sorry at runtime by the SDK um so if you go over this the app will just crash um so yeah not great uh if we want to enable um as an example if we want to enable users to search for a location find a nearby charger view information about that charger navigate there and start a charge we need to do this within five steps which um presents a bit of a ux challenge so given these restrictions the user experience pans out to be quite different to the mobile app and our initial plan to share view models between mobile and car just didn't really work out and also there's a few cases where it's beneficial to have car specific implementations of our interfaces so this led us to breaking down our shared module into sub modules allowing us to separate concerns between mobile and car so we have shared mobile cotlin multiplatform module where um we have our mobile specific code and then shared car which similarly is a cotlin multiplatform where we have our car specific code so what does this end up looking like for the car WS um well if we start by focusing on Android auto um so we have a screen which is kind of analogous to a fragment or a composable destination um a screen has life cycle methods like oncreate which will be familiar to Android developers but it also has an onet template function in which we use template uh Builders to Define our UI so note here we've injected our view model which is imported from the the shared car module so expanding on this a bit so we we consume a view state from said view model to build a list of locations which we'll show in the template switching over to carplay Things Are very similar we inject the same view model that we're using on Android auto we then consume a view state to create items for a list template so lots of similarities between the two platforms so moving over to the the vew model which lives in the shared car module so this essentially Maps a flow of data that we're getting from a use case in the shared module to something that the car UI can display so we try to keep this view model layer quite thin with all business logic networking persistence Etc done in the shared layer which is shared across both car and mobile so looping back to our architecture um even with these additional mobile and car modules we still benefit from having a large majority of our c-base shared between all platforms so obviously I've just scratched the surface here um but hopefully this has given you a taster of what it's like to use cotland multiplatform it's made it possible for us with a relatively small team to build products across multiple platforms with possibly more to follow so who knows maybe we need to update this graphic soon uh so in summary we covered a bit of background on our journey with C cotland multiplatform we looked at how we used it for Development Across mobile and car platforms and we looked at an example of what it looks like for Android auto and carplay and I can't wrap up without a shout out to Antonio who's based in in Germany so you can be here so Antonio has been the brains behind our Android car apps um and I know he'd love to connect if you have an interest in building uh apps for for car and what I should have mentioned also is Jack wave Jack similarly is the brains behind our carplay app so yeah again get in touch with him if you if you have an interest there uh also a couple of useful resources uh so starting off with touch lab we have a whole bunch of useful stuff around cotlin multiplatform so sample projects blogs uh open source libraries so recommend taking a look at their website uh John O'Reilly is a Google developer expert for cotlin um who has a keen interest in cotlin multiplatform so he has uh a number of really really really good sample projects as well and finally you're link to an Android code lab um for learning how to build uh apps for Android auto and automative OS PS as Alex said we're hiring across uh various teams and roles so if you're interested head head to the website or speak to Michael is Michael here Michael's somewhere um yeah that's it that's me any any questions [Applause]

Channel: Novoda

Views: 1,926

Keywords:

Id: 6UULcs0cA7g

Length: 13min 12sec (792 seconds)

Published: Fri Mar 01 2024