Coder Legion - Recent posts tagged androiddevelopment

The Night My Pipeline Rejected 43.8% of Everything — and Was Right

Sat, 17 Oct 2026 09:46:03 +0000

Last month, my automated software-ingestion pipeline did something terrifying: it rejected 43.8% of all updates in a single run. Forty-three point eight percent. My first instinct was that the pipeline was broken. It wasn't. It was the only thing in the room doing its job.

I run an open software catalog. Every few days, an automated pipeline pulls new releases from vendors, GitHub, and F-Droid, verifies them, and publishes them. That night it pulled the fire alarm on nearly half the catalog — two SHA-256 hash mismatches (Google Chrome and CCleaner, of all things) and twelve signature mismatches across apps like Obsidian, Tor, and Ventoy.

Here’s what I learned fixing it, distilled into the checklist I now run before any binary goes live.

1. START WITH THE HASH — BUT KNOW WHAT IT CAN’T TELL YOU

Every release I publish carries a SHA-256 checksum, recomputed at download time. It’s the cheapest integrity check in existence:

sha256sum installer.exe
# compare against the publisher's published value

If the hash doesn’t match, stop. Don’t install it, don’t “try it anyway.” A mismatched hash means the file changed in transit — or it isn’t the file the publisher shipped. That night, Chrome and CCleaner’s hashes didn’t match their expected values. The pipeline refused them, and rightly so: a hash mismatch is never a rounding error.

But a hash answers only one question: did this file change? It says nothing about who made it. That’s what signatures are for.

2. VERIFY THE SIGNATURE, NOT JUST THE CHECKSUM

A checksum tells you the file is intact. A signature tells you it came from the right key. For Android packages, the tooling is free:

apksigner verify --print-certs app.apk

The critical step most people skip: check that the certificate fingerprint matches the publisher’s known key. The first time you see a new fingerprint on a familiar app, treat it as suspicious until proven otherwise. For desktop software, GPG serves the same role:

gpg --verify installer.exe.sig installer.exe

The pattern is identical everywhere: fetch the artifact, fetch the signature, verify against the publisher’s public key. And if a project ships binaries with no signatures at all? That’s a data point about the project — not a reason to skip verification.

3. ENROLLMENT IS THE HALF OF VERIFICATION EVERYONE FORGETS

Here’s the mistake that cost me a week. My pipeline verified every APK signature correctly — and still rejected twelve apps. The parser wasn’t broken. The cryptography was fine. The problem: I had never enrolled those signers in the first place.

Signature verification has two halves, and I was only doing one:

1. Is this signature cryptographically valid? (the tool answers this)
2. Do I recognize this signer? (only my allowlist answers this)

Twelve apps were signed by keys my system had simply never recorded — new maintainers, rotated keys, corporate renames. My favorite: a publisher whose legal name changed by a single dot (“Dynalist Inc.” vs “Dynalist Inc”), which my strict string match treated as a stranger. The pipeline was doing its job; my trust store was incomplete.

The fix is boring and essential. Keep an explicit registry of known-good signers per package, keyed by certificate fingerprint:

# trust_store.json — enrolled signers, one entry per package
{
  "com.example.app": {
    "fingerprints": ["AB:CD:EF:12:34..."],
    "enrolled_on": "2026-10-13",
    "note": "Key rotation announced in v4.2 changelog"
  }
}

When a new fingerprint appears, that’s an event, not an error — investigate it once, enroll it deliberately, and move on. Auto-trusting unknown signers defeats the entire purpose.

4. REJECT LOUDLY — WITH A THRESHOLD YOU CHOSE IN ADVANCE

A verification system that silently accepts everything is decoration. Mine fails the entire ingestion run closed if more than 15% of updates get rejected. That number is deliberate: a sudden spike means either the upstream world changed (keys rotated, publishers restructured) or my pipeline broke. Either way, I want a human looking at it before anything ships.

