DEV Community: Armando Picón

The conversation around software development is regressing with AI

Armando Picón — Fri, 28 Aug 2026 06:07:08 +0000

One of the advantages — or possible disadvantages — of keeping up with the latest advances in technology is that, at some point, a revolution can become so constantly present on social media that you inevitably end up saturated with every post, video, or reel talking about it.

I remember that this was one of the reasons why I initially refused to adopt AI in my workflows.

However, time passed and, inevitably, I started using some tools for things as simple as iterating over ideas and thoughts that tend to come back to me while I study and learn new things.

That helped me lower some of the barriers and mental blocks I had imposed on myself as a result of the information overload I experienced at the beginning.

On top of that, I have also had the chance to filter the kind of content I consume much more carefully.

For now, I follow a fairly limited number of creators because I know they actually put into practice the things they talk about. So I get the feeling that the amount of "bullshit" is considerably lower compared to other, more sensationalist creators.

And it was precisely through that selection of content that I started noticing something I find quite interesting.

Are we reinventing the wheel?

Those who follow me across my different social networks know that I mainly work on mobile application development for Android and that, more recently, I have also become involved in multiplatform development thanks to Kotlin Multiplatform.

However, while exploring the use of AI tools in software development more broadly, I have started to notice a kind of regression in the conversation around our profession.

Not necessarily in the tools.

Not necessarily in the capabilities we now have available.

But in the way we talk about them.

I keep coming across more and more content — including content from engineers working directly at companies building these kinds of tools — where it feels like we are rediscovering practices that have been part of software engineering for decades.

Now we constantly talk about guardrails to prevent an agent from introducing incorrect code.

But we have been using compilers, type systems, linters, static analysis, tests, and pipelines for years precisely to establish boundaries around which changes we consider acceptable.

We can also design increasingly sophisticated workflows to improve the context a model receives, organize instructions, split work across agents, or help the model understand our codebase better.

All of that has value.

But if, after building that workflow, we still do not have a solid CI system capable of automatically verifying what the model has just produced, then we are still placing a large part of our trust in the assumption that the model understood our instructions correctly.

And when we start talking about agent verification, the mechanism underneath often looks surprisingly familiar:

the agent generates code, we run a series of checks, we observe what failed, and then we iterate again.

The automation may be new.

The speed may be new.

The agent is definitely new.

But the principle behind the verification is not necessarily new.

And I think this is where it is worth stopping for a moment.

Probabilism vs. determinism

For the average user — and probably also for developers who have not spent much time studying what is happening behind these tools — AI can look like a black box.

You give it an instruction and, almost magically, it starts generating a series of results that will probably satisfy what you are looking for.

But if we look a little deeper, we find something much more interesting.

Behind many of these tools there is an entire set of components that, working together, give us capabilities such as reasoning, memory, access to information, interaction with local or remote tools, execution of actions, and more.

At the center of much of this machinery are language models.

And behind these models are mathematical systems that, simplifying things quite a bit, estimate a probability distribution over what the next token in a sequence should be.

That detail matters.

We are working with probabilistic systems.

That means we should not assume that the exact same input will necessarily produce the exact same output.

On the other end, we have deterministic systems.

In other words, systems where, given the same conditions and the same input data, we expect to obtain the same result.

A simple arithmetic operation is probably the most obvious example.

2 + 2 will still be 4 no matter how many times we run the operation.

And this is exactly where a paradox appears that I find particularly interesting:

The more probabilistic the way we generate code becomes, the more we need deterministic mechanisms to verify whether that code is acceptable.

Back to software development

A few lines above, I mentioned that I still see and hear content creators related to software development talking about how much AI is changing our profession.

And yes, many things are changing.

The speed at which we can produce code is changing.

The number of alternatives we can explore is changing.

The way we interact with our tools is changing.

Even the role developers play in some parts of the process is changing.

But if we deliberately abstract away many of those differences, there is one fundamental change that is much easier to observe:

We can delegate code generation.

Before, that code was written primarily by a human.

Today, an increasingly large portion of it can be generated by an AI model.

Of course, someone will say that I am oversimplifying things.

And yes.

I am.

Deliberately.

Because that simplification allows us to observe something important: changing who — or what — generates the code does not eliminate the mechanisms we used to verify it.

Quite the opposite.

For decades, we have been building fairly deterministic mechanisms that help us reduce uncertainty and verify certain properties of the software we produce.

To name a few:

Compilation and type systems

Compiler checks, type systems, and null-safety help us detect type errors, invalid contracts, and nullability issues before running the program.

Static Analysis

Android Lint, Detekt, SwiftLint, or Ktlint help us detect certain known bugs, bad practices, and code smells through predefined rules.

Formatting

Ktlint, Spotless, SwiftFormat, or Dart Format help us establish consistent and verifiable formatting rules.

Unit Testing

JUnit, XCTest, Kotlin Test, or Dart Test help us verify units of behavior in isolation.

Integration Testing

It allows us to verify how different components work together: repositories, databases, network layers, services, persistence, and so on.

UI Testing

Compose UI Test, Espresso, XCUITest, or Flutter Integration Test help us verify certain behaviors through the user interface.

Code Coverage

JaCoCo, Kover, or Xcode Coverage help us measure what portion of the code was executed during our tests.

Coverage does not prove quality by itself. Having 100% coverage does not necessarily mean having good tests, much less having a bug-free product. But it is still a measurable signal that can be part of a broader verification system.

Git Hooks

Pre-commit and pre-push hooks allow us to run certain checks before our changes leave our machine.

And we could keep going.

CI pipelines.

Contract testing.

Mutation testing.

Property-based testing.

Dependency checks.

Security checks.

Reproducible builds.

There are many more.

And some of them will probably make much more sense than others depending on the product, platform, or team we are working with.

The important thing is not to use all of them.

The important thing is to understand the principle behind them.

None of these practices guarantees, on its own, that our software is correct.

That absolute guarantee has practically never existed.

What they do is something far more useful:

They systematically reduce our uncertainty.

AI does not eliminate these practices

It makes them more important.

And this is precisely where I feel part of the current conversation is looking too much in one direction.

We can spend hours improving our prompts.

We can discuss how to build better context files.

We can experiment with different ways to organize instructions.

We can create agents, sub-agents, tools, MCPs, and increasingly complex workflows.

In fact, we should learn how to work with all of that properly.

But if our strategy ultimately depends exclusively on the model "understanding" what we want and producing correct code, then we are still playing with prompts.

We are still trying to increase the probability of getting a good answer.

And that is not necessarily bad.

The problem starts when we confuse improving that probability with verifying that the result is correct.

They are different problems.

Probabilistic generation, deterministic verification

I think we can use a fairly simple framework here to think about how to incorporate AI into our development processes.

It is not trying to invent anything new.

In fact, that is exactly the point.

