There are already MVC, MVP and MVVM for building mobile applications.

Why MVI, what's new in that? Touted as better than MVVM, but how?

Here are a few things recommended about MVI presentational arch pattern.

Supports Unidirectional Data Flow: due to flow of data from data layer, domain layer into UI layer.
Immutability: State, if immutable, helps in reducing bugs, when data is passed around.
Separation of Concerns: Clear separation between UI, state, and logic.
Reactive UI: Works well with reactive programming (e.g., Kotlin Flow, RxJava).
Testability: Reducers(Pure functions) and clear state transitions make testing easier.
Predictable State Management:All updates are handled through the state, making the flow easy to debug.

When to Use:when Complex state management is required involving lot of data Apps with heavy user interaction & those with requiring real-time updates, more significantly when state change is predictable and error free as in case of financial applications.

Ex: ecomm & social media apps including chat screens that frequently change data & needing predictable, error free state updates.

Let's begin:
MVI Architecture is a presentational architecture pattern(MVx) for building complex user interfaces.

Key components involved:

Essential: Intent, Model, State, ViewModel ,Action, Reducer (Simple implementations can use just these)

Optional: Effect, and Middleware.(Advanced use cases might need these)

•Model: The state of the UI at any given time.

•View: Renders the UI based on the current state.

•Intent: Represents user actions (e.g., button clicks).

•ViewModel: Manages the state and business logic.

• Action: Represents actions that trigger state changes.

•Reducer: Pure function that takes the current state and an action to produce a new state.

•Effect: Side effects (e.g., network calls, animations) triggered by actions.

•Middleware: Intercepts actions to perform additional logic (e.g., logging, analytics).

Code for the base viewmodel class

Example of middleware intercepting intents:

Here, middleware is integrated into the BaseViewModel as an open function that can be overridden by subclasses.

Middleware can:

Log intents for debugging or analytics.

Validate or block intents based on conditions.

Modify intents before they are processed.

The processIntent function ensures that intents are passed through middleware before being handled.

This approach makes the BaseViewModel highly flexible and reusable for various use cases.

Let's get into the details:

Let’s see how this works in a ChatViewModel that handles real-time updates and background tasks.

How Dispatchers Are Used in the Example connectToChat:

Uses runOnBackground to simulate a network call on Dispatchers.IO.

Updates the state and emits effects on the main thread using updateState and emitEffect.

sendMessage:

Simulates sending a message on Dispatchers.IO.

Updates the state on the main thread.

receiveMessage:

Updates the state and emits effects on the main thread.

Benefits of Using Dispatchers for Responsive UI:

Ensures that UI updates and side effects always happen on the main thread.

Efficient Background Tasks:

Offloads heavy operations (e.g., network calls) to background threads.

Thread Safety:

Prevents crashes or undefined behavior caused by updating the UI from a background thread.

Few things to note wrt to why StateFlow is used to represent UI State and not SharedFlow and SharedFlow for Intent, Actions and Events and StateFlow for State Why?

State represents the current UI state (e.g., loading, success, error).

StateFlow is designed for state persistence:

It holds the latest value and replays it to new collectors (e.g., the UI).

Ensures the UI always has the latest state when it (re)subscribes (e.g., after rotation).

Example: If the UI is in a "loading" state, new subscribers (like a recreated Activity) immediately see the loading state.

SharedFlow for Events (Intents, Actions, Effects) Why?

Intents, Actions, and Effects represent events (e.g., button clicks, navigation, toasts).

SharedFlow is designed for event streaming:

Events are short lived and should not be replayed to new collectors.

Avoids duplicate processing (e.g., showing a toast twice after rotation).

Example: A "Show Toast" effect should trigger only once, even if the UI resubscribes.

Key Differences

Why This Matters in MVI StateFlow ensures the UI always reflects the latest state (e.g., after screen rotation).

SharedFlow ensures events are processed exactly once (no duplicates).

The main purpose of this article was to provide with the MVI framework implementation:

**

For code with a demo app, please check

MainActivity.kt, DomainData.kt & app/build.gradle.kts files from my github repo

**

Let’s see how what can we do with it.

In canvas, a Paint object takes a shader/gradient for applying multiple colors [colors array].

