Forem: Joseph Sanjaya

How I Fixed Sunshine Screen Sharing on macOS Tahoe (The Native Wrapper Method)

Joseph Sanjaya — Thu, 01 Jan 2026 03:38:17 +0000

I have a bit of an unconventional “Work From Cafe” (WFC) setup.

While most people carry a MacBook, I often travel with a Mac Mini and a tablet.

You might ask: Why carry a desktop to a cafe?

The answer comes down to pure economics. A Mac Mini with an M4-series chip offers the exact same raw performance as a MacBook Pro but for a fraction of the price. We are talking about a ~$600 machine versus a $2,000+ laptop.

Furthermore, I already own a tablet. Why should I pay for a MacBook screen I don’t need when I already have a gorgeous, high-resolution display in my backpack?

To bridge the two, I don’t use Sidecar or VNC. I use Sunshine.

Sunshine (the host for Moonlight clients) is designed for gaming. That means it prioritizes ultra-low latency above all else. For coding and general UI navigation, it feels almost native, whereas standard VNC or AirPlay can feel like moving your mouse through molasses.

But after the recent update to macOS Tahoe (macOS 26), my perfect, budget-friendly setup broke.

The Problem: The “Invisible” Service

Everything was perfect until the recent macOS Tahoe update.

In previous versions of macOS, if you ran Sunshine as a background service or command-line tool, it might have been flaky, but at least it was visible. You could go into System Settings, find the binary, and toggle “Screen Recording” on.

macOS Tahoe changes the rules entirely.

The new security policy doesn’t just forget permissions for command-line tools, it ignores them completely. If you run a raw binary or a background service:

No Prompt: The system will not prompt you to allow screen recording.
No UI Entry: If you manually check System Settings > Privacy & Security > Screen Recording, the service will not appear. You cannot toggle a permission that doesn't exist.
No Manual Add: You often cannot even manually drag a binary into the list.

The system now essentially demands that any process requesting screen pixels must be a proper Native App Bundle with a valid Info.plist and Bundle Identifier. Without that identity, the service is invisible to the permission system.

The Solution: Building a Native Wrapper

To fix this, I wrote a script that generates a “real” macOS application on the fly. You don’t need Xcode installed just the terminal.

This wrapper wraps the Sunshine binary inside a legitimate .app structure. This gives it a stable Bundle Identity (dev.lizardbyte.sunshine.wrapper), which forces macOS to recognize it as a valid application, triggering the permission prompt and allowing it to appear in the System Settings list.

The Generator Script

Here is the script I used to restore my WFC setup. It compiles a tiny Swift application that acts as a bridge between the OS and the Sunshine binary.

Step 1: Create the file Open your Terminal and create a file named sunshine_wrapper.sh:

touch sunshine_wrapper.sh

Step 2: Paste the Code Paste the following code.

Note: The Swift code below includes specific logic to handle the “Quit” command. This ensures that when you quit the wrapper app, it kills the background process, preventing “zombie” instances from eating up your CPU.

#!/bin/bash

# Configuration
APP_NAME="Sunshine"
APP_DIR="${APP_NAME}.app"
BUNDLE_ID="dev.lizardbyte.sunshine.wrapper"

# Attempt to find sunshine binary
SUNSHINE_BIN=$(which sunshine)
if [ -z "$SUNSHINE_BIN" ]; then
    if [ -f "/opt/homebrew/bin/sunshine" ]; then
        SUNSHINE_BIN="/opt/homebrew/bin/sunshine"
    else
        echo "❌ Error: 'sunshine' binary not found!"
        exit 1
    fi
fi

echo "✅ Targeting Sunshine binary at: $SUNSHINE_BIN"

# 1. Clean & Create Structure
echo "📂 Creating App Structure..."
rm -rf "$APP_DIR"
mkdir -p "${APP_DIR}/Contents/MacOS"
mkdir -p "${APP_DIR}/Contents/Resources"

# 2. Create the Robust Swift Launcher
# This version imports Cocoa to handle the Quit command properly.
SWIFT_SOURCE="Launcher.swift"
cat <<EOF > "$SWIFT_SOURCE"
import Cocoa
import Foundation

class AppDelegate: NSObject, NSApplicationDelegate {
    var process: Process!

    func applicationDidFinishLaunching(_ notification: Notification) {
        let sunshinePath = "$SUNSHINE_BIN"

        process = Process()
        process.executableURL = URL(fileURLWithPath: sunshinePath)
        process.arguments = CommandLine.arguments.dropFirst().map { String(\$0) }

        // Pipe output so you can debug via Console.app if needed
        process.standardOutput = FileHandle.standardOutput
        process.standardError = FileHandle.standardError

        // If Sunshine crashes/quits on its own, close the wrapper app too
        process.terminationHandler = { _ in
            NSApp.terminate(nil)
        }

        do {
            try process.run()
        } catch {
            print("Failed to launch sunshine: \(error)")
            NSApp.terminate(nil)
        }
    }

    // This is called when you Right Click -> Quit in the Dock
    func applicationWillTerminate(_ notification: Notification) {
        if let proc = process, proc.isRunning {
            // Send SIGTERM to Sunshine to shut it down gracefully
            proc.terminate()
            // Wait a moment for it to cleanup, or it becomes a zombie
            proc.waitUntilExit()
        }
    }
}

// Main entry point
let app = NSApplication.shared
let delegate = AppDelegate()
app.delegate = delegate
app.setActivationPolicy(.regular) // Shows in Dock, has UI (menu bar)
app.run()
EOF

# 3. Compile
echo "🔨 Compiling Native Wrapper (with AppKit)..."
swiftc "$SWIFT_SOURCE" -o "${APP_DIR}/Contents/MacOS/${APP_NAME}"
rm "$SWIFT_SOURCE"

# 4. Create Info.plist (Updated for Icon)
cat <<EOF > "${APP_DIR}/Contents/Info.plist"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleExecutable</key>
    <string>${APP_NAME}</string>
    <key>CFBundleIdentifier</key>
    <string>${BUNDLE_ID}</string>
    <key>CFBundleName</key>
    <string>${APP_NAME}</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleShortVersionString</key>
    <string>2.0</string>
    <key>LSMinimumSystemVersion</key>
    <string>12.0</string>
    <key>NSHighResolutionCapable</key>
    <true/>
    <key>CFBundleIconFile</key>
    <string>AppIcon</string>
</dict>
</plist>
EOF

# 5. Sign
echo "🔐 Signing the application..."
codesign --force --deep --sign - "${APP_DIR}"

echo "------------------------------------------------"
echo "✅ Success! '${APP_DIR}' created."
echo "------------------------------------------------"

Step 3: Run and Install

Run the script:

chmod +x sunshine_wrapper.sh
./sunshine_wrapper.sh

Then, move the resulting Sunshine.app to your /Applications folder.

The Result

After running this script, you may need to reset your permissions one last time to clear out any old conflicts:

tccutil reset ScreenCapture dev.lizardbyte.sunshine.wrapper

When you launch the new app, macOS Tahoe will see a signed, native application requesting access. Click Allow, and the permission will finally stick.

My portable Mac Mini setup is back in business. Just like that, you can stream your Mac Mini to Moonlight or Artemis on your tablet with zero fuss and low latency. If you are struggling with screen sharing tools on the new macOS, try wrapping them in a native .appit makes all the difference.

Stop Waiting for Gradle: Turn Your Old Laptop into an Android/Kotlin Build Sanctuary

Joseph Sanjaya — Mon, 15 Dec 2025 16:13:58 +0000

If you are a geek like me, you live in a multi-device environment. I have my Gaming PC for freelancing and late-night sessions. I have my Mac for professional work and those heavy iOS/CMP compilations. And I have my Corporate Laptop for the 9-to-5 grind.

Switching between them used to be a nightmare.

I would push code from the Mac, walk over to the PC, pull the changes, and then… wait. I’d wait for Maven Central to redownload libraries I already had on the other machine. I’d wait for Gradle to rebuild tasks that hadn’t changed.

I was paying a “Context Switch Tax” of 15 to 20 minutes every single time I changed desks.

But I also had a secret weapon: an old, dusty laptop sitting in a drawer. Instead of letting it rot, I turned it into a Build Sanctuary.

Using CasaOS, I transformed that junk hardware into a local powerhouse.

The best part? It didn’t just solve my build times. Because it’s running CasaOS, this old laptop is now my Private Cloud. It handles my local file storage (bye-bye, cloud storage fees), hosts my backend services for testing, and acts as a central environment for everything I develop.

Here is how you can do it and why you should stop ignoring your old hardware.

The “Sanctuary” Concept

Your bandwidth is finite, and your time is expensive. Downloading the same 500MB of libraries three times a day isn’t just inefficient; it’s a distraction.

Imagine a world where you update a library on your Mac, and when you open your PC, it’s already “there.”

No downloading.
No waiting.
Instant sync.

You create a Single Source of Truth for your entire home network.

The Foundation (CasaOS): We are going to use CasaOS. It’s a clean, visual interface for Linux. It turns a scary terminal into a friendly dashboard that looks like a smartphone screen.

Take your old laptop.
Install a lightweight Linux distro (like Ubuntu Server).
Run the CasaOS installer.

Now, let’s make it useful for Android.

Step 1: The Gradle Build Cache Node

Gradle is paranoid. It likes to rebuild things just to be safe. If you switch computers, Gradle assumes it’s a fresh start and recompiles code that you haven’t touched.

A Remote Build Cache Node acts as the brain of your operation. It remembers what you built on your Mac.

When you switch to your PC, Gradle asks the Node, “Do you have the output for this task?” The Node says “Yes,” and hands it over instantly via your local network. You skip the compilation step entirely.

The Setup: In your CasaOS dashboard, we are going to add a custom Docker app.

Create the Custom App *You don’t need to touch a single line of code or write a YAML file. In the CasaOS dashboard, just click the *+ button and select “Install a Custom App”.

Here is the Cheat Sheet:

Docker Image: gradle/build-cache-node
Tag: latest
Port (Host): 5071
Volumes (Host): /DATA/AppData/gradle-cache (This connects actual storage to store the Gradle cache files.)
Container Command: start

Hit Install. Wait a few seconds until the icon turns green. You are now live.

2. Connect Your Project
Open your Android project’s settings.gradle.kts file. We need to tell the project to talk to your old laptop.

Now, your Mac compiles the code, uploads the result to the laptop, and your PC downloads the result. It feels like magic. You can check if the project already using the remote cache by using --scan . On the report it will shown:

Step 2: Sonatype Nexus

I live in Indonesia. We are famous for our delicious food, beautiful islands, and unfortunately our terrible internet speeds.