1. Generate

We allow the model to do the things these tools can be extremely useful for:

exploring alternatives, writing code, performing refactors, proposing implementations, navigating our codebase, or even operating directly on our repository.

At this stage, we accept the probabilistic nature of the process.

We are not trying to eliminate it.

The model proposes.

2. Constrain

Then we make the generated code face contracts defined by us.

The compiler.

The type system.

Null-safety.

Formatting.

Linting.

Static analysis.

Architectural rules.

API contracts.

Whenever a constraint can be turned into an executable rule, we gain the ability to stop depending on the model "remembering" it.

The system simply enforces it.

3. Verify

Then we verify behavior.

Unit tests.

Integration tests.

UI tests.

Contract tests.

Property-based tests.

Whatever mechanisms make sense for the problem we are solving.

At this point, we stop asking whether the code "looks correct."

We start asking whether it satisfies concrete properties we can verify.

4. Decide

Finally, we establish the conditions under which we accept that change.

Build.

Tests.

Quality gates.

Security checks.

Code review.

Human approval when appropriate.

Only after going through those verifications do we allow the code to move forward.

Generate.

Constrain.

Verify.

Decide.

In reality, we are not doing something radically different from what we were already doing.

We are changing the entity that generates part of the code and dramatically increasing the speed at which it can do so.

And precisely because of that, we need to strengthen the rest of the system.

So what is a guardrail, really?

This is where the conversation becomes particularly interesting.

A guardrail does not have to be a particularly clever instruction inside a prompt.

It can simply be a rule the model cannot ignore.

The model can forget that we have a particular formatting convention.

Ktlint does not.

The model can incorrectly infer a type contract.

The compiler does not negotiate with it.

The model can convince us, with a perfectly reasonable explanation, that its implementation works.

A failing test has a very different opinion.

Of course, we can now use agents to execute all of these mechanisms, interpret the results, and even automatically fix whatever failed.

That does represent a new and extremely interesting capability.

But we are building that capability on top of principles we already knew.

We should not confuse a new layer of automation with the emergence of a new discipline.

It is still software engineering.

Stop just playing with prompts

I have nothing against prompts.

Nor against context engineering, agents, or increasingly sophisticated workflows.

Quite the opposite.

They are tools I am progressively incorporating into my own work, and I find them extremely interesting.

But I think there is an important difference between improving the probability that a model will produce correct code and building a system capable of rejecting it when it does not.

The first strategy tries to get a better answer.

The second reduces our dependence on the answer being correct in the first place.

And if I can choose where to place my trust, I would rather place it in what I can verify.

Maybe that is one of the most interesting opportunities AI is giving us.

If we increasingly need to spend less time manually writing every single line of code, then we can invest part of that time in building better contracts, better tests, better pipelines, and better verification systems.

Not to stop AI from working.

But precisely so that we can trust more of what it produces.

AI is dramatically changing who can generate code, how much code we can generate, and how quickly we can do it.

But it has not eliminated the engineering we need to decide which code deserves to reach production.

And maybe part of the conversation around software development is regressing precisely because we are too fascinated by this new way of generating code and are forgetting everything we had already learned about how to verify it.

The more probabilistic software generation becomes, the more deterministic the process that decides whether we accept the result should be.

La conversación sobre desarrollo de software está involucionando con la IA

Armando Picón — Fri, 28 Aug 2026 05:53:33 +0000

Una de las ventajas - o posibles desventajas - de estar al tanto de los últimos avances de la tecnología es que, llegado cierto punto, alguna revolución puede estar presente de forma tan continua en las redes sociales que inevitablemente uno termina saturándose con cada post, video o reel que habla del tema.

Recuerdo que esa fue una de las razones por las que inicialmente me negué a adoptar la IA en mis flujos de trabajo.

Sin embargo, el tiempo pasó e inevitablemente comencé a emplear algunas herramientas para cosas tan sencillas como iterar sobre ideas y pensamientos que suelen ser recurrentes en mí mientras voy estudiando y aprendiendo cosas nuevas.

De esta forma, empecé a bajar las barreras y bloqueos mentales que yo mismo me había impuesto producto de la saturación de información que había experimentado en un inicio.

Adicionalmente, he tenido la oportunidad de filtrar bastante la clase de contenido que consumo.

Por el momento sigo a un número acotado de creadores porque sé que realmente ponen en práctica las cosas que divulgan. Entonces, tengo la sensación de que el nivel de "chamullo" es bastante menor en comparación con otros creadores más sensacionalistas.

Y justamente a partir de esa selección de contenido comencé a notar algo que me resulta bastante curioso.

¿Estamos reinventando la rueda?

Para quienes me siguen en mis diferentes redes sociales, saben que me dedico principalmente al desarrollo de aplicaciones móviles para Android y que, recientemente, también me he involucrado en el desarrollo multiplataforma gracias a Kotlin Multiplatform.

Sin embargo, explorando el uso de herramientas de IA en el desarrollo de software en general, he comenzado a observar una especie de involución en la conversación alrededor de nuestra profesión.

No necesariamente en las herramientas.

No necesariamente en las capacidades que tenemos disponibles.

Sino en la manera en que hablamos sobre ellas.

Cada vez encuentro más contenido - incluso proveniente de ingenieros que trabajan directamente en empresas que están construyendo este tipo de herramientas - donde pareciera que estamos redescubriendo prácticas que llevan décadas formando parte de la ingeniería de software.

Ahora hablamos constantemente de guardrails para evitar que un agente introduzca código incorrecto.

Pero llevamos años utilizando compiladores, sistemas de tipos, linters, static analysis, tests y pipelines precisamente para establecer límites sobre qué cambios consideramos aceptables.

También podemos diseñar workflows cada vez más sofisticados para mejorar el contexto que recibe un modelo, organizar instrucciones, dividir trabajo entre agentes o conseguir que el modelo entienda mejor nuestro codebase.

Todo eso tiene valor.

Pero si después de construir ese workflow no tenemos un CI sólido capaz de verificar automáticamente lo que acaba de producir, seguimos depositando gran parte de nuestra confianza en que el modelo haya entendido correctamente nuestras instrucciones.

Y cuando comenzamos a hablar de agent verification, muchas veces el mecanismo que encontramos debajo resulta sorprendentemente familiar:

el agente genera código, ejecutamos una serie de checks, observamos qué falló y volvemos a iterar.

La automatización puede ser nueva.

La velocidad puede ser nueva.

El agente definitivamente es nuevo.

Pero el principio detrás de la verificación no necesariamente lo es.

Y creo que aquí vale la pena detenernos un momento.

Probabilismo vs. determinismo

Para el usuario común - y probablemente también para desarrolladores que no se han detenido demasiado a estudiar qué ocurre detrás de estas herramientas - la IA puede parecer una caja negra.

Le entregas una instrucción y mágicamente comienza a generar una serie de resultados que probablemente satisfagan lo que estás buscando.

Pero si observamos un poco más abajo encontramos algo bastante más interesante.

Detrás de muchas de estas herramientas existe todo un conjunto de componentes que, funcionando en conjunto, nos permiten contar con capacidades de razonamiento, memoria, acceso a información, interacción con herramientas locales o remotas, ejecución de acciones, entre otras cosas.

En el centro de buena parte de este andamiaje se encuentran los modelos de lenguaje.

Y detrás de estos modelos existen sistemas matemáticos que, simplificando bastante, van estimando una distribución de probabilidades sobre cuál debería ser el siguiente token dentro de una secuencia.

Ese detalle importa.

Estamos trabajando con sistemas probabilísticos.

Eso significa que no deberíamos asumir que, ante una misma entrada, obtendremos necesariamente exactamente la misma salida.

En el otro extremo tenemos los sistemas determinísticos.

Es decir, aquellos en los que, dadas las mismas condiciones y los mismos datos de entrada, esperamos obtener el mismo resultado.

Una operación aritmética simple probablemente sea el ejemplo más evidente.

2 + 2 seguirá siendo 4 independientemente de cuántas veces ejecutemos la operación.

Y es justamente aquí donde aparece una paradoja que me parece particularmente interesante:

Cuanto más probabilística se vuelve la forma en que generamos código, más necesitamos mecanismos determinísticos para verificar si ese código es aceptable.

Volviendo al desarrollo de software

Mencionaba líneas arriba que sigo viendo y escuchando a creadores de contenido relacionados con el desarrollo de software hablar de cuánto está cambiando la incorporación de la IA en nuestra profesión.

Y sí, están cambiando muchas cosas.

Está cambiando la velocidad con la que podemos producir código.

Está cambiando la cantidad de alternativas que podemos explorar.

Está cambiando la forma en la que interactuamos con nuestras herramientas.

Está cambiando incluso el rol que desempeña el desarrollador dentro de algunas partes del proceso.

Pero si abstraemos deliberadamente muchas de esas diferencias, hay un cambio fundamental mucho más sencillo de observar:

Podemos delegar la generación del código.

Antes ese código era escrito principalmente por un ser humano.

Hoy una proporción cada vez mayor puede ser generada por un modelo de IA.

Claro, no faltará quien diga que estoy sobresimplificando las cosas.

Y efectivamente lo estoy haciendo.

Deliberadamente.

Porque esa simplificación permite observar algo importante: cambiar quién - o qué - genera el código no elimina los mecanismos que utilizábamos para verificarlo.

Todo lo contrario.

Durante décadas hemos construido mecanismos bastante determinísticos que nos permiten reducir incertidumbre y verificar determinadas propiedades del software que producimos.

Por mencionar algunos:

Compilación y sistemas de tipos

Compiler checks, type systems y null-safety nos permiten detectar errores de tipos, contratos inválidos y problemas de nullability antes de ejecutar el programa.

Static Analysis

Android Lint, Detekt, SwiftLint o Ktlint nos permiten detectar determinados bugs conocidos, malas prácticas y code smells mediante reglas previamente definidas.

Formatting

Ktlint, Spotless, SwiftFormat o Dart Format nos permiten establecer reglas de formato consistentes y verificables.

Unit Testing

JUnit, XCTest, Kotlin Test o Dart Test nos permiten comprobar unidades de comportamiento de manera aislada.

Integration Testing

Nos permite verificar cómo distintos componentes colaboran entre sí: repositories, bases de datos, network layers, servicios, persistencia, etc.

UI Testing

Compose UI Test, Espresso, XCUITest o Flutter Integration Test nos permiten verificar determinados comportamientos desde la interfaz.

Code Coverage

JaCoCo, Kover o Xcode Coverage nos permiten medir qué porción del código fue ejecutada durante nuestras pruebas.

Coverage no demuestra calidad por sí solo. Tener 100 % de coverage no significa necesariamente contar con buenos tests ni mucho menos con un producto libre de errores. Pero sí constituye una señal medible que puede formar parte de un sistema de verificación mayor.

Git Hooks

Pre-commit y pre-push hooks nos permiten ejecutar determinadas verificaciones antes de que nuestros cambios abandonen nuestra máquina.

Y podríamos seguir.

CI pipelines.

Contract testing.

Mutation testing.

Property-based testing.

Dependency checks.

Security checks.

Reproducible builds.

Son muchas más.

Y probablemente algunas tengan mucho más sentido que otras dependiendo del producto, plataforma o equipo en el que estemos trabajando.

Lo importante no es utilizar todas.

Lo importante es entender el principio que existe detrás.

Ninguna de estas prácticas garantiza por sí sola que nuestro software sea correcto.

Esa garantía absoluta prácticamente nunca ha existido.

Lo que hacen es algo mucho más útil:

Reducen sistemáticamente nuestra incertidumbre.

La IA no elimina estas prácticas

Las vuelve más importantes.

Y es precisamente aquí donde tengo la sensación de que parte de la conversación actual está mirando demasiado hacia un solo lado.

Podemos dedicar horas a mejorar nuestros prompts.

Podemos discutir cómo construir mejores archivos de contexto.

Podemos experimentar con diferentes maneras de organizar instrucciones.

Podemos crear agentes, subagentes, herramientas, MCPs y workflows cada vez más complejos.

De hecho, deberíamos aprender a trabajar correctamente con todo eso.

Pero si nuestra estrategia termina dependiendo exclusivamente de que el modelo "entienda bien" lo que queremos y produzca código correcto, seguimos jugando a prompts.

Seguimos intentando aumentar la probabilidad de obtener una buena respuesta.

Y eso no es necesariamente malo.

El problema aparece cuando confundimos mejorar esa probabilidad con verificar que el resultado sea correcto.

Son problemas distintos.

Generación probabilística, verificación determinística

Creo que aquí podemos utilizar un marco bastante sencillo para pensar cómo incorporar IA dentro de nuestros procesos de desarrollo.

No pretende inventar nada nuevo.

De hecho, justamente ese es el punto.

1. Generar

Permitimos que el modelo haga aquello en lo que estas herramientas pueden resultar extremadamente útiles:

explorar alternativas, escribir código, realizar refactors, proponer implementaciones, navegar nuestro codebase o incluso operar directamente sobre nuestro repositorio.

En esta parte aceptamos el probabilismo.

No intentamos eliminarlo.

El modelo propone.

2. Restringir

Luego hacemos que el código generado se enfrente a contratos definidos por nosotros.

El compilador.

El sistema de tipos.

Null-safety.

Formatting.

Linting.

Static analysis.

Reglas arquitectónicas.

Contratos de APIs.

Siempre que una restricción pueda convertirse en una regla ejecutable, tenemos la posibilidad de dejar de depender de que el modelo la "recuerde".

