Kotlin Multiplatform Mobile (KMM) at Volley, Voice-Controlled Entertainment Company

all right uh welcome everyone we are here for another episode of uh touch life's chair we are very excited to be joined by the volley team both josh and aaron um so what we're going to start off with uh with introductions if aaron you want to go first and kind of give us a little bit of background on yourself and then we'll switch over to josh before we dive into some of the questions that we have prepared for today yeah sure uh yeah really happy to be here thanks for having us my very long-winded title is vice president of engineering for media infrastructure and mobile over at volley so i've kind of done a little bit of everything most of my career was actually in mobile huge fan of kotlin from even prior jobs that i've worked with josh here as well and we've just kind of carried it through to our current projects here at bali so yeah really happy to be here and i'm josh i come from a non-traditional tech background which i always like to to rep went to a boot camp and then i've been doing android for about five years now and then ios for one year and i've been with volley for for that year awesome for the folks that may have not have heard of volley we would kind of like to hear it straight from from um from the folks that are working on the products how would you describe the company its products and and what are they working to accomplish like what's kind of the vision and mission here so volley kind of has grown up with the most success kind of around the voice market and that's definitely what we've sort of uh come to specialize in we were fond of saying internally that like we sort of want to target anything with a microphone so alexa is definitely our you know alexa and google assistant are our big sort of targets and then as things sort of start to show a lot of promise and grow an audience we start looking at like well you know how can we bring mobile into the picture so you know like one of our our top uh skills in the voice arena is song quiz um you know and like i think that that's kind of been our behemoth sort of for most of the the company's life and eventually we're like okay people want to play this on mobile let's make song quiz mobile a volley fm uh which is sort of our sort of micro podcast you know little five minute daily clips uh you know with our own sort of uh set of hosts and content creators um you know that started to grow and get you know very successful and so we said okay people are going to want to be able to take this with them you know kind of seamlessly transition to maybe listening in the kitchen to listening in the car so that's kind of where mobile came in for that and so yeah just kind of anything with a microphone voice that's sort of what we do thank you for that and kind of going into you know what a typical day looks like for both you can just kind of just describe what some of the roles and responsibilities that you're currently working on i'm the lead mobile engineer for android and ios for the volley fm app so my my day is just writing code uh talking with product and uh planning the features and coordinating dependencies and whatnot and so i'm the the engineer for both the android and the ios app so i jump into both code bases and through kmm there's a lot of shared code which makes my life easier and so yeah typical day i might be working on like let's say i'm working on a new feature i'll pick up on the platform to write it in first like whether it's ios or android uh work on the shared code and then jump on the the other platform to finish it out yeah and i unfortunately get to write very little mobile code these days um as volley has kind of grown and scaled you know pretty quickly in the past year so uh it was really cool that i was able to land josh and live vicariously through him but yeah my my day-to-day like is managing um kind of all of the voice product engineering that happens in the media group and so that is volley fm that's bedtime stories things like that as well as kind of overseeing the direction of our infrastructure group and so like we have our own internal engine for building multi-platform voice skills um you know unfortunately that side is type script uh and you know it was a node company that i came into and so we kind of lean part into that it's been really good and then yeah just kind of checking in with josh every now and then and seeing seeing what he needs i'm glad um we have both perspectives here right we have the kind of management side and then we have the folks that are actually in you know in kmm day in and day out my question to josh has to be you describe yourself as an android and ios engineer and and we know that a big part of the draw for to coming over to volley was the ability to work on kmm what's been the experience like so far being able to deliver on both platforms what what do you like about the experience just kind of share with us because i think that that title to me my first thought i was like oh that's really interesting right android and ios what do you what are your thoughts there so yeah i mean like the the draw of kmm of course was the the shared code base being able to and to not have to write everything twice and when i first started at volley like my first task was refactoring the ios code base because it was originally uh written as a hackathon project after doing that and then like jumping into the android code base like they were different architectures it was just the context switching was huge and like very costly i would have to like i didn't want to jump in and out of the code bases i was like wait i want to focus on this one first because it's going to take me like an afternoon to ramp up on the other one with kmm and and the shared code base like the architectures are aligned like it's much easier to reason about everything it's much easier to think about like how to add new features and so jumping in and out is much easier like i'm i'm very comfortable jumping like starting my day on android going to ios like switching back and forth like so the the cost of context shifting is greatly reduced i i kind of wonder if kevin sam russell like have you did you share those experiences do they sound familiar yeah certainly as i'm saying i'm curious it's actually if um if you still find yourself kind of favoring one or the other like i i definitely still feel more at home on the android side than the ios side despite having done both for a while now for sure um like definitely because android's you know android's why i know andrew's angel's my home um so i definitely feel more comfortable on the android side and it's like writing the shared code in kotlin is is great uh i love kotlin so so um but then also each has its own own appeals too like there are ui things are much easier to do on ios than android but if you're talking about like comfort level yeah i would say that i feel more comfortable on android weird in that regard not that i feel more comfortable with ios i've just been so far out from being an android only dev for so many years i'm not sure which platform more actual binary gets shipped on out of my day but i will say merging a large x code project from a release branch into i did that yesterday i wasn't excited about it yeah is that what you did yesterday yeah uh you know i had a lot of things i needed to get done yesterday yesterday was about a solid 12-hour day many of those hours were involved in that one particular thing but it you know obviously it's not cobbler related um but you know there are certain things like i worry significantly less about the device variation for object screen stuff so that's what you're doing but i don't really think of the architectures as much different because they're not working with their shared code so yeah i'm not an android engineer but um i agree with josh android it's still my home uh he's because of touch lab and and all the folks that work on it so let's let's kind of talk a little bit about the use case of kmm at diwali um where in the portfolio in the suite of products right does this kmm sit and and what's kind of the use case um for for kmm on that particular part of the of the suite yeah so right now we're using kmm in the valley fm mobile app it is the the first app we're using kmm and it was the the test run to see if it you know to see how successful it would be so far it's it's been great we've we've loved it and the goal is to be able to share code in future mobile apps as well some of the my favorite things about working in kmm is also just trying to build these reusable components and like if especially if we have less engineers like the more we could take off their plates the better and so if we have module that works for ios and android great um and so like at volley right now we're working on we've got a media player for android and ios and the eventual goal like far future is to you know release an open source but the ability to be able to drop like a media player into a different app on android or ios i think would be a huge gain for us um and and kind of describe the the technical makeup of the kmm implementation what's what's being utilized what's being shared right so we're we're using ktor for the networking we're we're using a open source library that aaron built for caching for the day layer persistence and then we are also sharing view models which is i think a huge benefit especially of having um a small team working working on both platforms is that we're able to share all this code like the one of the the big draws of kmm like and shared code was the fact that like we could also share view models so that's a lot of potential for code sharing so that's how we're using it if your model's already one because like there's i've definitely seen some kind of back and forth in the community on like what layer you want to stop at like sometimes you want you want things to behave a little bit differently for platform or you want to be able to like mean to platform specific things more easily um but when you can get it all shared it's really nice yeah yeah i it's interesting because i have had conversations with some pretty die hard ios folks you know that i know in my network and on twitter and i think the one thing that they like that is kind of unassailable that they can't come back against is just like yeah man data and networking like you know like maybe work into view models and like the architecture stuff later but everybody that you pitch like you know just like yeah unified networking and caching too like everybody has scars from from that that they're just like yeah i would love to just be able to cut down that work have one really well tested code base and not have like android getting four stars on the the play store and ios getting three stars because like of tech debt or whatever so yeah it definitely resonates uh is the networking shared throughout the app or or are you sharing a particular module like the the video player that you mentioned networking is shared throughout the app so we're using um ktor for for all our api calls it's like sort of jeopardy and earmuffs uh how do you feel about kator in the sense that like uh it's an interesting conversation that comes up repeatedly kate torkan does a lot of platforms and it kind of tries to do the same thing across a lot of platforms but especially on let's say the ios side it's still as far as i know you like launch it from the main trading so it clearly doesn't do its work in the main trip but there's certain restrictions there we found it's kind of difficult to test and some folks essentially implement like a mobile native only network player which is something we kind of internally discussed on and off you don't really want to compete with so yeah my thoughts on ktor is i've heard about drawbacks like serialization happens on the main thread and we like we weighed the pros and cons and decided that the pros outweighed the cons there like because our payloads aren't that big like we're not taking that big of a hit with the serialization stuff and then also aaron and i were talking about this the other day but just thinking about this like ktor was the foundational part of the app because like the first shared component was the networking so seeing that that worked was also just psychologically like really cool because it's like like this this works there like there's potential here let's keep going and yeah just it was the the first building block and we don't really have any complaints it's been great so far yeah i think there's also a lot of really cool synergy just that kator and the kotlin x serialization stuff sort of like you know comes as a pair almost and just like it's almost like the unsung hero of this equation is that like they kind of solve you know not having to have this layer of you know like json on one side and you know i potable or whatever on the other side it's just like yeah like throw in some annotations you know we're big fans of quick type for actually converting like we actually do a lot of our schemas in typescript and then run it through quick type i would i actually contributed the kotlin x serialization support for the inverter and it's just it's beautiful right and so then just having a network layer that kind of hooks directly into those types natively like is like almost a bonus looking back right i i know the experience has been pretty positive and it's working and team enjoys working with the technology a couple of things right looking back what were some of the trickier things that you had to solve for for your particular organization that you think are applicable to other teams any any stuff like that that we can talk about so uh so i will say this like it it has been a very positive experience but we also knew what we were getting into because we started using it before collin 1.4 which was like you know a milestone change and so writing before that and after that we had to change a whole bunch of stuff the co-routines multi-threading dependency didn't work on ios for like a couple weeks too like so just there there were issues but we knew what we were getting into and that was something we we took head on and it's been very positive and now it's a lot more stable so i think people coming into it now it'll be much easier but also as far as things we could have avoided maybe like missteps the one big thing that comes to mind was the caching library we're using we originally were importing it as an artifact and while these changes were happening it was difficult to manage like transitive dependencies so when things worked on android but they didn't work on ios because serialization like hit 1.0 and we didn't notice that we didn't update it uh it was hard to track down so in hindsight we shouldn't have tried to separate things out so so soon and waited for things to be more stable and like just throwing everything into a single project that's that's the big one i think um we'll we'll get to that part about the the weighing the risks pros and cons right but i think a common theme that we hear in a lot of the teams that we talked to for telescope share is we knew what we were getting into right we evaluated in certain areas that we knew were going to be you know alpha other areas areas that were going to be beta and we had a calculated approach to how we're going to manage some of that so it's really cool to hear that theme coming up again in this particular occasion as well any areas that surprise you in terms of how well they worked it was the satisfaction of sort of making prs and stereo like doing an android version followed by an ios version and then the reviewer was like wait didn't i just review this uh uh yeah and and josh is also very good at attaching gifts to his prs um of like here is the feature in action which like you know if you ever want to make your boss really happy just start doing that um and so i would get these pr's and sometimes he would just pr both platforms at the same time and there would just be two side-by-side gifs of like scrolling the recycler view or you know whatever so it was cool yeah like and then the most satisfying part was also just figuring out how to architect it when we were first evaluating the technology like seeing what we could do with it i remember just not knowing how to use reactive patterns from the shared module on the ios side i was like wait do i need to wrap this in something and use com like implement combine and like freaking out about that and then i found this thing online from intellij where they wrap flows like for this kotlin conference app and we're able to use them on the ios side once we found that it was like oh we're good to go like seeing how well that worked is like like oh like now like this is a totally viable thing we can do you find yourself um like running into any um issues with the threading model around that we have tried to avoid those issues as best we can but um by not changing threats when we don't need to we are recently as we're like adding more complexity i have started to run into these issues and now i'm learning more about the threading model and it is it's a steep learning curve um it's you know it's like it's surprising at first what do you what do you mean this is straightforward russell why'd you bring it up yeah yeah just um seeing how everything well okay so for example like if for some of this i've been you know writing like an interface or an expect actual class in the shared module and then on the ios side i'll implement the interface and inject into the shared module and usually when that happens like i'm only dealing with kotlin data classes so it's very trivial to to freeze them and like pass them around if i'm trying to write something in the shared module in kotlin there's more things going on with the multi-threading that like i i have to think a lot harder and reason about like how things get frozen and like what will that freezing stop i feel like i i'm like the only the planet's only defender of the of the threading model in any way shape or form but the interesting part is i just had this thought it's been rolling around my head for a while it is difficult and i think it's difficult because that you know fundamentally on the jvm side you don't have these rules and you're not used to them and kotlin the language itself was designed jvm side and then you have these rules over here on the ios side and i've been doing it for so long but i don't find them to be difficult necessarily to work with but it's like a lot of people i've seen especially even recently they're like i don't understand how this works we didn't didn't read the intro like you have to read the instructions you can't not read the instructions like otherwise it will absolutely not work and looking forward down the road i almost feel like this is a really good thing to learn if you want to understand concurrency but then not have to use it you know what i mean like if it was like this was a class and concurrency you'd use collin natives like runtime model so you'd really get intentional about thinking about your current currency they'd be like all right great let's just take that away and then you can like just use it however you want then i'm down with that yeah i think i kind of take for granted that you know my background was in the game industry uh when i first started you know before i kind of got in like i basically we did an ios game way back then and that's how i got into ios but at first yeah it was c plus plus like building a game engine i still think one of my favorite books out there is c plus plus concurrency in action i think it's called where it's like literally the book walks you through how you would write a lockless cue i think and just like how you do the transactional like you know kind of rollbacks and all that and so yeah for me it's just like yeah no this is gonna be okay like this is gonna be really tricky and this is going to be like c plus and i think you know josh kind of came into it and having done you know the more jvm side and is you know kind of digging into a lot of these things for the first time it is weird because it's like it was a noble effort i think on the kotlin side because it is putting rails around things you shouldn't think it's usually it's it's like when you dig into it's like well this is getting frozen i don't understand why it's because you are referencing something from a different thread that you really shouldn't be but that's that all sounds good in theory but then there's things that like you know you aren't intentionally referencing or it's it's a immutable value that you're representing from another thread but that happens to capture the rest of your object graph so you know good intentions [Laughter] yeah those i definitely get why they did it and sort of also get why they eventually like first of all mad props to jetbrains for looking at it and looking around the room and they were just like you know what come back to us in a couple of years we're gonna replace this you know looking really looking forward to seeing how that goes i i like well i mean part of that i think was they were working on the multi-threaded car routines and not just seeing other people writing issues by running into themselves there is a thing that will never see the light of day that i was like sucking up my life at the beginning end of 2019 at the beginning of 2020. which was an intelligent visual plug-in that was attempting to warn you when you were likely to do something that was going to write a foul of these rules that part of it was to help you code but it was also part to help you learn the model this is back when i was like i definitely props to japanese for deciding to like say hey we're going to change this and hit pause for a couple of years in the runtime effectively but it was also like i don't think that's going to help with adoption in the near term i was trying to like convince people that it wasn't so bad but i i think we've all collectively decided that this is the correct move now we're just all waiting see how it goes but yeah it was a pretty it was actually pretty neat like what you can do with static analysis it would just underline what it was like you know what you know you're trapping this and freeze this whole thing i think lambdas was one of the tricky things that i remember us discussing the other day of like pointing out well you know like this variable does get referenced in this lambda you just enclosed it and that was having to start thinking in that in those terms is always that's like that's like 95 percent of the issues between currency model because the lambda syntax makes it so easy to do certain things but it's so easy to also capture state and then like it's not just it's like if you have a class and the class has a value that's like an integer and then in a lambda you're calling the database you happen to be referencing that integer you're also referencing the entire closing class and everything could touch which might be your entire object so good times so anyway that intelligent plugin will never exist beyond the confines of my backup hard drive or whatever whatever it is now yeah we can't even say rip it never came out but uh it's there somewhere i want to take a little bit of a step back you know because i think we're getting into some of the the more technical aspects of like implementation and kind of maintaining this for the folks that are not there yet right what what really stood out about kmm compared to other solutions and and what i mean by that is like did you evaluate other solutions if so what ultimately led to the decision to move forward with uh with kmm i definitely evaluated a lot of these solutions back when i was at capital one which is where josh actually you know kind of first joined my team through you know level money and and that acquisition and things like that and you know as part of one of these big organizations that's always looking for synergies and you know consolidations especially among their web developer group who who would often come to come over to us or somebody and be like hey like when can we you know adopt react native so all these web developers can get in on the the mobile stuff you know hopefully that's past statute of limitations to talk about i don't know but yeah so like i did i did the evaluation of react native we even like built a few things like me and a few of the team members and everybody kind of roundly agreed like this you know like this isn't for us i think it's hard to get it's hard to get mobile devs on board when both sides need to learn something new you know at least like you know you can get android devs fully on board with kotlin multi-platform because it's as you said it's home so yeah like react native like i think you know both the javascript runtime i think the fact that maybe in its earlier days it was very ios centric and android kind of like was a follow-on platform in many ways like especially with the navigation stack and then like philosophically i'm not sold on shared ui i think ui is a very special thing like being able to do full native like platform specific ui means that you're always able to use the the latest releases tools features and that you know you never have to worry about it like it just maybe a few pixels off right that kind of uncanny valley i think flutter just did the amazingly hard thing of fully replicating both visual platforms like pixel by pixel and good for them with the little goopy you know animations and transitions but i do still think you know like when apple goes and decides to change their entire design language like flutter's gonna have a hard time you know that and i'm just personally not a huge dark fan so and then i even went as far as to like uh evaluate xamarin and all of that stuff and it was fine oh yeah you know i did i ran a game company for two years and so there's a lot of like little projects sitting around at volley of explorations in unity for shared mobile stuff which i still you know really love but you know it's not native oh i just want to echo aaron's sentiments also about the fact that it didn't cover ui like that for me was a great just like philosophically baked in separation of concerns because i you know i i agree that it's usually with ui bugs that things get the trickiest and so to just take that off the table was a wise decision i think i'm so excited for jetpack compose though we'll see how that does so i was going to throw out the not so much that it doesn't do ui is that it doesn't force you to make some of these choices which is like you know without getting into particulars of the other you know competing frameworks which you just mentioned all of them they are not designed necessarily to interact well with the existing platform that is it is very difficult to create a solution that that does play well with everything that exists there which is kind of what howard's design goal is versus i don't want to say it's easy because it's not easy to do any of these things but it's easier to say we're just going to like not worry about the rest of what's out here and just build their own say and then the rest the communication with the rest is sort of like at arm's length or at inter-process communication versus like direct interact which i can't see what we're doing exactly but i've had to actually uh i have i've gotten composed at least the run time to run on native uh with with help from folks who are way smarter with those but not the ui that's i i wouldn't expect that to come anytime soon but eventually sure and now kind of going to um you know the differentiation and the value proposition of kmm was pretty clear and aligned to your engineering philosophy what was the evaluation part like right did you um how did you introduce the concept to to leadership um was there any pushback just kind of walk us through that experience of like getting this ultimately from an idea that you agreed with philosophically to now where you're at and the success that you had with the technology it's you know like this is like where you sort of get into this like your mileage may vary situation right i think we kind of had this perfect storm of you know situation where a like i think both of the apps kind of definitely had a lot of tech debt like or both platforms um you know one was straight up a hackathon project from the ceo and so like we had kind of i think put off some of that tech debt founders of the company knew that like i was a huge fan of kotlin you know i've spoken at kotlin conf and so i think that gave me some leverage or or at least a little bit of a halo to be able to you know to say some of these things but you know like one of the the big things that i i would sort of say is the you know at the very least like what do you call a failed kotlin multi-platform project and it's a bog standard android app right like yeah okay you you try to go make kotlin multi-platform work and you fail well the android app's still ready to go and like you know you maybe have to rewrite the ios side so like there's this limited down downside i think you know if i were being totally honest like they i think they were very impressed with josh and they knew that josh really like that was what sort of sold him on this job in the first place was that he got to do this that's that's true that that was a big selling point for me yeah yeah because i have been hounding josh for a while like man when are you gonna come work for me um so you mentioned kmp i was like i'm there yeah um but yeah so like we kind of had this thing where it was due for a rewrite i think i had already kind of sold folks that like it's time to address the tech debt file new project which is the dream right like you very rarely get that opportunity and this greenfield project that you know they the the rest of it was just being able to convince them like well look you know here's how it does the objective c in or off and you know basically at the end like i think my final sort of rip chord was like you know if all this goes sideways we can always call touch lab you know sound bite for you there it's like yeah we'll just call kevin and it'll be fine which is a perfect segue to my next question um did you use any of our of our resources initially to kind of get acquainted with the tech to implement that anything like that camp kit that was how it got started because especially in those early days i had no idea how to start a shared project so that was invaluable to us stately you know all the videos we found about the the memory model were from touch labs those were those were the the biggies so that pretty much covers it camp like we would have never figured any of this out without camp kit to be perfectly honest we're always glad to hear positive feedback about that i was also going to say it's it's great to hear we uh like you said at that point the initial setup was really difficult and it can still be tricky but the the wizards and such are a lot better now but at that point it was definitely tricky and that was our goal with camp kit was to say like here's a starting point like we're not necessarily you know it's not everything you'll need but it but it'll be something that you can jump off from my last question personally for me will be what's the future of kmm at um volley any any plans that you can share things that you're looking into i don't know that there's you know it's funny like volley is growing enough that we like now have uh for the first time a pr firm that has like prepped us like don't say anything you don't have to uh so i don't think we have anything super interesting like to announce but like obviously the more of our products that succeed and start to kind of like grow into these like mobile companion apps you know like that you know like i will be hiring those roles and like i'm i remain a big fan of kmm and of kotlin and so i think you know like josh said we're hoping that the things that we've built and learned and done over on volley fm is going to make it really easy and fast to be able to replicate it and kind of create these very efficient reusable patterns on our other apps and i'm i'm also very hopeful about reusable components across our different apps i think we've laid out a lot of great groundwork for that awesome yeah i think that's uh that's a great place to kind of conclude i want to thank you both for your time and for kind of sharing all the lessons and insights you've kind of picked up along the way and it's really exciting to hear that the technology is so it's so positively received at volley and we're excited to kind of see where maybe you know some of the some of the work you're doing on the open source front how that matures and it kind of takes off as well so again thank you for your time and with that thanks to the touch live team as well and that will conclude our touch lecture episode with volley you

Channel: Touchlab

Views: 311

Rating: 4.4285712 out of 5

Keywords: android, development, mobile, ios, kotlin, kotlin multiplatform, cross platform, xamarin, cordova, phonegap, react native, flutter

Id: 4Q9UVU14Cks

Length: 33min 27sec (2007 seconds)

Published: Thu May 13 2021