 So I'm going to talk about Android Jetpack Compost today. So before I start, I'm just going to start with a little bit about myself. I'm Yashaka. I work as an Android developer. And I've been an Android engineer for like past five years. I've been working a delivery hero in Singapore, and also a full-stack engineer. Some languages I like to play with. You must see on my stickers that I'm playing with Go Langry recently. So before I start with Android, I would like to know how many of you are actually aware of it? Have you guys even built an app? Build an app? OK, awesome. So I'm just going to give you a little bit intro about what is Android. Android is open-source, Linux software, a platform where you can run software for your mobile. Pretty simple, and a mouthful. In simple words, you can run apps, which you use every day on your phone. So today, specifically, I'm going to talk about the UI toolkits, the UI that the user are using, the UI that user are seeing every day, the animations, the motions. So how does that work in Android? So this is a little bit of history. I hope you guys can see it. Was it a book? So 2008 was when the first Android was started. They started with 1.0. This is the UI history. So they created only one kit in 10 years. And in that one kit, they updated it. They modified it. They made changes. They upgraded it, but they never changed it. Oh, because it's too much of work, obviously. So this was the first phone on the left, the Android phone. I don't know if you guys have ever used it or what. It's no one has used it. Quick configuration. It was one core Qualcomm, 528 megahertz, and 256 MB internal RAM. I don't think we can survive with that today. And this is what we are doing these days. So the UI kit was developed for this, this small little phone, and it's been used here in this one. So the changes they have made over the ages is made them possible to do this, but not in a better way. Because we started with one core. Now we have four. We have eight. We may be expanding it much more. So the community spoke, and the developers were like, dude, you need to change this. Because this is a bundle UI kit. They take one year to create a new Android, the one year to update the files for the developers. So the UI, if you know there's a bug in the app, if you know there's a bug in Android, you can make a wrapper, you can fix it, but you cannot actually fix it. Because one year later, Android comes and says, hey, we have fixed it. And we are like, nobody cares, because we've already done it. We have found a workaround. The UI kit was designed for 2008 devices, which we have already realized. It's still be not scalable. The classes that exist right now, they're in Java. They have close to 30,000 lines of code, which I think all of us know that is not a scalable product. And everything is tightly coupled. If you guys know what MVP, MVVM, you would know. These are the design patterns that we use. So why we needed a new toolkit? I'm not saying that what I'm going to talk about is the optimum toolkit. We're going to come back to that. But we do need a new toolkit for Android. So every platform release and the UI releases should be independent. They should not be linked together, because I should not wait for one year for my new UI. Because user want rapid things, user want, I mean, you would want an animation in your phone, right? You would want good motion. You would love it. Everybody would love it. And as a developer who wants to build apps, they would want these apps, these features in their phone. So I would want an unbounded. So they started with that, OK. So Android started with like, OK, we'll move some of the classes to the library. We'll not make it native. We'll make it helpful for you. But then they realized, OK, if you're doing that much work, if we're making that much effort, why not just make it a little better? So they came to jetpack compose. Coming back to that later, the reason one of that was, I don't think this is visible. So in Android, you have to have resources. And this is the amount of resources that you need to build an application that is production ready. You have different layouts, different configurations. Landscape, you have portrait, you have so many things. And this is just for mobile. You can have for TV, Android TV. You can have for multiple things. So this can go on. And obviously, there's VR also. Nowadays, you would want your app to be on VR. OK. So then they created this jetpack compose. So they said that we'll create something new, something fresh. And they don't use any Android native libraries. It's completely written in Kotlin. It's inspired by React. Some of you have used React. It's Flutter, UJS, these kind of languages. So quick benefits. I think it's a modern toolkit, simple UI design, written in Kotlin, so very less code. It has composable functions. We will definitely come back to that. Obviously, each composable defined by composable again will come back to that. It has separation of concerns. So each UI component is individual from the other one. Nothing is dependent on each other, unlike the previous Android toolkit we had. And obviously, it makes you rendering fast. That's the goal. That's the goal. We want you to view your app fast. Second of all, this is still under progress. Nothing is production ready. They're still working on it. And they're open for contributions. So yeah, that's it. This would be difficult to watch. So this is the button class that they had. This is a simple button that you see on your Android phone. You might not think this is a very simple thing. You just place a button where it has a 12,000 line code written for it in Java. And that's just 10 lines in the new toolkit. So this is what they moved to this one in the new toolkit. They didn't want. So why does the button need the text view? It extends the text view. Do you want your button to be selectable? Do you want your button to be changed? Can user select a button? Text selection? No, right? You just click on a button, right? So I don't think that's necessary. So they removed all this shit and moved to something cool. These are the same thing I think that's the XML one that's been previously used. So you just write, this is what the XML creates, a login button. And similarly, this two-liner creates the same thing. And this is our new toolkit, and that's the old one. A bit deeper. So composable, you can create your own UI element. So what I want to do is, this image in two text, I want to make this as a UI component. So I add the red composable on top of it, and that's it. This is my new UI component. And I can customize it as I like. I can change the height. I can change screen size. I can add constraints based on the layout that I'm using, landscape, portrait, anything. You don't have to worry about the resources anymore. Now the fun part is what's happening inside. So everything has a runtime compiler, right? Java has JRT, Android has ART. Compose basically has Compose runtime. So it's independent of any other tool that Android uses. It's not linked to Android device. It's not linked to anything. So it uses Compose runtime. So whenever you write Azure, it's composable on top of your function. Also, before we'll come back, I want to say that all UI is a function here. In Compose, every UI element is a function. So button is a function, text is a function, everything is a method. So it's very easy to implement. So most likely, using Kotlin as a functional language, it's been targeted at that. So whenever you write Azure Composable with your function, you will think that this is an annotation, and they're going to be annotation processing. But no, that's not it. This is not what it's doing. It's actually a Kotlin plugin. It defines a function in a certain way. So it's not processing anything. It's not an annotation. It's just saying that this function does a UI part. That's it. So internally, it uses data structures, which is obviously everything. So I don't know if you guys know about GapBuffers. GapBuffer is the data structure for text editor with node paths. What it does is always have extra space in his array, more than the elements that they always have. So that extra gap that caused the GapBuffers. So Composable uses those GapBuffers data structure to define and create components for Android readability. So when you write in your Compos, it converts to Android readable, Android Compose view, and then it is painted as a canvas to the UI. So internally, it does this, and a lot more complex, too many classes to be created. So coming to the drawbacks. So I said that this is not, we need a new toolkit, but I don't think this is the right one to go with. There are many controversies, because when you move from XML to a Java and a Kotlin code, people have been working here for 10 years. People have been working in Android for over a decade. So you're too comfortable, you don't want to move, right? You know, and you never even thought that there was a gap. You never even thought that there was a gap in creating a UI, right? You thought that, oh, this is the way to do it. This is how, I mean, this is how all the guidelines say, this is how the YouTube videos say. So this is the way to do it. But you never questioned it. So it's very difficult to change the mindset of people that we need a new toolkit, more than just creating one. So again, you don't need, so the problem is it's not standardized. People will definitely make business logic with the UI logic, which is so not recommended. And there are gonna be a lot of problems with the coding styles, all the other things. So Android currently has drag and drop. iOS has drag and drop, all these things, I think.net has drag and drop to view the views, but Compose does not. So I don't know what's the future for that, but I hopefully they do, because we would want to be more proactive about creating UI's. Okay, thank you guys.