Efficient Android, Half 2: Purposeful Reactive Programming

Purposeful 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 consumer interfaces, and manages state easily. As a consequence of these and lots of different clear advantages, the usage of FRP goes mainstream in cellular and net improvement.

That doesn’t imply understanding this programming paradigm is straightforward—even seasoned builders could 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 on the whole programming languages.

Getting Began with FRP: System Design

The FRP paradigm is an limitless 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 likely be up to date with every occasion it receives. This program consists of the identical parts 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 overall reactive parts with actual Android parts and libraries:

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

• Ivy FRP: This can be a library I wrote that will likely be used for academic functions on this tutorial. It’s meant as a place to begin to your strategy to FRP however will not be supposed for manufacturing use as is because it lacks correct assist. (I’m presently the one engineer sustaining it.)
• Arrow: This is among the finest and hottest Kotlin libraries for FP, one we may even use in our pattern app. It offers nearly every part you could go purposeful in Kotlin whereas remaining comparatively light-weight.
• Jetpack Compose: That is Android’s present improvement toolkit for constructing native UI and is the third library we’ll use at present. It’s important for contemporary Android builders—I’d suggest studying it and even migrating your UI when you haven’t already.
• Move: That is Kotlin’s asynchronous reactive datastream API; althought we’re not working with it on this tutorial, it’s suitable with many frequent Android libraries resembling RoomDB, Retrofit, and Jetpack. Move works seamlessly with coroutines and offers reactivity. When used with RoomDB, for instance, Move ensures that your app will at all times work with the newest knowledge. If a change in a desk happens, the flows depending on this desk will obtain the brand new worth instantly.
• Kotest: This check platform affords 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 undertaking 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
}

knowledge 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 consumer inputs, which we’ll convert later.
• outcome: An elective 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 {
    knowledge class SetConversionType(val conversion: ConvType) : ConvEvent()

    knowledge 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 likely 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 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 Move as a reactive knowledge stream).
• handleEvent(Occasion): droop () -> S: Produces the subsequent 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 take 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 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: Further Operate Implementations

Our view mannequin additionally incorporates operate 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 research 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 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 based mostly on the chosen conversion sort.

Utilizing the facility of composition, we are able to use the convert: State -> State operate as enter for different compositions. You will have seen 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 at any time when we use updateState {}. Fully 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 essentially the most sensible: Use pure capabilities for essentially the most half, and ensure any impure capabilities have managed uncomfortable side 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 likely be a bit “ugly,” however the aim of this instance is to reveal FRP, to not construct a stupendous 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 traces of code attainable. Nevertheless, there’s one attention-grabbing 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 Move.
• Propagates occasions to the ViewModel with the code onEvent: (Occasion) -> Unit).
• Supplies a @Composable higher-order operate that performs occasion propagation and receives the newest state.
• Optionally offers a technique to cross initialEvent, which known as as soon as the app begins.

Right here’s how the FRP operate is carried out 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)
}

You will discover the complete code of the converter instance in GitHub, and the whole UI code will be discovered within the UI operate of the ConverterScreen.kt file. If you happen to’d prefer to experiment with the app or the code, you’ll be able to 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 robust foundational understanding of purposeful programming, reactive programming, and, lastly, purposeful reactive programming, you’re 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.