Yesterday, the worst happened. My ISP went dark. I had a hard deadline for a freelance client in three hours. Usually, this is the part where I panic, tether my phone, and watch a 10MB download take twenty minutes while sweating bullets.

Because I had Nexus running, I kept working. My Android Studio didn’t even notice the internet was gone. It reached out to my local server, grabbed the dependencies it needed instantly, and the build finished successfully. I met the deadline without a single blocker.

Nexus acts as a Proxy.

You ask for a library (e.g., Retrofit).
Nexus checks if it has it locally.
If not, it downloads it once from the internet and stores it.
The next time any device asks for Retrofit or if your internet dies Nexus delivers it at LAN speeds.

The Setup: Click + and “Install a Custom App” again. Use these settings:

The Cheat Sheet:

Docker Image: sonatype/nexus3
Tag: latest
Port: Host 8081 ↔ Container 8081
Volume: Host /DATA/AppData/nexus-data ↔ Container /nexus-data (Tip: You can point the Host path to an external hard drive if you have a massive library collection)

2. Configure the Proxy

Log in to the Nexus dashboard (default is usually port 8081). The default username is admin. The first-time password is stored in a file inside the container’s host path open it to get the initial password.
Create a “Proxy Repository” for maven-central and google-maven.

Group them into a single repository called maven-public.

3. Connect Your Project: Now, tell your Android project to look at your sanctuary first. Open your root build.gradle.kts (or settings.gradle.kts in newer projects) and update the repositories block:

Now, your builds fly because they are pulling data via Ethernet, not waiting on a server across the ocean. You can check on the Download Info :

Step 3: The “One-Shot” Hack

You probably have dozens of projects. Opening every single build.gradle.kts file to add your new server IP is tedious. It's boring work, and you will forget to do it for new projects.

We can use a Global Initialization Script. You write this configuration once on your machine. Every single project you open or create on that computer will automatically use your local Build Sanctuary. No manual editing required.

On your Mac or PC, navigate to the .gradle folder (usually ~/.gradle/) and create a folder named init.d.

nexus.gradle,this script forces Gradle to look at your local server before it looks at the internet.

The “Line Cutter” Logic (**repos.add(0, nexus)**): Gradle is polite; it usually checks repositories in the order they are listed. If your project lists google() first, Gradle will hit the internet first, defeating the purpose. This script aggressively removes your local repo and re-inserts it at index 0 (the top). It guarantees your local server is always the first stop.

casa-cache.gradle, this script connects the build cache, but safely.

How to activate it: Now, just add this one line to your ~/.gradle/gradle.properties file:

casa.cache.url=http://192.168.1.XXX:5071/cache/
casa.cache.push=true

Restart Android Studio. That’s it. Every project you touch is now supercharged.

For the Terminal Purists

Maybe you are reading this and thinking, “I don’t want a fancy UI. I don’t want the overhead of CasaOS. I just want raw performance.”

You don’t need CasaOS. It’s just a nice wrapper. Under the hood, this is all just Docker.

The Setup: If you prefer the command line, just install Docker and Docker Compose on your server. Create a single docker-compose.yml file that defines both the Nexus service and the Build Cache service.

Run docker-compose up -d.

You get the exact same benefits the speed, the sync, the sanctuary without the graphical interface. It’s your sanctuary; build it how you like it.

Scaling to the Enterprise

You might be thinking, “This is cool for my home lab, but does it work at work?”

This exact architecture is how top-tier tech companies speed up development.

If this setup saves you 15 minutes a day, imagine what it does for a team of 50 developers. By setting up a central Gradle Enterprise server or a shared Nexus instance in the office:

Onboarding is instant. New employees don’t spend Day 1 downloading the internet. They sync from the local server.
Consistency is enforced. Everyone uses the exact same artifacts.
Bandwidth is saved. You stop 50 people from downloading the same 1GB files simultaneously.

It creates a Single Source of Truth for the entire engineering department.

Monday Morning Action Step

Don’t let this be just another article you bookmark and forget.

Find the hardware. Go dig out that old ThinkPad, the unused Dell, or even a Raspberry Pi 4.
Wipe it. Install a fresh Linux OS.
Deploy. Whether you use the friendly CasaOS interface or stick to pure Docker, just get it running.

Give your old tech a new job, and give yourself the gift of faster builds. Your sanity (and your internet bill) will thank you.

KToon: Tiny Tables, Big Savings Plug TOON into Your @Serializable Kotlin Classes

Joseph Sanjaya — Thu, 04 Dec 2025 16:22:49 +0000

JSON is comfortable. Familiar. Everywhere.
But it’s also wasteful. Every time we send a list of objects, we pay the cost of repeating the same field names again and again "id" a hundred times, "name" a hundred times silently taxing bandwidth and slowing real-world performance.

Meanwhile, the LLM world quietly optimized around this problem.
Token-oriented formats like TOON, which treat data like a spreadsheet (headers once, values below), already power faster inference and cheaper processing at massive scale. They get real efficiency gains simply by avoiding redundancy.

That raised the obvious question:
If AI companies already benefit from TOON, why aren’t our apps?

So for the Kiroween Hackathon’s Skeleton Crew challenge, I set out to build a compact, flexible serialization format that brings those same advantages to everyday Kotlin developers without forcing anyone to rewrite their models or architecture. Using Kiro’s spec-driven workflow to design before coding, I built the foundation for KToon, a TOON-style format that plugs directly into kotlinx.serialization and works with your existing @Serializable classes.

One clean skeleton. Many possible applications.

Next, I’ll walk through what makes TOON useful in practice and how KToon turns a normal data class into a dramatically smaller payload without changing a single line inside it.

What TOON Really Is (and Why It Works)

Think about a spreadsheet.

You define your columns once id, name, age and then you just fill in the rows. No one would ever rewrite the column names on every line; that would be absurd. Yet that’s exactly what JSON does every time we serialize a list of structured objects.

TOON flips that model on its head. It treats structured data collections as tables instead of repeated key-value objects. The structure lives once at the top. Everything below is just values.

A simple example speaks louder than theory:

JSON

[
  {"id": 1, "name": "Alice", "age": 30},
  {"id": 2, "name": "Bob", "age": 25}
]

TOON

users[2]{id,name,age}:
  1,Alice,30
  2,Bob,25

Same meaning. Same structure.
But dramatically fewer characters especially as datasets grow.

The results scale fast: when you have thousands of rows, the headers stay exactly the same size, while JSON grows linearly with duplicated keys. TOON cuts the redundancy out of the serialisation pipeline entirely.

And when data is hierarchical, not tabular, TOON switches into a clear, indentation-based representation instead of forcing everything into a grid. It’s human-readable without being verbose, and structured without being rigid.

Why this matters

Faster network responses (less data, fewer tokens)
Lower costs in bandwidth-sensitive environments
Smaller offline storage footprints
Faster parsing, especially on constrained devices A structure that aligns with how humans already think about lists This idea isn’t abstract the LLM ecosystem already runs on token-efficient formats like this because it saves real money at scale. We’re simply borrowing a proven trick and applying it where mobile and multiplatform apps need it just as much.

How KToon Fits into kotlinx.serialization

The best part about building KToon wasn’t inventing a new format.
It was realizing we didn’t need to reinvent the entire serialization ecosystem to support it.

Kotlin already gives us a powerful abstraction layer with kotlinx.serialization.
At the core of that system are two extensibility points:

an Encoder that defines how values are written, and
a Decoder that defines how values are read back
Everything else reflection, annotations, polymorphism, nested objects, nullability is handled by the framework. The serialization engine walks through your object graph and calls into whatever format implementation you provide.

Meaning:
If you implement your own encoder/decoder, you automatically get compatibility with every @Serializable data class without modifying any of them.

That’s the breakthrough that made KToon possible.

Rather than invent custom DSLs, code generators, or special DTO structures, KToon simply acts as a StringFormat implementation. The serialization machinery already knows how to traverse a list of User, or a ProductCatalog, or a tree of nested objects. KToon just decides how to write them.

It’s the software equivalent of replacing the wheels without redesigning the car.

You don’t rewrite @Serializable data class User(...) you tell serialization to express it differently.

That’s what makes KToon a skeleton worth building on:
thin, intentional, and flexible enough to power completely different applications without accumulating framework weight.

Building the Engine, Encoder, Decoder, and Lexer

The heart of KToon lives in three small but tightly synchronized components. Each exists for one purpose, nothing more. No grand abstractions, no “just in case” layers. Like bones in a good skeleton, they do less so the whole system can do more.

The Encoder, Structure Without Buffering

ToonEncoder extends Kotlin’s AbstractEncoder, and that’s where the magic really begins. As the serialization framework walks through the object graph, calling methods like encodeString(), encodeInt(), or beginStructure(), we decide what to write and when. The encoder runs a small state machine with four modes:

IDLE — waiting for the next field
ENCODING_STRUCTURE — writing nested objects using indentation
ENCODING_COLLECTION — preparing to output a table
ENCODING_VALUE — writing primitive values
Encounter a list? Instead of holding the entire collection in memory, the encoder immediately delegates to ToonCollectionEncoder, which writes a header like:

users[5]{id,name,email,age}:

Then each element hands control to ToonRowEncoder, which writes CSV values line by line:

1,Alice,alice@example.com,28

The delegations are deliberate:
the main encoder handles structure,
the collection encoder handles headers,
the row encoder handles values.

No one knows more than it needs to. No buffering. No temporary model. Everything streams straight into a StringBuilder in one pass O(N) time and minimal memory footprint.

The Decoder, Context-Aware Parsing and Real Error Messages

Decoding is harder than encoding; anyone who has built a parser knows the pain. You’re not just reading you’re validating structure, honoring indentation, counting rows, matching types, and explaining mistakes gracefully.

ToonDecoder uses a ToonLexer to tokenize input line by line, tracking indentation level and mapping fields back to properties. When it hits table mode, it verifies the declared size matches reality and parses each row with ToonRowDecoder.

Its real superpower: human-readable error messages.

Example:

Type mismatch at line 4, field 'age': cannot decode 'invalid' as Int
Context:

    2: users[5]{id,name,email,age}:
    3:   1,Alice,alice@example.com,28
>>>  4:   2,Bob,bob@example.com,invalid
    5:   3,Charlie,charlie@example.com,42

Instead of stack traces, you get answers.

The Lexer Tokenizing With Indentation Awareness

ToonLexer sits between raw text and structured understanding it splits lines, tracks indentation, and identifies patterns like headers, CSV values, and delimiters. Because TOON is line-oriented, indentation gives structure and table headers give shape.

