Coder Legion - Recent posts tagged kotlin

⚒️Todas as funções do aplicativo!:

Sat, 31 Oct 2026 20:44:09 +0000

Versão do app:

A "UpdateActivity" apresenta as informações da versão instalada do Mulher Amparada, utilizando os dados diretamente do aplicativo instalado.

Ela exibe:

Ícone do app disfarçado
Nome do aplicativo
Versão instalada ("versionName")
Número da build ("versionCode")
Indicador visual de disponibilidade do sistema

A versão e a build são obtidas diretamente dos metadados do APK, garantindo que as informações exibidas correspondam à versão realmente instalada no dispositivo.

Botão de Pânico:

Botão de Pânico, com ligação ao 180 de forma direta no primeiro clique.

Proteção por Barulho:

Ative a proteção, faça barulho alto e ele liga para o 180.

caso ocorra alguma falha ou o aparelho da usuária não possua o sensor necessário, o aplicativo utiliza o microfone como alternativa. Ao detectar um barulho alto, a proteção é acionada.

>Sobre a proteção por palmas/barulho: Nota de Segurança: Uma vez ativada, a proteção permanecerá vigilante e reativará o microfone automaticamente após cada detecção e ligação pro 180. Isso garante que o aplicativo continue te protegendo caso a situação de risco persista. Para desligá-la por completo, você deve fazer isso manualmente no aplicativo após o término da situação de risco.

Balançar o Celular para Pedir Ajuda:

Ative e, ao chacoalhar o celular, ele liga para o 180.

Escurecimento por inclinação:

com isso, voce pode controlar o brilho da tela clicando em um botão..., porém, e tipo como se fosse o menor brilho do celular, e ai depois ele deixa a tela preta (nao com brilho e sim colocando a cor), (honestamente, antes aparecia as duas barras, agora elas se escondem!), e o efeito e vitalicio ate fechar e abrir o app!

>Vale lembrar que ele só funciona dentro da HubActivity!

Emergência:

Saindo dessa área, existem botões que abrem o aplicativo nativo do telefone nos números 190, 192 e 180.

Compartilhamento Rápido de Localização:

Além disso, existe um botão dentro do aplicativo que obtém a localização atual, monta um link do Google Maps com as coordenadas e abre uma conversa no WhatsApp do 180 com a mensagem preparada. O envio não é automático: é necessário apenas conferir a mensagem e tocar no botão de enviar.

Contatos de Confiança:

Além dos contatos de confiança, clicando no primeiro botão você seleciona e salva o contato. O botão abaixo envia um pedido de ajuda para ele.

e os contatos de confiança, quando são cadrastados eles também são criptografados!

Compartilhamento de metadados;

Ao pressionar o botão de emergência, um botao circular feito com compose aparece no canto inferior direito da tela. O aplicativo obtém a localização atual do dispositivo e abre o menu de compartilhamento do Android.

A mensagem contém:

Latitude e longitude;
Link para visualizar a localização no Google Maps;
Precisão da localização em metros;
Data e hora;
Fabricante e modelo do dispositivo;
Versão do Android;
Porcentagem da bateria.

A usuária pode escolher por qual aplicativo deseja compartilhar essas informações, como WhatsApp, SMS ou e-mail.

O compartilhamento não é enviado automaticamente para um contato específico. O usuário precisa escolher o aplicativo e confirmar o envio.

Vale lembrar que o compose é um overlay usandi a classe EmergencyOverlay, e a HubActivity chama essa classe!

🔐Área Protegida:

Se estiver cadastrado no celular, com Biometric Prompt junto com Device Credential e autenticação weak, pode desbloquear essa área com impressão digital, rosto, PIN, padrão, senha e outros métodos.

Sistema Cripto (Segurança do App)

O aplicativo possui um sistema próprio de armazenamento seguro que utiliza criptografia nativa do Android para proteger os dados armazenados.

Como funciona:

Quando um dado é salvo no app, ele é criptografado antes de ser armazenado.

O conteúdo armazenado não permanece em texto simples. Para recuperar o dado, o aplicativo utiliza a chave de criptografia protegida pelo Android e descriptografa o conteúdo somente quando necessário.

Tecnologias usadas:

AES-256
Criptografia simétrica utilizada para proteger os dados.

Android Keystore
Sistema do Android utilizado para proteger as chaves criptográficas.

Jetpack DataStore Preferences
Sistema utilizado para armazenar as informações persistentes do aplicativo.

O que cada função faz:

salvar(chave, valor) → criptografa e armazena o dado

carregar(chave) → recupera e descriptografa o dado

remover(chave) → remove um dado específico

limparTudo() → remove todos os dados armazenados

Segurança:

Os dados não são armazenados diretamente em texto simples.

A criptografia utiliza uma chave protegida pelo Android Keystore, enquanto o armazenamento persistente é realizado pelo Jetpack DataStore.

Dessa forma, o conteúdo protegido não fica diretamente legível no armazenamento do aparelho.

Calendário Menstrual:

Registre como dói cada dia e, com isso, o aplicativo monta um calendário.

Mapa:

Mostra um mapa da região e, quando a localização estiver disponível e autorizada, permite visualizar a posição atual.

Raio Seguro

Recurso de georreferenciamento que permite definir uma área segura e verificar se a usuária permanece dentro do raio estabelecido.

📌 Define a sua localização como centro da área segura e isso é fixo.
📏 Permite configurar o raio em metros.
🗺️ Utiliza OpenStreetMap para visualização do mapa.
📍 Compara a localização atual com a área definida.
⚠️ Em caso de saída do raio, exibe um alerta.
🆘 Disponibiliza a opção Pedir ajuda.
🔐 Os dados da área segura são armazenados de forma criptografada.
🚫 Não cria histórico de trajetos no aplicativo.
🌐 O carregamento dos mapas depende de conexão com a internet.

O recurso foi desenvolvido como uma ferramenta de apoio à segurança, permitindo que a própria usuária estabeleça os limites da área que considera segura.

Só funciona dentro da GeoActivity!

e quando ele detecta que a usuária saiu da área segura, ele mostra um popup com um botão vermelho, e ao clicar ele leva pro telefone nativo do sistema com o 190 já discado!

Diário criptografado:

Usando criptografia, a usuária poderá anotar o que quiser. Com a senha, ficará seguro e também não some, pois estará guardado, e é possivel baixar as páginas desse diário!, e ele tem suporte para markdown...

Tarefas:

O sistema permite categorizar tarefas em áreas como estudos, trabalho, pessoal e saúde.

As tarefas podem ser marcadas como concluídas para acompanhamento do progresso.

Todas as tarefas são salvas diretamente na classe cripto da usuária.

Os dados ficam armazenados localmente no dispositivo do usuário.

Gravador de voz:

Usando uma activity (uma tela) em kotlin, é possivel ter um gravador de voz no app, sendo possível registrar gravações que podem ser utilizadas pela própria usuária para documentação, além do que a usuária quiser, sempre usando permissoes android e com o consentimento da usuária!

GRAVAÇÕES — COMPORTAMENTO E METADADOS

1. DURANTE A GRAVAÇÃO

Ao tocar no botão de gravação:

• O aplicativo inicia a gravação de áudio pelo microfone.
• É criado temporariamente um arquivo .3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho).
• É registrado o horário exato de início da gravação.
• O nível da bateria é registrado.
• O acelerômetro começa a acompanhar os movimentos do aparelho e registra o maior valor de força G observado durante a gravação.
• Se as permissões de localização estiverem disponíveis, o aplicativo acompanha a localização e registra latitude, longitude, precisão e provedor.
• O arquivo original permanece temporário durante o processo.

2. AO ENCERRAR A GRAVAÇÃO

Quando a gravação é encerrada:

• É registrado o horário exato de encerramento.
• É calculado o SHA-256 do áudio original.
• O áudio é criptografado usando AES/GCM.
• O arquivo protegido recebe a extensão .enc.
• É calculado o SHA-256 do arquivo criptografado.
• É criado um arquivo separado .metadata.json contendo os metadados.
• Depois que a criptografia é concluída, o .3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho) original temporário é apagado do armazenamento privado do aplicativo.
• A gravação protegida e seus metadados aparecem na lista do aplicativo.

3. METADADOS GERADOS

TEMPO:

• created_at — timestamp UNIX do início.
• created_at_utc — início em UTC.
• closed_at — timestamp UNIX do encerramento.
• closed_at_utc — encerramento em UTC.
• last_modified — última modificação registrada pelo sistema.
• last_modified_utc — última modificação em UTC.
• ntp_synced — indicação relacionada à configuração de hora automática do Android.

INTEGRIDADE E CRIPTOGRAFIA:

• sha256_raw — SHA-256 do áudio original antes da criptografia.
• sha256_encrypted — SHA-256 do arquivo .enc.
• crypto_algorithm — AES/GCM/NoPadding, 256-bit.
• key_provider — AndroidKeyStore.

LOCALIZAÇÃO:

• gps_latitude — latitude registrada.
• gps_longitude — longitude registrada.
• gps_accuracy — precisão estimada em metros.
• location_provider — provedor utilizado, como GPS ou rede.

DISPOSITIVO:

• device_model — modelo do aparelho.
• device_brand — fabricante/marca.
• android_version — versão do Android.
• api_level — nível da API.
• device_hash — identificador derivado do Android ID e protegido por SHA-256.

SENSORES E AMBIENTE:

• max_g_force — maior aceleração registrada pelo acelerômetro durante a gravação.
• battery_level — nível da bateria no início da gravação.

ARQUIVO:

• file_name — nome do arquivo criptografado.
• file_size_bytes — tamanho do arquivo .enc.
• file_format — formato original do áudio, 3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho)/AMR-NB.
• metadata_version — versão do formato dos metadados.

4. O QUE ACONTECE AO TOCAR EM "DOWNLOAD"

O botão de download NÃO simplesmente copia o .enc.

O aplicativo:

1. Localiza o arquivo .enc protegido.
2. Descriptografa temporariamente o conteúdo.
3. Cria um arquivo .3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho) temporário no cache do aplicativo.
4. Copia esse áudio para a pasta Downloads do Android.
5. No Android 10 ou superior, utiliza o MediaStore.
6. Em versões antigas, utiliza a pasta pública Downloads.
7. Depois da cópia, o arquivo .3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho) temporário utilizado durante o processo é apagado.
8. O arquivo .enc original continua protegido dentro do aplicativo.

5. IMPORTANTE SOBRE O JSON

O .metadata.json é um arquivo separado do áudio.

Por exemplo:

Downloads:

rec_1787821440.3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho)

rec_1787821440.metadata.json

O .3gp, (ou um arquivo 3ga, ou outro arquivo, isso varia conforme o aparelho) é o áudio reproduzível.

O .metadata.json contém as informações técnicas associadas àquela gravação.

6. IMPORTANTE SOBRE A LOCALIZAÇÃO

A localização não é garantida em todas as gravações.

Se a permissão de localização estiver concedida e o Android fornecer uma localização válida, os campos de localização são preenchidos.

Caso contrário, eles ficam como null.

7. IMPORTANTE SOBRE OS METADADOS

Esses metadados são registros técnicos produzidos pelo aplicativo. Eles podem ajudar a documentar como e quando uma gravação foi criada, mas a existência de hashes, localização ou timestamps, por si só, NÃO garante validade jurídica ou prova que um fato ocorreu.

O SHA-256 permite verificar se os bytes de um arquivo correspondem ao conteúdo anteriormente registrado, enquanto os dados de localização, sensores e horário dependem dos recursos e configurações do próprio aparelho.

Meus arquivos:

Dentro do aplicativo, o Gerenciador de Arquivos do Mulher Amparada funciona como um visualizador. Ele permite navegar pelas pastas e, ao selecionar um arquivo, utiliza o mecanismo do Android para abrir um seletor de aplicativos compatíveis com aquele tipo de arquivo, permitindo que a usuária escolha um aplicativo para visualizá-lo ou executá-lo.

O aplicativo possui um único botão para alternar entre os diferentes tipos de armazenamento disponíveis, seguindo uma sequência entre:

Armazenamento interno → cartão SD → dispositivo externo (como pendrive via USB OTG) → armazenamento interno.

O acesso varia de acordo com o tipo de armazenamento:

Armazenamento interno e cartão SD: utilizam a permissão de Acesso a todos os arquivos, quando concedida pelo Android.
Dispositivos externos, como pendrives conectados por USB OTG: utilizam o SAF (Storage Access Framework), mecanismo oficial do Android para acesso a documentos e dispositivos de armazenamento externos autorizados pela usuária.

>O Gerenciador de Arquivos (que apenas visualiza) não acessa os arquivos internos do Gravador de Voz do Mulher Amparada nem os dados ou recursos internos de outras funcionalidades do aplicativo. Ele trabalha com arquivos que já estão disponíveis nos armazenamentos do dispositivo e que podem ser acessados pelos mecanismos de armazenamento autorizados pelo Android.

>Porém, quando eu digo que o Gerenciador de arquivos apenas visualiza, eu quero dizer que ele nao faz operações de arquivos, mas quando clica em um arquivo, ele abre um seletor de apps, ajudando muito para a coleta de evidências!, porém, se a usuária selecionar um app por esse seletor e perder os dados, o desenvolvedor não se responsabiliza!

Arquivo seguro:

Ao tocar neste botão, o app te leva para uma activity que você pode adicionar arquivos usando o storage acess framework (S.A.F) e ele criptografa com a classe cripto, e você pode descriptografar ou excluir!

Navegador:

A navegação para o Google é feita diretamente pelo código usando window location replace(), sem disponibilizar o endereço como um link na interface. O aplicativo também não implementa um sistema próprio de registro de histórico de navegação, (ou pelo ou menos eu não coloquei na página)

>O aplicativo possui um navegador interno. A navegação para o Google é feita diretamente pelo código usando link na MainActivity sem disponibilizar o endereço como um link na interface. O aplicativo também não implementa um sistema próprio de registro de histórico de navegação, (ou pelo ou menos eu não coloquei na página)

>MainActivity > Google > pesquisa/link do Google

>Voltar > fecha a MainActivity

Considerações finais:

e os audios do gravador de voz também são criptografados com a classe Cripto

e o recurso de proteção ppr barulho, chacalhoar o celular e escurecer a tela, tem como ativar e desativar!

todas as activitys tem a flag secure!

e no application do AndroidManifest do app tem allowBackup="false"

❤️🩹Área do amparo:

A Área do amparo também utiliza o sistema "BiometricPrompt", com autenticação por "BIOMETRIC_WEAK" e "DEVICE_CREDENTIAL".

Carteirinha de reivindicação dos direitos de transporte das mulheres:

Após o desbloqueio, é exibida uma carteirinha informativa que não constitui um documento oficial do governo. Ao tocá-la, a usuária é direcionada para uma página destinada à apresentação à equipe de motoristas do transporte, para solicitar o desembarque em um ponto mais seguro durante o período noturno, quando a legislação aplicável permitir.

Carteirinha do gesto de ajuda:

Também há uma segunda carteirinha que, ao ser selecionada, direciona para um tutorial sobre como realizar o gesto internacional de combate à violência.

O gesto é um sinal silencioso de pedido de ajuda e pode ser utilizado em diferentes situações de violência. Ele não é exclusivo de mulheres: qualquer pessoa, independentemente de ser homem ou mulher, pode realizá-lo quando precisar sinalizar que necessita de ajuda.

🌐 Site oficial: https://mulher-amparada.github.io/mulher-amparada-app/

💻 Repositório GitHub: https://github.com/mulher-amparada/mulher-amparada-app

⚙️Decisões técnicas:

lembre-se que hoje em dia uso github para compilar os apps e o a16 5g da samsung, então ele nao mata o processo de compilação mais!

Sobre o WebView do app:

e APENAS A FUNÇÃO DE NAVEGADOR, AS OUTRAS SÃO OU FEITAS COM COMPOSE OU FEITAS COM XML, usa este webview:


val settings =  
        webView.settings  

settings.cacheMode =
    android.webkit.WebSettings.LOAD_DEFAULT

settings.loadsImagesAutomatically =
    true

settings.blockNetworkImage =
    false

settings.databaseEnabled =
    true

settings.displayZoomControls =
    false

settings.builtInZoomControls =
    false

settings.setSupportZoom(
    false
)

settings.textZoom =
    100

settings.defaultTextEncodingName =
    "UTF-8"

settings.mixedContentMode =
    android.webkit.WebSettings.MIXED_CONTENT_NEVER_ALLOW

    webView.overScrollMode =  
        View.OVER_SCROLL_NEVER  


    webView.isVerticalScrollBarEnabled =  
        false  


    webView.isFocusable =  
        true  


    webView.isFocusableInTouchMode =  
        true  


    webView.setOnFocusChangeListener {  
            _,  
            _ -> 
    }  


    webView.isHorizontalScrollBarEnabled =  
        false  


    webView.scrollBarStyle =  
        View.SCROLLBARS_INSIDE_OVERLAY  


    settings.javaScriptEnabled =  
        true  


    settings.mediaPlaybackRequiresUserGesture =  
        false  


    settings.domStorageEnabled =  
        true  


    settings.setGeolocationEnabled(  
        true  
    )  


    settings.allowFileAccess =  
        true  


    settings.allowContentAccess =  
        true  


    settings.allowFileAccessFromFileURLs =  
        false  


    settings.allowUniversalAccessFromFileURLs =  
        false  


    settings.javaScriptCanOpenWindowsAutomatically =  
        false  


    settings.setSupportMultipleWindows(  
        false  
    )


onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        val urlAtual = webView.url

        if (urlAtual != null && urlAtual.contains("google.com")) {
            webView.clearHistory()
            finish()
        } else {
            if (webView.canGoBack()) {
                webView.goBack()
            } else {
                isEnabled = false
                onBackPressedDispatcher.onBackPressed()
            }
        }
    }
})

Por que, na FileActivity, o botão para trocar o tipo de armazenamento é unificado em um só?

O botão foi unificado para tornar a navegação entre os diferentes tipos de armazenamento mais simples e organizada, especialmente em situações de pânico ou urgência.

Em vez de apresentar vários botões separados, o mesmo botão alterna sequencialmente entre os armazenamentos disponíveis, seguindo o ciclo 1 → 2 → 3 → 1.

Essa escolha também foi pensada como uma forma de incentivar uma vistoria sequencial. Ao passar por cada armazenamento antes de retornar ao primeiro, a usuária é estimulada a verificar diferentes locais onde arquivos importantes podem estar, reduzindo a possibilidade de deixar algum armazenamento sem ser conferido por distração ou pressa.

é tipo assim:

armazenamento interno, para trocar para cartao sd, clica no botão e troca o icone, mas aí para voltar atrás, tem passar pelo cartao sd e pelo pendrive para só então voltar para o armazenamento interno

Por que o WebView do app não trata "intent" para abrir outros aplicativos?

Por questões de segurança e privacidade.

Permitir que páginas dentro do WebView utilizem "intent" livremente para abrir outros aplicativos ou executar ações externas poderia aumentar os riscos de comportamentos inesperados, abuso de links e rastreamento de usuários.

Links também podem conter parâmetros de rastreamento, redirecionamentos e outros mecanismos capazes de identificar ou acompanhar a navegação.

Por isso, o WebView mantém esse comportamento limitado. A exceção é a tela de aplicativos, que possui uma função específica e um fluxo controlado pelo próprio app.

Sobre o tema escuro, o conforto visual e a discrição:

O aplicativo oferece suporte a ícones monocromáticos, modo claro e modo escuro. O ícone do aplicativo também se adapta automaticamente ao tema selecionado, enquanto os sites acompanham a configuração, alterando seus fundos e elementos visuais conforme o modo ativo.

E o site do github pages usa essa estrutura (os nomes dos arquivos podem varias):

<link rel="stylesheet" href="claro.css" media="(prefers-color-scheme: light)">
<link rel="stylesheet" href="escuro.css" media="(prefers-color-scheme: dark)">

🔗 Deep Link do aplicativo:

O aplicativo utiliza um Deep Link personalizado para permitir que o Android abra diretamente o Mulher Amparada:

com.mulheres://abrir

Esse endereço utiliza o identificador do aplicativo ("com.mulheres") como esquema de URI. Ao acessar o link em um dispositivo Android que possui o aplicativo instalado, o sistema pode encaminhar a abertura diretamente para o aplicativo, sem a necessidade de um site ou domínio externo.

O esquema é registrado no "AndroidManifest.xml" por meio de um "intent-filter":

Assim, o endereço: com.mulheres://abrir funciona como uma forma direta de solicitar a abertura do aplicativo Mulher Amparada. e temos um botão no index.html no site do github pages que leva pro app usando esse link também! 📦Packpage do repositório no github: ele é um packpage focado para quem quiser divulgar o projeto! ele contém: pngs de divulgação com link, texto e qr do site do giithub pages; o proprio qr do site do giithub pages; banners do projeto, tanto png, tanto um código para html; posters de divulgação para o projeto; icones para sites e para usos no geral, tanto o do mulher amparada tanto o ic_launcher do app, versão normal e monocromático; o ícone do mulher-amparada-bot >APENAS PARA AS USUÁRIAS!: Ao indicar o projeto para uma mulher em situação de risco, priorize o compartilhamento do QR Code impresso ou na tela, em vez de enviar links de texto por mensagens (como WhatsApp ou SMS). Por que o QR Code? Links de texto deixam rastros fáceis de serem interceptados por agressores que monitoram o celular da vítima. >Como agir: Se for imprimir cartazes ou banners, certifique-se de que o QR Code está visível e em alta resolução. Isso permite que a usuária aponte a câmera e acesse o projeto diretamente, minimizando o histórico de digitação e mensagens trocadas. a pessoa instala pelo github releases! e quem publica e atualiza essa release é o proprio workflow! 📦link do packpage! 🌐 Site oficial: https://mulher-amparada.github.io/mulher-amparada-app/ 💻 Repositório GitHub: https://github.com/mulher-amparada/mulher-amparada-app

