Photo by Johny vino on Unsplash

During this article, we’ll discuss reasons why Declarative UIs could be a choice compared with Imperative UIs and really “Why” it could be a choice that matters on Android.

A State Machine

A state machine or finite-state machine, understanding the term “finite-state” like a limited number of states. By definition, it is a mathematical model of computation. That actually is a simplification of the very famous Turing Machine, basically, a state machine would be a subset of it. …

Photo by Henrik Verle on Unsplash

Most of us Android engineers probably remember that Google IO on 2019 where Romain & Chet presented Jetpack Compose, a modern Android toolkit to build native UI. They mentioned some awesome core features of it, among them that it is Reactive & Kotlin.

However, it is especially remarkable to say that to achieve Declarative UIs, we would need to connect the different dots with a Reactive approach. My call would be to do that by using Unidirectional Data Flow (UDF) in Android and Kotlin

Synchronous communication Design cover

Introduction to Synchronous communication

Synchronous communication in simple terms is when we start an action whose output may produce an immediate or that must be handled because we are waiting for this process to finish.

This is the opposite of Asynchronous communication, when the response is not coming instantly, with situations or examples like:

  • we are requesting information to the or , we carry on with other tasks and the result of the async operation will come back at some point in the future.
  • or like…

Photo by Derek Oyen on Unsplash

The most important part of an iceberg is not what you can observe from the surface. What really matters is what is under it. That is what will make it float above the surface.

Comparing an iceberg with Declarative UIs, we can tell that essentially our iceberg would be powered by a Reactive approach to producing successful updates. Updates that came from a change, preferably executing in a single direction. These are indeed the foundations of Unidirectional Data Flow (UDF).

Throughout this article…

My work’s Secret Santa’s gift: a Rick & Morty t-shirt in addition to Beer Hawk Craft beer Discovery Gift box.

Do you wonder what this is about? The end of 2020 is happening. Such a strange year for all of us, right?! This surely wasn’t the most exciting year we can recall so far. However, I am going to focus (at least I’ll try) on what & how this year has been so far, without mentioning politics or world miseries (rest assured, keep reading).

For those who don’t know how this kind of article works for me. I typically start matching my previous year’s ToDo objectives against some facts…

Photo by Ray Hennessy on Unsplash

Once we’ve completed a full migration strategy, we should feel happy because our objective is completed (✅), isn’t it?

However, are we sure this is it?

In my opinion, our work here is not completed just yet. There are a few things we certainly have learned along the way. Moreover, we may still need to do some significant changes.

From this point, I assume you had a similar experience regarding this “Migration Strategy” proposed at Part 1:

To recap previous articles please go to the end of this article…

Implementation details cover

The View is such an interesting and challenging artefact to deal with. We can be very tempted as Android engineers to create a custom View, Fragment, Activity, etc and probably add inside extra (not needed) logic.

I truly believe moving logic away from the would make our code more . Over the years I’ve learned that the more you can decouple logic and responsibilities out of the , the easier to test your code could become.

A good design pattern for that concrete purpose is the Delegate pattern

Implementation details cover

Once upon a time, I recall creating business logic into the View was “all right”. For instance, not too many years ago most of the Android apps were built on top of a collaborator called . contained a variety of mutable states and had direct communication with the . Does it sound familiar? (MVC) was a very popular “architecture” pattern at the time, not only for mobile apps but also on the web where it became popular.

I believe Clean Architecture started like a remedy to…

Implementation details cover

The most exciting moment for a software engineer surely is when enjoys coding and gets stuff done. However, for the pragmatic developer, implementation details should be as important as the process to get things done, because the difference is on the details, isn’t?

Throughout Part 3, I will elaborate throughout the from the Data layer. Firstly I will start with “Data Sources Design: Network & DB”. I will go deep inside “Repository Design Step 1: RxJava approach”, what I call the naive approach. …

“Fueled Reactive apps with Asynchronous Flow” cover

Refactoring an application to use modern techniques and libraries can be really challenging. This post is the second part where I explain how I started to learn about the concepts that are a must-do for it.

Since the presentation had a limited time to speak about some topics, they were covered quickly sometimes, but here I want to tell in-depth or at least trying about a few subtle details.

Along this part, I will compare RxJava and Coroutines to get a better understanding of all important concepts. I will…

Raul Hernandez Lopez

Software Engineer (Android) @ Twitter. Kotlin lover. Continuous learner, sometimes runner, some time speaker & open minded. Opinions my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store