Separating lexing from decoding keeps both components clean, testable, and predictable.

Plugging Into Ktor One Line to Swap Formats
Once the engine existed, Ktor integration felt almost embarrassingly simple. Ktor already exposes an extension point for serialization formats via ContentConverter. We wrap the TOON engine and expose one toon() extension:

install(ContentNegotiation) {
    json() // Keep JSON
    toon() // Add TOON
}

Request Content-Type: application/toonget TOON.
Request JSON get JSON.
Same route code. Zero switching cost (on client side).

Real-World Impact, 67.4% Fewer Tokens
In our sample endpoint, JSON produced 553 bytes (~138 tokens).
TOON produced 179 bytes (~45 tokens).
A 67.4% reduction.

And the bigger the dataset, the bigger the gap.

This isn’t theoretical efficiency:
for inference pipelines sending product catalogs, search results, or event logs to LLMs, this means faster context windows and lower token bills.
For mobile apps, it means snappier UX and lighter data usage.

How Kiro Shaped the Development Process

This skeleton didn’t emerge from hacking in the dark. It was shaped intentionally using Kiro’s spec-driven workflow.

Before writing code, every major component encoder, decoder, lexer, Ktor integration lived first as words:
requirements, architecture sketches, constraints, trade-offs.

When decisions got messy, like how to handle nulls in tables or whether indentation levels should equal structure depth, MCP agents acted like design partners challenging assumptions, connecting dots, forcing clarity. They didn’t generate code. They generated understanding.

That discipline is what kept KToon around 1000 lines of pure Kotlin instead of spiraling into a maze of abstractions.

If KToon had been built “vibe-first”, it would have collapsed under its own cleverness.
Built spec-first, it became a skeleton instead of spaghetti.

Why This Skeleton Matters

KToon doesn’t try to replace JSON everywhere.
It exists to solve a very real problem: redundant field names in structured collections.

The foundation is intentionally small:

pure Kotlin, no platform code,
single-pass O(N) performance,
works with any existing @Serializable classes,
one-line integration with Ktor,
and a clean surface for future extensions (streaming, binary mode, Retrofit, etc.).
Most importantly, it proves something worth remembering:

See Project here: JosephSanjaya/ktoon

The techniques that make AI faster and cheaper don’t need to stay inside LLM labs.
They can make our everyday apps better too.

The Day Mentoring Felt Like Parenting: Lessons from The Explosive Child

Joseph Sanjaya — Sun, 09 Nov 2025 17:41:27 +0000

I didn’t plan to spend my weekend herding two middle schoolers through a game jam, but fate had other ideas.

“Just mentor them a bit,” they said. “It’ll be fun!” they said.

I’d been asked, last-minute, to mentor two middle schoolers eighth and ninth graders during a weekend “Build-a-thon.”

I’m a senior Android engineer and occasional game development mentor, so I expected to spend 48 caffeine-fueled hours teaching arrays, tilesets, and maybe some basic game logic. Instead, I found myself mediating creative explosions, emotional whiplash, and a tug-of-war between two brilliant but combustible imaginations.

Their project, which they proudly titled Eco-nomy, was a digital board game about saving or exploiting the planet. One team played as Forest, planting trees and cleaning pollution. The other, Industry, mined resources and built factories. It was conceptually sharp an eco-capitalism duel. But the execution? Chaotic.

The Hackathon Meltdown

It started with pure energy whiteboard sketches, quick Godot prototypes, laughter, and instant noodle wrappers multiplying like power-ups. Then, as the caffeine wore off and the logic grew tangled, the temperature in the room rose.

They fought about everything. One wanted to build a full-blown card system, complete with randomized draws, resource costs, and special abilities. The other just wanted a simple drag-and-drop mechanic place tiles, take turns, keep it fast and visual.

I tried to intervene like an engineer. I pointed at the backlog we’d written in Notion and said, “Let’s stick to the MVP.” That only made it worse. They accused each other of “ruining the vision.”

By the second meltdown, I was googling phrases like how to mentor teenagers without losing your sanity. That’s when I stumbled back on a book I’d read years ago but never really applied outside of family life: Ross W. Greene’s The Explosive Child.

It’s a parenting book. But in that chaotic moment, it felt like a software manual for emotional systems under load.

“Kids Do Well If They Can”

Greene’s first and most famous principle is deceptively simple: Kids do well if they can.

He argues that kids aren’t difficult because they want to be they’re difficult because they’re missing the skills to handle frustration, flexibility, or problem-solving in that moment.

That line reframed everything. My mentees weren’t being defiant they were overwhelmed. The scope was huge, the time was short, and their emotional bandwidth was thinner than their FPS counter.

Once I looked through that lens, their arguments stopped feeling like personal resistance and started looking like lagging skills. They weren’t refusing to collaborate they just hadn’t learned how to regulate disagreement yet.

So instead of enforcing rules (“We’re sticking to this plan!”), I took a breath and tried empathy first. “Looks like both of you have strong ideas for the economy system,” I said. “What’s making it tricky to agree right now?”

That single question changed the tone. They went from attacking each other to explaining themselves to me. One admitted, “I just don’t want my team to be boring.” The other confessed, “I’m scared we won’t finish if we keep adding stuff.”

Beneath the shouting, there were valid emotions creativity and fear wrestling for control.

Regulate Before Reasoning

Greene emphasizes that logic is useless when someone’s brain is in fight-or-flight mode. You can’t reason with a mind on fire.

I learned this the hard way.

At one point, one student was supposed to design the board tiles forests, factories, rivers while his teammate handled the game logic. But after nearly an hour, his screen was still blank except for a single half-drawn tree. His partner exploded: “We’re never going to finish at this pace!”

The air thickened. The designer froze, eyes fixed on his tablet, shoulders tight. My instinct was to jump straight into “fix mode”: Let’s review your workflow, optimize your sprite pipeline, speed this up. But the tension in the room told me logic would bounce off a wall of stress.

So I changed tactics. “Let’s take a break,” I said. “Grab water. Stretch.” I turned the conversation away from the task asked about their favorite games instead. Ten minutes later, laughter returned. When we sat back down, the artist quietly opened his canvas and started sketching again. By the next hour, the board had color and personality.

That was regulate before reasoning in action. I learned that when creativity jams, pressure only tightens the knot. Sometimes the fastest way forward is stepping away not to escape the work, but to reset the brain behind it.

Lagging Skills, Not Bad Behavior

Greene’s framework treats challenging moments as unsolved problems, not acts of rebellion.

Midway through the hackathon, I noticed a pattern. Whenever we hit a design disagreement, one student would quietly drift away from the project watching YouTube or sneaking in a few minutes of Minecraft. Meanwhile, his teammate would start panicking about the deadline, muttering, “He’s not even working anymore!”

Initially, I saw it as procrastination. But when I thought in terms of lagging skills, I recognized something else: they didn’t know how to handle scope stress. They weren’t lazy they lacked the executive function to break big problems into smaller ones.

So I shifted my mentorship from “enforcer” to “coach.” I sat down and said, “Let’s split this into milestones. You finish the resource system while your teammate designs the board grid. Once both work, we merge.”

Suddenly, momentum returned. They felt capable again because the task had been right-sized to their skill level.

It reminded me of something Greene wrote: “Challenging behavior occurs when the demands being placed on a child exceed the child’s capacity to respond adaptively.” Substitute developer for child, and you’ve got a perfect postmortem for half of all failed sprints.

Collaborative Problem Solving (Plan B)

Greene describes three “plans” adults can use when conflict arises:

Plan A: Impose your will.
Plan B: Solve collaboratively.
Plan C: Drop the issue temporarily.

As a senior engineer, I realized I defaulted to Plan A far too often “We’ll do it this way because it’s the most efficient.” But hackathons (and children) don’t thrive on efficiency; they thrive on ownership.

So I tried Plan B.

During a heated debate over whether trees should generate gold or points, I resisted the urge to “decide as the adult.” Instead, I asked, “What would make it fair for both?”

They thought. One suggested that trees generate gold, but only if forests stay healthy. The other proposed that pollution lowers the forest’s gold yield. Within minutes, they had invented an elegant feedback loop a mechanic I would have over-engineered into oblivion.

Collaborative problem solving didn’t just fix the argument; it unlocked innovation.

The Turnaround

By the final day, the chaos had finally found a shape. The game didn’t look great the art was clunky, the colors uneven, and the tiles didn’t quite align but it worked. Players could drag and drop tiles across the board, trying to form patterns that, when connected, triggered special abilities: a forest alignment would sap production points from Team Industry, while a chain of factories could choke the planet faster.

It wasn’t elegant, but it was alive. The students, once at odds, were now playtesting side by side, laughing as they discovered unintended combos and quick-fixing bugs together.

They even began resolving disagreements without me. “Let’s just test both versions,” one said. “We’ll keep whichever feels fairer.”

They submitted Eco-nomy minutes before the deadline. The judges smiled politely at the art but loved the idea a tiny eco-strategy born from two competing visions that somehow fused into one. It’s here if you want to see it:
👉https://devpost.com/software/eco-nomy-xz09w8

For me, the real victory wasn’t on the screen. It was in seeing those two explosive minds finally synchronize not because I took control, but because I learned to let go just enough for collaboration to happen.

The Reflection

In software teams, we often focus on technical mentorship: code reviews, architecture decisions, performance tuning. But mentoring those two kids reminded me that leadership whether with junior developers or middle schoolers is fundamentally about emotional scaffolding.

Greene’s principles translate almost perfectly into the engineering world:

“Kids do well if they can” becomes “Developers do well if the system allows.” Struggles aren’t signs of incompetence; they’re signs of unmet skill development or unclear expectations.
“Regulate before reasoning” becomes “Don’t debug while you’re burning out.” Step away before you escalate.
“Collaborative problem solving” becomes “Pair-program your way out of conflict.” Shared ownership outperforms imposed hierarchy.

Mentorship, like parenting, isn’t about control it’s about creating the conditions for competence.

When I think back to those two students their laughter, their messiness, their boundless conviction I realize The Explosive Child isn’t just a parenting guide. It’s a philosophy of human development: that people grow best when they feel understood first, instructed second.

And maybe that’s the secret to mentoring, managing, or even living well with others in high-pressure, creative work:

People do well if they can. And if they can’t yet, our job isn’t to punish it’s to teach.

References

The Explosive Child by Dr. Ross Greene

The Subtle Art of Making Android Animations Feel Expensive

Joseph Sanjaya — Thu, 30 Oct 2025 02:15:36 +0000

Designing Animations That Feel Expensive

Most apps move. Only a few flow.
You can feel it instantly, one looks like a slideshow, the other like choreography. The difference isn’t in how many lines of animation code it has, but in how intentionally time and motion are used.

