What is wrong with MVVM?

• livedata-combineutil-java

  0 9 0.0 Java

  [ACTIVE] Helper function to combine LiveDatas.

  people exposing 11 public LiveData fields for 11 private MutableLiveData fields instead of using MediatorLiveData as combiners to reduce the number of exposed LiveData fields

• sunflower

  7 17,050 0.0 Kotlin

  A gardening app illustrating Android development best practices with migrating a View-based app to Jetpack Compose.

  

  Google samples pretending that the right way to observe 11 LiveDatas that weren't even a minimal state representation required Databinding, and most people don't like Databinding due to its intrusive nature (which is a byproduct of kapt running for layout modifications + people completely misusing @BindingAdapters as if they were "XML extension functions" or something rather than use them for what they actually were for)

• Appwrite

  appwrite.io

  sponsored

  Appwrite - The open-source backend cloud platform. The open-source backend cloud platform for developing Web, Mobile, and Flutter applications. You can set up your backend faster with real-time APIs for authentication, databases, file storage, cloud functions, and much more!

  

• orbit-mvi

  0 685 0.0 Kotlin

  A simple MVI framework for Kotlin Multiplatform and Android

  

  Everything in MVI is just more code that does nothing (see how most MVI frameworks are basically just a wrapper over state.value = state.copy() like in Orbit or MvRx which you wouldn't even need if you used combiners) and instead adds unnecessary constraints over MVVM that don't help you at all. The "sealed class inputs" are basically a reinvention of calling interface functions except you create classes for it, despite there being no asynchronicity when you have a View -> ViewModel communication.

• MvRx

  0 5,523 0.0 Kotlin

  Mavericks: Android on Autopilot

  

  Everything in MVI is just more code that does nothing (see how most MVI frameworks are basically just a wrapper over state.value = state.copy() like in Orbit or MvRx which you wouldn't even need if you used combiners) and instead adds unnecessary constraints over MVVM that don't help you at all. The "sealed class inputs" are basically a reinvention of calling interface functions except you create classes for it, despite there being no asynchronicity when you have a View -> ViewModel communication.

Suggest a related project