DEV Community: Danilo Barreto

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.

Android ViewModel

Danilo Barreto — Sat, 18 Sep 2021 14:54:17 +0000

Uma das práticas básicas de desenvolvimento que temos que adotar assim que saímos do campo de estudos e entramos no campo de desenvolvimento profissional de aplicativos é separar a camada de negócios da camada de visualização. A camada de visualização possui um ciclo de vida próprio que muda de acordo com o estado do device (se a app está em primeiro ou segundo plano, se rotacionamos o aparelho, se o SO solicita memória, etc). Os dados de negócio não podem estar sujeitos a esses tipos de mudança.
Para auxiliar essa implementação o Kotlin traz o ViewModel. O ViewModel permite realizar uma delegação e uma separação dos dados de negócio. Vamos à implantação:

O primeiro passo é a referencia à biblioteca no build.gradle.
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0'

A seguir no projeto crie uma classe herdando de ViewModel

public class PackageModel : ViewModel(){
}

Agora vem a parte importante da implementação. O Kotlin possui um recurso chamado Property Delegate. Basicamente ele permite que uma propriedade delegue o getter e o setter para uma classe externa. A sintaxe é essa:

var [nome] : [tipo] by [classe delegada]()

No nosso caso, vamos declarar a propriedade delegada do modelo dentro de uma Activity ou Fragment. Vai ficar assim:

private val model : PackageModel by viewModels()

No exemplo acima viewModels() é um property delegate que vem pronto do Kotlin.

Deste ponto em diante basta implementar as propriedades e métodos necessários

Flutter 2.5 - O que há de novo?

Danilo Barreto — Sat, 11 Sep 2021 00:19:54 +0000

Esse release foi realmente bem grande! Alguns números:

4600 issues encerradas
3932 PRs fechadas
252 contribuidores

(fonte flutter.dev)

Vamos ver algumas melhorias

Framework

Android Full Screen

Agora o Flutter oferece suporte à tela cheia no Android. Suporta os seguintes modos: Lean back, Immersive, Immersive Stick e Edge-to-Edge.

Material You

Suporte à nova versão do Android Material Design. Em breve vou liberar um novo artigo com as novidades!

Visual Studio Code

Update no plugin do Visual Studio Code inclui dois novos comandos para facilitar a instalação de dependências e dependências de desenvolvimento do Dart. Além disso tem um novo test runner ainda em preview, mas que logo deve substituir o atual.

Dart 2.14

Com a atualização do Flutter também chega uma atualização do Dart. Algumas mudanças são:

Lint

Agora ao criar o projeto já é criado um set de lints padrão, o que não era possível antes. Agora a análise com Lint ficou bem mais fácil e intuitiva.

Nova formatação

Vem com um novo padrão de formatação para permitir que o cascateamento de comandos fique mais claro. Só tenho a agradecer por esse item :)

Essas são as melhorias principais e as mais visíveis. Além delas houveram várias correções de bugs e melhorias de performance. Os detalhes podem ser visto no artigo oficial do flutter.dev.

Happy coding!

DEV Community: Danilo Barreto

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

Android ViewModel

Flutter 2.5 - O que há de novo?

Framework

Android Full Screen

Material You

Visual Studio Code

Dart 2.14

Lint

Nova formatação

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