(Code) Sharing is caring
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Heine, Tobias
Dane, Said Tahsin
In this talk we will deep dive into Kotlin multiplatform projects. We will cover why you should consider using it, compare it with other cross-platform solutions. how it is different than regular Kotlin projects and how to use it to level up your product development. We will show a simple project that includes Android, iOS, Web (React) and Desktop clients. Then we will demonstrate how Kotlin makes it easier to inject platform specific logic into shared code. We will conclude the talk with limitations and challenges we faced during development.
 Welcome to our talk. We will talk about today close cross platforms and specifically about Kotlin multi-platform and Actually, how you would make use of Kotlin to like also change your architecture a little bit I we will talk about architecture as well And how Kotlin is different than than the others basically Yeah, exactly. So my name is Toby. This is Tassin. I work at Novoda in Berlin, which is our agency slash Consultancy and I seen at Wayfair And yeah, we had the chance why we were working together at Novoda to spike in Kotlin multi-platform And we want to share our learnings with everyone here and Yeah, so now you know us now. We want to know you a bit better. So we are really curious Who's writing Kotlin code in general first? Which is like almost everybody an obvious question The Android conference, but who's also writing Kotlin code for non-android use cases like for the back end Okay, quite a lot of people Do we even have some iOS developers here? I know that sounds really weird, but yeah, awesome Great, but like I ask people like written writing Kotlin in I not yet. Okay, cool. Yeah so we will talk about that too and We will we don't have like too too many code, but we have a little bit code and It may seem familiar with Swift, but it is actually Kotlin Yeah, just Yeah, so we want to start this talk with a really bold statement So the technology we talk about Kotlin multi-platform native This will be a real game changer for the collaboration between Android and iOS people at least we think so So stay tuned So let's talk about why do we even share code, right? So the first thing comes to mind is the cost basically, you know when you think about not even sharing code multi-cross platform, but like, you know Everybody uses lots of lots of library. You must have heard about like the term called like do not invent the wheel Right, that's basically actually sharing code. We do libraries frameworks to to you know share share the knowledge as much as possible then that is because of the cost because Yeah, you do essentially write less code And then means less less cost Yeah, but it's not supposed to cost at least not just about them. It's also about the quality I mean, we all know the batches on our famous GitHub libraries where they say X percent test coverage So as soon as we start to share our code with others, we really make sure this is good code, right? And yeah in the community or for one platform we see also there is a lot of co-chairing, right? I mean just imagine all the frameworks all the libraries we use what would we do without the community that that comes up with them, but So this is for the platforms, but what if we leave this layer? What if we look at our organization at the different layers we have there where we have the mobile team the web front and the back-end team? unfortunately, there's not too much co-chairing there and Why is that? The reason is obvious. It's because of the different technology stacks We have the back-end team is working on go to JavaScript or the front-end team is working with JavaScript with the latest frameworks there and The iOS people are working with Swift Objective C. We are working with Kotlin and Java and there have been a couple of Yeah attempts to introduce some sharing like what we heard this morning using a JavaScript runtime or using J2 Objective C But it's hard Obviously and therefore there have been a couple of Yeah frameworks lately or also recent. Yeah, yeah, like everybody like trying to solve this Problem obviously like there has been like, you know when you look at phone gap, etc It's like really old projects and like recently The more solid project that I I can say is like react native and flutter is getting really famous and then cut the multi-platform is just experimental is like in a New born basically is in the field Yeah, so like we will not compare them a lot, but we feel like Kotlin is taking like different approach basically similar to what Jake Burton Had in this morning. So he explained it very well. I think but we will not go further in into Comparison but see what Kotlin offers In this area basically. Yeah, but it's still important to understand. What's the difference actually so these tools Except of Kotlin in the middle they come basically from the platform So what they do is they try to abstract the platform for you away and they give you one API and you can use it and you come with your business logic and you use this and Does you this works for use cases right for games for I don't know use cases where the The platform is not that prominent where you have a huge or a big brand That makes sense but Otherwise, I mean the marketing Message write codes once with one of these tools This is this won't work in reality and the ones that have been using these tools that know that already and in the end What does it mean? We need platform or we need these framework experts We need the people that are able to work on react native But we still need the platform experts to add the tracking ads and all these kind of things So yeah, the question is what do we actually win here? Yeah, so the next thing is you know already talk about sharing code, but why is it so difficult? So like there's no silver bullet in this area yet. So everybody is comparing the the platforms like Mostly you have yeah, different Platforms frameworks working for different use cases for better So we will go into like more details. Why why this is actually difficult now Yeah, because Kotlin Multiplatform comes from the other side it basically gives you two utilities to just share your business logic and deal with the platform So sharing logic is actually hard and And sounds easy and why isn't everyone already doing this? One of the reasons especially on mobile is that Mobile projects have been traditionally started as site projects to enterprise web or desktop systems Where we have can look back to decades of experience and where we have software architects that Yeah work for the project and they basically have lots of experience and can look back to that and can use that and for mobile We basically we struggle a bit on the side. We recently Got support from the framework or from the SDK where with the architecture components and since the couple of years there's also lots of initiatives to Introduce all these patterns that are already known in VC MVP and be something on mobile Yeah, but it's still hard Yeah, so we will Talk about a story a little bit these two are super heroes in in in your company So one iOS and Android developers So they are working really hard to to build features right and then they are Working together, but also two separate teams, but suddenly they maybe it's one of you India audience you hear about the Kotlin multi-platform like really excited and go back to your desks and Try to use it basically like tomorrow, maybe or Thursday after the conference Yeah, and then well you look at your IDE at your Android studio X code you have your home view controller your base activity Open and you can scroll all the way down 3000 lines of code. I mean we have been all working with these kind of classes and especially if you stick to our Legacy code base you will still have to deal with such classes, right? Yeah, so if you are such person or if you work with such code base Then we have one good news at least as to see nor you mentioned Kotlin multi-platform is still experimental so you still have some time to clean your code base up and No worries. This is not gonna turn into an architecture talk, but on the other hand we think it's really important because if you are not able to Separate your business rules from your platform Then you won't be able to use this tool at all and that's what we really said Yeah, so as we said right now we will go into little bit architecture But just a little bit so to two bullet points that we will talk about basically About architecture that we can make use like just two principles that we can we can Apply to to make it easier make our lives easier. So this is a uncle uncle Bob is Yeah, he's really famous in software development He has like several books on clean codes. Some of you may like him or not, I don't know but the two quotes We will talk about today is like meeting really important. Yeah, so we are not here to advocate any MV something Pattern this one mean there have been other talks to introduce MVI or something. So this is really about the core fundamentals what is important here and One quote is the delivery mechanism is an annoying detail from him and what does he mean by that? He basically means if you're delivering your application to Android if you deliver your application to the web if you deliver your application as mobile application or another application Your application or your code shouldn't talk about that. That shouldn't be too prominent. This should be in detail What does it mean? It means you should have clear boundaries between your business rules and your platform and also maybe try to actually Deliver your platform or deliver your application to a different platform So one example that we have been doing for a specific project is that we took our business logic or use cases the clean architecture and we just replaced the whole view layer on Android and we replaced it with their interactive Commentline interface like a groovy shell and it was awesome And we could quickly test, you know some of the quirks of our business logic and it worked really well and In the end that helped and it also helped us to foresee actually how we should develop our application Yeah, the other one is the screaming architecture and So this is I think traditionally a problem in Android like even when you look at the sample projects provided by Google and traditionally when you go file new in Android Studio and create a new project even the Layout resources structure like it for it it it all starts with, you know, you have all your activities in activity package And fragments in fragment package whatever So ideally this shouldn't be the case when you look at your architecture packaging structure It shouldn't talk about Android. It's it's if it is too involved with Android It is bad it's it's too coupled with the platform. It's really Impossible like yesterday. I think it was a good example at the panel You're talking about Android cars suddenly even though it is Android same platform You cannot use it with the car when it's not super easy to just publish your application Because it's talk about too much It screams basically a lot about your platform when even when you look at the architecture Basically what you need to do is just your your architecture Your architecture Should be platform agnostic, right and then on top on top of that You you will apply Your Android platform or then you can apply the same architecture into different platforms Yeah, yeah, basically good enough of this. Let's jump into the more interesting topic Kotlin multi-platform So we will show some simplified code in the slides really simplified to just focus on what we think is important and To give you a little introduction into the tool itself So Kotlin multi-platform is something that enables you to deploy Kotlin code onto to multiple platforms It uses under the hood Kotlin JS to be able to deploy it to JavaScript to like where we don't have a virtual machine it uses Kotlin native to To deploy it to the native platforms like iOS for example or any other embedded system and And it's all backed by a gradle. Thanks for thankfully and that helps a lot to integrate it also into our existing projects So this is as we spoke about Kotlin multi-platform Encourages you to share your business logic and to do so you need a common a common module and to do so you need to apply Kotlin platform common plug-in and with this plug-in you can basically have a gradle module and with this gradle model You can share your business logic you put it in and obviously you can just have dependencies to pure Kotlin code, right? So you cannot use RX Java you can use your retrofit You cannot use Mojito you can actually when you start doing this you find out that you can't use a lot And this is also one of the downsides so far Yeah, yeah, when I when applicable they are putting more and more into the common part But basically yeah, you cannot Access any JDK methods any Android methods. It's not like when you integrate Kotlin into an Android project It's much yeah limited So this example There's a common JVM module. So what does it mean? It is a platform module which contains the JVM bindings that are Expected by your common module and in this scenario we have two common modules We have data and IO and within this gradle module. We're gonna supply the The platform bindings so the implementations that will work on the JVM for your project or for your code and in here we can now use all the JVM dependencies to fulfill this contract and One of the latest features that had been added to Kotlin multi-file Tom was the ability to actually have to expected by Dependency so previously there was just one allowed and with two now This means obviously that the on the door to the to multi to multi model approaches or multi model architectures and structures are now is open and Ready to be used Yeah, so here we see an example of Desktop client so we had like when we are working on this project. We had no idea Oh, but it was really nice to see somebody open a pull request after our blog post By the way, we will share the sample project Yeah, that's the discord is from there, but it's a desk desktop client. It was really easy to review It was really simple pull request But here you can see its application is means the apply plugin applications the desktop application But just use before this slide we show the common JVM here since This is just one option. So here in the desktop client. We use the common JVM on Android as well We will use the common JVM Yeah, and then and then otherwise we have like other dependencies. We would need in a desktop client. Yeah, that's it So let's say you don't have a new project for example You don't need a common JVM module because you just have an Android client and you can skip that part And this was also included of the last release of Kotlin You can just have a Kotlin Android platform, right? So you from there you can directly declare your expected Common module dependencies so you can actually skip the common JVM module if you don't need that Yeah, so it's getting more flexible and flexible With the recent versions So this is the screenshots from the official documentation It's really good like and simple examples and here we have like on top of the Kotlin language if you're familiar with it like we only have expect an actual Keywords they are like language constructs, but at the same time they are they are enabled when you apply the appropriate plugins So expect is in the common It's like a partial class I think Then you don't have an implementation there but you expect that implementation to be somewhere else in I like in an iOS project or like Neatly coordinated project or or in a Java project and on the other hand you have the in the implementation side The actual keyword so and then you can go ahead and have some actual fun there So things to notice here like if you Think about traditional Java interfaces essentially when you have an interface or an abstract class the implementation Needs to have a different name So here you see the same names foo and foo that's really make things Much much easier, so you don't have to invent names for your different different platforms. It's if it is full It's also full in iOS That's that may that makes it really easy and if you look at the first one again We have the constructor there, you know It's it's not an implemented class, but it still has constructor which is gonna be in The actual constructor will be in the implementation But what this gives us is that even in the common module you can instantiate this this come like common has no idea about the Implementation of this but still can instantiate as long as it can provide a string And the other nice thing is that the the project The plugins and the compilation forces you to have implementation So one of the problems with react native was that you know the bindings and between Android and iOS people are falling behind Etc. Right here you are forced to implement as long as you change the expect clause You have to have the implementation in both platforms Which is which Makes lots of things easier It also means that you don't have to like on your platform or do have to construct your whole application Because usually you have to do this right because you just in your common part You just have access to the abstractions and then in the specific use cases you need to build it all together Here is different you can basically in your common called Constructor objects that you expect by the platform modules and then on the platform you can basically just use these dependencies And they're used them as you want even me Yeah, we will talk about that later So let's talk a bit about the example that we did so We chose the game of life to implement example for a coffee multipurpose project Why that the game of life is on simulation for a cell reproduction It's used in a lot of coding car to us for a lot of coding exercises There are simple rules. So we thought it might be a good example Also, we to be honest, we just had limited time to deal with that. So we Yeah, we spike that and what we did is we implemented react front end We implemented an Android client and Yeah, let's have a look at the code So this is the only expect the class we have In the in the common module so when you think about like a multi-platform Trading is is one of the difficult things It's it's a game. We are developing a game and it has a game loop, you know every interval It has an iteration to redraw the board basically This is an asynchronous behavior. So we kind of had this simple abstraction over that so it's just a class without even a custom constructor So you start with and you give the interval and then you get the callback In on think on tick function and then you do your your thing there and then you can stop and check if it is looping So and the implementations we will see the implementations in the JVM implementation. We use direct Java, you know, a It was the most familiar thing we had at the moment. So just flowable that interval And then as you can see we have an additional private variable It's game loop and then like stopping is just disposing the game loop and then is looping is just an null check or it's just a sample implementation All right, and in JavaScript, you know, we don't have much JavaScript knowledge at all But it looks similar right we again have the game look game loop variable And then we looked at it and then nice thing is that with with Kotlin When you have and you're in the actual implementation, you can use the platform Classes it has really like Kotlin's focus is the interoperable Operability, right? So just like it's really good with Java. It's much better with Java But it's also really good with other other platforms. So we are using we found this window object There and then it has this set set interval. This is a window object from the browser package So just an interval again and then the rest is very similar yeah And yeah, this is the Kotlin Kotlin native implementation for the Android for the iOS client and That looks similar to the other ones right here. We have the game loop we instantiate it and what we use here is NS Timer and NS date now for a couple of you this might look familiar this is these are basically classes that come from the iOS SDK and Now the question is well, how that how does it work because this is the Kotlin code and now we are calling basically iOS dependency dependencies and again, this is possible through the interability feature that Kotlin native has and the Kotlin native compiler is actually shipped with Bindings for almost the whole iOS SDK that that's really interesting and in the end This also means nowadays you could write your iOS applications just in Kotlin, which is crazy. That sounds great and Let's have a look at the gradle plugin for Kotlin native since this is a bit more interesting So this has a slightly different plugin. It's called Conan Kotlin native and here we need to specify our targets And in this example we targeted the iPhone and the iPhone simulator and we had to specify some artifacts The framework closure defines the framework that will be produced by the compiler And this is an Xcode framework and we can then later on included into an existing iOS project for example and this is also interesting to mention that here There's basically a hard bridge between gradle and iOS since on the iOS IDs app code Xcode They don't know gradle. They don't know how to work with gradle There's also basically the hard line. So you need to manually or through any other mechanism import then the Framework dependency and framework is like a library in iOS Exactly and on other side when you have a look down on the dependencies You still reference your common module as you would do it for the For the other platform modules and speaking about writing iOS applications in Kotlin code which is the JetBrains IDE Meanwhile has also a plugin that allows you to create a single view app with Kotlin native framework and Yeah, you can basically have your view controller written in Kotlin You can do it But a question is should you do it and when we now look back to one of the first slides we showed Kotlin multi-platform Kotlin native these are tools to share business logic now We are here on the view controller level now. We are back on the platform and And yeah, the root of something should be leave the platform concerns to the platform experts and focus rather at least from our perspective Focus on sharing the business rules So we are going towards end Let's talk about what did we share at the end, you know, we only talk we only showed you about the expected class and the actual implementations, but there's a whole a lot of like the usage of these Basically, we have the models and the presenter and the views, right? It starts with the entities. So if you if you remember Remember the game you have the board and then we have the state We have the cells like cells and then cells are either alive or dead so this is the entities like completely in Kotlin because it's like Really? Data objects so then on top of that this did we have the model it's Like most of our business logic leaves there which is like Transforming the board into the next stage. This is also like completely in Kotlin And where we don't really depend on any special? JDK APIs or whatever because like Also, I have to admit the Although it's a nothing grown is application which was really good to work with to see Some somewhat more close to real life applications, but at the same time is relatively simple But it was really nice to see that we can encompass encapsulate the whole business logic of the models Inside the common module and then here like the good thing is that We can instantiate The game loop inside here, right and then and then we have the presentation level We were like hesitant whether what we should do but like, you know, the UIs were like even though not 100% the same actually like web UI has the Selection in the same page, but the Android and IOS has dialogues Etc. But like still this is the implementation detail of the view. So presentation logic was even the same So we kind of abstracted the life cycle All aspects of the things like Android IOS and React so it was not really hard So we were able to do that and then after doing that we were able to even share the presentation layer And then of course we have tests for these and then a nice thing about the test is that you run the test once and Then it runs three times like in our case three times But whatever client you have it runs as many as that So the only thing left is the views which we call passive views. They don't really have logic at all They just get to get the state and then their job is to display it and then you could even like Have really few number of code there with data binding and like I told you about this pull request Where the guy was adding the pull adding the desktop client there there he had only one if statement Which was great to see and it was even though we had no idea it was really easy to review It was really straightforward and then yeah, we basically merged it really quickly Yes, so one rule of thumb could be or does it something that's really experienced is you can basically share everything Where you write unit tests for all the can be shared? So yeah, what's missing? So last time we talk it was like really Not much libraries out there when we were both working with this project as well. So there are like lots of projects coming up So Kevin here at droidcon as well is talking about Kotlin multi-platform in the enterprise slot Here is simply a worked on a school light abstraction for Kotlin multi-platform, which is like amazing There's Reagan Jake Burton is working on that. You are not supposed to use it But it's it's a it's a reactive streams abstraction for multi-platform projects Just experimenting and yeah, there are a couple of libraries and yeah core teams are interesting Jake like JetBrains It is working on many things at the same time. So they are they are bringing core teams eventually to Ios and native platform as well, but yeah, very slowly at the moment Exactly and we need these tools because threading memory management. It's different on native platforms You cannot rely on things that we are used to from the JVM. So we need these these tools So yeah, what's missing from our point of view? We need a better multi-threading support in our example We did multi-threading on the Platform Ideally we would have multi-threading logic in the common model You could obviously do this by obstructing it all away But it would be good to have as to see mentioned something like core routines being available So we could use just fall back to this one We are also a heavily user of Reactive approaches and reactive patterns and use RX Java for that. So something like that would be also great I'm caching there's just before drug-converting. There has been this SQL light library Announced and that works on Kotlin native and Kotlin multi-platform some better testing support There's no mocking framework. So Mojito doesn't work and And yeah, some some better SDK integration So here are our references The code we just showed some of it so open source so you can have a look at The link is long. You don't have to memorize it, but we will share the slides. I think you can click on it Yeah, and that's it Thanks
 Welcome to our talk. We will talk about today  close cross platforms and specifically about Kotlin multi-platform and  Actually, how you would make use of Kotlin to like also change your architecture a little bit  I we will talk about architecture as well  And how Kotlin is different than than the others basically  Yeah, exactly. So my name is Toby. This is Tassin. I work at Novoda in Berlin, which is our agency slash  Consultancy and I seen at Wayfair  And yeah, we had the chance why we were working together at Novoda to spike in Kotlin multi-platform  And we want to share our learnings with everyone here and  Yeah, so now you know us now. We want to know you a bit better. So we are really curious  Who's writing Kotlin code in general first?  Which is like almost everybody an obvious question  The Android conference, but who's also writing Kotlin code for non-android use cases like for the back end  Okay, quite a lot of people  Do we even have some iOS developers here? I know that sounds really weird, but yeah, awesome  Great, but like I ask people like written writing Kotlin in I not yet. Okay, cool. Yeah  so we will talk about that too and  We will we don't have like too too many code, but we have a little bit code and  It may seem familiar with Swift, but it is actually Kotlin  Yeah, just  Yeah, so we want to start this talk with a really bold statement  So the technology we talk about Kotlin multi-platform native  This will be a real game changer for the collaboration between Android and iOS people at least we think so  So stay tuned  So let's talk about why do we even share code, right?  So the first thing comes to mind is the cost basically, you know  when you think about not even sharing code multi-cross platform, but like, you know  Everybody uses lots of lots of library. You must have heard about like the term called like do not invent the wheel  Right, that's basically actually sharing code. We do libraries frameworks to to you know share share the knowledge  as much as possible then that is because of the cost because  Yeah, you do essentially write less code  And then means less less cost  Yeah, but it's not supposed to cost at least not just about them. It's also about the quality  I mean, we all know the batches on our famous GitHub libraries where they say X percent test coverage  So as soon as we start to share our code with others, we really make sure this is good code, right?  And yeah in the community or for one platform we see also there is a lot of co-chairing, right?  I mean just imagine all the frameworks all the libraries we use what would we do without the community that  that comes up with them, but  So this is for the platforms, but what if we leave this layer?  What if we look at our organization at the different layers we have there where we have the mobile team the web front and the back-end team?  unfortunately, there's not too much co-chairing there and  Why is that?  The reason is obvious. It's because of the different technology stacks  We have the back-end team is working on go to JavaScript or the front-end team is working with JavaScript with the latest frameworks there and  The iOS people are working with Swift Objective C. We are working with Kotlin and Java and there have been a couple of  Yeah attempts to introduce some sharing like what we heard this morning using a JavaScript runtime or using J2 Objective C  But it's hard  Obviously and therefore there have been a couple of  Yeah frameworks lately or also recent. Yeah, yeah, like everybody like trying to solve this  Problem obviously like there has been like, you know when you look at phone gap, etc  It's like really old projects and like recently  The more solid project that I I can say is like react native and flutter is  getting really famous and then cut the multi-platform is just experimental is like  in a  New born basically is in the field  Yeah, so like we will not compare them a lot, but we feel like Kotlin is  taking  like  different approach  basically similar to what  Jake Burton  Had in this morning. So he explained it very well. I think but we will not go further in  into  Comparison but see what Kotlin offers  In this area basically. Yeah, but it's still important to understand. What's the difference actually so these tools  Except of Kotlin in the middle they come basically from the platform  So what they do is they try to abstract the platform for you away and they give you one API and you can use it and you  come with your  business logic and you use this and  Does you this works for use cases right for games for I don't know use cases where the  The platform is not that prominent where you have a huge or a big brand  That makes sense  but  Otherwise, I mean the marketing  Message write codes once with one of these tools  This is this won't work in reality and the ones that have been using these tools that know that already and in the end  What does it mean? We need platform or we need these framework experts  We need the people that are able to work on react native  But we still need the platform experts to add the tracking ads and all these kind of things  So yeah, the question is what do we actually win here?  Yeah, so the next thing is you know already talk about sharing code, but why is it so difficult?  So like there's no silver bullet in this area yet. So everybody is comparing the the platforms like  Mostly you have  yeah, different  Platforms frameworks working for different use cases for better  So we will go into like more details. Why why this is actually difficult now  Yeah, because Kotlin  Multiplatform comes from the other side it basically gives you two utilities to just share your business logic and  deal with the platform  So sharing logic is actually hard and  And sounds easy and why isn't everyone already doing this?  One of the reasons especially on mobile is that  Mobile projects have been traditionally started as site projects to enterprise web or desktop systems  Where we have can look back to decades of experience and where we have software architects that  Yeah work for the project and they basically have lots of experience and can look back to that and can use that and for mobile  We basically we struggle a bit on the side. We recently  Got support from the framework or from the SDK where with the architecture components and since the couple of years  there's also lots of initiatives to  Introduce all these patterns that are already known in VC MVP and be something on mobile  Yeah, but it's still hard  Yeah, so we will  Talk about a story a little bit these two are super heroes in in in your company  So one iOS and Android  developers  So they are working really hard to  to build features right and then  they are  Working together, but also two separate teams, but suddenly they  maybe it's one of you  India audience you hear about the Kotlin multi-platform like really excited and go back to your desks and  Try to use it basically like tomorrow, maybe or Thursday after the conference  Yeah, and then well you look at your IDE at your Android studio X code  you have your home view controller your  base activity  Open and you can scroll all the way down  3000 lines of code. I mean we have been all working with these kind of classes and especially if you stick to our  Legacy code base you will still have to deal with such classes, right?  Yeah, so if you are such person or if you work with such code base  Then we have one good news at least as to see nor you mentioned Kotlin multi-platform is still experimental  so you still have some time to clean your code base up and  No worries. This is not gonna turn into an architecture talk, but on the other hand we think it's really important  because if you are not able to  Separate your business rules from your platform  Then you won't be able to use this tool at all and that's what we really said  Yeah, so as we said right now we will go into little bit architecture  But just a little bit so to two bullet points that we will talk about basically  About architecture that we can make use like just two principles that we can  we can  Apply to to make it easier make our lives easier. So this is a uncle uncle Bob is  Yeah, he's really famous in software development  He has like several books on clean codes. Some of you may  like him or not, I don't know but the two quotes  We will talk about today is like meeting really important. Yeah, so we are not here to advocate any MV something  Pattern this one mean there have been other talks to introduce MVI or something. So this is really about  the core fundamentals what is important here and  One quote is the delivery mechanism is an annoying detail from him and what does he mean by that?  He basically means if you're delivering your application to Android if you deliver your application to the web if you deliver your application as mobile application or  another application  Your application or your code shouldn't talk about that. That shouldn't be too prominent. This should be in detail  What does it mean?  It means you should have clear boundaries between your business rules and your platform and also maybe try to actually  Deliver your platform or deliver your application to a different platform  So one example that we have been doing for a specific project is that we  took our business logic or use cases  the clean architecture and we just replaced the whole view layer on Android and we replaced it with their interactive  Commentline interface like a groovy shell and it was awesome  And we could quickly test, you know some of the quirks of our business logic and it worked really well and  In the end that helped and it also helped us to foresee actually how we should develop our application  Yeah, the other one is the screaming architecture and  So this is I think traditionally a problem in Android like even when you look at the sample projects provided  by Google and traditionally when you go  file new in Android Studio and create a new project even the  Layout resources structure like it for it it it all starts with, you know, you have all your activities in activity package  And fragments in fragment package whatever  So ideally this shouldn't be the case when you look at your architecture packaging structure  It shouldn't talk about Android. It's it's if it is too involved with Android  It is bad it's it's too coupled with the platform. It's really  Impossible like yesterday. I think it was a good example at the panel  You're talking about Android cars suddenly even though it is Android same platform  You cannot use it with the car when it's not super easy to just publish your application  Because it's talk about too much  It screams basically a lot about your platform when even when you look at the architecture  Basically what you need to do is just your your architecture  Your architecture  Should be platform agnostic, right and then on top on top of that  You you will apply  Your Android platform or then you can apply the same architecture into different platforms  Yeah, yeah, basically good enough of this. Let's jump into the more interesting topic Kotlin multi-platform  So we will show some simplified code in the slides really simplified to just focus on what we think is important and  To give you a little introduction into the tool itself  So Kotlin multi-platform is something that enables you to deploy Kotlin code onto to multiple platforms  It uses under the hood Kotlin JS to be able to deploy it to JavaScript to like where we don't have a virtual machine  it uses Kotlin native to  To deploy it to the native platforms like iOS for example or any other embedded system and  And it's all backed by a gradle. Thanks for thankfully and that helps a lot to integrate it also into our  existing projects  So this is as we spoke about Kotlin multi-platform  Encourages you to share your business logic and to do so you need a common a common module and  to do so you need to apply  Kotlin platform common plug-in and with this plug-in you can basically have a gradle module and with this gradle model  You can share your business logic you put it in and obviously you can just have  dependencies to pure Kotlin code, right? So you cannot use RX Java you can use your retrofit  You cannot use Mojito you can actually when you start doing this you find out that you can't use a lot  And this is also one of the downsides so far  Yeah, yeah, when I when applicable they are putting more and more into the common part  But basically yeah, you cannot  Access any JDK methods any Android methods. It's not like when you integrate Kotlin into an Android project  It's much yeah limited  So this example  There's a common JVM module. So what does it mean?  It is a platform module which contains the JVM bindings that are  Expected by your common module and in this scenario we have two common modules  We have data and IO and within this gradle module. We're gonna  supply the  The platform bindings so the implementations that will work on the JVM for your project or for your code and in here  we can now use all the JVM dependencies to fulfill this contract and  One of the latest features that had been added to Kotlin multi-file  Tom was the ability to actually have to expected by  Dependency so previously there was just one allowed and with two now  This means obviously that the on the door to the to multi to multi model approaches or multi model architectures and  structures are now is open and  Ready to be used  Yeah, so here we see an example of  Desktop client so we had like when we are working on this project. We had no idea  Oh, but it was really nice to see somebody open a pull request after our blog post  By the way, we will share the sample project  Yeah, that's the discord is from there, but it's a desk desktop client. It was really easy to review  It was really simple pull request  But here you can see its application is means the apply plugin applications the desktop application  But just use before this slide we show the common JVM here since  This is just one option. So here in the desktop client. We use the common JVM on Android as well  We will use the common JVM  Yeah, and then and then otherwise we have like other dependencies. We would need in a desktop client. Yeah, that's it  So let's say you don't have a new project for example  You don't need a common JVM module because you just have an Android client and you can skip that part  And this was also included of the last release of Kotlin  You can just have a Kotlin Android platform, right? So you from there you can directly  declare your expected  Common module dependencies so you can actually skip the common JVM module if you don't need that  Yeah, so it's getting more flexible and flexible  With the recent versions  So this is the screenshots from the official documentation  It's really good like and simple examples and here we have like  on top of the  Kotlin language if you're familiar with it like we only have expect an actual  Keywords they are like language constructs, but at the same time they are they are enabled when you apply the appropriate plugins  So expect is in the common  It's like a partial class I think  Then you don't have an implementation there  but you expect that implementation to be somewhere else in I like  in an iOS project or like  Neatly coordinated project or or in a Java project and on the other hand you have the in the implementation side  The actual keyword so and then you can go ahead and have some actual fun there  So  things to notice here like if you  Think about traditional Java interfaces essentially when you have an interface or an abstract class the implementation  Needs to have a different name  So here you see the same names foo and foo that's really make things  Much much easier, so you don't have to invent names for your different different platforms. It's if it is full  It's also full in iOS  That's that may that makes it really easy and if you look at the first one again  We have the constructor there, you know  It's it's not an implemented class, but it still has constructor which is gonna be in  The actual constructor will be in the implementation  But what this gives us is that even in the common module you can instantiate this this come like common has no idea about the  Implementation of this but still can instantiate as long as it can provide a string  And the other nice thing is that the the project  The plugins and the compilation forces you to have implementation  So one of the problems with react native was that you know the bindings and between Android and iOS people are falling behind  Etc. Right here you are forced to implement as long as you change the expect clause  You have to have the implementation in both platforms  Which is which  Makes lots of things easier  It also means that you don't have to like on your platform or do have to construct your whole application  Because usually you have to do this right because you just in your common part  You just have access to the abstractions and then in the specific use cases you need to build it all together  Here is different you can basically in your common called  Constructor objects that you expect by the platform modules and then on the platform you can basically just use these dependencies  And they're used them as you want even me  Yeah, we will talk about that later  So let's talk a bit about the example that we did  so  We chose the game of life to implement  example for a coffee multipurpose project  Why that the game of life is on simulation for a cell reproduction  It's used in a lot of coding car to us for a lot of coding exercises  There are simple rules. So we thought it might be a good example  Also, we to be honest, we just had limited time to deal with that. So we  Yeah, we spike that and what we did is we implemented react front end  We implemented an Android client and  Yeah, let's have a look at the code  So this is the only expect the class we have  In the in the common module so when you think about like  a multi-platform  Trading is is one of the difficult things  It's it's a game. We are developing a game and it has a game loop, you know every interval  It has an iteration to redraw the board basically  This is an asynchronous behavior. So we kind of had this simple  abstraction over that so it's just a class without even a custom constructor  So you start with and you give the interval and then you get the callback  In on think on tick function and then you do your your thing there and then you can stop and check if it is looping  So and the implementations we will see the implementations in the JVM implementation. We use direct Java, you know, a  It was the most familiar thing we had at the moment. So just flowable that interval  And then as you can see we have an additional private variable  It's game loop and then like stopping is just disposing the game loop and then is looping is just an null check or it's just a  sample implementation  All right, and in JavaScript, you know, we don't have much JavaScript knowledge at all  But it looks similar right we again have the game look game loop variable  And then we looked at it and then nice thing is that with with Kotlin  When you have and you're in the actual implementation, you can use the platform  Classes it has really like Kotlin's focus is the interoperable  Operability, right? So just like it's really good with Java. It's much better with Java  But it's also really good with other other platforms. So we are using we found this window object  There and then it has this set set interval. This is a window object from the browser package  So just an interval again and then the rest is very similar  yeah  And yeah, this is the Kotlin Kotlin native implementation for the Android for the iOS client and  That looks similar to the other ones right here. We have the game loop we instantiate it and what we use here is NS  Timer and NS date now for a couple of you this might look familiar  this is  these are basically  classes that come from the  iOS SDK and  Now the question is well, how that how does it work because this is the Kotlin code and now we are calling basically  iOS dependency  dependencies and again, this is possible through the interability feature that  Kotlin native has and  the  Kotlin native compiler is actually shipped with  Bindings for almost the whole iOS SDK that that's really interesting and in the end  This also means nowadays you could write your iOS applications just in Kotlin, which is crazy. That sounds great  and  Let's have a look at the gradle plugin for Kotlin native since this is a bit more interesting  So this has a slightly different plugin. It's called Conan Kotlin native and here we need to specify our targets  And in this example we targeted the iPhone and the iPhone simulator and we had to specify some artifacts  The framework closure defines the framework that will be produced by the compiler  And this is an Xcode framework and we can then later on  included into an existing iOS project for example and this is also interesting to mention that here  There's basically a hard bridge between gradle and iOS since on the iOS IDs app code Xcode  They don't know gradle. They don't know how to work with gradle  There's also basically the hard line. So you need to manually or through any other mechanism  import then the  Framework dependency and framework is like a library in iOS  Exactly and on other side when you have a look down on the dependencies  You still reference your common module as you would do it for the  For the other platform modules and  speaking about  writing iOS applications in Kotlin  code which is the JetBrains IDE  Meanwhile has also a plugin that allows you to create a single view app with Kotlin native framework and  Yeah, you can basically have your view controller written in Kotlin  You can do it  But a question is should you do it and when we now look back to one of the first slides we showed  Kotlin multi-platform Kotlin native these are tools to share business logic now  We are here on the view controller level now. We are back on the platform and  And yeah, the root of something should be leave the platform concerns to the platform experts and focus rather at least from our perspective  Focus on sharing the business rules  So we are going towards end  Let's talk about what did we share at the end, you know, we only talk we only showed you about  the expected class and the actual implementations, but there's a whole a lot of like the usage of these  Basically, we have the models and the presenter and the views, right? It starts with the entities. So  if you if you remember  Remember the game you have the board and then we have the state  We have the cells like cells and then cells are either alive or dead  so this is the entities like completely in Kotlin because it's like  Really?  Data objects so then on top of that this did we have the model  it's  Like most of our business logic leaves there which is like  Transforming the board into the next stage. This is also like completely in Kotlin  And where we don't really depend on any special?  JDK  APIs or whatever because like  Also, I have to admit the  Although it's a nothing grown is application which was really good to work with to see  Some somewhat more close to real life applications, but at the same time is relatively simple  But it was really nice to see that we can encompass encapsulate  the whole  business logic of the models  Inside the common module and then here like the good thing is that  We can instantiate  The game loop inside here, right and then and then we have the presentation level  We were like hesitant whether what we should do but like, you know, the UIs were like even though not  100% the same actually like web UI has the  Selection in the same page, but the Android and IOS has dialogues  Etc. But like still this is the implementation detail of the view. So presentation logic was even the same  So we kind of abstracted the life cycle  All aspects of the things like Android IOS and React so it was not really hard  So we were able to do that and then after doing that we were able to even share the presentation layer  And then of course we have tests for these and then a nice thing about the test is that you run the test once and  Then it runs three times like in our case three times  But whatever client you have it runs as many as that  So the only thing left is the views which we call passive views. They don't really have logic at all  They just get to get the state and then their job is to display it and then you could even like  Have really few number of code there with data binding and like I told you about this pull request  Where the guy was adding the pull adding the desktop client there there he had only one if statement  Which was great to see and it was even though we had no idea it was really easy to review  It was really straightforward and then yeah, we basically merged it really quickly  Yes, so one rule of thumb could be or does it something that's really experienced is you can basically share everything  Where you write unit tests for all the can be shared? So yeah, what's missing?  So last time we talk it was like really  Not much libraries out there when we were both working with this project as well. So there are like lots of  projects coming up  So Kevin here at droidcon as well is talking about Kotlin multi-platform in the enterprise  slot  Here is simply a worked on a school light abstraction for Kotlin multi-platform, which is like amazing  There's Reagan Jake Burton is working on that. You are not supposed to use it  But it's it's a it's a reactive streams abstraction for multi-platform projects  Just experimenting and yeah, there are a couple of libraries and yeah core teams are interesting Jake like JetBrains  It is working on many things at the same time. So they are they are  bringing core teams eventually to  Ios and native platform as well, but yeah, very slowly at the moment  Exactly and we need these tools because threading memory management. It's different on native platforms  You cannot rely on things that we are used to from the JVM. So we need these these tools  So yeah, what's missing from our point of view? We need a better multi-threading support in our example  We did multi-threading on the  Platform  Ideally we would have multi-threading logic in the common model  You could obviously do this by obstructing it all away  But it would be good to have as to see mentioned something like core routines being available  So we could use just fall back to this one  We are also a heavily user of  Reactive approaches and reactive patterns and use RX Java for that. So something like that would be also great  I'm caching there's just before drug-converting. There has been this SQL light library  Announced and that works on Kotlin native and Kotlin multi-platform some better testing support  There's no mocking framework. So Mojito doesn't work and  And yeah, some some better SDK integration  So here are our references  The code we just showed some of it so open source so you can have a look at  The link is long. You don't have to memorize it, but we will share the slides. I think you can click on it  Yeah, and that's it  Thanks
_DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_0_347.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_348_2927.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_2928_6215.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_6216_9515.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_9516_10595.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_10596_10715.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_10716_11183.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_11184_11531.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_11532_11651.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_11652_11999.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_12000_12119.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_12120_13235.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13236_13451.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13452_13499.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13500_13631.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13632_13703.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13704_13835.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13836_13883.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_13884_14015.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14016_14087.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14088_14267.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14268_14471.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14472_14519.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14520_14651.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14652_14723.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14724_14795.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_14796_15179.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_15180_15983.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_15984_18119.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_18120_20699.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_20700_22079.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_22080_23687.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_23688_27767.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_27768_32675.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_32676_33779.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_33780_35219.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_35220_37247.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_37248_38891.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_38892_40811.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_40812_41183.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_41184_41987.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_41988_49475.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_49476_50771.png _DCBerlin18_108_Heine_Code_Sharing_is_caring_DAY1_O7031dQu6-0_50772_51404.png