Some days ago, I needed to break the implementation of a complex ViewModel. Looking for some ideas I’ve found the Delegation Pattern.

What is the Delegation pattern?

A design pattern where one object relies on another to perform specific tasks instead of doing it itself.

Why use it?

• Promotes composition over inheritance
• Allows better reuse of functionality
• Simplifies code by avoiding duplication

Kotlin’s support for Delegation

Kotlin makes the Delegation Pattern easy by providing:

• Class delegation
• Property delegation

Class Delegation

In Kotlin, class delegation allows you to delegate the implementation of an interface to another object using the bykeyword.

interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) {
        println("ConsoleLogger: $message")
    }
}

class FileLogger : Logger {
    override fun log(message: String) {
        println("FileLogger: $message")
    }
}

class Application(logger: Logger) : Logger by logger

fun main() {
    val consoleLogger = ConsoleLogger()
    val fileLogger = FileLogger()

    // Pass the consoleLogger instance to Application
    val app1 = Application(consoleLogger)
    app1.log("Using console logger.") // ConsoleLogger: Using console logger.

    // Pass the fileLogger instance to Application
    val app2 = Application(fileLogger)
    app2.log("Using file logger.") // FileLogger: Using file logger.
}

It is even possible to apply multiple implementations with the only restriction being that you have to decide which one to use during the object construction.

interface Engine {
    fun start()
    fun stop()
    fun getStatus(): String
}

class ElectricEngine : Engine {
    override fun start() = println("⚡ Electric motor starting")
    override fun stop() = println("⚡ Electric motor stopping")
    override fun getStatus() = "Electric Motor OK"
}

class BasicEngine : Engine {
    override fun start() = println("🔥 Gas engine starting")
    override fun stop() = println("🔥 Gas engine stopping")
    override fun getStatus() = "Gas Engine OK"
}

class HybridCar(
    electricEngine: Engine,
    basicEngine: Engine,
    useElectric: Boolean
) : Engine by when {
    useElectric -> electricEngine
    else -> basicEngine
}

Of course, you can apply multiple class delegations to a single class

interface ElectricCar {
    fun chargeBattery()
    fun driveElectric()
}

interface GasolineCar {
    fun refuelTank()
    fun driveGasoline()
}

class GenericElectricCar : ElectricCar {
    override fun chargeBattery() {
        println("ElectricCar: Charging the battery.")
    }

    override fun driveElectric() {
        println("ElectricCar: Driving on electric power.")
    }
}

class GenericGasolineCar : GasolineCar {
    override fun refuelTank() {
        println("GasolineCar: Refueling the gas tank.")
    }

    override fun driveGasoline() {
        println("GasolineCar: Driving on gasoline.")
    }
}

class HybridCar(
    electricCar: ElectricCar,
    gasolineCar: GasolineCar
) : ElectricCar by electricCar, GasolineCar by gasolineCar

Property delegation

In Kotlin, property delegation allows you to delegate the getter and setter logic of a property to another object. This is done using the bykeyword. Instead of directly managing the property, the responsibility is handed off to a “delegate” object that provides custom behavior for reading and writing the property.

Built-in property delegates

Kotlin provides some useful built-in property delegates:

• Lazy initialization: lazy is a standard delegate for initializing a property lazily.

val myLazyValue: String by lazy {
    println("Initializing...")
    "Hello, Kotlin!"
}

fun main() {
    println(myLazyValue) // Prints: Initializing... Hello, Kotlin!
    println(myLazyValue) // Prints: Hello, Kotlin! (No reinitialization)
}

• Observable properties: Delegates.observable allows you to react to property changes.

import kotlin.properties.Delegates

var observedProperty: String by Delegates.observable("Initial Value") { _, old, new ->
    println("Changed from $old to $new")
}

fun main() {
    observedProperty = "New Value" // Prints: Changed from Initial Value to New Value
}

Custom property delegates

You can create your own property delegates by implementing the getValue and setValue operators

import kotlin.reflect.KProperty

class CustomDelegate {
    private var value: String = "Default"

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: String) {
        value = newValue.uppercase()
    }
}


var myProperty: String by CustomDelegate()

fun main() {
    println(myProperty) // Prints: Default
    myProperty = "hello"
    println(myProperty) // Prints: HELLO
}

You can find Property Delegation usage in Compose

The function remember{} in Compose has been designed using the concept of delegation in mind. Here I show you a very simplified example of it.

import kotlin.reflect.KProperty

class RememberDelegate<T>(private val initializer: () -> T) {
    private var value: T? = null

