Kotlin Multiplatform Mobile Standardizes Mobile App Analytics at Cox Automotive

at cox automotive we are always trying to find a way to make developers better i think kmm also gives us a way to get the developers collaborating again familiar language there's no extra runtimes familiar tool set you don't have to worry a whole lot about what goes on behind the scenes i think that's a clear benefit as well it's got a lot of the benefits not a lot of the weaknesses my name is robert i'm a dev manager here at cox automotive i work for or i work with three mobile teams consisting of android and ios developers and we produce the provision app stockwave app and we're working on a third project currently yeah my name is tokyo nessa kuchuk and i'm one of the tech leads that just robert mentioned one of the teams and i worked closely with robert you know i also managed the provision and stockwave apps so uh the company is all about dealer software and car buying software so this uh provision specifically it's an inventory management tool for car dealerships and we have dealers nationwide using it to appraise vehicles and assist with their pricing strategies this app has been around uh i'm gonna say about nine years now going on ten about to hit the double digits well um i didn't have anything uh until about the start of this year came across through some recommendations um and then you know two carers also he joined the team this year and had some some good things to say about it so that definitely helped investigation efforts not a whole lot of experience up until i guess relatively recently and we've been trying to find ways to integrate it into our current workflow so far i used a kotlin multiplatform for uh two years almost two years in our previous role we basically started as an exploration project uh hey can we we use this we wrote this very extensive module twice once for android once for ios and then we was like hey there's got to be a better way and that kind of led to an exploration and we landed in kmm so so basically that became the testing grounds and we rewrote that library in kmm and so then that the rest is history and we kept adding on you know adding more and more writing more libraries yeah that was that was a good journey so the first thing that comes to mind right so it's a purpose behind analytics and that's that's to have meaningful consistent data not just on one platform but on both and uh you know yeah sure we can log a button click here and a screen be there but what does it all mean and and how do we ensure consistent data between platforms so that's that's the big thing that we're having trouble with we'd have devs asking from the android team to the ios team how did you spell list price is that with a capital l if you put a space in there uh camel case and and even still we would have you know some situations of we get different things logs some things would come in different parameters because one person had an idea and just didn't share it with others and things happen um and so we're just trying to find a way to mitigate that and find a common ground to uh to you know just mitigate those differences did you integrate with a specific analytics tool for that um it wasn't necessarily a tooling question for us it was more of just of a of an implementation uh of actually having a good mindset for analytics and implementing that so we've had firebase going for a long time we've kind of had google analytics running in the background as well just to see what the differences are and you know we've experimented with some other tools as well so what what does that look like kind of architecturally like are you uh are you pinging those analytics apis from your shared code are you kind of injecting it in some way and just having the events defined and shared yeah so we what we ended up doing we have a framework we created in a kmp library for it does two things for us first one it's kind of a mouthful but it's it's an abstract implementation for logging events to analytic services uh event-based analytic services so that's the first thing it does the second thing that we use it for is to define our shared code our find you know what what are the strings that we want to be blogging what are the events that we want to be logging and from there it's the app's responsibility to tell that framework here's the tool that i want to use and here's the trigger point for the event that i'm calling a number of folks get involved with this kind of kind of just to make sure that we were going about it the right way because we wanted this framework to be set up so that we could use this on multiple projects multiple apps and so we we had a rough draft of something going on here and then uh two karen and all the guys on his team tore it apart for a little while and tried to try to really really make sure that it's it's um fool proof and shine um fortunately it's simple it's a relatively simple uh concept here but we just really wanted to make sure that it was going to hold up to the future and has has it so far i guess like it hasn't been that long yet yeah so far so far it has we're starting to integrate in a lot more a lot more things and it's it's been a good way to get folks more interested in this environment so there's a lot of mobile devs here not just on these three teams and it's been a good way just to get some exposure get something out there a working example for folks to see hey here's how you can get into it also i think if i may add um i think because it's it's a relatively straightforward implementation as opposed to a very complex project i think that people you know get their hands dirty easier like because it's you don't fear it as much okay i can grasp it i can appreciate it and i can use it in my implementations i think that that also played a key role into adoption all we're looking at options for speeding up development making developers better uh lowering the cost of development you know all these things that really lead to the conversation of cross-platform technology and that is a that's a huge play for us right now we're trying to find something that fits well not only for our you know find the things that work well for our existing projects and for new projects that come around which you know they may or may not be the same thing so there's there's a lot of a lot of different things that are kind of in play and through cox automotive especially you know there's there's a lot of a lot of different projects and different apps that we are a part of and we work with when you were figuring out what would work for you did you evaluate other cross-platform frameworks or were you more focused on like um we know native let's compare that to multi-platform or did you bring other ideas into oh yeah we definitely we're looking at some other technologies as well and flutter was a big one that we've got some eyes on the company has a history with xamarin and progressive web apps as well so we kind of taken from some learning experiences from that we were looking at what's important to us right now and for our our example you know in our app it's a large legacy code base so we had to take that into consideration that we're not about to rewrite the entire thing in the next couple of months and so kmm came into the picture if i could relate kmm to maybe a comic book character here i would uh say it's a lot like blade it's got a lot of the benefits not a lot of the weaknesses you know for us the things that we liked a lot it's a familiar language there's no extra runtimes familiar tool set uh best of all and the most important one a low risk of entry we can get a lot of benefits and start working with shared code without having to rewrite all of our legacy code all of our ui which is just a little unrealistic so that low low risk of entry was a huge win i would also add um like you can develop a c plus plus library for example right and you can try to share that but you know c plus plus has its own expertise they're not necessarily like just because you know c plus plus doesn't mean that you're a mobile developer and vice versa just because you're mobile but you don't know necessarily c plus plus so you could use an existing uh knowledge people who know kotlin or java in your team and okay i'm going to teach them c plus or something novel to get some multi-platform benefits so that was i think kind of an unintended positive benefit basically the overall vision with using crcd into and integrating with kmm was basically we want to treat our own code as a third-party library just like you would do it as a you know if you were to install firebase when you treat your code as a module it comes with multiple benefits like you have separation of concerns you have ease of unit testing and you've got this modular thinking like i think every function is a module sort of thing so there's definitely well-documented benefits of developing in that style but also there's another benefit right the developer who gets this library and doesn't have to worry about the implementation details of it uh you know going back to the firebase example if you're curious developer you can go back in into the look at the code but often more often than not i would guess that most people don't know how google decided to implement all sorts of functionalities in the firebase so so you could just focus on your app so you don't have to worry a whole lot about um what goes on behind the scenes i think that's a clear benefit as well so when we treat our own code that way um that's basically one of the ultimate benefits like one of the things that's that often is like becomes complicated in the kmp context in particular is like how you generate that binary um for your shared library and and where that lives and where you publish it to and all that so basically uh our it's really stable forward at this time because we only have one module and you're basically creating an android archive for android builds and xc framework for ios platform and we just upload them to our internal uh you know private repositories so so basically really we're emulating as though you would just download like a third-party library from maven or something so since it's a one-time it's just one module at the moment so that's how we're trading at the moment but our plan is to add more modules and scale it up so yeah it's relatively straightforward setup at the moment and from the ios side do they they consume that as kotlin or they consume it as the framework as a framework yeah i think um the child one of the uh you know discoveries or investigation is once we have multiple modules because we know we are well aware that you can only have one xc framework at this time and you know unless the specifications changes in the future so that's the those are the rules that we're playing with so we'll have to do some uh devops uh scripting or um you know come up with some creative idea to create generate single lexi framework you know there are multiple ways to go about this but we're not there yet yeah you actually you can have more than one um now but they can't really talk to each other so like often it's better to have one right right but for things like analytics sometimes um sometimes you know leaving that isolated right i think uh the exploration point is basically as russell said just uh how we scale this to multiple modules and libraries i think we're going to keep up treating our own code as a third-party library sort of thing i think we're going to keep that up for the foreseeable future but establishing sustainable repeatable clean development practices for kmm i think that's basically setting a good precedent so that any team member can even if it's a new team member can kind of pick up the rope and start climbing on it and hey i can i don't know it yet but i can look at the examples that and kind of go from there so i think that's basically where we grow from here is just establishing those patterns when they've been in the company documenting them and making it available to everyone in the team so that we have a we have a good and easy to follow practice for kmn do you know yet like what the next um modules you're going to build will be shared code is the next step so analytics is our that's our kind of baseline entry point here our little risk entry point the next step on here is to find some common things between the app that we can start extracting and dropping in here and then ultimately we want to get to a point where we can where we have our whole api layer they're listed in my mind that would be the ideal state we've got our whole api layer extracted out into this this k m uh k n project we're always ways away from that for right now but at least that's something that we want to work towards i was curious you know at this stage besides like the ability to have multiple independent frameworks that can talk to each other if you had a list of like things you would love to see solved like tomorrow and that can include libraries that can include runtime stuff that you know build related things distribution related things you know we would love to see the following i think from i you know i use that platform um over almost two years and so making it clear when this object graph freezing making it clear to the developers that this is a frozen object and um there are only certain actions you can take on this frozen object and this is a mutable object and there's certain actions you can take on that making it clear to the developers and somehow as you're developing the code i think that would help a lot with the production crashes and that sort of thing and also with the newer devices we have all the devices have multiple cores so somehow making it more multi-thread friendly i know when android is relatively straightforward it's not there's not a whole lot to worry about that for for ios you have to be more cognizant about okay which thread did i get this object from and which thread is it's going to go to and and there are certain usage patterns in each each platform so kind of take that into account i mean in android you could you could be using core routines and that sort of thing in ios you could be using grand central dispatch or you know other source of maybe rx fifth uh that also gives you uh multi you know a lot of uh threading options so kind of make it make it more multi-thread friendly i would say would be uh as you scale up you're gonna start seeing these issues so i think that last point there so it's probably the biggest one that that uh paused us for a moment when we were getting a little ahead of ourselves you know getting a little ambitious and just trying to move forward and run with things and then some conversations about multi-threading issues might be a thing we should probably watch out for it and you know given a lot of the devs are still pretty green with it we do have you know thankfully to care and uh and we've got another guy on the team here that's got some previous experience with it so that helped us realize you know what we should really make sure we understand what we're getting into before we go full out into this so that's part of our next steps that's kind of why we're incrementing we're getting towards an api state as we really want to make sure we know what we're doing before we get there

Channel: Touchlab

Views: 167

Rating: 5 out of 5

Keywords: android, mobile, kotlin, kmm, kotlin multiplatform, kmp, kotlin multiplatform mobile

Id: YdI3OZnA7S0

Length: 16min 36sec (996 seconds)

Published: Wed Sep 15 2021