The exact threshold matters less than the principle: decide in advance what “too many failures” looks like, and make the pipeline stop instead of shrugging. Quiet failures are how bad binaries reach users. My 43.8% night looked like a disaster and was actually the system working exactly as designed — it just needed a human to enroll the new signers and re-run.

5. DECIDE IN ADVANCE WHAT TO DO WITH THE UNVERIFIABLE

Not everything is signable. Some legitimate tools ship unsigned binaries — portable builds, indie utilities, projects too small for signing infrastructure. You have three honest options: reject them, allowlist them explicitly, or verify them another way (reproducible builds, publisher-published hashes fetched over HTTPS).

I allowlist them — explicitly, per binary, with a written reason. What I never do is let an unsigned binary through on a technicality. “The check didn’t apply” is not the same as “the check passed,” and conflating the two is how exceptions quietly become the rule. Ventoy’s unsigned binary, for example, sits in my allowlist with a note explaining why — visible, reviewable, deliberate.

THE CHECKLIST

Before any binary goes live:

SHA-256 matches the publisher’s published value (recomputed at download, not trusted from a mirror)
Signature verifies against the publisher’s known key
Signer fingerprint is in the enrolled registry — new fingerprints get investigated, never auto-trusted
Rejection rate for the run is under threshold, or the whole run stops
Unsigned artifacts are explicitly allowlisted with a written reason — never silently passed

None of this is exotic. It’s plumbing. But it’s the plumbing between a stranger’s server and your users’ machines, and every piece of it earns its place the first time it catches something. Mine caught something on a random Tuesday night, rejected nearly half the catalog, and was right.

Android CI/CD for Beginners — Part 1: Introduction

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Common triggers include:

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

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

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

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

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

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

Step
A step is a single task inside a job.

Examples of steps include:

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

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

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

For example:

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

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

In Android projects, common artifacts include:

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

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

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

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

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

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

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

👋Bye!!!

Google Play’s 2027 app quality requirements

Mon, 14 Sep 2026 15:41:55 +0000

Google Play is introducing new requirements for memory usage, code optimization, and automatic login restoration when users change Android devices. Announced on August 26, 2026, the changes take effect in February and April 2027.

Memory requirements from February 2027

Play will assess dynamic memory usage, measured as anonymous RSS plus swap, and memory held by bitmaps. The thresholds vary by process state, with separate dynamic memory limits for apps and games across device RAM tiers. The Android vitals tables list the applicable limits.

For phones and tablets, Play uses P90 measurements and the last 28 days of data. Evaluation includes available data from Android 13 onward. These requirements therefore reach beyond apps running on Android 17. Measurement scope.

Android 17 also introduces limits enforced by the operating system. Excessive memory use can trigger additional compression work and eventually process termination. Teams should examine memory use across foreground, background, and cached states.

DEX optimization from February 2027

Qualifying uploads must meet a minimum of 25% coverage in each of three areas: optimization, shrinking, and obfuscation. The requirement applies to apps with more than 10 MB of DEX code and games with more than 50 MB. These are DEX code thresholds, not total download sizes. DEX requirements.

Google recommends R8, although another optimizer can meet the requirement. Review optimization settings and keep rules, then inspect the percentages reported for the actual bundle uploaded to Play Console.

Apps offering optional or mandatory login must support automatic restoration of the user’s authenticated state when they transfer to another Android device. Google calls this Zero-Tap Sign-In. Games are currently exempt. Migration requirement.

The requirement covers phones and tablets. Apps without accounts are unaffected, and guests should remain guests. Block Store integrations qualify only if they successfully restore login and are in production by September 30, 2026. Other exceptions and exemption criteria are detailed in the technical requirements.

The recommended implementation uses Restore Credentials through Credential Manager. It includes creating a restore key for an authenticated user, handling restoration with the app’s backend, and deleting the key on logout. Plan for both app and backend changes.

Checks to schedule now