Why BasicTextField Fails at Scale — And How I Build Kortex

Mon, 19 Oct 2026 14:55:34 +0000

Reaching sub-millisecond input latency on 100K-line files using Kotlin Multiplatform, Skia, and Virtualized canvas layers

If you have ever tried building a serious text or code editor in Jetpack Compose or Compose Multiplatform using BasicTextField, you already know where the ceiling is.

Declarative UI frameworks excel at forms, chat inputs, and short documents. However, the moment you load a 50,000-line source file, attach real-time syntax highlighting, spawn multiple cursors, and scroll rapidly at 120Hz, the standard composable pipeline starts gasping for air. Recreating AnnotatedString instances on every keystroke, measuring thousands of nested layout nodes, and allocating objects on the hot rendering path inevitably leads to garbage collection pauses and dropped frames.

To solve this properly across Desktop (JVM), Android, iOS, and WebAssembly (Wasm-JS), I built Kortex — an open-source, hardware-accelerated code and text editor engine for Kotlin Multiplatform.

Here is a deep dive into the architecture behind Kortex, why it bypasses standard Compose text components entirely, and how it achieves locked 60+ FPS rendering on massive documents.

1. The Core Philosophy: Zero Composable-Per-Line Overhead

In a traditional declarative list (like a LazyColumn of text rows), every visible line is a separate composable node with its own layout pass, modifier chain, and composition state. When you scroll horizontally and vertically simultaneously, or render cross-line selections and diagnostic squiggles, coordinating state across individual row composables becomes an intractable bottleneck.

Kortex treats the entire editor viewport as a single hardware-accelerated surface.

Instead of delegating text rendering to Compose UI nodes, Kortex drops down directly to Skia (via Skiko) using a platform-specific SkiaCanvas abstraction:

// JVM, iOS, and WasmJS implementation
@Composable
actual fun SkiaCanvas(
    modifier: Modifier,
    onRender: (canvas: Canvas, width: Int, height: Int) -> Unit
) {
    Box(
        modifier = modifier.drawWithCache {
            val width = size.width.toInt()
            val height = size.height.toInt()

            onDrawBehind {
                if (width <= 0 || height <= 0) return@onDrawBehind

                drawIntoCanvas { canvas ->
                    onRender(canvas.nativeCanvas, width, height)
                }
            }
        }
    )
}

On Android, SkiaCanvas binds directly to an embedded SkikoSurfaceView and SkiaLayer. State changes that require repaints (such as cursor blinking or text input) trigger frame updates via SideEffect { surfaceView?.scheduleFrame() }, guaranteeing identical 60+ FPS Skia rendering semantics across all four targets without forcing recompositions across the entire Compose UI tree.

The Layered Rendering Pipeline

Every frame inside EditorCanvas is composed of lightweight, pre-calculated Layer primitives rendered in a strict Z-order pass:

Background Canvas (BackgroundLayer)
Gutter Background (gutterBackgroundLayer)
Unified Active Line Highlight (HighlightedLineLayer rendered across the full viewport width)
Isolated Gutter Elements (GutterLineLayer, FoldingMarkersLayer, GutterSeparatorLayer clipped to gutterWidth)
Code Viewport Matrix Shift & Clip (nativeCanvas.translate(gutterWidth, 0f) clipped to code width)
Underlay Guides & Markers (ColumnRulerLayer, OccurrencesHighlightLayer)
Multi-Selection Regions (SelectionLayer)
Syntax-Highlighted Text Paragraphs (TextContentLayer)
Diagnostic Sine-Wave Squiggles (DiagnosticsLayer)
Blinking Multi-Carets (CaretLayer)

Because the line-number gutter is isolated through its own clip bounds and the code area is shifted with matrix translations, horizontal code scrolling never bleeds into the gutter, and the entire viewport paints in a single unified GPU pass.

2. Backed by Krope: Logarithmic Text Mutations

A fast renderer is useless if typing a character copies a 10MB String in memory.

Under the hood, Kortex is powered by Krope, a thread-safe, persistent Red-Black Rope text buffer built specifically for high-throughput text processing.

Logarithmic Edits: Insertions, deletions, and range replacements execute in $O(\log N)$ time with structural sharing.
Immutable Snapshots: The UI and background analysis pipelines read from an immutable TextSnapshot tied to a monotonic TextRevision.
Delta Position Mapping: When a batch edit occurs (for example, typing simultaneously with 15 active cursors), Kortex sorts operations in descending document order so earlier edits never invalidate the offsets of later ones. Once the rope commits the transaction, it returns a TextEdit.Data delta, and EditorEngine maps every surviving selection and caret through that delta mathematically:

private fun mapSingleDelta(position: TextPosition, delta: TextEdit.Data.Single): TextPosition {
    val start = delta.startPosition
    val oldEnd = delta.oldEndPosition
    val newEnd = delta.newEndPosition

    return when {
        position < start -> position
        position in start..oldEnd -> newEnd
        else -> {
            val lineDelta = newEnd.line - oldEnd.line
            when (position.line) {
                oldEnd.line -> {
                    val colDelta = newEnd.column - oldEnd.column
                    TextPosition(line = position.line + lineDelta, column = position.column + colDelta)
                }
                else -> TextPosition(line = position.line + lineDelta, column = position.column)
            }
        }
    }
}

For structural line operations like MoveLineUp and MoveLineDown (Alt + Up/Down), calculating position via delta projection alone would snap the caret to the edge of the replaced range. Kortex resolves this by supporting explicit targetSelections inside EditorCommand.ApplyText, enabling line swaps to carry their carets and selections to adjacent lines without caret drift.

3. Killing GC Pauses with Bounded Native LRU Caches

Skia objects like Paragraph, TextLine, and Paint wrap native C++ resources. Allocating and destroying them on every 16ms frame (or 8ms on 120Hz ProMotion displays) quickly overwhelms the memory allocator.

Kortex solves this with a custom thread-safe LruCache extending CloseableResource. Whenever an item is evicted from the cache—or when the editor composable leaves the composition tree—its underlying native Skia pointer is deterministically closed:

internal class CodeParagraphCache(capacity: Int = 1000) : LruCache<CodeParagraphCache.Key, Paragraph>(capacity) {
    data class Key(
        val line: Int,
        val text: String,
        val tokens: List<Token>,
        val font: EditorFont,
        val syntaxTheme: SyntaxTheme,
    )

    override val factory: Key.() -> Paragraph = {
        // Builds and lays out the Skia Paragraph only on a cache miss
        ...
        builder.build().apply { layout(Float.MAX_VALUE) }
    }
}

Crucially, this zero-allocation philosophy extends to input gestures. Dragging the mouse to select text calls getOffsetAtCoordinate on every pixel change. Re-parsing a Skia paragraph on each pointer move would create unacceptable jank. In Kortex, EditorFont manages an internal measurementParagraphCache:

private val measurementParagraphCache = object : LruCache<String, Paragraph>(capacity = 128) {
    override val factory: String.() -> Paragraph = {
        val textToMeasure = this
        TextStyle().apply {
            this.fontFamilies = arrayOf(*Emails are not allowed*lyName)
            this.fontSize = *Emails are not allowed*
        }.use { baseTextStyle ->
            ParagraphStyle().apply {
                this.maxLinesCount = 1
                this.textStyle = baseTextStyle
            }.use { style ->
                buildParagraph(style) {
                    pushStyle(baseTextStyle)
                    addText(textToMeasure)
                    popStyle()
                }.use { builder ->
                    builder.build().apply { layout(Float.MAX_VALUE) }
                }
            }
        }
    }
}

During continuous 120 FPS scrolling, cursor blinking, or rapid mouse selection, Kortex hits its bounded caches with near-100% hit rates, resulting in zero native allocations on the render loop.

4. Viewport Virtualization & Logarithmic Code Folding (`FoldMap`)

How do you render a 200,000-line file when 50 different functions and classes are collapsed?

Iterating through lines to check which ones are hidden would turn rendering into an $O(N)$ operation. Instead, Kortex compiles collapsed regions into an immutable FoldMap—a sorted, merged interval table storing cumulative hidden line counts and visual thresholds:

internal data class Interval(
    val startLine: Int,
    val endLine: Int,
    val hiddenCount: Int,
    val cumulativeHiddenBefore: Int,
    val visualStartThreshold: Int,
)

Converting between a Visual Line (what the user sees on screen) and a Document Line (the actual index in the Rope buffer) is a binary search over active intervals running in $O(\log K)$ time, where $K$ is the number of folded blocks:

Viewport.of(...) calculates the exact visible visual line slice (startVisualLine..endVisualLine) from scrollY and lineHeight.
Each visible line is mapped to its true document line via foldMap.visualToDocumentLine(visualLineIndex).
Collapsed lines are completely culled before Skia ever touches them.

5. Pure Unidirectional MVI & Smart Undo/Redo Coalescing

UI components in Kortex never mutate state directly. The entire :kortex-core module is completely headless (zero Compose dependencies) and operates as a deterministic state machine:

(EditorState, EditorAction) -> EditorResult(newState, EditorCommand?)

Pure Reducers: CaretReducer, SelectionReducer, EditReducer, and ViewportReducer compute next states purely in memory.
Multi-Cursor Normalization: Every time cursors move or expand, Selection.normalize(...) sorts all active selections and automatically merges overlapping or touching ranges while preserving selection direction (FORWARD vs. BACKWARD), surrogate pairs (emoji), and stickyColumn offsets.
Sliding-Window Undo/Redo: HistoryManager records forward and inverse TextOperation.Data commands and automatically merges contiguous single-line insertions or deletions if they occur within a 700ms window—restoring exact multi-cursor positions when undone.

6. Full IDE Tooling: Async Analysis, Squiggles & Hierarchical Themes

On top of the plain-text :kortex-core engine sits :kortex-code and :kortex-code-compose, turning the editor into a complete IDE component.

Debounced Coroutine Pipelines

CodeEditorEngine binds to a pluggable LanguageAnalysisService using Kotlin Coroutine Flows on Dispatchers.Default:

Tokenization (TokenProvider): Debounced at 50ms, dropping stale snapshots via distinctUntilChangedBy(TextSnapshot::revision) and mapLatest. Existing folding regions and symbol occurrences are preserved during token updates.
Diagnostics (DiagnosticsProvider): Debounced at 300ms, feeding DiagnosticsLayer to draw procedural sine-wave/zigzag paths directly under erroneous tokens.
Hover Documentation (DocumentationProvider): Debounced at 250ms, resolving documentation for the symbol under the primary caret and updating CodeEditorState.documentation.
IntelliSense (CompletionProvider): Floating popup anchored to the active caret's visual coordinates with keyboard navigation (Up, Down, Tab/Enter, Escape).

Hierarchical Token Theming

Inspired by TextMate and VS Code scopes, SyntaxTheme resolves token colors hierarchically using dot-separated fallbacks. If your lexer emits keyword.control and the active theme only defines a color for keyword, Kortex walks up the scope tree automatically:

val syntaxTheme = SyntaxTheme.build(defaultText = Color(0xFFABB2BF)) {
    put(TokenType.KEYWORD.name, Color(0xFFC678DD))
    put(TokenType.KEYWORD_CONTROL.name, Color(0xFFE06C75)) // Overrides "keyword"
    put(TokenType.FUNCTION.name, Color(0xFF61AFEF))
    put(TokenType.STRING.name, Color(0xFF98C379))
}

Getting Started in 30 Seconds

Kortex is published on Maven Central and divided into four modular artifacts so you only pull what you need:

dependencies {
    implementation("io.github.numq.kortex:core:1.1.0")         // Headless engine
    implementation("io.github.numq.kortex:core-compose:1.1.0") // Plain text Skia editor
    implementation("io.github.numq.kortex:code:1.1.0")         // Code analysis engine
    implementation("io.github.numq.kortex:code-compose:1.1.0") // Full IDE Composable
    implementation("io.github.numq.krope:text:1.1.1")          // Rope text buffer
}

Embedding a full-featured code editor in your Compose Multiplatform app takes just a few lines:

@Composable
fun IdeEditorScreen() {
    val scope = rememberCoroutineScope()

    val buffer = remember {
        RopeTextBuffer(
            initialText = "fun main() {\n    println(\"Hello, Kortex!\")\n}",
            initialLineEnding = TextLineEnding.LF,
            initialEncoding = Encoding.UTF8,
            enablePooling = true
        )
    }

    val editorEngine = remember(buffer) { EditorEngine(scope = scope, buffer = buffer) }
    val codeEngine = remember(editorEngine) {
        CodeEditorEngine(
            scope = scope,
            engine = editorEngine,
            analysisService = myLanguageAnalysisService
        )
    }

    val font = remember {
        val typeface = FontMgr.default.matchFamilyStyle("JetBrains Mono", FontStyle.NORMAL)
            ?: Typeface.makeEmpty()
        EditorFont(typeface = typeface, size = 14f, lineSpacing = 1.25f)
    }

    DisposableEffect(font) {
        onDispose {
            font.close()
        }
    }

    val theme = rememberCodeEditorTheme()

    KortexCodeEditor(
        engine = codeEngine,
        font = font,
        theme = theme,
        columnRuler = 80,
        modifier = Modifier.fillMaxSize()
    )
}

Out of the box, you get Alt + Click multi-cursors, Ctrl/Cmd + D next-occurrence selection, code folding, smart indentation, line moving (Alt + Up/Down), comment toggling (Ctrl/Cmd + /), right-click context menus, and native desktop scrollbar adapters.

Explore the Source Code

Both Kortex and Krope are 100% open-source under the Apache 2.0 License. Whether you are building a developer tool, a Markdown note-taking app, a database query console, or a full multiplatform IDE, I would love for you to try it out and share your feedback!

Kortex: github.com/numq/kortex
Krope: github.com/numq/krope

Kempo: Real-Time Audio Time-Stretching, Pitch-Shifting, and Formant Control in Pure KMP

Wed, 14 Oct 2026 07:01:23 +0000

Zero-allocation streaming, phase-locked clarity, and multichannel spatial coherence across JVM, Android, iOS, and WebAssembly.

Whether you are building a podcast player with variable playback speed, a music practice app that slows down a complex guitar solo without dropping the tuning, a real-time voice modulator, or a spatial audio engine for a game, you eventually hit the same fundamental challenge: decoupling time from pitch.

In raw digital audio, playback speed and pitch are locked together. Play a buffer twice as fast, and the pitch jumps up a full octave. Slow it down, and everything drags into a muddy baritone.

Breaking that link—while keeping drums punchy, vocals natural, and the stereo image intact—requires a dedicated Digital Signal Processing (DSP) engine.

Meet Kempo (io.github.numq:kempo): an open-source, pure Kotlin Multiplatform audio time-stretching and pitch-shifting library built for studio-grade acoustic transparency and sub-millisecond real-time streaming across JVM, Android, iOS, and WebAssembly (Wasm/JS).

What Kempo Brings to Your Audio Stack

Kempo is designed to be drop-in simple for high-level application code while exposing full, granular control for low-level audio threads:

Independent Time, Pitch, and Formant Control: Speed up or slow down audio (0.25x to 3.0x and beyond), transpose musical pitch in semitones, and shift vocal timbre independently.
Zero-Allocation Real-Time Streaming: Once configured, the block-by-block processing loop allocates 0 bytes on the heap, eliminating Garbage Collection pauses on high-priority audio threads.
Vertical Harmonic Phase-Locking: Keeps transients crisp and eliminates the hollow, "underwater" phasing artifacts common in basic time-stretchers.
Multichannel & 5.1 Surround Coherence: Preserves exact inter-channel phase relationships across stereo and surround tracks so the soundstage never collapses.
Sample-Accurate Offline Rendering: Built-in pre-roll warm-up, algorithmic latency compensation, and automatic overlap-add tail flushing.
Built-In PCM-16 Serialization: Convert raw little-endian or big-endian WAV/PCM byte arrays directly into normalized floating-point tracks and back.

How Kempo Keeps Audio Crisp (Without the Artifacts)

If you have ever used a naive time-stretching algorithm, you probably recognize three classic audio defects: smeared drum hits, "chipmunk" vocals, and a collapsing stereo field. Kempo solves all three at the engine level.

1. Eliminating Transient Smearing with Vertical Phase-Locking

Standard phase vocoders split audio into hundreds of narrow frequency bins and advance the phase of each bin over time. Because each bin is updated in isolation, the natural harmonic alignment between a fundamental note and its overtones quickly drifts apart. Percussive attacks lose their snap, and instruments sound phasey and diffuse.

Kempo continuously analyzes the smoothed spectral energy contour of each frame to locate prominent spectral peaks. Instead of letting neighboring bins drift, Kempo performs vertical phase-locking—anchoring the phase trajectories of surrounding frequency bins to their dominant harmonic peaks. Harmonics move together as a unified acoustic event, keeping transients tight.

When stretching audio to extreme lengths (beyond 2.0x), Kempo automatically transitions into controlled stochastic phase dispersion, preventing the metallic ringing that usually plagues ultra-slow playback.

2. Fixing the "Chipmunk" Effect with Formant Decoupling

When you pitch a human voice up by +5 semitones, you aren't just raising the pitch of the vocal cords—you are also shrinking the perceived size of the singer's vocal tract. The result is the notorious "chipmunk" effect (or the "monster" effect when pitching down).

In Kempo, pitch and vocal timbre (formants) are decoupled. Kempo extracts the spectral envelope of the signal and allows you to shift or lock formants independently of the musical transposition:

Natural Pitch Shifting: Enable formant compensation (compensatePitch = true) to keep a singer's vocal tract resonance anchored while changing their melody.
Creative Voice Design: Shift formants up or down while keeping pitch at 0 st to transform the character and age of a voice without changing the note being sung.

3. Preserving Stereo Width and 5.1 Surround Imaging

Our ears localize sound in space by detecting tiny timing and phase differences between the left and right channels. If an audio processor stretches the Left and Right channels independently, their relative phases drift apart—causing the stereo image to wobble and center-panned vocals to hollow out when downmixed.

Kempo processes multichannel audio coherently. At every frequency band, it identifies the dominant channel and locks the Inter-channel Phase Differences (IPD) of all remaining channels to that reference. Whether you are processing a stereo master or a discrete 6-channel 5.1 surround mix, panning stays locked and center dialogue remains phase-aligned.

Getting Started

Kempo is published on Maven Central. Add the dependency to your build.gradle.kts:

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation("io.github.numq:kempo:1.0.0")
        }
    }
}

Or for a single-platform JVM/Android module:

dependencies {
    implementation("io.github.numq:kempo:1.0.0")
}

1. The One-Liner: Offline Track Processing

If you have raw 16-bit PCM bytes (from a WAV file, network stream, or microphone recording) and want to stretch or transpose them in a background coroutine, PcmConverter and AudioTrack handle the entire pipeline in a few lines:

import io.github.numq.kempo.PcmConverter

// 1. Decode interleaved 16-bit PCM bytes into a normalized [-1.0f, 1.0f] AudioTrack
val track = PcmConverter.fromPcm16(
    bytes = rawWavBytes,
    channels = 2,
    sampleRate = 44100f,
    isLittleEndian = true
)

// 2. Speed up by 25%, pitch up by 3 semitones, keep natural formants
val stretchedTrack = track.stretch(
    timeRatio = 1.25f,
    pitchSemitones = 3.0f,
    formantSemitones = 0.0f
)

// 3. Convert back to 16-bit PCM bytes for playback or file export
val outputBytes = PcmConverter.toPcm16(stretchedTrack, isLittleEndian = true)

2. Zero-Allocation Real-Time Streaming

Real-time audio callbacks operate under strict deadlines. Allocating arrays or objects inside the render loop will eventually trigger the garbage collector and cause audible clicks.

KempoStretch pre-allocates all ring buffers, FFT plans, twiddle factors, and spectral workspaces upfront during presetDefault() or configure(). Inside your audio callback, process() mutates pre-allocated buffers in place:

import io.github.numq.kempo.KempoStretch
import kotlin.math.max

class LiveAudioProcessor(
    channels: Int = 2,
    sampleRate: Float = 48000f
) {
    private val stretch = KempoStretch().apply {
        presetDefault(channels, sampleRate)
    }

    val outBlockSize: Int = stretch.defaultInterval
    private val outBuffer = Array(channels) { FloatArray(outBlockSize) }

    fun updateParameters(pitchSemitones: Float, formantSemitones: Float) {
        stretch.setTransposeSemitones(pitchSemitones)
        stretch.setFormantSemitones(formantSemitones, compensatePitch = true)
    }

    // Safe for high-priority audio threads: 0 B heap allocations
    fun processFrame(
        inputChannels: Array<FloatArray>,
        playbackSpeed: Float
    ): Array<FloatArray> {
        val inSamples = max(1, (outBlockSize * playbackSpeed).toInt())
        stretch.process(
            inputs = inputChannels,
            inputSamples = inSamples,
            outputs = outBuffer,
            outputSamples = outBlockSize
        )
        return outBuffer
    }
}

Need to support interactive scrubbing on a timeline without clicks or phase resets? Use stretch.seek() before resuming playback to pre-seed the internal phase accumulators with the audio frames right before the new cursor position:

val seekPreRoll = minOf(stretch.seekLength(), targetSampleIndex)
stretch.seek(
    inputs = track.channels,
    inputSamples = seekPreRoll,
    playbackRate = 1.0,
    inputOffset = (targetSampleIndex - seekPreRoll).coerceAtLeast(0)
)

3. Sample-Accurate Offline Rendering with `exact()`

When rendering an audio clip for a DAW timeline or a game asset pipeline, you often need the output buffer to match an exact target sample count—without leading silence from the STFT window latency or cut-off reverb tails at the end.

KempoStretch.exact() automates the entire offline lifecycle: it calculates the required pre-roll (outputSeekLength), warms up the vocoder state (outputSeek), processes the body of the track, and flushes the final synthesis tails (flush):

import io.github.numq.kempo.KempoStretch
import kotlin.math.roundToInt

fun renderExactClip(
    input: Array<FloatArray>,
    sampleRate: Float,
    timeRatio: Float,
    pitchSemitones: Float
): Array<FloatArray> {
    val channels = input.size
    val inSamples = input[0].size
    val outSamples = (inSamples / timeRatio).roundToInt().coerceAtLeast(1)
    val output = Array(channels) { FloatArray(outSamples) }

    val stretch = KempoStretch().apply {
        presetDefault(channels, sampleRate)
        setTransposeSemitones(pitchSemitones)
    }

    stretch.exact(
        inputs = input,
        inputSamples = inSamples,
        outputs = output,
        outputSamples = outSamples
    )
    return output
}

4. Custom Frequency Mapping & Tonality Limits

For experimental sound design, spectral effects, or specialized speech conditioning, Kempo lets you bypass standard semitone math entirely:

Tonality Limits: When transposing speech or vocals up, multiplying high-frequency sibilance ("s" and "sh" sounds) can make them sound lispy or artificial. Passing a tonalityLimit to setTransposeSemitones(semitones, tonalityLimit) transitions the upper spectrum from multiplicative harmonic scaling to a clean linear shift.
Custom Transfer Functions: Pass any lambda to setFreqMap to warp normalized frequencies [0.0f, 0.5f] non-linearly:

stretch.setFreqMap { normalizedFreq ->
    // Custom non-linear spectral warping
    (normalizedFreq * 1.15f).coerceIn(0f, 0.5f)
}

Engineered for Speed in Pure Kotlin

Writing high-throughput DSP in pure Kotlin without falling back to platform-specific C/C++ libraries requires careful attention to memory layout and CPU cache locality:

Flat Power-of-Two Ring Buffers (MultiChannelBuffer): Instead of nested object arrays or modulo arithmetic, Kempo backs all channels with a single flat FloatArray. Wrap-around indices are resolved via bitwise masks ((head + offset) and mask), and overlap-add accumulation uses 4x unrolled loops.
In-Place Mixed-Radix FFT (FastFft & ModifiedRealFFT): Supports radix-2, radix-3, radix-4, and composite window sizes with precomputed twiddle tables. Real signals are evaluated on a half-bin shifted grid (k + 0.5) / N, avoiding DC and Nyquist edge singularities and cutting transform overhead in half.
Split Computation Mode (split = true): In real-time audio, doing a full STFT analysis and synthesis every N samples can cause periodic CPU spikes. Enabling split = true in configure() or presetCheaper() slices the spectral workload into small incremental steps distributed evenly across every sample frame.
Automatic Silence Bypass: When input energy drops below the noise floor, Kempo automatically bypasses heavy spectral math while keeping ring buffers synchronized.

In JMH benchmarks on standard desktop JVM hardware (44.1 kHz audio), Kempo processes a real-time streaming block in ~220 μs (mono) and ~484 μs (stereo), and renders offline audio at over 128x real-time speed for mono and ~70x real-time for stereo.

Try It Live: The Compose Desktop Studio App

Want to hear how Kempo handles your own audio files before writing a line of code?

The repository includes an interactive Compose Multiplatform Desktop Studio application (:example). Drop any .wav file onto the window to inspect its waveform, scrub through the timeline in real time, and tweak live parameters on the fly:

Playback Speed (0.25x – 3.00x) with instant presets (0.50x, 0.75x, 1.25x, 1.50x, 2.00x)
Pitch Shift (-12 st to +12 st) in semitone steps
Formant Shift (-12 st to +12 st) for real-time vocal timbre shaping

Explore the Code

Check out the full source code, architecture docs, and the runnable CLI attack simulation on GitHub.

Why HTTPS Won’t Save Your Checkout Flow: Building Zero-Trust State Machines in Kotlin Multiplatform

Wed, 14 Oct 2026 06:29:28 +0000

How to protect multi-step workflows, fintech funnels, and Server-Driven UI from step-skipping, state tampering, and replay attacks — with zero runtime dependencies.

Imagine a standard e-commerce checkout flow: Shopping Cart → Shipping Address → Promo Code → Payment Authorization.

You use HTTPS. You validate JWT tokens on every request. Your backend endpoints are covered with unit tests. You feel safe.

Then someone opens your app on a rooted device, hooks into memory with Frida, or simply manipulates an internal deep link. Instead of going from Cart to Shipping (where a $50 express delivery fee is calculated), the client dispatches a transition straight from Cart to Payment. Or worse, in a Server-Driven UI (SDUI) flow, an attacker replays a cached JSON payload from five minutes ago where a KYC verification flag was temporarily set to true.

HTTPS only encrypts the pipe. JWTs only verify who is holding the token. Neither guarantees that your client-side state machine actually followed the legal sequence of steps to reach its current screen.

To fix this at the architectural level without littering business logic with endless if-else checks, I built TrustChain — a pure functional, cryptographically verifiable state machine ledger for Kotlin Multiplatform (KMP).

The Mental Model: Think "Git Commits" for Your App State

You don’t need a PhD in cryptography or heavy blockchain consensus algorithms to secure a user journey. You just need strict lineage.

Think about how Git works: every commit contains a hash of its own content plus the exact hash of the parent commit. If you try to alter history or insert a commit out of nowhere, the hashes don't match, and Git rejects the tree immediately.

TrustChain brings this exact mechanism to your application’s navigation and state stack:

Every screen or workflow step has a unique hash representing its current state, and a previousHash pointing to the exact step that preceded it.
When the user moves forward, the incoming step’s previousHash must match the hash of the currently active step on top of the stack.
Partial state updates (like applying a promo code or updating live order status over WebSockets) arrive as signed deltas (DeltaBlock). They verify the current hash, check the server’s asymmetric digital signature, mutate the state, and verify the new hash.

If an attacker tries to skip a screen, inject a fake discount, or replay an old state, the hash chain breaks. The state machine fails fast before a single pixel is rendered or a network call is fired.

Security Concern	Standard REST + HTTPS	JWT Tokens	TrustChain
Data In-Transit Encryption	Yes (TLS)	Yes (TLS)	Yes (TLS)
Prevent Step Skipping (Deep Links)	No (Complex backend checks)	No	Yes (Parent Hash Check)
Detect Tampered State Deltas	No	Partially	Yes (Asymmetric Signatures)
Replay Attack Prevention	Manual nonces required	No	Yes (Strict Hash Lineage)
Zero Runtime Dependencies	N/A	Often heavy	Yes (Pure KMP)

Designing for Zero Bloat: The Core Primitives

One of my main goals with TrustChain was keeping the core completely free of third-party runtime dependencies so it drops cleanly into Android, iOS, Desktop, Web, or backend KMP targets.

1. `VerifiableBlock`

Any screen, workflow step, or state snapshot in your domain simply implements a three-property interface:

interface VerifiableBlock {
    val id: String
    val hash: String
    val previousHash: String? // null only for the root (genesis) step
}

2. `DeltaBlock` (Signed Partial Updates)

Why re-fetch an entire screen when a user applies a 10% coupon or an order changes status? Instead of sending full state trees, the server sends a lightweight DeltaBlock:

@Serializable
data class DeltaBlock<P>(
    @SerialName("patches") val patches: P,
    @SerialName("previous_hash") val previousHash: String,
    @SerialName("new_hash") val newHash: String,
    @SerialName("signature") val signature: String = ""
)

Notice how DeltaBlock locks the mutation from both sides:

It can only be applied if the client is currently sitting on previousHash.
Its newHash is signed by the server's private key (RSA, Ed25519, or ECDSA).
Once the client applies patches via a BlockPatcher, the resulting block must produce newHash.

3. Pure Functional Reduction

TrustChain is completely immutable. There are no hidden side effects, mutable singletons, or uncaught exceptions flying across coroutines. You send a ChainEvent (Push, Pop, Replace, or ApplyDeltas), and reduce() returns a standard Kotlin Result:

sealed interface ChainEvent<out B : VerifiableBlock, out P> {
    data class Push<B : VerifiableBlock>(val block: B) : ChainEvent<B, Nothing>
    data object Pop : ChainEvent<Nothing, Nothing>
    data class Replace<B : VerifiableBlock>(val block: B) : ChainEvent<B, Nothing>
    data class ApplyDeltas<P>(val blocks: List<DeltaBlock<P>>) : ChainEvent<Nothing, P>
}

If a batch of 5 deltas is applied and the 4th delta has a broken hash link or invalid signature, atomicity is preserved — the entire reduction fails cleanly with a typed ChainError, leaving your original TrustChain untouched.

Real-World Walkthrough: The Unbreakable Checkout

Let’s look at how this works in practice using a multi-step checkout flow.

First, we define our domain step:

@Serializable
data class CheckoutStep(
    override val id: String,
    val title: String,
    val state: Map<String, String> = emptyMap(),
    override val hash: String,
    override val previousHash: String? = null
) : VerifiableBlock

Next, we initialize TrustChain on the client. Notice how cryptography and state patching are injected via simple functional interfaces (SignatureVerifier and BlockPatcher). You aren't locked into any specific crypto library:

var clientChain = TrustChain<CheckoutStep, Map<String, String>>(
    strictMode = true,
    verifier = SignatureVerifier { payload, signatureBase64 ->
        // Plug in your platform's Ed25519 / RSA / ECDSA verifier
        CryptoEngine.verify(serverPublicKey, payload, signatureBase64)
    },
    patcher = { step, patches, newHash ->
        step.copy(
            state = step.state + patches,
            hash = newHash
        )
    }
)

The Legitimate User Journey

As the user progresses through the checkout, every step returned by the server references the exact hash of the previous state:

// 1. User opens the Shopping Cart (Genesis block, previousHash = null)
val cartStep = server.startCheckout(sessionId)
clientChain = clientChain.reduce(ChainEvent.Push(cartStep)).getOrThrow()
// Active: Shopping Cart | Hash: h_c2c1a28598b8ad69

// 2. User confirms Shipping Address (Chained to Cart's hash)
val shippingStep = server.submitShipping(sessionId, "Baker St 221B")
clientChain = clientChain.reduce(ChainEvent.Push(shippingStep)).getOrThrow()
// Active: Shipping & Address | Hash: h_50bda3ba68cced0d | Prev: h_c2c1a28598b8ad69

// 3. User applies a 10% Promo Code (Signed DeltaBlock mutation)
val promoDelta = server.applyPromoCode(sessionId, "10%")
clientChain = clientChain.reduce(ChainEvent.ApplyDeltas(listOf(promoDelta))).getOrThrow()
// Active: Shipping & Address (Patched) | New Total: $1890 | New Hash: h_6471c5f0c53a644b

// 4. User proceeds to Payment (Chained to the patched Shipping hash)
val paymentStep = server.proceedToPayment(sessionId)
clientChain = clientChain.reduce(ChainEvent.Push(paymentStep)).getOrThrow()
// Active: Payment Authorization | Hash: h_6a6fd155e392f7ef

Simulating the Attack: Skipping Shipping

Now, let’s see what happens when an attacker loads the Cart (h_c2c1a28598b8ad69) and tries to jump straight to the paymentStep (bypassing shipping calculation):

var attackedChain = TrustChain<CheckoutStep, Map<String, String>>(strictMode = true)
attackedChain = attackedChain.reduce(ChainEvent.Push(cartStep)).getOrThrow()

// Attacker tries to force-push the Payment step directly onto the Cart
val attackResult = attackedChain.reduce(ChainEvent.Push(paymentStep))

attackResult.fold(
    onSuccess = {
        println("VULNERABILITY: Attack succeeded!")
    },
    onFailure = { error ->
        when (error) {
            is ChainError.HashMismatch -> {
                println("[!] BLOCKED BY TRUSTCHAIN: State machine integrity preserved.")
                println("    Expected parent: ${error.expected}, Actual: ${error.actual}")
            }
            is ChainError.SignatureVerificationFailed -> {
                println("[!] BLOCKED: Invalid server signature for block ${error.blockHash}")
            }
            else -> println("[!] Blocked: ${error.message}")
        }
    }
)

Console Output:

------------------------------------------------------
  Simulating Attack: Attacker tries to skip shipping  
------------------------------------------------------
Attacker has Cart loaded.
Attacker attempts to directly apply Payment step (bypassing Shipping)...
[!] BLOCKED BY TRUSTCHAIN: State machine integrity preserved.
Expected parent: h_c2c1a28598b8ad69, Actual: h_6471c5f0c53a644b

Because paymentStep expects its parent to be the patched shipping step (h_6471c5f0c53a644b), pushing it onto the cart (h_c2c1a28598b8ad69) triggers an immediate ChainError.HashMismatch. The state transition is rejected atomically.

Built for Developer Ergonomics

Security tools often fail because they make local development painful. Nobody wants to spin up a signing server just to preview a Compose Multiplatform screen or write a quick UI test.

That’s why TrustChain includes a strictMode flag:

strictMode = true (Default / Production): Enforces parent hash lineage on Push and Replace, verifies digital signatures via SignatureVerifier, and ensures BlockPatcher updates block hashes accurately.
strictMode = false (Previews / UI Prototyping): Bypasses cryptographic and lineage checks while keeping the exact same ChainEvent reducer API, allowing you to mock and jump between screens freely during development.

Where Does TrustChain Shine?

Server-Driven UI (SDUI): Guarantee that screens and dynamic patches pushed by the backend are rendered in the exact sequence intended by the server.
E-Commerce & Checkouts: Make it impossible to bypass delivery calculation, tax steps, or terms acceptance before payment.
Fintech & Banking: Enforce strict step ordering for wire transfers, credit limit increases, and multi-factor challenges.
KYC & Onboarding Funnels: Maintain a verifiable, tamper-proof progression through document capture and liveness checks.

Try It in Your Project

TrustChain is open-source under the Apache 2.0 License and published directly to Maven Central.

Check out the full source code, architecture docs, and the runnable CLI attack simulation on GitHub.

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Mon, 12 Oct 2026 08:10:01 +0000

Moving from backend C# and enterprise patterns into native mobile development can feel like stepping into a whole new world. But after building my very first mobile app using Kotlin, the experience was a revelation—the syntax felt natural, the developer tooling was sharp, and the results were immediate.

Coming from a C# background, Kotlin doesn't feel foreign at all; it feels like an alternative timeline of modern object-oriented and functional programming.

Key Benefits That Stand Out for C# Developers

Familiar Null Safety: Just like C#'s nullable reference types, Kotlin barks at nullability at compile time. Using the ? operator and safe-call operators keeps runtime crashes like NullPointerException (the Java equivalent of NullReferenceException) off your production apps.
Coroutines vs. Async/Await: If you are used to C#'s async/await pattern and channels, Kotlin's coroutines feel instantly intuitive. They make non-blocking UI rendering, API fetching, and background processing clean, sequential, and easy to reason about.
Radical Conciseness with Data Classes: Where a C# record or class with properties can still require a few lines, Kotlin's data class automatically generates equals(), hashCode(), and toString() methods in a single line of code.
Extension Functions: Just like C# extension methods, Kotlin lets you add new behavior to existing classes without inheritance or boilerplate decorator wrappers.
Modern UI Development: Paired with Jetpack Compose (or Compose Multiplatform), Kotlin allows you to build declarative user interfaces—similar to modern Web or XAML/MAUI approaches—making responsive layouts for different device sizes straightforward.

Key Technical References for C# Developers

When diving deeper into Kotlin from .NET, the following official references and standards are worth bookmarking:

Language Specification & Core Standards:
Kotlin Standard Library API Reference (kotlin-stdlib): Provides core data structures, scoping functions (let, apply, also, run), and extension functions.
Kotlin Language Specification: Covers fundamental compiler behaviors, type inference, subtyping, and execution semantics.

Concurrency & Jetpack Tooling:
Kotlin Coroutines Specification & Guide: Formal reference for structured concurrency, flows, and channels.
Android Jetpack Compose Documentation: Official toolkit for building native Android UIs declaratively with Kotlin.

The Takeaway

Building that first mobile app proves that backend principles—clean architecture, strong typing, and smart asynchronous design—translate directly into mobile development. Kotlin bridges the gap perfectly, giving C# developers a powerful, highly productive stack for native mobile apps.

Building Payment Flows in Android: Lessons from Real Fintech Apps

Wed, 23 Sep 2026 09:35:18 +0000

Building Payment Flows in Android: Production Patterns from Fintech Applications

Subtitle: Architectural patterns and state management strategies for reliable payment flows at scale

Introduction

Over the past months, I've been building and refining payment systems at scale. Every architectural decision compounds over time, and payment flows demand particular attention to state management, error handling, and offline resilience.

This article documents the patterns that have proven effective in production fintech applications. These aren't theoretical approaches—they represent lessons learned from handling millions of transactions and the edge cases that accompany them.

Why Payment Flows Require Specialized Architecture

Most mobile applications tolerate a certain degree of architectural looseness. A user can restart the app if something fails. Recovery is straightforward.

Payment flows operate under different constraints:

State Ambiguity is Costly
When a user initiates a payment, your application must maintain absolute clarity about its status: submitted, pending, failed, queued offline. If this state is unclear, the user is equally uncertain, leading to duplicate submissions or lost transactions.

Race Conditions Have Financial Consequences
A user confirms payment and immediately navigates away. Your retry logic must account for this without resubmitting the payment or losing the transaction record.

Network Reliability Cannot Be Assumed
In many markets, network interruptions occur mid-transaction. Your system must handle incomplete requests gracefully—queuing the transaction locally and retrying when connectivity returns.

Offline-First Is Essential
Users may initiate transactions without active connectivity. The application must queue payments locally, survive process termination, and submit reliably when network becomes available.

This is why Clean Architecture and MVI pattern implementation is not optional for payment flows—it becomes a structural guarantee that state remains traceable and predictable.

Architectural Foundation

For context on the underlying architecture, see Clean Architecture in Android: A Real-World Guide.

The structure we use:

:domain — Pure Kotlin business logic without Android dependencies
:data — Repository layer managing offline queues, network calls, and persistence
:feature:payment — MVI implementation containing Intent, UiState, ViewModel, and UI layers

This separation ensures business logic can be tested independently of Android runtime, catching state-related bugs before deployment.

Pattern 1: Payment Confirmation Flow with Explicit State

The MVI Contract

sealed class PaymentConfirmationIntent {
    data class LoadPaymentDetails(val paymentId: String) : PaymentConfirmationIntent()
    object ConfirmPayment : PaymentConfirmationIntent()
    object RetryPayment : PaymentConfirmationIntent()
    object CancelPayment : PaymentConfirmationIntent()
    object DismissError : PaymentConfirmationIntent()
}

data class PaymentConfirmationUiState(
    val paymentDetails: PaymentDetails? = null,
    val isLoading: Boolean = false,
    val isConfirming: Boolean = false,
    val error: PaymentError? = null,
    val isOffline: Boolean = false,
    val confirmationStatus: ConfirmationStatus = ConfirmationStatus.Idle,
) {
    enum class ConfirmationStatus {
        Idle,
        AwaitingUserConfirmation,
        Processing,
        Success,
        Failed,
        OfflineQueued,
    }
}

sealed class PaymentConfirmationEffect {
    object NavigateToSuccess : PaymentConfirmationEffect()
    object NavigateToFailure : PaymentConfirmationEffect()
    object NavigateBack : PaymentConfirmationEffect()
}

Structural Benefits:

The ConfirmationStatus.OfflineQueued state explicitly represents the condition where payment has been submitted locally and awaits network availability. This eliminates ambiguity about whether a transaction was successfully queued.

Each Intent represents a discrete user action with no overlap, preventing state collisions. The isOffline flag as part of UiState ensures the UI layer can respond to network conditions with appropriate messaging.

ViewModel Implementation

@HiltViewModel
class PaymentConfirmationViewModel @Inject constructor(
    private val paymentRepository: PaymentRepository,
    private val offlinePaymentQueue: OfflinePaymentQueue,
    private val networkManager: NetworkManager,
) : ViewModel() {

    private val _state = MutableStateFlow<PaymentConfirmationUiState>(
        PaymentConfirmationUiState()
    )
    val state: StateFlow<PaymentConfirmationUiState> = _state.asStateFlow()

    fun processIntent(intent: PaymentConfirmationIntent) {
        when (intent) {
            is PaymentConfirmationIntent.LoadPaymentDetails -> 
                loadPaymentDetails(intent.paymentId)
            is PaymentConfirmationIntent.ConfirmPayment -> 
                confirmPayment()
            is PaymentConfirmationIntent.RetryPayment -> 
                retryPayment()
            is PaymentConfirmationIntent.CancelPayment -> 
                cancelPayment()
            is PaymentConfirmationIntent.DismissError -> 
                dismissError()
        }
    }

    private fun confirmPayment() {
        viewModelScope.launch {
            _state.update { it.copy(isConfirming = true) }

            try {
                if (!networkManager.isConnected()) {
                    val queuedPayment = offlinePaymentQueue.enqueue(
                        _state.value.paymentDetails ?: return@launch
                    )
                    _state.update {
                        it.copy(
                            isConfirming = false,
                            confirmationStatus = 
                                PaymentConfirmationUiState.ConfirmationStatus.OfflineQueued,
                        )
                    }
                    return@launch
                }

                val result = paymentRepository.submitPayment(
                    _state.value.paymentDetails!!
                )

                when (result) {
                    is PaymentResult.Success -> {
                        _state.update {
                            it.copy(
                                isConfirming = false,
                                confirmationStatus = 
                                    PaymentConfirmationUiState.ConfirmationStatus.Success,
                            )
                        }
                    }
                    is PaymentResult.Failure -> {
                        _state.update {
                            it.copy(
                                isConfirming = false,
                                error = result.error,
                                confirmationStatus = 
                                    PaymentConfirmationUiState.ConfirmationStatus.Failed,
                            )
                        }
                    }
                }
            } catch (e: Exception) {
                _state.update {
                    it.copy(
                        isConfirming = false,
                        error = PaymentError.Unknown(e.message ?: "Unknown error"),
                        confirmationStatus = 
                            PaymentConfirmationUiState.ConfirmationStatus.Failed,
                    )
                }
            }
        }
    }

    private fun retryPayment() {
        confirmPayment()
    }

    private fun dismissError() {
        _state.update { it.copy(error = null) }
    }

    private fun loadPaymentDetails(paymentId: String) {
        viewModelScope.launch {
            _state.update { it.copy(isLoading = true) }
            try {
                val details = paymentRepository.getPaymentDetails(paymentId)
                _state.update {
                    it.copy(
                        isLoading = false,
                        paymentDetails = details,
                        isOffline = !networkManager.isConnected(),
                    )
                }
            } catch (e: Exception) {
                _state.update {
                    it.copy(
                        isLoading = false,
                        error = PaymentError.LoadFailed(
                            e.message ?: "Failed to load"
                        ),
                    )
                }
            }
        }
    }

    private fun cancelPayment() {
        // Navigate back without submission
    }
}

Key Implementation Details:

Network connectivity is checked before submission
Offline state triggers local queueing with explicit status update
Exception handling updates UI state rather than propagating errors
All state transitions are explicit and traceable

UI Layer

@Composable
fun PaymentConfirmationScreen(
    viewModel: PaymentConfirmationViewModel,
    paymentId: String,
    onSuccess: () -> Unit,
    onFailure: () -> Unit,
    onBack: () -> Unit,
) {
    val state by viewModel.state.collectAsState()

    LaunchedEffect(Unit) {
        viewModel.processIntent(
            PaymentConfirmationIntent.LoadPaymentDetails(paymentId)
        )
    }

    LaunchedEffect(state.confirmationStatus) {
        when (state.confirmationStatus) {
            PaymentConfirmationUiState.ConfirmationStatus.Success -> 
                onSuccess()
            PaymentConfirmationUiState.ConfirmationStatus.Failed -> 
                onFailure()
            else -> {}
        }
    }

    Box(modifier = Modifier.fillMaxSize()) {
        when {
            state.isLoading -> {
                CircularProgressIndicator(
                    modifier = Modifier.align(Alignment.Center)
                )
            }
            state.paymentDetails != null -> {
                Column(
                    modifier = Modifier
                        .fillMaxSize()
                        .padding(16.dp),
                    verticalArrangement = Arrangement.spacedBy(16.dp),
                ) {
                    PaymentDetailsCard(state.paymentDetails)

                    if (state.isOffline) {
                        OfflineWarningBanner()
                    }

                    state.error?.let { error ->
                        ErrorBanner(
                            message = error.message,
                            onDismiss = {
                                viewModel.processIntent(
                                    PaymentConfirmationIntent.DismissError
                                )
                            }
                        )
                    }

                    Spacer(modifier = Modifier.weight(1f))

                    when (state.confirmationStatus) {
                        PaymentConfirmationUiState.ConfirmationStatus
                            .AwaitingUserConfirmation -> {
                            ConfirmationButtons(viewModel, onBack)
                        }
                        PaymentConfirmationUiState.ConfirmationStatus
                            .OfflineQueued -> {
                            Button(
                                onClick = { onBack() },
                                modifier = Modifier.fillMaxWidth(),
                            ) {
                                Text("Done")
                            }
                        }
                        PaymentConfirmationUiState.ConfirmationStatus.Failed -> {
                            Button(
                                onClick = {
                                    viewModel.processIntent(
                                        PaymentConfirmationIntent.RetryPayment
                                    )
                                },
                                modifier = Modifier.fillMaxWidth(),
                            ) {
                                Text("Retry")
                            }
                        }
                        else -> {}
                    }
                }
            }
            state.error != null -> {
                ErrorScreen(
                    error = state.error,
                    onRetry = {
                        viewModel.processIntent(
                            PaymentConfirmationIntent
                                .LoadPaymentDetails(paymentId)
                        )
                    },
                    onBack = onBack,
                )
            }
        }
    }
}

@Composable
private fun OfflineWarningBanner() {
    Card(
        modifier = Modifier.fillMaxWidth(),
        colors = CardDefaults.cardColors(
            containerColor = Color(0xFFFFF3CD)
        ),
    ) {
        Row(
            modifier = Modifier
                .fillMaxWidth()
                .padding(12.dp),
            horizontalArrangement = Arrangement.spacedBy(8.dp),
            verticalAlignment = Alignment.CenterVertically,
        ) {
            Icon(
                imageVector = Icons.Default.Warning,
                contentDescription = null,
                tint = Color(0xFFFF9800),
            )
            Text(
                text = "You are offline. Your payment will be submitted when connectivity is restored.",
                fontSize = 14.sp,
                modifier = Modifier.weight(1f),
            )
        }
    }
}

Pattern 2: Offline Payment Queue with Persistence

Local queueing with durable storage is essential for offline-first applications.

// domain/payment/OfflinePaymentQueue.kt

data class QueuedPayment(
    val id: String,
    val payment: PaymentDetails,
    val timestamp: Long,
    val retryCount: Int = 0,
    val status: QueueStatus = QueueStatus.Pending,
) {
    enum class QueueStatus {
        Pending,
        Retrying,
        Submitted,
        Failed,
    }
}

interface OfflinePaymentQueue {
    suspend fun enqueue(payment: PaymentDetails): QueuedPayment
    suspend fun getAll(): List<QueuedPayment>
    suspend fun getById(id: String): QueuedPayment?
    suspend fun remove(id: String)
    suspend fun updateStatus(id: String, status: QueueStatus)
    suspend fun incrementRetry(id: String)
}

// data/payment/OfflinePaymentQueueImpl.kt

@Singleton
class OfflinePaymentQueueImpl @Inject constructor(
    private val paymentDao: PaymentQueueDao,
) : OfflinePaymentQueue {

    override suspend fun enqueue(payment: PaymentDetails): QueuedPayment {
        val queued = QueuedPayment(
            id = UUID.randomUUID().toString(),
            payment = payment,
            timestamp = System.currentTimeMillis(),
        )
        paymentDao.insert(queued.toEntity())
        return queued
    }

    override suspend fun getAll(): List<QueuedPayment> {
        return paymentDao.getAll().map { it.toDomain() }
    }

    override suspend fun updateStatus(
        id: String,
        status: QueueStatus
    ) {
        paymentDao.updateStatus(id, status.name)
    }

    override suspend fun remove(id: String) {
        paymentDao.delete(id)
    }

    override suspend fun incrementRetry(id: String) {
        paymentDao.incrementRetry(id)
    }

    override suspend fun getById(id: String): QueuedPayment? {
        return paymentDao.getById(id)?.toDomain()
    }
}

Background synchronization handles submission when connectivity is restored:

// data/payment/PaymentSyncWorker.kt

class PaymentSyncWorker @Inject constructor(
    context: Context,
    params: WorkerParameters,
    private val offlineQueue: OfflinePaymentQueue,
    private val paymentRepository: PaymentRepository,
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            val queuedPayments = offlineQueue.getAll()
                .filter { it.status == QueueStatus.Pending }

            queuedPayments.forEach { queued ->
                try {
                    offlineQueue.updateStatus(
                        queued.id,
                        QueueStatus.Retrying
                    )

                    val result = paymentRepository.submitPayment(
                        queued.payment
                    )

                    when (result) {
                        is PaymentResult.Success -> {
                            offlineQueue.updateStatus(
                                queued.id,
                                QueueStatus.Submitted
                            )
                            offlineQueue.remove(queued.id)
                        }
                        is PaymentResult.Failure -> {
                            if (queued.retryCount < MAX_RETRIES) {
                                offlineQueue.incrementRetry(queued.id)
                            } else {
                                offlineQueue.updateStatus(
                                    queued.id,
                                    QueueStatus.Failed
                                )
                            }
                        }
                    }
                } catch (e: Exception) {
                    if (queued.retryCount < MAX_RETRIES) {
                        offlineQueue.incrementRetry(queued.id)
                    } else {
                        offlineQueue.updateStatus(
                            queued.id,
                            QueueStatus.Failed
                        )
                    }
                }
            }

            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }

    companion object {
        private const val MAX_RETRIES = 5
        const val WORK_NAME = "payment_sync"
    }
}

// Schedule in application startup:
// WorkManager.getInstance(context).enqueueUniquePeriodicWork(
//     PaymentSyncWorker.WORK_NAME,
//     ExistingPeriodicWorkPolicy.KEEP,
//     PeriodicWorkRequestBuilder<PaymentSyncWorker>(
//         15, TimeUnit.MINUTES
//     ).build()
// )

Benefits of This Approach:

Payment data persists across process termination
Retry logic respects maximum attempt limits
Each payment has a unique identifier preventing duplicate submissions
Status transitions are durable and traceable

Pattern 3: Biometric Authentication for Payment Confirmation

Biometric authentication integrates as a discrete state within the payment flow:

sealed class BiometricAuthIntent {
    object AuthenticateWithBiometric : BiometricAuthIntent()
    object CancelBiometric : BiometricAuthIntent()
    object RetryBiometric : BiometricAuthIntent()
}

data class BiometricAuthUiState(
    val isAuthenticating: Boolean = false,
    val authResult: BiometricAuthResult? = null,
    val error: BiometricError? = null,
) {
    sealed class BiometricAuthResult {
        object Success : BiometricAuthResult()
        object Failure : BiometricAuthResult()
        object Cancelled : BiometricAuthResult()
    }
}

@HiltViewModel
class BiometricAuthViewModel @Inject constructor(
    private val biometricManager: BiometricManager,
) : ViewModel() {

    private val _state = MutableStateFlow<BiometricAuthUiState>(
        BiometricAuthUiState()
    )
    val state: StateFlow<BiometricAuthUiState> = _state.asStateFlow()

    fun processIntent(intent: BiometricAuthIntent) {
        when (intent) {
            BiometricAuthIntent.AuthenticateWithBiometric -> authenticate()
            BiometricAuthIntent.CancelBiometric -> cancel()
            BiometricAuthIntent.RetryBiometric -> authenticate()
        }
    }

    private fun authenticate() {
        viewModelScope.launch {
            _state.update { it.copy(isAuthenticating = true) }

            try {
                val result = biometricManager.authenticate()
                _state.update {
                    it.copy(
                        isAuthenticating = false,
                        authResult = result,
                    )
                }
            } catch (e: BiometricException) {
                _state.update {
                    it.copy(
                        isAuthenticating = false,
                        error = BiometricError.AuthenticationFailed(
                            e.message ?: "Authentication failed"
                        ),
                    )
                }
            }
        }
    }

    private fun cancel() {
        biometricManager.cancel()
        _state.update {
            it.copy(
                isAuthenticating = false,
                authResult = BiometricAuthUiState.BiometricAuthResult
                    .Cancelled,
            )
        }
    }
}

Biometric authentication state remains consistent with the MVI pattern rather than introducing separate concerns.

Transaction Flow Example

Consider a complete transaction lifecycle:

User initiates payment confirmation
App checks network connectivity
If offline: payment queued locally with OfflineQueued status
If online: payment submitted to server
On network restoration: background worker processes offline queue
Each queued payment retried up to 5 times before marking failed
User notified of final status through UI state updates

This approach ensures:

No state ambiguity at any point
Network interruptions don't result in lost transactions
Duplicate submissions are prevented
Process termination doesn't destroy payment records

Open-Source Implementation

These patterns are available in production-ready form:

clean-architecture-android — Foundation template with Clean Architecture, MVI, and Jetpack Compose
fintech-mobile-patterns-android — Payment flow implementations with offline queuing, error handling, and authentication patterns

Both repositories include complete implementations with testing examples.

Conclusion

Payment flow architecture demands explicit state management and thoughtful error handling. The patterns discussed—explicit state enums, offline queuing with persistence, and MVI-based architecture—provide structural guarantees that reduce the likelihood of state-related bugs.

These approaches have proven effective at production scale. They prioritize clarity of state over brevity of code, understanding that payment systems benefit more from predictability than elegance.

Additional Resources

Android CI/CD for Beginners — Part 1: Introduction

Tue, 22 Sep 2026 17:12:07 +0000

Stop building everything manually. Learn how modern Android teams automate their development workflow

This series is designed to provide a complete understanding of CI/CD for Android development. In Part 1, we’ll introduce the fundamentals of CI/CD, explore what it is, why it matters, and how it’s used in Android app development.

CI/CD (Continuous Integration and Continuous Delivery/Deployment) is a set of practices that automate repetitive tasks in the software development process, such as building, testing, and releasing applications.

Instead of manually performing these tasks every time you make a change, a CI/CD pipeline executes them automatically whenever predefined events occur, such as pushing code to a Git repository.

How can CI/CD automate tasks in Android development?
CI/CD automates many of the repetitive tasks involved in the Android development lifecycle. Instead of running these steps manually every time you make a change, they can be executed automatically whenever code is pushed to your repository.

With a CI/CD pipeline, your Android app can be automatically:

Built using Gradle.
Analyzed for code quality with Android Lint.
Tested by running unit and instrumentation tests.
Packaged into a signed or unsigned APK or Android App Bundle (AAB).
Distributed to testers or prepared for release to the Google Play Store.
You might be wondering: Why do we need to automate these tasks?

In real-world Android projects, multiple developers often work on the same codebase. Every new feature, bug fix, or improvement is usually submitted as a pull request (PR).

Before those changes are merged, the team needs to ensure they meet the project’s quality standards and don’t introduce bugs or break existing functionality.

Manually building the app, running lint checks, executing tests, and verifying every pull request can quickly become repetitive and time-consuming, especially as the project grows.

This is where CI/CD becomes valuable. Whenever a pull request is opened or updated, a CI pipeline can automatically build the app, run lint checks, execute unit and instrumentation tests, and report whether all checks have passed.

If any step fails, developers are notified immediately, allowing issues to be fixed before the changes are merged.

Once all the automated checks succeed, the CD pipeline can take over by generating an APK or App Bundle and distributing it to testers or preparing it for release.

This eliminates many manual steps, speeds up the development process, and helps maintain a stable and reliable codebase.

Common CI/CD Terminology
Before we start building our first CI/CD pipeline, it’s important to understand some common terms you’ll encounter throughout this series. These concepts are not exclusive to Android development, they’re used across many CI/CD platforms. We’ll explore how these ideas come together in practice in the upcoming sections.

Pipeline
A pipeline is the complete automated process that runs after a specific event, such as pushing code to a Git repository or opening a pull request. A pipeline can build your app, run tests, generate an APK, and even distribute it to testers — all without manual intervention.

Think of a pipeline as a sequence of automated tasks executed in a predefined order.

Workflow
In GitHub Actions, a pipeline is defined using a workflow. A workflow is a YAML (.yml or .yaml) file stored inside the .github/workflows directory of your project.

It describes what should happen, when it should happen, and how it should be executed.

A repository can contain multiple workflows, each responsible for different tasks. For example, one workflow may run tests for every pull request, while another creates a release build whenever a new version is published.

Event (Trigger)
A workflow doesn’t run on its own — it needs an event, also known as a trigger.

Common triggers include:

Pushing code to a branch (push)
Opening or updating a pull request (pull_request)
Manually starting a workflow (workflow_dispatch)
Creating a release (release)
Whenever one of these events occurs, GitHub Actions starts the corresponding workflow.

Runner
A runner is the machine responsible for executing your workflow.

GitHub provides hosted runners running Linux, Windows, and macOS. For Android projects, Linux runners are commonly used because they provide a fast and cost-effective environment for building Android applications.

You can also configure your own self-hosted runner if you need custom hardware or software.

Job
A job is a collection of related tasks executed on the same runner.

For example, one job might build the Android app, while another runs unit tests. Multiple jobs can run sequentially or in parallel, depending on how the workflow is configured.

Step
A step is a single task inside a job.

Examples of steps include:

Checking out the repository
Setting up Java
Installing Android dependencies
Running Gradle commands
Uploading the generated APK
A job is simply a sequence of steps executed one after another.

Action
An Action is a reusable piece of automation that performs a specific task.

Instead of writing everything from scratch, you can use actions created by GitHub or the community.

For example:

actions/checkout downloads your repository onto the runner.
actions/setup-java installs and configures Java.
actions/upload-artifact uploads build outputs such as APKs or test reports.
Actions make workflows shorter, cleaner, and easier to maintain.

Artifact
An artifact is a file generated during a workflow that you want to keep after the workflow finishes.

In Android projects, common artifacts include:

APK files
Android App Bundles (AAB)
Lint reports
Unit test reports
Code coverage reports
Artifacts can be downloaded later for testing, debugging, or distribution.

GitHub Actions
Throughout this series, we’ll use GitHub Actions as our CI/CD platform.

GitHub Actions is GitHub’s built-in automation service that allows you to create workflows using YAML files. It automatically responds to events in your repository, runs your workflows on runners, and reports the results all directly within GitHub.

Now that you’re familiar with these core concepts, we’ll start creating our first Android CI workflow in the next part of this series.

That all it for now…
Lets stop here for now as this is already too much if your just starting out

Now that you understand the purpose of CI/CD and the terminology behind it, it’s time to build your first pipeline.

In Part 2, we’ll set up GitHub Actions, create our first workflow, and automatically build an Android application whenever code is pushed to GitHub.

👋Bye!!!

Building High-Performance Text Editors in Kotlin Multiplatform with Krope

Fri, 24 Jul 2026 13:03:31 +0000

If you have ever tried building a text editor, an IDE, or a collaborative document tool, you quickly run into a fundamental wall: how do you store the text?

At first glance, a standard String seems fine. But Strings are immutable; changing a single character in a 1MB file requires allocating a brand new 1MB array. So, you move to StringBuilder. It’s mutable and fast for simple appends, but inserting or deleting text in the middle of a massive document still requires shifting hundreds of thousands of characters in memory — an O(N) operation that causes UI stuttering as your document grows.

This is where the Rope data structure comes in.

Today, I want to introduce Krope, a high-performance, memory-safe, and reactive Rope library built entirely in Kotlin Multiplatform. Whether you are targeting JVM, Android, iOS, or WASM, Krope provides the engine you need to build next-generation text editing tools.

What is a Rope?

Instead of storing text as a single massive, contiguous array of characters, a Rope stores text as a balanced binary tree (in Krope’s case, utilizing a Red-Black tree variant). The leaves of the tree contain short chunks of strings.

When you insert text in the middle of a document, a Rope doesn’t copy the whole string. Instead, it splits a leaf node and inserts a new branch. This gives operations like insertion, deletion, and replacement a time complexity of O(log N).

Furthermore, Krope implements structural sharing. When a modification occurs, Krope doesn’t mutate the existing tree; it returns a new tree that shares the untouched branches with the old one. This provides safe concurrent access, cheap undo/redo history.

Why I Built Krope

The idea for Krope was born while building haskcore — a full-featured IDE for Haskell written in Compose Desktop. It uses Skia for rendering, Tree-sitter for incremental syntax parsing, and the Language Server Protocol for code intelligence. It’s a real editor with 40+ modules, handling everything from syntax highlighting to code completion and project-wide diagnostics.

Very quickly, I hit a wall: Kotlin’s standard StringBuilder couldn't keep up. Editing large Haskell modules meant shifting massive text buffers on every keystroke, causing visible lag during syntax highlighting and LSP synchronization. I needed something better — and the rope data structure, battle-tested in editors like Emacs and Vim since the 90s, was the obvious answer.

But Kotlin Multiplatform lacked a modern, reactive, and fully-featured rope implementation. So I built Krope to solve the specific pain points I encountered:

Cross-Platform Consistency: haskcore targets the desktop, but the same text engine should work on Android, iOS, and WASM for future ports or companion apps.
Reactive by Design: Compose Multiplatform thrives on reactive state. Krope exposes every edit as a SharedFlow event and every document state as a StateFlow, making UI integration seamless.
Byte-Level Encoding Awareness: LSP servers speak in byte offsets, not character positions. Krope natively tracks UTF-8, UTF-16, and UTF-32, giving you efficient access to byte coordinates backed by an LRU cache.
Functional & Safe: Invalid operations shouldn’t crash your editor. Krope uses an Either<Throwable, Result> pattern, so out-of-bounds inserts return errors you can handle gracefully — critical when processing remote edits from LSP or collaborative peers.

Inside the Krope API

Krope separates the underlying data structure from the editor API. The primary interface you interact with is the TextBuffer.

Here is how simple it is to get started:

import io.github.numq.krope.core.Encoding
import io.github.numq.krope.text.*
import kotlinx.coroutines.launch

// 1. Initialize the buffer
val factory = RopeTextBufferFactory()
val buffer = factory.create(
    text = "Hello World",
    encoding = Encoding.UTF8,
    lineEnding = TextLineEnding.LF,
    enablePooling = true // Enables internal string interning to save memory
).fold(
    onLeft = { error -> throw error },
    onRight = { it }
)

The Reactive Paradigm

In a standard text editor, the UI needs to know exactly what changed to update the screen or send a diff over the network for collaborative editing. Krope exposes two flows:

snapshot: StateFlow<TextSnapshot>: Represents the immutable current state of the document.
data: SharedFlow<TextEdit.Data>: Emits granular events whenever the text changes.

// Observe all changes in real-time
launch {
    buffer.data.collect { editData ->
        when (editData) {
            is TextEdit.Data.Single.Insert -> 
                println("Inserted '${editData.insertedText}' at ${editData.startPosition}")
            is TextEdit.Data.Single.Delete -> 
                println("Deleted text ending at ${editData.oldEndPosition}")
            is TextEdit.Data.Single.Replace -> 
                println("Replaced '${editData.oldText}' with '${editData.newText}'")
            is TextEdit.Data.Batch -> 
                println("Batch processed ${editData.singles.size} operations atomically")
        }
    }
}

Line and Column Awareness

Most ropes just deal with raw character offsets. Krope natively understands Lines and Columns through TextPosition.

// "Hello Beautiful World"
buffer.insert(TextPosition(line = 0, column = 5), " Beautiful")

// Querying the snapshot is instantaneous thanks to cached tree node metadata
val snapshot = buffer.snapshot.value
println("Total Lines: ${snapshot.lines}")
println("Max Line Length: ${snapshot.maxLineLength}")

// Get byte offset for an LSP (Language Server Protocol)
val byteOffset = snapshot.getBytePosition(TextPosition(line = 0, column = 6))

Atomic Batch Operations

When you refactor code (like renaming a variable that appears 10 times in a file), you don’t want to trigger 10 separate UI redraws or clutter the undo stack. Krope supports withBatch:

buffer.withBatch { batch ->
    batch.replace(TextRange(TextPosition(0, 39), TextPosition(0, 42)), "vatAmount")
    batch.replace(TextRange(TextPosition(1, 19), TextPosition(1, 22)), "vatAmount")
}

This applies all edits internally, rebalances the tree once, and emits a single TextEdit.Data.Batch event to your listeners.

Performance: The 100 Megabyte Test

To answer the age-old question - "How does it perform with very large files?" - I ran JMH benchmarks on the JVM comparing Krope to StringBuilder.

We simulated the "Real Editor Scenario": 100 consecutive edits (insertions) occurring right in the middle of a document. We scaled the document size from 100,000 characters all the way to 100,000,000 characters (approximately 200 MB of text).

Here are the results (in milliseconds per 100 operations):

100,000 symbols

Krope: ~0.05 ms
StringBuilder: ~0.16 ms
Krope Advantage: ~3x faster

1,000,000 symbols

Krope: ~0.19 ms
StringBuilder: ~1.74 ms
Krope Advantage: ~9x faster

10,000,000 symbols

Krope: ~2.07 ms
StringBuilder: ~17.86 ms
Krope Advantage: ~8.5x faster

100,000,000 symbols

Krope: ~19.32 ms
StringBuilder: ~186.41 ms
Krope Advantage: ~9.6x faster

Why does StringBuilder choke?

Look at how the StringBuilder time multiplies by 10 every time the file size multiplies by 10. This is the curse of O(N) complexity. When you insert a single character in the middle of a 200MB StringBuilder, Java has to use System.arraycopy to physically shift 100MB of data in RAM to make room. Doing this 100 times forces the CPU to move 10 gigabytes of memory. This is exactly what causes UI thread stuttering and input lag in text editors.

Why does Krope win?

Because of structural sharing and its Red-Black tree foundation. When making 100 edits, Krope doesn't copy 100MB of arrays. It simply splits a small leaf node, updates a few pointers up to the root, and does a lightning-fast O(log N) tree rebalance.

(Note: In the benchmark above, the ~19.32 ms for Krope actually included the time to parse the 200MB string into a Rope tree from scratch on every iteration! The edits themselves are nearly instantaneous).

In a real-world typing or refactoring scenario, Krope maintains incredibly flat, predictable latency regardless of whether your file is 10 Kilobytes or 200 Megabytes, keeping your UI perfectly smooth while drastically reducing heap allocations.

Get Involved

If you are building text-heavy applications in Compose Multiplatform, writing a code editor, or experimenting with CRDTs for collaborative editing, give Krope a try.

The architecture is highly modular, separating the core data structures from the TextBuffer API, and includes built-in support for kotlinx.serialization.

Check out the source code, play with the examples, and star the repository on GitHub!

🔗 GitHub Repository: Krope

Kotlin 2.4.0 Released

Sat, 13 Jun 2026 19:31:15 +0000

JetBrains has released Kotlin 2.4.0. The update includes stable language features, standard library additions, Kotlin/Native changes for Swift interoperability, Kotlin/Wasm and Kotlin/JS improvements, and build tool updates for Gradle and Maven.

The release is included in the latest versions of IntelliJ IDEA and Android Studio. Projects can update by setting the Kotlin version to 2.4.0 in their build scripts.

Language and Standard Library

Several language features that were previously experimental are now stable, including context parameters, explicit backing fields, the @all meta-target for properties, and new defaulting rules for annotation use-site targets.

The common standard library now has a stable kotlin.uuid.Uuid API. Kotlin 2.4.0 also adds sorted-order checks such as .isSorted() and .isSortedBy(), plus JVM extensions for converting unsigned integers to BigInteger.

On Kotlin/JVM, the compiler can generate Java 26 bytecode, and annotations in Kotlin metadata are now enabled by default.

Kotlin/Native and KMP

For Kotlin Multiplatform projects, the main changes are in Kotlin/Native. Swift export is now Alpha and has improved concurrency support: Kotlin suspend functions are exported as Swift async counterparts, and kotlinx.coroutines flows can be exported to Swift as AsyncSequence.

KMP projects can also declare Swift packages as dependencies for iOS apps directly in Gradle configuration. JetBrains also provides migration support for projects that currently rely on CocoaPods dependencies.

Kotlin/Native now supports Xcode 26.4, updates LLVM to version 21, and enables the concurrent mark and sweep garbage collector by default. The default minimum supported Apple target versions have also been raised to iOS and tvOS 15.0, macOS 12.0, and watchOS 8.0.

Wasm, JS, and Build Tools

Kotlin/Wasm incremental compilation is now stable and enabled by default. Kotlin 2.4.0 also introduces experimental support for the WebAssembly Component Model.

Kotlin/JS improves JavaScript and TypeScript export with support for value class export and ES2015 features when inlining JavaScript code.

On the build side, Kotlin 2.4.0 is compatible with Gradle 9.5.0. Maven builds now support automatic alignment between Java and JVM target versions.

Official announcement:
https://blog.jetbrains.com/kotlin/2026/06/kotlin-2-4-0-released/

Detailed release notes:
https://kotlinlang.org/docs/whatsnew24.html

Kotlin Professional Certificate by JetBrains

Wed, 20 May 2026 10:00:04 +0000

JetBrains has launched the Kotlin Professional Certificate by JetBrains, a new LinkedIn Learning path designed to help developers build practical Kotlin and Kotlin Multiplatform skills.

The program is structured around four courses and takes developers from Kotlin fundamentals through object-oriented and asynchronous programming, Kotlin Multiplatform development, and full-stack app development with Ktor and Compose Multiplatform. JetBrains says the certificate is aimed at developers with basic programming knowledge who want to learn Kotlin and explore how it can be used across Android, iOS, web, desktop, and backend environments.

The course includes:

Kotlin Essential Training
Kotlin Multiplatform
Ktor
Compose

After completing the course and passing the final exam, developers can earn a certificate that can be downloaded, shared, and added to a LinkedIn profile.

Additional info at:
https://blog.jetbrains.com/kotlin/2026/04/kotlin-professional-certificate-by-jetbrains-now-on-linkedin-learning/

Link to the course:
https://www.linkedin.com/learning/paths/kotlin-professional-certificate-by-jetbrains

JetBrains Just Changed KMP Structure. Here's What They Didn't Tell You.

Mon, 18 May 2026 18:26:05 +0000

JetBrains announced a new default project structure for KMP. Two shared modules — sharedLogic and sharedUI — plus separate application modules for each platform. Clean. Simple. Obvious.

It's also a trap.

The problem with `sharedLogic` and `sharedUI`

A fresh sharedLogic module looks innocent. Business logic, models, repositories. sharedUI holds your Composables. What could go wrong?

Three months later sharedLogic contains:

Business logic
Network clients
Database models
Constants
Utility functions
Something called CommonUtils.kt that nobody understands but everyone is afraid to delete

sharedLogic has no internal boundaries. Everything depends on everything. You can import a database model from a use case and nobody stops you. The compiler certainly won't.

JetBrains tells you where to start. They don't tell you what happens when two modules become 50,000 lines.

What actually happens

You try to split sharedLogic into more modules. But there are no rules. So you end up with:

:sharedLogic:core — the new dumping ground
:sharedLogic:data — which also contains business logic somehow

The dependencies look like spaghetti. Changing one module breaks three others. You didn't enforce boundaries early, and now every refactoring is a gamble.

FLIP: the next step after `sharedLogic`

FLIP is an architectural pattern that gives you rules for splitting sharedLogic before it becomes a problem.

Five layers. One direction. Zero horizontal dependencies.

Layer	Purpose	Depends on
:common:core	Foundation	Nothing
:service	Domain logic without UI	`:common:core`
:feature	UI features	`:service`, `:common:core`
:entrypoint	DI assembly + slot composition	Everything above
:platform	Platform entry point	`:entrypoint`

The rule is simple: features don't know about other features. services don't know about other services. Dependencies only flow down.

Your IDE enforces this. You literally cannot import a feature from another feature — Gradle won't compile. The structure prevents the dumpster fire before it starts.

Start with JetBrains. Grow with FLIP.

The new KMP structure is a great starting point. Two modules is better than one. But when sharedLogic starts feeling like a junk drawer, you know what to do.

FLIP is at github.com/numq/flip. Template included. Konsist tests included. Rules over conventions.

FLIP: Modular Architecture for KMP

Sun, 17 May 2026 04:49:14 +0000

While building haskcore - an IDE for Haskell on Compose Desktop - I extracted rules that allowed me to create an architecture of 40 isolated modules, where each module knows only what it needs.

That's how FLIP - Feature-Layered Isolated Platform - was born.

The main problem I faced during development: horizontal dependencies make the system fragile. The solution - strict vertical hierarchy.

FLIP consists of the following isolated modules:

:common:core - common logic components.
:common:presentation - common UI components.
:service - UI-less domain module. Provides a service interface.

interface SeedService : AutoCloseable {
    val seed: Flow<Seed>
    suspend fun generateSeed(): Either<Throwable, Unit>
}

:feature:core — logic module of a UI-feature. Knows nothing about other features. Uses services from :service. Provides use cases.

class GenerateRemoteRandomSeed(private val seedService: SeedService) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() = seedService.generateSeed().bind()
}

:feature:presentation — UI module of a UI-feature. Knows only about its :feature:core and uses its use cases. Provides the view. Knows only about its own :feature:core.
:entrypoint — module where dependency configuration and composition of views from :feature:presentation into a single Composable happens.
:platform — module that initializes the Composable provided by :entrypoint for each platform.

Arrows show the direction of dependencies.

How to structure your system?

Decide which features your app should have, then determine whether each feature has a UI:

If it does — it’s a feature.
If it doesn’t — it’s a service.
If one feature’s logic is needed by another — extract it into a separate service.

Important: both :service and :feature:core contain domain logic:

:service — core domain.
:feature:core — presentation domain (use cases).

Wrong:

:service:foo
:feature:foo:core
:feature:foo:presentation

Right:

:service:foo
:feature:bar:core
:feature:bar:presentation

Navigation in FLIP is just another feature. It aggregates and routes views passed as lambda slots, keeping it independent from other features.

NavigationView(
    splash = {
        SplashView(applicationScope = applicationScope)
    },
    profile = {
        ProfileView(applicationScope = applicationScope)
    }
)

This approach lets you add new screens without touching existing features.

A complete example is available in the official GitHub repository.

A recipe for the Perfect Use Case

Sun, 17 May 2026 04:47:50 +0000

Today we’re cooking the perfect Use Case — and CQRS will be our recipe.

Ingredients

Action — fire and forget (logout, clear cache)
Query — read data (list products)
Command — write data (update profile)
Exchange — transform data (login)

All four types extend a sealed interface:

sealed interface UseCase<Input, Output> {
    interface Action : UseCase<Unit, Unit>
    interface Query<Output> : UseCase<Unit, Output>
    interface Command<Input> : UseCase<Input, Unit>
    interface Exchange<Input, Output> : UseCase<Input, Output>
}

Three Ways to Season It

Arrow (Typed Errors) — the chef’s choice:

class GenerateSeed(
    private val seedService: SeedService
) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() =
        seedService.generateSeed().bind()
}

Result (Standard Wrapper) — zero dependencies:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed().getOrThrow()
}

Raw (Direct Execution) — zero overhead:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed()
}

Why This Recipe Works

No more UseCase<Unit, Unit> noise
Every use case follows the same structure
Query or Command makes intent obvious

Full implementation in the GitHub repository.

Stop Fighting Your State. Reduce And Conquer It.

Sun, 17 May 2026 04:47:30 +0000

MVVM seemed simple. Then you added ten MutableStateFlow properties to your ViewModel. MVI promised purity. Then you wrote a middleware for side effects.

There’s a better way.

The Problem With MVVM

A typical ViewModel looks like this:

class ProfileViewModel : ViewModel() {
    val name = MutableStateFlow("")
    val email = MutableStateFlow("")
    val isLoading = MutableStateFlow(false)
    val error = MutableStateFlow<String?>(null)
    fun updateProfile(name: String) {
        viewModelScope.launch {
            isLoading.value = true
            try {
                profileService.update(name)
                *Emails are not allowed*e = name
            } catch (e: Exception) {
                error.value = e.message
            } finally {
                isLoading.value = false
            }
        }
    }
}

Five mutable properties. Loading state scattered across three places. Error handling duplicated in every method. And the ViewModel doesn’t own its side effects — viewModelScope does.

The Problem With MVI

MVI fixes the state explosion by putting everything in a sealed interface:

sealed interface ProfileState {
    data object Loading : ProfileState
    data class Loaded(val name: String, val email: String) : ProfileState
    data class Error(val message: String) : ProfileState
}

But MVI doesn’t tell you how to handle side effects. Some use middleware. Some use Channel. Some hack it with LaunchedEffect. Every project reinvents the wheel.

Reduce & Conquer

The core idea: a reducer is a pure function that returns more than just state.

data class Transition<State, Event>(
    val state: State,
    val events: List<Event> = emptyList(),
    val effects: List<Effect> = emptyList()
)

A transition has three outputs:

State - the new state
Events - one-shot notifications (navigation, snackbar)
Effects - long-running or async work

Effects are first-class citizens:

sealed interface Effect {
    data class Stream<Command>(
        val key: Any,
        val flow: Flow<Command>,
        val strategy: Strategy = Strategy.Sequential,
        val fallback: (suspend (Throwable) -> Command)? = null
    ) : Effect
    data class Action<Command>(
        val key: Any,
        val fallback: (suspend (Throwable) -> Command)? = null,
        val block: suspend () -> Command
    ) : Effect
    data class Cancel(val key: Any) : Effect
}

Stream - subscribes to a flow, emits commands back
Action - runs one async operation, emits a command
Cancel - cancels by key, preventing leaks

A Reducer in Practice

class ProfileReducer(
    private val profileService: ProfileService
) : Reducer<ProfileState, ProfileCommand, ProfileEvent> {
    override fun reduce(
        state: ProfileState,
        command: ProfileCommand
    ): Transition<ProfileState, ProfileEvent> = when (command) {
        is ProfileCommand.UpdateProfile -> transition(
            state.copy(isLoading = true)
        ).effect(
            action(
                key = "update_profile",
                fallback = { ProfileCommand.ProfileError(it) },
                block = {
                    profileService.update(command.name)
                    ProfileCommand.ProfileUpdated
                }
            )
        )
        is ProfileCommand.ProfileUpdated -> transition(
            state.copy(isLoading = false)
        ).event(ProfileEvent.NavigateBack)
        is ProfileCommand.ProfileError -> transition(
            state.copy(
                isLoading = false,
                error = command.throwable.message
            )
        )
    }
}

No viewModelScope. No LaunchedEffect. No mutable properties. One pure function.

Why This Is The Benchmark

MVVM

State: Multiple MutableStateFlow
Side effects: viewModelScope.launch
Cancellation: Manual
Testing: Mock ViewModel

MVI

State: Single sealed class/interface
Side effects: Ad-hoc (middleware, Channel)
Cancellation: Manual
Testing: Mock reducer + middleware

Reduce & Conquer

State: Single sealed interface
Side effects: Built-in (Effect)
Cancellation: Automatic by key
Testing: One pure function call

Testing a reducer:

@Test
fun `update profile sets loading and fires effect`() {
    val transition = reducer.reduce(
        state = ProfileState(),
        command = ProfileCommand.UpdateProfile("Alice")
    )
    assertTrue(transition.state.isLoading)
    assertEquals(1, transition.effects.size)
    assertEquals(0, transition.events.size)
}

One call. No coroutines. No mocks.

The Rule

State flows down. Commands flow up. Effects manage the rest.

The View sends Commands. The Reducer returns a Transition with new State, Events, and Effects. The Feature executes Effects and feeds resulting Commands back into the Reducer. That's it.

Full implementation in the GitHub repository.

Contract Testing in Kotlin

Tue, 21 Apr 2026 14:13:28 +0000

Contract Testing in Kotlin: Kill "Works on My Machine" API Failures

Frontend deploys. Backend deploys. Everything looks green in CI, yet production is screaming with 500s because a field was renamed and someone’s Swagger doc was three sprints behind. We've all been there—cutting emergency hotfixes while the PM asks for a post-mortem you don't have time to write.

The root cause? API Drift. One team tweaked a schema, the other team’s code still expects the old one. In a monolith, this is a compiler error. In microservices, it’s a production outage. As a Kotlin dev, I’m done with manual coordination. Contract testing makes these failures structurally impossible by verifying interfaces before they hit the pipeline.

The No-Nonsense Takeaway

Speed: Contract tests run in <60s. No shared environments, no flaky network, just raw build-time validation.
The Stack: Pact for consumer-driven polyglot setups or Spring Cloud Contract for tight-knit Spring monorepos.
The Gatekeeper: can-i-deploy is your CI/CD enforcer. If the contract is broken, the deployment stops. exit code 1. No excuses.

Why Integration Tests Fail You

Integration tests check if two services play nice now. But services deploy independently. By the time your consumer merges, the provider might have moved from v1.2 to v1.4. Your integration test was green for a version pair that no longer exists in any environment. Contract testing closes this gap by ensuring independent verification against a machine-readable artifact.

Kotlin Implementation

Kotlin’s DSL-friendly syntax makes contract definitions look like actual specs, not just more boilerplate. Here’s how you get started with the dependencies:

// build.gradle.kts
dependencies {
    testImplementation("au.com.dius.pact.consumer:junit5:4.6.5")
    testImplementation("io.mockk:mockk:1.13.8")
    testImplementation("io.rest-assured:kotlin-extensions:5.4.0")
}

In the full breakdown, I dive into why stringType matchers are superior to hardcoded values (avoiding brittle tests) and how to use a Pact Broker to see exactly which fields are safe to delete without breaking your consumers.

When is it overkill?

If you're in a single-team monorepo where everything deploys in lockstep, don't over-engineer it. But the second you have independent teams and separate deployment cycles, contract testing isn't a luxury—it's your only way to guarantee the system doesn't shatter on every merge.

Krun Dev Code
Stop guessing. Start verifying.

Understanding Flutter Method Channels Through a Real Production Bug

Thu, 16 Apr 2026 15:48:54 +0000

Introduction

Flutter is amazing—until it isn’t.

Most of the time, you can build entire apps without ever touching native code. But the moment you hit a platform limitation, things get… interesting.

This blog isn’t just about Method Channels.

It’s about:

When Flutter abstractions break down
How to take control using native Android
And how to think about Flutter ↔ Native communication like a system, not a hack

Funny enough, this blog comes from a real bug I hit while building my app Anahad — a saadhna app that plays mantra chants.

And yeah… it broke in a very weird way.

The Real Problem (Why This Blog Exists)

I was building a saadhna app that plays mantra chants on loop.

Simple requirement:

Play audio
Loop it continuously
Run in the background (screen off)

I was using:

audio_service
just_audio
just_audio_background

Everything worked perfectly…

Until it didn’t.

The Bug

After ~940–960 loops on Android (specifically Android 12+):

Playback would stop silently
No crash
No exception
Only when the screen was off

Even after:

Disabling battery optimization
Proper background setup

Still broke.

The Weird Part

It consistently failed around the same loop range (~940–960).

Not 100. Not 500. Not random.

That kind of consistency usually means:

Something deeper is going on — not just app-level logic.

At This Point, Two Choices

Keep debugging blindly inside Flutter
Drop down to native Android and take control

I chose option 2, cz i never interacted with native code and wanted to explore it

Fun part, i had an android 11 device which wasn't having this bug at all, tested on other android 11 devices as well

Why Flutter Isn’t Always Enough

Flutter is great, but it abstracts away platform details.

That’s usually good—until you need:

Deep lifecycle control
System-level integrations
Debug visibility into platform behavior

Common cases where native is needed:

Background services
Media playback control
Hardware interaction
Platform-specific APIs
Performance-critical logic

In my case:

I needed more control over how Android handles long-running audio playback. Just to be absolutely sure that it was not the issue of the package that i was using

Understanding Method Channels (The Right Mental Model)

Before code, get this clear:

Dart is the client. Native Android is the server.

When you write:

platform.invokeMethod("play")

You’re essentially doing:

Dart → sends request
Android → receives it
Executes native logic
Returns response

Think of it like:

An internal API call inside your app

No HTTP. No network. Just a binary bridge.

Once you understand this, Method Channels stop feeling “magical”.

Architecture Overview

Flutter (Dart)
├── UI Layer
├── Service Layer (PlaybackService.dart)
└── State Management

        ↓↓↓ Method Channel ↓↓↓

Android (Kotlin)
├── MethodChannel Handler
├── PlaybackService (MediaSessionService)
└── ExoPlayer

Flow (Step-by-Step)

User taps "Play"
Dart calls invokeMethod("play")
MethodChannel sends message
Kotlin receives it
Native service executes logic
Result is sent back

The Native Side: Android (Kotlin)

Why MediaSessionService?

Instead of a basic service, we use:

MediaSessionService

Because it:

Integrates with system controls (lock screen, notifications)
Handles background playback more reliably
Works with audio focus and lifecycle events
Plays nicely with the Android system

PlaybackService.kt

class PlaybackService : MediaSessionService() {
    private var mediaSession: MediaSession? = null

    override fun onCreate() {
        super.onCreate()

        val audioAttributes =
            AudioAttributes.Builder()
                .setUsage(C.USAGE_MEDIA)
                .setContentType(C.AUDIO_CONTENT_TYPE_MUSIC)
                .build()

        val player =
            ExoPlayer.Builder(this)
                .setAudioAttributes(audioAttributes, true)
                .setHandleAudioBecomingNoisy(true)
                .setWakeMode(C.WAKE_MODE_NETWORK)
                .build()

        player.addListener(object : Player.Listener {
            override fun onPlayerError(error: PlaybackException) {
                Log.e("PlaybackService", "Error: ${error.message}", error)
            }
        })

        val callback = object : MediaSession.Callback {}

        mediaSession = MediaSession.Builder(this, player)
            .setCallback(callback)
            .build()
    }

    override fun onDestroy() {
        mediaSession?.run {
            player.release()
            release()
            mediaSession = null
        }
        super.onDestroy()
    }
}

The Flutter Side: Dart

Service Wrapper

class PlaybackService {
  static const platform =
      MethodChannel('com.theahambrahmasmi.anahad/playback');

  static Future<void> play(String url) async {
    await platform.invokeMethod('play', {'url': url});
  }

  static Future<void> pause() async {
    await platform.invokeMethod('pause');
  }

  static Future<Map<String, dynamic>> getStatus() async {
    final result = await platform.invokeMethod('getStatus');
    return Map<String, dynamic>.from(result);
  }
}

Kotlin: Method Channel Handler

class PlaybackMethodHandler(private val context: Context) {

    fun setupChannel(flutterEngine: FlutterEngine) {
        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            "com.theahambrahmasmi.anahad/playback"
        ).setMethodCallHandler { call, result ->

            when (call.method) {
                "play" -> {
                    val url = call.argument<String>("url")
                    val intent = Intent(context, PlaybackService::class.java)
                    intent.putExtra("audio_url", url)
                    context.startService(intent)
                    result.success(null)
                }

                "pause" -> {
                    val intent = Intent(context, PlaybackService::class.java)
                    context.stopService(intent)
                    result.success(null)
                }

                else -> result.notImplemented()
            }
        }
    }
}

Real-World Insight: The Looping Problem

If you're building:

Meditation apps
Chanting apps
Ambient loop apps

Be careful.

Android may silently stop long-running playback after extended loops.

Even with:

Battery optimization disabled
Background services configured

Test aggressively:

500+ loops
Screen-off playback
Different OEM devices

This is not just Flutter—it’s often Android system behavior.

What About The Root Cause?

Short answer:

I don’t fully know yet.

And yeah — that’s intentional honesty.

What I do know:

It only happens on Android 12+
It triggers after long-running background playback
It happens silently (no crash, no logs)
It correlates with a high loop count (~950)

Current Hypotheses:

Doze / background execution limits
Audio focus or media session interruption
ExoPlayer internal behavior after prolonged looping
OEM-level process killing
Resource exhaustion over time

We’ll Be Updating This

Once I dig deeper and find the exact root cause, I’ll update this blog with:

What exactly broke
Why Android 12+ behaves this way
The proper fix (not just experimental ones)
What you should do in production

Because honestly?

Debugging something that breaks at the OS level is messy… and kinda fun.

Final Thoughts

I eventually moved back to just_audio because:

The problematic flow was no longer needed

So yeah…

This experimental fix wasn’t used in production.

But it gave me something way more valuable:

A deeper understanding of how Flutter actually works under the hood.

And honestly?

I’m not perfect. I didn’t fully solve it (yet).
But now I know one more thing than I did before.

And that’s what matters.

TL;DR

Flutter is great, but not enough for everything
Method Channels = internal RPC bridge
Native gives you control Flutter abstracts away
Android background behavior can be unpredictable
Sometimes… you won’t have all the answers immediately

If you're building something serious:

Don’t just rely on abstractions. Understand what’s underneath.

That’s where real engineering begins.

Shindig — Cross-Platform Event Discovery

Mon, 30 Mar 2026 22:40:45 +0000

Shindig is a cross-platform event discovery app built with Kotlin Multiplatform (KMP) and Compose Multiplatform. One codebase runs on both Android and iOS with 80% shared code.

What It Does

Discover events happening around you from multiple aggregated sources
Create and manage your own events
Book and join events in seconds
Subscribe to Shindig Spark for premium features via in-app purchases

Tech Stack

Kotlin Multiplatform — shared business logic across Android and iOS
Compose Multiplatform — shared UI layer
Koin — dependency injection
Ktor — networking
DataStore — local storage
PostHog — analytics and feature flags
GCP Secret Manager — secrets management (no hardcoded keys)
GitHub Actions — CI/CD pipeline

Recent Milestones

iPadOS 26 support with auth sheet crash fixes
In-app purchases live (Shindig Spark subscription)
Cross-product analytics dashboard with PostHog
City availability survey for out-of-market expansion
Apple App Store review compliance (sign-in UX improvements)
Full security audit — hardcoded secrets removed, encrypted token storage
iOS bundle separation audit complete

Why KMP?

We chose Kotlin Multiplatform because event discovery has complex business logic (geo-spatial search, event aggregation, user preferences) but relatively standard UI patterns. KMP lets us share 80% of the code while keeping native performance and platform-specific UX where it matters.

Sub-100ms geo-spatial search. One codebase. Two platforms. No compromises.

What's Next

Expanding to new cities (survey-driven market entry)
AI-powered event recommendations
Firefly virtual economy — earn and spend currency across the platform
Enhanced social features

Built by Mathew Dostal — Fractional CTO & Principal Architect based in Austin, TX.

CodeContext

Thu, 25 Dec 2025 08:00:37 +0000

CodeContext is an innovative open-source project designed to facilitate faster developer onboarding by intelligently analyzing codebases.

Why CodeContext?

Onboarding new developers can often take between 1 to 3 months, during which they struggle with various challenges such as:

Searching for initial tasks or reference points
Understanding file dependencies and relationships
Navigating outdated documentation
Handling repetitive questions from team members

The Solution

CodeContext offers a solution by quickly analyzing a codebase and providing essential insights to enhance the onboarding experience:

Interactive Dependency Maps: Visualize the entire structure of the codebase with zoomable, force-directed graphs.
Knowledge Hotspots: Leverage a PageRank algorithm to identify critically important files within the project.
Personalized Learning Paths: Generate suggested reading orders to guide new developers effectively through the codebase.
Smart Contextual Information: Gain insights into Git history, authorship, and frequency of changes for each file.

These features collectively reduce the onboarding time significantly, converting the period from 3 months to just 3 weeks.

Features

Feature	Description
Interactive Dependency Maps	Visual representation of file relationships through dynamic graphs.
Knowledge Hotspots	Discover critical files based on their importance in the project using PageRank.
Learning Paths	Provides a topologically sorted order to help new team members navigate the project with ease.
Git Integration	Access detailed Git history and statistics for better context.
Team Contribution Map	Identify knowledge silos and assess risks related to team member dependencies.
Multi-Language Support	Currently supports Java and Kotlin, with plans for more languages.
Fast Performance	Built with parallel parsing and intelligent caching for efficiency.
Visual Reports	Generates clean HTML reports enhanced with D3.js visualizations.

Demo

An interactive demo illustrates the functionality of CodeContext by showcasing a dependency graph, knowledge hotspots, and learning path generation. To see CodeContext in action, run the command:

./gradlew run --args="analyze ."

Documentation

Comprehensive documentation is available to help users understand the architecture, development guidelines, API references, and more:

Contributing

Contributions are encouraged and can take many forms, including bug fixes, feature additions, or documentation improvements. A structured guide is provided to help newcomers get started. To explore open issues suitable for new contributors, browse the issues labeled good first issue.

Roadmap

Future enhancements include support for additional programming languages, integration of popular IDE plugins, and potential cloud-hosted services to extend functionality.

For those interested in optimizing their development processes and enhancing team efficiency, CodeContext provides essential tools and insights to streamline the onboarding experience. Visit the project's website for further information and resources.

Type-safe Kotlin Multiplatform i18n: auto-convert Android strings to cross-platform translations.

Tue, 14 Oct 2025 23:22:55 +0000

i18nKonfig — Zero-Config Internationalization for Kotlin Multiplatform

Tired of juggling strings.xml, runtime crashes, and messy translation setups?
I built i18nKonfig, a Gradle plugin that turns your Android strings into type-safe, multiplatform translations — automatically

From this:
getString(R.string.welcome_message, userName)

To this:
Text(I18nKonfig.welcome_message)

Works across Android, iOS, Desktop & Web
Compile-time safety (no missing strings)
Auto-migrates your Android resources
Zero manual setup — just ./gradlew build

I haven’t released it yet — just testing community interest.
Would you use something like this in your KMP projects? Or even help shape the first release?

ImagePickerKMP 1.0.23: Controling Camera Launch on iOS with directCameraLaunch

Wed, 03 Sep 2025 05:56:05 +0000

ImagePickerKMP 1.0.23: Controling Camera Launch on iOS with `directCameraLaunch`

The latest release of ImagePickerKMP (v1.0.23) brings a small but
powerful addition for iOS developers: a new flag called
directCameraLaunch.

This feature gives you control over whether the image picker should
open directly into the camera or show the source selection
dialog first.

The New Flag: `directCameraLaunch`

By default, the picker shows a dialog on iOS asking the user to choose
between camera and gallery.\
With directCameraLaunch, you can now change that behavior:

directCameraLaunch = true → Skips the dialog and opens the
camera immediately.\
directCameraLaunch = false → Keeps the dialog so the user can
choose.

Usage Example

Here's how you can use it with ImagePickerLauncher in your Compose
Multiplatform project:

    ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { result ->
                capturedPhoto = result
                showCamera = false
            },
            onError = {
                showCamera = false
            },
            onDismiss = {
                showImagePicker = false // Reset state when user doesn't select anything
            },
            directCameraLaunch = false // Set to true if you want to launch the camera directly Only IOS
        )
    )

Why This Matters

This new option provides better UX flexibility:

Apps that want a streamlined flow (e.g., scanning receipts, IDs, QR
codes) can go straight to the camera.\
Apps that want to offer both gallery and camera selection can keep
the dialog.

In short: you now have the best of both worlds, controlled with a simple
flag.

Dependency

To try it out, update your Gradle dependency to the latest version:

dependencies {
    implementation("io.github.ismoy:imagepickerkmp:1.0.23")
}

Final Thoughts

The directCameraLaunch flag makes ImagePickerKMP even more versatile
for real-world use cases. Whether your app prioritizes fast camera
access or user choice, you can now support both seamlessly with version
1.0.23.

Are you planning to use directCameraLaunch in your project? Would you
prefer the dialog or direct camera launch by default?

Github: https://github.com/ismoy/ImagePickerKMP

Simplifying Kotlin Multiplatform Setup with the New Android-KMP Plugin

Wed, 03 Sep 2025 05:55:57 +0000

Simplifying Kotlin Multiplatform Setup with the New Android-KMP Plugin

Kotlin Multiplatform (KMP) has been evolving rapidly, and one of the
latest updates brings a huge quality-of-life improvement for Android
developers: a new Gradle plugin tailored specifically for KMP projects.

What changed?

Traditionally, when building Android libraries in a KMP setup, we used
the plugin:

plugins {
    id("com.android.library")
    kotlin("multiplatform")
}

This worked, but it wasn't optimized for multiplatform workflows.
Developers often faced issues like slow builds, confusing android {}
blocks, or having to manually adjust configurations.

Now, Google and JetBrains recommend switching to:

plugins {
    id("com.android.kotlin.multiplatform.library")
    kotlin("multiplatform")
}

Why it matters

Faster builds -- the new plugin is optimized for KMP projects.\
Cleaner configuration -- no more awkward android {} blocks.\
Better IDE integration -- Android Studio and IntelliJ IDEA
understand the new plugin out of the box.\
Smarter defaults -- Android instrumented tests are disabled by
default (no more empty test setups you don't need).

In short: your Gradle setup becomes leaner, and your workflow smoother.

Migration example

If you already have a KMP module configured with com.android.library,
just replace it with the new plugin:

Before:

plugins {
    id("com.android.library")
    kotlin("multiplatform")
}

After:

plugins {
    id("com.android.kotlin.multiplatform.library")
    kotlin("multiplatform")
}

That's it! No extra boilerplate, no breaking changes.

Final thoughts

This update may look small, but it's a big step toward making Kotlin
Multiplatform easier and more enjoyable for Android developers. If
you're starting a new KMP project, you should adopt the new plugin right
away. For existing projects, the migration is painless and gives you a
smoother development experience.

What do you think about this change? Have you already tried the new
plugin in your projects?

BelZSpeedScann Ismoy

Sat, 30 Aug 2025 04:32:45 +0000

Scan Barcodes in Just 3 Lines with BelZSpeedScan (Kotlin Multiplatform/Android)

Scanning barcodes is a common feature in mobile apps — from retail and logistics to fintech and personal productivity. But implementing a barcode scanner that works across Android and iOS can be painful.

That’s why I built BelZSpeedScan
: a Kotlin Multiplatform library that lets you integrate a barcode scanner with just 3 lines of code.

Installation

Add the dependency from Maven Central:

implementation("io.github.ismoy:belzspeedscan:1.0.12")

Usage: Only 3 Lines

Here’s how you can open the scanner and capture the result in your Compose Multiplatform project:

 var showScanner by remember { mutableStateOf(false) } 

if (showScanner) {
    BelZSpeedScanner(
        onCodeScanned = { code -> 
            // Handle scanned result here
        }
    )
}

Button(onClick = { showScanner = true }) {
    Text("Scan")
}

That’s it! When the user taps Scan, the camera opens, detects the barcode, and returns the result in onCodeScanned.

Why BelZSpeedScan?

Multiplatform ready: Works on Android & iOS.
Zero boilerplate: No need to handle camera APIs or decoding manually.
Production-ready: Lightweight, fast, and easy to drop into your
project.

Get Started

Check out the full documentation and source code here:
https://github.com/ismoy/BelZSpeedScan

If you try it out, I’d love your feedback and contributions! ⭐

Android implementation

Mon, 25 Aug 2025 22:36:56 +0000

Tutorial: How to Use ImagePickerKMP in Android with Jetpack Compose

Picking images from the gallery or capturing from the camera has always been tricky in Android: dealing with permissions, intents, and different APIs.
With ImagePickerKMP, you can handle it in a declarative and clean way using Jetpack Compose, without worrying about the platform-specific details.

In this tutorial, you’ll learn how to:

Integrate ImagePickerKMP in an Android app with Jetpack Compose.
Show a live camera preview.
Select images from the gallery.
Customize the UI with the Customization API.

Step 1: Setup the dependency

Add the dependency in your build.gradle.kts (module level):

dependencies {
    implementation("io.github.ismoy:imagepickerkmp:1.0.22") // Replace with the latest version
}

Step 2: Basic usage in Compose

ImagePickerKMP exposes an ImagePicker composable you can use directly.
Here’s the minimal example to open the camera or gallery:

ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { result ->
               // result here            },
            onError = {
                //ppermission denied error on something else
            },
            onDismiss = {
                showImagePicker = false // Reset state when user doesn't select anything
            }
        )
    )

✅ This automatically handles:

Camera permissions.

Returning the result as URI / uri.

Step 3: UI Customization

ImagePickerKMP provides a Customization API so you can style your picker UI.
For example, let’s customize the TopBar and bottom controls:

ImagePickerLauncher(
                            config = ImagePickerConfig(
                                onPhotoCaptured = { result ->
                                    photoResult = result
                                    showCameraPicker = false
                                    isPickerSheetVisible = false
                                },
                                onError = {
                                    showCameraPicker = false
                                    isPickerSheetVisible = false
                                },
                                onDismiss = {
                                    showCameraPicker = false
                                    isPickerSheetVisible = false
                                },
                                 cameraCaptureConfig = CameraCaptureConfig(
                                    permissionAndConfirmationConfig = PermissionAndConfirmationConfig(
                                        customConfirmationView = { photoResult, onConfirm, onRetry ->
                                            CustomAndroidConfirmationView(
                                                result = photoResult,
                                                onConfirm = onConfirm,
                                                onRetry = onRetry
                                            )
                                        },
                                        customDeniedDialog = { onRetry ->
                                            CustomPermissionDialog(
                                                title = "Permission Required",
                                                message = "We need access to the camera to take photos",
                                                onRetry = onRetry
                                            )
                                        },
                                        customSettingsDialog = { onOpenSettings ->
                                            CustomPermissionSettingsDialog(
                                                title = "Go to Settings",
                                                message = "Camera permission is required to capture photos. Please grant it in  settings",
                                                onOpenSettings = onOpenSettings
                                            )
                                        }
                                    )
                                )
                            )
                        )

With this, you completely control the UI while still using the library’s camera engine.

Step 4: Multiple image selection

You can also allow multiple images to be selected from the gallery:

 GalleryPickerLauncher(
        onPhotosSelected = { photos ->
           //result
        },
        onError = { error ->
           //error
        },
        onDismiss = {
           //when the result is null
        },
        allowMultiple = true, // False for single selection
        mimeTypes = listOf("image/jpeg", "image/png"), // Optional: filter by type
    )

Conclusion

With ImagePickerKMP you can:

Easily integrate camera and gallery in Jetpack Compose.

Customize the UI and user experience.

Use the same API across Android & iOS with Kotlin Multiplatform.

This saves you from handling ActivityResultContracts, Uri parsing, and permission requests manually — all while keeping your code clean and declarative.

BelZSpeedScan: A Kotlin Multiplatform Library for Fast Document Scanning

Fri, 22 Aug 2025 02:21:38 +0000

BelZSpeedScan: A Kotlin Multiplatform Library for Fast Document Scanning

Building mobile apps that need document scanning is often a challenge:

You want high performance.

You need cross-platform support (Android & iOS).

And you don’t want to reinvent the wheel every time.

That’s why I created [BelZSpeedScan][1]
, an open-source Kotlin Multiplatform (KMP) library that brings fast, clean and reliable document scanning to your apps with minimal setup.
[1]: https://github.com/ismoy/BelZSpeedScan

Why BelZSpeedScan?

Most scanning solutions are either locked to one platform, closed-source, or too heavy to integrate. BelZSpeedScan is designed with developers in mind:

✅ Cross-platform – Works on Android and iOS with a shared API.
✅ Fast & lightweight – Optimized camera preview and capture pipeline.
✅ Clean architecture – Built with separation of concerns, easy to extend.
✅ Open source – MIT licensed and community-driven.

Installation

Add the dependency in your build.gradle.kts (publish on MavenCentral):

implementation("io.github.ismoy:belzspeedscan:1.0.12")

Don’t forget to configure iOS-specific permissions in your Info.plist file:

<key>NSCameraUsageDescription</key>
<string>We need access to the camera to scan QR.</string>

Quick Usage

Here’s how simple it is to start a camera preview and capture a scanned code:

 var showScanner by remember { mutableStateOf(false) }

if (showScanner) {
    BelZSpeedScanner(
     onCodeScanned = { code ->}//result scan   
   )
}

Button(onClick = { showScanner = true }) {
    Text("Scan")
}

Analytics Integration

BelZSpeedScan includes an optional analytics system designed with privacy in mind:

Privacy-focused: No personal data is collected
Configurable: Granular control over what data is collected
Multi-platform: Works on both Android and iOS
Custom Callbacks: Support for custom analytics implementations

Contribute

BelZSpeedScan is still in its early days. If you’re building apps with Kotlin Multiplatform and need fast scanning, I’d love your feedback, issues, and contributions!

I built BelZSpeedScan because I needed a reliable KMP solution for code scanning. Now I’m sharing it with the community. If you find it useful, consider comment the post and share

Kotlin Multiplatform + Compose: Unified Camera & Gallery Picker with Expect/Actual

Thu, 21 Aug 2025 00:33:16 +0000

Kotlin Multiplatform + Compose: Unified Camera & Gallery Picker with Expect/Actual and Permission Handling

Handling image capture and gallery access in mobile apps is a task most developers face – but doing it the Kotlin Multiplatform way, using Compose, introduces unique challenges.

In this post, I’ll walk through how to create a shared, composable-based image picker using Kotlin’s expect/actual mechanism. The result is a unified camera and gallery experience for Android and iOS, fully integrated with Compose Multiplatform UI.

The Problem with Platform-Specific Image Pickers

Image picking requires different APIs on Android and iOS:

• Android: ActivityResultContracts, CameraX, media permissions

• iOS: UIImagePickerController, delegate protocols, Info.plist

• Compose Multiplatform has no built-in media picker

• Permissions and file access require different logic per platform

We want to hide this complexity and give developers a clean, shared interface.

Step 1: Define expect functions in commonMain

We declare our public API with expect composables. These serve as the shared contract across platforms.

ImagePickerLauncher

@Composable
expect fun ImagePickerLauncher(
    config: ImagePickerConfig
)

This picker handles capturing a photo with the camera. The config provides callbacks like onPhotoCaptured, onError, and onDismiss.

GalleryPickerLauncher

@Composable
expect fun GalleryPickerLauncher(
    onPhotosSelected: (List<PhotoResult>) -> Unit,
    onError: (Exception) -> Unit,
    onDismiss: () -> Unit = {},
    allowMultiple: Boolean = false,
    mimeTypes: List<String> = listOf("image/*"),
    selectionLimit: Long = SELECTION_LIMIT
)

This version supports selecting one or multiple images and filtering by MIME type.

Android Implementation

The Android actual implementation uses Compose with platform-aware context handling:

@Composable
actual fun ImagePickerLauncher(config: ImagePickerConfig) {
    val context = LocalContext.current
    if (context !is ComponentActivity) {
        config.onError(Exception("Invalid context"))
        return
    }

    CameraCaptureView(
        activity = context,
        onPhotoResult = { result -> config.onPhotoCaptured(result) },
        onPhotosSelected = config.onPhotosSelected,
        onError = config.onError,
        onDismiss = config.onDismiss,
        cameraCaptureConfig = config.cameraCaptureConfig
    )
}

For gallery access:

@Composable
actual fun GalleryPickerLauncher(...) {
    val context = LocalContext.current
    if (context !is ComponentActivity) {
        onError(Exception("Invalid context"))
        return
    }
    val config = GalleryPickerConfig(
        context = context,
        onPhotosSelected = onPhotosSelected,
        onError = onError,
        onDismiss = onDismiss,
        allowMultiple = allowMultiple,
        mimeTypes = mimeTypes
    )
    GalleryPickerLauncherContent(config)
}