    operator fun getValue(thisRef: Any?, property: KProperty<*>): T {
        if (value == null) {
            value = initializer()
        }
        return value!!
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: T) {
        value = newValue
    }
}


fun <T> customRemember(initializer: () -> T): RememberDelegate<T> {
    return RememberDelegate(initializer)
}

fun main() {
    var rememberedValue by customRemember { "Hello, World!" }
    println(rememberedValue) // Prints: Hello, World!

    rememberedValue = "New Value"
    println(rememberedValue) // Prints: New Value
}

Conclusion

The Delegation Pattern in Kotlin is a powerful way to simplify code and promote composition over inheritance. Kotlin’s built-in delegation support makes implementing this pattern easy and elegant.

• Promotes composition over inheritance
• Allows better reuse of functionality
• Simplifies code by avoiding duplication

NOTE: I’ve created a playlist for 3 videos I recorded showing all these examples work (those videos are in Spanish)

References

• Delegation | Kotlin Documentation
  https://kotlinlang.org/docs/delegation.html
• Delegated properties | Kotlin Documentation
  https://kotlinlang.org/docs/delegated-properties.html

Almost seven years ago, I arrived in Santiago, Chile from Mexico. Having never been here before, I was unsure of what to expect. I remember being curious about my new job, colleagues, and the challenges ahead in a prominent startup founded years before. What I experienced during those first five and half years was valuable for me in terms of my professional career, I met great and passionate tech people. I gained valuable experience, being involved in recruitment, interviewing devs identifying which skills and values can fit our team.

On the technical side, I have always been someone who values reading and staying informed, but when it comes to making decisions, I rely more on my own experience and common sense rather than strictly following what the books say. This practical approach has guided me in working on evolving, well-designed architectures and being responsible for many of the technical decisions. When I’d been promoted to Technical Lead, I saw how by involving my teammates in technical discussions, we were able to create a sense of ownership over the product, which resulted in a more stable and cohesive team with less turnover during that time even during the pandemic.

Of course, many things have changed during the last few years, that startup was acquired by big tech, and the culture changed, and those enriching experiences came to a close, prompting me to seek new horizons.

On my community side, I’ve been involved with some developer communities like the community of Android and Kotlin. A lot of the content I consume to learn about different technologies and keep me up-to-date is thanks to people who share what they’ve learned so I’m committed to giving back to the community what I learn. Also, I believe that people grow not only by themselves but also by sharing what they learned and encouraging others to learn and grow. Building a strong community is not an easy task, but helps us to create strong connections and make some friends.

As I reflect on these years of growth and the dynamic experiences I have had, I’m reminded of the importance of being part of a team and a mission that truly resonates with me. I continue to seek out opportunities that challenge me and align with my passions, allowing me to contribute meaningfully and grow alongside like-minded professionals. I remain committed to pursuing excellence in every project I undertake, looking forward to what the future holds.

If you’d like to discuss these experiences or explore potential opportunities together, I’d be happy to grab a coffee or a drink and chat about it.

#thoughts #chile #developer

I’m learning about drawing in Android with Compose; here you can find my thoughts.

Since the first time I heard the word “Canvas,” I have been curious about what it is and why some developers talk a lot about it, but life took me to work on different aspects of Android app development, and I couldn’t find out what it means.

Until this year, when I was looking at some charts a colleague built in an Android app, the word “canvas” came back to me.

According to Merriam-Webster dictionary, a canvas is “a piece of cloth backed or framed as a surface for a painting”.

Similarly, Android provides a canvas to draw whatever we want.

Choosing our canvas

Before starting, we need to choose where we will draw.

We can use one of the modifiers available for this purpose, like drawBehind(), drawWithContent() or drawWithCache(), or we can use a convenient composable called Canvas (behind the scenes, it is an Spacer using the drawBehind() modifier).

Understanding the coordinate system

It is very important to remember this: “The origin or point (0,0) is located at the top left corner of the screen (or canvas).”

This also works for the Offset, an object that declares how far from the origin an object will be placed.

Which form do you want to draw?

Well, at this point, Compose offers you several functions to help you to start drawing:

For basic shapes:

• drawRect()
• drawCircle()
• drawRoundedRect()
• drawOval()
• drawArc()
• drawLine()
• drawPoints()

And:

• drawText()
• drawImage()

…and that’s it for now. I’m recording some videos about this topic (in Spanish). Here you can watch the first video:

References

• Graphic modifiers | Jetpack Compose
  https://developer.android.com/develop/ui/compose/graphics/draw/modifiers#drawing-modifiers

