TL;DR — If you are already familiar with Kotlin Coroutines, SharedFlow, and sealed classes, skip the basics and jump straight to the LocalBroadcast + BroadcastEvent section.

Preface

Every non-trivial Android app eventually runs into the same problem: how do you communicate between two completely unrelated parts of your app — a background sync service and a fragment, a repository and a ViewModel — without coupling them together?

For years, the go-to answer was LocalBroadcastManager. It was simple. It worked. And then Google deprecated it.

“LocalBroadcastManager is an application-wide event bus and embraces layer violations in your app; any component may listen to events from any other component… Use other means of communicating between components.”
 — Android Developer Documentation

So, what do we use instead? There are options — EventBus, RxJava's PublishSubject, or callbacks passed through constructors — but each comes with its own cost. We are in the coroutines era now. There is a cleaner answer.

Let me walk you through an event bus architecture I’ve been using in production — built on MutableSharedFlow, Kotlin sealed classes, and coroutine extension functions. To keep things concrete, we'll build it in the context of a News Reader app that syncs articles in the background, handles user authentication, and notifies the UI of changes from anywhere in the stack.

⭐ Why Not Just Use LiveData or StateFlow?

Before we get to the solution, let’s quickly rule out the obvious alternatives.

LiveData is lifecycle-aware but it maintains state. If you emit “show a loading spinner” via LiveData and the user rotates the screen, the spinner re-shows on re-subscription. That’s not what you want for fire-and-forget commands.

StateFlow has the same problem — it always replays the last value to new collectors. It’s perfect for UI state, not for events.

SharedFlow with replay = 0 is exactly what an event bus needs. It does not replay missed emissions. It delivers to all current subscribers simultaneously, and then the event is gone. Think of it like a real broadcast — if you weren't listening, you missed it.

⭐ The Two Core Classes

The entire system is built on two files. One defines what can be broadcast. The other defines how to broadcast and observe it.

BroadcastEvent — The Contract

BroadcastEvent is a sealed class. Every possible in-app event is a subclass — either a data class (if it carries a payload) or an object (if it's just a signal).

For our News Reader app, these are the events that flow across the app:

sealed class BroadcastEvent {

    // An article's content was updated remotely
    data class ArticleUpdated(val articleId: String? = null) : BroadcastEvent()

    // Background feed sync is in progress
    data class FeedRefreshing(
        val currentProgress: Float,
        val total: Float,
        val remaining: Long
    ) : BroadcastEvent()

    // Background feed sync completed
    object FeedRefreshComplete : BroadcastEvent()

    // App has finished initializing and is ready
    object AppReady : BroadcastEvent()

    // A human-readable sync status message (e.g. "Fetching top stories...")
    data class SyncStatus(val message: String) : BroadcastEvent()

    // OTP received via SMS for login
    data class OtpReceived(val otp: String, val smsBody: String) : BroadcastEvent()

    // A news category's articles were updated
    data class CategoryUpdated(
        val categoryId: String?,
        val articlesChanged: Boolean,
        val updateTime: Long
    ) : BroadcastEvent()

    // A category update is currently in progress
    data class CategoryUpdateInProgress(val categoryId: String?, val updateTime: Long) :
        BroadcastEvent()

    // Bookmark cloud sync started or completed
    data class BookmarkSyncUpdate(val started: Boolean, val bookmarkCount: Int) :
        BroadcastEvent()

    // Request to prompt the user for notification permission
    object RequestNotificationPermission : BroadcastEvent()

    // User changed their app lock / security settings
    data class SecurityChanged(val lockTypeChanged: Boolean) : BroadcastEvent()

    // User signed out
    object UserSignOut : BroadcastEvent()

    // Sign-out flow was initiated (before confirmation)
    object UserSignOutInitiated : BroadcastEvent()

    // Toggle read-count visibility in the UI
    data class HideReadCount(val hide: Boolean) : BroadcastEvent()

    // Onboarding was reset (e.g. after account switch)
    object OnboardingReset : BroadcastEvent()

    // Restore from backup is in progress
    object RestoreInProgress : BroadcastEvent()
}

The sealed class is your contract. If you need to add a new event type to the app, this is the one place you go. Your IDE will immediately flag any when expression that doesn't handle the new subtype — that's the compiler enforcing your architecture.

FilterType — The Subscription Filter

Alongside BroadcastEvent, we define a FilterType enum. Each entry corresponds directly to one event type. Observers subscribe to a list of filters, not to all events.

enum class FilterType {
    ARTICLE_UPDATED,             // BroadcastEvent.ArticleUpdated
    FEED_REFRESHING,             // BroadcastEvent.FeedRefreshing
    FEED_REFRESH_COMPLETE,       // BroadcastEvent.FeedRefreshComplete
    APP_READY,                   // BroadcastEvent.AppReady
    SYNC_STATUS,                 // BroadcastEvent.SyncStatus
    OTP_RECEIVED,                // BroadcastEvent.OtpReceived
    CATEGORY_UPDATED,            // BroadcastEvent.CategoryUpdated
    CATEGORY_UPDATE_IN_PROGRESS, // BroadcastEvent.CategoryUpdateInProgress
    BOOKMARK_SYNC_UPDATE,        // BroadcastEvent.BookmarkSyncUpdate
    REQUEST_NOTIFICATION_PERM,   // BroadcastEvent.RequestNotificationPermission
    SECURITY_CHANGED,            // BroadcastEvent.SecurityChanged
    USER_SIGN_OUT,               // BroadcastEvent.UserSignOut
    USER_SIGN_OUT_INITIATED,     // BroadcastEvent.UserSignOutInitiated
    HIDE_READ_COUNT,             // BroadcastEvent.HideReadCount
    ONBOARDING_RESET,            // BroadcastEvent.OnboardingReset
    RESTORE_IN_PROGRESS,         // BroadcastEvent.RestoreInProgress
}

This filter pattern lets a subscriber declare exactly what it cares about. The ArticleDetailViewModel only subscribes to ARTICLE_UPDATED and BOOKMARK_SYNC_UPDATE. It never wakes up for OTP_RECEIVED or SECURITY_CHANGED. Clean boundaries.

⭐ LocalBroadcast — The Bus

Now the bus itself. It’s a Kotlin object — a singleton — holding a single MutableSharedFlow.

object LocalBroadcast {

    private val _events = MutableSharedFlow<Pair<FilterType, BroadcastEvent>>()
    private const val TAG = "LocalBroadcast"

    @JvmStatic
    suspend fun postData(type: FilterType, data: BroadcastEvent) {
        Log.d(TAG, "Broadcasting: filter=$type event=$data")
        _events.emit(Pair(type, data))
    }

    @JvmStatic
    fun observeData(
        scope: CoroutineScope,
        filters: List<FilterType>,
        onReceive: (FilterType, BroadcastEvent) -> Unit
    ) {
        scope.launch(Dispatchers.Main) {
            _events
                .filter { filters.contains(it.first) }
                .collect { event ->
                    onReceive.invoke(event.first, event.second)
                }
        }
    }
}

Let’s break down what’s happening here:

• _events is a MutableSharedFlow<Pair<FilterType, BroadcastEvent>> — private, not exposed externally.
• postData() is a suspend function. Emitting into a SharedFlow is a suspend operation — it must be called from within a coroutine.
• observeData() takes a CoroutineScope. Pass viewModelScope or lifecycleScope, and when that scope is cancelled, the collector automatically stops. No manual cleanup needed.

Kotlin-First Call Sites — Extension Functions

For Kotlin callers inside a CoroutineScope, we expose two extension functions that make posting a broadcast feel completely natural:

fun CoroutineScope.broadcastEvent(type: FilterType, data: BroadcastEvent) {
    launch {
        LocalBroadcast.postData(type = type, data = data)
    }
}

fun CoroutineScope.broadcastEventWithCompletion(
    type: FilterType,
    data: BroadcastEvent,
    onCompleted: () -> Unit
) {
    launch {
        LocalBroadcast.postData(type = type, data = data)
    }.invokeOnCompletion {
        onCompleted.invoke()
    }
}

The first is your everyday fire-and-forget broadcast. The second gives you a callback once the emission coroutine has finished — useful when you need to trigger navigation or a UI update after the broadcast is guaranteed to have been emitted.

⭐ How to Use It

Sending a broadcast from the background sync repository when articles are fetched:

class NewsSyncRepository(private val scope: CoroutineScope) {

    suspend fun syncFeed() {
        scope.broadcastEvent(
            type = FilterType.FEED_REFRESHING,
            data = BroadcastEvent.FeedRefreshing(
                currentProgress = 0f,
                total = 100f,
                remaining = 50
            )
        )
        // ... do actual sync work ...
        scope.broadcastEvent(
            type = FilterType.FEED_REFRESH_COMPLETE,
            data = BroadcastEvent.FeedRefreshComplete
        )
    }
}

Observing in the home screen ViewModel:

class HomeViewModel : ViewModel() {

    init {
        LocalBroadcast.observeData(
            scope = viewModelScope,
            filters = listOf(
                FilterType.FEED_REFRESH_COMPLETE,
                FilterType.ARTICLE_UPDATED,
                FilterType.CATEGORY_UPDATED
            )
        ) { _, event ->
            when (event) {
                is BroadcastEvent.FeedRefreshComplete -> reloadFeed()
                is BroadcastEvent.ArticleUpdated -> refreshArticle(event.articleId)
                is BroadcastEvent.CategoryUpdated -> refreshCategory(event.categoryId)
                else -> Unit
            }
        }
    }
}

No BroadcastReceiver. No IntentFilter. No onResume/onPause registration juggling. The ViewModel subscribes once in init{}, and viewModelScope handles teardown automatically when the ViewModel is cleared.

Further Improvements

1. The FilterType enum is redundant in pure Kotlin projects.
   Kotlin sealed classes already carry type identity. You can filter the flow using filterIsInstance<T>() directly, removing the need for the enum entirely. The enum was likely introduced for Java interoperability. If your codebase is fully Kotlin, consider simplifying to:

// Type-safe, no enum needed
_events.filterIsInstance<BroadcastEvent.ArticleUpdated>().collect { event ->
    refreshArticle(event.articleId)
}

2. replay = 0 means late subscribers miss events.
The current MutableSharedFlow() uses default replay = 0. If a subscriber registers after an emission, it will never see that event. For one-time signals like AppReady, consider replay = 1 or a dedicated StateFlow for those specific signals.

3. invokeOnCompletion fires on cancellation too.
In broadcastEventWithCompletion, the onCompleted callback triggers even if the coroutine is cancelled mid-flight. Always check the cause parameter:

}.invokeOnCompletion { cause ->
    if (cause == null) onCompleted.invoke() // Only on clean completion
}

