Android Developer’s Guide To Compose

After spending 100+ hour with compose, thoroughly compose is the best ui toolkit that can teach programming and architectural patterns. Also when I tried to learn this tech I did some mistakes. In this article we’re going to talk about the mistakes, compose’s benefits and weaknesses and how we should think with compose.

Classic Way

First things first, the benefits of compose will improve your productivity and it’ll save you from unnecessary codes. Ok but how? I can say that compose has a unique thinking style that we had never use to when we are writing classic codes. How we were thinking before and what’s new now? In the classic way, we needed some extra idiot components. Thanks to all those idiot things we can show something on the UI. For example; binding adapters, custom views,styles,xml etc. I’m really asking to you what is binding adapter. What has happened to us that to compel it to use it? As if they weren’t enough, custom views entirely rubbish. When we are trying to show something on the UI we need to viewmodel and UI observation or setting bindings, then if you have binding adapters you need to set all things up then congratulations user can see something on the screen. Overall on the classic way (you should have think at least once) something went wrong therefore some helpers libraries and techs appeared like butterknife,view binding, data binding etc. Moreover have you ever asked yourself what is xml when you got into android development? Or I’m asking now what is XML? If we want to create an application another weird thing that we have to learn. But I’m surprised to say that, xml does justice to quick programming(We’ll talk about later). Anyway I don’t want to talk more about classic way :) But finally we can say we just need to 2 things to display something on the screen. First viewmodel, secondly ui component. Nothing more.

Compose Way

While I’m alive after talk about old way finally lets talk about the cute way. In fact, some problems stem from trying to creating a bridge with ui and viewmodel. What compose does is one language for all thing you don’t need to learn anything new and there is no bridge between ui and viewmodel. But basically there are many reason of why compose released. In this article I want to explain thinking in compose. Compose says you can show some data on the screen or not. The view can be shown or hidden. Say whatever you want all those things actually are called state. And when you try to develop a compose project you’ll understand the states goes down events goes up. That’s came with some idea. You shouldn’t set any child item specs (include states) from parent cause of single responsibility. And it helps to view managing.

‼️ Create View-Models It’s Free

Composables are views and views coming from their own viewmodels. Let’s think about we have a composable which is visibility depend a state. In this case we don’t need to prepare data that we’re going to send to view from parent view’s viewmodel. Create viewmodels inner composables. But this can lead problems in the future.

• For example what if we create every or necessary nested composables viewmodels? Our package hierarchy can be fill out. So my solution is make room between your package hierarchy guys is separate component package. Completely manageable.
• Second problem seems like everything looks fine but how we’can manage states, or states changed. The problem inhere is how viewmodels communicate with each other. Thanks to compose and kotlin we use higher order functions a lot. What did we say? Events up! So just use them :)
• You might think that we are creating states already. What if I send them all to nested composable and when I changed them it’s then listen with LaunchEffect at first look it seems okey. But it wont work. Cause of state :)

These advices help to improve your application performance, readability, manageability. Anyway before we finished, you should use use-cases. It’s help to process your data flow and write once run anywhere right? :) Maybe I can write an article about use-cases. :)

Why compose sucks?

Cause previewer is not working okey. Not even okey too bad. It’s not relevant with compose directly but previewer performance is so slow. That’s why xml better than compose. Also if you try to create a real project your project is going to fill with “@ExperimentalApı” annotations or something. I don’t know why we met with compose in 2020 but it is still almost an experimental tech.