When Gemini in Android Studio was released, I was curious about how different or similar the experience would be to Github Copilot. I can say I’m gladly happy with the approach taken.

First things first… we have the control

Something I dislike about Copilot is the sensation of being tracked constantly without any chance to restrict what the model can read or not.

From the beginning, you’re aware of the different options for making the model aware of your project in Gemini in Android Studio. You can decide between using Gemini in Android Studio only as a conversational chat box, letting the model get context about the current project, or letting the model get context about all your projects. Also, you can include .aiexclude files to restrict access over parts of your project or even the entire project from the model.

When you let the model access your project, you can also enable the option for Gemini to act as a copilot, providing suggestions to complete the code in the same way as Github Copilot does.

Accuracy of results

Gemini in Android Studio promises you some features like code generation, answering questions, finding resources, code optimization and analyzing crash reports. I’ve tested all of these features, and everything went well until I made some complex requests.

Asking for the generation of a Person data class is not the same as asking how I can solve a bug with the BottomSheetDialogFragment that provokes the sheet to move to the top of the screen when the size of any child component changes. When I tried for this last request, Gemini gave me several bad answers and suggestions, even inventing its own classes. It was a total disaster in terms of trust.

Not only with Gemini

This problem is not exclusive to Gemini but Github Copilot and Chat GPT also; you can ask them something complex, and these tools usually offer you results far from something real or valuable. Without enough experience, a developer can waste time finding which of those wrong answers is correct.

This situation made me think about how confident those repositories are consumed by these models to be trained. However, this topic could be covered in a different article.

My conclusion

For me, Gemini in Android Studio is a good tool. Even when you restrict access to your project, disabling any chance to offer a suggestion, the chat box will help you ask about references or even solve routine tasks, so you don’t need to abandon your IDE to open a browser and make a search for a reference.

Recently, I shared a talk about Gemini in Android Studio (in Spanish) with the Android community in Santiago, Chile. Here are the slides and the recording.

My prompt: Hey, can you help me write an article about Gemini in Android Studio? What’s relevant? What are the main features? How do we have control over which project can be read by the model? Include a comparison with the former Studio Bot. Differentiate between Gemini and Gemini in Android Studio.

Google’s Gemini represents a major leap in AI capabilities. It’s a versatile large language model (LLM) designed for various tasks, from writing creative content to analyzing complex data. While Gemini is the broader technology, Gemini in Android Studio is a specialized application tailored for developers.

Gemini: The Foundation

Gemini is Google’s most advanced AI model. Its key features include:

• Multimodal: It can process text, images, and potentially other formats, leading to richer interactions and outputs.
• General Purpose: Gemini isn’t limited to one domain. It’s designed for a wide range of applications across different industries.
• Flexible Deployment: Gemini can run on powerful servers or smaller devices, making it accessible for various use cases.

Gemini in Android Studio: Your Coding Co-Pilot

Gemini in Android Studio (formerly Studio Bot) is the embodiment of Gemini’s power specifically harnessed for Android development. It leverages Gemini’s vast knowledge to provide:

• Intelligent Code Generation: From creating UI elements to implementing complex features, Gemini helps you write code faster and more accurately. Describe what you need, and let Gemini handle the syntax.
• Expert Q&A: Have a question about Android APIs, best practices, or error messages? Gemini provides insightful answers, drawing on its extensive knowledge of Android development.
• Context-Aware Suggestions: Gemini understands the nuances of your project and provides tailored recommendations, saving you time and effort.
• Future Crash Report Analysis: The upcoming integration of crash report analysis will enable Gemini to help you diagnose and fix issues more efficiently.
• Multilingual Support: Gemini is actively expanding its language support beyond English, increasing its accessibility for developers worldwide.

Comparing Gemini and Gemini in Android Studio:

Privacy and Control in Gemini in Android Studio:

Gemini in Android Studio is built with privacy in mind. By default, its responses are based solely on conversation history. You have full control over which project code, if any, to share with Gemini for more personalized suggestions.

To customize Gemini’s access, create a .aiexclude file in your project's root directory to specify which files or directories should remain private.

Embracing the Future of Android Development:

Gemini in Android Studio is a game-changer, empowering developers to work smarter, not harder. By leveraging AI assistance, you can accelerate your development process, improve code quality, and ultimately create better Android apps.

Don’t wait — dive into Gemini in Android Studio and experience the future of Android development today!

If you reach this part, you can read my honest opinion about Gemini in Android Studio.

Some developers often have difficulties choosing between these two sealed components, so I intend to provide some clarity to help them understand when they use one or the other with this short article.

