DEV Community: Danilo Barreto

The Koin Scope Bug That Teaches You What single vs. factory Actually Means

Danilo Barreto — Thu, 13 Aug 2026 23:34:24 +0000

The Koin Scope Bug That Teaches You What `single` vs. `factory` Actually Means

Dependency injection frameworks make a promise: ask for a dependency, get an instance, don't worry about how it was constructed. Koin's single {} and factory {} definitions look interchangeable in a quick glance at the DI module — both are one-liners, both resolve the same type. They are not interchangeable, and building Finio produced a bug that makes the difference impossible to forget.

The bug

AuthViewModel was originally registered in Koin as:

val appModule = module {
    factory { AuthViewModel(get(), get()) }
}

factory {} means: every time something injects AuthViewModel, Koin constructs a new instance. That's fine for something stateless and cheap to build. It is not fine for a ViewModel holding observable auth state, because in Finio, MainActivity injected AuthViewModel directly (via koinInject, to call saveFcmToken after a successful login) while Compose screens injected their own AuthViewModel through by viewModel() for UI state observation.

With factory {}, those were two different objects. MainActivity held one instance of AuthViewModel; the login screen's composable held another. When the login screen updated its instance's state (successful auth, user profile loaded), MainActivity's separate instance had no idea anything happened — it was still holding the old, unauthenticated state. Symptoms like "the FCM token doesn't get saved after login" or "the UI doesn't reflect the login I just did, depending on which part of the app checks state" trace directly back to this: two objects that look like one shared source of truth to the code reading them, but aren't.

The fix, and why it's correct

val appModule = module {
    single { AuthViewModel(get(), get()) }
}

single {} means Koin constructs the instance once and returns that same instance for every subsequent injection request, for the lifetime of the Koin container. Now MainActivity and every Compose screen injecting AuthViewModel are looking at the same object. State mutated in one place is visible everywhere, which is the entire point of a ViewModel meant to represent shared session state.

When each one is actually correct

The rule isn't "always use single" — that would just trade one class of bug for a different one (unbounded memory retention, state leaking across contexts that shouldn't share it). The distinguishing question is: does this dependency represent shared state that multiple consumers need to observe consistently, or is it a stateless/cheap operation that's fine to reconstruct on demand?

single {} fits shared, long-lived state: AuthViewModel (session state), a database instance, a network client, anything acting as a source of truth that more than one part of the app reads or writes.
factory {} fits short-lived, stateless, or intentionally-isolated instances: a use case class with no internal state, a mapper, or a ViewModel that's genuinely scoped to one screen instance and shouldn't be shared even if injected from two places.

The open question this raised for the rest of the app

Fixing AuthViewModel surfaced a broader review that's still in progress in Finio: TransactionViewModel, BudgetViewModel, and InsightsViewModel are currently all registered as factory {}. Whether that's correct depends on the same question above, applied per-ViewModel, not assumed globally:

If a screen and, say, a widget or notification handler both need to observe the same transaction list state, factory {} will silently produce the same bug AuthViewModel had — two instances, one seeing stale data.
If each ViewModel is genuinely scoped to exactly one screen instance, with no other consumer expected to share its state, factory {} is correct and arguably safer — it avoids holding a screen's state in memory after the screen itself is gone, and avoids one screen instance's data leaking into a re-visit of the same screen.

The honest answer, before "fix it" makes sense as an action: audit each ViewModel for whether it currently has, or is ever likely to have, more than one consumer that needs consistent shared state. AuthViewModel failed that test because MainActivity needed to observe/act on auth state outside the Compose tree that owned the "main" AuthViewModel instance. TransactionViewModel might genuinely not have that requirement yet — but "yet" is doing a lot of work in that sentence, and it's the kind of assumption worth writing down as a comment next to the Koin definition, not just carrying in your head.

The generalizable lesson

Koin's single vs. factory distinction is really Koin's syntax for a much older DI concept — singleton scope vs. transient/prototype scope, present in Spring, Dagger, and virtually every DI framework under different names. The bug pattern this produces (two objects both believed to be "the" instance, one of them silently stale) isn't specific to Koin or even to Kotlin — it's what happens any time a DI container's scope configuration doesn't match the actual sharing requirements of the code consuming it. The fix is never "use single by default" or "use factory by default" — it's asking, for each registration, who else reads this, and do they need to see the same object I just mutated.

Takeaways

factory {} gives every injection a new instance; single {} gives every injection the same instance. Treat this as a correctness decision, not a style preference.
Any dependency injected from more than one place that needs to observe consistent state — a ViewModel read by both an Activity/Controller and a Compose/UI layer — almost always needs single {}.
When you find a factory {}-scoped dependency injected in multiple places, that's the exact shape of bug to check for before assuming the issue is elsewhere in your state management.
Audit DI scope decisions per-dependency, not as a blanket default — and write down why a scope was chosen when it's not obvious, because "obviously scoped to one screen" today can quietly become "actually needs to be shared" after the next feature is added.

This article is part of a series on the engineering decisions behind Finio, a Kotlin Multiplatform personal finance app. Full series and notes: github.com/dgbarreto/tech-writing.

FCM Push Notifications and Deep Linking in Compose Multiplatform: The Payload Choice That Breaks Everything

Danilo Barreto — Sat, 08 Aug 2026 13:38:05 +0000

FCM Push Notifications and Deep Linking in Compose Multiplatform: The Payload Choice That Breaks Everything

There's a single decision in Firebase Cloud Messaging that determines whether your Android push notification handling code runs at all when the app is backgrounded: whether you send a notification payload or a data-only payload. Get it wrong and your carefully written onMessageReceived handler simply never fires — no crash, no error, just silence. This is one of the sharper lessons from building push notifications and deep linking for Finio, a Compose Multiplatform personal finance app.

