Forem: Marlon López

Eleva tu app Android: patrones de arquitectura con Jetpack Compose

Marlon López — Sun, 14 Dec 2025 00:36:07 +0000

📱 ¿A qué llamamos los patrones de arquitecturas Android?

Son formas recomendadas de organizar el código de una app Android para que sea:

Más mantenible
Más escalable
Más testeable
Más fácil de entender en equipo

Con Kotlin + Jetpack Compose, Google promueve arquitecturas reactivas y unidireccionales.

🧩 Componentes clave con Jetpack Compose

Antes de los patrones, es importante entender los roles principales:

1. UI (Compose)

Funciones @Composable
Solo muestran el estado
No contienen lógica de negocio
Reaccionan a cambios de estado

@Composable
fun HomeScreen(state: HomeState) {
    Text(text = state.title)
}

2. ViewModel

Maneja el estado de la UI
Contiene la lógica de presentación
Sobrevive a cambios de configuración
Expone StateFlow o LiveData

class HomeViewModel : ViewModel() {
    private val _state = MutableStateFlow(HomeState())
    val state = _state.asStateFlow()
}

3. Domain / Business Logic

Reglas de negocio
Casos de uso (UseCases)
Independiente de Android

4. Data Layer

Repositorios
APIs (Retrofit)
Base de datos (Room)

🏗️ Patrones de arquitectura más usados

🔹 1. MVVM (Model–View–ViewModel) ⭐⭐⭐⭐⭐

El más usado y recomendado con Compose

Estructura

UI (Compose)
   ↓
ViewModel
   ↓
Repository
   ↓
Data Source (API / DB)

Flujo de datos (unidireccional)

User Action → ViewModel → State → UI

Ejemplo simple

@Composable
fun HomeScreen(viewModel: HomeViewModel = viewModel()) {
    val state by viewModel.state.collectAsState()

    Button(onClick = { viewModel.loadData() }) {
        Text("Cargar")
    }
}

Ventajas:

Separación clara de responsabilidades
Fácil testing
Ideal para Compose

🔹 2. MVI (Model–View–Intent) ⭐⭐⭐⭐

Muy popular en apps grandes

Conceptos clave

Intent: acción del usuario
State: estado completo de la pantalla
Reducer: transforma el estado

Flujo

Intent → ViewModel → Reducer → New State → UI

Ejemplo conceptual

sealed class HomeIntent {
    object LoadData : HomeIntent()
}

data class HomeState(val loading: Boolean = false)

Ventajas:

Estado inmutable
Flujo predecible
Ideal para UIs complejas

Desventajas:

Más código y complejidad

🔹 3. Clean Architecture con Compose ⭐⭐⭐⭐⭐

No es un patrón UI, sino una arquitectura completa

Capas

Presentation (Compose + ViewModel)
Domain (UseCases)
Data (Repository, API, DB)

Reglas

Las capas internas no dependen de las externas
UI no conoce detalles de datos

Ventajas:

Escalable
Muy testeable
Ideal para proyectos grandes

🧠 Recomendación oficial de Google

MVVM + Unidirectional Data Flow + StateFlow + Jetpack Compose
ViewModel como fuente única de estado
Compose solo observa y renderiza
Estado inmutable
Eventos separados del estado

🔁 Unidirectional Data Flow (UDF)

Event → ViewModel → State → Compose UI

Esto evita bugs y hace la UI predecible.

📌 ¿Cuál usar?

Proyecto	Recomendación
App pequeña	MVVM
App mediana	MVVM + Clean
App grande	MVI + Clean
UI compleja	MVI

✅ Conclusión

Jetpack Compose cambia la forma de pensar la UI
MVVM sigue siendo la base
El estado es el corazón de la app
Flujo unidireccional = menos errores

🔹 Referencias

📐 Material 3 Adaptive: Implementing Window Size Classes in Kotlin Compose

Marlon López — Wed, 12 Nov 2025 02:59:14 +0000

Hey everyone! 👋

I wanted to share a look at a crucial technique for modern Android development: implementing Window Size Classes to create truly adaptive layouts that align with the recent updates to Material 3 Adaptive Guidance.

The MobileWindowSize enum in this code snippet is the foundation. It categorizes the available screen space based on Google's defined WindowWidthSizeClass and WindowHeightSizeClass (Compact, Medium, Expanded).

🧐 Material 3 & Component Placement:

This code directly drives key design decisions based on the available screen space, like:

Navigation: Deciding whether to use a bottom NavigationBar (Compact), a NavigationRail (Medium), or a permanent NavigationDrawer (Expanded).
Content Layout: Reorganizing content (e.g., using a master-detail pattern) to maximize screen utility on tablets and desktops.

By mapping screen dimensions to profiles like MOBILE_PORTRAIT or DESKTOP, we ensure our app components are always displayed according to Material 3's best practices for large screens.

📚 Resources & Official Documentation

For the full guide on implementation and understanding the key breakpoints used in M3 Adaptive, these are the best resources:

1. Official Google Guide: Check out the complete guide on implementing this strategy: Use window size classes | Adaptive layouts in Compose | Android Developers

2. Practical Course: To see another code implementation of Window Size Classes using Material 3 Adaptive, check out this Compose crash course from Philipp Lackner: The Full Jetpack Compose Responsive UI Crash Course (The topic starts at [31:21]).

Implementing this logic is non-negotiable for delivering a high-quality, multi-form factor user experience!

🪟 Window Size Class: Migrating from androidx.window to Material 3 Adaptive