That sense of flow is what separates hobby projects from products that feel “high-end.” When an animation lands just right, easing in, pausing at the right frame, fading naturally, it gives the user subconscious trust. It tells them: this interface was crafted, not assembled.

“Animation isn’t flair, it’s feedback.”

Recently, I’ve been mentoring a young briliant developer still in Middle school at 10th grade, already building solid Android apps. I’ve been teaching her how motion design, when guided by research and design principles, can elevate an interface from functional to elegant.

Once she began applying those principles, her apps stopped looking like prototypes and started feeling like products. That’s the real power of thoughtful animation: it quietly teaches the user that the experience was made by someone who understands design at a human level.

Why Animation Quality Matters

Animation isn’t about making things move it’s about making things make sense.
When transitions are timed well, users don’t just see movement; they understand continuity. The screen doesn’t “change,” it flows into the next state. That’s why good motion design is often invisible your brain just accepts it as natural.

“Good animation disappears. Bad animation demands attention.”

Every major design system from Material You to Apple’s Human Interface Guidelines treats animation as part of interaction design, not decoration. They talk about things like spatial continuity, momentum, and temporal hierarchy.
Translated to code, that means your easing curves, durations, and offsets are more than aesthetic choices they’re cognitive tools. They help the user’s eyes and brain track where elements go and what matters most in each moment.

From a developer’s perspective, we’re effectively managing perceived latency. A well-timed 400ms transition can feel faster than a 200ms one because it signals continuity instead of abrupt replacement.

That’s why, when teaching animation design, I start with the fundamentals: rhythm, easing, and depth. Get those three right, and even a simple fade can feel like craftsmanship. Get them wrong, and no amount of particle effects will save it.

From Static Screens to Living Navigation

During a mentoring session for my mentee’s Android project a beautifully structured app that just lacked motion personality I introduced her to Ramcosta Destinations.
Not because the library itself is magical, but because it provides a clear structure to experiment with transitions without boilerplate. Once navigation felt manageable, I asked her to focus on how the screen should move, not just what it should show.

That’s when we implemented this custom animation setup. It transformed plain navigation into something that felt crafted each transition now carries a sense of direction and emotion.

The Motion Core

We began by defining three duration constants the backbone of rhythm for every animation in the app.

private const val DURATION_LONG = 500
private const val DURATION_MEDIUM = 400
private const val DURATION_SHORT = 250

Think of these as musical beats.

Long (500ms) is the cinematic motion full attention, used for major transitions.
Medium (400ms) keeps companion animations (fade, scale) in harmony.
Short (250ms) makes the exit feel snappy; users notice arrivals more than departures.

Keeping them centralized makes later tuning simple if the whole app feels too “heavy,” you tweak these three values instead of 20 scattered numbers.

1. Enter Transition “Make it Arrive with Grace”

override val enterTransition = {
    slideInHorizontally(
        initialOffsetX = { fullWidth -> fullWidth / 2 },
        animationSpec = tween(DURATION_LONG, easing = EaseOutQuart)
    ) + fadeIn(
        animationSpec = tween(DURATION_MEDIUM, easing = LinearOutSlowInEasing),
        initialAlpha = 0.05f
    ) + scaleIn(
        animationSpec = tween(DURATION_LONG, easing = EaseOutBack),
        initialScale = 0.90f
    )
}

The goal is to guide the eye gently into the new screen.

Slide: Using fullWidth / 2 makes the entry travel half the screen width enough to show motion, not overwhelm.
EaseOutQuart: Slows down sharply near the end that elegant “coast to stop” found in Apple and high-end app transitions.
Fade: Starts almost invisible (0.05f), creating a smooth “emerge from depth” effect.
Scale: Begins at 0.9 and slightly overshoots with EaseOutBack, which mimics real-world elasticity a polished bounce that feels natural, not cartoonish.

💡 Tips!_
Try testing with fullWidth / 1 instead of /2. You’ll see instantly how shorter distance makes transitions feel tighter and more luxurious._

2. Exit Transition “Drift Away, Don’t Disappear”

override val exitTransition = {
    slideOutHorizontally(
        targetOffsetX = { fullWidth -> -(fullWidth / 4) },
        animationSpec = tween(DURATION_MEDIUM, easing = EaseInOutCubic)
    ) + fadeOut(
        animationSpec = tween(DURATION_SHORT, easing = FastOutLinearInEasing)
    ) + scaleOut(
        animationSpec = tween(DURATION_MEDIUM, easing = EaseInOutCubic),
        targetScale = 0.96f
    )
}

Leaving should feel light and dismissive not dramatic.

Slide out only a quarter: this asymmetry (half in, quarter out) keeps motion fast without visual fatigue.
EaseInOutCubic: smooth acceleration and deceleration, like a steady drift.
FadeOut: quick 250ms fade because once the new screen enters, the old one should vanish decisively.
ScaleOut: Shrinking to 0.96 subtly hints at distance, reinforcing the illusion of depth.

3. Pop Enter Transition “The Return”

override val popEnterTransition = {
    slideInHorizontally(
        initialOffsetX = { fullWidth -> -fullWidth / 3 },
        animationSpec = tween(DURATION_LONG, easing = EaseOutQuart)
    ) + fadeIn(
        animationSpec = tween(DURATION_MEDIUM, easing = LinearOutSlowInEasing),
        initialAlpha = 0.1f
    ) + scaleIn(
        animationSpec = tween(DURATION_MEDIUM, easing = EaseOutBack),
        initialScale = 0.93f
    )
}

When navigating back, the motion should communicate “returning to where you came from.”

Negative offset: slides from the left to visually match back navigation.
EaseOutQuart + Back combo: makes the returning screen feel like it “snaps back into place.”
Slightly smaller scale (0.93f): avoids the feeling that content is jumping too fast from offscreen.

4. Pop Exit Transition “Leaving the Spotlight”

override val popExitTransition = {
    slideOutHorizontally(
        targetOffsetX = { fullWidth -> fullWidth / 2 },
        animationSpec = tween(DURATION_LONG, easing = EaseInCubic)
    ) + fadeOut(
        animationSpec = tween(DURATION_SHORT, easing = FastOutLinearInEasing)
    ) + scaleOut(
        animationSpec = tween(DURATION_MEDIUM, easing = EaseInOutCubic),
        targetScale = 1.05f
    )
}

The screen leaving backward should feel like it’s gently pushed away not abruptly removed.

EaseInCubic: accelerates quickly, giving a sense of “slide offstage.”
ScaleUp (1.05f): that tiny zoom outward makes the departing screen feel like it’s stepping away into depth.

🧠 Note:_1.05f_ is the visual sweet spot larger values start to feel cartoonish; smaller ones become imperceptible.

Smooth State Transitions, Teaching Motion That Feels “Alive”

In the same project where my mentee implemented those navigation transitions, I introduced her to the next level:
making composable state transitions that feel like the UI understands what just happened.

This is where we used a custom setup built around AnimatedContent.
It handles the classic tri-state scenario — Loading → Content → Error — but with movement that feels organic and consistent with the app’s overall animation language.

Code Setup: StateSwitcherAnimator

@Composable
fun <T> StateSwitcherAnimator(
    targetState: T,
    modifier: Modifier = Modifier,
    transitionType: AnimationTransitionType = AnimationTransitionType.Default,
    content: @Composable (T) -> Unit
) {
    AnimatedContent(
        targetState = targetState,
        modifier = modifier,
        transitionSpec = {
            when (transitionType.resolve(targetState)) {
                AnimationTransitionType.Error -> {
                    slideInVertically(
                        initialOffsetY = { -it },
                        animationSpec = tween(500, easing = FastOutSlowInEasing)
                    ) + fadeIn() togetherWith
                        slideOutVertically(
                            targetOffsetY = { -it },
                            animationSpec = tween(400, easing = FastOutSlowInEasing)
                        ) + fadeOut()
                }
                AnimationTransitionType.Loading -> {
                    scaleIn(
                        initialScale = 0.8f,
                        animationSpec = tween(400, easing = FastOutSlowInEasing)
                    ) + fadeIn(animationSpec = tween(400)) togetherWith
                        scaleOut(
                            targetScale = 0.8f,
                            animationSpec = tween(300, easing = FastOutSlowInEasing)
                        ) + fadeOut()
                }
                else -> {
                    slideInVertically(
                        initialOffsetY = { it / 2 },
                        animationSpec = tween(500, easing = FastOutSlowInEasing)
                    ) + fadeIn() togetherWith
                        slideOutVertically(
                            targetOffsetY = { it / 2 },
                            animationSpec = tween(400, easing = FastOutSlowInEasing)
                        ) + fadeOut()
                }
            }
        },
        label = "PremiumAnimatedContent"
    ) { state ->
        content(state)
    }
}

🧩 How It Works

This function is basically a state-aware animation wrapper it listens to changes in a “state machine” and animates between them in a way that visually communicates what’s happening.

Each state transition type (Error, Loading, Default) is tuned with a specific motion profile:

1. Error State Vertical Slide from Top

slideInVertically(initialOffsetY = { -it }) + fadeIn()
slideOutVertically(targetOffsetY = { -it }) + fadeOut()

Errors drop in from above like a toast or alert entering the viewport.
The -it offset signals urgency, paired with a 500ms easing (FastOutSlowInEasing) for smooth entry that still feels assertive.

🎛️ Why these values?The 500 → 400 ms duration split ensures the entry feels slightly longer than the exit — attention-grabbing without overstaying.
Using _FastOutSlowInEasing_ softens the landing critical for keeping even an “error” message from feeling harsh.

2. Loading State Scale In-Out

scaleIn(initialScale = 0.8f) + fadeIn()
scaleOut(targetScale = 0.8f) + fadeOut()

Loading feels “breathing.”
It scales up from 0.8x to full, suggesting preparation like data being assembled.
The scale symmetry (in and out both to 0.8f) gives a rhythmic pulse.

🧠 Design reasoning:

0.8f keeps it subtle below that feels cartoonish.
Durations (400 → 300 ms) make loading snappy, because waiting UIs should never feel sluggish.
FastOutSlowInEasing makes the motion ease naturally in both directions.

3. Default / Content State Gentle Slide

slideInVertically(initialOffsetY = { it / 2 }) + fadeIn()
slideOutVertically(targetOffsetY = { it / 2 }) + fadeOut()

When switching between content states (say, from one composable to another), the animation should feel neutral neither alerting nor distracting.
This half-distance slide keeps visual continuity while maintaining flow.

💡 Calculation insight:_
Dividing by 2 keeps the movement within comfortable visual range (human eyes find 25–50% of screen height ideal for transitional motion)._

⚙️ Supporting Enum Logic

The AnimationTransitionType enum allows this system to stay context-aware:

enum class AnimationTransitionType {
    Error, Loading, Content, Default;
    fun <T> resolve(targetState: T): AnimationTransitionType { ... }
}

This layer lets any screen hook into the same animation language without repeating logic one pattern for every kind of stateful motion.

This abstraction mimics a design system the way Material defines color tokens, we’re defining motion tokens.

🧩 Integrating with Real UI States

Finally, we bind everything using ContentStateSwitcher:

@Composable
fun ContentStateSwitcher(
    isLoading: Boolean,
    modifier: Modifier = Modifier,
    error: String? = null,
    actionButton: Pair<String, () -> Unit>? = null,
    onContent: @Composable () -> Unit
) {
    val targetState = when {
        !error.isNullOrBlank() -> "ERROR"
        isLoading -> "LOADING"
        else -> "CONTENT"
    }
    StateSwitcherAnimator(targetState, modifier) { state ->
        when (state) {
            "ERROR" -> GeneralError(error.orEmpty(), actionButton = actionButton)
            "LOADING" -> RevibesLoading()
            "CONTENT" -> onContent()
        }
    }
}

This gives a unified place for handling async content instead of branching in multiple composables, you get one reactive motion system.

“Every state change tells a story, animation makes sure users don’t miss the plot.”

Final Thoughts: The Feel of Enterprise Elegance

I built these transitions to prove that small motion details can completely change how an app feels. The goal wasn’t to make it flashy it was to make it believable.

The duration values 250 ms, 400 ms, 500 ms aren’t random; they follow how humans perceive motion. Short transitions make interactions feel instant. Medium ones feel smooth and intentional. Long ones give breathing room for major context shifts.

The easing curves EaseOutQuart, EaseOutBack, FastOutSlowIn come from motion studies that model how physical objects move and settle. That’s why the animation feels grounded instead of robotic.

Even the math sliding in from width / 2, scaling from 0.9fhelps create subtle parallax and depth. You’re not throwing screens around; you’re guiding the user’s focus. It’s cinematic, not theatrical.

That balance is what gives an animation its enterprise-level polish: it’s quiet, intentional, and human. The kind that makes people say, “I don’t know why, but this feels right.”

🌱 See It in Action RevibesYou can experience this motion system live in Revibes on Google Play.

It’s built by my middle school mentee her first public release and focuses on raising environmental awareness and encouraging sustainable actions.

Some rough edges? Sure. But that’s the magic of early creation purpose meeting experimentation. The animations you’ve seen above power its smooth, meaningful flow.

🎓 Join My Mentoring Sessions on ADPListI mentor Android developers for free through ADPList from students just starting out to professionals refining their motion design and architecture skills.

Quick & Easy Glass Effects in Jetpack Compose

Joseph Sanjaya — Sun, 26 Oct 2025 07:42:16 +0000

When the Design Brief Says “Make It Look Like Glass”

The request came in during a design review:

“We want the new layout to feel glassy something with depth, light, and a touch of transparency.”

On paper, that sounds straightforward. In reality, it’s one of those UI challenges that sit right between design language and rendering logic. “Glassy” can mean a dozen different things depending on who says it. For designers, it’s about mood and perception. For engineers, it’s about how light and blur interact with the pixel pipeline.

That’s where Jetpack Compose gets interesting. It gives us the tools to think in layers surfaces, gradients, and modifiers without breaking composability. So, when the brief landed, our goal wasn’t just to fake transparency; it was to build a real sense of depth that behaves predictably and performs well.

We quickly learned that depth isn’t about turning down the opacity. It’s about how the background and foreground interact. The background softens; the foreground stays sharp. And when those two parts works in sync, your brain reads the surface as glass instead of just “see-through.”

“Depth happens when context blurs and focus stay clear.”

From that insight, the task became clear: two layers one for the blurred background, one for the crisp content.
That’s the foundation of everything that follows.

Understanding What “Glass” Actually Means in UI

Before touching a single line of Compose code, we had to answer one deceptively simple question:
What does “glass” really mean in digital design?

When designers talk about glass, they’re usually referencing how light behaves through a translucent surface not the surface itself. It’s not just about seeing what’s behind something; it’s about how the background becomes soft, how edges catch light, and how everything feels subtly three-dimensional.

So, the challenge isn’t to make a transparent box.
It’s to recreate how glass interacts with its environment.

“Real glass isn’t transparent it’s reactive.”

That insight guided how we approached the layout in Compose.
If you think about a piece of glass in the real world, it has two distinct layers of perception:

The background layer the world seen through the glass, slightly blurred, colors diffused.
The content layer, reflections, borders, or text on top, perfectly sharp and readable.

Those two layers together are what convince the human eye that the surface has depth.

To bring that logic into Compose, we needed a system where both layers could coexist independently:
a blurred base for context and a crisp top for interaction.
That separation would let us fine-tune realism adjusting how soft or strong the effect feels without reworking layouts.

That became our design rule moving forward:
every glass effect is built from at least two coordinated layers nothing more, nothing less.

In the next section, we’ll turn that concept into code and show how GlassContainer makes the illusion both reusable and predictable in Compose.

The Layered Approach

Once we understood glass as a layered material, the next question was how to express that elegantly in Compose.
We didn’t want another “UI trick.” It had to be composable, easy to theme, and lightweight enough to survive in production.

That’s where the idea of GlassContainer came in a layout that manages both the blurred background and the sharp content layer, while keeping its shape and boundaries consistent.

The implementation turned out to be surprisingly simple once the layering concept was right.

“One layer sets the mood; the other defines the focus.”

Here’s the core structure that powers it all:

@Composable
fun GlassContainer(
    modifier: Modifier = Modifier,
    shape: Shape = RoundedCornerShape(16.dp),
    blurRadius: Dp = 12.dp,
    backgroundAlpha: Float = 0.15f,
    borderAlpha: Float = 0.3f,
    borderWidth: Dp = 1.dp,
    content: @Composable () -> Unit
) {
    val surfaceColor = MaterialTheme.colors.surface
    val borderColor = MaterialTheme.colors.border
    Box(modifier = modifier.clip(shape)) {
        // Background layer with blur
        Box(
            modifier = Modifier
                .matchParentSize()
                .blur(radius = blurRadius)
                .background(brush = createGlassGradient(surfaceColor, backgroundAlpha))
                .border(width = borderWidth, brush = createGlassBorderGradient(borderColor, borderAlpha))
        )

        // Content layer stays sharp
        content()
    }
}

The composable uses a Box as the container, clipped to a shape. Inside it, we render two stacked layers:

The background layer uses Modifier.matchParentSize() to fill the container exactly. It applies blur, gradient, and border the ingredients that give it that glassy diffusion.
The content layer renders normally, untouched by blur, ensuring text and icons stay crisp.

That single line —

.matchParentSize()

— does most of the heavy lifting.
It locks the blur area to the same dimensions as your content region, preventing misaligned softness or inconsistent edges.

This approach has two big benefits:

It decouples design from effect. You can drop any composable inside without worrying about visual integrity.
It stays composable-friendly. No need for custom draw logic or external blur views.

Adding Realism with Gradients

Once the blur was working, we noticed something subtle: the surface still looked too clean.
It was transparent, sure but not alive.
Real glass has micro-variations in brightness and transparency that make it react to its surroundings. Without those, it just feels like a semi-transparent overlay.

So, we started layering gradients.

“Flat transparency looks artificial because real materials bend light unevenly.”

Instead of relying on a single color with reduced opacity, we introduced a vertical gradient.
At the top, it’s slightly brighter mimicking light catching the upper edge.
The middle stays neutral, and the bottom fades softly to maintain depth.

That tiny adjustment changes how your eye perceives the surface:
your brain reads it as curved, reflective, and physical rather than flat.

Here’s the helper we used:

private fun createGlassGradient(baseColor: Color, alpha: Float): Brush {
    return Brush.verticalGradient(
        colors = listOf(
            baseColor.copy(alpha = alpha * 1.1f),  // Slightly brighter at top
            baseColor.copy(alpha = alpha),         // Base opacity
            baseColor.copy(alpha = alpha)          // Consistent bottom
        )
    )
}

This gradient works because it introduces just enough contrast for the viewer to infer lighting direction.
It’s not something you consciously notice but it anchors the illusion in realism.

Then we applied a similar idea to the border.
Edges in real glass catch and scatter lighter, which creates that crisp rim glow designers love.
A second vertical gradient for the border gives that highlight near the top and softens it toward the bottom.

private fun createGlassBorderGradient(borderColor: Color, alpha: Float): Brush {
    return Brush.verticalGradient(
        colors = listOf(
            borderColor.copy(alpha = alpha * 1.5f),  // Strong highlight
            borderColor.copy(alpha = alpha * 0.3f),  // Fade in middle  
            borderColor.copy(alpha = alpha * 0.8f)   // Subtle bottom
        )
    )
}

Together, these gradients make a huge perceptual difference.
The component suddenly stops looking like “just transparency” and starts to behave like a material.
It refracts light, separates itself from the background, and feels consistent across themes. Result after applying gradient:

Reusable Variations That Scale with Your Design

After we got the glass effect looking right, the next challenge was consistency.
We didn’t want each screen or designer to invent their own blur strength or alpha combination.
The real power of Compose is that once a pattern is stable, it should scale effortlessly.

So, we abstracted the effect into variations light and heavy glass containers each tuned for a different purpose.

“Consistency isn’t limitation; it’s leverage.”

The lighter version is subtle good for overlays, cards, or backgrounds where content underneath should still peek through.
The heavier version has stronger blur and opacity, ideal for modals or drawers where you need visual separation.

@Composable
fun LightGlassContainer(/* ... */) {
    GlassContainer(
        blurRadius = 6.dp,
        backgroundAlpha = 0.06f,
        borderAlpha = 0.12f
    ) { content() }
}
@Composable  
fun HeavyGlassContainer(/* ... */) {
    GlassContainer(
        blurRadius = 16.dp,
        backgroundAlpha = 0.12f,
        borderAlpha = 0.25f
    ) { content() }
}

This small abstraction turned out to be the real win.
By treating glass as a reusable composable, not a visual trick, we could easily adapt it across our app.

Here’s a closing statement for your article, written in that same casual and smart style, which incorporates your animated background idea.

Taking It Further: Making the Glass Reactive

We’ve successfully built a GlassContainer that’s reusable, theme-friendly, and scales with our design system. We’ve separated the blurred background from the crisp content and added subtle gradients to mimic how real-world light catches an edge.