Why data-only payloads are not optional

FCM supports two payload shapes. A notification payload is rendered by the OS notification tray automatically, which sounds convenient — until the app is backgrounded or killed, at which point Android intercepts it before it ever reaches your app's onMessageReceived callback. Your FinioMessagingService never runs, so any custom logic — routing data into the right screen, marking a budget alert as read, deep link payload construction — is skipped entirely.

The fix is to always send data-only payloads:

{
  "message": {
    "token": "...",
    "data": {
      "type": "budget_alert",
      "budgetId": "abc123",
      "title": "Budget Alert",
      "body": "You've spent 90% of your Groceries budget"
    }
  }
}

With a data-only payload, onMessageReceived fires in every app state — foreground, background, or killed — and you take full responsibility for constructing the notification yourself, including navigating the intent when the user taps it. It's more code up front, but it's the only path that gives you control over what happens on tap, which is exactly what deep linking needs.

Routing the tap: `DeepLinkEventBus`

Once a push notification is tapped, the app needs to know it should open directly to a specific screen — in Finio's case, tapping a budget alert should land the user on the Budget tab, not the default home screen. The mechanism connecting "Android Intent received in MainActivity" to "Voyager navigator changes screen" is a DeepLinkEventBus: a shared event stream that platform-specific entry points publish to, and that the Compose navigation layer subscribes to.

The flow looks like this:

FinioMessagingService.onMessageReceived builds a local Notification from the data payload, attaching a PendingIntent that carries the deep link target (e.g., budgetId and a route identifier) as Intent extras.
When the user taps the notification, MainActivity.onNewIntent (or onCreate, if the app was killed) reads those extras and publishes an event onto DeepLinkEventBus.
A composable observing the bus — typically hoisted near the root Navigator — reacts to the event and calls into Voyager to push the Budget tab's screen onto the stack.

This indirection matters because MainActivity shouldn't know about Voyager's navigation API directly, and the Compose navigation layer shouldn't know about Android's Intent system. The event bus is the seam between "platform delivered a signal" and "UI reacted to it," which keeps the platform-specific code (MainActivity, the FinioMessagingService) decoupled from the shared Compose navigation logic — important in a KMP codebase where the iOS side needs the equivalent flow (APNs → deep link) to funnel into the same shared navigation reaction, not a parallel implementation.

A rendering trap that looks unrelated but isn't

One easy-to-miss detail on the Voyager side: a Navigator composable requires calling navigator.lastItem.Content() — not just referencing navigator.lastItem. It's a one-token difference that fails silently: the screen state changes, the navigator's internal stack updates correctly, but nothing visibly renders, because lastItem on its own is just a Screen reference, not a call to its Content composable. If a deep link event correctly updates navigation state but the UI doesn't visibly change, this is the first thing worth checking before assuming the event bus itself is broken.

The bug hiding in "why did I get this notification twice?"

A concrete debugging example from Finio: the app was displaying two duplicate notifications on launch, even with no new pushes sent from the server. There are two candidate explanations worth separating before touching code:

FinioMessagingService itself firing twice for a single message (a service lifecycle or registration issue), or
getBudgetWithProgress — the endpoint that evaluates whether a budget threshold was crossed — being called multiple times during initial load, each call independently deciding "this budget is over threshold, fire a notification."

These have different fixes. The first is a client-side FCM registration bug. The second is a backend logic gap: if budget alert evaluation happens as a side effect of a read endpoint, then anything that causes that endpoint to be called twice (a retry, a duplicate screen mount triggering the same ViewModel fetch, a race between cache and network) produces a duplicate alert, because there's no idempotency guard around "have I already alerted for this state."

That second failure mode is really a design gap, not a bug: alert-firing is currently coupled to every evaluation of budget progress, with no memory of whether an alert was already sent. The options under consideration to fix this properly:

lastAlertSentAt with a 24-hour throttle — simple, but can suppress a legitimate second alert if the user makes several large purchases in one day and crosses further thresholds.
An alertSent boolean that resets on budget renewal — cleaner semantically (one alert per budget period), but requires the budget renewal job to explicitly reset the flag.
Fire only when the percentage crosses a threshold for the first time — the most precise, but requires persisting the last-known percentage to detect a crossing rather than a static state.

None of these is implemented yet in Finio; the point worth taking away isn't which one is "correct" in the abstract, but that duplicate-notification bugs are frequently a decoupling problem — a side effect (sending an alert) fired from something that has no concept of "have I done this already" (a stateless progress calculation) — rather than a duplicate-registration bug, and it's worth ruling out the simpler client-side explanation before redesigning the alert logic.

Takeaways

Always use data-only FCM payloads if you need custom logic to run in the background or killed app states — notification payloads bypass your handler entirely outside the foreground.
Keep an event bus (DeepLinkEventBus or equivalent) as the seam between platform-specific intent handling and shared Compose navigation — it keeps both sides testable and keeps Android/iOS deep link entry points converging on one reaction path.
With Voyager, remember navigator.lastItem.Content(), not navigator.lastItem — a common one-token bug that silently fails to render.
When you see duplicate side effects (notifications, alerts, emails), check whether the side effect is coupled to a stateless read operation before assuming it's a registration or delivery bug — idempotency is usually the real fix.

This article is part of a series on the engineering decisions behind Finio, a Kotlin Multiplatform personal finance app. Full series and notes: github.com/dgbarreto/tech-writing.

Building a Design System That Actually Gets Used: Tokens, Components, and the AGP 9 Gotcha That Almost Broke It

Danilo Barreto — Tue, 21 Jul 2026 00:37:09 +0000

Building a Design System That Actually Gets Used: Tokens, Components, and the AGP 9 Gotcha That Almost Broke It