Note for Spanish native speakers: Si eres hispanohablante y no tienes claro lo que es una Sealed class puedes visitar este artículo escrito en el 2020 por Facundo Rodríguez Arceri llamado “Sealed classes en Kotlin: ¿Por qué y para qué?” que sigue vigente aún y puede servirte como base para luego volver a este artículo.

Let’s begin with the basis…

Why do we create a class or an interface regularly? I think answering this question could help us find reasons to choose between both sealed components.

A class can represent states and entities, while an interface helps us declare what behaviors are supported by a class but without describing how or creating a contract.

Sealed class

For instance, think about the state of a User profile screen with some data to be displayed. We usually represent creating a class like this:

class UserProfileScreen(
  val name:String,
  val address:String,
  val tags:List<String>
)

Even though this class can represent the state of the screen when the data is displayed to the users, we know that we’ll need at least one additional state to cover the loading state.

We could add a loading attribute to our UserProfileScreen class, which could violate the Single Responsibility principle. So here is when a Sealed class can help us.

sealed class UserProfileState
data class UserProfileScreen(
    val name: String,
    val address: String,
    val tags: List<String>
) : UserProfileState()
data object LoadingUserProfileScreen : UserProfileState()

Now, we have a better representation of the states, which is easier to identify and understand. But what do we gain by declaring states in this way?

• By default, every class in Kotlin is final, so you can’t create an inheritance without marking the parent class as open.
• Make it possible to declare attributes to be shared by each subclass that extends the sealed class.

Sealed interface

One way you can take a sealed interface is to declare common classes that are not exactly to be used in the same context. This is opposite to a sealed class that defines related types for the same context.

I will take the example provided by the official documentation.

// Create a sealed interface
sealed interface Error

// Create a sealed class that implements sealed interface Error
sealed class IOError(): Error

// Define subclasses that extend sealed class 'IOError'
class FileReadError(val file: File): IOError()
class DatabaseError(val source: DataSource): IOError()

// Create a singleton object implementing the 'Error' sealed interface
object RuntimeError : Error

Even though we declare error types, we can distinguish between those errors related to I/O operations and those related to runtime errors.

Conclusion

I did not want to be exhaustive about definitions and scenarios to use sealed classes or interfaces, only to mention something that would be helpful to identify when you can use one or the other.

Sealing a class or an interface lets you safeguard the possible states of any modification outside the scope of the package where these classes were declared. It is particularly helpful when you are creating libraries.

As the documentation mentions, you can use the sealed classes and interface with when expressions; it allows the compiler to check that all possible cases are covered.

And that’s it; I hope this brief article will be useful. I’m open to receiving comments about how you use these sealed components or if you have other criteria to choose between them.

See you next time…

References & other articles

• Sealed classes and interfaces | Kotlin documentation
  https://kotlinlang.org/docs/sealed-classes.html
• Sealed classes en Kotlin: ¿Por qué y para qué? (in Spanish)
  https://medium.com/droid-latam/sealed-classes-en-kotlin-por-qu%C3%A9-y-para-qu%C3%A9-67bb9e1f2e5e

I’m revisiting some helpful content for starting a new Android project. One of the pain points is how to handle a ton of dependency declarations for multi-module projects. Here is where version catalogs come to our rescue.

Declaring dependencies

Before discussing the version catalogs, we will see how dependencies are being declared in an Android project. To declare a dependency in an Android project, you would add something like the following code in your build.gradle.kts file:

plugins {
  //...
}
android {
  //...
}
dependencies {
  // Here is where the dependencies are declared
  implementation("androidx.core:core-ktx:1.12.0")
  // ...other dependecies
}

Coordinates

One important concept to have in mind is the concept of coordinates. Each coordinate is composed by “[group]:[artifact name]:[version]”. For example, in the example above, the coordinate of the core-ktx dependency is [androidx.core]:[core-ktx]:[1.12.0], so the same dependency can be decomposed in a declaration like this:

implementation(group = "androidx.core", name = "core-ktx", version = "1.12.0")

Keep in mind this concept; we will return to it later.

A common issue with multi-module projects

In case you have more than one module in your project, each dependency needs to be declared on every module that requires the specific dependency. The problem arises with this approach because of having repetitive declarations; every time you want to update a dependency version, you have to make the change in every gradle file where the dependency is declared. This makes dependency handling redundant and messy.

Here is where Version catalogs come to our rescue.

Version catalogs