Marlon López — Sun, 02 Nov 2025 18:39:57 +0000

(Cover image: Window size class representations based on width, courtesy of Google)

Spanish version: Here.

In recent years, the Android ecosystem has increasingly embraced adaptive design. From the rise of foldable devices to large screens, managing the window size (WindowSizeClass) became key to offering seamless experiences across any form factor.

With the arrival of Material 3 Adaptive, Google proposes a new way to handle window size classes, integrating this concept directly into the Material Design libraries.

In this article, I want to share my experience migrating from androidx.window to the new Material 3 API, the challenges I encountered, and the advantages this change brings.

🧩 1. Context: The Previous Approach (androidx.window)

Until recently, the most common way to calculate size classes was using:

import androidx.window.layout.WindowMetricsCalculator

val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(activity)
val width = metrics.bounds.width()
val height = metrics.bounds.height()

The size class (compact, medium, expanded) was then derived manually or by using the WindowSizeClass extension from androidx.compose.material3.windowsizeclass.
This worked well, but it required manual configuration and was somewhat separate from modern Material 3 practices.

🧱 2. Material 3 Adaptive: The New Path

Material 3 introduces a new unified API for handling adaptive layouts, better integrating size classes with design components.

Now you can use:

import androidx.compose.material3.adaptive.WindowAdaptiveInfo
import androidx.compose.material3.adaptive.currentWindowAdaptiveInfo
val adaptiveInfo = currentWindowAdaptiveInfo()
val windowSizeClass = adaptiveInfo.windowSizeClass

This simplifies access to the current window size and connects it with other elements of the adaptive system (e.g., NavigationSuiteScaffold or PaneScaffold).

🔄 3. The Migration Process

During the migration, the main steps were:

Remove androidx.window dependencies (e.g., androidx.window:window or androidx.window:window-java).
Update Material 3 dependencies to a version that supports adaptive features.
Replace metric calculation functions with the use of currentWindowAdaptiveInfo().
Adjust breakpoints if you were using custom values.

💡 4. Benefits of the New Approach

✅ Direct integration with Material 3 adaptive components.
🧭 Less boilerplate: no need to calculate metrics manually.
💥 Better future support for foldable screens and multitasking.
🧩 Visual cohesion: Material 3 adapts interfaces more easily based on size.

⚠️ 5. Considerations and Limitations

Some advanced androidx.window functions (like FoldingFeature) may still require
additional code.
Full support depends on the version of Compose and Material 3 libraries.
It is still evolving, so there may be minor changes in the APIs.

🚀 6. Conclusion

The migration to Material 3 Adaptive is not only straightforward but also aligns your app with the future of adaptive design on Android.
If you are already using WindowSizeClass, the change will allow you to maintain a cleaner, modern, and more scalable foundation.

🪟 Window Size Class: migrando de androidx.window a Material 3 Adaptive

Marlon López — Sun, 02 Nov 2025 18:36:46 +0000

(Imagen de portada: Representaciones de clases de tamaños de ventana basadas en el ancho, creditos a Google).

Versión en inglés: Aquí.

En los últimos años, el ecosistema Android ha ido abrazando cada vez más el diseño adaptativo. Desde el auge de los dispositivos plegables hasta las pantallas grandes, la gestión del tamaño de ventana (WindowSizeClass) se volvió clave para ofrecer experiencias fluidas en cualquier formato.

Con la llegada de Material 3 Adaptive, Google propone una nueva forma de manejar las clases de tamaño de ventana, integrando este concepto directamente en las librerías de Material Design.
En este artículo quiero compartir mi experiencia migrando de androidx.window a la nueva API de Material 3, los retos que encontré y las ventajas que trae este cambio.

🧩 1. Contexto: el enfoque anterior (androidx.window)

Hasta hace poco, la forma más común de calcular clases de tamaño era usando:

import androidx.window.layout.WindowMetricsCalculator

val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(activity)
val width = metrics.bounds.width()
val height = metrics.bounds.height()

Luego, se derivaba manualmente la clase de tamaño (compact, medium, expanded) o se usaba la extensión WindowSizeClass de androidx.compose.material3.windowsizeclass.
Esto funcionaba bien, pero requería una configuración manual y estaba algo separado de las prácticas modernas de Material 3.

🧱 2. Material 3 Adaptive: el nuevo camino

Material 3 introduce una nueva API unificada para manejar layouts adaptativos, integrando mejor las clases de tamaño con los componentes de diseño.

Ahora puedes usar:

import androidx.compose.material3.adaptive.WindowAdaptiveInfo
import androidx.compose.material3.adaptive.currentWindowAdaptiveInfo
val adaptiveInfo = currentWindowAdaptiveInfo()
val windowSizeClass = adaptiveInfo.windowSizeClass

Esto simplifica el acceso al tamaño actual de la ventana y lo conecta con otros elementos del sistema adaptativo (por ejemplo, NavigationSuiteScaffold o PaneScaffold).

🔄 3. El proceso de migración

Durante la migración, los pasos principales fueron:

Eliminar dependencias de androidx.window (por ejemplo, androidx.window:window o androidx.window:window-java).
Actualizar las dependencias de Material 3 a una versión que soporte adaptive.
Reemplazar las funciones de cálculo de métricas por el uso de currentWindowAdaptiveInfo().
Ajustar los puntos de quiebre (breakpoints) si usabas valores personalizados

💡 4. Beneficios del nuevo enfoque

