We have a custom view that is used in a lot of places. We want to tie this to a viewmodel and keep all the business logic there. A coworker suggested just passing in the ViewModel and lifecycle owner to the custom view and then observe on the properties. This doesn’t feel right. What do you guys do?

Don’t make a (custom)

View

dependent on a ViewModel… Instead, think about how Fragments and Activities handle this. A Fragment or Activity receive a ViewModel and a View as input/dependency and this Fragment/Activity then observes properties on the ViewModel and manipulates the View accordingly.

View ------+
           +--> Fragment/Activity
ViewModel -+

Make a similar type of class (a ‘controller’?) that will take (or get injected) a custom View and your custom-view related ViewModel like a Fragment or Activity.

MyCustomView      --+
                    +--> MyCustomController
MyCustomViewModel --+

This doesn’t feel right.

What makes you feel so?

class SomeActivity : AppCompatActivity() {
    ...
    
    val myCustomController: MyCustomController by lazy {
        MyCustomController(findViewById(R.id.my_custom_view), MyCustomViewModel())
    }
    ...
}

You could finagle the creation of the MyCustomController and its dependencies (MyCustomView and MyCustomViewModel) through dependency injection (dagger/koin/etc), if you want to remove some boiler plate.

Why not? 🙂 I can imagine a full Custom View approach using libraries such as Conductor. Where would you put the ViewModel in such case?

You put the ViewModel in a controller (like the example ‘MyCustomController’ above). True, it doesn’t break the MVVM pattern. But makes MyCustomView dependent on MyCustomViewModel which is not necessary, and it would break the rendering of the custom view in the IDE’s layout-editor (the layout-editor wouldn’t know how to provide an instance of MyCustomViewModel).

Using completely custom views as replacement for fragment/activity is a valid thing, but it requires quite a lot of custom logic and essentially own framework, and very easy to implement it in a wrong way It's more flexible approach I. Theory, but it easy becomes a huge mess. We used to use fully custom views as controller, but eventually decide that it doesn't worth it, and now it's our biggest legacy, it painful every time to touch this code, none of new features of androidx (lifecycle, viewmodels, backstack dispatchers) works there

@Nick would it be possible to refactor this view to become a fragment containing the view?

@Joost Klitsie That could work too. But I always feel like fragments contain so much overhead with the extra lifecycle.

@Nick Yup, a lot of overhead. That is where that ‘controller’ type of class comes in, like a very very lightweight fragment 🙂

Are there any examples that you’ve seen online that show what you describe?

the situtation with fragments lifecycle may be improved, there. are plans to follow lifecycle of view (so no more detached fragment). So, when it will happen, this “lightweight controller view” becomes “heavyweight” 🤷

The majority of our crashes and problems comes from lifecycle issues related to fragments. I want to avoid them if I can.

but it requires quite a lot of custom logic and essentially own framework,

I know 🙂 , that’s why I mentioned using something like Conductor to facilitate this, because this wasn’t how the Android Views were originally designed for. Additionally, Jetpack Compose is just around the corner. It doesn’t need Fragments or multiple Activities, and you can provide the viewModel from the top level Composable function

You put the ViewModel in a controller

That could work also, but that’s no longer simple MVVM. It’s MVVM+Controller.

The majority of our crashes and problems comes from lifecycle issues related to fragments. I want to avoid them if I can.

Really? what kind crashes? i

so @streetsofboston, the controller will take the viewmodel as a param (that’s already created using the fragments lifecycleowner), and inside the controller i’d observe on the properties?

that’s why I mentioned using something like Conductor

I’m not a big fan of conductor, for me it looks that they took all bad things from fragments, but yeah, made lifecycle more simple

@Nick there was a huge refactoring of Fragments, and part of that is fixing lifecycle issues and trying to align with the Activities’ lifecycle. You can consider using them again. https://medium.com/androiddevelopers/fragments-rebuilding-the-internals-61913f8bf48e Alternatively, LifecycleOwner is supposed to be a simpler way to have lifecycle-aware classes as well. I asked why your colleague’s idea doesn’t feel right, since I think there is a case specific to your project that make that a bad idea. 🙂 As you can see here everyone has their opinions based from their experiences, so I guess that answers your question as you were simply asking how the others are doing. There is no right single answer I think

I just want to point out, that using conductor it’s not the same as using custom view for controller, it’s essentially the same approach as use fragments, just different implementation

I’m not a big fan of conductor, for me it looks that they take all bad things from fragments, but yeah, make lifecycle more simple

me neither 😄 I don’t like to depend on 3rd party libraries for something so important unless it’s really mainstream

Sounds like MVP not MVVM.