Version catalogs are a feature of Gradle, so you can use it if you use Gradle as your build system in your Android project. This allows you to declare and organize all your dependencies in a single file, which acts as a catalog where each dependency is associated with a single alias, making this catalog act as a source of truth and it can be referenced in every gradle file.

To enable this option, you need to follow these steps:

1. Create a new file in the gradle folder at the project level with the name libs.versions.toml.
2. Declare the dependencies into that file.
3. Reference these declarations in every gradle file of each module.

If you don’t know where the gradle folder is, you can typically find it at the root project level; you can use the Project view to look at it.

At this point, you can ask… how these declarations must be made into that file?

Basic usage

Now, let’s see the structure of the libs.versions.toml file.

[versions]
core-ktx = "1.12.0"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "core-ktx" }

In the most basic format, you have to declare two sections [versions] and [libraries], the first one is used to declare versions for each dependency, the second is for the dependencies itself.

For this example, we took the same dependency that has been declared in the first example of this article in the gradle file. In order to make the core-ktx dependency available in the libs catalog, we associate the alias androidx-core-ktx to the GAV (group, artifact, version) coordinates.

The main benefit is these declarations are visible by all the modules in your project. So you can reference these declarations from your gradle file.

plugins {
  //...
}

android {
  //...
}

dependencies {
	// Here is where the dependencies are declared
	implementation(libs.androidx.core.ktx)
	// ...other dependecies
}

Note: Every time you add a new declaration in the TOML file, you have to sync the project to make it available for the modules.

Also, using Version catalogs allows you to reference the same version for multiple different libraries, for example:

[versions]
android-paging = "3.2.1"

[libraries]
android-paging-common = { module = "androidx.paging:paging-common-ktx", version.ref = "android-paging" }
android-paging-runtime = { module = "androidx.paging:paging-runtime-ktx", version.ref = "android-paging" }
android-paging-rxjava2 = { module = "androidx.paging:paging-rxjava2-ktx", version.ref = "android-paging" }

Here, we simplify the coordinates using the module to group the [group]:[artifact] pair and use the same version reference for all the android-paging dependencies.

Going a bit further

Not only you can declare the regular dependencies in that TOML file, but you can also declare your plugins and even create bundles for grouping dependencies.

How to declare plugins

To declare a plugin, you only need to add the [plugins] section.

[versions]
//Here the versions are declared
android-gradle-plugin = "8.2.0"

[libraries]
//Here the libraries are declared

[plugins]
android-application = {id = "com.android.application", version.ref = "android-gradle-plugin"}

So, after syncing the project, we can change the references from this

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id("com.android.application") version "8.2.0" apply false
    //... more plugins are placed here
}

To this

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    alias(libs.plugins.android.application) apply false
    //... more plugins are placed here
}

How to create your own bundle

To create a bundle, you have to add a [bundles] section into your TOML file. For example, here I’m adding the Room bundle.

[versions]
room = "2.6.1"
ksp = "1.9.0-1.0.13"

[libraries]
androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" }
androidx-room-ktx = { group = "androidx.room", name = "room-ktx", version.ref = "room" }
androidx-room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" }

[plugins]
kotlin-symbol-processing = { id = "com.google.devtools.ksp", version.ref = "ksp" }

[bundles]
android-room-bundle = ["androidx-room-ktx", "androidx-room-runtime"]

Again, you can use the bundle like this after syncing your project.

plugins {
    // More plugins are added here...
		alias(libs.plugins.kotlin.symbol.processing)
}

android {
  //...
}

dependencies {
    // Some dependencies are declared here
    implementation(libs.bundles.android.room.bundle)
    ksp(libs.androidx.room.compiler)
}

Conclusion

It’s also worth mentioning that using a version catalog is likely the best way to establish a single source of truth for all your project dependencies. It’s also worth mentioning that the official documentation has a section about this topic.

You can experiment with different strategies using bundles to organize the necessary dependencies for each project, avoiding the tedious process of checking each Gradle file to see what you’ve declared.

References

Migrate to version catalogs

https://developer.android.com/build/migrate-to-catalogs

Sharing dependency version between projects

https://docs.gradle.org/current/userguide/platforms.html

In the last few months, my team and I have been thinking about the best way to adopt Compose. After checking a ton of articles and videos suggesting ways to make this transition, a couple of things helped us create a path for this.

Something my entire team shares is our desire to use or at least test all the new components the Android team releases as it is released. That is why we create our pet projects to use them and test them in a controlled environment.

We take our time adopting something new because it is irresponsible to introduce something new only because of FOMO. We know that our users do not care what or how many tools, old or new, we use. They only want a good experience when they are using our apps.

Jetpack Compose