El sistema simplemente la hace cumplir.

3. Verificar

Después verificamos el comportamiento.

Unit tests.

Integration tests.

UI tests.

Contract tests.

Property-based tests.

Los mecanismos que correspondan al problema que estamos resolviendo.

En este punto dejamos de preguntarnos si el código "parece correcto".

Comenzamos a preguntar si cumple propiedades concretas que podemos comprobar.

4. Decidir

Finalmente establecemos las condiciones bajo las cuales aceptamos ese cambio.

Build.

Tests.

Quality gates.

Security checks.

Revisión de código.

Aprobación humana cuando corresponda.

Solo después de atravesar esas verificaciones permitimos que el código avance.

Generar.

Restringir.

Verificar.

Decidir.

En realidad, no estamos haciendo algo radicalmente distinto a lo que ya hacíamos.

Estamos cambiando la entidad que genera parte del código y aumentando dramáticamente la velocidad con la que puede hacerlo.

Y precisamente por eso necesitamos reforzar el resto del sistema.

Entonces, ¿qué es realmente un guardrail?

Aquí es donde la conversación se vuelve particularmente interesante.

Un guardrail no tiene por qué ser una instrucción particularmente ingeniosa dentro de un prompt.

Puede ser simplemente una regla que el modelo no puede ignorar.

El modelo puede olvidar que tenemos una determinada convención de formato.

Ktlint no.

El modelo puede inferir incorrectamente un contrato de tipos.

El compilador no negocia con él.

El modelo puede convencernos con una explicación perfectamente razonable de que su implementación funciona.

Un test que falla tiene una opinión bastante diferente.

Por supuesto que ahora podemos utilizar agentes para ejecutar todos estos mecanismos, interpretar los resultados e incluso corregir automáticamente aquello que falló.

Eso sí representa una capacidad nueva y extremadamente interesante.

Pero estamos construyendo esa capacidad sobre principios que ya conocíamos.

No deberíamos confundir una nueva capa de automatización con la aparición de una nueva disciplina.

Sigue siendo ingeniería de software.

Dejar de jugar solamente a prompts

No tengo nada contra los prompts.

Tampoco contra el context engineering, los agentes o los workflows cada vez más sofisticados.

Todo lo contrario.

Son herramientas que estoy incorporando progresivamente en mi propio trabajo y que me parecen tremendamente interesantes.

Pero creo que existe una diferencia importante entre mejorar las probabilidades de que un modelo produzca código correcto y construir un sistema capaz de rechazarlo cuando no lo es.

La primera estrategia intenta conseguir una mejor respuesta.

La segunda reduce nuestra dependencia de que la respuesta sea correcta desde el principio.

Y si puedo elegir dónde depositar mi confianza, prefiero hacerlo en aquello que puedo verificar.

Quizá ahí está una de las oportunidades más interesantes que nos está dando la IA.

Si cada vez necesitamos invertir menos tiempo en escribir manualmente cada línea de código, podemos invertir una parte de ese tiempo en construir mejores contratos, mejores tests, mejores pipelines y mejores sistemas de verificación.

No para impedir que la IA trabaje.

Sino precisamente para poder confiar más en aquello que produce.

La IA está cambiando dramáticamente quién puede generar código, cuánto código podemos generar y a qué velocidad podemos hacerlo.

Pero no eliminó la ingeniería que necesitamos para decidir qué código merece llegar a producción.

Y quizá parte de la conversación alrededor del desarrollo de software está involucionando precisamente porque estamos demasiado fascinados con la nueva forma de generar código y estamos olvidando todo lo que ya habíamos aprendido sobre cómo verificarlo.

Cuanto más probabilística se vuelve la generación de software, más determinístico debería ser el proceso que decide si aceptamos el resultado.

🔐 Beyond SSL Pinning: mTLS, Backend Security & Real-World Mobile Architecture (Part 3)

Armando Picón — Mon, 04 May 2026 21:44:39 +0000

In the previous parts, we explored SSL pinning across Android and iOS, including both certificate and public key approaches.

But here’s the uncomfortable truth:

Even perfectly implemented pinning is not enough.

In this final part, we move beyond the client and look at what truly defines a secure mobile architecture:

Mutual TLS (mTLS)
Backend access control
Defense in depth
When mobile security actually fails in production

🧠 Why Pinning Is Not the Endgame

Pinning protects the channel, not the system.

That means:

✔ Prevents MITM attacks
❌ Does NOT prevent unauthorized API access
❌ Does NOT validate who is calling your backend

If your API is publicly exposed, anyone can still:

Use Postman
Reverse engineer your app
Replay requests

So the real question becomes:

How do we ensure that only trusted clients can talk to our backend?

🔴 Enter mTLS (Mutual TLS)

Unlike standard TLS:

Server presents a certificate ✅
Client verifies server

With mTLS:

Server presents certificate ✅
Client presents certificate ✅
Both sides verify each other

🔐 mTLS Flow

Client → Server: Hello
Server → Client: Certificate
Client → Server: Certificate (client identity)
Server → Client: Accept / Reject

✔ What mTLS Solves

Strong client authentication
Prevents unauthorized clients (e.g. Postman, curl)
Removes reliance on API keys alone
Can partially replace VPN in some architectures

⚠️ Why mTLS Is Rare in Mobile

Because it’s operationally expensive:

Securely storing client certificates on device is hard
Certificates must be rotated
Risk of extraction on rooted/jailbroken devices
Complex provisioning process

👉 Most teams underestimate this complexity

🧩 Where mTLS Actually Makes Sense

Use it when:

Enterprise apps (controlled devices)
MDM-managed environments
Internal tools
High-security B2B systems

Avoid it for:

Public consumer apps
Apps distributed via App Store / Play Store
Large-scale unknown user bases

🧠 Real-World Alternative: Token-Based Security

Instead of relying on transport-level identity:

👉 Use application-level identity

App → HTTPS → API Gateway → Auth (JWT / OAuth) → Services

✔ What This Solves

User authentication
Fine-grained authorization
Revocation
Scalability

🧱 Defense in Depth (What Actually Works)

A realistic production setup looks like this:

Mobile App
   ↓
TLS (HTTPS)
   ↓
(Optional) Certificate Pinning
   ↓
API Gateway
   ↓
Auth Layer (JWT / OAuth)
   ↓
Rate Limiting / WAF
   ↓
Microservices

🔍 Common Mistakes in Mobile Security

Let’s be blunt:

❌ “We added SSL pinning, we’re secure”

No — you protected only the transport layer.

❌ Hardcoding API keys in the app

These will be extracted. Always.

❌ Trusting the client

The client is always hostile. Assume compromise.

❌ Ignoring backend validation

Security belongs to the backend, not the app.

🧠 When Mobile Security Fails

