Efficient Android, Half 2: Practical Reactive Programming

Practical reactive programming (FRP) is a paradigm that mixes the reactivity from reactive programming with the declarative operate composition from purposeful programming. It simplifies complicated duties, creates elegant person interfaces, and manages state easily. On account of these and lots of different clear advantages, the usage of FRP goes mainstream in cellular and net growth.

That doesn’t imply understanding this programming paradigm is simple—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 helpful 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 shall be up to date with every occasion it receives. This program consists of the identical components as these in a reactive program:

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

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

There are a selection of Android libraries and instruments that may make it easier to get began with FRP, and which can be additionally related to purposeful programming:

• Ivy FRP: It is a library I wrote that shall be used for instructional functions on this tutorial. It’s meant as a place to begin on your strategy to FRP however will not be meant for manufacturing use as is because it lacks correct assist. (I’m at the moment the one engineer sustaining it.)
• Arrow: This is without doubt one of the greatest and hottest Kotlin libraries for FP, one we will even use in our pattern app. It supplies nearly every part you must 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 right now. It’s important for contemporary Android builders—I’d advocate studying it and even migrating your UI in case you haven’t already.
• Stream: That is Kotlin’s asynchronous reactive datastream API; althought we’re not working with it on this tutorial, it’s suitable with many widespread Android libraries corresponding to RoomDB, Retrofit, and Jetpack. Stream works seamlessly with coroutines and supplies reactivity. When used with RoomDB, for instance, Stream ensures that your app will at all times 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 take a look at platform provides property-based testing assist related to pure FP area code.

Implementing a Pattern Ft/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 mission with a Jetpack Compose exercise, and set up Arrow and Ivy FRP. You will have a minSdk model of 28 or greater 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 kind describing what we’re changing between—toes to meters or meters to toes.
• worth: The float that the person inputs, which we are going to convert later.
• outcome: An elective outcome that represents a profitable conversion.

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

Occasion

We outlined ConvEvent as a sealed class to signify the person 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 look at 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 shall be used for the conversion.
• Convert: Performs the conversion of the inputted worth utilizing the conversion kind.

Now, we are going to proceed with our view mannequin.

The Declarative Pipeline: Occasion Handler and Perform Composition

The view mannequin incorporates 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 Stream 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 operate composition:

• then: Composes two capabilities collectively.
• asParamTo: Produces a operate g() = f(t) from f(T) and a worth t (of kind 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 Perform Implementations

Our view mannequin additionally incorporates operate implementations for setting our conversion kind 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 operate that outputs a brand new state containing the results of the transformed enter. In pseudocode, we are able to summarize it as: State (ConvState) -> Worth (Float) -> Transformed worth (Float) -> Outcome (Possibility<String>).

The Occasion.SetValue occasion dealing with is easy; it merely updates the state with the worth from the occasion (i.e., the person inputs a quantity to be transformed). Nonetheless, dealing with the Occasion.SetConversionType occasion is a little more fascinating as a result of it does two issues:

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

Utilizing the ability of composition, we are able to use the convert: State -> State operate as enter for different compositions. You will have observed that the code demonstrated above will not be pure: We’re mutating protected summary val _state: MutableStateFlow<S> in FRPViewModel, leading to uncomfortable side effects each time 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 uncomfortable side effects. That is precisely what we’ve executed above.

Observable and UI

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

Our app’s UI shall be a bit “ugly,” however the purpose of this instance is to exhibit FRP, to not construct an exquisite design utilizing Jetpack Compose.

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

Our UI code makes use of primary Jetpack Compose ideas within the fewest strains of code attainable. Nonetheless, there’s one fascinating operate value mentioning: FRP<ConvState, ConvEvent, ConverterViewModel>. FRP is a composable operate from the Ivy FRP framework, which does a number of issues:

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

Right here’s how the FRP operate 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 complete UI code will be discovered within the UI operate of the ConverterScreen.kt file. When you’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 might have elevated storage earlier than the app can run.

Cleaner Android Structure With FRP

With a powerful 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.