4. Sensitive data on a shared bus.
OtpReceived(val otp: String, val smsBody: String) routes raw OTP strings through a global singleton. Any subscriber with access to the right FilterType gets the full payload. Scope sensitive events as tightly as possible — consider a dedicated, narrowly scoped channel for authentication signals rather than the global bus.

5. Use Set instead of List for filters.
observeData() accepts a List<FilterType>. A Set is semantically more correct here — duplicate filter entries are meaningless and Set.contains() is O(1) vs O(n) for a List.

fun observeData(
    scope: CoroutineScope,
    filters: Set<FilterType>, // Set, not List
    onReceive: (FilterType, BroadcastEvent) -> Unit
)

Closing Thoughts

The combination of MutableSharedFlow, a sealed class event hierarchy, and coroutine scopes gives you everything LocalBroadcastManager did — and more — with far less ceremony. The sealed class is your single source of truth for all in-app signals. The FilterType enum keeps subscriptions explicit and auditable. The CoroutineScope parameter does all lifecycle management for you.

This is not groundbreaking architecture — it’s just coroutines doing what they’re already good at. No new dependencies, no new abstractions to learn. Just Kotlin, used well.

Thanks for reading! If this helped you move away from LocalBroadcastManager, clap clap clap 👏👏👏 as many times as you can.

MVI keeps screen state predictable, but it creates a new problem: Fat ViewModels.

If your app has a complex “Feature Carousel” component used on the Home Screen, the Search Screen, and the Profile Screen, duplicating the loading, error handling, and state logic across three ViewModels violates DRY. You cannot use inheritance because a ViewModel can only extend one base class, and a carousel is just one piece of a screen.

We need Composition. We need to extract the MVI logic of that component into a reusable unit that any ViewModel can plug in.

Introducing AacMviDelegateVM

A DelegateVM is a plain class (not an AndroidViewModel) that encapsulates a full MVI loop (ViewState, ViewEffect, ViewEvent) for a specific, reusable UI component.

It shares code, not state. Each Host ViewModel instantiates its own unique instance of the Delegate. The Host ViewModel funnels the Delegate’s state and effects into its own MVI stream, and the View remains completely unaware of the delegation.

Because the Delegate is strictly bound to a single Host ViewModel, it doesn’t need to manage its own lifecycle. It simply borrows the viewModelScope of its Host.

1. The AacMviDelegateVM Base Class

open class AacMviDelegateVM<STATE, EFFECT, EVENT> : ViewModelContract<EVENT> {

    private var _delegateScope: CoroutineScope? = null
    protected var delegateScope: CoroutineScope
        get() = _delegateScope ?: throw UninitializedPropertyAccessException("Call initDelegate() first")
        set(value) { _delegateScope = value }

    // State: SharedFlow with replay=1 ensures the Host gets the current state instantly
    private val _viewStates = MutableSharedFlow<STATE>(replay = 1)
    val viewStates: SharedFlow<STATE> get() = _viewStates.asSharedFlow()

    protected var viewState: STATE
        get() = _viewState ?: throw UninitializedPropertyAccessException()
        set(value) {
            _viewState = value
            delegateScope.launch { _viewStates.emit(value) }
        }

    // Effects: Channel for one-shot delivery
    private val _viewEffects = Channel<EFFECT>(Channel.BUFFERED, BufferOverflow.DROP_OLDEST)
    val viewEffects: Flow<EFFECT> get() = _viewEffects.receiveAsFlow()

    protected var viewEffect: EFFECT
        get() = _viewEffect ?: throw UninitializedPropertyAccessException()
        set(value) {
            _viewEffect = value
            delegateScope.launch { _viewEffects.send(value) }
        }

    @CallSuper
    override fun process(viewEvent: EVENT) { /* Handle events */ }

    /**
     * Binds the Delegate to the Host ViewModel's scope and wires up the output.
     */
    fun initDelegate(
        coroutineScope: CoroutineScope,
        handleDelegateViewState: (STATE) -> Unit,
        handleDelegateViewEffect: (EFFECT) -> Unit,
    ) {
        _delegateScope = coroutineScope
        initViewState()
        
        delegateScope.launch {
            viewStates.collect { handleDelegateViewState(it) }
        }
        delegateScope.launch {
            viewEffects.collect { handleDelegateViewEffect(it) }
        }
    }

    @CallSuper
    protected open fun initViewState() {}
}

2. Building the Delegate

Let’s build the reusable FeatureCarouselDelegate:

data class CarouselState(val items: List<Item> = emptyList(), val isLoading: Boolean = false)
sealed class CarouselEffect { data class ShowError(val msg: String) : CarouselEffect() }
sealed class CarouselEvent { object Load : CarouselEvent() }

class FeatureCarouselDelegate(
    private val repo: Repository
) : AacMviDelegateVM<CarouselState, CarouselEffect, CarouselEvent>() {

    override fun initViewState() {
        viewState = CarouselState(isLoading = true)
        process(CarouselEvent.Load)
    }

    override fun process(viewEvent: CarouselEvent) {
        when (viewEvent) {
            is CarouselEvent.Load -> loadItems()
        }
    }

    private fun loadItems() {
        delegateScope.launch {
            val data = repo.getFeatures()
            viewState = viewState.copy(items = data, isLoading = false)
        }
    }
}

