Chapters
Chapters

Chapters

Hide chapters

Functional Programming in Kotlin by Tutorials

First Edition · Android 12 · Kotlin 1.6 · IntelliJ IDEA 2022

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: Functional Programming Fundamentals

Section 1: 8 chapters
Show chapters Hide chapters

Section II: Data Types & Typeclasses

Section 2: 5 chapters
Show chapters Hide chapters

Section III: Functional Programming in Practice

Section 3: 7 chapters
Show chapters Hide chapters

Appendix

Section 4: 13 chapters
Show chapters Hide chapters

18. Mobius — A Functional Reactive Framework
Written by Massimo Carli

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In Chapter 15, “Managing State”, you learned the importance of the concept of state. A state is usually defined as some value that can change over time. You also learned that what you consider a state defines side effects. A side effect is something that changes the state of the world, which is outside the context of a function.

Side effects aren’t harmful as long as you can control them. In Chapter 16, “Handling Side Effects”, you saw how important it is to separate the description of an effect from its actual execution.

These are all the fundamental principles used by Mobius, which is defined in its documentation as: “a functional reactive framework for managing state evolution and side-effects, with add-ons for connecting to Android UIs and RxJava Observables. It emphasizes separation of concerns, testability, and isolating stateful parts of the code”.

In this chapter, you’ll learn:

  • The main concepts Mobius is based on.
  • What the Mobius loop is and how it works.
  • What the Mobius workflow is, and how to apply it to a real case.
  • How Mobius works with Android.
  • How Mobius handles side effects.

You’ll do this by creating a Mobius version of the RayTV app you met in Chapter 14, “Error Handling With Functional Programming”. You’ll call it Raybius. :]

Note: Although Mobius’s architecture and principles don’t depend on it, RxJava is one of the most commonly used libraries to handle side effects. RxJava-specific concepts will be kept at a minimum, but if you want to learn all about it, Reactive Programming with Kotlin is the right place to go.

Note: The Raybius app uses Dagger and Hilt. If you want to learn all about the Android dependency injection framework, Dagger by Tutorials is the perfect book for you.

Mobius principles and concepts

To understand how Mobius works, just think about a typical mobile app. You have some UI that displays some information. You usually interact with the UI by pressing some buttons or providing some input. This triggers some actions to access, for instance, a server, fetch some data and show it in the UI. This might look like an overly simplified description of what usually happens, but the reality isn’t far off. You can represent the flow like in Figure 18.1:

Figure 18.1: The Mobius loop
Figure 18.1: The Mobius loop

This image has numerous interesting concepts you can easily understand by following the flow described earlier.

When you launch your app, you can see a UI, which is usually a composition of views, like TextViews, Buttons and so on. You can think of a view as a way to represent some data. When the data changes, the UI usually changes. This is important because you can think of the data as the current state of the UI. The data you want to display with the UI is usually represented as the model.

As mentioned earlier, the user interacts with the UI by pressing some buttons or providing some data as input. Mobius represents these actions as events. An event is what makes an app interesting. Some events just update the UI, creating a new model to display. Others are more complicated because they trigger a request to the server or access to a database.

To handle both use cases, Mobius provides an Update function. It receives the current model and the input event, and returns the new model and an optional description of a side effect. It’s crucial to see how the Update function lives in the pure section of the diagram. The Update function is pure. This is because:

  • The new model just depends on the input model/state and event.
  • It returns a description of the side effects you need to execute eventually.

This makes the Update function very easy to test. Not represented in Figure 18.1 is the Init function. Init is a version of Update that generates the first state and, optionally, the first set of effects to generate.

Now, Mobius sends the new model to the UI and the optional effects to some effect handlers. These are what actually execute the side effects, usually in a background thread. It’s also interesting to see that effect handlers notify the outcome using events and how they go through the same flow you saw earlier for the events from the UI.

The Update function is invoked, and a new state/model is created along with other optional side effect descriptions.

This is an example of a unidirectional flow. It favors principles like immutability and purity to avoid the classical problems of a concurrent application, like race conditions and deadlocks.

Finally, an event source represents a generic component able to generate events even without a specific interaction from the user. Think about the events related to the battery level or your device going offline and then back online again.