A design system is only as good as its adoption rate. It's easy to publish a beautiful FinioButton component and watch half the codebase quietly reach for raw Material3 Button anyway because it was faster in the moment. The real engineering problem isn't drawing the components — it's making the design system the path of least resistance.

Here's how finio-design-system, one of five KMP libraries behind the Finio personal finance app, is structured to make that true, plus a packaging bug that silently strips your design system's resources out of production builds if you don't know to look for it.

Tokens first, components second

Everything in the design system is built on four token categories, each its own object in dev.finio.designsystem.theme:

Colors (FinioColors.kt) — semantic, not literal. primary = #6C63FF, but also purpose-built tokens like success = #4CAF50, error = #B00020, subtle = #8A8AA8, disabled / onDisabled pairs. The naming convention pairs every "on-X" color with its background (onPrimary, onSurface, onError), following the same pattern Material Design uses internally — which makes the token set easy to reason about even if you've never seen Finio's code before.

Spacing (FinioSpacing.kt) — a linear scale from xxxs = 2.dp to xxxl = 64.dp, in nine steps. Having nine named steps instead of arbitrary dp values everywhere means a spacing audit is a search for raw .dp literals, not a design review.

Typography (FinioTypography.kt) — a full type scale from displayLarge (57sp) down to labelSmall (11sp), each with explicit lineHeight and letterSpacing, mirroring Material 3's type scale but scoped to the app's own object so it can diverge later without touching Material internals.

Shape (FinioShape.kt) — seven corner radius steps from none to full (a pill shape via RoundedCornerShape(50)).

The rule enforced across the entire finio-app codebase: no screen uses a hardcoded color, spacing, shape, or raw Material3 component. Every value traces back to one of these four token objects, and every interactive element is a DS component (FinioButton, FinioTextField, FinioCard) rather than Button, OutlinedTextField, or Card directly.

Designing components around variants, not props explosion

FinioButton is a useful example of API design under constraint:

@Composable
fun FinioButton(
    text: String,
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    variant: FinioButtonVariant = FinioButtonVariant.Primary,
    enabled: Boolean = true
)

enum class FinioButtonVariant { Primary, Secondary, Destructive, Ghost }

Internally, FinioButton dispatches to FinioPrimaryButton, FinioSecondayButton (yes, that typo is load-bearing now — renaming it is a breaking API change for existing call sites, a reminder that public API surfaces accumulate small debts you choose to live with), FinioDestructiveButton, and FinioGhostButton. Each of those internal implementations pulls its colors, shape, and typography from tokens — FinioColors.primary / onPrimary for the primary variant, FinioColors.error for destructive, FinioShape.sm, FinioTypography.labelLarge throughout.

The pattern generalizes across the component set:

FinioCardTransaction encodes an enum class FinioTransactionType { Income, Expense } and maps it directly to FinioColors.success / FinioColors.error for the amount text — so "is this money coming in or going out" is a type-level decision, not a color chosen ad hoc at each call site.
FinioText ships as semantic wrappers (FinioHeadline, FinioBody, FinioLabel) rather than exposing raw Text(style = ...) calls, so a copy change to "what does body text look like app-wide" is one edit, not a find-and-replace across every screen.
FinioDialog bundles the interaction pattern itself (isDestructive: Boolean swaps the confirm button to the Destructive variant automatically) so a screen author can't accidentally ship a "delete this transaction" dialog with a primary-colored confirm button.

The common thread: the component API encodes the decision (is this a destructive action? is this income or expense?), and the token/variant mapping happens once, inside the design system, instead of being re-derived by every screen that needs it.

The AGP 9 packaging bug that ships an app with no design system resources

This is the kind of bug that doesn't show up until it's too late to catch in a code review: on AGP 9.x with com.android.kotlin.multiplatform.library, Compose resources (composeResources) are excluded from the published .aar by default unless you explicitly opt in:

androidLibrary {
    androidResources {
        enable = true
    }
}

Without this line, finio-design-system builds fine locally, publishes fine to GitHub Packages, and then throws MissingResourceException at runtime in finio-app — but only for whatever resources the design system bundles (icons, fonts) that got silently dropped from the artifact. It's a gap between "the library compiles" and "the library actually works when consumed," and it only surfaces once you try to run the consuming app, not when you build the library itself.

If you're on AGP 9 with a KMP library module and you see resource-not-found exceptions that make no sense given the resource clearly exists in the source tree, check this flag first.

Making adoption the easy path, not the enforced path

None of the token discipline above is enforced by a linter in Finio yet — it's a convention, reinforced by code review and by the fact that DS components are simply less code to write than reaching for Material3 directly and re-deriving colors and spacing by hand. That's a deliberate bet: a design system wins when using it correctly is less typing than not using it, not only when a CI check blocks the PR. The next step on the roadmap is exactly the enforcement layer — extracting FinioNavigationBar as a standalone DS component instead of leaving it inlined in the app shell, and adding semantic income/expense color tokens to FinioTheme to eliminate the last hardcoded Color(0xFF2E7D32) / Color(0xFFC62828) pair still living in TransactionItem.

Takeaways

Build the token layer (color, spacing, typography, shape) before the component layer — components should consume tokens, never define values themselves.
Encode decisions in the component API (destructive vs. primary, income vs. expense) rather than leaving color/style choices to whoever writes the screen.
On AGP 9.x KMP library modules, explicitly enable androidResources or your published artifact silently loses its bundled resources.
Treat every hardcoded color or raw Material3 usage found in review as a design system gap to close, not a one-off exception to allow.

This article is part of a series on the engineering decisions behind Finio, a Kotlin Multiplatform personal finance app. Full series and notes: github.com/dgbarreto/tech-writing.

Structuring a Kotlin Multiplatform App as a Library Ecosystem: Lessons from Building Finio