Inspect Android vitals memory metrics by device RAM tier and process state, including behavior after leaving the app.
Review the uploaded release bundle’s DEX size and optimization results. Test critical flows after changing R8 rules.
Audit the device migration flow with the authentication team and test both device transfer and cloud restoration.

Google says apps that miss the requirements may face reduced store visibility and publishing capabilities. Further enforcement details are still to come. Check the official announcement and technical requirements when planning releases.

Getting Started with Native Android: Kotlin & Jetpack Compose

Tue, 08 Sep 2026 04:14:28 +0000

Hey devs! For anyone looking to get into native mobile development, I put together a starter guide on building Android apps using Kotlin and Jetpack Compose.

Key takeaways:

Transitioning from traditional imperative UI to modern declarative composables

Managing UI state with remember and mutableStateOf

Quick design cycles using live previews in Android Studio

Read the full post on SunnyWriteUps! Are you currently using Jetpack Compose, KMP, or cross-platform frameworks for your mobile builds?

https://sunnyblog.apexmansunny.workers.dev/posts/get-started-with-kotlin/

Eunify: Bridging the Continuity Gap Between Mac and Android

Fri, 22 May 2026 17:24:01 +0000

If you’ve ever lived deep within the Apple ecosystem, you know the magic of Continuity. The ability to copy a link on your iPhone and instantly paste it on your Mac, or use your phone’s camera as a wireless webcam, feels like living in the future. Apple built these features seamlessly into their OS, giving their users a cohesive multi-device experience.

But what if you love your Mac, but prefer an Android phone? Out of the box, you get nothing. The wall around Apple's garden is tall, and cross-platform continuity has historically been clunky, relying on a patchwork of third-party apps that drain battery and feel decidedly un-magical.

