DEV Community: Armando Picón

🔐 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.

Kotlin Coroutines on Android 101

Armando Picón — Mon, 27 Apr 2020 06:25:32 +0000

Las corutinas son una de las características que gracias a Kotlin tenemos hoy en día y que busca simplificar la forma en la que se ejecutan tareas asíncronas. Este artículo tiene por objetivo hacer un repaso por los conceptos claves para entender cómo funciona.

Las corutinas actúan de forma similar; sin embargo, es importante recalcar que no son hilos.
Varias corutinas pueden ser ejecutadas en un mismo hilo.
Internamente se hace uso de un pool de hilos que nos proveerá el sistema.
Las funciones suspendidas o suspend functions es una variante de nuestras funciones regulares pero que pueden ser pausadas y resumidas en un momento posterior.
Para la ejecución de corutinas o funciones suspendidas es necesario establecer previamente el ámbito o scope en el que van a ser ejecutados (Ej. CoroutineScope)
Además del ámbito, la ejecución de una corutina necesita un punto de entrada que se establece mediante el uso de un coroutine builder (Ej. launch{} o async{}).
Para establecer en qué conjunto de hilo o hilos se ejecutarán nuestras corutinas y funciones suspendidas se dispone de los Dispatchers (Main, IO y Default).
Las funciones suspendidas solo pueden ejecutarse dentro de una corutina o desde otra función suspendida.

No te preocupes si por el momento todo lo que he señalado hasta aquí se lee como chino; vamos a ejemplificar estos puntos e irlos explicando poco a poco.

Agregar dependencias

Como primer paso para entrar al mundo de las corutinas debemos agregar las siguientes dependencias a nuestro proyecto. Toma en consideración que a la fecha de publicación de este artículo la versión existente es la 1.3.4, tal vez para cuando tú leas este artículo esta versión haya cambiado.

    def coroutines_version = "1.3.4"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version"

Crear layout

Para centrarnos en probar las corutinas vamos a crear una interfaz sencilla que contenga un elemento de tipo Button con el id @+id/button_launch y un elemento TextView con el id @+id/text_result. ¿Cómo se deben distribuir en la pantalla? Es algo que dejaré a tu criterio.

Preparar nuestras funciones base

Antes de tocar las corutinas necesitaremos crear algunas funciones utilitarias como las que muestro a continuación. Las puedes agregar a tu implementación de tu clase MainActivity.kt (asumiendo que no le cambiaste el nombre por defecto al momento de crear tu Activity):

fun showResult (result: String){
    // Aquí vamos a aprovechar el uso de los synthetic imports para obtener
    // la referencia al textview que agregamos en nuestro UI directamente
    text_result.text = text_result.text.toString() + result + "\n"
}

fun log (message: String){
    // Emplearemos esta función para ayudarnos a identificar el hilo en el 
    // que se está ejecutando nuestra corutina. No siempre será el mismo hilo.
    println("[${Thread.currentThread().name}]: $message")
}

A continuación, dentro de nuestra función onCreate() vamos a agregar la invocación a la función setOnClickListener() de nuestro botón.

button_launch.setOnClickListener {
   // Dentro vamos a escribir nuestra primera corutina
}

Vamos con las corutinas

Vamos a escribir un ejemplo bastante común, vamos a simular la invocación a dos servicios que nos retornarán valores aleatorios.

Para conseguir esto primero escribiremos un par de funciones como te las presento a continuación, estas funciones van a escribir en los logs en qué hilo se está ejecutando, luego va a esperar un determinado tiempo en milisegundos y, finalmente, retornarán un resultado (estamos retornando valores String pero también podríamos retornar otro tipo de valor):

suspend fun getApiResult1 (): String {
    log("Get result from suspend function 1")
    delay(3000) // milisegundos
    return "result 1"
}

suspend fun getApiResult2 (): String {
    log("Get result from suspend function 2")
    delay(1500) // milisegundos
    return "result 2"
}

De estas dos funciones suspendidas es importante notar el uso de la función delay() la cual cumple un rol similar a Thread.sleep() pero sin bloquear el hilo y debido a que en sí misma es también una función suspendida, la regla nos indica que solo se pueden ejecutar desde una corutina o dentro de otra función suspendida (se lee redundante pero es así).

Ahora vamos a armar la implementación de la corutina con su correspondiente punto de entrada:

button_launch.setOnClickListener {
    // Dentro vamos a escribir nuestra primera corutina
    CoroutineScope(Dispatchers.Main).launch {
        executeRequest()
    }
}