But we can push this illusion one step further.

Early on, we noted that “real glass isn’t transparent it’s reactive”. Our GlassContainer looks great on a static background, but to make it feel truly alive, it needs something to react to.

This is where a dynamic background comes in. By placing a subtle, animated gradient behind our glass components, the blur effect suddenly has shifting light to catch and diffuse. The glass no longer feels like a static overlay; it feels like a physical object interacting with a living environment.

Here’s a quick way to create a “light bleed” animation, simplified to just the dark-mode colors that match our final design:

// --- Define our dark palette ---
// (Assuming these are defined in your theme)
val blue = Color(0xFF3A7DFF)
val midnight = Color(0xFF161A3C)
val grape = Color(0xFF5A4BFF)
val nearBlack = Color(0xFF0D0F21)
// --------------------------------
@Composable
fun AnimatedLightBleedBackground(
    modifier: Modifier = Modifier,
    animationDurationMs: Int = 8000,
    bleedIntensity: Float = 0.15f
) {
    val infiniteTransition = rememberInfiniteTransition(label = "lightBleedTransition")
    val animationProgress by infiniteTransition.animateFloat(
        initialValue = 0f,
        targetValue = 1f,
        animationSpec = infiniteRepeatable(
            animation = tween(
                durationMillis = animationDurationMs,
                easing = LinearEasing
            ),
            repeatMode = RepeatMode.Restart
        ),
        label = "lightBleedProgress"
    )
    val darkColors = remember(bleedIntensity) {
        createDarkModeColors(bleedIntensity)
    }
    Canvas(
        modifier = modifier.fillMaxSize()
    ) {
        // Use the provided custom drawing logic
        drawNaturalLight(
            animationProgress = animationProgress,
            colors = darkColors
        )
    }
}
private fun createDarkModeColors(bleedIntensity: Float): List<Color> {
    return listOf(
        blue.copy(alpha = bleedIntensity * 1.8f),
        midnight.copy(alpha = bleedIntensity * 1.2f),
        grape.copy(alpha = bleedIntensity * 0.8f),
        midnight.copy(alpha = bleedIntensity * 0.6f),
        nearBlack.copy(alpha = bleedIntensity * 0.4f),
        Color.Transparent,
        Color.Transparent
    )
}
/**
 * Draws a natural, multi-source light bleed effect that
 * animates gently.
 */
private fun DrawScope.drawNaturalLight(
    animationProgress: Float,
    colors: List<Color>
) {
    val lightSourceX = size.width * 0.85f
    val lightSourceY = size.height * 0.15f
    // Calculate animated positions for the primary light source
    val animatedX = lightSourceX + cos(animationProgress * 2 * Math.PI).toFloat() * size.width * 0.02f
    val animatedY = lightSourceY + sin(animationProgress * 2 * Math.PI * 0.7f).toFloat() * size.height * 0.015f
    // Define multiple light sources for a more complex, natural feel
    val lightSources = listOf(
        Offset(animatedX, animatedY), // Primary source
        Offset(animatedX - size.width * 0.05f, animatedY + size.height * 0.03f), // Secondary
        Offset(animatedX + size.width * 0.03f, animatedY - size.height * 0.02f)  // Tertiary
    )
    lightSources.forEachIndexed { index, lightSource ->
        // Vary the radius for each light source
        val radiusMultiplier = when (index) {
            0 -> 1.2f // Main light is largest
            1 -> 0.8f
            else -> 0.6f
        }
        // Vary the intensity (alpha) for each light source
        val intensityMultiplier = when (index) {
            0 -> 1.0f // Main light is brightest
            1 -> 0.6f
            else -> 0.4f
        }
        val radius = size.width * radiusMultiplier
        // Apply the intensity multiplier to the base colors
        val naturalColors = colors.map { color ->
            color.copy(alpha = color.alpha * intensityMultiplier)
        }
        val brush = Brush.radialGradient(
            colors = naturalColors,
            center = lightSource,
            radius = radius
        )
        drawRect(
            brush = brush,
            size = size
        )
    }
}

The Final Combination

Now, we put it all together.

In our main screen, we use a Box to create our layers. The AnimatedLightBleedBackground goes at the very bottom. On top of that, we stack our GlassContainer elements (like the "Account Information" and "Settings" cards).

The result is a UI that feels both deep and dynamic. The animated background provides just enough shifting light for the blurred layer of our glass cards to catch and diffuse. The content on top, like “Settings,” stays perfectly sharp and readable.

This combination is what finally delivers on that initial brief. We didn’t just make a transparent box; we built a small, layered system that creates a believable and truly “glassy” effect.

Mastering Engineering Habits for Growth

Joseph Sanjaya — Sun, 19 Oct 2025 05:58:48 +0000

It’s my turn for our team’s mini tech talk this week. You know the drill someone’s gotta bring a topic that’s interesting enough to keep people from checking social media halfway through.

I wanted to talk about something deeper than just tools or frameworks. Something that actually sticks.
Coincidentally, I’m in the middle of finishing Better Than Before by Gretchen Rubin, a book about mastering habits in everyday life.

And as I was reading it, something clicked: everything Rubin writes about habits how we form them, why we break them, how tiny changes compound applies frighteningly well to how we grow as engineers.

Think about it.
The way we review pull requests, plan features, pick up new frameworks, or avoid touching that legacy module it’s all habit.
We often mistake skill for experience, but the truth is, what really defines a great engineer is how they build repeatable patterns of improvement.

“What we do every day matters more than what we do once in a while.” — Gretchen Rubin

So, instead of another deep dive into architecture patterns or the latest AI framework, I thought why not talk about the habits that actually make us better engineers in this harsh, demanding tech world?

This article isn’t about “hustling harder.” The industry already worships at that altar.
It’s about designing better engineering habits using Rubin’s five strategies:
Scheduling, First Steps, The Lightning Bolt, Monitoring, and The One Coin Loophole.

These are ideas from psychology and behavior science, reframed for the engineer who wants to build long-term mastery not burnout.

The Engineering Grind Loop

Most engineers don’t burn out because they’re lazy.
They burn out because they’re always on.

Every sprint bleeds into the next.
Meetings stretch into “just one more task.”
Even after shipping, our brains won’t stop benchmarking themselves against someone else’s Git activity.

We live inside the machine and the machine never sleeps.

The modern engineering world quietly worships hustle culture.
It’s the unspoken rule that your value equals your output.
We glorify the developer who fixes bugs at midnight, the architect who “lives and breathes code,” the founder who hasn’t taken a weekend in years.

It sounds noble until it becomes noise.
Every podcast, every tweet, every LinkedIn post tells us to optimize ourselves more.
Ship faster. Learn Rust. Write threads. Publish side projects.
It’s an infinite feedback loop of performance disguised as growth.

But like any overloaded system, it eventually collapses.

We try to fix it the way we fix everything else: with optimization.
We buy new apps, reorganize Notion boards, experiment with productivity frameworks like they’re new libraries to import.
For a while, it works. Then entropy takes over.

“Habits are the invisible architecture of daily life.” — Gretchen Rubin

That line hit me hard.
Because in engineering, architecture is everything and most of us are building our days on fragile, undocumented systems.

We keep pushing hotfixes into our routines instead of designing them properly.
We don’t test. We don’t monitor. And eventually, the system crashes.

Hustle culture tells us the fix is to run faster.
But the real fix is to redesign the system itself.

The world won’t slow down frameworks will keep updating, expectations will keep rising.

So the question isn’t how do I keep up?
It’s how do I build habits that keep me stable while everything else moves fast?

That’s where Rubin’s strategies come in not as motivational fluff, but as genuine design patterns for the self.
Because if you can design reliable systems for distributed microservices, you can design one for your own well-being too.

Strategy 1: The Power of Scheduling, Build Rituals Like Cron Jobs

The first strategy Rubin talks about is scheduling, the simple act of deciding when you’ll do something, instead of endlessly debating whether to do it.

Sounds basic, right?
But that tiny shift changes everything.

In code, once you automate a process say a nightly build or a deployment you stop thinking about it. It just happens.
Scheduling habits works the same way.
Once something is on the calendar, your brain stops negotiating with itself.

No more internal debates like “Should I learn that new framework tonight?” or “Maybe I’ll refactor later.”
You’ve already made the decision once the system will execute it

“We can build habits by deciding not to decide.” — Gretchen Rubin

That’s why the best engineers I know don’t rely on bursts of motivation.
They rely on rituals.
A fixed morning slot for learning.
A Friday hour blocked for cleaning up tech debt.
A recurring calendar reminder for journaling ideas or documenting architecture.

At first, these feel rigid. But in reality, they create freedom the same kind you get when automation removes repetitive tasks.

Because if every decision costs energy, scheduling is how you write a scheduler for your life.

⚡ Practical Takeaway for Engineers

Start small. Don’t build a new system overnight.
Just pick one recurring thing that matters and automate it.
Maybe it’s a 15-minute slot to review your pull requests, or to read docs before daily stand-up.

Make it non-negotiable.
Make it boring.
That’s the point.

Once it runs smoothly, it becomes part of your mental infrastructure reliable, predictable, and beautifully unremarkable.

That’s what a real habit looks like.

Section 2: The First Step Start Small, Ship Something

One of Gretchen Rubin’s most deceptively simple ideas is The Strategy of the First Step.
To begin a habit, you just need to begin. Not plan, not research tools for three days, not color-code a Notion board just start.

As engineers, we’re world-class at avoiding first steps.
We tell ourselves we’re “setting up the architecture” or “exploring options,” but half the time, we’re just over-preparing. Our brains crave the illusion of progress instead of the discomfort of actually building.

“The first step is small but once taken, it creates its own energy.” — Better Than Before

That’s exactly what pushed me to create my own build logic repository:

👉🏻 [sjy-build-logic](https://github.com/Sanjaya-Inc/sjy-build-logic).

For years, I noticed how much friction existed every time I started a new Android project. Reconfiguring Gradle files. Re-adding dependencies I always use. Re-tweaking project structures. Each time, the real first step actually writing code got delayed behind repetitive setup.

So I built my own starting point.
The repo now contains everything I usually need: dependency catalogs, Android Studio templates, project configurations from compile SDK to test frameworks all the boring parts automated.
Now, spinning up a new project isn’t a mental mountain. It’s one command, and I’m straight into momentum mode.

But here’s the best part: it updates itself.
Whenever the frameworks evolve or new stable versions drop, the setup refreshes automatically using dependabot. That means I don’t waste energy keeping up I just start coding, always on the latest stack.

That’s what Rubin means by mastering the first step: make it so easy, you can’t not start.
It’s not about removing effort it’s about removing resistance.

In an industry that glorifies “10x speed” and “hustle harder,” it’s easy to overlook the quiet power of small beginnings.
But the truth is, mastery rarely starts with a grand launch. It starts with a repo, a file, a function and the courage to make it exist.

Section 3: The Lightning Bolt When Change Hits You Hard

Every once in a while, something hits you so clearly that it changes how you work forever. Gretchen Rubin calls this The Strategy of the Lightning Bolt a sudden moment of insight that makes a new habit not just appealing, but inevitable.

We’ve all felt it as engineers.
That late-night realization that the architecture you’ve been defending is actually holding the team back.
That one tech talk that makes you rethink how you’ve been testing.
Or that single line in a pull request comment that rewires your entire approach to clean code.

For me, one of those lightning-bolt moments was realizing how much friction was silently draining my creativity. I’d spend more time fighting boilerplate and build errors than building ideas.
That’s what led me to systemize my own tooling, automate setup, and ultimately create sjy-build-logic.

But this time, the motivation didn’t come from planning it came from frustration. And frustration, when channeled right, can be lightning in a bottle.

“Some changes are gradual, but others happen in a flash when we’re struck by a powerful insight that alters everything.” — Better Than Before

The Lightning Bolt is rare, but when it strikes, it rewrites the rules of your game. It’s the spark behind every great open-source project, every bold refactor, every side project that suddenly consumes your weekend in the best way.

In a culture that romanticizes grind, we sometimes forget how valuable these moments of emotional clarity are.
You can’t schedule them. You can’t automate them. But you can recognize them and when they come, act fast before the feeling fades.

Because the truth is, change doesn’t always require discipline. Sometimes it just requires electricity and the courage to follow it.

Section 4: Monitoring Debug Yourself Like Production Code

After a Lightning Bolt moment, motivation surges but it never lasts forever. That’s where Gretchen Rubin’s Strategy of Monitoring steps in. She writes that “we manage what we monitor.”
And honestly, no group understands that better than engineers.

When something’s in production, we don’t just hope it behaves well we instrument it, observe it, and set up alerts. We track uptime, latency, user engagement, crash rates.
But when it comes to ourselves our learning pace, our focus, our burnout risk we often fly blind.

We forget that we are the system.

“Self-knowledge is the foundation of habit change.” — Better Than Before

That realization hit me when I noticed I was constantly jumping between projects, convinced I was being “productive.” In truth, I was context-switching myself into exhaustion.
So, I started debugging my own patterns. I tracked when I wrote my best code (mornings), when I got distracted (afternoons), and how often I overcommitted (always).

Eventually, I began treating my workflow like an observability problem.
Just like I’d analyze logs or performance metrics, I’d note down how long tasks actually took compared to how long I thought they would.
Turns out, my mental estimates were off by a consistent 30–40%. Once I saw the data, it stopped being personal it became debuggable.

The beautiful thing about monitoring is that it removes judgment.
You don’t need to guilt-trip yourself for being tired or slow you just read the logs and optimize.
That mindset shift alone changed everything. My calendar became a dashboard, not a to-do list. My progress stopped being about emotion and started being about evidence.

In engineering, we love to say “if you can’t measure it, you can’t improve it.”
That’s true for code and even truer for ourselves.

Section 5: The One Coin Loophole When “Just Once” Becomes a Bug

Gretchen Rubin tells a story about a man who kept adding coins to a jar every day.
One coin alone meant nothing but over time, it made him rich.
The flip side is just as true: skipping “just one coin” doesn’t seem like a big deal… until it becomes a habit of exceptions.
She calls this The One Coin Loophole our tendency to tell ourselves that one small deviation doesn’t matter.

Engineers know how that story ends.
Because “just once” is how production bugs are born.

“What we do ‘just this once,’ we often do again and again.” — Better Than Before

We see it all the time:

“I’ll skip writing this test, just this once.”
“I’ll push directly to main, just this once.”
“I’ll skip the code review it’s urgent.”

It’s innocent, even logical in the moment. But the cost compounds quietly, like technical debt disguised as efficiency.
The danger isn’t the exception it’s the normalization of it.

I’ve seen this play out not just in code, but in habits too.
Skip one personal retrospective. Miss one refactor sprint. Delay one cleanup task. Suddenly, the system you built to keep yourself sharp starts drifting out of sync.
And like any complex system, once entropy sets in, recovery takes far more effort than maintenance ever did.

That’s why I treat my own process like a living codebase.
When I catch myself saying “just this once,” I pause and ask:
Would I accept this logic in production?

Most of the time, the answer’s obvious.

The One Coin Loophole isn’t about guilt it’s about awareness. It’s the reminder that consistency, not intensity, defines growth.
Habits, like systems, thrive on small correctnesses tiny acts of integrity repeated long enough to become invisible.

And that’s how good engineers become great ones.
Not by doing everything perfectly, but by refusing to let “just once” become “every time.”

Closing: Building Momentum, Not Just Code

At the end of the day, growth isn’t about doing more things it’s about removing the friction between you and momentum. For me, that’s exactly why I built [**sjy-build-logic**](https://github.com/Sanjaya-Inc/sjy-build-logic).

It’s not just another Gradle setup. It’s a living foundation a repository that evolves automatically, preloaded with every dependency, Android Studio template, and project configuration I rely on daily. It means when an idea strikes, I don’t waste energy wiring things up I just create, run, and iterate.

Every engineer needs their own version of this: a launchpad that eliminates hesitation and keeps you focused on building things that matter. Because once you remove the friction, consistency follows naturally and that’s where mastery begins.

References:

Better Than Before: Mastering the Habits of Our Everyday Lives — Gretchen Rubin

📚 Originally published on Medium.

💬 I also share free mentoring sessions on ADPList.

🚀 Let’s connect and talk about Android, Kotlin, and building great systems together!

Offline-First Challenge: Making CSV & PDF Reports Right on Android

Joseph Sanjaya — Sat, 18 Oct 2025 14:42:05 +0000

Usually, when someone asks for a “report feature,” we Android devs breathe easy that’s backend territory. We send the data, wait for a neat PDF or CSV, and move on with our day.

Not this time.

The requirement came with one deceptively simple line: “It has to work fully offline.”

No APIs. No internet. No backend wizardry. Everything had to happen locally, right inside the Android app.

“Sometimes the hardest part of an offline app isn’t the lack of network it’s realizing the phone is your backend now.”

What started as a “simple export button” turned into a deep dive through file permissions, document contracts, and Compose rendering quirks. Somewhere between debugging URI access and watching Compose draw on an invisible canvas, I realized this wasn’t just about exporting data it was about rethinking what ‘frontend’ really means.

The Problem: When Servers Step Aside

Most Android apps live in a comfortable ecosystem data comes from APIs, heavy work happens on the server, and we just display the results beautifully.

But take away the server, and everything changes. Suddenly, you’re not just designing UI you’re handling the entire workflow: data collection, structuring, rendering, and writing files to storage.

“The moment your app goes offline, you stop being a client developer you become a system architect.”

Offline-first development forces you to think differently. It’s not just about making things work without the internet it’s about designing an experience that feels complete, even in isolation.

CSV Generation: The Warmup

Before diving into the PDF rabbit hole, there was the warm-up round generating CSV files. Compared to Compose and pagination math, this felt like a vacation.

A CSV is basically structured text with commas. You don’t need fancy rendering or layout logic, just clean data and careful escaping.

“CSV generation is that rare Android task that behaves exactly how you expect it to.”

In Compose, you can kick off file creation with the Storage Access Framework.
This ensures users choose where the CSV goes, while your app writes safely through a provided URI:

val csvLauncher = rememberLauncherForActivityResult(
    contract = ActivityResultContracts.CreateDocument("text/csv"),
    onResult = { uri ->
        if (uri != null) {
            csvWriter.writeCsv(uri, transactions)
        }
    }
)

When triggered (say, from a button click), this opens Android’s file picker so the user can pick the save location.

Next, the writer itself lightweight, dependency-free, and easy to plug into any project:

class CsvWriter(
    private val transactionCsvMapper: TransactionCsvMapper,
    private val context: Context
) {
    fun writeCsv(uri: Uri, transactions: List<ExportedTransaction>) {
        context.contentResolver.openOutputStream(uri)?.use { output ->
            val headers = TransactionCsvMapper.HEADERS
            val rows = transactions.map { transactionCsvMapper.toCsvRow(it) }            BufferedWriter(OutputStreamWriter(output)).use { writer ->
                writer.appendLine(headers.joinToString(","))
                for (row in rows) {
                    writer.appendLine(row.joinToString(",") { escapeCsv(it) })
                }
            }
        }
    }    
private fun escapeCsv(value: String): String {
        val needsQuotes = value.contains(",") || value.contains("\"") || value.contains("\n")
        return if (needsQuotes) "\"${value.replace("\"", "\"\"")}\"" else value
    }
}

That’s all you need. No external libraries, no fragile permissions hacks just clean Kotlin I/O.
When you trigger the launcher, the system handles file creation and your writer takes care of the content.

There’s a certain joy in that simplicity. No layouts, no rendering, no UI thread drama. Just data in, file out.

The Built-in PDF Way

Before we jumped into custom layouts, life was simple.
Android already gives you a handy class called PdfDocumentyou just draw directly onto a Canvas.

Here’s what a minimal version looks like:

val pdfDocument = PdfDocument()
val pageInfo = PdfDocument.PageInfo.Builder(595, 842, 1).create()
val page = pdfDocument.startPage(pageInfo)
val canvas = page.canvas
val paint = Paint().apply { textSize = 16f }
canvas.drawText("Hello, PDF World!", 50f, 50f, paint)
pdfDocument.finishPage(page)
val file = File(context.cacheDir, "report.pdf")
pdfDocument.writeTo(FileOutputStream(file))
pdfDocument.close()

✅ Pros:

Runs fully offline.
Works fine for static text or simple receipts.
Lightweight and dependency-free.

❌ Cons:

No layout engine you calculate everything manually.
Forget about Compose, dynamic grids, or pretty formatting.

Custom-Designed PDFs with Compose

Okay, now we’re getting into the fun (and slightly painful) part.

When the requirement changed from “just export a PDF” to “make it look beautiful, like a real report”, the built-in PdfDocument wasn’t enough anymore. You can draw text and rectangles but not full layouts, grids, or dynamic tables like Compose gives us.

The dream:

“What if we could use the same Jetpack Compose UI that powers our app screen, and print that as a PDF?”

That’s exactly what we did.
But to make it work, we first needed to define a precise page specification because print layouts aren’t like pixels on a phone screen.

