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 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. …
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 in simple terms is when we start an action whose output may produce an immediate effect or reaction that must be handled as soon as possible 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:
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…
(This article was featured into Specials section at Android #447 Weekly)
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…
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…
View is such an interesting and challenging artefact to deal with. We can be very tempted as Android engineers to create a custom
Activity, etc and probably add inside extra (not needed) logic.
I truly believe moving logic away from the view would make our code more testable. Over the years I’ve learned that the more you can decouple logic and responsibilities out of the view, the easier to test your code could become.
A good design pattern for that concrete purpose is the Delegate pattern…
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 Controller. Models contained a variety of mutable states and Controller had direct communication with the View. Does it sound familiar? Model-View-Controller (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…
(This article was featured at Android #418 Weekly)
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 Implementations details 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. …
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…
Software Engineer (Android) @ Twitter. Kotlin lover. Continuous learner, sometimes runner, some time speaker & open minded. Opinions my own.