Forem: Elimihele God's favour

The Future of Compose UI with JetStart

Elimihele God's favour — Sun, 05 Apr 2026 15:23:08 +0000

Jetpack Compose completely changed how we write Android UIs. It brought declarative programming to an ecosystem desperate for it. But while the code changed, the tooling didn't.

Android developers were writing elegant, modern Compose code, but compiling it using a heavily bloated, multi-minute, slow pipeline. We built JetStart to bring the tooling into the modern era.

Where JetStart is Going

We successfully replaced our old DSL parser with raw DEX compilation. This allows developers to use genuine Compose functions without any syntax hacks. What's next for the JetStart ecosystem?

1. Expanded Desktop & iOS Support

Kotlin Multiplatform (KMP) has taken the world by storm. Compose isn't just for Android anymore—it's for iOS and Desktop natively. JetStart currently focuses heavily on the Android execution path, but we are working on abstracting our WebSocket injection layer to target Compose Multiplatform apps on iOS and macOS/Windows.

2. Live State Injection

Live hot reload is amazing, but it can lose local UI state if an overarching class is redefined. We are building a memory-graph inspector that captures the Compose tree's state payload right before the hot-reload byte replacement and injects it back after the class loads.

3. VS Code & IntelliJ Extensions

We are finalizing our JetStart VS Code Extension and planning an IntelliJ plugin to tightly bind the OverrideGenerator warnings, connection statuses, and logs directly into your IDE.

JetStart is more than just a hot-reload CLI—it is a philosophical shift in how Android apps are compiled and tested. Try npx jetstart create my-app today and see the future of Android development.

Why Build Systems Matter: Ditching Gradle for WebSockets

Elimihele God's favour — Sun, 05 Apr 2026 15:13:44 +0000

Gradle is an incredible piece of engineering. It manages complex dependency trees, supports endless plugins, and orchestrates build tasks in a way that scales well for enterprise applications.

But for the inner development loop—the seconds between writing code and seeing the result—Gradle is an obstacle. If you simply want to change a padding value on a Compose UI screen, running a full Gradle evaluation is overkill. The overhead of task execution graphs, even with caching enabled, causes noticeable delays.

The JetStart Solution: Sidestepping Gradle

We realized that to get instant, state-preserving hot reloads on physical Android devices, we couldn't rely on Gradle. We had to build our own compiler pipeline specifically designed for the edit-refresh cycle.

When you run jetstart dev, Gradle is nowhere to be found. Instead, we run a custom Node.js server that binds a file system watcher to your .kt files. When an edit occurs, we run a raw kotlinc command on that singular file. We bypass the build system entirely.

Once kotlinc outputs a Java class, we run d8 to generate DEX bytecode. And because ADB (Android Debug Bridge) is too slow for our needs, we built a WebSocket connection between our dev server and the physical device. The device listens on port 8766 for raw byte arrays and loads them into a custom ClassLoader instantly.

The Best of Both Worlds

We didn't completely kill Gradle—we just put it in its place. When you run jetstart build, we hand the process back to Gradle to compile an APK, manage dependencies, and digitally sign your app.

JetStart gives you the blinding speed of WebSockets for UI work, and the reliable build process of Gradle for production releases. This hybrid approach represents the future of Android development.

Android Emulator vs Physical Device: Picking Your Development Target

Elimihele God's favour — Sun, 05 Apr 2026 15:05:52 +0000

JetStart gives Android developers a choice. I wanted to make sure you could hot reload your Kotlin Compose UIs exactly how you prefer whether that's directly onto a physical Android device or using a high-performance Android Emulator.

Which one is right for your workflow? Here is how I built both paths to ensure you never have to wait for Gradle again.

The Gold Standard: Physical Device Hot Reload

There is no substitute for feeling an app in your hands. To achieve live, state-preserving speeds on a physical device, I had to develop a custom injection architecture. JetStart intercepts your file edits, runs kotlinc and d8 in the background, and pushes raw DEX bytecode via WebSocket directly to a custom ClassLoader inside your running app.

Pros: It is the "real" environment. Colors, native Android choreography, and touch latency are 100% accurate.
Cons: Requires a physical device connected via USB or the same Wi-Fi network.

The Virtual Powerhouse: Android Emulator

If you don't have a device handy, the Android Emulator is the next best thing. I’ve fully integrated AVD (Android Virtual Device) management into the JetStart CLI so you don't even need to open Android Studio.

By running npx jetstart android-emulator, you can create "JetStart-optimized" emulators that are pre-configured for speed. When you run npx jetstart dev --emulator, the CLI automatically detects the running emulator, installs the client, and establishes the hot reload connection for you.

Pros: No cables required. It stays on your screen alongside your IDE. Supports multiple configurations and API levels.
Cons: Requires hardware acceleration (VT-x/AMD-V) and can be resource-intensive on older machines.

Experimental Fallback: The Web Emulator

I also included a Web Emulator as a tactical fallback. By running jetstart dev --web, the CLI starts a secondary pipeline that transpiles your Compose code to JavaScript (ES modules) and renders it in the browser.

I consider this experimental. It’s perfect for quick UI scaffolding when you’re working from a laptop in a cafe and can't run a heavy emulator, but it isn't a replacement for a true Android environment.

Pros: Opens instantly in any browser. No virtualization required.
Cons: It's an abstraction layer; it won't render complex third-party Android-specific views.

The Verdict

For final polish and performance testing, use a Physical Device. For your day-to-day development loop, the Android Emulator is the perfect companion. If you're on the move and need to save battery or resources, the Web Emulator has your back.

JetStart gives you the freedom to build at the speed of thought, regardless of your hardware setup. Give it a spin and let me know which one you prefer!

How to Achieve Instant Android Hot Reload

Elimihele God's favour — Sun, 05 Apr 2026 14:55:02 +0000

Android development is plagued by long feedback loops. If you make a tweak to a padding value, an alignment, or a color, Gradle will make you wait. Sometimes seconds, sometimes minutes. This single bottleneck ruins the developer "flow state."

We wanted a web-like developer experience on physical Android devices. We wanted an instant UI hot reload. Here is how we achieved it in JetStart.

The Architecture of Speed

Standard Android development compiles your whole app, signs an APK, and pushes it via ADB. This is fundamentally slow. JetStart circumvents this process entirely during development.

Here is the step-by-step pipeline we use:

File System Watching: A Chokidar process watches your project directory. As soon as a .kt file changes, we grab it.
Targeted Compilation: We do not run Gradle. We invoke kotlinc directly, passing only the changed file and compiling it into Java classes using the Compose compiler plugin.
Instant Run Hooks: Our OverrideGenerator injects standard $Override companion logic into the class so the Android runtime natively swaps the implementation.
DEX Translation: We pipe those .class files into Google's d8 tool, spitting out a raw .dex payload.
WebSocket Delivery: ADB is too slow, so we rely on WebSockets. The DEX is base64-encoded and blasted to your device over a local Wi-Fi or USB connection on port 8766.
Live Execution: The JetStart client app running on your device intercepts the DEX payload, feeds it to a custom ClassLoader, and forces an instant recomposition of your UI.

Why I Killed My DSL Parser for Raw DEX Compilation

Elimihele God's favour — Sun, 05 Apr 2026 14:38:30 +0000

When I first built JetStart, the goal was simple: make Android UI development fast. I started with a DSL (Domain Specific Language) approach. I parsed Kotlin-like syntax, mapped it to Compose UI elements, and sent a JSON payload to the app to render. It worked, and it was fast—but it wasn't real.

Developers hit a wall the moment they needed to use their own custom state, complex animations, or third-party Compose libraries. The DSL approach was too brittle, too restrictive, and ultimately, a dead end for a serious developer tool.

So, I made a hard pivot.

The Pivot to DEX

Instead of faking it with a DSL, I decided to compile the actual Kotlin code. Here is how the new architecture works:

KotlinCompiler: JetStart uses kotlinc with the Compose compiler plugin to compile your .kt files into Java .class files.
DexGenerator: It passes those .class files through Android's d8 tool to create raw classes.dex bytecode.
WebSocket Push: This base64 DEX payload is streamed to the connected Android device over our custom WebSocket protocol.
Live Injection: A custom ClassLoader on the device loads the new classes instantly. The UI recomposes with the new logic—no full app rebuild, no re-installation.

The Result: Real Compose, Sub-100ms

By dropping the DSL and embracing true Kotlin Compilation + DEX generation, JetStart now supports any valid @Composable function. You aren't writing "JetStart Code" anymore; you're writing pure Android code, but experiencing a Web-like hot reload speed.

It’s instantly injected. It’s real Compose. It’s the Android development experience I’ve always wanted. Have you tried it yet? Let me know what you think on Discord or X!

I Built an AI Tutor That Actually Sees Your Homework — Here's How

Elimihele God's favour — Thu, 12 Mar 2026 23:03:01 +0000

A few weeks ago I was watching my younger cousin struggle through a physics worksheet.
She kept typing questions into ChatGPT, getting a wall of text back, and still looking confused. It hit me!
why can't she just show the problem to an AI and have it talk her through it like a real tutor would?

That question became VisionSolve(SolveTutor), and I built it for the Gemini Live Agent Challenge.

The Idea: What if AI Could See and Speak?

Most AI tutoring tools work through text boxes. You type your question, you get a text response. But that's not how tutoring works in real life. A real tutor looks at your paper, listens to your confusion, and talks you through it step by step. They notice when you're lost and adjust.

So I wanted to build exactly that — an AI tutor that:

Sees your homework through your camera
Listens to your questions through your microphone
Speaks explanations back to you, naturally

No typing required. Just point your phone at a math problem and start talking.

Why Gemini Live API Was Perfect for This

I'd been playing around with different LLM APIs, and when I found the Gemini Live API, it clicked immediately. Most APIs are request-response — you send text, you get text back. Gemini's Live API is completely different. It opens a persistent bidirectional stream where you can send audio and video frames continuously, and the model responds in real-time audio.

The killer feature for me was native audio output. The model doesn't generate text that gets piped through a TTS engine — it produces audio directly. The voice sounds natural, with proper pacing and intonation. When Sol (my tutor agent) explains a math concept, it actually sounds like someone talking to you, not a robot reading a script.

The other thing that sold me was barge-in support. Students interrupt. That's normal. They'll say "wait, what?" in the middle of an explanation. With other APIs you'd have to manage complex state to handle that. With Gemini Live, the student can just... talk. The model handles it gracefully.

The Stack

Here's what I ended up using:

Backend:

Google ADK (Agent Development Kit) — this was huge. Instead of wiring up raw API calls, I defined my agent with a system instruction, gave it tools, and ADK handled the session management. The agent framework made it easy to add Google Search grounding so Sol can verify facts on the fly.
FastAPI + WebSockets — the frontend connects over a WebSocket, and the backend proxies audio/video to Gemini Live and streams audio responses back.
Firebase Firestore — for storing session transcripts so students can review past sessions.

Frontend:

Next.js + TypeScript — nothing fancy here, just a clean mobile responsive interface with a webcam feed, audio visualizer, and chat transcript.
Firebase Auth — Google Sign-In for authentication.

Model: gemini-2.5-flash-native-audio — the latest native audio model. Fast enough for real-time conversation, capable enough to understand handwritten math from a shaky phone camera.

Things That Surprised Me

The vision capabilities are seriously good

I expected the model to struggle with handwritten math, especially messy student handwriting. It doesn't. I tested it with all kinds of problems scribbled algebra, printed calculus, even chemistry diagrams — and it identified them correctly almost every time. It even handles when the camera is slightly angled or the lighting isn't great.
i even tried it with my cousin's messy algebra homework, a printed calculus worksheet, and even a badly drawn chemistry diagram.

Natural interruptions just work

This was the feature I was most nervous about. In my head, I had this complex state machine planned out for handling when a student interrupts. Turns out, I didn't need any of it. The Live API's barge-in support means when the student starts talking, the model stops, listens, and responds. It's seamless.

The hardest part wasn't the AI

Honestly, the AI side was smoother than I expected thanks to ADK and the Live API.
The hardest part wasn't the AI at all.
It was WebSocket audio streaming.
Browsers hate it. Microphone permissions break. Safari behaves weirdly. Classic web dev pain.

Google Cloud Deployment

I deployed the whole thing on Google Cloud:

Backend runs on Cloud Run with Vertex AI integration
Frontend is on Firebase Hosting
CI/CD pipeline through GitHub Actions — push a tag and everything deploys automatically

The deploy workflow builds a Docker image, pushes it to GCR, deploys to Cloud Run, then builds the frontend with the new backend URL injected and deploys it to Firebase. The whole pipeline takes about 4 minutes, which is pretty nice for not having to think about deployments at all.

You can check out the full pipeline here.

What I'd Do Differently

If I had more time, I'd add:

Drawing/annotation support — let Sol highlight parts of the image while explaining
Progress tracking — track which topics the student struggles with over time

Try It Out

The project is open source: github.com/dev-phantom/VisionSolve

The README has full setup instructions if you want to run it locally. You'll need a Gemini API key (free from Google AI Studio) and a Firebase project.

If you're thinking about building something with the Gemini Live API, I'd say go for it. The combination of real-time audio + vision is genuinely different from anything else available right now. It opens up use cases that just weren't possible with traditional request-response APIs.

Built for the #GeminiLiveAgentChallenge using Google Gemini, ADK, Firebase, and Cloud Run.