Aquí también estamos haciendo uso de la función withContext() y mediante Dispatchers.Main le estamos indicando que la ejecución de esta corutina empezará en el hilo principal. Adicionalmente, hacemos uso de la función launch la cual marcará el inicio de la corutina.

Por razones ilustrativas vamos a agregar un par de funciones adicionales, primero esta:

suspend fun executeRequest() = withContext(Dispatchers.IO) {
    val result1 = getApiResult1()
    showResult(result1)
    val result2 = getApiResult2()
    showResult(result2)
}

Aquí también estamos haciendo uso de la función withContext() el cual especificará que el bloque de código que encierra se va a suspender en el grupo de hilos que determina el Dispatcher, en este caso Dispatchers.IO, el cual está optimizado para la realización de tareas de networking y escritura en disco.

Si intentamos ejecutar el código hasta aquí (espero que lo intentes), seguro la aplicación se va a romper ¿alguna idea del por qué? Dale una vuelta o checka la excepción que salió en tu consola.

Only the original thread that created a view hierarchy can touch its views.

Pero ¿qué pasó? bueno, resulta que gracias al withContext(Dispatchers.IO) esta última función se está ejecutando en los hilos de IO y no en el Main Thread o Hilo de UI. Vamos, entonces, a corregir este problema agregando una última función:

suspend fun sendResultToMainThread(result: String) = withContext(Dispatchers.Main){
    log("Display $result")
    showResult(result)
}

Si lo hiciste bien podrás apreciar lo siguiente en tu consola de Logcat:

[DefaultDispatcher-worker-1]: Get result from suspend function 1
[main]: Display result 1
[DefaultDispatcher-worker-1]: Get result from suspend function 2
[main]: Display result 2

Y listo, podemos apreciar los cambios que se van haciendo a medida que vamos ejecutando cada paso de nuestra pequeña aplicación. Ojo que no hemos empleado un adecuado diseño y hemos puesto todo dentro del Activity, pero la intención es ilustrar cómo funcionan los cambios de contexto durante la ejecución de la corutina y las funciones suspendidas.

Si les gustó este artículo, podría continuar profundizando en el tema y repasar otros conceptos.

Mi nuevo proyecto: Codalot Podcast

Armando Picón — Sun, 29 Mar 2020 04:38:33 +0000

Desarrollo móvil y tecnología en un solo podcast

Desde octubre del año pasado (2019) dejé de participar como co-host de Android Dev Podcast en español. Estoy agradecido por el tiempo porque me brindó muy buenas lecciones.

Tras mi salida del programa de podcast en el que participé durante un año, andaba dándole vueltas a diversas ideas para dedicar mi tiempo.

Hasta el momento debo decir que participar de un podcast me parece una experiencia genial. La posibilidad de entrevistar a otros desarrolladores o profesionales, plantearles preguntas para aprender y conocer más de lo que hacen, intercambiar ideas y, sobretodo, compartir todo este con la comunidad.

Iniciando la creación de un podcast desde cero

Con esto en mente decidí armar mi propio podcast y, como nos pasa con las variables, decidir qué nombre ponerle fue uno de los aspectos más difíciles de decidir. Porque no se trata solo de ponerle un nombre y ya, la elección del nombre va acompañada de preguntas como ¿será un podcast personal o de tecnología? y si será de tecnología ¿el nombre debe brindar la opción de abrir la temática a temas más allá del desarrollo móvil o no?, ¿el nombre debería estar en inglés o en español? ¿será lo suficientemente corto para pronunciar pero sea fácil de recordar también?

Al final de este proceso quedó Codalot y que sería un podcast que iniciaría hablando de desarrollo móvil (mi campo actual de trabajo), pero que eventualmente, en futuras temporadas pudiera tocar temas nuevos como desarrollo front, backend, machine learning, inteligencia artificial, periodismo de tecnología, etc.

¿Por qué Códalot? long-short story: antiguamente, era el nombre que recibió una iniciativa educativa que tuvimos con un buen amigo hace muchos años atrás y que, con el tiempo y las circunstancias de la vida, cayó en desuso. Tiempo atrás hablé con este amigo y me dejó a mi albedrío decidir qué hacer con el nombre. Debo confesar que no fue el nombre que había decidido ponerle al podcast, pero al final, después de indagar un poco, el nombre sonaba bien. Codalot se escucha como Lancelot, Camelot o Code-a-lot.

Ya tenemos un nombre y ¿dónde se va a alojar nuestro podcast?

Buscando alojamiento para nuestro podcast