Step 1: Defining the Page Specs

Printing uses typographic points instead of pixels, and your layout must scale correctly for real-world paper sizes like A4 or Letter.
So we start by defining a PageSpec and a PdfPageConfig to handle this conversion neatly.

enum class PageSpec(val widthPoints: Double, val heightPoints: Double) {
    A4(595.2755905511812, 841.8897637795277),
    LETTER(612.0, 792.0);
    fun toPx(dpi: Int): Pair<Int, Int> {
        val scale = dpi.toDouble() / 72.0
        val widthPx = round(widthPoints * scale).toInt()
        val heightPx = round(heightPoints * scale).toInt()
        return Pair(widthPx, heightPx)
    }
    companion object {
        fun fromLocale(locale: Locale): PageSpec {
            return when (locale.country.uppercase(Locale.ROOT)) {
                "US", "CA", "MX" -> LETTER
                else -> A4
            }
        }
    }
}
data class PdfPageConfig(
    val pageSpec: PageSpec = PageSpec.fromLocale(Locale.getDefault()),
    val dpi: Int = 300
) {
    fun getSizePx() = pageSpec.toPx(dpi)
}

This lets us dynamically adapt to paper type, locale, and print DPI without hardcoding anything.
It also ensures that when Compose renders off-screen, our elements will line up perfectly when printed.

Step 2: Building the Composable Page

The key trick here is when rendering to PDF, your Composable must match exactly the size of a printed page no scrolling, no “infinite height”.

That’s where Modifier.requiredSize() comes in.
Here’s how our export composable looks:

@Composable
fun ExportTxPdf(
    fileName: String,
    transactions: PersistentList<ExportedTransaction>,
    pageIndex: Int,
    totalPages: Int,
    pdfPageConfig: PdfPageConfig
    modifier: Modifier = Modifier
) {
    val tableSpec = remember { ExportTxTableSpec.default() }
    val (pageWidthPx, pageHeightPx) = pdfPageConfig.getSizePx()
    val density = LocalDensity.current
    val pageWidthDp = with(density) { pageWidthPx.toDp() }
    val pageHeightDp = with(density) { pageHeightPx.toDp() }    
    Column(
        modifier = modifier
            .requiredSize(pageWidthDp, pageHeightDp)
            .padding(16.dp),
        verticalArrangement = Arrangement.spacedBy(8.dp)
    ) {
        ExportTxHeader(tableSpec)
        transactions.forEachIndexed { index, transaction ->
            val color = if (index % 2 == 0) Color(0xFFE9E6F7) else Color.White
            ExportTxTableItem(tableSpec, transaction, color = color)
        }
        Spacer(modifier = Modifier.weight(1f))
        ExportTxFooter(fileName, pageIndex, totalPages)
    }
}

Each page is rendered like a real paper same width, same height, all inside a Compose layout.

No guesswork, no scaling errors.

💡 Pro tip (quote block idea):_
“When you treat your PDF page as a Compose layout, you stop thinking in pixels you start designing paper.”_

Step 3: Printing the Composables to PDF

Once each Composable page is ready, we still need to print it into a real PDF document.
That means rendering the Compose view to a Bitmap, then drawing it onto the PdfDocument page canvas.

Here’s the helper extension we use for that:

private fun List<View>.saveAsPdf(outputStream: OutputStream) {
    if (isEmpty()) return
    val dpi = 300
    val pageSpec = PageSpec.A4
    val (pageWidthPx, pageHeightPx) = pageSpec.toPx(dpi)
    val document = PdfDocument()
    forEachIndexed { index, view ->
        val widthSpec = View.MeasureSpec.makeMeasureSpec(pageWidthPx, View.MeasureSpec.EXACTLY)
        val heightSpec = View.MeasureSpec.makeMeasureSpec(pageHeightPx, View.MeasureSpec.EXACTLY)
        view.measure(widthSpec, heightSpec)
        view.layout(0, 0, pageWidthPx, pageHeightPx)
        val bitmap = createBitmap(pageWidthPx, pageHeightPx)
        val canvas = Canvas(bitmap)
        view.draw(canvas)
        val pageInfo = PdfDocument.PageInfo.Builder(pageWidthPx, pageHeightPx, index + 1).create()
        val page = document.startPage(pageInfo)
        page.canvas.drawBitmap(bitmap, 0f, 0f, null)
        document.finishPage(page)
        bitmap.recycle()
    }
    document.writeTo(outputStream)
    document.close()
}

This method converts a list of offscreen-rendered Compose views into a print-ready, paginated PDF all offline, all on device.

Now here’s the catch: Compose rendering must happen on the main thread. You can’t just call it inside a background coroutine like your CSV export it’ll crash or hang.
So, you need to offload heavy work like bitmap compression or file writing to Dispatchers.IO, but keep the Compose snapshot creation on the UI thread.

🏁 Wrapping It All Up

All this work landed as a new feature in open-source app (Brain Wallet) that I actively maintained, now you can export transactions directly to CSV or beautifully styled PDFs.

Check it out here:
👉 GitHub —gruntsoftware/android: The open source code of Brainwallet Android

Download Here:
👉Brainwallet®: Buy Litecoin — Apps on Google Play

🌱 Takeaways

To wrap it up neatly:

✅ Compose can render beautiful PDFs but it must run on the UI thread.
📐 Accurate page specs (points → pixels → Dp) are key for consistent layouts.
🧮 Handling pagination and page size manually is unavoidable but rewarding.
💾 CSV export is the easy win but custom PDFs are where the real learning begins.
🚀 And yes, you can now build full offline report systems entirely on Android.

📚 Originally published on Medium.

💬 I also share free mentoring sessions on ADPList.

🚀 Let’s connect and talk about Android, Kotlin, and building great systems together!

When Smart People Clash: What Engineering Taught Me About NVC

Joseph Sanjaya — Fri, 17 Oct 2025 07:18:33 +0000

My coworker gave a short tech talk today not about Kotlin or CI pipelines, but about Nonviolent Communication. And it hit me. Hard.

Because conflict in teams is one of those things we all quietly struggle with. No matter how good the tech stack is, no matter how clean the architecture once communication breaks down, everything else starts to rot.

You’ve seen it before: a small disagreement turns into a cold silence. A code review starts feeling personal. A team that used to brainstorm freely suddenly just plays it safe.

That talk made me realize something uncomfortable but true:

“We spend our days debugging systems, yet we rarely stop to debug how we talk to each other.”

The Real Cost of Conflict

Conflict doesn’t start loud it starts quiet. It starts with a sigh on workspace chats. A “fine, I’ll do it myself.” A meeting where someone clearly wants to say something but doesn’t.

In engineering teams, these tiny moments stack up like unhandled exceptions. One unspoken frustration becomes two, then five, and before you know it, your high-performing team starts feeling like a collection of isolated freelancers.

“When engineers stop talking honestly, teams don’t just lose velocity, they lose safety.”

And the scary thing? You can still ship features while your team is quietly falling apart. That’s what makes communication breakdowns so dangerous they don’t show up in metrics. You’ll still hit sprint goals, still merge PRs, still deliver builds. But underneath, trust is decaying.

Soon, feedback feels like an attack. Architecture discussions turn into turf wars. The best people stop speaking up because it’s easier to stay quiet than to be misunderstood.

And once that happens, even the cleanest codebase can’t save the culture.

Discovering Nonviolent Communication

At its core, NVC is simple: it’s a way of talking that separates what happened from how we feel about it, and what we need from what we demand.
It’s built on four small but surprisingly powerful steps:

Observation: describe what you see without judgment.
Feeling: name how it makes you feel.
Need: express the value or need behind that feeling.
Request: ask for a concrete action, not a threat or demand.

Sounds easy, right? It’s not. Because our brains are wired to judge before we understand.

“We’re quick to debug code, but slow to debug assumptions.”

Imagine a typical code review comment:

“You didn’t follow the architecture guidelines.”

Now, apply a bit of NVC thinking:

“I noticed the implementation doesn’t follow our shared architecture guideline. I feel concerned because consistency helps us maintain long-term readability. Could we revisit this approach together?”

The difference isn’t just tone it’s intent. One message points a finger; the other opens a door.

NVC doesn’t mean avoiding hard feedback or sugarcoating problems. It’s about removing unnecessary violence, the subtle edge in our words that turns collaboration into conflict.

And just like writing clean code, clarity here takes effort. The cleaner you express what you observe and need, the easier it is for others to understand your intent without defensiveness.

Don’t Debug People in Public

One of the hardest lessons I’ve learned in engineering teams is that how you deliver feedback matters as much as what you’re saying.

When feedback turns into a group event a thread, a meeting callout, or a “let’s all discuss this one person’s decision” moment it stops being about learning. It starts feeling like exposure.

Public criticism, even if technically correct, lands like a personal attack.
The person on the receiving end doesn’t hear your logic they hear the message beneath it: “You don’t belong here.”

“Once feedback feels like comparison, the goal shifts from improvement to survival.”

Nonviolent Communication teaches the opposite approach: empathy scales best one-on-one.

Pull someone aside. Ask questions instead of assigning blame. Listen for intent before judging execution.

Private space turns feedback from humiliation into dialogue. That’s where understanding lives and understanding is what keeps teams together.

The Consequences of Ignoring This

The thing about communication bugs is that they don’t crash immediately. They degrade slowly, like memory leaks in culture.

Teams that don’t talk stop trusting.
Teams that don’t trust stop collaborating.
And teams that stop collaborating start quietly dying, even while the sprint board looks perfectly healthy.

You start hearing phrases like, “Let’s just do it this way,” instead of, “What if we tried this?” Decisions become political. Feedback becomes personal. And brilliant engineers start looking for new jobs, not because of the tech, but because of the tone.

“You can fix bad code. You can’t fix a team that’s stopped talking.”

Debugging Ourselves

The more I think about it, the more it’s clear: most “technical” problems aren’t about code, they’re about people.

Nonviolent Communication is basically clean code for conversations. When words get messy, intent gets lost.

Small rewrites go a long way:

“You should’ve known” → “I wish we’d talked earlier.”
“That’s wrong” → “Can you walk me through your thinking?”

Same message, totally different vibe.

Conflict isn’t bad. Avoiding it is.
Good teams argue they just do it safely.

So next time things get tense, pause and ask yourself:

“What do I really feel, and how can I say it without blame?”

That little pause? It’s like linting your words before pushing them to prod.

References

Marshall Rosenberg’s Nonviolent Communication book

📚 Originally published on Medium.

💬 I also share free mentoring sessions on ADPList.

🚀 Let’s connect and talk about Android, Kotlin, and building great systems together!