view models feel wrong. I'm sorry. I liked the idea very much back in 2018. Finally, after years of doing freestyle MVC, there was some guidance bringing structure to my code base. I was trying to make it work ever since. I tried ARX style input-output mappings. I tried actor models, but it never felt quite right. And now I'm done. I'm breaking up with view models. I'm sure it's not about them; it's about me. Let me explain. When it comes to initializing or fetching data as soon as you enter a screen, do you prefer using view model.init or launch defect or event-triggered methods inside your composable functions? Which approach do you lean towards? I have seen this tweet and realized how annoyed I was by it. Not because of the Tweet; it's a great question, but with the fact that after all those years, such a simple question is still highly debated. There's something wrong with how we have been taught about view models. Here's the reply from the Fantastic Ian Lake: both are anti-patterns. Object creation shouldn't have

side effects and launch effect is going to rerun on each first composition of the screen. Instead, prefer cold flows that kick off their work when you start collecting them via collect as state with life cycle. And I agree, while you will never hear me use the word anti-pattern, both options really do not feel right and they have some kind of drawbacks. But the official documentation uses this extensively. So, what is wrong with view models? View models cannot provide easy and satisfying answers even for the most basic of questions: how to structure your code. The one thing I thought they will do for me. What do I mean by that? Clearly, view models provide some separation between your views and whatever you call business logic, sure. But how can this be split? One view model per screen or one view model per UI component? What even is a UI component? I don't know. Having one view model per UI component sounds nice in theory because it would allow for small independent pieces of code which we could just compose. But how should we connect those view models together? One view model per screen gets

rid of this complicated question of how to connect this parent-child view models together, but there are so many more questions to be answered. Should a view model just contain one state and presented as one state flow, or should that view model contain multiple states and multiple state flows? Browsing through Google's official samples and guidelines seemingly answers this with one state class, one state flow in a single view model. Now, combining the fact that we would like to have one view model for the screen and one state per view model kind of requires to cramp everything a screen needs into a single state object, no matter how unrelated certain parts might be. Let's look at some code from the Android compos samples repository to see what this will look like. This is the home view model, which is associated with the home screen of the chat cter app. As you can see, while it contains several small private states, it exposes its overall state as one single home screen UI state. Just combining those smaller states into the exposed one requires 55 lines of code.

and even a special combined utility function. I don't know about you, but this does not feel right to me. And please, I'm not saying this is bad code by any means. The engineers that wrote those examples have done a great job, in my opinion. My point is that the idea of VI models just doesn't fit and requires so much code to be written. For now, let's just accept the facts of life: coding is hard, exposing your state requires some coroutines flow code to be written. Who really cares nowadays? We can put the entire screen's logic into a single class, use dependency injection frameworks to create it, and carry on with our lives. But again, we have more issues to resolve. If you have this one state representing the entire screen, how gets this state passed down, and how shall we wire events back up? The pragmatic and quick approach is just to pass the view models down into your child composes. And yes, this will lead to launching a working app quickly, but despite it being a quite well-working approach, it feels entirely wrong now.

Every small UI component needs to know about the entire screen. Reusing such components across screens is practically impossible. No surprise, this is something the community highly disregards. The right way is called State hoisting. This will pass relevant pieces of State down and wire events back up, passing lambdas. This will make components reusable. Here's how this would look like. We're looking at Android's architecture samples, and this is the tasks screen. As you can see, it gets the tasks view model passed by Hilt, the dependency injection framework. Events such as the user selecting some kind of filter will be wired using these lambdas, which get passed down the composable hierarchy. The state also gets passed down raw from the task screen to the tasks content into Leaf composables such as this loading content. This approach is promising. It seems to make components very easily reusable and even testable if he would write tests. I cannot possibly have any further complaints here, right? Damn, I told you it's not about view models, it's about me. But I have even two issues. The

first one might be an obvious skill issue on my end, but look at how ugly and huge those composable functions can become. Let's not even talk about libraries and compatibility issues, but my more pressing point: Have you ever tried refactoring such composable functions? Changing a leave function can easily end up with you retouching your entire code base, and whose fault is it? The view model. Now, what's the point of me ranting about view models? Ever since I started building Android applications, I've remembered the community struggling to find good consensus about architecture, and I know this video will be my most disliked and disagreed one yet. I hope it was still fun, though. I remember the first time I wrote some code for iOS. Wait, what? You can just create a view controller yourself, attach it to a window, and it works? This moment was pivotal for me as an Android engineer. Android's complex life cycle and a handful of dudes on Reddit have scared us so much that we don't even dare to

think about finding approaches that we like and that work for us in our rep. If you like view models and they work well for your app, your team, then go for it. There's so much content on how to approach and so many success stories. Please feel encouraged. If you're like me and it's just not for you, dare to dream of approaches that you like. For me, I won't go back to Freestyle MVC. Remember the advice from Ian Lake using cold flows. I'm doing freestyle MV now, which basically just defines independent events and states. All the boilerplate wire-up logic was extracted to a library I call Evas events and states. Let me show an example and encourage you to build something that you can call your own. So we want to build a choke app. Therefore, we want to fetch something from an API. Here we have an already working Hello World Main activity. In order to create our choke app, we want to define a choke state, which can either be loading, can be an error state, or we can have successfully.

fetched out choke in order to use EAS. We define this as a state, and we also want to define a key to retrieve and set the state. This key is required to have a default, and we set the default to null. Next step, we are going to create our choke composable, which we will be able to use this C choke state in using the compos value function. We'll get us the current value of this current joke state, and compos will react to any changes. We switch over the cases when there's an aror state. We can print the count choke state with a large font size, or we can just show or indicate that we currently rading the joke with a circular progress indicator. Next step, we are making sure that there is a states container installed, and we can see that launching did not show anything yet. So what we have to do is we need to create a ctin, an actor that is producing us the state. We want to do this lazily, so we use the launch state function that just gets

the key instance request in the state as a parameter. First, we emit that we're currently loading the state. Then, we try to fetch a response from this public joke API by requesting it as a plain text for this video. If the response was not successful, we can emit the error with the description of the status. Otherwise, we can emit the joke that we got from the API as plain text. Now, it's time for us to start this state actor. We can just choose the lifecycle scope, make sure that the states container is available in the coroutine context, and launch the state. As you can see on screen, there is already a working app that fetches a joke. It shows the loading with the circular progress indicator. So, the last remaining thing that I want to show you is how you would bubble up some events from the UI into such State actors. For this, we define this reload joke click event that will now be emitted once the user presses on the button that will wrap just our composable here. The important thing is that we also need to make sure the event

bus is available in compose and on the quoting context. We install the events, or we can just use install Evas for events and states as a convenient function. The last remaining thing is to adapt our state actor in a way that it handles those reload events. For that, we can just wrap the code that is currently loading the choke in one suspending function, load choke. We will call this load choke function immediately and then collect all the events and trigger their reload of the choke. Let's restart the app. We can see this ugly button, and now clicking on it shows for a brief moment that it's loading, and then it just shows the joke. I think that's it, folks. Sorry for ranting so much about view models, and as always, have fun with Kotlin.

I am done with ViewModels...

I am done with ViewModels...

Scripts