Otro desafío en nuestro camino rumbo a convertirnos en P̵o̵k̵é̵m̵o̵n̵ ̵m̵a̵s̵t̵e̵r̵s̵ Podcasters es encontrar un buen alojamiento para nuestros episodios.

Aquí hay que considerar varias cosas. ¿Queremos tener el control sobre todo aspecto de nuestro podcast o que alguien más nos provea del servicio? Y si queremos que alguien nos provea del servicio ¿Buscamos un servicio gratuito o uno pago?

Si quisiera hacerlo todo desde cero habría que considerar armar una landing page para el podcast, reservar un repositorio para nuestros episodios (puede ser pago como Amazon S3 o gratuito como Archive.org), generar el RSS de nuestro programa y crear cuentas en cada servicio de distribución (Spotify for Podcasters, Podcast Connect by Apple, Google Play Podcast Portal, Pocketcast, etc).

Como no quería invertir mucho tiempo en todo ello, me fui por una plataforma que me proveyera de todo lo necesario para que solo me preocupe por grabar. De todos los servicios que vi me quedé con el servicio gratuito que brinda Anchor.fm.

¿Qué implica usar Anchor.fm?

Implica que solo puedes tener un podcast por cuenta, que agreguen su loguito en el arte visual de tu podcast, que tengas la posibilidad de monetizar (si vives en EUA), que puedas grabar segmentos a través de sus diferentes plataformas, pero el principal valor fue que te distribuye en una buena cantidad de servicios automáticamente (incluyendo Spotify, excluyendo Apple Podcast).

Es importante mencionar que si deseas acceder a los stats de Spotify, puedas reclamar tu podcast empleando el correo que asignaste a tu podcast. No es un proceso difícil, pero es importante tenerlo en cuenta.

Si eventualmente el programa crece y quisiera llevarlo a un plano más profesional, tal vez requiera de otro tipo de servicios; como todavía es prematuro no he revisado que tan complicado podría ser abandonar la plataforma.

¿Y qué onda con el hardware?

Para empezar un podcast diría que lo más importante es el contenido y que así juntito está la calidad del audio. Como muchas cosas, soy de la idea que lo primero es empezar y ver si le agarramos el gusto. Cuando participaba del anterior programa lo hacía con el micrófono de la laptop, luego de agarrarle el gusto invertí un poco de dinero para comprar un micrófono.

El micrófono que adquirí fue un Yeti by Blue. Ya conocía este micrófono porque lo había empleado años atrás cuando me tocó grabar un curso para una plataforma online y conocía de sus opciones. Además de proveer una buena calidad de sonido, los modos que trae consigo te permiten usarlo también para entrevistas presenciales con más de una persona. Les recomiendo revisarlo.

¿Y el software?

Para grabar cada episodio me valgo de la plataforma Zencastr, en su plan gratuito te permite contar con 3 participantes por grabación, te brinda almacenamiento local e integración con Dropbox, lo cual permite que al final de cada sesión tengas el audio por separado de cada participante en la nube, esto es suficiente para luego pasar a la post-producción.

Para juntar los audios, editarlos y generar el archivo de audio que subiré a Anchor empleo Audacity, una aplicación gratuita muy conocida que permite realizar ediciones de audio. Esto es suficiente para preparar el audio final.

Planeación de cada episodio

El contenido es un aspecto importante del podcast. Para ello lo que hice fue planear de antemano sobre qué temas quería hablar en una primera temporada.

Recibí el buen consejo de planificar de 6 en 6 los episodios. Partiendo por enumerar un título genérico de la temática de cada episodio y, luego, por cada uno, coordinar la participación del invitado, enumerar las preguntas o dudas que puedan surgir de uno mismo o de la comunidad, armar un pequeño delineación de la estructura del episodio (incluyendo la apertura, la presentación y el cierre).

También, es bueno practicar un poco las transiciones, familiarizarse con el contenido del tema a tratar, todo esto con el fin de hacer que la dinámica de cada episodio sea fluída. Igual, es algo que se va mejorando con el tiempo y a medida de que se vaya ganando experiencia.

Sin duda alguna entrar al mundo del podcasting es genial, espero que este contenido les sirva de referencia por si algún día se animan a incursionar en ello. No dejen de escuchar mi podcast a través de la principales plataformas de streaming (los enlaces de cada plataforma se los dejo a continuación). Si tienen comentarios o sugerencias no duden en hacérmelas llegar. Saludos y buena cuarentena.

Codalot en Spotify

Codalot en Podcast by Apple

Codalot en Google Play Music