I’ve seen this topic mentioned only once or twice ...
# compose
j
I’ve seen this topic mentioned only once or twice with barely any discussion and I think it could be quite useful debating about this: I believe in compose-only android projects (for UI, ofc) we should handle config changes instead of recreating the activity. And, as a consequence, I also believe we should avoid using the Android ViewModel. Thread with discussion:
👍 1
In short, if we handle config changes we have more control, the app responds faster, and we do not have different lifespans for the view and its controller (e.g. viewmodel). And compose handles config changes easily with recomposition. Having the view and view controller with the same lifespan means that the controller can have classes that internally use the Activity Context, for instance, for handling resources. This gives us freedom to build better architectures!
1
The reasons for not using the Android ViewModel, then, are these:  1) we won’t need factories and our view controllers will be more lightweight 2) they are not needed (they were built to survive config changes) 3) we can easily create bugs with them. With this what I mean is that if we do not handle all config changes, or if new ones are introduced in a new Android release, using the Android ViewModel means the activity recreates and the ViewModel retains the Context: memory leak. Given that those config changes would be rare and the main ones would be handled by ourselves, instead we can let the activity recreate for the rare ones and save user state with SavedStateHandle (which we should already be using for process death). But this requires using our own viewModel instead of the Android one.
s
Thank you, i was also looking for avoiding ViewModel in Compose only app. Do you have any example project with zero ViewModel.
j
I’m finishing up a sample that I’ll open source together with part 3 of this series. I hope to have it by Monday but it might be a bit longer 🙂
👍 1