iOS Implementation

On iOS, we integrate UIKit behavior with Compose state, launching the correct picker depending on user action:

@Composable
actual fun ImagePickerLauncher(config: ImagePickerConfig) {
    var showDialog by remember { mutableStateOf(true) }
    var askCameraPermission by remember { mutableStateOf(false) }
    var launchCamera by remember { mutableStateOf(false) }
    var launchGallery by remember { mutableStateOf(false) }

    handleImagePickerState(
        showDialog = showDialog,
        askCameraPermission = askCameraPermission,
        launchCamera = launchCamera,
        launchGallery = launchGallery,
        config = config,
        onDismissDialog = { showDialog = false },
        onCancelDialog = {
            showDialog = false
            config.onDismiss()
        },
        onRequestCameraPermission = { askCameraPermission = true },
        onRequestGallery = { launchGallery = true },
        onCameraPermissionGranted = {
            askCameraPermission = false
            launchCamera = true
        },
        onCameraPermissionDenied = {
            askCameraPermission = false
            config.onDismiss()
        },
        onCameraFinished = { launchCamera = false },
        onGalleryFinished = { launchGallery = false }
    )
}

And for gallery selection:

@Composable
actual fun GalleryPickerLauncher(...) {
    LaunchedEffect(Unit) {
        if (allowMultiple) {
            val selectedImages = mutableListOf<PhotoResult>()
            GalleryPickerOrchestrator.launchGallery(
                onPhotoSelected = { result ->
                    selectedImages.add(result)
                    onPhotosSelected(selectedImages.toList())
                },
                onError = onError,
                onDismiss = onDismiss,
                allowMultiple = true,
                selectionLimit = selectionLimit
            )
        } else {
            GalleryPickerOrchestrator.launchGallery(
                onPhotoSelected = { result -> onPhotosSelected(listOf(result)) },
                onError = onError,
                onDismiss = onDismiss,
                allowMultiple = false,
                selectionLimit = 1
            )
        }
    }
}

How It All Comes Together in Compose

With both platform implementations hidden, your shared Compose code stays clean:

if (showCamera) {
    ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { photo -> capturedPhoto = photo },
            onError = { showError = true },
            onDismiss = { showCamera = false }
        )
    )
}

And for gallery:

if (showGallery) {
    GalleryPickerLauncher(
        onPhotosSelected = { photos -> selectedImages = photos },
        onError = { showError = true },
        onDismiss = { showGallery = false },
        allowMultiple = true
    )
}

Why This Pattern Works

• Shared UI remains fully declarative and platform-agnostic

• Permissions and platform quirks are abstracted

• It respects Compose principles and KMP architecture

• You avoid boilerplate and platform channels

Conclusion

Kotlin Multiplatform offers powerful abstractions when used correctly. By leveraging expect/actual and fully composable APIs, we've built a clean, testable, and scalable image picker that works across platforms.

You can explore the full implementation in ImagePickerKMP, an open-source project that follows these principles. Whether you use it directly or as inspiration, it's a practical example of Compose and KMP working in harmony.

OpenTelemetry Tracing on the JVM

Thu, 07 Aug 2025 17:24:20 +0000

You may know I'm a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language.

In this post, I want to compare the different zero-code OpenTelemetry approaches on the JVM, covering the most widespread:

Spring Boot with Micrometer Tracing
Spring Boot with the OpenTelemetry Agent
OpenTelemetry Spring Boot Starter
Quarkus
Quarkus with the OpenTelemetry Agent

Commonalities

I keep the architecture pretty simple:

I'm using Reactive data access on both the remote service and the database to spice up things a bit, more specifically, Kotlin coroutines. Here's the general structure:

val products = coroutineScope {
    val ping = async {
        // Call the ping service
    }
    val products = async {
        // Query the database
    }
    println("Received ping response: ${ping.await()}")
    products.await()
}

Here are the features for each stack:

	Quarkus	Spring Boot
Web	Mutiny	WebFlux
HTTP client	REST client	`WebClient`
Database access pattern	Record	Repository
Database access	Hibernate Reactive with Panache	R2DBC

Running the OpenTelemetry Agent

The OpenTelemetry Java Agent is the first approach I used regarding OpenTelemetry.

The only necessary configuration is to set the agent when running the JVM:

java -javaagent:opentelemetry-javaagent.jar -jar otel-boot-agent.jar

The agent supports lots of frameworks and libraries, including Spring Boot, Quarkus, Ktor, Spark, and many others. When the application flow finds a supported framework/library, it logs a span.

The Agent upholds the standard OpenTelemetry environment variables.

services:
  otel-boot-agent:
    build: otel-boot-agent
    environment:
      OTEL_SERVICE_NAME: OTEL Boot Agent                             #1
      OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4318                #2
      OTEL_METRICS_EXPORTER: none                                    #3
      OTEL_LOGS_EXPORTER: none                                       #3

OpenTelemetry service name
OpenTelemetry endpoint; Spring Boot uses HTTP
Neither metrics nor logs

Here's the Jaeger trace when calling the endpoint on the Spring Boot application:

And here's the one on Quarkus:

Spring Boot features an additional span that displays the repository call. There's no such thing available on Quarkus, as I'm using the Record pattern to access the data.

The Agent outputs the SQL query in both frameworks, i.e., SELECT product.* FROM product. The Java Agent works out-of-the-box.

Micrometer Tracing on Spring Boot

Spring Boot provides dedicated OpenTelemetry support via Micrometer Tracing.

>Micrometer Tracing provides a simple facade for the most popular tracer libraries, letting you instrument your JVM-based application code without vendor lock-in. It is designed to add little to no overhead to your tracing collection activity while maximizing the portability of your tracing effort.

Besides the Micrometer Tracing dependency itself, you need additional ones:

The Spring Boot Actuator
A bridge–OpenTelemetry
An exporter–OpenTelemetry as well

Configuration doesn't follow the OpenTelemetry standard:

services:
  otel-boot-micrometer:
    environment:
      SPRING_APPLICATION_NAME: OTEL Micrometer                       #1-2
      MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #1-3

Different values from the OpenTelemetry specification
The Spring application name serves as the OpenTelemetry service name
Full path to the API endpoint

The above setup doesn't register the database call. To fix it, we need an additional dependency: R2DBC Proxy.

The new trace contains the database span:

You might notice another issue: calls to the service and the database are sequential, where they should be parallel. It stems from Spring Boot not handling context propagation properly to the coroutine scope. It's an underlying work from the Spring team. Subscribe to the GitHub issue if you're interested.

OpenTelemetry Spring Boot Starter

The OpenTelemetry project provides a Spring Boot starter. You need only a single dependency, and like other starters, Spring Boot magic takes care of configuration:

<dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency>

The result is very similar to the previous one, including the not-parallel-but-serial issue.

Quarkus

We saw the results of using the OpenTelemetry Agent in the first section. It's quite straightforward to use OpenTelemetry without the Agent; you need a single dependency:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-opentelemetry</artifactId>
</dependency>

Quarkus prefixes regular OpenTelemetry environment variable names with QUARKUS_:

services:
  otel-quarkus:
    environment:
      QUARKUS_OTEL_SERVICE_NAME: OTEL Quarkus                        #1
      QUARKUS_OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: http://jaeger:4317 #2

OpenTelemetry service name
OpenTelemetry endpoint; Quarkus uses gRPC

Results are as expected:

Discussion

OpenTelemetry approaches vary widely in both configuration and results. Unless you're prevented from using Java agents for technical or organizational reasons, I recommend using the OpenTelemetry Agent first. It handles everything you can throw at it out of the box, including the most common libraries. Barring that, you need deep knowledge of the stack you're using, lest results don't represent what happens in reality.

The complete source code for this post can be found on GitHub.

To go further:

Originally published at A Java Geek on August 3^rd, 2025

Pattern-matching across different languages

Thu, 24 Jul 2025 19:51:56 +0000

Pattern matching is a major feature in software development. While pattern matching applies in several locations, its current usage is limited to switch case blocks. I want to compare the power of pattern matching across a couple of programming languages I'm familiar with in this post.

I assume that every reader is familiar with the switch case syntax inherited from C. In short:

The switch clause references a value-returning statement
Each case clause sets another statement; if the value matches the statement, it executes the related block
case clauses are evaluated in order. The first clause that matches gets its block executed
In C, case clauses are fall-through; you need to explicitly break to escape the switch, otherwise, the next case is evaluated

Java's pattern matching

I'll start with Java, as it was the first programming language I used in a professional context.

Java's pattern matching has evolved a lot across its versions. Here's the "official" sample for version 23, slightly amended. It defines several Shape implementations and a static method to evaluate its perimeter. It's definitely not a good example of Object-Oriented Programming.

interface Shape { }
record Rectangle(double length, double width) implements Shape { }
record Circle(double radius) implements Shape { }

public class Main {
    static double getPerimeter(Shape s) throws IllegalArgumentException {
        return switch (s) {                                                 //1
            case Rectangle r when r.length() == r.width() -> {              //2
                System.out.println("Square detected");
                    yield 4 * r.length();
            }
            case Rectangle r ->                                             //3
                2 * r.length() + 2 * r.width();
            case Circle c ->                                                //4
                2 * c.radius() * Math.PI;
            default ->                                                      //5
                throw new IllegalArgumentException("Unrecognized shape");
        };
    }
}

Reference the Shape parameter as s
Evaluate whether s is a Rectangle and whether the Rectangle is a square
Evaluate whether s is a Rectangle
Evaluate whether s is a Circle
If none of the previous clauses match, default to throwing an exception

This Java version will be our baseline.

Characteristics of the new `switch` syntax

The new syntax has some advantages over the legacy non-arrow switch inherited from C.

C-style case clauses are fall-through. Once the runtime has executed a case block, it runs the next case block. To avoid it, you need to set a break explicitly. In the not-so-good old days, some developers leveraged this feature to avoid code duplication. However, experience has shown that it was too much of a cause of potential bugs: modern coding practices tend to avoid it. Yet, it's too easy to forget a break. With the new arrow syntax, the runtime only evaluates the corresponding case block.

C-style case clauses only evaluate simple values. The community celebrated Java 7 as a huge boon when it allowed String values. Java 21 went even further: coupled with the arrow syntax, it allowed for switching on types. In the above example, we check the exact Shape type.

Additionally, if switching on classes and if the class hierarchy is sealed, the compiler can automatically detect missing cases. Finally, version 24 added the additional optional when filter.

On the flip side, in the old C syntax, the runtime jumps directly to the correct case clause. The new arrow syntax evaluates them sequentially, exactly like if with if else statements.

In the next sections, we will port the code to other languages.

Scala's pattern matching

Scala's pattern matching has been second to none since its inception. Kotlin drew a lot of inspiration from it.

trait Shape
case class Rectangle(length: Double, width: Double) extends Shape
case class Circle(radius: Double) extends Shape

def getPerimeter(s: Shape) = {
  s match {                                                                 //1
    case Rectangle(length, width) if length == width =>                     //2-3
      println("Square detected")
      4 * length
    case Rectangle(length, width) => 2 * length + 2 * width                 //3-4
    case Circle(radius) => 2 * radius * Math.PI                             //3-5
    case _ => throw new IllegalArgumentException("Unrecognized shape")      //6
  }
}

Use the s reference directly
Evaluate whether s is a Rectangle and whether the Rectangle is a square
Scala additionally matches the class attributes
Evaluate whether s is a Rectangle
Evaluate whether s is a Circle
If none of the previous clauses match, default to throwing an exception

Kotlin's pattern matching

Let's translate Java's code to Kotlin. For that, we must activate the experimental Xwhen-guards compilation feature described in KEEP-371.

interface Shape
data class Rectangle(val length: Double, val width: Double): Shape
data class Circle(val radius: Double): Shape

fun getPerimeter(s: Shape) = when (s) {                                     //1
        is Rectangle if s.length == s.width -> {                            //2
            println("Square detected")
            4 * s.length
        }
        is Rectangle -> 2 * s.length + 2 * s.width                          //3
        is Circle -> 2 * s.radius * Math.PI                                 //4
        else -> throw IllegalArgumentException("Unknown shape")             //5
    }
}

Reference the Shape parameter as s
Evaluate whether s is a Rectangle and whether the Rectangle's width is equal to its height
Evaluate whether s is a Rectangle
Evaluate whether s is a Circle
If none of the previous clauses match, default to throwing an exception

Kotlin's pattern matching greatly resembles Java's, with slight syntax changes, e.g., if replaces when.

The comparative evolution of Kotlin vs. Java in pattern matching is quite enlightening. Java lagged behind the legacy C syntax, while Kotlin could already match on concrete types from the beginning. In 2020, Java 14 reduced the gap with the arrow operator; one year later, Java 16 closed the gap completely with the ability to match on concrete types. Finally, Java 23 added the when clause.

The experimental nature of Kotlin's if means Java has overtaken Java–at least in this area! It's rare enough to be noted.

Python's pattern matching

Before, Python didn't offer anything similar to the switch statement of the above JVM languages. From version 3.10, it does offer the same capability in an elegant way:

class Shape:
    pass


class Rectangle(Shape):
    def __init__(self, length: float, width: float):
        self.length = length
        self.width = width


class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius


def get_perimeter(s: Shape) -> float:
    match s:
        case Rectangle(length=l, width=w) if l == w:
            print("Square detected")
            return 4 * l
        case Rectangle(length=l, width=w):
            return 2 * l + 2 * w
        case Circle(radius=r):
            return 2 * pi * r
        case _:
            raise ValueError("Unknown shape")

The runtime evaluates the case clauses sequentially, as in the JVM languages.

Rust's pattern matching

Rust's approach to memory management doesn't play well with checking types. In short, Rust offers two base concepts:

Structures are structured data placeholders; their memory size is known at compile time
Traits are contracts, akin to interfaces
You can provide an implementation of a trait for a structure
Referencing a variable by its trait has consequences.
Since the reference can point to structures of different sizes, the compiler can't know its size at compile-time and must place the variable on the heap instead of the stack.

I tried to port the original code to Rust one-to-one for educational purposes. The original Java doesn't take advantage of polymorphism; it is not great. In Rust, it's even uglier. It's interesting to realize that while Rust isn't an Object-Oriented programming language, it leads you to use polymorphism.

Warning: I don't recommend the following code and will deny any association with it!

trait Shape: Any {
    fn as_any(&self) -> &dyn Any;                                     //1
}

struct Circle {
    radius: f64,
}

struct Rectangle {
    width: f64,
    height: f64,
}

impl Shape for Circle {
    fn as_any(&self) -> &dyn Any {                                    //2
        self
    }
}
impl Shape for Rectangle {
    fn as_any(&self) -> &dyn Any {                                    //2
        self
    }
}

fn get_perimeter(s: Box<dyn Shape>) -> f64 {
    match s.as_any() {                                                //3
        any if any.is::<Rectangle>() => {                             //4
            let rectangle = any.downcast_ref::<Rectangle>().unwrap(); //5
            if rectangle.width == rectangle.height {
                println!("Square matched");
                4.0 * rectangle.width
            } else {
                2.0 * (rectangle.width + rectangle.height)
            }
        }
        any if any.is::<Circle>() => {                                //4
            let circle = any.downcast_ref::<Circle>().unwrap();       //5
            2.0 * std::f64::consts::PI * circle.radius
        }
        _ => panic!()
    }
}

Rust's type system doesn't offer a way to get the type of a variable. We must create a dedicated function for that.
Implement the function for structures
Match on the underlying structure type
Check the type
Downcast to the underlying structure to use its fields

This artificial code port above misrepresents Rust's pattern-matching abilities. It applies in many places.

Conclusion

Among all languages described in the post, Scala was the first to provide pattern-matching in switch clauses. For many years, it was the Grail that others tried to catch up with; Kotlin and Java have finally reached this stage.

Outside of the JVM, Python and Rust feature powerful pattern-matching capabilities.

With destructuring, pattern matching is a huge help to developers who want to write readable and maintainable code.

The complete source code for this post can be found on GitHub.

To go further:

Originally published at A Java Geek on July 20^th, 2025

RingtoneSmartKit – Android Ringtone Tool

Thu, 17 Jul 2025 00:33:22 +0000

RingtoneSmartKit — Effortless Android Ringtone Management with Kotlin

Tired of fragmented and inconsistent ringtone management in your Android apps? RingtoneSmartKit is the modern, extensible Kotlin library I built to simplify setting and managing system ringtones, alarms, notifications, and custom contact tones with ease.
We built this because Android's native ringtone handling is often
fragmented and complex. We wanted a library that just works—no fuss,
no boilerplate, no Context juggling.

What Makes it Special?

Effortless Control: Easily set ringtones for calls, alarms, and notifications.
Contact-Specific Tones: Assign unique tones to contacts with zero hassle.
Flexible Audio Sources: Handle any audio source, whether from your app's assets or content URIs.
Context-Free API: Use it anywhere in your app without needing to pass a Context or Activity.
Clean Architecture: Built on robust principles for future-proof extensibility.

See How Simple It Is

Setting a system ringtone or customizing one for a specific contact is straightforward:

Set a System Ringtone

RingtoneHelper.setSystemRingtone(
    source = RingtoneSource.FromAssets("ringtones/my_ringtone.mp3"),
    target = SystemTarget.Call // or Notification, Alarm
).onSuccess {
    println("✅ System ringtone set successfully")
}.onFailure { error ->
    println("❌ Error setting system ringtone: ${error.message}")
}.launch()

Set a Ringtone for a Specific Contact

RingtoneHelper.setContactRingtone(
    source = RingtoneSource.FromStorage(Uri.parse("content://media/internal/audio/media/10")),
    target = ContactTarget.ByPhone("+1234567890")
).onSuccess { contact ->
    println("✅ Ringtone set for contact: ${contact.displayName}")
}.onFailure { error ->
    println("❌ Error setting contact ringtone: ${error.message}")
}.launch()

Enjoy!

Happy coding!

A Kotlin library that simplifies setting and managing Android ringtones programmatically

Tue, 15 Jul 2025 13:02:59 +0000

RingtoneSmartKit – Simplified Android Ringtone Management

Hi devs!
I recently developed and released RingtoneSmartKit, an open-source Kotlin library that simplifies ringtone management on Android devices — with a modern, clean architecture.

Key Features

Set system ringtones for alarms, notifications, and incoming calls effortlessly
Assign custom ringtones to individual contacts
Support multiple audio sources like assets, raw resources, and content URIs
Context-free usage — no need to pass Context or Activity explicitly
Built for extensibility and clean architecture, ensuring long-term maintainability

Why RingtoneSmartKit?

Android doesn’t offer a simple, reusable way to manage ringtones programmatically.
This library fills that gap by providing a developer-friendly API that handles the heavy lifting behind the scenes.

You can use it from anywhere in your codebase — without boilerplate or system-specific quirks.

What’s Next?

I’m exploring:

Vibration pattern support (thanks to a great suggestion!)
Enhanced customization options
More examples in Compose, Java, and XML

Contribute & Feedback

I welcome your feedback, ideas, and contributions to make this library even better.
Check out the GitHub repo and feel free to open issues or pull requests.

GitHub Repository

Thanks for reading, and happy coding!

Testing an OpenRewrite recipe

Thu, 26 Jun 2025 20:18:12 +0000

For the last two weeks, I've kicked the tires of OpenRewrite. At first, I created a recipe to move Kotlin source files as per the official recommendations with a set package name. I then improved the recipe to compute the root automatically. In both versions, I thoroughly tested the recipe. However, my testing approach was wrong. In this post, I want to describe my mistakes, and how I fixed them.

The naive approach

I originally approached the testing of the recipe in a very naive way, to say the least. As explained in the first post, I used OpenRewrite's low-level APIs. Here's what I wrote:

// Given
val parser = KotlinParser.builder().build()                                      //1
val cu = parser.parse(
    InMemoryExecutionContext(),                                                  //2
    sourceCode
).findFirst()                                                                    //3
 .orElseThrow { IllegalStateException("Failed to parse Kotlin file") }           //3
val originalPath = Paths.get(originalPath)
val modifiedCu = (cu as K.CompilationUnit).withSourcePath(originalPath)          //4

// When
val recipe = FlattenStructure(configuredRootPackage)
val result = recipe.visitor.visit(modifiedCu, InMemoryExecutionContext())        //5

// Then
val expectedPath = Paths.get(expectedPath)
assertEquals(expectedPath, (result as SourceFile).sourcePath)                    //6

Build the Kotlin parser
Set an execution context; I had to choose and the in-memory one was the easiest.
Boilerplate to get the single compilation unit from the stream
Cast to a K.CompilationUnit because we know better
Explicitly call the visitor to visit
Assert the recipe moved the file

The above works, but requires a deep understanding of how OpenRewrite works. I didn't have that understanding, but it was good enough. It came back to bite me when I improved the recipe to compute the root.

As explained in the last post, I switched from a regular recipe to a scanning recipe. I had to provide at least two source files to test the new capability. I came up with the following:

// When
val recipe = FlattenStructure()
val context = InMemoryExecutionContext()
val acc = AtomicReference//String?(null)
recipe.getScanner(acc).visit(modifiedCu1, context)                               //1
recipe.getScanner(acc).visit(modifiedCu2, context)                               //1
val result1 = recipe.getVisitor(acc).visit(modifiedCu1, context)                 //2
val result2 = recipe.getVisitor(acc).visit(modifiedCu2, context)                 //2

Get the scanner and visit source files to compute the root
Get the visitor and visit source files to move the file

It worked, but I admit it was a lucky guess. More involved recipes would require a deeper knowledge of how OpenRewrite works, with more potential bugs. Fortunately, OpenRewrite provides the means to keep the testing code at the right level of abstraction.

The nominal approach