Not because of TLS.

But because:

Poor authentication design
Lack of rate limiting
Missing monitoring
Weak backend validation

🧭 Practical Recommendations

If you’re building a modern mobile app:

Start with HTTPS (mandatory)
Add proper authentication (JWT / OAuth)
Introduce API Gateway controls
Add rate limiting & monitoring
Consider pinning as an extra layer
Evaluate mTLS only if you truly need it

🧠 Final Takeaway

Security is not a feature — it’s a system.

Pinning protects the connection.
mTLS protects the client identity.
Backend security protects your business.

If you ignore the last one, the first two won’t save you.

👋 Closing

At this point, you’ve seen:

How to implement pinning on Android
How to implement it on iOS
And where it actually fits in a real-world architecture

Use it wisely.

And more importantly — design beyond it.

🔐 SSL Pinning in Mobile Apps: Android & iOS (Practical Guide + Trade-offs) - Part 2

Armando Picón — Mon, 04 May 2026 21:25:47 +0000

Unlike Android, where libraries like OkHttp abstract much of the complexity, iOS takes a more low-level approach to networking and security.

This means one thing:

You have more control — but also more responsibility.

In this second part, we’ll explore how SSL pinning is implemented in iOS using two different strategies:

Certificate Pinning (.cer)
Public Key Pinning (recommended for production)

Both approaches achieve the same goal — trusting only your backend — but they differ significantly in terms of stability, maintainability, and real-world viability.

We’ll also take a step back and look at the bigger picture:

When pinning makes sense
When it becomes a liability
And how it fits into a broader mobile security strategy

Let’s dive in.

🍎 iOS Implementation

iOS is more low-level. You’ll work with:

URLSession
URLSessionDelegate
Security.framework

There are two approaches:

🟢 Approach 1: Certificate Pinning with .cer

This is typically the first approach developers encounter when implementing pinning on iOS.

🔧 Steps

Export your backend certificate as .cer
Add it to your Xcode project
Compare it at runtime

🧪 Example

class PinningDelegate: NSObject, URLSessionDelegate {

