Efficient Android, Half 2: Practical Reactive Programming

Practical reactive programming (FRP) is a paradigm that mixes the reactivity from reactive programming with the declarative perform composition from purposeful programming. It simplifies advanced duties, creates elegant consumer interfaces, and manages state easily. As a consequence of these and plenty of different clear advantages, using FRP goes mainstream in cellular and net growth.

That doesn’t imply understanding this programming paradigm is straightforward—even seasoned builders might surprise: “What precisely is FRP?” In Half 1 of this tutorial, we outlined FRP’s foundational ideas: purposeful programming and reactive programming. This installment will put together you to use it, with an summary of helpful libraries and an in depth pattern implementation.

This text is written with Android builders in thoughts, however the ideas are related and useful to any developer with expertise basically programming languages.

Getting Began with FRP: System Design

The FRP paradigm is an countless cycle of states and occasions: State -> Occasion -> State' -> Occasion' -> State'' -> …. (As a reminder, ', pronounced “prime,” signifies a brand new model of the identical variable.) Each FRP program begins with an preliminary state that will probably be up to date with every occasion it receives. This program contains the identical parts as these in a reactive program:

• State
• Occasion
• The declarative pipeline (indicated as FRPViewModel perform)
• Observable (indicated as StateFlow)

Right here, we’ve changed the final reactive parts with actual Android elements and libraries:

There are a selection of Android libraries and instruments that may show you how to get began with FRP, and which are additionally related to purposeful programming:

• Ivy FRP: This can be a library I wrote that will probably be used for academic functions on this tutorial. It’s meant as a place to begin in your strategy to FRP however just isn’t meant for manufacturing use as is because it lacks correct help. (I’m presently the one engineer sustaining it.)
• Arrow: This is among the greatest and hottest Kotlin libraries for FP, one we can even use in our pattern app. It gives nearly every thing you want to go purposeful in Kotlin whereas remaining comparatively light-weight.
• Jetpack Compose: That is Android’s present growth toolkit for constructing native UI and is the third library we’ll use as we speak. It’s important for contemporary Android builders—I’d suggest studying it and even migrating your UI in the event you haven’t already.
• Circulation: That is Kotlin’s asynchronous reactive datastream API; althought we’re not working with it on this tutorial, it’s appropriate with many frequent Android libraries akin to RoomDB, Retrofit, and Jetpack. Circulation works seamlessly with coroutines and gives reactivity. When used with RoomDB, for instance, Circulation ensures that your app will all the time work with the newest information. If a change in a desk happens, the flows depending on this desk will obtain the brand new worth instantly.
• Kotest: This check platform gives property-based testing help related to pure FP area code.

Implementing a Pattern Toes/Meters Conversion App

Let’s see an instance of FRP at work in an Android app. We’ll create a easy app that converts values between meters (m) and toes (ft).

For the needs of this tutorial, I’m solely masking the parts of code very important to understanding FRP, modified for simplicity’s sake from my full converter pattern app. If you wish to observe alongside in Android Studio, create your undertaking with a Jetpack Compose exercise, and set up Arrow and Ivy FRP. You’ll need a minSdk model of 28 or larger and a language model of Kotlin 1.6+.

State

Let’s begin by defining the state of our app.

// ConvState.kt
enum class ConvType {
	METERS_TO_FEET, FEET_TO_METERS
}

information class ConvState(
    val conversion: ConvType,
    val worth: Float,
    val outcome: Possibility<String>
)

Our state class is pretty self-explanatory:

• conversion: A sort describing what we’re changing between—toes to meters or meters to toes.
• worth: The float that the consumer inputs, which we’ll convert later.
• outcome: An non-obligatory outcome that represents a profitable conversion.

Subsequent, we have to deal with the consumer enter as an occasion.

Occasion

We outlined ConvEvent as a sealed class to characterize the consumer enter:

// ConvEvent.kt
sealed class ConvEvent {
    information class SetConversionType(val conversion: ConvType) : ConvEvent()

    information class SetValue(val worth: Float) : ConvEvent()

    object Convert : ConvEvent()
}

Let’s study its members’ functions:

• SetConversionType: Chooses whether or not we’re changing from toes to meters or from meters to toes.
• SetValue: Units the numeric values, which will probably be used for the conversion.
• Convert: Performs the conversion of the inputted worth utilizing the conversion sort.

Now, we’ll proceed with our view mannequin.

The Declarative Pipeline: Occasion Handler and Operate Composition

The view mannequin accommodates our occasion handler and performance composition (declarative pipeline) code:

// ConverterViewModel.kt
@HiltViewModel
class ConverterViewModel @Inject constructor() : FRPViewModel<ConvState, ConvEvent>() {
    companion object {
        const val METERS_FEET_CONST = 3.28084f
    }

    // set preliminary state
    override val _state: MutableStateFlow<ConvState> = MutableStateFlow(
        ConvState(
            conversion = ConvType.METERS_TO_FEET,
            worth = 1f,
            outcome = None
        )
    )

    override droop enjoyable handleEvent(occasion: ConvEvent): droop () -> ConvState = when (occasion) {
        is ConvEvent.SetConversionType -> occasion asParamTo ::setConversion then ::convert
        is ConvEvent.SetValue -> occasion asParamTo ::setValue
        is ConvEvent.Convert -> stateVal() asParamTo ::convert
    }
// ...
}

Earlier than analyzing the implementation, let’s break down just a few objects particular to the Ivy FRP library.

FRPViewModel<S,E> is an summary view mannequin base that implements the FRP structure. In our code, we have to implement to following strategies:

• val _state: Defines the preliminary worth of the state (Ivy FRP is utilizing Circulation as a reactive information stream).
• handleEvent(Occasion): droop () -> S: Produces the following state asynchronously given an Occasion. The underlying implementation launches a brand new coroutine for every occasion.
• stateVal(): S: Returns the present state.
• updateState((S) -> S): S Updates the ViewModel’s state.

Now, let’s have a look at just a few strategies associated to perform composition:

• then: Composes two capabilities collectively.
• asParamTo: Produces a perform g() = f(t) from f(T) and a price t (of sort T).
• thenInvokeAfter: Composes two capabilities after which invokes them.

updateState and thenInvokeAfter are helper strategies proven within the subsequent code snippet; they are going to be utilized in our remaining view mannequin code.

The Declarative Pipeline: Extra Operate Implementations

Our view mannequin additionally accommodates perform implementations for setting our conversion sort and worth, performing the precise conversions, and formatting our finish outcome:

// ConverterViewModel.kt
@HiltViewModel
class ConverterViewModel @Inject constructor() : FRPViewModel<ConvState, ConvEvent>() {
// ...
    personal droop enjoyable setConversion(occasion: ConvEvent.SetConversionType) =
        updateState { it.copy(conversion = occasion.conversion) }

    personal droop enjoyable setValue(occasion: ConvEvent.SetValue) =
        updateState { it.copy(worth = occasion.worth) }

    personal droop enjoyable convert(
        state: ConvState
    ) = state.worth asParamTo when (stateVal().conversion) {
        ConvType.METERS_TO_FEET -> ::convertMetersToFeet
        ConvType.FEET_TO_METERS -> ::convertFeetToMeters
    } then ::formatResult thenInvokeAfter { outcome ->
        updateState { it.copy(outcome = Some(outcome)) }
    }

    personal enjoyable convertMetersToFeet(meters: Float): Float = meters * METERS_FEET_CONST
    personal enjoyable convertFeetToMeters(ft: Float): Float = ft / METERS_FEET_CONST

    personal enjoyable formatResult(outcome: Float): String =
        DecimalFormat("###,###.##").format(outcome)
}

With an understanding of our Ivy FRP helper capabilities, we’re prepared to investigate the code. Let’s begin with the core performance: convert. convert accepts the state (ConvState) as enter and produces a perform that outputs a brand new state containing the results of the transformed enter. In pseudocode, we will summarize it as: State (ConvState) -> Worth (Float) -> Transformed worth (Float) -> Outcome (Possibility<String>).

The Occasion.SetValue occasion dealing with is simple; it merely updates the state with the worth from the occasion (i.e., the consumer inputs a quantity to be transformed). Nevertheless, dealing with the Occasion.SetConversionType occasion is a little more attention-grabbing as a result of it does two issues:

• Updates the state with the chosen conversion sort (ConvType).
• Makes use of convert to transform the present worth primarily based on the chosen conversion sort.

Utilizing the ability of composition, we will use the convert: State -> State perform as enter for different compositions. You’ll have observed that the code demonstrated above just isn’t pure: We’re mutating protected summary val _state: MutableStateFlow<S> in FRPViewModel, leading to unintended effects at any time when we use updateState {}. Utterly pure FP code for Android in Kotlin isn’t possible.

Since composing capabilities that aren’t pure can result in unpredictable outcomes, a hybrid strategy is probably the most sensible: Use pure capabilities for probably the most half, and ensure any impure capabilities have managed unintended effects. That is precisely what we’ve completed above.

Observable and UI

Our last step is to outline our app’s UI and convey our converter to life.

Our app’s UI will probably be a bit “ugly,” however the objective of this instance is to show FRP, to not construct a phenomenal design utilizing Jetpack Compose.

// ConverterScreen.kt
@Composable
enjoyable BoxWithConstraintsScope.ConverterScreen(display: ConverterScreen) {
    FRP<ConvState, ConvEvent, ConverterViewModel> { state, onEvent ->
        UI(state, onEvent)
    }
}

Our UI code makes use of fundamental Jetpack Compose ideas within the fewest strains of code doable. Nevertheless, there’s one attention-grabbing perform value mentioning: FRP<ConvState, ConvEvent, ConverterViewModel>. FRP is a composable perform from the Ivy FRP framework, which does a number of issues:

• Instantiates the view mannequin utilizing @HiltViewModel.
• Observes the view mannequin’s State utilizing Circulation.
• Propagates occasions to the ViewModel with the code onEvent: (Occasion) -> Unit).
• Offers a @Composable higher-order perform that performs occasion propagation and receives the newest state.
• Optionally gives a strategy to cross initialEvent, which is named as soon as the app begins.

Right here’s how the FRP perform is applied within the Ivy FRP library:

@Composable
inline enjoyable <S, E, reified VM : FRPViewModel<S, E>> BoxWithConstraintsScope.FRP(
    initialEvent: E? = null,
    UI: @Composable BoxWithConstraintsScope.(
        state: S,
        onEvent: (E) -> Unit
    ) -> Unit
) {
    val viewModel: VM = viewModel()
    val state by viewModel.state().collectAsState()

    if (initialEvent != null) {
        onScreenStart {
            viewModel.onEvent(initialEvent)
        }
    }

    UI(state, viewModel::onEvent)
}

Yow will discover the total code of the converter instance in GitHub, and the whole UI code might be discovered within the UI perform of the ConverterScreen.kt file. For those who’d prefer to experiment with the app or the code, you possibly can clone the Ivy FRP repository and run the pattern app in Android Studio. Your emulator may have elevated storage earlier than the app can run.

Cleaner Android Structure With FRP

With a robust foundational understanding of purposeful programming, reactive programming, and, lastly, purposeful reactive programming, you might be able to reap the advantages of FRP and construct cleaner and extra maintainable Android structure.

The Toptal Engineering Weblog extends its gratitude to Tarun Goyal for reviewing the code samples offered on this article.