As many of you know, Jetpack Compose is the newest way to create our UIs on Android. Using Kotlin as the language and the current version of Android Studio (Arctic Fox), we can create UIs declaring all the components required.

Even though we can create components on demand, Compose encourages the creation of reusable components, and this could be a problem if your application does not follow a design system.

Design system

A design system is a group of allowed elements that different teams can use to design and implement new features. This set of elements helps us to standardize the look and feel of every screen, making it easier for the users to identify common behaviors when they use our app. Furthermore, they reduce the complexity that designing a new screen requires.

Counting with a design system provides you with several common components you can create and use across all the features of your app. But how can we create a design system? Here is where a methodology called Atomic Design enters the field.

Atomic Design

Atomic Design is a methodology for creating design systems. It drives composing screens by building with smaller reusable components toward building ever more complex constructions. This methodology was created for Web development, but we can use the same principles in developing mobile applications.

Under this metaphor:

• Atoms could be the view elements that Android provides us. These elements could be views or composable functions.
• Molecules are a combination of different atoms. Under our Android Perspective, a molecule could be a component composed of different types of views (eg. an ImageView + a title TextView + a brief description with other TextView) or a bit complex Composable function that receives the content. A molecule should be reusable.
• Organisms should be reusable sections composed of different molecules, atoms, or even other organisms. These sections could be populated by different data in different places in the application.
• Templates, from the View perspective, should be a group of containers to distribute and organize elements into a screen. From the Compose perspective, Composable functions as Scaffold or any complex Composable function that receives other Composable functions and brings distribution of elements to the screen.
• Pages should be our screens.

What does it look like?

I’m sure an image is better than words, so look at this image below

As you can see, these images show you some screens, their components, and elements that are part of them.

These pages called design kits usually are developed using tools like Figma, Sketch, or Adobe XD.

Having a clear idea in our mind

With our design system defined, we can start following the recommendations of other developers.

Start migrating a low-risk screen using any of the different ways to combine Views and Compose. You can even build new screens from zero. Having a design system allows you to create a palette of reusable components on a single module to build or migrate any screen you want in your project.

Obviously, you always can create components directly without a design system, but after seeing its benefits, I will recommend this way to work because it reduces some cognitive charge provoked when you have to build from scratch those components that a screen requires.

References

• Atomic Design
  https://bradfrost.com/blog/post/atomic-web-design/
• UpLab
  https://www.uplabs.com/templates/android
• Jetpack Compose
  https://developer.android.com/jetpack/compose

¿Buscas la versión en español de este artículo? Haz click aquí

Before We Start

If this is your first time reading about Clean Architecture, you need to keep the following in mind,

• Clean Architecture is the title of a book by Robert C. Martin, aka. Uncle Bob (2017). There is an article in their blog with the same title.
• “Clean Architecture” is not actually architecture itself, but a guide with a specific set of principles. The author tries to synthesize elements in common on several architectures.
• SOLID is an acronym created by Uncle Bob for his first five object-oriented design principles. “Clean Architecture” uses those principles as its foundation.
• Uncle Bob’s guide leads you to structure your app with the Domain layer as its center. This is where you will find the application’s rules.
• Developers often confuse N-layer-based architecture with “Clean Architecture.”
• “Clean Architecture” is a mainstream phrase that developers use as an easier way to describe application structures to others.

What is architecture?

Architecture is a structure, a way to distribute your application components in various groups. There is not a single way to organize your projects because it could depend on several aspects like project state, team size, time constraints, etc.

Clean Architecture on Android

Many developers point out Separation of Concerns and Testing as two of the main aspects of Clean Architecture. However, they forget that it is imperative to have a well-implemented Domain layer. Why? Because all of the application and business rule components are located in the Domain layer; they control the entire application.

How then would a project based on these principles be structured? There are two considerations to take into account before defining the structure:

• The Dependency Rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything about something in an outer circle.

• There are data that need to cross boundaries, from out to inner layers and vice-versa. Because we have to respect the Dependency Rule, we solve this issue by using the Dependency Inversion principle.

Now, we can create a basic structure using three modules‒ Presentation, Domain, and Data. They will represent each one of the layers.

What components go into each layer?

Remember, when we speak about architecture, we are speaking about structure and organization. This depends on the purpose of every component I added to the application.

The following describes a three-layered architecture represented in three modules:

• The Domain module contains components with the business and application rules like Interactors, Use Cases, and Domain classes, along with, the abstractions of repositories represented by interfaces. This module will be without reference to the Android Framework, and it should be created as a Kotlin Gradle module.
• The Presentation module contains every UI element like Views or Composable functions. Under patterns like MVP or MVVM, components like Presenters or ViewModels reside here. Because this module will use dependencies from the Android Framework, this module must be created as an Android Gradle module.
• The Data module contains every component related to consuming external services and the local persistence of data. Client implementations of Room, Retrofit, SharedPreferences or/and any third-party dependency will be placed in this module. Additionally, if we declare the abstractions of repositories in the Domain layer, the concrete implementations will be into the Data module too. This S sounds obvious, but this module must be created as an Android Gradle module too.

Dependency Inversion Principle

Previously, we mentioned data needs to cross boundaries between layers. How do you consume components from the Data layer into components of your Domain layer? The answer is the Dependency Inversion principle.

This principle establishes two rules:

• High-level modules should not import anything from low-level modules. But they should depend on abstractions (interfaces).
• The abstractions should not depend on details (concrete implementations), but details should depend on abstractions.

According to these rules, we need to add an interface to the Domain module. This represents the operations that will be available in the Repository class. Adding an interface to the Domain module isolates the Use Case from any specific implementation. Following these rules, we also make the Data module depend on the Domain module, which helps us keep the concrete implementation separated from the Domain.

In order to ground these concepts, we will see how to put them in code. These definitions below t will be placed in the Domain module.

interface BookRepository {
    suspend fun getBooks():List<Book>
}

class GetBooksUseCase(
    private val bookRepository: BookRepository
) { /*...*/ }

Meanwhile, in the Data module, we will find the concrete implementation of that repository.

class BookRepositoryImpl (...) : BookRepository {
    override suspend fun getBooks(): List<Book> { /* ... */}
}

Thus, having the repository abstraction will help us inject this repository into the Use Case component.

Final thoughts

• There is no single way to structure a project, and each architecture has its characteristics.
• Even though you do not define an architecture, following the SOLID principles will lead you to maintain a well-organized code.
• The revamped Android Architecture official guide offers you a structure-based in layers without a clear definition of a business layer.
• Having a well-separated domain layer helps you define your Presentation and Data layer as you wish. For example, you could use a View-based UI system or Compose in your Presentation module, or use Retrofit, Volley, or Ktor in your Data module. Every change you made in any of these modules should not affect others.

References

• Clean Architecture
  https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
• Dependency Inversion principle
  https://en.wikipedia.org/wiki/Dependency_inversion_principle
• Architecting Android…Reloaded by Fernando Cejas
  https://fernandocejas.com/blog/engineering/2019-05-08-architecting-android-reloaded/

Looking for the English version of this article? Click here

Antes de comenzar…

Si es tu primera vez leyendo sobre Clean Architecture quizá te convenga saber algunas cosillas antes de seguir:

• Clean Architecture es el título de un libro escrito por Robert C. Martin (aka. Uncle Bob)
• No es una arquitectura en sí, sino una guía que encierra un conjunto de principios a seguir.
• La base de esta guía se encuentra en aplicar los principios SOLID.
• En términos generales, te intenta llevar a una estructura basada en el Dominio como punto central de tu aplicación (la capa en la que se implementará la lógica de tu aplicación). ¿Alguien habló de Domain-driven development?
• Un buen número de desarrolladores la confunde la arquitectura con N-capas.
• No es el santo grial, es una expresión algo mainstream entre los desarrolladores y por ende sirve como una forma fácil de describirle a un desarrollador de qué manera se ha estructurado un proyecto.

¿Qué es una arquitectura?

Básicamente, es una estructura, una manera de distribuir los componentes que conforman una aplicación en distintas agrupaciones. Por esto mismo, no existe una única manera de organizar tu proyecto. Diversos aspectos como el estado de tu proyecto, el tamaño de tu equipo, el tiempo, etc influirán en las decisiones que tomes al momento de decidir la manera en la que organizarás los componentes de tu aplicación.

Clean Architecture en el mundo Android

Mucho se ha dicho y escrito sobre cómo aplicar Clean Architecture en las aplicaciones que desarrollamos, un buen número de desarrolladores te hablarán sobre Separation of concerns and testing como las principales características de seguir estos principios, suelen a su vez olvidar un aspecto muy importante sobre Clean Architecture y que consiste en que su base yace en la implementación de la capa de Dominio.

Dicho esto ¿cómo se estructuraría un proyecto base siguiendo estos principios? Para trabajar en esto es importante establecer dos consideraciones importantes:

• Existe una regla en Clean Architecture por la cual toda capa exterior dependerá de una capa interior (y no al revés), quedando para el final la capa de Dominio sin dependencia alguna.