    func urlSession(_ session: URLSession,
                    didReceive challenge: URLAuthenticationChallenge,
                    completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
              let serverTrust = challenge.protectionSpace.serverTrust,
              let serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else {
            completionHandler(.cancelAuthenticationChallenge, nil)
            return
        }

        let serverCertData = SecCertificateCopyData(serverCertificate) as Data

        guard let localCertPath = Bundle.main.path(forResource: "server", ofType: "cer"),
              let localCertData = try? Data(contentsOf: URL(fileURLWithPath: localCertPath)) else {
            completionHandler(.cancelAuthenticationChallenge, nil)
            return
        }

        if serverCertData == localCertData {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

⚠️ Downside (critical)

This approach is:

💣 Fragile

Certificates expire
Renewal changes .cer
Your app breaks

👉 You must release a new version of the app

🟡 Approach 2: Public Key Pinning (Recommended)

Instead of comparing full certificates:

👉 Compare public keys

✔️ Advantages

Survives certificate renewal
More stable in production
Equivalent to Android approach

🧪 Conceptual Example

let serverPublicKey = SecCertificateCopyKey(serverCertificate)
let localPublicKey = SecCertificateCopyKey(localCertificate)

// Compare keys or their hashes
// ⚠️ Apple APIs here are verbose and require careful handling.

🧭 Better Option: Use a Library

Instead of manual implementation, use:

Alamofire (widely used networking library)

Example

let evaluators: [String: ServerTrustEvaluating] = [
    "api.yourservice.com": PinnedCertificatesTrustEvaluator()
]

let manager = ServerTrustManager(evaluators: evaluators)

let session = Session(serverTrustManager: manager)

🔍 What SSL Pinning DOES NOT Do

Let’s be clear:

Feature	Covered by Pinning
Encrypt traffic	✔ (via TLS)
Prevent MITM	✔
Authenticate user	❌
Protect API access	❌
Replace VPN	❌

👉 You still need:

JWT / OAuth
API Gateway
Rate limiting
Backend security

⚠️ Real-World Trade-offs

Before adding pinning, ask yourself:

❗ Operational cost

Certificate rotation becomes risky
You need fallback pins
You need monitoring

❗ Release dependency

A backend change can break clients instantly

❗ Debugging complexity

Harder to inspect traffic (Charles Proxy, etc.)

🧠 When Should You Use It?

Use pinning if:

You build fintech / healthcare apps
You operate in hostile network environments
You have strong DevOps practices

Avoid (or delay) if:

You’re building a typical consumer app
You don’t control backend infrastructure
Your team lacks experience with cert rotation

🧩 Recommended Architecture (No VPN)

Mobile App
   ↓
HTTPS (TLS)
   ↓
API Gateway
   ↓
Authentication (JWT / OAuth)
   ↓
Microservices

Optional hardening:

Certificate Pinning 🔐
WAF 🛡️
Rate limiting 🚦

🧠 Final Thoughts

“SSL pinning” is often mentioned casually, but:

👉 It’s not a silver bullet
👉 It’s not a replacement for authentication
👉 It’s not trivial to maintain

Used correctly, it adds a strong extra layer of defense.

Used blindly, it becomes a production risk.

👋 Closing

If you’re working with Kotlin Multiplatform or shared logic, keep in mind:

Pinning is platform-specific
You’ll need separate implementations for Android and iOS

🔐 SSL Pinning in Mobile Apps: Android & iOS (Practical Guide + Trade-offs) - Part 1

Armando Picón — Mon, 04 May 2026 21:20:13 +0000

When building mobile apps that consume APIs over the internet, HTTPS is mandatory—but sometimes it’s not enough.

If your app handles sensitive data (finance, health, enterprise), you might want to go one step further:

👉 Certificate Pinning (aka “SSL pinning”)

This article explains:

What SSL pinning actually is (and what it isn’t)
How to implement it in Android

In a second part, these topics will be covered:

How to implement it in iOS (both .cer and Public Key approaches)
The real trade-offs nobody tells you

🧠 What is SSL Pinning (really)?

Despite the name, modern apps use TLS, not SSL.

👉 The correct term is:

Certificate Pinning
or TLS Pinning

But “SSL pinning” is still widely used.

🔐 Default HTTPS behavior

By default, your app trusts any valid certificate signed by trusted Certificate Authorities (CAs).

That means:
App → HTTPS → Server (valid cert) → OK

🚨 The problem

If an attacker installs a malicious certificate (e.g. on public WiFi), they could:

Intercept traffic
Decrypt requests
Act as a proxy (MITM attack)

🔐 What Pinning Changes

Instead of trusting all valid certs:

👉 Your app trusts only a specific certificate or public key

If it doesn’t match → ❌ connection rejected

In Android, SSL pinning can be implemented either at the HTTP client level (e.g., OkHttp) or at the platform level using Network Security Config.

📱 Android Implementation (OkHttp)

Android makes this relatively straightforward thanks to OkHttp.

✔️ Public Key Pinning (recommended)

val certificatePinner = CertificatePinner.Builder()
    .add("api.yourservice.com", "sha256/AAAAAAAAAAAAAAAAAAAA...")
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

🧪 How to get the SHA-256 hash

You can extract it using OpenSSL:

openssl s_client -connect api.yourservice.com:443 -servername api.yourservice.com \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64

🧭 Alternative on Android: Network Security Config (Platform-Level Pinning)

So far, we’ve implemented SSL pinning using OkHttp, which gives us fine-grained control at the HTTP client level.

However, Android also provides a platform-level approach: Network Security Config.

Instead of configuring pinning in code, you can declare it in XML and apply it globally to your app.

🔧 Example Configuration

Create a file under:

res/xml/network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.yourservice.com</domain>

        <pin-set expiration="2026-05-09">
            <pin digest="SHA-256">YOUR_BASE64_SHA256_PIN</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Then reference it in your AndroidManifest.xml:

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ... >

🧠 How It Works

This configuration tells Android:

Only trust connections to this domain if the server’s certificate matches the pinned public key.

Unlike OkHttp’s CertificatePinner, this operates at the platform level, not just within a specific HTTP client.

⚖️ OkHttp vs Network Security Config

Approach	Scope	Control	Flexibility
OkHttp CertificatePinner	Per client	High	High
Network Security Config	App-wide	Medium	Lower

⚠️ Trade-offs

Still subject to certificate rotation issues
Less dynamic than code-based approaches
Android-only (no equivalent in iOS)

🧭 When Should You Use It?

Use Network Security Config when:

You want a centralized security policy
Your app uses multiple networking libraries
You prefer a declarative approach

Use OkHttp pinning when:

You need fine-grained control
You want to scope pinning to specific requests or clients

🧠 Key Insight

Both approaches ultimately solve the same problem:

Restricting trust to a known certificate or public key.

The difference lies in where the responsibility lives:

In your networking layer (OkHttp)
Or in the Android platform configuration

Wrapping Up (Part 1)

At this point, we’ve covered what SSL pinning really is, what problems it solves (and what it doesn’t), and how to implement it on Android using a modern, production-ready approach.

If there’s one takeaway from this first part, it’s this:

Pinning is not about replacing your security model — it’s about strengthening the transport layer.

On Android, the ecosystem makes it relatively straightforward to adopt public key pinning with tools like OkHttp. However, the real challenge isn’t implementation — it’s operational discipline:

Handling certificate rotation
Avoiding hard failures in production
Understanding when pinning actually adds value

Before moving forward, ask yourself:

Do I really need pinning, or am I trying to compensate for missing backend security?

In the next part, we’ll move to iOS — where things are a bit more low-level, and where the trade-offs become even more evident.

Gemma 4 E2B on Mobile: Android vs iOS Reality (1)

Armando Picón — Mon, 04 May 2026 19:53:30 +0000

I'm still looking for a new job. In the meantime, I'm running experiments with the new Gemma 4 E2B model...

I just wanted to share a few notes on this...

The model uses the .litertlm extension, as it now relies on LiteRT-LM, the new framework to run these models in edge devices. It's an evolution of TensorFlow Lite.
On Android, there is a Kotlin-based API to run these models on Android devices optimized for coroutines.
On iOS, there is currently no native Swift API to run it, so you have to rely on the C++ API.

So, one of my experiments consists of evaluating whether it's possible to run this model in a device without a dedicated IA chipset.

[iOS] CocoaPods cheatsheet

Armando Picón — Fri, 06 Feb 2026 02:37:51 +0000

This post is just a reminder about how to use CocoaPods.

First things first...

What is CocoaPods

CocoaPods is a dependency manager for iOS projects.
It integrates third-party libraries into Xcode projects using a Podfile.

Install ruby

brew install ruby

Install CocoaPods

sudo gem install cocoapods

Verify the installation using

pod --version

Initialize CocoaPods in a project

First, go to the project folder (where .xcodeproj is located) and run

pod init

A minimal example of configuration

platform :ios, '15.0'

target 'YourAppTarget' do
  use_frameworks!

  pod 'Alamofire'
  pod 'SnapKit'
end

Key things:
• platform → minimum iOS version
• target → must match your app target name exactly
• use_frameworks! → required for many Swift pods

Install the dependency

pod install

This creates:
• Pods/ folder
• YourProject.xcworkspace

🚨 From now on, open the .xcworkspace, not the .xcodeproj.

Using a pod in code

import Alamofire

AF.request("https://example.com").response { response in
  print(response)
}

If it compiles → done.

Common commands

pod install     # install dependencies
pod update      # update dependencies
pod repo update # update specs repo
pod deintegrate # remove CocoaPods completely
pod search NAME # search pods

Typical problems & fixes

❌ “No such module”
• You opened .xcodeproj instead of .xcworkspace
• Target name mismatch in Podfile

❌ Build settings conflicts

pod deintegrate
pod install

❌ Slow installs

pod install --repo-update

Some additional notes

CocoaPods is mostly for legacy projects
For libraries that don't support SPM (Swift Package Manager)
Consider using only Swift Package Manager

Android - Scalable dependency management with version catalogs

Armando Picón — Wed, 13 Dec 2023 21:56:58 +0000

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 is 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 to a single alias, making this catalogs acts as a source of truth and it can be referenced in every gradle file.

To enable this option you need to follow these steps:

Create a new file into the gradle folder at the project level with the name libs.versions.toml.
Declare the dependencies into that file.
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 it has been declared in the first example of this article, in the gradle file. In order to make the core-ktx dependency available into 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 added a new declaration in the TOML file you have to sync the project to make it available for the modules.

Also, using Version catalogs let 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, you can 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

Android - Desmitificando Clean Architecture

Armando Picón — Thu, 30 Dec 2021 17:22:28 +0000

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 (Domain) 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

Kotlin - Scope Functions (let, with, run, apply & also)

Armando Picón — Mon, 22 Feb 2021 00:36:49 +0000

Empecemos viendo este código:

  name?.let{
    //...
  }

Estoy seguro que en algún momento lo has visto y sabes que es una forma de validar que name no sea nulo antes de emplear el valor dentro del bloque de código dentro de la función let. Pero ¿realmente sabes las implicancias del uso de dicha función? Si la respuesta es no, pues esta publicación es para ti.

Definiendo las scope functions

Según la documentación oficial son funciones cuyo único propósito es "ejecutar un bloque de código dentro del contexto de un objeto". Creo que la explicación es algo sencilla, básicamente es una forma de organizar nuestro código y hacerlo mejor leíble.

¿Qué scope functions trae Kotlin?

Básicamente tenemos 5 scope functions: let, with, run, apply y also; adicionalmente hay 2 funciones extras takeIf y takeUnless que nos permitirán adicionar algunas validaciones de estado en medio de una cadena de invocación (o en tras palabras cuando concatenas varias scope functions) y que suelen emplearse junto con las 5 anteriores.

Como la documentación lo señala hay dos elementos que distinguen a una scope function de otra:

la forma en que se referencia al objeto de contexto
el valor de retorno

Por la forma en que se referencia al objeto de contexto

La razón por la que tenemos un it o un this es para simplificar o acortar el nombre de la variable original y, básicamente, te dirá si el objeto va a recibir la lambda (para el caso del this) o si el objeto va a pasarse como argumento de la lambda (para el caso de it).

Entonces, ¿en qué casos el objeto de contexto va a recibir la lambda? run, with y apply y ¿en qué casos el objeto de contexto se pasará como argumento? let y also.

Por el valor de retorno

Para esta situación tendremos el retorno del mismo objeto de contexto para el caso de apply y also o el valor de resultado de la lambda en el caso de let, run y with.

¿Qué función elegir?

Teniendo estas dos distinciones en mente, la documentación oficial detalla cada una de las funciones y los posibles escenarios de uso. De esa misma documentación saqué este cuadro que ayuda mucho a resumir lo dicho anteriormente:

Función	Referencia de objeto	Valor de retorno	¿Es una extension function?
`let`	`it`	Resultado de la lambda	Sí
`run`	`this`	Resultado de la lambda	Sí
`run`	-	Resultado de la lambda	No, cuando se llama sin el objeto de contexto
`with`	`this`	Resultado de la lambda	No, porque toma el objeto de contexto como argumento
`apply`	`this`	Objeto de contexto	Sí
`also`	`it`	Objeto de contexto	Sí

También la documentación brinda una pequeña guía de referencia:

Ejecución de una lambda en objetos non-null: let
Introducir una expresión como una variable en un ámbito local: let
Configuración de un objeto: apply
Configuración de un objeto y computación del resultado: run
Ejecutar sentencias donde una expresión es requerida: run a secas sin objeto de contexto ni como función extendida
Efectos adicionales: also
Agrupar llamadas a funciones en un objeto: with

takeIf y takeUnless

Estas dos funciones que vienen en la biblioteca estandar de Kotlin, no son consideradas scope functions; sin embargo, se emplean junto con ellas y sirven para realizar algunas validaciones.

La documentación oficial tiene algunos buenos ejemplos de cómo emplearlas.

Conclusión

Me resultan super interesantes las scope functions y este artículo tiene por intención hacer un breve resumen de en qué consisten y cuando emplearlas. Es importante practicar su uso para acostumbrarse a sus diferencias y casos de uso, dado que por lo similares que son resultado fácil confundirlas y equivocar su uso.

¿Qué nos dejó el 2020 y que nos traerá el 2021?

Armando Picón — Fri, 01 Jan 2021 03:36:42 +0000

Hola amigos y amigas de Codalot Podcast, que año para complicado el que nos tocó pasar, cierto? y quería empezar expresando mis condolencias a todos los que sufrieron de la pérdida de algún ser querido o de alguna persona cercana producto de esta pandemia.

Si bien es cierto que diversos sectores económicos sufrieron de un gran impacto producto de la crisis que se generó por causa de las medidas que tomó cada gobierno, producto de ello se perdieron muchos puestos de trabajo; sin embargo, dentro de las ocupaciones que no sufrieron tanto durante esta pandemia estuvieron los programadores y los desarrolladores de software.

Si fuiste uno de estos, puedes sentirte privilegiado y a su vez puedes sentirte feliz de haber tomado la decisión de dedicarte a esto.

El año del trabajo remoto

Este año que termina ha sido un año lleno de desafíos y de cambios significativos para cada uno de nosotros. Muy aparte de las cuarentenas y demás restricciones dictaminadas por cada gobierno, fue el año del trabajo remoto o home office.
Un problema latente con el trabajo remoto en este tiempo es que, sumado al hecho de que muchos de nosotros no podíamos salir, puede llegar a ser tedioso y muy agotador. Por eso se torna importante contar con rutinas, generar hábitos, aprender a desconectarse y aprender a ser creativos para no llegar al colapso.

Sin embargo, para los escépticos del trabajo remoto, ahora ya se tiene evidencia de que esta dinámica bien implementada puede ser no solo beneficiosa sino también altamente productiva. Lo que abriría las puertas para que se armen espacios de trabajo híbridos donde el que quiera pueda ir a una oficina a trabajar y el que no lo desee pueda trabajar desde donde le plazca. Evidentemente, esto dependerá de la forma en que vaya evolucionando la crisis.

El mundo Android en el 2020

En el mundo Android, este fue el año de las llamadas habilidades de Desarrollo Moderno en Android o conocido en inglés como “MAD skills”, se ha hecho mucho esfuerzo en la adopción de Kotlin por parte de Android en las diferentes dependencias o bibliotecas que se han venido trabajando. Esto ha permitido potenciar el conjunto de bibliotecas que yacen bajo el nombre de Jetpack y que forman parte de la manera en que Google recomienda la construcción de las nuevas aplicaciones, hecho que nos debe llevar a una necesaria actualización y adopción.

También, se ha hecho incapié en el uso de App Bundle, una nueva forma de distribución que permite la optimización de los recursos de nuestras aplicaciones.

Adicionalmente, han habido mejoras significativas en la construcción de las UIs mediante el uso de componentes como ConstraintLayout 2 y MotionLayout. Los cuales han de estar muy vigentes también durante el próximo año.

Finalmente, con las nuevas actualizaciones de Android como sistema operativo han llegado nuevas restricciones al acceso a data sensible que debemos tomar en consideración si deseamos mantener nuestras aplicaciones vigentes.

De hecho, tras el apoyo de Google hace 3 años, hoy en día no cabe duda del valor que Kotlin tiene para nosotros y, de hecho, si no estás familiarizado con dicho lenguaje tus opciones de empleabilidad van a caer dramáticamente.

Las comunidades se reinventaron

Las comunidades de desarrolladores también se vieron en la necesidad de adaptarse; tuvieron que pasar de organizar eventos de forma presencial con toda la logística que ello conlleva, a organizarlas de manera virtual. Pasaron de buscar espacios físicos a buscar plataformas de streaming que facilitaran la organización de pláticas.

Lo anterior también llevó a replantearse la necesidad de cobrar por el acceso a los eventos, dado que ya no se cuenta con el atractivo inherente de un evento físico, algunos eventos pasaron a cobrar algo simbólico o simplemente a liberar la entrada.

Esto también provocó el replanteamiento de las charlas brindadas por los speakers, dado que anteriormente tenía sentido compartir la misma presentación en múltiples lugares con público distinto en cada una y ahora una charla dada en un evento tranquilamente es accesible a través de las grabaciones que podían quedar en Youtube, lo que los lleva a presentar algo nuevo en cada presentación.

¿Qué vendrá en el 2021?

Este año que viene será el año de Compose, una nueva forma de construir interfaces de manera declarativa y que viene siendo escrita enteramente en Kotlin, y de Hilt, una dependencia que crea una capa de abstracción sobre Dagger, y que nos permitirá efectuar la inyección de dependencias de una forma más natural. Ambos, van a contar con sus primeros releases estables durante este próximo año.

No podemos dejar de lado la mención a Kotlin Multiplatform, una solución que permite compartir código durante el desarrollo de aplicaciones multiplataforma y que se ha venido cocinando durante un buen tiempo, ahora mismo se encuentra aún en alpha, pero podríamos ver sus primeros betas en el trascurso de este 2021 también.

Otro cambio más que se nos viene será la adopción de nuevos nombres código o codenames para las nuevas versiones de Android Studio empezando por la versión 4.3 que además de cambiar el esquema de versionamiento que estará más alineado con lo que se viene haciendo con IntelliJ Idea nos traerá un nuevo nombre código Android Studio Artic Fox.
https://android-developers.googleblog.com/2020/12/announcing-android-studio-arctic-fox.html

Este nuevo año traerá consigo muchas adaptaciones de lo viejo a lo nuevo; la entera adopción de Kotlin, la adopción de los MAD skills, etc.
https://developer.android.com/series/mad-skills

Claro está que más allá de las novedades, lo que no cambiará será la necesidad de conocer cosas tan fundamentales como los buenos principios de programación, la adopción de patrones de diseño de software, entre otros conocimientos que nos ayudarán a escribir y estructurar nuestro código de mejor forma, y que a su vez nos llevará a desarrollar mejores aplicaciones.

Cierre

Espero que este nuevo año traiga consigo cosas positivas, que puedan seguir cuidándose a ustedes y a sus familias. Y que podamos seguir creciendo en medio de la adversidad que hoy vivimos. Un abrazo a todos y les deseo un Feliz Año Nuevo 2021.

Adios!

Kotlin Coroutines 101 — Jobs

Armando Picón — Sun, 17 May 2020 18:33:01 +0000

Kotlin Coroutines 101 — Jobs

En este artículo estaré vamos a mencionar algunos aspectos que encuentro interesantes sobre los Jobs.

¿Qué es un Job?

En el primer artículo que escribí tuvimos ocasión de lanzar una corutina mediante la acción de un botón. Pero ¿qué pasa si por algún motivo queremos verificar el estado de la corutina o cancelarla, si fuera necesario?. Es aquí donde entra a tallar la tarea de un Job.

Un Job es una representación de una corutina y nos va a permitir realizar algunas acciones sobre ella.

¿Cuáles son sus estados?

Los Jobs cuentan con estados, los cuales listaré a continuación:

Ciclo de vida de un Job

New : representa el estado de creación de una corutina y la asociación de un Job a ella.
Active : este estado representa el momento en el que se inicia ejecución y mantiene la ejecución de una corutina.
Completing : este estado representa el momento en que la corutina ha finalizado su ejecución y precisa esperar a que otras corutinas asociadas a ella o en una relación de padre-hijo finalicen.
Completed : este estado representa el estado final de una corutina, el momento en el que toda su ejecución, incluyendo las corutinas hijas, ha finalizado.
Cancelling : este estado representa el momento en el que se ha cancelado la corutina y se espera la cancelación de los Jobs asociados a ella.
Cancelled : este es el estado final una vez que se ha procedido a la cancelación total o completa.

Debido a la existencia de estos estados, es posible mediante un Job acceder a las siguientes propiedades:

isActive : esta propiedad nos permitirá saber si un Job se encuentra en estado activo o no.
isCancelled : esta propiedad nos permitirá saber si un Job ha sido cancelado o no.
isCompleted : esta propiedad nos permitirá saber si un Job ha finalizado o ha completado todas sus operaciones.

¿Cuándo emplear estas propiedades? La respuesta sencilla sería emplearlas en momentos en los que la ejecución o lógica de tu corutina demande saber si debe continuar o no si el estado de la misma cambia.

La función invokeOnCompletion

Un aspecto interesante de los Jobs es que es posible ejecutar código una vez que estos finalizan y esto es gracias a la función invokeOnCompletion(), esta función recibe como parámetro un objeto nullable de tipo Throwable? que nos permitirá validar la causa por la que una corutina fue cancelada.

job1.invokeOnCompletion { throwable ->  
    log("Complete my job 1")
    throwable?.let {  
        log("There is a throwable object!")
        when ( it ) {
            is CancellationException -> {
                log( it.message ?: "Without message")
            }
        }
    }  
}

¿Cómo cancelar un job?

Cancelar un Job se puede conseguir mediante la invocación de su función cancel(). Sin embargo, te va a pedir que pases una instancia de la clase CancellationException, preferiblemente hay que agregarle un mensaje que indique la causa por la que se está cancelando el Job.

¿Cómo concatenar jobs?

Concatenar Jobs es relativamente sencillo, para ello requerimos ejecutar la función join(). El comportamiento por defecto de la función join() implica que la corutina que lo invoque se suspenda hasta que este Job esté completo. Sin embargo, si al builder de turno le pasamos el parámetro start=CoroutineStart.LAZY lo que acontecerá es que dicho Job pasará a un estado activo en el punto en el que join() sea invocado.

¿Cómo definir una relación de padre/hijo entre Jobs?

Definir una relación de padre e hijos es posible si pasas el Job como parte del contexto de la corutina que quieres definir como Job hijo.

val job1 = coroutineScope.launch(start = CoroutineStart.LAZY, 
                                 context = handlerException) {...}

val childCoroutineScope = CoroutineScope(Dispatchers.Main + job1)
val job2 = childCoroutineScope.launch{...}

¿Cómo manejar una excepción en un job?

Para manejar excepciones tienes dos forma; la primera, de forma tradicional usando un try/catch en la sección de código que quieres asegurar; la otra, es declarando una instancia de CoroutineExceptionHandler, el cual recibe como parámetros tanto un objeto conteniendo información sobre el contexto de la corutina y un objeto del tipo Throwable. Este objeto debe pasarse como parte del contexto de la corutina.

val handlerException = CoroutineExceptionHandler {
    coroutineContext, throwable ->  
        run {  
                log("$coroutineContext - ${throwable.message}")
        }  
}  

val job1 = coroutineScope.launch(context = handlerException ) {...}

Para complementar les dejo un video para complementar el contenido de este artículo, regálenme un Me gusta si les es de utilidad y un comentario en el video.