Danilo Barreto — Sat, 11 Jul 2026 21:18:19 +0000

Structuring a Kotlin Multiplatform App as a Library Ecosystem: Lessons from Building Finio

When most tutorials talk about Kotlin Multiplatform (KMP), they show you a single repo with a shared module and call it a day. That works for a demo. It falls apart the moment you're building a real product with a backend team, a design system that needs to evolve independently, and features that ship on different cadences.

While building Finio, a personal finance app for Android and iOS, I split the codebase into six repositories instead of one monolith: a Node.js/TypeScript API, five independently published KMP library modules, and a Compose Multiplatform app shell that consumes all of them. Here's why, and what it actually takes to make that work.

The shape of the ecosystem

Finio is composed of:

finio-api — a Node.js/TypeScript backend on Railway. Routes live inside feature modules (src/modules/budget, src/modules/transaction, etc.) rather than a separate routes/ folder, and request/response contracts are validated with Zod schemas in src/schemas/.
Five KMP library modules, each published independently via Maven to GitHub Packages: finio-design-system, finio-auth, finio-transaction, finio-budget, finio-insights.
finio-app — the Compose Multiplatform shell, split into androidApp, iosApp, sharedLogic, and sharedUI, which pulls in every library module as a dependency.

The app shell doesn't own business logic. It owns navigation, composition, and platform wiring (Koin DI graph, FCM registration, deep link handling). Everything else — auth flows, transaction parsing, budget calculations, insights — lives in a module that can be versioned, tested, and consumed on its own.

Why split it this way

The obvious question: why not just use Gradle's multi-module setup inside one repo? Two reasons drove the decision.

Independent versioning. When finio-auth gets a bug fix, I don't want to force a new release of finio-budget or touch anything in the app shell's build graph. Publishing each module as its own Maven artifact means finio-app's build.gradle.kts just bumps a version string:

dependencies {
    implementation("dev.finio:auth:1.4.2")
    implementation("dev.finio:transaction:2.1.0")
}

Forcing a real API boundary. When a module only exists as source inside a monorepo, it's tempting to reach across module boundaries "just this once." When a module is a compiled artifact pulled from GitHub Packages, that's not possible — you're forced to design a public API surface deliberately, the same discipline you'd apply to any external SDK.

The tradeoff is real: cross-module changes now require publishing a new version and bumping it downstream, which is slower than editing a file in a monorepo. For a solo/small-team project this is a deliberate cost, taken on because it mirrors how larger organizations actually structure multiplatform codebases once more than one team touches the code.

The `build.gradle.kts` template that makes this repeatable

Every KMP library module in Finio follows the same Gradle template, based on finio-design-system. A few details matter more than they look:

val localProperties = ... // read before the plugins block
val publishVersion = ...

plugins {
    alias(libs.plugins.kotlinMultiplatform) // must come before androidMultiplatformLibrary
    alias(libs.plugins.androidMultiplatformLibrary)
    id("maven-publish")
}

kotlin {
    androidLibrary { /* ... */ }
    iosArm64()
    iosSimulatorArm64()

    listOf(iosArm64(), iosSimulatorArm64()).forEach {
        it.binaries.framework {
            baseName = "auth" // matches the internal module name — see below
        }
    }
}

// publishing block lives OUTSIDE the kotlin { } block
publishing {
    publications.withType<MavenPublication> {
        groupId = "dev.finio"
        artifactId = project.name
        // pom { ... }
    }
    repositories {
        maven {
            credentials {
                username = System.getenv("GITHUB_ACTOR") ?: ""
                password = System.getenv("GITHUB_TOKEN") ?: ""
            }
        }
    }
}

Two ordering rules aren't cosmetic: the kotlinMultiplatform plugin has to be applied before androidMultiplatformLibrary, and the publishing block has to sit outside the kotlin { } block. Get either wrong and you get Gradle configuration errors that don't obviously point back to ordering.

The naming trap: internal module name vs. artifact ID

The single most expensive lesson from this project: the internal module name determines the generated iOS framework/artifact ID, and it has to match the domain, not be something generic like shared.

Early on, finio-auth's internal module was named shared — a leftover from scaffolding. That name propagated into the generated iOS artifact ID, producing a framework that didn't clearly correspond to what it was (auth), and colliding conceptually with any other module that also defaulted to shared. The same issue showed up in finio-transaction, where the Android artifact was published as dev.finio:finio-transaction-android instead of the intended dev.finio:transaction-android — traced back to the artifactId assignment inside withType<MavenPublication> not matching project.name.

The fix in both cases was the same: rename the internal module to match its domain (auth, transactions) and verify the artifactId block explicitly rather than relying on Gradle defaults. If you're setting up a similar structure, check this on day one — renaming a published artifact after consumers depend on it is a breaking change.

Where this leaves the app shell

Because business logic lives in versioned libraries, finio-app stays thin: Compose screens, Voyager navigation, Koin wiring, and platform-specific glue (push notification registration, deep link routing). Before wiring a new feature into the shell, the practice that's paid off is a DTO contract review — checking that the fields a KMP module expects (e.g., finio-transaction, finio-budget) actually match what finio-api's Zod schemas return, before writing a single line of UI code against them. Contract mismatches caught at this stage are a diff; caught after UI is built, they're a rewrite.

Takeaways

If you're structuring a KMP product for more than a weekend project:

Treat each domain (auth, transactions, budget) as a library with a real public API, not a folder.
Get the internal module naming right before you publish — it leaks into iOS artifact IDs and is expensive to rename later.
Keep the publishing block and plugin ordering consistent across every module via a shared template; copy-pasting Gradle config by hand invites drift.
Validate backend/client contracts before building UI on top of them, not after.