Eunify (https://github.com/FredrickOdondi/eunify) changes that.

What is Eunify?
Eunify is an open-source "Continuity Bridge" designed specifically for users who split their digital lives between macOS and Android. It consists of a native macOS host app (built with Swift and SwiftUI) and an Android client (built with Flutter), tied together by a clever cloud relay system.

The goal? To give Android users the exact same seamless, real-time continuity features that were previously exclusive to the Apple ecosystem.

Bringing Apple Magic to Android
Eunify doesn't just mimic one or two features; it aims to replicate the entire Continuity suite:

Universal Clipboard: Copy text or a block of code on your Mac, and it instantly lands in your Android clipboard.
Tab & URL Push: Drag a Chrome or Safari tab onto the Eunify Mac app, and it opens instantly on your phone. You can also send links in reverse, from your Android back to your Mac browser.
Notification Mirroring: See your Android push notifications appear on your Mac in real-time, complete with actionable quick replies.
File Transfer: Drag any file onto the Mac app to send it directly to your Android device via high-speed P2P WebRTC.
Continuity Camera: Stream your Android phone's camera feed directly to your Mac to use as a wireless webcam.
Biometric Mac Unlock: Tap your fingerprint on your Android phone to unlock your Mac remotely.
Media Sync: See what's playing on your Android and control it right from your Mac desktop.
How It Works Under the Hood
Achieving this level of synergy across fundamentally different operating systems requires a robust technical foundation.

The Handshake: It starts with a simple QR code. The macOS app generates a QR code encoding a unique room ID. Scanning this with the Android app connects both devices to the same Supabase Realtime (WebSocket) channel.
Signaling: Standard events—like URL pushes, clipboard syncs, and notification mirroring—are securely transmitted as structured JSON payloads over the Supabase cloud relay.
Peer-to-Peer Streaming: For heavy lifting (binary data like files and live camera frames), the WebSocket channel is used to negotiate a direct WebRTC DataChannel. This ensures fast, secure, peer-to-peer data streaming without routing massive payloads through a cloud server.
Conquering Android Background Restrictions
One of the biggest hurdles for an app like this is keeping the connection alive while the mobile app is in the background. Modern Android is notoriously aggressive about killing background processes to save battery.

Eunify solves this with a two-layer approach:

A Foreground Service keeps the Supabase WebSocket connection alive with a WakeLock.
A separate Background Isolate written in Dart re-initializes the connection independently, handling message delivery even if the main UI is completely killed by the OS.
(It even employs clever workarounds, like using FlutterForegroundTask to briefly trampoline the app to the foreground on Android 10+ just to bypass background clipboard-writing restrictions.)

Get Started
If you're tired of emailing yourself links and want to bring your Android device into your Mac's ecosystem, Eunify is open source and ready to try.

Check out the code, read the full protocol design, and download the latest releases directly from the GitHub repository:

Explore Eunify on GitHub: https://github.com/FredrickOdondi/eunify

https://apkpure.com/eunify/com.eunify.client

Built with Swift, SwiftUI, Flutter, Dart, and Supabase.

Refined Your Flutter Recipe App using Gemini AI

Mon, 16 Mar 2026 03:43:11 +0000

Hola..Back to article writing and I want to tell a story about my journey as Boarding House Citizen. Living in a boarding house alone, sometimes leaving leftover food can feel kind of unreal in a good way. Back at home, leftovers usually came with rules, reminders, or a bit of guilt, especially after big celebrations like Eid Al-Fitr or Christmas.

Here, it’s not like that at all. The fridge is shared, containers are labeled, and everyone knows that food can be shared if it’s meant to be. When I cook too much or can’t finish my meal, I just pack it up instead of forcing myself to eat more. Someone else might enjoy it later after a long day at work or a late night of studying. It just makes sense.

Food leftovers should not be wasted, even though many people feel unsure what to cook with them. Leftover rice, vegetables, or bread can be turned into simple meals like fried rice, soup, or toast. Checking the fridge before cooking helps reduce waste. Using leftovers saves money, cut daily meal cost, and is good for the environment.

Now imagine you could build a real-life app that calculates and combines all your leftover food into one new recipe and shows the budget cost like you’ll never think of? Now we’ll make it using flutter.

Note: due to character limitation, see full article on my Medium

Android build types, product flavors, and variants from zero to production

Sun, 01 Mar 2026 12:23:28 +0000

How do you build different versions of the same app from one codebase?

You use build types, product flavors, and variants!

Let's explain the concept and dive into some examples.

What is a build type

A build type defines how the app is built.

The most common build types are:

debug
release

Debug is what you use during development. It usually:

Is debuggable
Has logging enabled
Is signed with a debug key
May include tools like LeakCanary

Release is what you ship to users. It usually:

Is not debuggable
Has code shrinking enabled
Is signed with your real keystore
Has logging disabled

So build types describe technical behavior.

What is a product flavor

A product flavor defines what app you are building.

Examples:

demo vs prod, different backend servers
free vs paid, different features
white label apps for different clients
staging vs production

Flavors describe business or product differences.

You can think of flavors as different personalities of your app.

What is a variant

A variant is the combination of:

One build type
One flavor from each flavor dimension

For example:

demoDebug
demoRelease
prodDebug
prodRelease

Each of those is a fully buildable and installable app.

When you click Run in Android Studio, you are running a specific variant.

Step 1: Basic Android app setup

Open your app module file:

app/build.gradle.kts

Inside the android block, you typically have something like:

android {
    namespace = "com.example.variants"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.example.variants"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"
    }
}

This defines your base app configuration.

Step 2: Understanding build types in practice

Add build types inside the android block:

android {

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = ".debug"
            isDebuggable = true

            buildConfigField("Boolean", "LOGGING_ENABLED", "true")
        }

        release {
            isMinifyEnabled = true
            isShrinkResources = true

            buildConfigField("Boolean", "LOGGING_ENABLED", "false")

            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

What this does:

Debug builds have a different application id, so you can install them next to release.
Debug builds expose a constant called LOGGING_ENABLED.
Release builds enable code shrinking.

Use the generated constant in code:

object LoggerConfig {
    val loggingEnabled = BuildConfig.LOGGING_ENABLED
}

Now your app behaves differently depending on build type.

Step 3: Creating your first flavor

Now we introduce flavors.

We will create two environments:

demo
prod

First, define a flavor dimension:

android {

    flavorDimensions += "environment"

    productFlavors {
        create("demo") {
            dimension = "environment"
            applicationIdSuffix = ".demo"
            versionNameSuffix = ".demo"

            buildConfigField(
                "String",
                "API_BASE_URL",
                "\"https://api.demo.example.com\""
            )
        }

        create("prod") {
            dimension = "environment"

            buildConfigField(
                "String",
                "API_BASE_URL",
                "\"https://api.example.com\""
            )
        }
    }
}

Now you have:

demoDebug
demoRelease
prodDebug
prodRelease

Each one has a different API base URL.

Use it in your networking layer:

object ApiConfig {
    val baseUrl: String = BuildConfig.API_BASE_URL
}

No if statements required.

Step 4: Source sets and environment specific code

Android supports separate folders per flavor.

Structure example:

app/src/main
app/src/demo
app/src/prod
app/src/debug
app/src/release

Suppose you want a developer menu only in demo.

Create:

app/src/demo/java/com/example/variants/FeatureFlags.kt

object FeatureFlags {
    const val showDeveloperMenu = true
}

And in:

app/src/prod/java/com/example/variants/FeatureFlags.kt

object FeatureFlags {
    const val showDeveloperMenu = false
}

The correct file is compiled automatically depending on variant.

This is cleaner than runtime checks.

Step 5: Multiple flavor dimensions

Now let's introduce branding.

Suppose you want:

One codebase
Two clients: acme and globex

Add a second dimension:

android {

    flavorDimensions += listOf("environment", "brand")

    productFlavors {

        create("demo") { dimension = "environment" }
        create("prod") { dimension = "environment" }

        create("acme") {
            dimension = "brand"
            applicationIdSuffix = ".acme"
            resValue("string", "brand_name", "Acme")
        }

        create("globex") {
            dimension = "brand"
            applicationIdSuffix = ".globex"
            resValue("string", "brand_name", "Globex")
        }
    }
}

Now total variants:

2 environments times 2 brands times 2 build types equals 8 variants.

This is how large production apps handle white labeling.

Step 6: Variant specific dependencies

You can attach dependencies to specific variants.

dependencies {

    implementation("androidx.core:core-ktx:1.13.1")

    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14")

    demoImplementation("com.jakewharton.timber:timber:5.0.1")
}

LeakCanary only in debug.
Timber only in demo builds.

This keeps production builds clean.

I built an open-source IRC client for Android – AndroidIRCX

Thu, 29 Jan 2026 13:38:36 +0000

Hey everyone
I’ve been working on an open-source IRC client for Android called AndroidIRCX, and I wanted to share it with the community.
The goal was to create a modern, lightweight, and privacy-focused IRC app, while preserving the classic IRC experience. The app is actively maintained and continues to evolve based on user feedback.
Key features:
Real-time notifications
Optional app lock (PIN / biometrics)
Supports irc:// and ircs:// deep links
Multiple servers and channels
Reliable auto-reconnect logic
ZNC (bouncer) ready
IRCv3 protocol support
End-to-end encryption (E2EE)
Clean, simple UI with no unnecessary tracking
The entire project is fully open source, and contributions, issues, and pull requests are very welcome.
GitHub:
https://github.com/AndroidIRCx/AndroidIRCx
Google Play:
https://play.google.com/store/apps/details?id=com.androidircx
Website:
https://androidircx.com
This started mostly as a passion project and as a way to keep IRC usable and relevant on modern Android devices.
I’d love to hear your feedback, suggestions, or criticism
Thanks for reading!

From JavaScript to Kotlin

Tue, 27 Jan 2026 04:12:59 +0000

A practical guide for Web developers moving to Android

Switching from web development to mobile development can feel intimidating at first. If you come from a JavaScript background(like me)and start learning Android with Kotlin the syntax may look familiar in places yet surprisingly strict in others.

This guide is written specifically for JavaScript and web developers who are transitioning to Android development using Kotlin. The goal is to make that transition smoother by comparing concepts side by side clarifying common confusions, and explaining why Kotlin feels different but often safer and more predictable.

Why Kotlin Feels Different Coming from JavaScript

JavaScript is flexible, dynamic, and forgiving. Kotlin is designed to be safe, explicit, and structured. This difference is intentional. When web developers struggle with Kotlin, it is usually not because Kotlin is hard, but because it enforces rules that JavaScript does not.

Key mindset shift:

JavaScript optimizes for speed of writing

Kotlin optimizes for correctness and maintainability

Initial Confusion Points

Strict typing
Null safety rules
Immutability by default
More boilerplate at first glance

These feel restrictive if you come from JavaScript, but they exist to protect you.

What gets easier over time

Code becomes more predictable
Refactoring feels safer
Fewer runtime crashes
Better IDE assistance

Most developers report that after a few weeks, Kotlin feels clearer than JavaScript for large applications.

Pros of Kotlin for JavaScript Developers

Strong null safety
Clear data flow and state management
Excellent tooling in Android Studio
Modern language features
Cleaner long term maintenance

Kotlin shines in applications that grow over time especially team based projects.

Cons and Tradeoffs

Slower initial learning curve
More rules to remember
Less flexibility compared to JavaScript
Compilation errors can feel overwhelming at first

These are short term costs for long term stability.

Will Kotlin reduce or increase confusion?

Short answer: Initially it may increase confusion. Long term it significantly reduces it.

Why?

Kotlin removes ambiguity
Errors are visible early
Code intent is clearer

For mobile apps where crashes impact users directly, this tradeoff is worth it.

Core Language Comparison

Variables and Mutability

JavaScript

let name = "Alex"
const age = 30

Kotlin

var name = "Alex"
val age = 30

Clarification

val is immutable and should be your default choice
var is mutable and should be used intentionally

Why this helps
Kotlin makes state changes explicit, which reduces bugs in large codebases and UI state management.

Type System

JavaScript

let count = 5
count = "five" // valid

Kotlin

var count = 5
// count = "five" // compilation error

Clarification
Kotlin is statically typed most type errors are caught at compile time instead of runtime.

Benefit for mobile apps
Crashes are caught earlier
Refactoring is safer
Large teams move faster with confidence

Functions
JavaScript

function add(a, b) {
  return a + b
}

Kotlin

fun add(a: Int, b: Int): Int {
    return a + b
}

Clarification
Types are required in Kotlin
Function signatures become self documenting
This reduces ambiguity when reading unfamiliar code.

Null safety
One of Kotlin’s biggest advantages

JavaScript

let user = null
console.log(user.name) // runtime error

Kotlin

var user: User? = null
println(user?.name)

Clarification

? means the value can be null
?. safely accesses properties
Why this matters
Null pointer exceptions are one of the most common crash causes in mobile apps. Kotlin forces you to think about nullability explicitly.

Conditionals as expressions

JavaScript

let result
if (x > 10) {
  result = "Big"
} else {
  result = "Small"
}

Kotlin

val result = if (x > 10) "Big" else "Small"

Clarification
In Kotlin, if returns a value this leads to cleaner and more predictable code.

Loops and Collections

JavaScript

for (let i = 0; i < list.length; i++) {
  console.log(list[i])
}

Kotlin

for (item in list) {
    println(item)
}

Or more functional style

list.forEach { println(it) }

Clarification
Kotlin encourages readable collection APIs and less index based logic means fewer errors.

Final Thoughts

If you are coming from web development, learning Kotlin is not about abandoning what you know. It is about adapting your mindset.

Think less about writing code quickly

Think more about writing code safely

Once that shift happens Kotlin becomes not just understandable, but enjoyable.

To read the new article visit my personal blog and join my @devlogsbyazizkhuja telegram channel!

From XML Screens to Scalable Systems — My 6-Year Mobile Dev Journey (Still Loading…)

Mon, 29 Dec 2025 12:13:47 +0000

Introduction

Six years ago, I opened Android Studio with zero clarity and max curiosity. No roadmap. No mentor. Just vibes, bugs, and the stubborn belief that I could build things people would actually use. Fast-forward to today: I’ve shipped apps, survived startup chaos, lived through COVID-era uncertainty, and evolved into a full-stack mobile app developer who’s still learning every single day.

This is my journey — raw, messy, and very real.

The Tech Stack That Shaped Me

I didn’t “pick” a stack. The stack picked me.

Android (Java + XML) – where discipline came from
Kotlin – where clean code finally made sense
Flutter – where cross-platform speed changed the game
Firebase – real-time apps, auth, push, analytics, the whole deal
Supabase – modern backend energy, SQL but developer-friendly
SQLite – offline-first thinking, data control
Custom Servers & APIs – because sometimes you need full control

Over time, I stopped chasing tools and started solving problems. Big mindset shift.

Pain, Gain — The Real Learning Curve

Let’s be honest: tutorials don’t prepare you for production.

I’ve:
Shipped features that broke in real users’ hands
Over-engineered apps that never saw the light of day
Underestimated timelines (classic dev mistake)
Burned out, restarted, and rebuilt — multiple times

Running my own startup was the hardest and most educational phase. You don’t just code — you handle product decisions, user complaints, scaling issues, server costs, and the pressure of “this has to work.”

That pain? It compounds into experience. The gain is insane.

COVID Era: Survival Mode → Skill Upgrade

COVID flipped everything. Projects paused. Plans broke. Motivation dipped.

So I doubled down on skills:
Refined architecture patterns
Improved UI/UX thinking (not just “it works”)
Learned to ship faster with fewer resources
Adapted to remote-first workflows

That phase rewired how I work. Less noise. More impact.

What I Bring to the Table Now

End-to-end mobile app development
Scalable backend integration
Performance-focused UI/UX
Startup mindset (not just feature delivery)
Clear communication + ownership

I care about why a feature exists, not just how to build it.

Open for Freelance & Collaborations

I’m currently available for freelance, remote work, and long-term collaborations —
Worldwide & across India

If you’re:
A startup building v1
A founder needing a reliable dev
A team looking for someone who actually owns outcomes

Let’s build something solid.

✨ Final Thought

This journey isn’t a highlight reel. It’s six years of up and down, shipping and failing, learning and unlearning. And honestly? I’m just getting started.

If you’re building — keep going.
If you’re stuck — you’re not alone.
If you want to collaborate — my inbox is open.

Let’s cook.

Music App Bug: Songs Broke on Switching — Here’s Why

Sun, 03 Aug 2025 22:32:31 +0000

I was facing this annoying issue in Flutter music player:

When you tap songs quickly (like switching from one to another), playback breaks, mini player disappears, and you have to tap again to play. It was 2-3 times out of every 10 switch.

It took me a while to trace it. I tried:

Making our playback function async
Adding delays
Debugging tap triggers

But nothing worked.

Then I found the real culprit:

await _player.stop(); //  this innocent-looking line was breaking everything

The Wrong Code

In the background audio handler's updateQueue() method:

Future<void> updateQueue(List<MediaItem> newQueue) async {
  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  await _player.setAudioSource(_playlist, initialIndex: 0);
  await _player.stop(); // ❌ this line breaks playback!

  queue.add(newQueue);
}

What’s the Problem?

This creates a race condition:

setAudioSource() loads and prepares the new song(s).
Immediately after, stop() wipes the loaded source.
So by the time the player is supposed to play, there's nothing left
to play.

This bug especially shows up during rapid song switching, because set -> stop -> play happens too fast and gets out of sync.

The Right Code

Future<void> updateQueue(List<MediaItem> newQueue) async {
  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  _playlist.clear();
  _playlist.addAll(newAudioSources);

  await _player.setAudioSource(_playlist, initialIndex: 0);

  if (_player.playing) {
    await _player.play();
  }

  queue.add(newQueue);
}

If you're using just_audio and audio_service, never call stop() right after setAudioSource().
You're basically loading a song and immediately throwing it away.

Let the player handle resets internally unless you truly need to stop everything.

Happy building!

Query Smarter, Not Harder

Sat, 26 Jul 2025 19:58:21 +0000

If you're building a music app with on_audio_query, it’s tempting to call querySongs() everywhere—home screen, playlists, search, etc. But this means repeated storage scans → slower UI, battery drain, and unnecessary complexity.

The Wrong Way – Querying Every Time

final OnAudioQuery audioQuery = OnAudioQuery();

Future<List<SongModel>> getSongs() async {
  return await audioQuery.querySongs(); // Called in every screen
}

In each screen:

final songs = await getSongs(); // Repeats scan again

Fetch once in a service (e.g., MusicPlaybackService):

class MusicPlaybackService extends ChangeNotifier {
  List<SongModel> _allSongs = [];

  Future<void> loadSongs() async {
    final OnAudioQuery query = OnAudioQuery();
    _allSongs = await query.querySongs();
    notifyListeners();
  }

  List<SongModel> get allSongs => _allSongs;
}

Provide it globally:

runApp(
  ChangeNotifierProvider(
    create: (_) {
      final service = MusicPlaybackService();
      service.loadSongs(); // Fetch once
      return service;
    },
    child: MyApp(),
  ),
);

Reuse anywhere without re-querying:

final allSongs = context.watch().allSongs;

Benefits

No repeated disk access.
Faster UI transitions (playlist, search, player use the same list).
Centralized state → easier maintenance.

Coder Legion - Recent posts tagged androiddevelopment

The Night My Pipeline Rejected 43.8% of Everything — and Was Right

1. START WITH THE HASH — BUT KNOW WHAT IT CAN’T TELL YOU

2. VERIFY THE SIGNATURE, NOT JUST THE CHECKSUM

3. ENROLLMENT IS THE HALF OF VERIFICATION EVERYONE FORGETS

4. REJECT LOUDLY — WITH A THRESHOLD YOU CHOSE IN ADVANCE

5. DECIDE IN ADVANCE WHAT TO DO WITH THE UNVERIFIABLE

THE CHECKLIST

Android CI/CD for Beginners — Part 1: Introduction

Google Play’s 2027 app quality requirements

Memory requirements from February 2027

DEX optimization from February 2027

Login restoration from April 2027

Checks to schedule now

Getting Started with Native Android: Kotlin & Jetpack Compose

Eunify: Bridging the Continuity Gap Between Mac and Android

Refined Your Flutter Recipe App using Gemini AI

Android build types, product flavors, and variants from zero to production

What is a build type

What is a product flavor

What is a variant

Step 1: Basic Android app setup

Step 2: Understanding build types in practice

Step 3: Creating your first flavor

Step 4: Source sets and environment specific code

Step 5: Multiple flavor dimensions

Step 6: Variant specific dependencies

I built an open-source IRC client for Android – AndroidIRCX

From JavaScript to Kotlin

A practical guide for Web developers moving to Android

From XML Screens to Scalable Systems — My 6-Year Mobile Dev Journey (Still Loading…)

Music App Bug: Songs Broke on Switching — Here’s Why

The Wrong Code

What’s the Problem?

The Right Code

Query Smarter, Not Harder

The Wrong Way – Querying Every Time

The Better Way – Query Once, Share via Provider