What is wrong with MVVM?

• livedata-combineutil-java

  11 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

  19 17,498 7.4 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)

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• orbit-mvi

  6 834 6.4 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

  7 5,745 6.1 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