3. Wiring it into the Host ViewModel

The Host ViewModel includes the Delegate’s state in its own ViewState and uses initDelegate to funnel the data.

data class HomeState(
    val carouselState: CarouselState = CarouselState(),
    val screenTitle: String = "Home"
)

class HomeViewModel(
    application: Application,
    private val carouselDelegate: FeatureCarouselDelegate // Unique instance for this VM
) : AacMviViewModel<HomeState, HomeEffect, HomeEvent>(application) {

    init {
        viewState = HomeState()
        
        // Bind the delegate to this ViewModel's lifecycle
        carouselDelegate.initDelegate(
            coroutineScope = viewModelScope,
            handleDelegateViewState = { delegateState ->
                // Merge delegate state into screen state
                viewState = viewState.copy(carouselState = delegateState)
            },
            handleDelegateViewEffect = { delegateEffect ->
                // Forward delegate effects
                when (delegateEffect) {
                    is CarouselEffect.ShowError -> viewEffect = HomeEffect.ShowSnackbar(delegateEffect.msg)
                }
            }
        )
    }

    override fun process(viewEvent: HomeEvent) {
        when (viewEvent) {
            is HomeEvent.CarouselAction -> carouselDelegate.process(CarouselEvent.Load)
            // Handle Home-specific events...
        }
    }
    
    // No manual cleanup needed! When HomeViewModel is cleared, 
    // viewModelScope cancels, which automatically kills all Delegate coroutines.
}

The Takeaway

By combining Unidirectional Data Flow with Composition, we keep ViewModels focused solely on screen-level orchestration. Complex, reusable UI logic lives isolated, tested, and shared in DelegateVMs, without muddying the inheritance tree or creating lifecycle headaches.

Thanks for reading!
Rohit Surwase

If you liked this article, clap clap clap 👏👏👏 as many times as you can.

The original architecture served us well, but the Android ecosystem has shifted. LiveData is tied to the Android SDK and struggles with one-shot events. SingleLiveEvent was a hack. Jetpack Compose completely changed the UI rendering contract.

Here is how we evolved our MVI base to use Kotlin Flows, support Jetpack Compose, and guarantee lifecycle safety.

1. State: LiveData ➡️ StateFlow

LiveData binds lifecycle-awareness into the ViewModel. StateFlow pushes that responsibility to the UI layer, keeping the ViewModel pure Kotlin. It always holds a value and replays it instantly to new collectors, making it the perfect replacement for ViewState.

// In AacMviViewModel.kt
private val _viewStates: MutableStateFlow<STATE> by lazy { MutableStateFlow(viewState) }
override val viewStates: StateFlow<STATE> get() = _viewStates.asStateFlow()

protected var viewState: STATE
    get() = _viewState ?: throw UninitializedPropertyAccessException("Init viewState first")
    set(value) {
        _viewState = value
        _viewStates.value = value
    }

Note: We use by lazy so the flow is only instantiated after the subclass init {} block assigns the initial viewState.

2. Effects: SingleLiveEvent ➡️ Channel

SingleLiveEvent was notorious for dropping events or multi-delivery bugs during configuration changes. To handle fire-and-forget ViewEffects (like navigation or Toasts), we use a Channel exposed as a Flow.

A Channel guarantees exactly-once delivery. If the UI is rotating, the BUFFERED capacity holds the effect until the UI re-attaches.

private val _viewEffects: Channel<EFFECT> = Channel(
    capacity = Channel.BUFFERED,
    onBufferOverflow = BufferOverflow.DROP_OLDEST,
    onUndeliveredElement = { Log.w(TAG, "Dropped effect: $it") } // Hook for analytics
)
override val viewEffects: Flow<EFFECT> get() = _viewEffects.receiveAsFlow()

protected var viewEffect: EFFECT
    get() = _viewEffect ?: throw UninitializedPropertyAccessException()
    set(value) {
        _viewEffect = value
        viewModelScope.launch { _viewEffects.send(value) }
    }

override fun onCleared() {
    super.onCleared()
    _viewEffects.close() // Crucial: prevents memory leaks of buffered effects
}

3. Safe UI Collection: repeatOnLifecycle

Raw Kotlin Flows don’t stop collecting when the Activity goes to the background. To prevent crashes and wasted resources, we enforce repeatOnLifecycle(STARTED) in the Base Activity/Fragment.

STARTED is critical. If you use RESUMED, your flow pauses when a dialog or permission prompt appears on top of your app. Any effects emitted during that time would be permanently dropped by the Channel.

// Inside AacMviActivity.kt onCreate()
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        launch { viewModel.viewStates.collect { renderViewState(it) } }
        launch {
            // Main.immediate prevents dropping effects during rapid config changes
            withContext(Dispatchers.Main.immediate) {
                viewModel.viewEffects.collect { renderViewEffect(it) }
            }
        }
    }
}

4. Bridging Jetpack Compose

To allow incremental migration, we introduce an isForPureCompose flag. When true, XML rendering is bypassed. State collection is handled naturally by Compose's collectAsStateWithLifecycle().

override fun onCreateView(...): View? {
    return if (isForPureCompose) {
        ComposeView(requireContext()).apply {
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent {
                val viewState = viewModel.viewStates.collectAsStateWithLifecycle()
                ComposeViewState(viewState.value)
            }
        }
    } else {
        super.onCreateView(inflater, container, savedInstanceState)
    }
}

However, Effects require explicit collection. We force developers to call a ComposeViewEffect {} block inside their composable tree. This prevents the silent failures common in open XML methods.

@Composable
fun ComposeViewEffect(composeViewEffect: (EFFECT) -> Unit) {
    val lifecycleOwner = LocalLifecycleOwner.current
    LaunchedEffect(viewModel.viewEffects, lifecycleOwner.lifecycle) {
        lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
            withContext(Dispatchers.Main.immediate) {
                viewModel.viewEffects.collect { composeViewEffect(it) }
            }
        }
    }
}

Two details worth noting:

1. Dispatchers.Main.immediate: A regular withContext(Dispatchers.Main) posts the effect as a new task on the main thread event loop. If the composable is near a recomposition cycle boundary, the effect could be dispatched after the lifecycle moves below STARTED and get dropped. Main.immediate executes the block in the current event cycle if already on Main, eliminating that race condition.
2. Why not automatic?: Making effect collection opt-in forces the developer to consciously place the ComposeViewEffect{} call in their composable tree. Silent drop (forgetting to call it) is a compile-time-visible omission rather than a silent runtime bug, and it keeps state and effect concerns cleanly separated.

Example: A Compose Activity

class MainActivity : AacMviActivity<MainState, MainEffect, MainEvent, MainViewModel>(
    isForPureCompose = true
) {
    override val viewModel: MainViewModel by viewModels()

    // Required by base contract, but safe to ignore in Compose mode
    override fun renderViewEffect(viewEffect: MainEffect) {}

    @Composable
    override fun ComposeViewState(viewState: MainState) {
        MainScreen(state = viewState)

        // Explicitly handle effects
        ComposeViewEffect { effect ->
            when (effect) {
                is MainEffect.ShowToast -> Toast.makeText(this, effect.message, Toast.LENGTH_SHORT).show()
            }
        }
    }
}

The Full Base Classes:

private const val TAG = "AacMviActivity"

abstract class AacMviActivity<STATE, EFFECT, EVENT, VM : AacMviViewModel<STATE, EFFECT, EVENT>>(
    val isForPureCompose: Boolean,
) : AppCompatActivity() {

    abstract val viewModel: VM

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        if (isForPureCompose) {
            setContent {
                val viewState = viewModel.viewStates.collectAsStateWithLifecycle()
                ComposeViewState(viewState.value)
            }
        } else {
            lifecycleScope.launch {
                repeatOnLifecycle(Lifecycle.State.STARTED) {
                    launch {
                        viewModel.viewStates.collect {
                            if (logging) Log.d(MAIN_TAG, "$TAG -> observed viewState : $it")
                            renderViewState(it)
                        }
                    }
                    launch {
                        withContext(Dispatchers.Main.immediate) {
                            viewModel.viewEffects.collect {
                                if (logging) Log.d(MAIN_TAG, "$TAG -> observed viewEffect : $it")
                                renderViewEffect(it)
                            }
                        }
                    }
                }
            }
        }
    }

    open fun renderViewState(viewState: STATE) {}
    abstract fun renderViewEffect(viewEffect: EFFECT)

    @CallSuper
    @Composable
    open fun ComposeViewState(viewState: STATE) {
        if (logging) Log.d(MAIN_TAG, "$TAG -> ComposeViewState: $viewState")
    }

    @Composable
    fun ComposeViewEffect(composeViewEffect: (EFFECT) -> Unit) {
        val lifecycleOwner = LocalLifecycleOwner.current
        LaunchedEffect(viewModel.viewEffects, lifecycleOwner.lifecycle) {
            lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                withContext(Dispatchers.Main.immediate) {
                    viewModel.viewEffects.collect {
                        if (logging) Log.d(MAIN_TAG, "$TAG -> ComposeViewEffect: $it")
                        composeViewEffect(it)
                    }
                }
            }
        }
    }
}

private const val TAG = "AacMviFragment"

abstract class AacMviFragment<STATE, EFFECT, EVENT, VM : AacMviViewModel<STATE, EFFECT, EVENT>>(
    val isForPureCompose: Boolean,
) : Fragment() {

    abstract val viewModel: VM

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        return if (isForPureCompose) {
            ComposeView(requireContext()).apply {
                setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
                setContent {
                    val viewState = viewModel.viewStates.collectAsStateWithLifecycle()
                    ComposeViewState(viewState.value)
                }
            }
        } else {
            super.onCreateView(inflater, container, savedInstanceState)
        }
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                if (isForPureCompose.not()) {
                    launch {
                        viewModel.viewStates.collect {
                            if (logging) Log.d(MAIN_TAG, "$TAG -> observed viewState : $it")
                            renderViewState(it)
                        }
                    }
                    launch {
                        withContext(Dispatchers.Main.immediate) {
                            viewModel.viewEffects.collect {
                                if (logging) Log.d(MAIN_TAG, "$TAG -> observed viewEffect : $it")
                                renderViewEffect(it)
                            }
                        }
                    }
                }
            }
        }
    }

    open fun renderViewState(viewState: STATE) {}
    abstract fun renderViewEffect(viewEffect: EFFECT)

    @CallSuper
    @Composable
    open fun ComposeViewState(viewState: STATE) {
        if (logging) Log.d(MAIN_TAG, "$TAG -> ComposeViewState: $viewState")
    }

    @Composable
    fun ComposeViewEffect(composeViewEffect: (EFFECT) -> Unit) {
        val lifecycleOwner = LocalLifecycleOwner.current
        LaunchedEffect(viewModel.viewEffects, lifecycleOwner.lifecycle) {
            lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                withContext(Dispatchers.Main.immediate) {
                    viewModel.viewEffects.collect {
                        if (logging) Log.d(MAIN_TAG, "$TAG -> ComposeViewEffect: $it")
                        composeViewEffect(it)
                    }
                }
            }
        }
    }
}

What Hasn’t Changed

The conceptual contracts — ViewState, ViewEffect, ViewEvent — are identical to the original article. The file-per-feature convention (keeping all three in one file per screen) is still the recommendation. The process() entry point and copy()-based state mutation are unchanged. This evolution is purely in the plumbing, not the pattern.

Thanks for reading!
Rohit Surwase

If you liked this article, clap clap clap 👏👏👏 as many times as you can.

Best of MVVM and MVI architecture patterns merged into one, for a perfect architecture for any Android project.

TL;DR
If you are already aware of basic principles of architecture patterns and MVVM and MVI patterns in detail then skip the basics and jump to MVI + LiveData + ViewModel (or second) section of the article.

Preface

There are so many architecture patterns available, each has some pros and cons. All those patterns try to achieve the same basic principles of architecture:

1. Separation of concerns (SoC): It is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern. A concern is anything that matters in providing a solution to a problem.

This principle is closely related to the Single Responsibility Principle of object-oriented programming which states that “every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function.” -Wikipedia

2. Drive UI from a model: App should drive UI from a model, preferably a persistent model. Models are independent from the View objects and app components, so they're unaffected by the app's life-cycle and the associated concerns.

Let’s also look at the summary of some popular architecture patterns-

⭐ MVC Architecture:

Model-View-Controller architecture by Trygve Reenskaug is the base of all modern architecture patterns. Let’s see the responsibility of each component defined on it’s Wikipedia page-

* The model is responsible for managing the data of the application. It receives user input from the controller.
* The view means presentation of the model in a particular format.
* The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.

So, the model is responsible for representing state, structure, and behavior of the view and view is nothing but the representation of that model.

⭐ MVVM Architecture:

In Model-View-ViewModel architecture, view has the instance of ViewModel and it calls respective function based on the user input/action. Also, view observes different observable properties of ViewModel for changes. ViewModel processes user input based on the business logic and modifies respective observable property.

⭐ MVI Architecture:

In Model-View-Intent architecture, view exposes view-events (user input/action) and observes model for view-state changes. We process view-events and convert them into respective intent and pass it to the model. The model layer creates a new immutable view-state using intent and previous view-state. So, this way it follows the Unidirectional Data Flow principle i.e. data flows only in one direction: View > Intent > Model > View.

In summary, the best part of MVVM architecture is ViewModel but I think, it does not follow the concept of model defined in MVC pattern, as, in MVVM DAO (Data Access Object) abstraction is considered as model and view observes multiple observable properties from ViewModel for state changes and view is not driven by model, directly. Also, these multiple observable properties from ViewModel can cause state overlapping issue (two different states being shown unexpectedly).

MVI pattern solves this problem by adding an actual ‘model’ layer which is observed by view for state changes. As this model is an immutable and single source of truth for the current view state, state overlapping will not happen.

In the following architecture, I tried to combine the best of MVVM and MVI patterns for a better architecture of any Android project, on top of that I abstracted as many things as possible by creating base classes for View and ViewModel.

🌟 MVI + LiveData + ViewModel = ❤️ Architecture:
Before proceeding, let’s reemphasize some basic terms from MVI architecture:
ViewState: As the name suggests this is part of the model layer, and our view observes this model for state changes. ViewState should represent the current state of the view at any given time. So this class should have all the variable content on which our view is dependent. Every time there is any user input/action we will expose modified copy (to maintain the previous state which is not being modified) of this class. We can create this model using Kotlin’s data class.

ViewEffect: In Android, we have certain actions that are more like fire-and-forget, for example- Toast, in those cases, we can not use ViewState as it maintains state. It means, if we use ViewState to show a Toast, it will be shown again on configuration change or every time there is a new state unless and until we reset its state by passing ‘toast is shown’ event. And if you do not wish to do that, you can use ViewEffect as it is based on SingleLiveEvent and does not maintain state. ViewEffect is also part of our model, and we can create it using Kotlin’s sealed class.

ViewEvent: It represents all actions/events a user can perform on the view. This is used to pass user input/action to the ViewModel. We can create this event set using Kotlin’s sealed class.

I suggest you, keep these three classes in a single file as it will give you an overall idea of all doable actions and variable content being handled by the target view.

Now, let’s dive deeper into the architecture:

The above diagram may have given you the core idea of this architecture. If not, the core idea of this architecture is, we are including an actual immutable model layer in the MVVM architecture and our view is dependent this model for state changes. This way ViewModel will have to modify and expose this single model.

To avoid redundancy and simplify the use of this architecture in multiple places, I have created two abstract classes one for our view (separate for activity, fragment, custom-view) and one for ViewModel.

AacMviViewModel: A generic base class to create ViewModel. It needs three classes STATE, EFFECT, and EVENT. We have already seen an example of these classes above.

As you can see we have viewState: STATE and viewEffect: EFFECT and two private LiveData containers _viewStates: MutableLiveData<STATE> and _viewEffect: SingleLiveEvent<EFFECT> which are being exposed using public functions viewStates() and viewEffects(). Please note we are extending AndroidViewModel as it will allow us to use the Application context (only) if required. Moreover, we are logging each viewEvent, that we will be processing.

This is how we create a ViewModel for any of our activity/fragment/view:

All we have to do is initialize viewState inside init{} block and modify the viewState further using copy() function of the data class whenever required. Please do not modify the same instance of viewState instead modify its copy, this way we are keeping ViewState immutable. If you modify the same instance of viewState, you may encounter an unexpected behavior as you may change some properties which are being processed by the view.

viewState = viewState.copy(fetchStatus = FetchStatus.Fetched, newsList = result.data)

That’s it, the rest of the part (i.e. _viewStates.setValue() ) is being handled by the AacMviViewModel class.

AacMviActivity: A generic abstract class to create compatible Activities for this architecture.
(Please refer this repository for generic classes required for fragment and custom-views.)

It has viewModel , renderViewState() and renderViewEffect() abstract properties/functions which we need to implement. Also, it creates viewStateObserver, viewEffectObserver LiveData-Observers internally and starts observing viewStates() and viewEffects() exposed by the ViewModel in onCreate() of the Activity. So, this abstract activity does everything that we would have to do anyway inside each activity. Moreover, it logs each observed viewState and viewEffect.

Now, creating a new activity for this architecture is very easy:

That’s all, with this we have everything in place, working seamlessly, logging each action and content we are processing. No chance of state overlapping as the model is a single source of truth for the view’s state change.

Note: If you are new to this ‘model-driven UI’ you may think we are adding more complexity than straight forward processing as for some complex views ViesState data class will have so many properties as it has to have content for each widget and its visibility and so on. But believe me, it will pay off as tracking down the cause of any issue/crash will be super easy.

Further Improvements:
1. Many of you would suggest using ConflatedBroadcastChannel as it posts the latest values only but it is still experimental so I preferred to use LiveData. And anyway even if we decide to use ConflatedBroadcastChannel/Flow in the future, we will have to modify the abstract classes only.

2. What if we have single activity and multiple fragments or custom-views? How can we communicate between activity-to-fragment, fragment-to-fragment? F̵o̵r̵ ̵t̵h̵i̵s̵ ̵u̵s̵e̵ ̵c̵a̵s̵e̵,̵ ̵w̵e̵ ̵h̵a̵v̵e̵ ̵i̵n̵t̵r̵o̵d̵u̵c̵e̵d̵ ̵D̵a̵t̵a̵S̵t̵o̵r̵e̵,̵ ̵m̵o̵r̵e̵ ̵o̵n̵ ̵t̵h̵i̵s̵ ̵i̵n̵ ̵t̵h̵e̵ ̵n̵e̵x̵t̵ ̵a̵r̵t̵i̵c̵l̵e̵.̵
Update: The moment I started to write about our DataStore implementation, I realized it was breaking MVI’s core concept, so dropped that idea.

For a detailed version (with some improvements) of this architecture that handles Activities, Fragments, and Custom Views with an example, please check out this GitHub repository.

Credits & References:
⚈ Special thanks to my colleagues Aalap Shah and Akhilesh Swarnkar for questioning each component/concept that I have used and helping me evolve this architecture. We had so many discussions over the incremental iteration of this architecture. Thanks to both of you for asking me to minimize and simplify as many things as possible so further implementation becomes easy.
⚈ Official guide on MVVM Architecture
⚈ MVI Architecture by Hannes Dorfmann
⚈ MVI Architecture by Etienne Caron & this example
⚈ MVC Architecture - Wikipedia
⚈ Concept of ViewEffect by Kaushik Gopal
⚈ Kotlin Backing Properties
⚈ Wikipedia- Separation of concerns & Single responsibility principle
⚈ GitHub: source code and example

Thanks for reading!
Rohit Surwase

If you liked this article, clap clap clap 👏👏👏 as many times as you can.

Best Architecture For Android : MVI + LiveData + ViewModel = ❤️ was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am sure, most Android developers are aware of Firebase Test Lab and Google Play Console Pre-launch Report. These are really useful tools. Today, I am not gonna explain why, when and how to use those tools. But, I am gonna tell you, how can we get the most out of those tools with minimum efforts. So, before we begin with our topic, let me take everyone on the same page.

Robo Script:

Robo Test (similar to Monkey Test) is a test performed by a robo on the target app which usually performs random actions by clicking random UI elements. But, that is not what we want. For example, we might want to test a new user onboarding flow or day-night mode. So, random actions would not satisfy our needs. We would want to have control over robo actions. That’s where robo scripts come into play. Robo Script is a JSON file that has a set of actions (commands that robo can understand 😊) that robo can perform in the given order. And, creating this robo script is also simple, all you have to do is record yourself walking through the desired workflow using Android Studio. You can find this recording option under Android Studio > Tools > Firebase > Test Lab > Record Robo Script. Once done, you have to upload the script file on the Firebase Test Lab and Google Play Console Pre-launch Report console, separately.

Problem:

Whether it is Firebase Test Lab or Google Play Console Pre-launch Report the robo scripts we have recorded and uploaded do not work as expected most of the time. It fails in-between and we have to retry with another script. But we are already short on the number of retries we can get as Play Console Pre-launch Report runs only when we upload a new APK and with the free plan of Firebase Test Lab, we are allowed to run tests only once in 24hrs. So, there should be a way to test those robo scripts multiple times, locally before we upload it on the console. How can we do this?

After searching in every possible way I was pretty sure that this is not possible as of now so I decided to request this feature as a part of Firebase Assistance Tool in Android Studio. I sent the feature request and I got a response too. Noel from Firebase Support team responded and informed me that this is an interesting feature that can be considered and forwarded it ahead. And after a few days, Noel came up with the solution that he got from the team. Here is the elaborated version of the solution given by him.

Solution:

You might have heard about App Crawler, it is part of Android Jetpack and works the same as Robo Test, that too locally. But the official doc or any other source does not say that we can provide a Robo Script to the App Crawler, right? Let’s see-

Here are the steps to setup App Crawler that can be used for our purpose
(I am assuming you already have a recent version of Android SDK)-

Step 1: Download the crawler binary archive and extract to the directory of your choice.
Step 2: Start an emulator or connect a physical device using a USB cable.
Step 3: Open the terminal/command window where you have extracted the app-crawler binary.

That’s all, simple, isn’t it?

Step 4: You can invoke the crawler to test target apk with random actions, just the way Test Lab does, using the following command-

java -jar crawl_launcher.jar --apk-file <apk-path> --android-sdk <android-sdk-path>

Now, here is the catch, Can we provide our robo script to app crawler? Yes… we can… though the official doc does not say anything about this feature. Thankfully, I got to know about this from Noel and the team.

Step 5: Provide a Robo script to the App crawler using following command-line option-

— robo-script-file <robo-script-path>

java -jar crawl_launcher.jar --robo-script-file <robo-script-path> --apk-file <apk-path> --android-sdk <android-sdk-path>

Hurray! Mission accomplished.

Now, that we can run and test the robo scripts locally, it is time to fix them. For that, we can use logcat files generated by App Crawler, it is stored under the build > crawl_output directory.

I hope, this helps you.

Useful Resources:

1. Firebase Test Lab Robo tests
2. Setup App Crawler
3. Use pre-launch reports to identify issues : Control how the pre-launch report explores your app

Thanks for reading!
Rohit Surwase

If you liked the article, clap clap clap 👏👏👏 as many times as you can.

LIKED SO MUCH! Medium allows up to 50 claps.
Also, post a Tweet on Twitter.

Let’s be friends on LinkedIn, Medium, Twitter and GitHub.

Best Architecture For Android : MVI + LiveData + ViewModel = ❤️

Test Robo Scripts Locally: Useful For Firebase Test Lab & Pre-launch Reports was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is a part of “Android Kotlin Coroutines: Basic Terminologies & Usage” article.

Updated (30 Oct 2018) for stable Kotlin plugin v1.3.
Note: Now onward, this post will not be updated unless required. So, it would be better if you add required dependencies from the official doc: https://github.com/Kotlin/kotlinx.coroutines

Here we are going see the steps involved in adding the stable version of Coroutines included in Kotlin v1.3.

Android Studio:
Step 1. Go to Tools → Kotlin → Configure Kotlin Plugin Updates, select “Stable” in the Update channel drop-down list, and then click Check for updates.

Step 2. Add following lines to your project level build.gradle
(As EAPs are not public we need to add private URL)

dependencies {
    //...
    classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.0'
}

Step 3. Add following lines to your app/module level build.gradle
We are adding coroutines-core along with coroutines-android.

dependencies {
    //...
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.0.0'
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.0.0'
}

Now, sync your project with gradle files and you are ready use the latest Coroutines.

Thanks for reading!
Rohit Surwase

If you liked the article, clap clap clap 👏👏👏 as many times as you can.

LIKED SO MUCH! Medium allows up to 50 claps.
Also, post a Tweet on Twitter.

Let’s be the friends on LinkedIn, Medium, Twitter and GitHub.

Best Architecture For Android : MVI + LiveData + ViewModel = ❤️

Add Stable Coroutines to Android-Kotlin Project was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

The common terms used in Coroutines. Knowing these terms in advance will ease your learning process.

This article is a brief summary of official Kotlin doc and a few other resources that I have gone through over time during my learning. This is my attempt to simplify common terms used in the context of coroutines and give you the taste of the power, coroutine gives you which would inspire you to jump in the world of coroutines as asynchronous or non-blocking programming is a new reality.

Developing Apps using Kotlin is really fun. Code less, perform better suits very well for Kotlin. And with coroutines, it becomes sweeter. Coroutines are now stable and can be used within an early-access-preview version of Kotlin v1.3. So, it is the best time to learn about coroutines and start using it in your Android projects.

What are Coroutines?

“A coroutine is an instance of suspendable computation, conceptually similar to a thread, in the sense that it takes a block of code to run and has a similar life-cycle, it is created and started, but it is not bound to any particular thread. It may suspend its execution in one thread and resume in another one. Moreover, like a future or promise, it may complete with some result or exception.”

Coroutines are lightweight threads and they are so cheap to create which open the doors to asynchronous programming for developers. This means we can call more than one functions asynchronously and get the result in a shorter duration in very effective way. Now imagine how faster our validations would be as we can call them asynchronously. All those things (API calls, Database access…) which need a background thread to process are just a few lines away than creating separate worker threads for it and then managing it. And making coroutines life-cycle aware is so simple.

suspend fun validateEntries(str: String): Boolean =
    coroutineScope {
        val deferred1 = async { firstValidation(str) }
        val deferred2 = async { secondValidation(str) }
        deferred1.await() && deferred2.await()
    }

Coroutine is language feature of Kotlin, it means Kotlin provides core level APIs (like suspending function) which enable various other libraries to utilize coroutines such as kotlinx.coroutines, a library developed by JetBrains which need to be added in any Kotlin project which provides a number of high-level coroutine-enabled primitives. Otherwise, you can directly use core level APIs to build your own.

If you are curious about adding the latest stable version of coroutines to your project, you can refer the link I have shared at the end of this article.

Suspending Function

“A suspending function (marked with suspend modifier) may suspend the execution of the code without blocking the current thread of execution by invoking other suspending functions.” So how does it work? Instead of returning just result, a suspending function also returns context which is used by the caller. In simple words, it is a function which executes a part of the code and then suspends while keeping the context and reference to the remaining code (like a lambda consisting remaining code). So whenever the function resumes it has the context and the remaining code that need to be executed. Suspending functions are only allowed to be called from a coroutine or another suspend function.

CoroutineBuilder

“A function that takes some suspending lambda (lambda marked with suspend modifier) as an argument, creates a coroutine, and, optionally, gives access to its result in some form.”

fun suspendableLambda(block: suspend () -> Unit) = //...

Few of coroutine builders provided by kotlinx.coroutines:
launch {}: Launch a coroutine that does not have any result, it returns Job.
async{}: Returns a single value result using Deffered- a light-weight non-blocking future that represents a promise to provide a result later. So, we can use .await() on a deferred value to get its eventual result, but Deferred is also a Job, so we can cancel it if needed.
runBlocking{}: Blocks current thread until the execution of coroutine.

delay is a special suspending function that does not block a thread but suspends coroutine.

CoroutineScope

Each coroutine run inside a scope defined by us, so we can make it application wide or specific for a view with well-defined life-cycle such as Activities or Fragments. Every coroutine builder is an extension on CoroutineScope. Each coroutine waits for all the coroutines inside their block/scope to complete before completing themselves.
CoroutineScope provides properties like coroutineContext and it is a set of various elements like Job of the coroutine and its dispatcher. We can check whether coroutine is active or not using isActive property of Job. GlobalScope is used to launch a coroutine with a lifetime of the whole application.

CoroutineDispatcher

CoroutineDispatcher can confine (restrict) coroutine execution to a specific thread, dispatch it to a thread pool, or let it run unconfined (unrestricted). It means CoroutineDispatcher determines what thread or threads the corresponding coroutine uses for its execution.

kotlinx.coroutines provides following dispatchers:
Dispatchers.Default: Used by all standard builder if no dispatcher is specified. It uses a common pool of shared background threads. This is an appropriate choice for compute-intensive coroutines that consume CPU resources.
Dispatchers.IO: Uses a shared pool of on-demand created threads and is designed for offloading of IO-intensive blocking operations (like file I/O and blocking socket I/O).
Dispatchers.Unconfined — Unrestricted to any specific thread or pool and should not be used normally in code. There will be certain use-cases where we might need to use this.
newSingleThreadContext: To create new private single-threaded coroutine context.
newFixedThreadPoolContext: To create private thread pool of fixed size.
asCoroutineDispatcher: Extension function to convert Executor to dispatcher.

All coroutines builders like launch and async accept an optional CoroutineContext parameter that can be used to explicitly specify the dispatcher for new coroutine and other context elements. So, launch(Dispatchers.Default) { ... } uses the same dispatcher as GlobalScope.launch { ... }.

Job

“Conceptually, a job is a cancellable thing with a life-cycle that destroys on its completion. It can be arranged into parent-child hierarchies where cancellation of the parent leads to an immediate cancellation of all its children. Failure or cancellation of a child with an exception other than CancellationException immediately cancels its parent. This way, a parent can cancel its own children (including all their children recursively) without canceling itself.”
We can make a job non-cancellable using NonCancellable . Also, we can make a coroutine to cancel itself after timeout using withTimeout function.

Recently, I have started a series which covers MVP & Architecture Components in Kotlin with basic examples without any libraries to give you the exact idea of these patterns.

Best Architecture For Android : MVI + LiveData + ViewModel = ❤️

Actors

An actor is a combination of a coroutine state, behavior and a channel to communicate with other coroutines. Actor processes stream of messages. It can also be used for tasks that should not be performed concurrently. This is useful when we do not want to respond to all back-to-back (unnecessary) clicks by a user on a button but only first or recent click.

Channels

Channel is a non-blocking primitive for communication between sender and receiver. It has suspending operations instead of blocking ones. It provide a way to transfer a stream of values between coroutines. Channels are (till mid of October ’18) an experimental feature of kotlinx.coroutines.

Structured Concurrency

In general programming, threads are global by default but coroutines are always related to some local scope like a UI element with well-defined life-cycle. And we should launch coroutines in the specific scope of the operation we are performing.

Android

In Android, we need a coroutine dispatcher context that restricts the coroutine execution to main UI thread. This can be achived by adding Android specific kotlinx-coroutines-android library dependency along with core library mentioned above. It provides Dispatchers.Main context for Android applications.

I hope, I was able to give you some basic idea of coroutines. If you think I have missed something or something need to be improved/corrected, please comment, I would do necessary changes.

Also, check out Linkaive App, an app to save news, articles, and all useful links for later. One of the best app for users who like to have a collection of their favorite links. I am redesigning this app using Kotlin and Architecture Components.

Linkaive: Save For Later - Apps on Google Play

Link to Add Stable Coroutines to Android-Kotlin Project article.

References & Further Readings

1. Official coroutines guide: https://kotlinlang.org/docs/reference/coroutines-overview.html
2. Exploring Coroutines in Kotlin: https://www.youtube.com/watch?v=jT2gHPQ4Z1Q
3. kotlinx.coroutine library: https://github.com/Kotlin/kotlinx.coroutines
4. Core primitives to work with coroutines: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/
5. Guide to UI programming: https://github.com/kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md
6. Structured Concurrency: https://medium.com/@elizarov/structured-concurrency-722d765aa952

Thanks for reading!
Rohit Surwase

If you liked the article, clap clap clap 👏👏👏 as many times as you can.

LIKED SO MUCH! Medium allows up to 50 claps.
Also, post a Tweet on Twitter.

Let’s be the friends on LinkedIn, Medium, Twitter and GitHub.

Few of my other articles:

• Introverts Decoded: Unspoken Dilemma While In Love
• Introverts Decoded

Android Kotlin Coroutines: Basic Terminologies & Usage was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR
Practically it is not feasible to summaries the MVP pattern here in few lines. But I can assure you that every single line of the following article worth your time. I bet it will give you enough understanding that you can implement it on your own. And still, if you are in a hurry I would suggest jumping at “How does MVP works?” section. Source code of the example.

Whenever any Android developer starts thinking of improving technical skills, the first thing that comes to his or her mind is the Architecture of the App. Not to mention that they already know the pain involved in maintaining the standard code-base after it grows.

I did the same and learned about architectures and later chosen to focus on MVP. After trying it with test projects and later production apps, I moved to learn Kotlin language, and now the latest Architecture Components. But during this transition, I realized that there are very few to none; examples showcasing the implementation of these concepts in Kotlin. So, here I am with these examples showing the implementation of some architectural patterns in Kotlin. I promise you that these examples are gonna be so simple that you can grasp the core of these concepts with ease.

In this series I will target two main architectural patterns: Model -View-Presenter & Android Architecture Components.

1. Android App Architectures: MVP Example With Kotlin (This)
2̵.̵ ̵A̵n̵d̵r̵o̵i̵d̵ ̵A̵r̵c̵h̵i̵t̵e̵c̵t̵u̵r̵e̵ ̵C̵o̵m̵p̵o̵n̵e̵n̵t̵s̵ ̵E̵x̵a̵m̵p̵l̵e̵ ̵W̵i̵t̵h̵ ̵K̵o̵t̵l̵i̵n̵
3̵.̵ ̵A̵n̵d̵r̵o̵i̵d̵ ̵A̵r̵c̵h̵i̵t̵e̵c̵t̵u̵r̵e̵ ̵C̵o̵m̵p̵o̵n̵e̵n̵t̵s̵:̵ ̵A̵d̵v̵a̵n̵c̵e̵m̵e̵n̵t̵s̵
4. Best Architecture For Android : MVI + LiveData + ViewModel = ❤️

Model-View-Presenter (MVP) with Kotlin

While designing the architecture of any software the basic principle to keep in mind is the separation on concerns. MVP is one of the best pattern to separate presentation layer from the business logic. Moreover MVP also helps you easily implement more advanced, complete architecture patterns like Clean Architecture.

Here I am not gonna answer questions like WHAT and WHY but HOW.
How to use MVP? How does it work? and How to implement it using Kotlin?
So in this 1st article we will see the implementation of MVP using Kotlin.

View

Who: Combination Activity/Fragment/View and its contract i.e. interface.
Purpose: Do all UI related stuff and all that needs Android context.
Job: Whenever it needs to do some action, it should trigger respective function of Presenter using object. It should not have any business logic.

Though the XML layout is part of the view, it is not alone called as View. All necessary functions are added to our Activity/Fragment/View via contract/interface. Adapters are also the part of the View. Activity/Fragment/View directly initializes Presenter including Model indirectly as Presenter initializes Model in its constructor.

Example tasks:
- Show/hide progress bar.
- Request data to be shown and later show received data/error.
- Get LayoutInflater, Resources, Android System Services.

Presenter

Who: It is a separate class which should not have Android context.
Purpose: Act as a mediator between two main layers of the architecture View and Model.
Job: Trigger respective function of Model depending on the request made by View.

Presenter has the objects of View and Model. It should not have any business logic. Moreover, it should not have direct access to any UI elements.

Model

Who: Database, models (schema), API calls and all other business logic is part of this layer. This is where all business logic will be located.
Purpose: To separate business logic so we can test it in isolation without View. This also helps us to reuse code-base across platforms.
Job: Get/calculate data or error to shown on the UI.

This is where we should make API, Database calls, and other calculations.
But to make it more solid, we can add one more layer inside Model:

Repository:
Decides the source of the data to be shown depending on the predefined conditions. It means it will get the data from offline or online sources depending on the conditions like network availability.
(To keep things simple, the included app does not have repository layer.)

This way our Model will get the data to be shown irrespective of the network conditions.

Recently, I have published an article on Coroutines, check out-

Android Kotlin Coroutines: Basic Terminologies & Usage

How does MVP works?

In brief words: View calls functions of Presenter, Presenter transfers it to Model, Model requests the data to be shown. After Model gets the data, it passes it to Presenter and Presenter passes it to View where View shows that data on the screen.

Direct Communication of:
View ==> Presenter ==> Model

Indirect Communication using contract/interface:
Model =/=> Presenter =/=> View

Here is the simple workflow diagram of MVP in Android. I request all to spend a few minutes with the following illustration, it will help you a lot to understand MVP in Android.
Note: Model is referred to as Interactor.

I hope I was clear enough to make this understandable.
Here is the complete source code of the example.

RohitSurwase/Android-Architectures-Kotlin

Thanks for reading!
Rohit Surwase

If you liked the article, clap clap clap 👏👏👏 as many times as you can.

LIKED SO MUCH! Medium allows up to 50 claps.
Also post a Tweet on Twitter.

Let’s be the friends on LinkedIn, Medium, Twitter and GitHub.

Also, check out few other stories published by me:

• Introverts Decoded: Unspoken Dilemma While In Love
• Introverts Decoded

Android App Architectures: Example of MVP with Kotlin was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update 1: Included lambda functions as an alternative.
Update 2: Included a link to Implementation example App on GitHub.

TL;DR
Instead of creating a custom ItemClickListener interface to getAdapterPosition() inside your Activity/Fragment/View and end up creating multiple Anonymous Classes under the hood for each item. Better pass the RecyclerView.ViewHolder using view.setTag() inside your ViewHolder and then getAdapterPosition() (…and many other things) from view.getTag() i.e. ViewHolder’s object inside your Activity/Fragment/View.
Implementation example App on GitHub

The Most Popular Way; The Problem

I know you must have already found a way to get onItemClickListener() for your RecyclerView Adapter. But sometimes the way we think is not always the correct or a better way. Whenever anyone tries to find a way to getAdapterPosition() inside their Activity/Fragment/View. He or she comes across the well-known pattern of creating a custom interface with view and position as the parameters.

public interface ItemClickListener {
    void onItemClick(View view, int position);
}

Later, we initialize the ItemClickListener instance using the public setter.

private ItemClickListener onItemClickListener;

...

public void setItemClickListener(ItemClickListener clickListener) {
    onItemClickListener = clickListener;
}

OR… by passing the ItemClickListener instance via constructor.

And finally we pass our view and adapter position to the listener.

And we know the rest of the part very well.
Most of the articles out there depict the same thing. But there is a problem.

When we say itemView.setOnClickListener(new View.OnClickListener()…

It creates an Anonymous inner class under the hood which implements our ItemClickListener listener.

class AnonymousItemClickListener implements ItemClickListener{
    @Override
    public void onItemClick(View view, int position) {
        
    }
}

And we end up creating and initializing multiple Anonymous inner classes under the hood just for a click listener.

new AnonymousItemClickListener(){
        @Override
        public void onItemClick(View view, int position) {
            
        }
    };

I used to do the same. Because that is what we get to see all over the internet.

Introverts Decoded: Unspoken Dilemma While In Love

Update:
As suggested by Sachin Chandil in the comments section, we can use Java8’s Lambda functions to get rid of anonymous class creation at compile time. Lambda functions work with SAM types (interfaces with Single Abstract Method) and the reason it does not create anonymous inner class is the InvokeDynamic instruction, introduced in Java 7.
So with Lambdas, we can convert above function as below:

itemView.setOnClickListener(view -> onItemClickListener.onItemClick(view, getAdapterPosition());

And for some reasons you can not use Java8’s Lambda functions then go ahead as following way is still a better option for you.

A Better Way; The Solution

But, recently I got a suggestion from a colleague to implement it in a better and lighter way. Let’s see how we can get adapter position, item id (…and many other things) inside our Activity/Fragment/View.

So, instead of creating new custom interface, we will use View.OnClickListener and initialize it in the way we used to do.

private View.OnClickListener onItemClickListener;

...

public void setItemClickListener(View.OnClickListener clickListener) {
    onItemClickListener = clickListener;
}

And we will pass the instance of ViewHolder via itemView to the listener using setTag().

private class MyViewHolder extends RecyclerView.ViewHolder {
    public MyViewHolder(View itemView) {
        super(itemView);
        itemView.setTag(this);
    }
}

In this way, we do not need to create Anonymous inner class as we can directly give the reference of onItemClickListener

private class MyViewHolder extends RecyclerView.ViewHolder {
    public MyViewHolder(View itemView) {
        super(itemView);
        itemView.setTag(this);
        itemView.setOnClickListener(onItemClickListener);
    }
}

Finally we can get adapter position and item id (…and many other things) inside our Activity/Fragment/View from the ViewHolder instance.

RecyclerView.ViewHolder viewHolder = (RecyclerView.ViewHolder) view.getTag();

int position = viewHolder.getAdapterPosition();
// viewHolder.getItemId();
// viewHolder.getItemViewType();
// viewHolder.itemView;

Simple! Isn’t it?
Let me know your views and suggestions about this in the comment section.

If you still have some doubts, here is the source code of the Implementation example App on GitHub.

Thanks for reading!
Rohit Surwase

If you like the article, clap clap clap 👏👏👏 as many times as you can.

LIKED SO MUCH! Medium allows up to 50 claps.
Also post a Tweet on Twitter.

Let’s be the friends on LinkedIn, Medium, Twitter and GitHub.

Latest stories by me

Best Architecture For Android : MVI + LiveData + ViewModel = ❤️

Android RecyclerView onItemClickListener & getAdapterPosition(): A Better Way was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Things they never tell anyone else.

Updated title of the article from “Introverts Decoded: Why am I still single?”

LOVE, love is a romantic yet a scary word for many introverts. For introverts, it is not easy to fall in love. Love takes away so many things from them, more importantly, solitude. In the first article of Introverts Decoded, we have seen how different they are from many others. We have seen they are loving and caring by heart.
Then, why are they still single? Why are they scared of falling in love? How could not everyone see their inner beauty?
Let’s see if we can find the answer.

Introverts Decoded

We know, we all are carried in two different directions by our heart and mind. The problem with introverts is that their mind is much stronger than their heart. Though they have one loving and caring heart but always dominated by their ruthless mind. This is why they are different and this is why they are introverts.

A battle starts within them-self whenever they fall in love with someone. A never-ending battle until any one of it wins. The battle is between their heart and mind. The heart strives for its love and the mind strives for its priorities, both are already firm in their fields. If heart wins then the love, the one also becomes the priority and if mind wins the heart has to sacrifice the love. But why does this happen?

Introverts work in a strange way. The work they do, the time they spend is always organized by their priorities. This is why they never feel lonely, this is why they are always busy with something meaningful. Their loved ones always have the highest priority with all exceptions. But reaching to that level is really difficult for anyone. It seems rare that they approach someone so instantly though they can sense any person in the first interaction. They wait until they pass through all stages of their mind. Like- Is it lust? Is it obsession? or Is it just their thoughts? Once they are assured that they actually like the one their heart starts making moves. And this is where the problem begins.

Wanna See! How does it go inside? Let’s see the conversation between heart ❤ and mind of an introvert.

Heart ❤: Let’s plan something, so we can spend some time together. Let’s call her out.
Mind: Oh! Come on bro! She is not interested in you.
Heart❤: Yeah! But why would anyone be interested in me if I never show up?
Mind: Don’t you have anything to do? Get back to work.
Heart❤: But I like her.
Mind: I know! But aren’t we both happier together?
Heart❤: Yes! We are… but sometimes I need someone, the one.
Mind: But you already have so many. Do not open up yourself until you are sure.

And it goes on…

Somehow the heart ❤ succeeds in calling her out, the mind settles for a while.
Now if she says YES!, the mind will allow the heart ❤ to continue. And if she says NO!, then the end of the story before it begins. Next time mind will come up with thousands of reasons to not to try again.

Here is the difference between others and introverts. Others try several times while introverts’ heart ❤ can try only fewer times. They will choose to lose the one than to run behind him or her. Harsh but the truth!

The stronger my heart tries to make a move closer to the one, the harder my mind tries to control and even suppress my feelings.
My poor heart.

Whoever they are it is just because of the combination of their loving heart and commanding mind. The mind regulates priorities to the things and the people which helps them to focus on fewer but important stuff. This enables their loving heart to spread whatever it has among those very close to it.

The tragedy is, no-one will get to see their inner beauty unless he or she gets on their priority list. You need to show real interest in them, to know them. But, you would ask: how could anyone be interested in anyone without knowing anything about him or her? It is possible, it is possible because you already got intuitions from him or her, you just need to trust in those. Snap-judgments which tells you that he or she is not exactly same as everyone knows, he or she has something different hidden inside. Remember! They are very good at catching lies, observing people, so never try that way. Once you are able to open the locked doors of their heart, they are all yours.

“If you are ever lucky enough to find a weirdo, never let them go.” -Matthew Gray Gubler

It is not like, introverts do not fall in love but it is the fact that the one has to try harder. His or her love must be compelling enough to set their heart free from their mind, to get himself or herself on their priority list.

If you like the article, clap clap clap 👏👏👏 as many times as you can. It inspires me to come up with more beautiful articles.
LIKED! Share on Facebook, LinkedIn, WhatsApp.

LIKED SO MUCH! Medium allows up to 50 claps.
Also post a Tweet on Twitter.

About: Rohit Surwase,
Techy by Birth. Writer by Hobby. Observer by Nature. Unpredictable by Character. Android Developer (Google Certified) by Profession.

Let’s be the friends on LinkedIn, Medium, Twitter and GitHub.

Previous article of this series: Introverts Decoded

Introverts Decoded

Introverts Decoded: Unspoken Dilemma While In Love was originally published in P.S. I Love You on Medium, where people are continuing the conversation by highlighting and responding to this story.