The nominal approach involves a couple of out-of-the-box classes; it requires a new dependency. I didn't do it before, so now is a good time: let's introduce a BOM to align all of OpenRewrite's dependencies:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-recipe-bom</artifactId>
            <version>3.9.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

It's now possible to add the dependency without a version, as Maven resolves it from the above BOM.

<dependency>
    <groupId>org.openrewrite</groupId>
    <artifactId>rewrite-test</artifactId>
    <scope>test</scope>
</dependency>

This brings a couple of new classes to the project:

The documentation states your test class should inherit from RewriteTest, which provides rewriteRun. The latter runs the recipe, without any need to know about its inner workings, e.g., the above in-memory execution context. It's the abstraction level that we want. Assertions offers static methods to assert. OpenRewrite also advises using Assertion4J, which I fully endorse. Yet, I didn't do it to keep the comparison simpler.

We can rewrite the previous snippet to:

rewriteRun(                                                                     //1
    kotlin(sourceCode1) { spec ->                                               //2-3-4
        spec.path("src/main/kotlin/ch/frankel/blog/foo/Foo.kt")                 //5
        spec.afterRecipe {                                                      //6
            assertEquals(                                                       //7
                Paths.get("src/main/kotlin/foo/Foo.kt"),
                it.sourcePath
            )
        }
    },
    kotlin(sourceCode2) { spec ->                                               //2-3-4
        spec.path("src/main/kotlin/org/frankel/blog/bar/Bar.kt")                //5
        spec.afterRecipe {                                                      //6
            assertEquals(                                                       //7
                Paths.get("src/main/kotlin/bar/Bar.kt"),
                it.sourcePath
            )
        }
    },
)

Run the recipe
kotlin transform the string into a SourceSpecs
I'm using Kotlin, but java does the same for regular Java projects
Allow customizing the source specification
Customize the path
Hook after running the recipe
Assert that the recipe updated the path according to the expectations

You may have noticed that the rewritten code doesn't specify which recipe it's testing. That's the responsibility of the RewriteTest.defaults() method.

class FlattenStructureComputeRootPackageTest : RewriteTest {

    override fun defaults(spec: RecipeSpec) {
        spec.recipe(FlattenStructure())
    }

    // Rest of the class
}

Don't forget cycles

If you followed the above instructions, there's a high chance your test fails with this error message:

java.lang.AssertionError: Expected recipe to complete in 0 cycle, but took 1 cycle. This usually indicates the recipe is making changes after it should have stabilized.

We need to turn to the documentation to understand this cryptic message:

>The recipes in the execution pipeline may produce changes that in turn cause another recipe to do further work. As a result, the pipeline may perform multiple passes (or cycles) over all the recipes in the pipeline again until either no changes are made in a pass or some maximum number of passes is reached (by default 3). This allows recipes to respond to changes made by other recipes which execute after them in the pipeline.

>-- Execution Cycles

Because the recipe doesn't rely on any other and no other recipe depends on it, we can set the cycle to 1.

override fun defaults(spec: RecipeSpec) {
    spec.recipe(FlattenStructure())
        .cycles(1)                                                              //1
        .expectedCyclesThatMakeChanges(1)                                       //2
}

Set how many cycles the recipe should run
Set to 0 if the recipe isn't expected to make changes

Criticisms

I like what the OpenRewrite testing classes bring, but I have two criticisms.

First and foremost, why does OpenRewrite assert the number of cycles by default? It bit me in the back for no good reason. I had to dig into the documentation and understand how OpenRewrite works, although the testing API is supposed to shield users from its inner workings. I also can't help but wonder about the defaults.

public class RecipeSpec {

    @Nullable
    Integer cycles;

    int getCycles() {
        return cycles == null ? 2 : cycles;                                     //1
    }

    int getExpectedCyclesThatMakeChanges(int cycles) {
        return expectedCyclesThatMakeChanges == null ? cycles - 1 :             //2
                expectedCyclesThatMakeChanges;
    }

    // Rest of the class body
}

Why two cycles by default? Shouldn't one be enough in most cases?
Why cycles - 1 by default?

My second criticism is about how the provided testing classes make you structure your tests. I like to structure them into three parts:

Given: describe the initial state
When: execute the to-be-tested code
Then: assert the final state conforms to what I expect.

With OpenRewrite's abstractions, the structure is widely different from the above.

Conclusion

In this post, I migrated my ad hoc test code to rely on OpenRewrite's provided classes. Even though they are not exempt from criticism, they offer a solid abstraction layer and make tests more maintainable.

The complete source code for this post can be found on GitHub.

To go further:

Originally published at A Java Geek on June 22^nd, 2025

Improving my previous OpenRewrite recipe

Thu, 19 Jun 2025 09:26:47 +0000

I started discovering OpenRewrite last week by writing a Kotlin recipe that moves Kotlin files according to the official directory structure recommendation. I mentioned some future works, and here they are. In this post, I want to describe how to compute the root package instead of letting the user set it.

Reminder

I developed last week a recipe to follow the Kotlin recommendation regarding directory structure:

>In pure Kotlin projects, the recommended directory structure follows the package structure with the common root package omitted. For example, if all the code in the project is in the org.example.kotlin package and its subpackages, files with the org.example.kotlin package should be placed directly under the source root, and files in org.example.kotlin.network.socket should be in the network/socket subdirectory of the source root.

>-- Directory structure

In a Java project, if you have packages ch.frankel.foo, ch.frankel.bar, and ch.frankel.baz, you'll get the following structure:

src
 |__ main
    |__ java
       |__ ch
          |__ frankel
             |__ foo
             |__ bar
             |__ baz

In Kotlin projects, many developers follow the same structure as above, but it can be flattened as:

src
 |__ main
    |__ kotlin
       |__ foo
       |__ bar
       |__ baz

The work

My recipe's original version mandated that you configure the root package yourself, e.g., ch.frankel for the above example. However, it should be possible to compute it automatically, from looking at the source files. It adds an extra step to the process: before moving the file to the root, the recipe should look at each source file, get the package, compute the longest prefix with the existing root, make it the root, and go to the next source file. The regular Recipe doesn't work in this case. We need to switch to a ScanningRecipe:

>If a recipe needs to generate new source files or needs to see all source files before making changes, it must be a ScanningRecipe. A ScanningRecipe extends the normal Recipe and adds two key objects: an accumulator and a scanner. The accumulator object is a custom data structure defined by the recipe itself to store any information the recipe needs to function. The scanner object is a visitor which populates the accumulator with data.

>-- Scanning recipes

Scanning recipes offer two steps: the first to gather data, the second to do the work.

We must design our algorithm within the constraints of OpenRewrite, and they are the following: in the first phase, for each source file, OpenRewrite will call the getScanner() method that returns a visitor of our choice. In turn, OpenRewrite calls the visitor's methods, which can access the accumulator.

My first naive approach was to use a collection as the accumulator, but it's not necessary. The algorithm is much simpler if we set a mutable placeholder that holds the package root and update it if necessary during each visit. The initial value should be null.

If the value is null, which happens on the first visitor, set the package root to the source file's package.
If the value is an empty string, skip–see below.
In any other case, compute the new package root by finding the longest prefix between the existing package root and the source file's package.

It might result in an empty string, indicating that packages have no common root, e.g., ch.frankel.foo and org.frankel.foo.

Here's the updated code:

class FlattenStructure(private val rootPackage: String?) : ScanningRecipe<AtomicReference<String?>>() { //1-2

  constructor() : this(null)                                                   //3

  override fun getDisplayName(): String = "Flatten Kotlin package directory structure"
  override fun getDescription(): String =
    "Move Kotlin files to match idiomatic layout by omitting the root package according to the official recommendation."

  override fun getInitialValue(ctx: ExecutionContext) = AtomicReference<String?>(null) //4

  override fun getScanner(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
    if (rootPackage != null) return TreeVisitor.noop<Tree, ExecutionContext>() //5
    return object : KotlinIsoVisitor<ExecutionContext>() {
      override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
        val packageName = cu.packageDeclaration?.packageName ?: return cu
        val computedPackage = acc.get()
        when (computedPackage) {
          null -> acc.set(packageName)                                         //6
          "" -> {}                                                             //7
          else -> {
            val commonPrefix = packageName.commonPrefixWith(computedPackage).removeSuffix(".") //8
            acc.set(commonPrefix)
          }
        }
        return cu
      }
    }
  }

  override fun getVisitor(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
    return object : KotlinIsoVisitor<ExecutionContext>() {
      override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
        val packageName = cu.packageDeclaration?.packageName ?: return cu
        val packageToSet: String? = rootPackage ?: acc.get()                   //9
        if (packageToSet == null || packageToSet.isEmpty()) return cu
        val relativePath = packageName.removePrefix(packageToSet).removePrefix(".")
          .replace('.', '/')
        val filename = cu.sourcePath.fileName.toString()
        val newPath: Path = Paths.get("src/main/kotlin")
          .resolve(relativePath)
          .resolve(filename)
        return cu.withSourcePath(newPath)
      }
    }
  }
}

Inherit from ScanningRecipe instead of directly from Recipe
Set the accumulator type to be an AtomicReference<String?>
Make the configuration easier when you don't override the package root
The initial root is uninitialized
Skip the computation if the root package is manually set
If it's the first file visited, the accumulator holds null, and we can set the (temporary) root as the current package
One of the previous computations returned no common root–do nothing
Find the longest common prefix between the held package root and the current package
The only difference with the original code:
we check if the root package has been set manually otherwise, we use the one computed in the first pass

Optimizing the recipe

You may have noticed that when there is no common root, e.g., ch.frankel.foo and org.frankel.foo, we scan all files anyway. In a small codebase, it's not a big issue, but when scanning millions of source files, that's a huge waste of CPU cycles and time. If you run the recipe in the Cloud, it directly translates to money. We should stop scanning as soon as we detect the computed package root is an empty string to optimize the recipe.

Here's the updated code:

override fun getScanner(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
  if (rootPackage != null) return TreeVisitor.noop<Tree, ExecutionContext>()   //1
  val currentPackage = acc.get()
  if (currentPackage == "") return TreeVisitor.noop<Tree, ExecutionContext>()  //2
  return object : KotlinIsoVisitor<ExecutionContext>() {
    override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
      val packageName = cu.packageDeclaration?.packageName ?: return cu
      // Different call than the one above!
      val currentPackage = acc.get()
      // First scanned file
      if (currentPackage == null) acc.set(packageName)                         //3
      else {
        // Find the longest common prefix between the stored package and the current one
        val commonPrefix = packageName.commonPrefixWith(currentPackage).removeSuffix(".")
        acc.set(commonPrefix)
      }
      return cu
    }
  }
}

If the root package has been set, skip visiting
If one of the previous computations sets an empty string, there isn't any common root package: skip visiting
Simplify the visitor by removing the clause when the accumulator is an empty string since it can't happen anymore

Note that OpenRewrite still scans each file, but at least doesn't visit it thanks to the no-op visitor.

Counting visits

I made a couple of attempts before finding the right approach to the above. To ensure that I got it right, I wanted to display the number of visits by the scanner. We can use the accumulator to increment the visit count. Here are the changes I made:

Migrated from an AtomicReference<String?> to an AtomicReference<Pair<Int, String?>>
The getInitialValue() function returns AtomicReference<Pair<Int, String?>>(0 to null)
During each visit:
- Get the visits count from the accumulator
- Increment it
- Print it
- Store it back in the accumulator
Update the tests accordingly

With packages ch.frankel.blog.foo, org.frankel.blog.bar, and org.frankel.blog.baz, the log shows:

[INFO] [stdout] FlattenStructure: 1 file visited
[INFO] [stdout] FlattenStructure: 2 files visited

By changing ch.frankel.blog.foo to org.frankel.blog.foo, the log changes to:

[INFO] [stdout] FlattenStructure: 1 files visited
[INFO] [stdout] FlattenStructure: 2 files visited
[INFO] [stdout] FlattenStructure: 3 files visited

Because I made these changes just to validate my understanding of how OpenRewrite works, I put them in the visits_count branch on GitHub. To see the differences, execute git diff master visits_count.

Conclusion

In this post, I added the automatic computation of the root package. I had to change my design and understand how scanning recipes work. Then, I skipped further visits when there wasn't any common root package to optimize performance.

The recipe is still not serializable, though it's a recommendation. I also noticed that my tests didn't leverage OpenRewrite's testing API. There's still a lot of work to do!

The complete source code for this post can be found on GitHub.

To go further:

Originally published at A Java Geek on June 15^th, 2025

Koin on modularization: How to use it?

Sat, 15 Mar 2025 20:05:51 +0000

What is Modularization in Android?

Modularization in Android means breaking an app into smaller, independent modules instead of keeping all code in a single project. Each module has its own responsibility and can be developed, tested, and maintained separately.

Basic Prerequisites to Understand Modularization

Before learning modularization, you should be familiar with:

Android Project Structure – Understanding how an app is built using
app/src/main.
Gradle & Dependencies – Knowing how dependencies are
managed in build.gradle.kts.
Packages & Code Organization – Basics
of organizing files using packages.
Types of Android Modules – App
Module (Main application)
Library Module (Reusability across
projects)
Feature Module (For dynamic delivery in large apps)

Why Modularization?

✅ Faster Build Times – Only modified modules get compiled.
✅ Better
Code Maintainability – Easier to manage and scale.
✅ Reusability –
Common features like networking or authentication can be shared
across projects.
✅ Parallel Development – Teams can work on different
modules independently.

Today we are going to set up step by step how to use Koin in modularization with viewModel.

Before we get started. Create some new modules and structured them like this:

Step 1

You have to determine what koin gradle version you want to use. For this tutorial, I use 2.2.2 version. Define the gradle into di module

implementation "io.insert-koin:koin-android:2.2.2"
implementation "io.insert-koin:koin-androidx-viewmodel:2.2.2"
implementation "io.insert-koin:koin-androidx-scope:2.2.2"

Step 2

After you have decided koin version you'd use, add other dependency your project would need for injecting to koin in di module as well. In this tutorial I want to inject Retrofit for network, AndroidX Room for local DB, Shared Preferences, ViewModel for managing data, and Coroutine for threading

implementation "io.insert-koin:koin-android:2.2.2"
implementation "io.insert-koin:koin-androidx-viewmodel:2.2.2"
implementation "io.insert-koin:koin-androidx-scope:2.2.2"
implementation "javax.inject:javax.inject:1"

implementation "com.squareup.okhttp3:logging-interceptor:4.9.0"
implementation "com.squareup.retrofit2:retrofit:2.9.0"
implementation "com.squareup.retrofit2:converter-moshi:2.9.0"
implementation "com.squareup.retrofit2:converter-gson:2.9.0"

implementation "com.jakewharton.retrofit:retrofit2-kotlin-coroutines-adapter:0.9.2"

implementation "androidx.room:room-runtime:2.4.2"
kapt "androidx.room:room-compiler:2.4.2"
implementation "androidx.room:room-ktx:2.4.2"

Step 3

Define Network Module, Api Module, Shared Preferences Module, Room Module, and ViewModel Module (we also use UseCase and Repository module for clean architecture principle)

class ApiModule {
    companion object {
        val apiModule = module(override = true) {
            single { provideDisneyApi(get()) }
        }

        fun provideDisneyApi(retrofit: Retrofit): Api {
            return retrofit.create(Api::class.java)
        }
    }
}

class NetworkModule  {
    companion object {
        private fun httpInterceptor() = HttpLoggingInterceptor().apply {
            return HttpLoggingInterceptor { _ ->
            }.apply {
                level = HttpLoggingInterceptor.Level.BODY
            }
        }

        fun provideNetworkHandler(context: Context) = NetworkHandler(context)

        fun provideOkHttpClient() : OkHttpClient {
            return Builder.initInterceptor(httpInterceptor())
        }

        fun provideRetrofitService(okHttpClient: OkHttpClient): Retrofit {
            return Builder.initRetrofit(okHttpClient)
        }
    }
}

class SharedPrefModule {
    companion object {
        fun providePreference(context: Context) : SharedPreferences {
            return context.getSharedPreferences("SharedPreferenceName", Context.MODE_PRIVATE)
        }
    }
}

class RoomModule {
    companion object {
        fun provideRoom(context: Context) : DBConfig {
            return Room.databaseBuilder(context, DBConfig::class.java, "db_sample")
                .fallbackToDestructiveMigration()
                .build()
        }
    }
}

class RepositoryModule {
    companion object {
        val repositoryModule = module(override = true) {
            single<CharacterRepository> { return@single CharacterRepositoryImpl(get(), get()) }
        }
    }
}

class UseCaseModule {
    companion object {
        val useCaseModule = module(override = true) {
            single<CharacterUseCase> { return@single CharacterUseCaseImpl(get()) }
        }
    }
}

class ViewModelModule {
    companion object {
        val viewModelModule = module(override = true) {
            viewModel { GamesListVM(get(), get()) }
            viewModel { GamesDetailVM(get(), get()) }
            viewModel { GamesFavoriteVM(get(), get(), get()) }
        }
    }
}

After you add them all, locate and categorize module that you prioritize as a 'core' module and wrap them into AppModule class. In this tutorial I'll wrap retrofit, room, and shared preferences module like this:

val MainAppModule = module(override = true) {
    single { NetworkModule.provideOkHttpClient() }
    single { NetworkModule.provideRetrofitService(get()) }
    single { NetworkModule.provideNetworkHandler(androidContext()) }
    single { RoomModule.provideRoom(androidContext()) }
    single { SharedPrefModule.providePreference(androidContext()) }
}

Step 4

Call them with StartKoin in Application Class in App Module (default module). I will call ViewModel, Repository, Usecase, and Api module as same level with MainApp Module

class DisneyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidLogger(Level.ERROR)
            androidContext(this@DisneyApp)
            modules(MainAppModule, ApiModule.apiModule, RepositoryModule.repositoryModule,
                UseCaseModule.useCaseModule, ViewModelModule.viewModelModule
            )
        }
    }
}

And Voila! Congratulation you've built Koin in modular version. it's easy isn't it?

Happy Coding :)

Sample project: Github link

Coder Legion - Recent posts tagged kotlin

⚒️Todas as funções do aplicativo!:

Versão do app:

Botão de Pânico:

Proteção por Barulho:

Balançar o Celular para Pedir Ajuda:

Escurecimento por inclinação:

Emergência:

Compartilhamento Rápido de Localização:

Contatos de Confiança:

Compartilhamento de metadados;

🔐Área Protegida:

Calendário Menstrual:

Mapa:

Raio Seguro

Diário criptografado:

Tarefas:

Gravador de voz:

Meus arquivos:

Arquivo seguro:

Navegador:

Considerações finais:

❤️🩹Área do amparo:

Carteirinha de reivindicação dos direitos de transporte das mulheres:

Carteirinha do gesto de ajuda:

Sobre o WebView do app:

Por que, na FileActivity, o botão para trocar o tipo de armazenamento é unificado em um só?

Por que o WebView do app não trata "intent" para abrir outros aplicativos?

Sobre o tema escuro, o conforto visual e a discrição:

🔗 Deep Link do aplicativo:

Why BasicTextField Fails at Scale — And How I Build Kortex

Reaching sub-millisecond input latency on 100K-line files using Kotlin Multiplatform, Skia, and Virtualized canvas layers

1. The Core Philosophy: Zero Composable-Per-Line Overhead

The Layered Rendering Pipeline

2. Backed by Krope: Logarithmic Text Mutations

3. Killing GC Pauses with Bounded Native LRU Caches

4. Viewport Virtualization & Logarithmic Code Folding (FoldMap)

5. Pure Unidirectional MVI & Smart Undo/Redo Coalescing

6. Full IDE Tooling: Async Analysis, Squiggles & Hierarchical Themes

Debounced Coroutine Pipelines

Hierarchical Token Theming

Getting Started in 30 Seconds

Explore the Source Code

Kempo: Real-Time Audio Time-Stretching, Pitch-Shifting, and Formant Control in Pure KMP

Zero-allocation streaming, phase-locked clarity, and multichannel spatial coherence across JVM, Android, iOS, and WebAssembly.

What Kempo Brings to Your Audio Stack

How Kempo Keeps Audio Crisp (Without the Artifacts)

1. Eliminating Transient Smearing with Vertical Phase-Locking

2. Fixing the "Chipmunk" Effect with Formant Decoupling

3. Preserving Stereo Width and 5.1 Surround Imaging

Getting Started

1. The One-Liner: Offline Track Processing

2. Zero-Allocation Real-Time Streaming

3. Sample-Accurate Offline Rendering with exact()

4. Custom Frequency Mapping & Tonality Limits

Engineered for Speed in Pure Kotlin

Try It Live: The Compose Desktop Studio App

Explore the Code

Why HTTPS Won’t Save Your Checkout Flow: Building Zero-Trust State Machines in Kotlin Multiplatform

How to protect multi-step workflows, fintech funnels, and Server-Driven UI from step-skipping, state tampering, and replay attacks — with zero runtime dependencies.

The Mental Model: Think "Git Commits" for Your App State

Designing for Zero Bloat: The Core Primitives

1. VerifiableBlock

2. DeltaBlock (Signed Partial Updates)

3. Pure Functional Reduction

Real-World Walkthrough: The Unbreakable Checkout

The Legitimate User Journey

Simulating the Attack: Skipping Shipping

Built for Developer Ergonomics

Where Does TrustChain Shine?

Try It in Your Project

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Key Benefits That Stand Out for C# Developers

Key Technical References for C# Developers

The Takeaway

Building Payment Flows in Android: Lessons from Real Fintech Apps

Building Payment Flows in Android: Production Patterns from Fintech Applications

Introduction

Why Payment Flows Require Specialized Architecture

Architectural Foundation

4. Viewport Virtualization & Logarithmic Code Folding (`FoldMap`)

3. Sample-Accurate Offline Rendering with `exact()`

1. `VerifiableBlock`

2. `DeltaBlock` (Signed Partial Updates)

The problem with `sharedLogic` and `sharedUI`

FLIP: the next step after `sharedLogic`