• Existe un flujo de datos que pasa por todas las capas externas e internas tanto de ida desde que se efectúe el ingreso de datos por parte del usuario (o de los sensores), pasando por la lógica de negocio/aplicación y terminando en la persistencia de los datos o el envío de los mismos a un servicio remoto, como también de vuelta con el resultado de la operación con el servicio hasta la presentación del resultado a nuestro usuario.

Teniendo en cuenta estos dos aspectos, para una estructura básica contaríamos con tres módulos: presentation, domain y data. La relación entre estos sería de la siguiente manera:

¿Qué componentes irían en cada capa?

Es importante reiterar que al hablar de arquitectura, hablamos de organización y estructura, por lo tanto, la distribución y qué componentes en específico irán en cada módulo dependerá del patrón que decidas emplear y el propósito de cada módulo:

• Domain deberá contener los elementos que contengan la lógica de tu aplicación y la lógica del negocio. Con ello en mente, tendremos clases de dominio, y además componentes que tendrán la lógica como son los Casos de Uso o Interactors. Este módulo NO debe depender del Android framework ni de dependencias de terceros. Este módulo puede ser un módulo Kotlin.
• Presentation tendrá los elementos que permitan mostrar información a nuestro usuario, recibir datos del mismo o de sensores. Además de los componentes visuales propios de Android (Activity y Fragment) y su sistema de UI (archivos XML o funciones de Compose), si se siguen patrones como MVP o MVVM, tendremos también Presenters o ViewModels respectivamente. Este módulo es un módulo Android.
• Data va a incluir todas las dependencias de networking (Retrofit, volley, etc) y de persistencia de datos (Room, SharedPreferences, DataStore, Firebase, etc). Si se emplea el patrón repositorio será en esta capa en la que tendremos la implementación de los repositorios y las fuentes de datos (data sources). Este módulo es un módulo Android también.

Seguramente aquí te podría surgir la siguiente duda: si Domain no tiene visibilidad de Data ¿cómo es que podríamos inyectar los repositorios en nuestros casos de uso? La respuesta se encuentra en el principio de Inversión de Dependencia (Dependency inversion) de SOLID.

Dependency inversion principle

Este principio de SOLID establece dos consignas:

• Los módulos de alto nivel no deberían importar nada de un módulo de bajo nivel. Pero ambos deberían depender de abstracciones (interfaces).
• Las abstracciones no deberían depender de los detalles. Los detalles (las implementaciones concretas) deberían depender de las abstracciones.

Teniendo en mente esto, nuestro módulo Domain deberá ser propietario de la interfaz del repositorio que se implementará dentro del módulo Data.

En código esto luciría más o menos de la siguiente manera, en el módulo Domain estaría la abstracción de un BookRepository.

interface BookRepository {
    suspend fun getBooks():List<Book>
}

class GetBooksUseCase(
    private val bookRepository: BookRepository
) { /*...*/ }

Mientras que en el módulo Data iría su implementación.

class BookRepositoryImpl (...) : BookRepository {
    override suspend fun getBooks(): List<Book> { /* ... */}
}

De este modo al momento de crear una instancia de nuestro caso de uso le podremos inyectar la implementación debido a la interfaz que hemos declarado.

Conclusiones

Podría mencionar algunas cosas como parte de la conclusión:

• Contar con una arquitectura o forma de organizar los componentes es mejor que no tener ninguna.
• Clean Architecture no es una arquitectura en sí, pero nos provee de una guía a seguir para estructurar nuestros proyectos.
• Existen otras arquitecturas que no cuentan con mucha fama, pero no por ello son menos útiles.
• Teniendo esta estructura, puedes usar lo que se te antoje tanto en la presentación (sea Views-XMLs o Compose) como a nivel del acceso a datos (Retrofit, Room, SharedPreferences, etc).
• En mi experiencia, la buena aplicación de los principios SOLID te da una buena base para ir perfilando la arquitectura de tu proyecto.
• La relanzada guía oficial de arquitectura de Android no sigue Clean Architecture, pero sí provee de una arquitectura separada en capas.

Referencias

• Clean Architecture
  https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
• Dependency Inversion principle
  https://en.wikipedia.org/wiki/Dependency_inversion_principle
• Architecting Android…Reloaded by Fernando Cejas
  https://fernandocejas.com/blog/engineering/2019-05-08-architecting-android-reloaded/

Android — Desmitificando Clean Architecture was originally published in DevPicon by Armando on Medium, where people are continuing the conversation by highlighting and responding to this story.