The previous architecture is straightforward and gives each component a clear responsibility, as the separation of concerns principle suggests. This also allows the implementation of a process named the Mobius workflow.

The Mobius workflow

In the previous section, you learned that the main concepts in Mobius are:

Model your app

Models in Mobius can represent different concepts like:

Niguqi 14.0: Fke ewozuec BeYneg
Jadiso 75.3: Wna edidair CaJboh

Civoga 45.4: Kxe ZiFnos xovk imuv uwjufijzoak uzibld
Duzoni 66.7: Npu HaFhag xiqz ejac apcudufveig ojusjp

Secali 83.1: Aqcuth awqovbz
Yawuya 55.9: Omrohd ambuswn

Vabapa 86.4: Qijoye morukf
Pabopo 40.1: Figase hopuwh

Hetiqo 89.7: Sivuzi elpepxn quuqyupk ojotzg
Xokoli 91.8: Kamohe ebgaxgt yoepmeqz ipoxvg

Zijeyo 74.0: Onkojueyuw omxozyj
Lebipu 35.3: Oyvaqeoyoz ozqongb

Describe your app

When you have the MoFlow for your app, you can start implementing the Update function. Update is a pure function that receives the event and the current model as input and generates the new model and the set of effects as output. In Mobius, an instance of the Next class encapsulates this information.

Jutiku 99.8: Hne Golwiac ibj
Dusode 06.0: Swe Vuzpaej ayd

Nasiki 33.2: Sevo MQ cmign ex rugixjt
Duwisa 09.4: Biwa SK jcafv in kixupwj

Plan your app

In this step, you basically design how your app should do all the tasks you described in the Update function. The actual code should be part of the next step, but right now, you’ll look at how different effects are executed. You already know that an effect is basically the description of an operation that changes the external world. The component responsible for actually executing an effect is called an effect handler. Mobius provides different ways to implement an effect handler.

Build your app

In this step, you’ll finish implementing the MoFlow table you described earlier. It’s time for you to use Mobius to implement the feature to display TV show details.

Implementing the TvShowDetail feature

Now, you’ll add the show detail feature. To do this, you need to:

Model update

Open TvShowModel.kt, and add the following constructor property:

Adding new events

Now, open TvShowEvent.kt, and add the following events:

Adding effects

Add new effects. Open TvShowEffect.kt, and add the following code:

Update the update function

To bind events and effects together, you need to open TvShowLogic.kt and add the following code to the update when block:

Add new effect handlers

In the previous code, you defined the new NavigateToDetail and GetTvShowDetail effects. It’s now time to tell Mobius how to execute them. They’re both effects that need to generate some events as a result. Open UIEffectHandler.kt, and add the following definition to the interface:

Update UI logic

You still need to do a few last things to handle user events and use the data you receive from the new effects. You basically need to:

Kororo 66.91: Mqo huqauw ffhoer
Lazumu 46.87: Dpo qosiaw rqheog

Mobius loop in Android

In Figure 18.1, you learned that Mobius’s architecture is based on the creation of the Mobius loop, which is responsible for:

Key points

  • Mobius is a functional reactive framework for managing state evolution and side effects, with add-ons for connecting to Android UIs and RxJava Observables.
  • Mobius emphasizes separation of concerns, testability and isolating stateful parts of the code.
  • Mobius is an example of unidirectional flow architecture.
  • The MoFlow is a process that allows you to design your app in terms of models, events and effects.
  • The model represents the current state of the UI.
  • You can use events to represent a user interaction or the result of an effect.
  • An effect is the description of a task that might change the state of the world.
  • Models, events and effects are immutable.
  • The Update function is a pure function, receiving the current model and the event as input, and returning the new model and the optional effects.
  • The purity of the Update function makes it very easy to test.
  • An effect handler is responsible for the actual execution of an effect, and it usually works in the background.

Where to go from here?

Congratulations! In this chapter, you learned how the Mobius framework works as an example of a unidirectional architecture that uses many of the principles you learned about functional programming. In the next — and final — chapter, you’ll learn the most important concepts about a very important functional programming library in Kotlin: Arrow.

17. Sequence & Flow
19. Arrow
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now