Here’s the Api of LinearGradient from android.graphics package:

A linear gradient object takes a nullable array.

The topic under discussion here is the “positions” array.

If one specifies null for positions, the colors are evenly distributed [linear growth of gradient] along the length of the gradient as show below:

The above effect is achieved using 4 colors used as gradient, and with null passed as argument for positions. If you closely observe, each color has got equal portion, here 25% of length, along the rect Here's the code for it:

class CustomView @JvmOverloads constructor(
    context: Context, attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {
    private val trackHeight=50f
    // set left, top, right, bottom positions/bounds of the rectangle
    private val rect=RectF(100f,100f,600f,150f)
    private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
        strokeWidth = trackHeight
    }
    private val colorsArray =
        intArrayOf(Color.RED, Color.BLUE, Color.YELLOW,
            Color.parseColor("#FFA500"))// orange color hex code

    // apply gradient from left to right of the rectangle along X axis , from top to bottom along Y axis
    private val paintShader = LinearGradient(
        rect.left,
        rect.top,
        rect.right,
        rect.bottom,
        colorsArray,
        null,//evenly distribute colors along the whole length of gradient
        Shader.TileMode.CLAMP
    )

Now, what if we need to specify which color should occupy how much portion of the available space i.e. distribution of colors? / non-linear growth of gradient? Here's the position values array comes into play.

Suppose, I want red color to have 60% of length from starting X co-ordinate, then blue color to have next 10% of space from previous color's ending X co-ordinate, then yellow color to occupy next 15% of space and then Orange color to have 15% of the next space till the end, this is how you specify the positions array:

private val colorsArray =
        intArrayOf(Color.RED, Color.BLUE, Color.YELLOW,
            Color.parseColor("#FFA500"))// orange color hex code

 private val colorPositions= floatArrayOf(0.6f,0.7f,0.85f,1f)

Note: No of Colors in colorsArray and values in positions array must be of equal length, increasing in value and only even no of entries in both of them. [can't specify 1, or 3 or so on no of colors in odd no entries]

Non conforming to the above requirement throws an exception!

Let's pass colorPositions to LinearGradient as shader to paint instead of null as follows:

// apply gradient from left to right of the rectangle along X axis , from top to bottom along Y axis
    private val paintShader = LinearGradient(
        rect.left,
        rect.top,
        rect.right,
        rect.bottom,
        colorsArray,
        colorPositions,// distribution of colors along the length of gradient.
        Shader.TileMode.CLAMP
    )

This is what you would notice:

Also, instead of using multiple colors, we can use a multiple opacity values for a single color code.

In this case too, if you pass null, you'd get even distribution of colors. But for requirement having non-linear growth of the opacity of a single color you can specify the positions array with the requirement.

Here's how we would do it:

//pink color, also show with two colors too.
    private val singleColorWithVaryingOpacitiesArray = intArrayOf(
        Color.parseColor("#00BF6793"),//pink with 0% opacity
        Color.parseColor("#CCBF6793"),//pink with 80% opacity
        Color.parseColor("#FFBF6793")//pink with 100% opacity
    )
    private val colorPositions= floatArrayOf(0.6f,0.9f,1f)

    // apply gradient from left to right of the rectangle along X axis , from top to bottom along Y axis
    private val paintShader = LinearGradient(
        rect.left,
        rect.top,
        rect.right,
        rect.bottom,
        singleColorWithVaryingOpacitiesArray,
        colorPositions,// distribution of colors along the length of gradient.
        Shader.TileMode.CLAMP
    )
    override fun onDraw(canvas: Canvas?) {
        super.onDraw(canvas)
        canvas?.drawRect(rect, paint.apply {
            color = Color.BLACK
        })

            canvas?.drawRect(rect, paint.apply {
            shader = paintShader
       // Used blending with porter-duff mode so that underlying rectangle's black color is visible for 
      //portion having for 0% opacity values
            xfermode = PorterDuffXfermode(PorterDuff.Mode.SRC_OVER)
        })

Had we passed null, the output would be like: and if we passed positions with requirement : like till 60% of space from starting X co-ordinate has 0% opacity(not visible), followed by 80% opacity till next 30% of space, and the 100% opacity(fully visible) for remaining 10% of space or till the end, the output would have been: