Osama Raddad

FireCrasher is an Android library that catches uncaught exceptions on the main thread and recovers the app instead of letting it crash. It replaces Android’s main-thread message loop with one that dispatches each message inside a try/catch. When something throws, your onCrash handler gets the exception first, so crash reporting still works, and then the library recovers in steps. The main-loop interception is adapted from SafeLooper (mmin18, 2013); the recovery ladder, back-stack tracking and handler API are FireCrasher’s own. I started it in 2016 and moved most of it to Kotlin in 2019. It was modernized, and made fully Kotlin, in 2026.

How it differs: Crash reporters such as Crashlytics, Sentry and Bugsnag record a crash, but the app still dies. FireCrasher keeps it running: it passes the exception to your reporter first, then recovers.

• Recovery ladder: the first two crashes restart the activity. The third goes back if there is a screen behind it, and relaunches the app from its launcher activity if there isn’t.
• On API 30+, the recovery level and retry count are saved with the process (a 5-byte state summary). If the process dies mid-recovery and the app relaunches within 30 seconds, the next crash picks up the ladder where it left off. (On master.)
• Native crashes and ANRs kill the process before any handler runs. On API 30+, FireCrasher reads the system’s exit record on the next launch and passes it to onPreviousProcessExit { }. context.lastAbnormalExit() and context.historicalExitReasons() query the same records on demand. (On master.)
• The public API is locked down with Kotlin explicit-API mode and a committed binary-compatibility baseline, both checked on every CI build. 34 JUnit and Robolectric tests. (On master.)
• 7 merged pull requests from 5 outside contributors, 2016 to 2022.

Warehouse is a dependency injection library for the JVM, written as a Kotlin DSL. It wires dependencies with nested warehouse { module { factory { } } } blocks and hands them out through property delegation (by mainDI()). A warehouse can include other warehouses, and its accessibility level (OPEN, LOCAL or ISOLATED) decides which bindings pass up to the warehouse that includes it. Each factory can be named, exposed as an interface, and limited to the classes allowed to receive it.

How it differs: Dagger/Hilt and Koin are the established choices for dependency injection on Android. Warehouse is a smaller, DSL-based alternative for the JVM, and its own angle is access control: you decide which classes may receive a binding, and which bindings a warehouse passes up to the one that includes it.

• injectsIn { Demo::class } limits who can receive a binding. Injecting it anywhere else fails with an error that names both classes.
• @Named picks between bindings of the same type, and constructor parameters resolve from the graph with param() or param(name).
• Three creation patterns: NEW, SINGLETON and REUSABLE.
• Tests with JaCoCo coverage, Detekt and Dokka API docs were set up in GitHub Actions in 2022.

Holdfast is a transactional state library for Kotlin Multiplatform. A store holds state, and its unit of consistency is the transaction. Inside action { } mutations are buffered and observers only see committed values. If the block throws, the whole action rolls back and nothing leaks. atomic(a, b) { } stretches that guarantee across stores: they all commit, or none of them do.

Why it exists: In a plain state holder such as MutableStateFlow, every write is published as soon as it is made, so an exception halfway through a multi-step update leaves half-applied state behind. Holdfast publishes once, on commit, and rolls everything back if the block throws.

It grew out of Vault (December 2024), a JVM Kotlin state container on my own GitHub where action { } blocks already rolled back on an exception.

• action { } returns TransactionResult.Success or TransactionResult.Error. A failed transaction rolls back and its observers never fire.
• atomic() and suspendAtomic() run an in-memory two-phase commit across stores, taking locks in one global order so frames can’t deadlock each other.
• The frame is enforced: writing to a store you didn’t enroll throws, so it can’t commit on its own.
• Separate modules for coroutines (Flow and StateFlow adapters, suspendAction), Compose (collectAsState) and tests (storeTest { }).
• CI runs the tests on JVM, Android (host tests) and the iOS simulator. The wasmJs target is experimental.

Install: Not yet published

Hallmark turns a raw String or Long into a type such as Email or Age, built through a validator that checks the value first. Validation accumulates, so you get every violation at once, each with the path to the field that failed. Uncivilized (2022) was my earlier take on the same idea: a small JVM library that wraps raw primitives in typed objects through rules and variations.

• Typed wrappers (Boxed<T>), validators built from rule specs, and an infix of to construct a value.
• A failure in a nested field arrives with its path, for example ["address", "zip"].
• hallmark-coroutines adds suspending validation for checks such as database lookups.

Install: Not yet published (Uncivilized: implementation 'com.github.osama-raddad:Uncivilized:1.0.1' via JitPack)

gentle-palette is an Android library that snaps a color to the nearest color in a palette: give it a color int and an array of #RRGGBB strings and you get back the closest entry. It was made to sit next to Android’s Palette library: take the dominant color of an image and round it to the nearest flat or Material color. The released 0.1.3 uses a callback and plain RGB distance. Master was modernized in 2026 with a direct round() call and redmean-weighted distance, and isn’t released yet.

• Five built-in palettes: flat, Material, social brand colors, Fluent and Metro.
• No runtime dependencies.
• Listed in the Android section of awesome-jordan since 2018.
• Unreleased on master: round() returns the color directly, validates its input, and has 12 JUnit tests.

A proof of concept for a dating app’s UI flow, written once in Compose Multiplatform. It goes from onboarding to phone number entry, a six-digit code screen, profile setup and a tabbed home screen, with sample data and no backend. The same module builds for Android, iOS through a SwiftUI host, desktop JVM, and the browser through Kotlin/Wasm.

Why it exists: It is a demonstration, not a product: one Compose Multiplatform UI flow running on Android, iOS, desktop and the web from a single module, with no backend behind it.

• One :composeApp module: commonMain plus Android, iOS, desktop and wasmJs source sets.
• Navigation is a sealed Screen class driven by state, with no navigation library.
• A Ktor client with per-platform engines (Android, Darwin, OkHttp) and an auth layer that isn’t connected to a backend yet.
• Desktop packaging for DMG, MSI and DEB.
• Kotlin 2.2.0, Compose Multiplatform 1.8.2, Material 3.

Install: Not published (an app).