✅ Integración directa con los componentes adaptativos de Material 3.
🧭 Menos boilerplate: no hay que calcular métricas manualmente.
💥 Mejor soporte futuro para pantallas plegables y multitareas.
🧩 Cohesión visual: Material 3 adapta más fácilmente las interfaces según el tamaño.

⚠️ 5. Consideraciones y limitaciones

Algunas funciones avanzadas de androidx.window (como FoldingFeature) aún pueden requerir
código adicional.
El soporte completo depende de la versión de Compose y de las librerías de Material 3.
Aún está en evolución, así que puede haber cambios menores en las APIs`.

🚀 6. Conclusión

La migración a Material 3 Adaptive no solo es sencilla, sino que alinea tu app con el futuro del diseño adaptativo en Android.
Si ya estás usando WindowSizeClass, el cambio te permitirá mantener una base más limpia, moderna y escalable.

First steps using Material3 in a WearOS Android App

Marlon López — Sun, 22 Sep 2024 18:43:20 +0000

Would you like your WearOS app to have the same modern and sophisticated look as the latest Android apps? Material Design 3, design system built and supported by Google, has already transformed the look and feel of millions of apps. Now, it’s your wearable apps’ turn. Although the library responsible for applying material3 in WearOS is still in alpha phase, this new specification promises to take smartwatch user interfaces to the next level.

In the following text, I will share some aspects to take into account when changing from current material design system library to material3 in our Android applications for WearOS.

About WearOS Compose Material 3 Library

This library makes it easier for developers to write Jetpack Compose applications for Wearable devices that implement Wear Material 3 Design UX guidelines and specifications.

Let's start the migration

In Android studio, create a new project that generates a WearOS App. you can check the instructions from the Android Official Guide, After created, lets check that the the app is successfully built and running in an emulator or phisical wearable device.

Adding the Wear Compose Material 3 library

When moving from the actual Wear Compose Material library to the Material3 one, its important to note that, at the time of writing, it was straightforward to change the composables used, just be careful with this, not all composables available in the material2 version have the corresponding material3 composable for WearOS.

Android Wear Compose Material 3 library can be installed using the instructions from Maven central.

dependencies {
  ...
  implementation("androidx.wear.compose:compose-material3:1.0.0-alpha25")
  ...  
}

The library version at the time of writing is 1.0.0-alpha25.

Inside the build.gradle.kts file in the wearos app module, replace the previous wear compose material dependency androidx.wear.compose:compose-material with the above one. If youre using version catalogs, apply the adjustments in the respective gradle/libs.version.toml file as well.

Next, clean and rebuild the project, at this moment, the errors related to the replaced wear compose material library starts to show up.

Adjusting the MaterialTheme

So far so good, now, we're gonna fix the material theme properties (colors, typography, theme composable) using the new material3 classes for wearos.

Keep in mind that we're using an alpha version of the Android Wear Compose Material 3 library, so, the foundations of the library can be changed in the future.

Part 01: Color schemes

Firstly, the material 3 colors are different from previous material color system, so, in the Color.kt file, we see the contents like this:

/* Color.kt */
import androidx.compose.ui.graphics.Color
import androidx.wear.compose.material.Colors

internal val wearColorPalette: Colors = Colors(
  primary = Color(0xFFAECBFA),
  primaryVariant = Color(0xFF8AB4F8),
  secondary = Color(0xFFFDE293),
  secondaryVariant = Color(0xFF594F33),
  background = Color.Black,
  surface = Color(0xFF303133),
  error = Color(0xFFEE675C),
  onPrimary = Color(0xFF303133),
  onSecondary = Color(0xFF303133),
  onBackground = Color.White,
  onSurface = Color.White,
  onSurfaceVariant = Color(0xFFDADCE0),
  onError = Color(0xFF000000)
)

In this case, we change the Colors variable with the following:

/* Color.kt */
import androidx.compose.ui.graphics.Color
import androidx.wear.compose.material3.ColorScheme

internal val wearColorPalette = ColorScheme(
  primary = Color(0xFF1F3701),
  primaryDim = Color(0xFF1F3701),
  primaryContainer = Color(0xFFCDEDA3),
  onPrimary = Color(0xFF354E16),
  onPrimaryContainer = Color(0xFFBFCBAD),
  secondary = Color(0xFF2A331E),
  secondaryDim = Color(0xFF2A331E),
  secondaryContainer = Color(0xFFDCE7C8),
  onSecondary = Color(0xFF404A33),
  onSecondaryContainer = Color(0xFFA0D0CB),
  tertiary = Color(0xFF003735),
  tertiaryDim = Color(0xFF003735),
  tertiaryContainer = Color(0xFFBCECE7),
  onTertiary = Color(0xFF1F4E4B),
  onTertiaryContainer = Color(0xFFFFB4AB),
  onSurface = Color(0xFF44483D),
  onSurfaceVariant = Color(0xFF8F9285),
  surfaceContainerLow = Color(0xFF1E201A),
  surfaceContainer = Color(0xFF282B24),
  surfaceContainerHigh = Color(0xFF33362E),
  outline = Color(0xFF44483D),
  outlineVariant = Color(0xFF000000),
  background = Color(0xFF12140E),
  onBackground = Color(0xFFE2E3D8),
  error = Color(0xFF690005),
  onError = Color(0xFF93000A),
  errorContainer = Color(0xFFFFDAD6),
  onErrorContainer = Color(0xFFE2E3D8),
)

When using ColorScheme class, the attributes are quite similar to the m3 color available in the official m3 website.

For the color selection process, we refer to the material3 theme builder website. When picking the colors and fonts, and finally exporting the theme (in this scenario, export the compose theme), inside the exported theme it exists the Color.kt file.

Check the exported theme, open the Color.kt file, check the color pallete for light and dark theme, alog with the dynamic color contrast color palette, in it, you can find the dark color palette.

In this topic, the color palette for wearos takes the dark theme and not the light theme (not recommended, by the way), so, you use the dark colors pallete (os the dynamic color contrast color palettes) for initializing the color attributes in the ColorScheme class, with those attributes, the color palette.

After creating the color scheme for wearos, you can change the colors, but, keep in mind the material 3 color system definitions when doing so.

Part 02: Typography

In WearOS apps, there is a recommendation in the official ui design guide for using the default typography, which includes the Roboto font and the default settings (weight, size, style, etc.).

Now, let's change the typography for wearos app module using the m3 new Typography class.

/* Type.kt */

/* NOTE: New import, the old one is:<br> 
 * import androidx.wear.compose.material.Typography 
 */
import androidx.wear.compose.material3.Typography

// Set of Material typography styles to start with
val appTypography = Typography(...)

In this topic, the textstyles for the Typography class are very different, for reference, lets see the following table:

M2 Typography Text styles	M3 Typography Text styles
display1 display2 display3 title1 title2 title3 body1 body2 button caption1 caption2 caption3	displayLarge displayMedium displaySmall titleLarge titleMedium titleSmall labelLarge labelMedium labelSmall bodyLarge bodyMedium bodySmall bodyExtraSmall numeralExtraLarge numeralLarge numeralMedium numeralSmall numeralExtraSmall

The typography attributes / text styles are defined in a similar way to the official material 3 documentation, so, after changing the class, you can make the customizations that you want for default font family, sizes, etc.

NOTE: At the time of writing this, I am not aware of the numeral TextStyle and where to use it in composables, so we will keep an eye out for future updates to the Android Wear Compose Material 3 library.

Part 03: Shapes

Following with the material 3 Shapes for WearOS, they have similar recommendations and default settings as the previous section: For shapes, the official documentation generally recommend using the default Material Wear shapes which are optimized for round and non-round devices.

Now, let's change the shapes configuration for wearos app module using the m3 new Shapes class, if it doesn not exist, create the Shape.kt file.

/* Shape.kt */

/* NOTE: New import, the old one is:<br> 
 * import androidx.wear.compose.material.Shapes 
 */
import androidx.wear.compose.material3.Shapes

// Set of Material typography styles to start with
val appShapes = Shapes(...)

The new Shapes class have added 2 more shape configurations, for reference, lets check the following table:

M2 Shapes	M3 Shapes
small medium large	extraSmall small medium large extraLarge

You can customize the Shapes configuration for any of the listed shape sizes, but, keep in mind the material 3 color system definitions when doing so.

Part 04: Theme Composable

Now, let's glue the previous settings into the MaterialTheme composable function, in this topic, we do the following:

1- Fix the import, so we call MaterialTheme from material3 package.
2- Check that the colorScheme, typoghaphy (and shapes, if you did a customization of shapes) are compatible.

After this, the results is described in the following snippet:

/* Theme.kt */

import androidx.compose.runtime.Composable
import androidx.wear.compose.material3.MaterialTheme

@Composable
WearosTheme(
  content: @Composable () -> Unit
) {
  MaterialTheme(
    colorScheme = wearColorPalette,
    typography = appTypography,
    /* For shapes, we generally recommend using the default 
     * Material Wear shapes which are optimized for round 
     * and non-round devices.
     */
    shapes = appShapes,
    content = content,
  )    
}

After doing this, let's clean and rebuild the project, since here we are ding the migration in a newly created wearos project, the error could be found in the MainActivity class and they are related to some imports and classes, so, let's fix them in the next section.

Fixing the errors in MainActivity class

Inside the mainActivity class, the following errors appeared:

a. Fix the imports related to androidx.wear.compose.material package:

import androidx.wear.compose.material3.MaterialTheme
import androidx.wear.compose.material3.Text
import androidx.wear.compose.material3.TimeText

b. Fix the usage of MaterialTheme.colors to MaterialTheme.colorScheme:

MaterialTheme.colors.background -> MaterialTheme.colorScheme.background
MaterialTheme.colors.primary -> MaterialTheme.colorScheme.primary

c. Fix the TimeText composable invocation, inside the WearApp composable function body, here, we adjust the WearApp composable:

/* MainActivity.kt */
@Composable
fun WearApp(greetingName: String) {
  MyApplicationTheme {
    Box(
      modifier = Modifier.fillMaxSize().background(MaterialTheme.colorScheme.background),
      contentAlignment = Alignment.Center
    ) {
      TimeText { time() }
      Greeting(greetingName = greetingName)
    }
  }
}

¿What happened in `TimeText` composable?

The mentioned composable has been upgraded, you can check the information from the composables.com website.

The complete MainActivity class looks like this:

/* MainActivity.kt */

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.background
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.runtime.Composable
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.res.stringResource
import androidx.compose.ui.text.style.TextAlign
import androidx.compose.ui.tooling.preview.Preview
import androidx.core.splashscreen.SplashScreen.Companion.installSplashScreen
import androidx.wear.compose.material3.MaterialTheme
import androidx.wear.compose.material3.Text
import androidx.wear.compose.material3.TimeText
import androidx.wear.tooling.preview.devices.WearDevices

class MainActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    installSplashScreen()
    super.onCreate(savedInstanceState)
    setTheme(android.R.style.Theme_DeviceDefault)
    setContent {
      WearApp("Android")
    }
  }
}

@Composable
fun WearApp(greetingName: String) {
  MyApplicationTheme {
    Box(
      modifier = Modifier.fillMaxSize()
        .background(MaterialTheme.colorScheme.background),
      contentAlignment = Alignment.Center
    ) {
      TimeText { time() }
      Greeting(greetingName = greetingName)
    }
  }
}

@Composable
fun Greeting(greetingName: String) {
  Text(
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    color = MaterialTheme.colorScheme.primary,
    text = stringResource(R.string.hello_world, greetingName)
  )
}

@Preview(device = WearDevices.SMALL_ROUND, showSystemUi = true)
@Composable
fun DefaultPreview() {
  WearApp("Preview Android")
}

With this, the next step is reabuild the project, there will be no errors at this point, so, from here, you can test the wearos app in the emulator or device.

Conclusions

In this 'first steps' blog post, we learned to apply the Android Wear Compose Material 3 library, as a first glance, we found similar configs for the color schemes, typography, shapes and theme composable function, but, there are more changes, like the TimeText composable, that we could apply while using the library.

Keep in mind that the library is in alpha state, and, while so, there will be changes inside it, which can affect the usage of the composables/classes/values described here.

I hope you find this informative and useful and that at some point you can follow these steps in your Android applications, in order to apply a good migration to material 3 when developing Wearos apps.

Thanks for reading, happy coding! 😊

Adapt Kotlin 2.0 in Android applications

Marlon López — Sat, 01 Jun 2024 23:43:07 +0000

Read this post in Spanish here.

Recently, version 2.0 of Kotlin has been released, and with it, several adjustments to Android projects to adapt or implement code with this new version of the programming language officially supported by Google for Android mobile development (Multiplatform, according to the latest versions of the Google I/O event).

In this short article, I explain my experience migrating from version 1.9.23 to version 2.0.0; This, due to the novelties that the use of this new version covers in projects that use Kotlin as a programming language, and also the possible difficulty for many of us developers to apply migrations from versions of Kotlin much lower than 1.9.0.

About the K2 compiler

The K2 compiler is a complete reimplementation of the original Kotlin compiler, designed to offer significant improvements in Android application development. Introduced in Kotlin 2.0, K2 provides several advantages, among which are: faster compilation speed, performance improvements, and improved cross-platform support; These advantages applied to Android projects allow a reduction in the size of the applications by generating more compact code, as well as the generation of native code which implies greater performance in mobile applications.

How to test K2 compiler on Android?

It is worth mentioning that this section covers the configuration aspect from the point of view of Android projects. I will not mention details of KMP, although several of the details indicated are easy to assimilate if one already has experience in cross-platform projects using Kotlin.

1. A new build directory

Kotlin 2.0 introduces a new build output directory: .kotlin. you must add it to the .gitignore file so that its contents do not appear in commits:

#.gitignore
# Kotlin 2.0
.kotlin/

2. Apply new version of kotlin

Now we go to the gradle/libs.versions.toml file, in this section, it is assumed that Version Catalogs are being used to control the dependencies of the mobile application (versions, plugins, etc.), The reference to the Kotlin version is located, and it is changed to version 2.0.0. So:

# gradle/libs.versions.toml
[versions]
agp="8.4.1"
kotlin="2.0.0"
ksp="2.0.0-1.0.21"

Regarding compatibility, the versions of the Kotlin symbol processor (KSP) libraries and the gradle plugin for Android (AGP, acronym used for reference) must also be updated. The previous snippet indicates the versions for review.

At the library level, the following Kotlin libraries are also updated:

# gradle/libs.versions.toml
[libraries]
kotlin-gradle-plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:2.0.0"
kotlin-serialization-plugin = "org.jetbrains.kotlin:kotlin-serialization:2.0.0"

Note: there are libraries that, at the time of writing this article, did not present problems in terms of changing versions, such as kotlin-coroutines, kotlin-serialization, kotlin-serialization-json.

At the plugin level, the Kotlin libraries are also updated below, taking into account the version reference already indicated previously:

# gradle/libs.versions.toml
[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

With this done, run the command gradle clean build or from Android Studio, build the project.

3. Update the Compose compiler

Another important aspect regarding the configuration of Android projects, especially using Jetpack Compose, is related to the Compose compiler for Kotlin, which is a configuration that allows the transformation of functions annotated as @Composable in order to apply optimizations In the compilation of these functions, now, the way of defining the version of the compose compiler has presented a big change, which is described below.

Previously, the version of the compose compiler had to be placed inside the build.gradle file of the gradle project module that has the Android implementations and that also contains the Jetpack Compose implementations.

/* build.gradle.kts */
…
composeOptions {
 kotlinCompilerExtensionVersion="1.5.3"
}
…

And if you use Version Catalogs, the version would be indicated as follows:

# gradle/libs.versions.toml
[versions]
compose-compiler = “1.5.3”
…

/* build.gradle.kts */
…
composeOptions {
 kotlinCompilerExtensionVersion = libs.versions.composeCompiler.get()
}
…

This initiative was good at the time, but it has some maintenance problems, since it is required to be compatible with the current version of Kotlin. It is different from the Compose version and the IDE did not propose to improve it. Every time you update your Kotlin version, you have to Google the Jetpack Compose documentation for the compatible version of the Compose compiler. Kotlin 2.0 solves this problem.

Now, the inclusion of a new gradle plugin is applied to the gradle/libs.versions.toml file, which is responsible for managing the more organized version of the compose compiler and linked to the Kotlin version.

# gradle/libs.versions.toml
[plugins]
…
kotlin-compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

After this action, the build.gradle.kts file of the Android module that has the Jetpack Compose capabilities is modified, removing the composeOptions configuration. kotlinCompilerExtensionVersion and adding the reference to the kotlin-compose-compiler plugin in the plugins { .. } section.

/* build.gradle.kts */
…
plugins {
 …
 alias(libs.plugins.compose.compiler)
}
…

With this done, run the gradle clean build command or from Android Studio, build the project or synchronize.

And that's it! This plugin will configure the Compose compiler version based on the current Kotlin version.

Conclusions

Overall, the K2 compiler represents a significant step forward for Android app development with Kotlin. Improvements in speed, performance, and extensibility make it a valuable tool for Android developers.

Now that the use of Kotlin 2.0.0 is becoming standard, now is a good time to update our Android applications so that they support more of the technology that goes and evolves in terms of Kotlin, KMP, Jetpack Compose, and the other technologies that Google and app developers and mobile libraries are adapting for more modern mobile apps with better features.

I hope you find this informative and useful and that at some point you can follow these steps in your Android applications, in order to apply a good migration to Kotlin 2.0.0.

Thanks for reading, happy coding! 😊

Adaptar Kotlin 2.0 en aplicaciones Android

Marlon López — Sat, 01 Jun 2024 18:06:06 +0000

Lee este post en inglés aquí.

Recientemente, se ha liberado la versión 2.0 de Kotlin, y con ello, varios ajustes a los proyectos Android para adaptar o implementar código con esta nueva versión del lenguaje de programación oficialmente soportado por Google para desarrollo móvil Android (Multiplataforma, según las últimas versiones del evento Google I/O).

En este corto artículo, explico mi experiencia migrando de la versión 1.9.23 a la versión 2.0.0; Esto, debido a las novedades que abarca el uso de esta nueva versión en proyectos que usan Kotlin como lenguaje de programación, y también la posible dificultad de muchos de nosotros los desarrolladores para aplicar migraciones desde versiones de Kotlin muy inferiores a la 1.9.0.

Acerca del compilador K2

El compilador K2 es una reimplementación completa del compilador Kotlin original, diseñado para ofrecer mejoras significativas en el desarrollo de aplicaciones Android. Introducido en Kotlin 2.0, K2 aporta varias ventajas, entre las que se destacan: mayor velocidad de compilación, mejoras en rendimiento, y soporte multiplataforma mejorado; Estas ventajas aplicadas a proyectos Android, permiten una reducción en el tamaño de las aplicaciones al generar código más compacto, así como la generación de código nativo lo cual implica mayor rendimiento en las aplicaciones móviles.

¿Cómo probar el compilador K2 en Android?

Cabe mencionar, en este apartado se cubre el aspecto de configuración desde el punto de vista de proyectos Android, no mencionaré detalles de KMP, aunque varios de los detalles indicados son fáciles de asimilar si uno ya tiene experiencia en proyectos multiplataforma usando Kotlin.

1. Un nuevo directorio de compilación

Kotlin 2.0 presenta un nuevo directorio de salida de compilación: .kotlin. debes agregarlo al archivo .gitignore para que su contenido no aparezca en las confirmaciones:

# .gitignore 
# Kotlin 2.0
.kotlin/

2. Aplicar nueva versión de kotlin

Ahora vamos al archivo gradle/libs.versions.toml, en este apartado, se asume se está utilizando Version Catalogs para controlar las dependencias de la aplicación móvil (versiones, plugins, etc.), Se localiza la referencia a la versión de Kotlin, y se cambia a la versión 2.0.0. así:

# gradle/libs.versions.toml
[versions]
agp = "8.4.1"
kotlin = "2.0.0"
ksp = "2.0.0-1.0.21"

A propósito de la compatibilidad, se debe actualizar también las versiones de las librerías Kotlin symbol processor (KSP) y el plugin gradle para Android (AGP, siglas usadas para referencia), en el snippet anterior se indican las versiones para revisión.

A nivel de librerías, se actualizan también las librerias de kotlin a continuación:

# gradle/libs.versions.toml
[libraries]
kotlin-gradle-plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:2.0.0"
kotlin-serialization-plugin = "org.jetbrains.kotlin:kotlin-serialization:2.0.0"

Nota: hay librerías que, al momento de la redacción del presente artículo, no presentaron inconvenientes en cuanto a cambio de versiones, como kotlin-coroutines, kotlin-serialization, kotlin-serialization-json.

A nivel de plugins, se actualizan también las librerias de kotlin a continuación, esto, tomando en cuenta la referencia de versión ya indicada previamente:

# gradle/libs.versions.toml
[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

Con esto realizado, ejecutar el comando gradle clean build o desde Android Studio, hacer build del proyecto.

3. Actualizar el compilador de Compose

Otro aspecto importante en cuanto a la configuración de proyectos Android, especialmente utilizando Jetpack Compose, es el relacionado con el compilador de Compose para Kotlin, el cual es una configuración que permite la transformación de funciones anotadas como @Composable en pro de aplicar optimizaciones en la compilación de dichas funciones, ahora, la forma de definir la versión del compilador de compose ha presentado un gran cambio, el cual se describe a continuación.

Anteriormente, se tenia que colocar la versión del compilador de compose dentro del archivo build.gradle del modulo del proyecto gradle que posea las implementaciones Android y que contengan también las implementaciones de Jetpack Compose.

/* build.gradle.kts */
…
composeOptions {
  kotlinCompilerExtensionVersion = "1.5.3"
}
…

Y en caso de utilizar Version Catalogs, se indicaría la versión de la siguiente manera:

# gradle/libs.versions.toml
[versions]
compose-compiler = “1.5.3”
…

/* build.gradle.kts */
…
composeOptions {
  kotlinCompilerExtensionVersion = libs.versions.composeCompiler.get()
}
…

Esta iniciativa fue buena en su momento, pero presenta algunos problemas de mantenimiento, ya que se requiere que sea compatible con la versión actual de Kotlin. Es diferente de la versión Compose y el IDE no propuso mejorarla. Cada vez que se actualiza la versión de Kotlin, se tiene que buscar en la documentación de Jetpack Compose en Google la versión compatible del compilador Compose. Kotlin 2.0 soluciona este problema.

Ahora, se aplica en el archivo gradle/libs.versions.toml la inclusión de un nuevo plugin de gradle, que se encarga de manejar la versión del compilador de compose mas organizada y ligada a la versión de Kotlin.

# gradle/libs.versions.toml
[plugins]
…
kotlin-compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

Luego de esta accion, se modifica el archivo build.gradle.kts del módulo Android que posea las capacidades de Jetpack Compose, removiendo la configuración composeOptions. kotlinCompilerExtensionVersion y agregando la referencia al plugin kotlin-compose-compiler en la sección plugins { .. }.

/* build.gradle.kts */
…
plugins {
  …
  alias(libs.plugins.compose.compiler)
}
…

Con esto realizado, ejecutar el comando gradle clean build o desde Android Studio, hacer build del proyecto o sincronizar.

¡Y eso es todo! Este complemento configurará la versión del compilador Compose según la versión actual de Kotlin.

Conclusiones

En general, el compilador K2 representa un avance significativo para el desarrollo de aplicaciones Android con Kotlin. Las mejoras en la velocidad, el rendimiento y la extensibilidad lo convierten en una herramienta valiosa para los desarrolladores Android.

Ahora que ya se está volviendo como estándar el uso de Kotlin 2.0.0, Ahora es buen momento para actualizar nuestros aplicativos Android para que estos soporten más de la tecnología que va y va evolucionando en cuando a Kotlin, KMP, Jetpack Compose, y las demás tecnologías que desde Google y desarrolladores de apps y librerias móviles van adaptando para unas apps móviles mas modernas y con mejores prestaciones.

Espero que encuentres esto informativo y útil y que en algún momento puedas seguir estos pasos en tus aplicaciones de Android, en pro de aplicar una buena migración hacia Kotlin 2.0.0.

Gracias por leer, ¡feliz código! 😊

Using launcher and themed icons in Android studio, the manual way

Marlon López — Sat, 23 Dec 2023 19:41:42 +0000

As per android official documentation: An adaptive icon can display differently depending on individual device capabilities and user theming. Adaptive icons are primarily used by the launcher on the home screen, but they can also be used in shortcuts, the Settings app, sharing dialogs, and the overview screen.

In this short article, you can see a way to create and use adaptive icons using png or webp images, this also can be done using svg files, remember that for svg files you have to use a dedicated tool for designing the images.

Finding the images

You can use images from the internet for making the launcher icon for your android apps, in most cases, you can grab one from a external site, but, when using the file you must credit to its author.

The images we'll be using are found in the Flaticon website, i like swimming, so the icons choosen.

Flaticon is the largest free database of editable icons with over 7 million resources available.

Themed icons

With Android 13 (API level 33) or above, users can theme their adaptive icons, the feature can be enabled via device system settings.

For the exercise, i selected the icons provided for the normal launcher icon and the themed icon.

The icons used has to have equal size (512px in this case), both the launcher and the themed/monochrome icon has to be with transparent background.

Add adaptive icons in android studio

In this section, we go to android studio, we can choose to create a new project or use an existing one, just keep in mind that if the following actions are applied, it is recommended to keep in mind that when creating the adaptive icons they replace the existing icons (it is assumed there is version control applied in these cases).

Once in the IDE, check the res folder, right-click on it and select the option New > Image asset.

Once the image asset configuration dialog appears, we can select the image for the icon in the foreground layer tab, for this part we select the monochrome icon that we chose earlier, also, we set the scaling for the icon to be trimmed and to have a zoom of 60%.

Later, in the background layer tab, we select the source asset type to color, and set the color using the hex color #FFFBFE, additional settings remain as the default in the dialog.

After configured the icon, we do click Next, for reviewing the icon files to be generated.

In this screen, we can see that the images are stored in the mipmap folders for each available app density, also, the images generated using the filenames ic_launcher.xml, ic_launcher_round.webp and ic_launcher_foreground.webp.

At this point, we are going to use the ic_launcher_foreground.webp files, because those icons represent the monochrome foreground layer for the themed icon.

The following step is to rename the ic_launcher_foreground.webp files to ic_launcher_monochrome.webp. for this, we can use the menu Refactor > Rename (Mayus + F6) option.

After renamimg, the files are shown like this:

Now, we repeat the steps for adding a launcher icon, this time, adding the normal icon we choosed.

As result, we have both the monochrome and the colored foreground layer for the adaptive icon.

Now, check the results for the adaptive icon display

Now that we have ready the launcher icon using the normal colored image we used, this time we check the launcher.xml files, which contains the setting for the foreground layer and the background layer for the adaptive icon.

In the exercise, we made both the not-round and the round launcher icon based on the configuration we used before for creating the launcher icons, so, we check both xml files:



{root project folder}/app/src/main/res/mipmap-anydpi-v26
res/mipmap-anydpi-v26/
 ic_launcher.xml
 ic_launcher_round.xml

Both files have the following xml content for the adaptive icon configuration, in which is used the <adaptive-icon> element to define the foreground, background, and monochromatic layer drawables for the icons:



<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
  <background android:drawable="@color/ic_launcher_background"/>
  <foreground android:drawable="@mipmap/ic_launcher_foreground"/>
</adaptive-icon>

For the monochrome we add the <monochrome> drawable xml element after the foreground xml element.



<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
  <background android:drawable="@color/ic_launcher_background"/>
  <foreground android:drawable="@mipmap/ic_launcher_foreground"/>
  <monochrome android:drawable="@mipmap/ic_launcher_monochrome" />
</adaptive-icon>

With that, the themed adaptive icon is configured. Now, let's check the result visually, for that, open the ic_launcher.xml file and ensure to have clicked the split option for viewing both the code and the design result.

In the upper right side of the split view, we can see the icon with a representation for dark/night mode, when we click that option, we can see the options for selecting the theme mode (night/not-night) and the dynamic color theme.

At this point, we can change the mode and the dynamic color for display the themed icon variant.

Preview in devices

After creating the launcher icon and the themed / monochrome variant, we can test the icon displayed in the device or the emulator, for that, just build and test the android app, for the device, try to use a device/emulator using android version 13 or above.

From left to right:

Displayed normal launcher icon in the home screen
Wallpaper and style system configuration, here, select themed icons
Displayed themed launcher icon in the home screen

Conclusion

With this exercise it was possible to perform a manual configuration of the launcher icon for an Android application using the adaptive icon concept.

Although it can also be done using SVG files, as recommended by Google's Android developers, in cases where you have png image files, this way can be very useful when creating these launcher icons.

Adaptive icons not only apply to launchers, they can also be applied to notification icons and shortcut icons, but the content of this article covers launcher icons.

...

Thank you for taking the time to read my article, it has been a while since I last wrote any long text in these parts. If you find something isn't quite right or have other information to add, feel free to add a respectful comment.
If you like this article, please click the clap icon or share it on social media (or both).

I Hope that you find this informative and useful and in some time you can use these steps in your android apps.

Thanks for reading, Happy coding!! 😊

...

Forem: Marlon López

Eleva tu app Android: patrones de arquitectura con Jetpack Compose

📱 ¿A qué llamamos los patrones de arquitecturas Android?

🧩 Componentes clave con Jetpack Compose

1. UI (Compose)

2. ViewModel

3. Domain / Business Logic

4. Data Layer

🏗️ Patrones de arquitectura más usados

🔹 1. MVVM (Model–View–ViewModel) ⭐⭐⭐⭐⭐

Estructura

Flujo de datos (unidireccional)

Ejemplo simple

🔹 2. MVI (Model–View–Intent) ⭐⭐⭐⭐

Conceptos clave

Flujo

Ejemplo conceptual

🔹 3. Clean Architecture con Compose ⭐⭐⭐⭐⭐

Capas

Reglas

🧠 Recomendación oficial de Google

🔁 Unidirectional Data Flow (UDF)

📌 ¿Cuál usar?

✅ Conclusión

🔹 Referencias

📐 Material 3 Adaptive: Implementing Window Size Classes in Kotlin Compose

🧐 Material 3 & Component Placement:

📚 Resources & Official Documentation

🪟 Window Size Class: Migrating from androidx.window to Material 3 Adaptive

Spanish version: Here.

🧩 1. Context: The Previous Approach (androidx.window)

🧱 2. Material 3 Adaptive: The New Path

🔄 3. The Migration Process

💡 4. Benefits of the New Approach

⚠️ 5. Considerations and Limitations

🚀 6. Conclusion

🪟 Window Size Class: migrando de androidx.window a Material 3 Adaptive

Versión en inglés: Aquí.

🧩 1. Contexto: el enfoque anterior (androidx.window)

🧱 2. Material 3 Adaptive: el nuevo camino

🔄 3. El proceso de migración

💡 4. Beneficios del nuevo enfoque

⚠️ 5. Consideraciones y limitaciones

🚀 6. Conclusión

First steps using Material3 in a WearOS Android App

About WearOS Compose Material 3 Library

Let's start the migration

Adding the Wear Compose Material 3 library

Adjusting the MaterialTheme

Part 01: Color schemes

Part 02: Typography

Part 03: Shapes

Part 04: Theme Composable

Fixing the errors in MainActivity class

¿What happened in TimeText composable?

Conclusions

Adapt Kotlin 2.0 in Android applications

About the K2 compiler

How to test K2 compiler on Android?

1. A new build directory

2. Apply new version of kotlin

3. Update the Compose compiler

Conclusions

Adaptar Kotlin 2.0 en aplicaciones Android

Acerca del compilador K2

¿Cómo probar el compilador K2 en Android?

1. Un nuevo directorio de compilación

2. Aplicar nueva versión de kotlin

3. Actualizar el compilador de Compose

Conclusiones

Using launcher and themed icons in Android studio, the manual way

Finding the images

Themed icons

Add adaptive icons in android studio

Now, check the results for the adaptive icon display

Preview in devices

Conclusion

Further reading

¿What happened in `TimeText` composable?