None of this is exotic — it's the same modular discipline backend teams have applied to microservices for years, applied to a mobile codebase that happens to target two platforms from one Kotlin source tree.

This article is part of a series on the engineering decisions behind Finio, a Kotlin Multiplatform personal finance app. Full series and notes: github.com/dgbarreto/tech-writing.

Contratos no Kotlin

Danilo Barreto — Mon, 15 Jul 2024 20:49:24 +0000

No desenvolvimento Android com Kotlin, um dos recursos avançados disponíveis para melhorar a segurança e a robustez do código são os "contracts". Contracts permitem que desenvolvedores definam condições que devem ser atendidas antes ou depois da execução de uma função. Este artigo explorará o conceito de contracts, sua importância, como utilizá-los e os benefícios que eles trazem para o desenvolvimento Android.

O Que São Contracts?

Contracts em Kotlin são declarações que definem condições para a execução de funções. Eles permitem que você especifique pré-condições e pós-condições que o compilador pode usar para otimizações e verificações de segurança. Isso ajuda a garantir que certas condições sejam verdadeiras em pontos específicos do código, melhorando a segurança em tempo de compilação e a legibilidade do código.

Importância dos Contracts

Segurança em Tempo de Compilação
Contracts permitem que o compilador faça verificações adicionais, ajudando a capturar erros mais cedo no ciclo de desenvolvimento.
Código Mais Claro e Direto
Especificar pré-condições e pós-condições torna o código mais legível e documentado, facilitando o entendimento das expectativas de uma função.
Redução de Erros em Tempo de Execução
Ao garantir que certas condições sejam atendidas antes de executar um bloco de código, você reduz a chance de erros em tempo de execução, como NullPointerException.

Exemplo de Uso de Contracts

Vamos explorar um exemplo prático de como usar contracts em uma função Kotlin. Suponha que estamos desenvolvendo uma função de validação para um objeto Request.

Definindo um Contract
Aqui está um exemplo de função de validação que usa um contract para garantir que o objeto Request e seu argumento não sejam nulos:

Explicação do Código

Importação de Contracts:
O contrato é uma funcionalidade experimental no Kotlin, por isso é necessário importar o módulo kotlin.contracts.

Definição do Contract:
Dentro da função validate, usamos o bloco contract para definir as condições que devem ser verdadeiras para que a função retorne normalmente. Aqui, especificamos que a função só retorna (returns()) se request e request.arg não forem nulos.

Validação das Condições:
A seguir, realizamos verificações explícitas. Se request for nulo, lançamos uma exceção. Se request.arg for nulo ou vazio, também lançamos uma exceção.

Benefícios dos Contracts

1. Verificação Adiantada
Ao definir contratos, o compilador pode verificar essas condições durante a compilação, ajudando a identificar possíveis problemas mais cedo.

2. Melhor Documentação do Código
O uso de contracts torna o código mais auto-documentado, esclarecendo quais condições são esperadas para a execução correta da função.

3. Maior Robustez
Garantir que pré-condições sejam atendidas antes da execução de um bloco de código reduz a possibilidade de falhas inesperadas durante a execução.

Conclusão

O uso de contracts no desenvolvimento Android com Kotlin oferece uma maneira poderosa de definir e verificar condições críticas em seu código. Eles melhoram a segurança em tempo de compilação, tornam o código mais claro e reduzem a probabilidade de erros em tempo de execução. Implementar contracts em funções críticas pode aumentar significativamente a robustez e a qualidade geral do seu aplicativo. Como esse recurso ainda está em fase experimental, é importante acompanhar as atualizações da linguagem Kotlin para aproveitar ao máximo as melhorias e novidades futuras.

O que há de novo no Android 13?

Danilo Barreto — Sat, 04 Jun 2022 13:48:55 +0000

Chegou aquela hora feliz do ano em que temos uma versão nova do Android. Anunciado no Google I/O, o Android 13 tem uma séries de melhorias e mudanças que afeta não só a vida do usuário final, como a vida de nós desenvolvedores. Eu separei algumas das mudanças que afetam mais a vida do desenvolvedor até agora:

Primeiro e principalmente, quando deve sair:

Já podemos baixar e começar a adaptar os nossos recursos, para o release em Julho!

E o que mais?

1) JetPack Compose 1.2: O JetPack Compose traz uma série de ferramentas para ajudar a montar interfaces mais ricas e fluídas de forma mais simples. Ele traz nessa nova versão recursos como Downloadable Fonts, onde o sistema busca e baixa diretamente fontes do Google Fonts, ajudando a diminuir o tamanho final do apk. Outro recurso interessantes é o Lazy Grid, permitindo montar grids de objetos em tamanho diferentes e não padronizados com menos linhas de código.

2) Melhorias no Android Studio: com o lançamento do AS Dolphin e o Eletric Eel em Canary, temos um monte de recursos novos chegando.

LogCatV2: LogCat remodelado, ajudando na visualização, busca e filtro de registros
Gradle Managed Devices: tudo o que você precisa fazer é descrever o device que precisa pra rodar os seus testes e o GMD cuida do resto pra você! Ele baixa o SDK, provisiona, executa os testes, desmonta o ambiente.
Live Edit: todo o código que você altera, visualmente no Compose, pode ser visto em tempo real, não só na tela de preview como também no emulador e no device físico!
Baseline Profiles: ele permite que apps e bibliotecas adicionem metadados em vistas a ajudar o compilador ahead-of-time a priorizar certos caminhos de código em vistas a deixar a experiência inicial do usuário mais rápida. Essa técnica já está sendo usada em libs como Fragments e Compose e também no app da Play Store, que já reportou ganho de velocidade de 40%

3) Outras melhorias gerais como:

Privacy Sandbox: um novo conjunto de APIs, ainda em preview, para disponibilização de conteúdo para o usuário de forma mais fácil e sem conflitar com as suas preferências de privacidade
Google Wallet: o Google Pay Passes está integrando ao serviço de pagamentos agora chamado Google Wallet. A nova API agora permite a gravação de passes genéricos e o agrupamento em vouchers

Opcionais no Swift

Danilo Barreto — Fri, 17 Dec 2021 17:54:43 +0000

Você já viu um monte de códigos no Swift com "?" e "!" e fica perdido? Usa esses operadores mas sem saber direito quando e onde usar? Esse post então é pra você.

O que é um "?" no Swift

O símbolo "?" representa um opcional no Swift. E um opcional é (pasmem) um enum: .Some(Valor Encapsulado) e .None. Isso permite que ele possa ser vazio (.None) ou possa ter algum valor internamente (.Some(valor).

Exemplo:

var x: Int? = 10

Ao criar uma variável com "?", no caso Int? o Swift cria um enum do tipo Optional mas com o estado .Some(10).

var x: Int? = nil

Caso contrário, se você atribui nil, é criada uma variável do tipo Optional com o estado .None

Comparação

Sabendo agora como é armazenado um Opcional, o Swift oferece algumas formas de trabalhar com ele. Podemos comparar ele de algumas formas:

let x: Int? = 10

switch x{
   case .Some(let value) : print("Valor de x \(value)")
   case .None : print("x não tem valor")
}

Uma boa prática é "desembrulhar" (do inglês unwrap) o valor da váriavel de forma segura usando o guard. O guard pode ser executado da seguinte forma:

func foo(x: Int?){
   guard let y = x else{
      return
   }
   print(y)
}

Encadeamento Opcional

O encadeamento opcional permite você pegar o valor de dentro de um opcional. Diferente do Unwrapping Forçado que vou falar a seguir, ele não causa um erro caso não tenha um valor dento do Opcional. Vamos ao exemplo:

var x: Int? = 10 // .Some(10)
var y: Int = x? // 10

No exemplo simples acima quando eu chamo x? eu faço um unwrapping do Opcional, ou seja, eu pego somente o valor que existe dentro dele. Vamos para um exemplo um pouco mais complexo. Considere o código:

class Person{
   var residence: Residence?
}

class Residence{
   var numberOfRooms = 1
}

Agora considere a seguinte função:

func foo(){
   let john = Person()
   if let roomCount = john.residence?.numberOfRooms{
      print("Número de quartos \(roomCount)")
   } else {
      print("Não foi possível determinar o número de quartos")
   }
}

O trecho de código acima não irá produzir um erro, pois o encadeamento opcional sempre retornar um Opcional que pode ser comparado. Mas ele será nil. Então sua condição irá cair no else. Mas se mudarmos aqui:

func foo(){
   let john = Person()
   john.residence = Residence()
   if let roomCount = john.residence?.numberOfRooms{
      print("Número de quartos \(roomCount)")
   } else {
      print("Não foi possível determinar o número de quartos")
   }
}

O retorno será 1, pois é o valor padrão da quantidade de quartos.

Unwrapping Forçado

O unwrapping forçado tem uma sintaxe parecida, trocando apenas "?" por "!". Mas ele tem uma diferença fundamental: Caso o valor no Opcional seja nil, é gera um erro de execução e o aplicativo irá encerrar, caso não tratado. Utilizando o exemplo acima:

func foo(){
   let john = Person()
   if let roomCount = john.residence!.numberOfRooms{ //o app irá quebrar nessa linha
      print("Número de quartos \(roomCount)")
   } else {
      print("Não foi possível determinar o número de quartos")
   }
}

o unwrapping forçado só deve ser usado caso você tenha ABSOLUTA CERTEZA de que o Opcional tenha valor.

Coalescência

O operador de coalescência "??" permite que você retorne o primeiro valor não nulo (nil) de duas variáveis. Vamos deixar mais claro no exemplo:

let c: Int? = 10
let d: Int = 0
let e = c ?? d //o valor de e será 10

No exemplo acima prevalece o primeiro valor não nil. Segundo exemplo:

let c: Int? = nil
let d: Int = 5
let e = c ?? d //o valor de e será 5

Como no exemplo acima c é nil, o valor de e será 5, o primeiro valor não nil.

BONUS ADVANCED: Map e FlatMap

O tipo Opcional ainda oferece duas funções chamadas Map e Flatmap que permitem que você controle o método de unwrapping passando um closure. A única diferença entro o Map e Flatmap é que o Map não pode devolver nil. Exemplos, exemplos:

var a : Int? = 10

let y : Int?  = a.Map{
   if $0 < 10 {
      return 0
   } else {
      return $0
   }
}

let z : Int? = a.FlatMap{
   if $0 < 10 {
      return nil
   } else {
      return $0
   }
}

É isso gente. Esse é todo o "mistério" dos Opcionais no Swift. A partir de agora você já sabe ler quando encontrar "?" e "!" nos códigos e sabe como posicionar nos seus próprios códigos.

Até a próxima! Keep coding!

Nativo x Hibrido?

Danilo Barreto — Sat, 27 Nov 2021 20:42:20 +0000

No desenvolvimento mobile nos dias de hoje temos diversas opções para criar um app. As pessoas me procuram sempre com essa dúvida: o que usar? E eu sempre respondo: depende!

Não existe uma fórmula mágica que determine qual estratégia usar, mas eu reunião neste paper os principais pontos para essa tomada de decisão. A principal tomada de decisão, na minha visão, é se devemos seguir com o desenvolvimento nativo ou híbrido.

Dentro do desenvolvimento híbrido, é claro, temos muitas vertentes, mas estou considerando por hora Flutter e React Native. Mas a decisão crucial ainda repousa entre o nativo x híbrido. As variações de equipe, custo, qualidade são enormes!

Pode baixar o paper aqui

Injeção de Dependência

Danilo Barreto — Tue, 16 Nov 2021 16:48:41 +0000

O que é injeção de dependência? O que ela tem a ver comigo? O que ela come?

A injeção de dependência é uma prática essencial nos dias de hoje. Apesar de eu falar sobre ela no âmbito do Android, ela é utilizada em todas as linguagens orientadas a objeto, pois ela fornece um fraco acoplamento entre as entidades, permitindo que a sua aplicação possua uma boa arquitetura. Ela também possui um papel fundamental nos testes automatizados, pois permite quer façamos a troca das dependências sem realizar nenhuma modificação nas classes.

Vamos de exemplo

Imagine um carro. O carro possui uma dependência de um motor. Nós podemos representar dessa forma no Kotlin:

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

Nesse caso o motor está definido dentro do carro. Temos um acoplamento forte, pois o carro só permite um tipo de motor. Essa relação cria uma dificuldade caso eu queira um motor diferente. Nos testes automatizados, caso eu queira criar um FakeMotor() isso também não seria possível.
Mas com uma alteração já podemos ver algo diferente:

class Car(private val engine: Engine) {
   fun start() {
      engine.start()
   }
}

Aqui já podemos dizer que temos uma injeção de dependência! Quando recebemos o Engine como parâmetro permitimos diferentes implementações como um EletricMotor ou um FakeMotor no caso de um teste automático. A forma demostrada acima é chamada de Injeção de Construtor. No Android podemos fazer de outra forma com Kotlin:

class car {

   lateinit var engine: Engine

   fun start() {
      engine.start()
   }
}

fun main(args: Array) {
   val car = Car()
   car.engine = Engine()
   car.start()
}

Essa segunda forma é chamada se Injeção de Setter. Como Algumas classes são instanciadas por sistema, como Activities ou Fragments, as vezes não é possível se utilizar da Injeção por Construtor.

Essa é a forma manual de injeção de dependência. Agora imagine que você precisa instanciar todas a partes de um carro? Muita coisa né? Pra isso existem bibliotecas como o Dagger ou o Hilt que podem ajudar a fazer isso de forma automática criando um Graph em memória. Mas isso é assunto para um próximo artigo. A lição valiosa importante aqui é gerar um acoplamento forte da sua classe, pois isso engessa o seu modelo e torna qualquer teste e qualquer refatoração um trabalhão no futuro!

Nova ferramenta do Facebook para encontrar falhas de segurança em apps Android

Danilo Barreto — Fri, 08 Oct 2021 20:43:00 +0000

Há alguns dias o Facebook liberou para o público uma ferramenta, até então caseira, para descobrir falhas de segurança e privacidade em aplicações Anndroid e Java.

Batizada de Mariana Trench (MT) e distribuida de forma Open Source a ferramenta está em constante evolução e suporte pelo time de engenharia do Facebook. Ela é usada hoje em milhões de linhas de código no Whatsapp, Instagram e, claro, no próprio app do Facebook. Segundo o Facebook, na primeira metade de 2021, 50% das vulnerabilidades encontradas foram de forma automatizada.

O MT foi desenvolvido em Python e roda de forma estática no código. Está disponível (aqui)[https://github.com/facebook/mariana-trench/). O Facebook também deixou pronto um tutorial para facilitar nos primeiros passos. O tutorial pode ser acessado (aqui)[https://mariana-tren.ch/docs/getting-started/].

Face Detection com Android e Kotlin

Danilo Barreto — Thu, 23 Sep 2021 18:37:10 +0000

O Google disponibiliza uma API que permite realizar detecção de rostos de maneira offline, sem depender de nenhum serviço na nuvem. Essa API é a Google Vision e foi introduzida no Play Services na versão 8.1. Fazer uma implementação básica é bem simples:

Inclua a referência no build.gradle:
implementation 'com.google.android.gms:play-services-vision:8.1.0'

Em seguida vem a implementação do controle

package com.avanade.myfacedetection

import android.content.Context
import android.graphics.*
import android.util.AttributeSet
import android.util.SparseArray
import android.view.View
import androidx.core.util.valueIterator
import com.google.android.gms.vision.Frame
import com.google.android.gms.vision.face.Face
import com.google.android.gms.vision.face.FaceDetector

public class FaceOverlayView(context: Context, attrs: AttributeSet? = null, defStyleAttr: Int) : View(context, attrs, defStyleAttr) {
    constructor(context: Context, attrs: AttributeSet) : this(context, attrs, 0)
    private lateinit var mBitmap: Bitmap
    private var mFaces: SparseArray<Face> = SparseArray<Face>()

    fun setBitmap(bitmap: Bitmap){
        mBitmap = bitmap

        val faceDetector : FaceDetector = FaceDetector.Builder(context)
            .setTrackingEnabled(true)
            .setLandmarkType(FaceDetector.ALL_LANDMARKS)
            .setMode(FaceDetector.ACCURATE_MODE)
            .build()

        if(!faceDetector.isOperational()){
            //TODO: Colocar verificação
        }
        else{
            val frame : Frame = Frame.Builder()
                .setBitmap(mBitmap)
                .build()
            mFaces = faceDetector.detect(frame)
            faceDetector.release()
        }

        invalidate()
    }

    override fun onDraw(canvas: Canvas?) {
        super.onDraw(canvas)

        if(mBitmap != null && mFaces != null){
            var scale : Int? = canvas?.let { drawBitmap(it) }
            if(canvas != null && scale != null){
                drawFaceBox(canvas, scale)
            }
        }
    }

    fun drawBitmap(canvas: Canvas) : Int{
        val viewWidth : Int = canvas?.width ?: 0
        val viewHeight : Int = canvas?.height ?: 0
        val imageWidth : Int = mBitmap.width
        val imageHeight : Int = mBitmap.height
        val scale : Int = Math.min(viewWidth / imageWidth, viewHeight / imageHeight)
        val bounds : Rect = Rect(0, 0, imageWidth * scale, imageHeight * scale)
        canvas.drawBitmap(mBitmap, null, bounds, null)
        return scale
    }

    fun drawFaceBox(canvas: Canvas, scale: Int){
        var paint: Paint = Paint()
        paint.setColor(Color.BLUE)
        paint.style = Paint.Style.STROKE
        paint.strokeWidth = 5F

        var left : Float = 0F
        var top : Float = 0F
        var right : Float = 0F
        var bottom : Float = 0F

        for(face in mFaces.valueIterator()){
            left = face.position.x * scale
            top = face.position.y * scale
            right = scale * (face.position.x + face.width)
            bottom = scale * (face.position.y + face.height)

            canvas.drawRect(left, top, right, bottom, paint)
        }
    }
}

Aqui fazemos a criação do objeto que faz a detecção dos rostos na foto

        val faceDetector : FaceDetector = FaceDetector.Builder(context)
            .setTrackingEnabled(true)
            .setLandmarkType(FaceDetector.ALL_LANDMARKS)
            .setMode(FaceDetector.ACCURATE_MODE)
            .build()

Logo abaixo temos if(!faceDetector.isOperational()) que é uma verificação importante. Caso o usuário nunca tenha usado em nenhuma aplicação a API do Google Vision o device vai baixar essa lib e, pode ser que nesse momento a API ainda não esteja disponível. Então é importante fazer essa verificação para evitar um erro de NullPointerException.

            val frame : Frame = Frame.Builder()
                .setBitmap(mBitmap)
                .build()
            mFaces = faceDetector.detect(frame)
            faceDetector.release()

Aqui é onde o código irá efetivamente analisar a imagem e verificar os rostos das pessoas. As informações dos rostos encontrados é armazenado em um array de Faces usado aqui para desenhar os quadrados sobre o frame:

        for(face in mFaces.valueIterator()){
            left = face.position.x * scale
            top = face.position.y * scale
            right = scale * (face.position.x + face.width)
            bottom = scale * (face.position.y + face.height)

            canvas.drawRect(left, top, right, bottom, paint)
        }

O código completo está aqui no repo.

Aqui também está um vídeo da implementação:

Mudança de Privacidade Chegando

Danilo Barreto — Wed, 22 Sep 2021 12:41:52 +0000

O Google estará liberando nos próximos meses uma melhoria nos recursos de privacidade. Esse recurso terá como algo todas aquelas aplicações mais antigas, esquecidas e sem uso, que possuam acesso a dados sensíveis.
Entre os recursos que serão "perdidos" para essas apps estão envio de SMS, sensores e acesso à lista de contatos.
"O recurso será habilitade por padrão em apps rodando Android 11 (API level 30) ou superior. Contudo, usuários poderão habilitar auto-reset de permissões para apps rodando com API levels 23 a 29", disse o Google.

Esse novo recurso visa aumentar ainda mais a segurança digital, prevenindo que apps antigas possam se aproveitar desses acessos concedidos e, com alguma atualização, rodar algum código malicioso ou abrir portas para tal.

A atualização deve começar a sair para o público geral a partir de Dezembro, mas deve demorar até o final de Março/2022 para atingir todo o público esperado.

DEV Community: Danilo Barreto

The Koin Scope Bug That Teaches You What single vs. factory Actually Means

The Koin Scope Bug That Teaches You What single vs. factory Actually Means

The bug

The fix, and why it's correct

When each one is actually correct

The open question this raised for the rest of the app

The generalizable lesson

Takeaways

FCM Push Notifications and Deep Linking in Compose Multiplatform: The Payload Choice That Breaks Everything

FCM Push Notifications and Deep Linking in Compose Multiplatform: The Payload Choice That Breaks Everything

Why data-only payloads are not optional

Routing the tap: DeepLinkEventBus

A rendering trap that looks unrelated but isn't

The bug hiding in "why did I get this notification twice?"

Takeaways

Building a Design System That Actually Gets Used: Tokens, Components, and the AGP 9 Gotcha That Almost Broke It

Building a Design System That Actually Gets Used: Tokens, Components, and the AGP 9 Gotcha That Almost Broke It

Tokens first, components second

Designing components around variants, not props explosion

The AGP 9 packaging bug that ships an app with no design system resources

Making adoption the easy path, not the enforced path

Takeaways

Structuring a Kotlin Multiplatform App as a Library Ecosystem: Lessons from Building Finio

Structuring a Kotlin Multiplatform App as a Library Ecosystem: Lessons from Building Finio

The shape of the ecosystem

Why split it this way

The build.gradle.kts template that makes this repeatable

The naming trap: internal module name vs. artifact ID

Where this leaves the app shell

Takeaways

Contratos no Kotlin

O Que São Contracts?

Importância dos Contracts

Exemplo de Uso de Contracts

Explicação do Código

Benefícios dos Contracts

Conclusão

O que há de novo no Android 13?

Opcionais no Swift

O que é um "?" no Swift

Comparação

Encadeamento Opcional

Unwrapping Forçado

Coalescência

BONUS ADVANCED: Map e FlatMap

Nativo x Hibrido?

Injeção de Dependência

Vamos de exemplo

Nova ferramenta do Facebook para encontrar falhas de segurança em apps Android

Face Detection com Android e Kotlin

Mudança de Privacidade Chegando

The Koin Scope Bug That Teaches You What `single` vs. `factory` Actually Means

Routing the tap: `DeepLinkEventBus`

The `build.gradle.kts` template that makes this repeatable