DEV Community: Andrea Sunny

Building an Offline-First Android App with Jetpack Compose (2026 Guide)

Andrea Sunny — Fri, 15 May 2026 06:24:35 +0000

Modern Android apps are expected to work even when the internet doesn’t.

Users open apps inside elevators, during flights, in low-network regions, or while switching between Wi-Fi and mobile data. If your app crashes or becomes unusable offline, users leave quickly.

That’s why offline-first Android architecture is becoming the default approach in 2026.

In this guide, you’ll learn how to build an offline-capable Android app using Jetpack Compose, Room, WorkManager, and Retrofit - along with the latest stable dependency versions developers are searching for right now.

👉 Original detailed guide:

https://www.appxiom.com/blogs/build-offline-android-app-jetpack-compose/

Why Offline-First Apps Matter

Offline-first apps provide:

Faster UI responsiveness
Better user retention
Reliable performance in poor networks
Seamless background synchronization
Reduced server dependency

Apps like WhatsApp, Notion, Spotify, and Google Keep all rely heavily on offline-capable architecture.

Tech Stack for Offline Android Apps

Here’s the modern stack most Android developers use today:

Technology	Purpose
Jetpack Compose	Modern UI toolkit
Room Database	Local offline storage
WorkManager	Background sync
Retrofit	API networking
Kotlin Coroutines	Async programming
Flow / StateFlow	Reactive streams

Latest Android Dependency Versions (2026)

Many developers search for dependency versions directly in Google Search Console, which explains queries like:

androidx.room:room-runtime:2.6.1
androidx.work:work-runtime-ktx:2.9.0
androidx.activity:activity-compose latest version 2026

Here are the commonly used stable versions.

Room Database

implementation("androidx.room:room-runtime:2.6.1")
implementation("androidx.room:room-ktx:2.6.1")
ksp("androidx.room:room-compiler:2.6.1")

You may also see older searches like:

implementation("androidx.room:room-runtime:2.5.2")

But 2.6.1 is the preferred version for most new projects.

WorkManager

implementation("androidx.work:work-runtime-ktx:2.9.0")

This is currently one of the most searched WorkManager dependencies because developers want:

Reliable background syncing
Offline queue processing
Retry mechanisms
Battery-efficient background tasks

Activity Compose

implementation("androidx.activity:activity-compose:1.9.0")

If you searched for:

androidx.activity activity-compose latest version 2026

this is the dependency you likely need.

Step 1 - Create Your Room Entity

Room acts as your local source of truth.

@Entity(tableName = "notes")
data class NoteEntity(
    @PrimaryKey(autoGenerate = true)
    val id: Int = 0,
    val title: String,
    val content: String,
    val synced: Boolean = false
)

Step 2 - DAO Layer

@Dao
interface NoteDao {

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(note: NoteEntity)

    @Query("SELECT * FROM notes")
    fun getAllNotes(): Flow<List<NoteEntity>>
}

Using Flow ensures the UI updates automatically whenever local data changes.

Step 3 - Configure Room Database

@Database(
    entities = [NoteEntity::class],
    version = 1
)
abstract class AppDatabase : RoomDatabase() {

    abstract fun noteDao(): NoteDao
}

Initialize it like this:

val db = Room.databaseBuilder(
    context,
    AppDatabase::class.java,
    "offline_db"
).build()

Step 4 - Retrofit Networking

Retrofit remains the standard for Android APIs.

implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")

A lot of developers also search for:

square retrofit 2.6.0 suspend support release notes
retrofit latest version 2026 2.9.0

Suspend support is now fully standard in Retrofit.

Example API service:

interface NoteApi {

    @POST("notes")
    suspend fun uploadNote(
        @Body note: NoteEntity
    )
}

Step 5 - WorkManager for Background Sync

This is where offline-first architecture becomes powerful.

Whenever the internet returns, WorkManager syncs unsynced local data automatically.

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {

        return try {
            // Upload local notes
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Schedule it like this:

val request = OneTimeWorkRequestBuilder<SyncWorker>()
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

Step 6 - Jetpack Compose UI

Compose makes reactive offline UIs much easier to implement.

@Composable
fun NotesScreen(viewModel: NotesViewModel) {

    val notes by viewModel.notes.collectAsState()

    LazyColumn {
        items(notes) { note ->
            Text(text = note.title)
        }
    }
}

Because Room exposes Flow, the UI updates instantly whenever local data changes.

Offline-First Architecture Flow

The recommended architecture is:

UI → Local Database → Background Sync → Remote Server

Instead of:

UI → API → Database

This ensures your app remains functional even without connectivity.

Common Mistakes Developers Make

1. Treating APIs as the Source of Truth

Your local database should always be the primary source.

2. Syncing Too Frequently

Aggressive background sync drains battery and impacts performance.

Use WorkManager intelligently.

3. Ignoring Conflict Resolution

Offline edits can conflict with server data.

Use:

timestamps
versioning
merge strategies

What Does “Offline Capable” Mean?

One interesting search query from Search Console was:

offline capable

An offline-capable app means:

Users can view data without internet
Users can create/update data offline
Synchronization happens automatically later
App functionality degrades gracefully

This is now expected behavior for production apps.

Recommended Android Architecture in 2026

The best modern Android architecture stack includes:

MVVM
Repository pattern
Room as source of truth
Retrofit for APIs
WorkManager for sync
Compose for UI
Coroutines + Flow

This setup improves maintainability, scalability, and user experience.

Why This Architecture Scales Well

Offline-first apps scale better because:

APIs can fail temporarily without breaking UX
Users continue interacting with the app
Cached content improves speed
Sync operations happen in the background
Mobile battery usage becomes more optimized

This architecture is especially useful for:

Note-taking apps
E-commerce apps
Chat applications
Healthcare systems
Logistics platforms
Field-service apps

Advanced Improvements You Can Add

Once the basics are working, you can improve the architecture further with:

Paging 3

Efficiently load large offline datasets.

DataStore

Store preferences and lightweight app settings.

Hilt Dependency Injection

Improve modularity and testing.

Network Monitoring

Automatically trigger synchronization when connectivity returns.

Encryption

Protect local Room database data for security-sensitive apps.

Final Thoughts

Offline-first Android development is no longer optional.

If your app depends completely on network availability, users will eventually experience frustration.

By combining:

androidx.room:room-runtime:2.6.1
androidx.work:work-runtime-ktx:2.9.0
Retrofit
Jetpack Compose

you can build apps that feel fast, modern, and reliable.

For the complete implementation walkthrough, check the original article:

👉 https://www.appxiom.com/blogs/build-offline-android-app-jetpack-compose/

Sqflite Flutter: A Simple Way to Add Local Database Support in Flutter Apps

Andrea Sunny — Thu, 14 May 2026 06:03:05 +0000

When building production-ready Flutter apps, one thing becomes obvious very quickly - you eventually need local storage.

Whether it’s:

offline access,
caching API responses,
storing user preferences,
or maintaining app state,

having a reliable local database solution matters.

That’s where sqflite Flutter integration becomes extremely useful.

If you’ve searched for sqflite tutorials recently, you probably noticed that many examples only cover basic CRUD operations without explaining real-world usage patterns. So in this post, I want to share why sqflite is still one of the best choices for Flutter local storage and where beginners can learn it properly.

What is Sqflite?

Sqflite is a Flutter plugin for SQLite.

It allows Flutter developers to store structured data locally using SQL queries inside mobile applications.

With sqflite, you can:

Create local databases
Insert/update/delete data
Perform SQL queries
Store relational data efficiently
Build offline-first apps

Since SQLite is lightweight and optimized for mobile devices, sqflite has become one of the most popular local database solutions in the Flutter ecosystem.

Why Developers Use Sqflite Flutter Solutions

Here are a few reasons why sqflite is widely used in Flutter projects.

1. Offline Support

Your app can continue functioning without internet access.

This is especially important for:

productivity apps,
note-taking apps,
expense trackers,
learning platforms,
and field-service applications.

2. Better Performance

Reading data locally is much faster than making repeated API calls.

Many apps use sqflite for:

caching,
session persistence,
and reducing unnecessary network requests.

3. Structured Data Storage

Unlike simple key-value storage systems, sqflite supports relational tables and SQL queries.

That means you can build:

searchable datasets,
filtered records,
connected entities,
and scalable local architectures.

Common Sqflite Flutter Use Cases

App Type	Usage
Todo Apps	Task persistence
Finance Apps	Offline transaction storage
E-commerce Apps	Cart & wishlist caching
Chat Apps	Local message history
Learning Apps	Saved progress & lessons

Things Beginners Usually Struggle With

When starting with sqflite Flutter development, beginners often face challenges like:

Database initialization
Async query handling
Managing database versions
Writing reusable helper classes
Structuring CRUD methods cleanly

That’s why following a proper implementation guide is important instead of just copying snippets from random tutorials.

Sqflite vs Other Flutter Storage Packages

Flutter developers often compare sqflite with:

Hive
Drift
SharedPreferences
ObjectBox

Each has its strengths, but sqflite still works really well when:

you need relational data,
SQL queries matter,
or you want full control over your database structure.

Final Thoughts

Even with newer storage libraries available, sqflite remains one of the most practical solutions for local database management in Flutter.

If you’re building apps that require:

offline functionality,
structured local storage,
or scalable persistence,

then learning sqflite flutter development is definitely worth your time.

And if you want a clean beginner tutorial, the Appxiom guide linked above is a solid place to start.

The Hidden Problem in Most Flutter Location Implementations

Andrea Sunny — Tue, 17 Mar 2026 11:00:19 +0000

Let’s talk about something most Flutter developers implement…
but rarely optimize properly.

👉 Location services.

At first, it feels simple:

Get location
Show it on UI
Done

But once your app hits real users, things change.

The Problem Most Developers Don’t Notice

Location features don’t fail loudly.

They don’t crash your app.
They don’t throw obvious errors.

Instead, they:

Drain battery silently
Reduce app performance
Deliver inconsistent location accuracy
Run unnecessary background updates

And users don’t say:

“Your GPS polling strategy is inefficient”

They say:

“Your app kills my battery.”

Why Location Services Are Harder Than They Look

Modern location-based apps rely on:

GPS
Network signals
Background services
Permission handling
Real-time updates

And each of these comes with trade-offs:

Accuracy vs battery usage
Frequency vs performance
Real-time updates vs system load

Even small inefficiencies can compound quickly.

For example:

Continuous tracking can drain power rapidly
Poor filtering can create noisy location data
Frequent updates can overload UI rendering

What Most Implementations Get Wrong

From what I’ve seen (and probably you too), common mistakes include:

Fetching location too frequently
Not handling permissions properly
Ignoring background optimization
Treating all location updates equally
Not filtering noisy GPS data

The result?

👉 An app that “works” - but performs poorly in the real world.

A Better Way to Think About Location in Flutter

Instead of thinking:

“How do I get the location?”

Start thinking:

“How do I get location efficiently and responsibly?”

That means:

Choosing the right package (geolocator, etc.)
Handling permissions gracefully
Reducing unnecessary updates
Optimizing for battery
Structuring location logic cleanly

Where Things Get Interesting

There’s a really solid breakdown I came across that goes deeper into this - not just how to implement location services, but how to optimize them properly in real apps.

It covers things like:

Efficient location fetching strategies
Handling permissions correctly
Reducing unnecessary updates
Structuring location logic for performance

👉 If you want to go beyond basic implementation, this is worth reading:
Best Practices for Using Location Services in Flutter

Final Thought

Location services aren’t just a feature.
They’re a system inside your app.

And like any system:

It needs optimization
It needs balance
It needs intention

Because in the end, users don’t care how you implemented it.

They care about:

Battery
Accuracy
Smooth experience

And that’s where good engineering shows up.

Read the Full Guide

If you're building anything involving maps, tracking, or real-time location, don’t stop here.

👉 Read the full detailed guide here:
Best Practices for Using Location Services in Flutter

How Do You Extend Jetpack Compose Components Without Making Them Messy?

Andrea Sunny — Wed, 04 Mar 2026 05:16:17 +0000

When building Android apps with Jetpack Compose, you quickly notice something: UI components evolve constantly. A simple button suddenly needs loading states, analytics tracking, accessibility hints, or animations.

The easy solution? Modify the component directly.

The better solution? Use a design pattern that lets you extend behavior without rewriting the original component.

One pattern that fits this idea perfectly is the Decorator Pattern.

I recently came across a great walkthrough explaining how this pattern works in Compose, and it’s worth exploring if you care about building reusable UI components.

(Full guide here: How to Implement the Decorator Pattern in Jetpack Compose)

Let’s break down the idea and why it’s useful for modern Android development.

What the Decorator Pattern Actually Means

The Decorator Pattern is a classic design pattern that allows you to add behavior to an object dynamically without changing its original code.

Instead of modifying the base component, you wrap it with another object (a decorator) that enhances its behavior.

Think of it like layering features.
Example:

Base Button
  ↓
Loading Decorator
  ↓
Analytics Decorator
  ↓
Accessibility Decorator

Each layer adds something without touching the original implementation.

This approach keeps components:

reusable
maintainable
easier to test

Why This Pattern Works So Well in Compose

Compose is built around composition and small reusable UI pieces.

That means patterns that rely on wrapping and layering behavior naturally fit its architecture.
In fact, you already use this idea daily through modifiers:

Modifier
   .padding(16.dp)
   .background(Color.Blue)
   .clickable { }

Each modifier is essentially decorating the UI element with additional behavior.

The Decorator Pattern simply applies the same idea at a component architecture level.

A Simple Implementation Walkthrough

The Appxiom guide walks through the pattern using a simple example: enhancing a button.
Here’s the general idea.

1. Create the Base Component

Start with a minimal composable that does only one thing.

@Composable
fun BaseButton(text: String, onClick: () -> Unit) {
   Button(onClick = onClick) {
       Text(text)
   }
}

This component is intentionally simple.
No logging.
No loading state.
No analytics.

Just a button.

2. Create Decorators

Decorators wrap the base component and add new behavior.

For example, a loading decorator might look like this:

@Composable
fun LoadingDecorator(content: @Composable () -> Unit) {
   CircularProgressIndicator()
   content()
}

Instead of modifying the button directly, the decorator simply wraps it and enhances it.

3. Apply Decorators

Now we can layer behavior on top of the base component.

LoadingDecorator {
   BaseButton("Submit") {
       println("Clicked")
   }
}

Need analytics?
Add another decorator.

Need animation?
Wrap it again.

Each feature stays isolated and reusable.

4. Use the Decorated Button

Once wrapped, the final component behaves like a richer version of the original.

This keeps your UI architecture flexible because you can combine decorators depending on the screen’s needs.

Why This Pattern Matters in Real Apps

As apps grow, UI components often accumulate responsibilities.

Without patterns like this, you end up with components that look like:

SuperMegaButton(
   loading = true,
   analytics = true,
   tracking = true,
   animate = true,
   accessibility = true
)

Eventually, the component becomes hard to maintain.

The decorator approach keeps responsibilities separate.

Benefits include:

easier testing
reusable behavior
cleaner composables
better separation of concerns

The Real Value of Patterns in Compose

Patterns like this aren’t just academic ideas.

They solve practical problems that appear in real Android projects:

feature layering
UI reuse
scalable component design

Compose encourages thinking in small building blocks, and the decorator pattern fits naturally into that mindset.

If You Want the Full Walkthrough

This article only scratches the surface.

The original guide includes a step-by-step implementation with working examples and explains how to structure decorators properly.
👉 Read the full guide here:
How to Implement the Decorator Pattern in Jetpack Compose

If you’re building reusable UI systems with Jetpack Compose, it’s definitely worth a read.

Final Thought

Jetpack Compose gives developers powerful tools for building UI quickly.

But writing scalable UI still depends on good architectural decisions.

Patterns like the Decorator Pattern help keep your components small, reusable, and adaptable as your app grows.

And sometimes, the simplest patterns make the biggest difference.

Being a Fresher Developer Is Harder Than It Looks

Andrea Sunny — Fri, 27 Feb 2026 12:05:11 +0000

From the outside, being a fresher developer looks exciting.

New job.
New tech.
First commits.
First paycheck.

But from the inside, it often feels very different.

It feels overwhelming.
It feels confusing.
And sometimes, it feels lonely.

This isn’t a complaint about the industry or senior developers.
It’s just the reality many freshers quietly live through.

The Gap No One Warns You About

As a fresher, you don’t struggle because you can’t code.

You struggle because knowing syntax is not the same as knowing systems.

Suddenly, you’re dealing with:

Large codebases you didn’t write
Business logic that evolved over years
Decisions made before you joined
Bugs with history and context you don’t have

Senior developers see patterns.
Freshers see noise.

And that gap can feel brutal.

When “Just Ask” Isn’t That Simple

People often say:

“If you’re stuck, just ask.”

But for a fresher, asking isn’t always easy.

You hesitate because:

You don’t want to sound incompetent
You’re afraid the question is “too basic.”
You already asked something similar yesterday
Everyone else seems busy

So you spend hours trying to solve something that could’ve taken five minutes with context.

That’s exhausting - mentally and emotionally.

The Invisible Pressure to Prove Yourself

Freshers don’t just write code.
They constantly evaluate themselves.

Every review comment feels personal.
Every bug feels like failure.
Every silence feels like judgment.

You compare yourself to seniors who:

Debug faster
Speak confidently
Understand the system intuitively

What you don’t see is:

Their years of mistakes
Their early confusion
Their burnout phases
Their learning curve

You only see the polished version.

Burnout Starts Quietly for Freshers

Burnout for freshers doesn’t start with anger.
It starts with overcompensation.

You:

Stay late to “catch up.”
Re-read documentation endlessly
Overthink small tasks
Feel guilty for not being productive enough
Tie your self-worth to output

And because you’re “new,” you feel like you’re not allowed to be tired yet.

That’s how burnout sneaks in.

Why Seniors Often Don’t Feel This the Same Way

This isn’t about blaming senior developers.

Seniors struggle too - just differently.

But they have:

Context
Confidence
Pattern recognition
The ability to say “this will take time” without guilt

Freshers don’t have that yet.

So the same pressure hits harder, lasts longer, and feels more personal.

What Actually Helps (From a Fresher’s POV)

Here’s what genuinely makes a difference — not motivational quotes:

Being told “It’s okay not to know.”
Seniors explaining why, not just what
Time to read and understand code without urgency
Reviews that teach instead of judge
Normalizing confusion instead of hiding it

Small things. Huge impact.

To Freshers Reading This

If you’re struggling, you’re not weak.
You’re learning.

Confusion is not failure.
It’s part of the job.

You are not behind.
You are early.

And one day, someone else will look at you and think,

“How do they understand this so easily?”

They won’t see your early days either.

To Seniors Reading This

You don’t need to lower the bar.
Just lower the fear.

A little patience.
A little context.
A little empathy.

You might be the reason someone stays in tech - or quietly burns out.

Final Thought

Being a fresher developer is hard in a way that’s rarely visible.

Not because the work is impossible
But because the learning is constant, public, and emotional.

And acknowledging that doesn’t make anyone weaker.

It makes teams stronger.

The Human Side of Writing Code (That We Rarely Talk About)

Andrea Sunny — Tue, 24 Feb 2026 09:17:36 +0000

Code looks clean on the screen.
People assume it’s logical, structured, unemotional.

But anyone who has written software for more than a few months knows the truth:

Code carries feelings.

Frustration. Relief. Anxiety. Pride. Doubt.
They don’t show up in the syntax - but they shape every line.

Every Developer Knows This Feeling

You stare at a bug for hours.
The logic should work.
The tests pass.
Yet something feels wrong.

That feeling isn’t technical.
It’s intuition built from experience, failure, and repetition.

We don’t talk about it much, but good developers trust that feeling - then validate it with logic.

A Quiet Moment Every Developer Knows

I remember staring at a screen long after everyone else had logged off.
The bug wasn’t loud. No crash. No error. Just a feeling that something was off.

The code looked fine. Tests were green. Still, I didn’t trust it.

I reread the same function for the tenth time, not because I didn’t understand it - but because I was hoping it would confess. It didn’t.

Eventually, I stepped away. Came back later. Read it again.

There it was.
A tiny assumption I had made hours earlier - one line that worked, but not always.

Fixing it didn’t feel like victory.
It felt like relief.
That moment taught me something no tutorial ever did:

writing code isn’t just logic - it’s patience, doubt, and learning to listen when something feels wrong.

Writing Code Is Quietly Emotional

There’s the tension before a release.
The panic when production breaks.
The relief when a fix finally works.

Even joy - the quiet kind - when a refactor suddenly makes everything clearer.

No one applauds those moments.
But they’re real.

Most of software development is emotional work wrapped in technical tasks.

Debugging Is a Conversation With Yourself

Debugging isn’t just “finding the bug”.
It’s:

Questioning your assumptions
Admitting you were wrong
Relearning how the system actually behaves That’s uncomfortable.

The best debuggers aren’t the smartest - they’re the most honest with themselves.
They don’t argue with reality.
They listen.

Code Reviews Are Human Moments

A code review isn’t just feedback on code.
It’s:

Vulnerability (“Here’s my work”)
Trust (“I believe you’ll make it better”)
Ego (sometimes bruised, sometimes reinforced) Good teams understand this.

They review code with empathy, not superiority.
They critique logic - not people.

That’s how psychological safety is built.

Burnout Doesn’t Come From Code - It Comes From Pressure

Most developers don’t burn out because coding is hard.

They burn out because:

Everything feels urgent
Mistakes feel personal
There’s no room to slow down
Failure feels public Code becomes the outlet for stress, even though it’s not the cause.

Sustainable development is less about productivity hacks - and more about humane expectations.

Why We Keep Doing This Anyway

Despite everything, we keep coding.

Because there’s something deeply satisfying about:

Turning confusion into clarity
Building something from nothing
Solving problems that didn’t have answers yesterday

That quiet moment when things finally work?
That’s the reward.

Not the commit.
Not the deploy.
That moment.

Code Is a Record of Thought

Every codebase is a snapshot of how humans thought at a moment in time.

Messy code often means rushed decisions.
Clean code often means someone cared.

You can read stress, urgency, and growth in a repository if you know how to look.

That’s why refactoring feels therapeutic.
It’s rewriting past decisions with present understanding.

Final Thought
Software development isn’t just about machines understanding us.
It’s about us understanding ourselves through machines.
The logic matters.
The performance matters.
But so do the people behind the code.

And acknowledging that doesn’t make us weaker developers.

It makes us better ones.

How to Confidently Test Jetpack Compose UI with Espresso

Andrea Sunny — Fri, 20 Feb 2026 08:24:54 +0000

If you’ve worked with Jetpack Compose long enough, you’ve probably thought:

“UI looks great — but how do I test it reliably?”

Compose makes building UI fun, but testing it is underrated. Without solid tests, your beautiful UI can break in subtle ways that users notice long before you do.

That’s where Espresso + Compose testing comes in - and this article helps you actually understand how to use them in real code, not just copy/paste snippets.

Inspired by: How to Test Jetpack Compose UIs Using Espresso

Why UI Testing Matters (and What Usually Fails)

Let’s be honest:

Manual testing feels okay until it doesn’t.

You may catch obvious crashes, but:

Layout glitches slip through
Recomposition bugs go unnoticed
Edge cases eat your time
Something that worked yesterday suddenly breaks

Especially with Compose’s dynamic UI and state system, UI tests catch problems early.

Automated testing:

Reduces manual QA effort
Gives confidence for refactors
Acts as living documentation
Helps prevent regressions

So yes - testing isn’t optional. It’s part of quality.

Espresso Meets Jetpack Compose - The Basics

Espresso was historically the go-to UI test tool for Android Views.

Compose introduced its own test APIs (composeTestRule), but Espresso still plays nicely when testing parts of your UI that compose with classic Views or interoperability components.

Before you write a test, set up your test rule:

@get:Rule
val composeTestRule = createAndroidComposeRule<MainActivity>()

This gives you an entry point to:

Set content
Interact with semantics
Assert UI state

Plug this into your instrumented test file (usually under androidTest/).

Finding UI Elements

In Compose, elements are identified not by IDs, but by semantics - roles, content descriptions, and custom test tags.

For example:

composeTestRule.onNodeWithText("Login").performClick()

This finds a node displaying text and clicks it. Simple.

But often you’ll want a custom tag:

Modifier.testTag("login_button")

Then find it:

composeTestRule.onNodeWithTag("login_button").assertIsDisplayed()

This works great because:

Tags aren’t visible to users
They’re test-only handles
They keep your test logic independent of design changes

Interacting with UI

Testing isn’t just about looking - it’s about doing.

Compose test APIs let you:

performClick()
performTextInput("hello")
performScrollTo()

For example:

composeTestRule.onNodeWithTag("email_field")
    .performTextInput("dev@example.com")

This simulates the user typing into the field - a real interaction, not just a state change.

Asserting UI Behavior

Assertions tell you what should have happened.

Useful assertions include:

assertIsDisplayed()
assertTextEquals("Welcome")
assertIsEnabled()

For example:

composeTestRule.onNodeWithTag("submit_button")
    .assertIsEnabled()

This makes sure your UI isn’t only visible, it’s interactive as expected.

Dealing With Asynchronous UI

UI often updates asynchronously - for example, after network calls or state updates.

Compose test rules let you wait for the UI to settle:

composeTestRule.waitForIdle()

This makes sure no pending changes are in flight before you assert.

Sometimes you need to wait for a condition:

composeTestRule.waitUntil(timeoutMillis = 5_000) {
    composeTestRule.onAllNodesWithTag("item").fetchSemanticsNodes().isNotEmpty()
}

This waits up to 5 seconds for something to appear - handy with asynchronous data.

Espresso + Compose - Real Interop

If your screen mixes Compose and classic Views (e.g., a RecyclerView or WebView), combine Espresso and Compose APIs:

onView(withId(R.id.recycler_view))
    .perform(RecyclerViewActions.scrollToPosition<MyViewHolder>(10))

And then back to Compose:

composeTestRule.onNodeWithTag("footer").assertExists()

The ability to mix both tools makes tests flexible on mixed projects.

A Real Example Workflow

Let’s say you want to test a login screen:

Launch the UI
Type valid credentials
Click the login button
Check for the welcome message

In code:

@Test
fun login_success_displaysWelcome() {
    composeTestRule.onNodeWithTag("email_field")
        .performTextInput("test@example.com")

    composeTestRule.onNodeWithTag("password_field")
        .performTextInput("password123")

    composeTestRule.onNodeWithTag("login_button")
        .performClick()

    composeTestRule.onNodeWithText("Welcome Back!")
        .assertIsDisplayed()
}

Clean. Readable. And directly connected to user intent.

Why This Is Better Than Manual QA

Manual testing is:

Slow
Hard to reproduce
Missing coverage
Inconsistent

Automated Compose tests give:

Repeatable results
Confidence during refactor
Fast feedback
Integration with CI/CD

You’ll end up shipping safer, faster, and with fewer late-night bug hunts.

Final Tips for Daily Practice

Here are a few practical reminders:

Use testTag() liberally - it makes targets predictable.
Prefer semantics over text lookups - UI text changes often.
Group related actions in helper functions - reduce boilerplate.
Run tests on multiple devices/emulators - behavior isn’t always consistent.
Automate tests in CI/CD - make it part of your pipeline, not an afterthought.

Wrapping Up

Jetpack Compose makes UI elegant - and with the right tests, reliable too.

By combining:

Compose testing APIs
Espresso for interop
Clear semantics
Smart assertions

…you can confidently validate your UI behavior and avoid regressions.

Compose is powerful. Testing makes it trustworthy.

7 Practical Ways to Sharpen Your Software Development Skills (What usually goes wrong, and how to fix it)

Andrea Sunny — Wed, 18 Feb 2026 05:12:13 +0000

Let’s be honest.

Most developers don’t stop improving because they’re lazy.
They stop because they’re busy, overwhelmed, or practicing the wrong things.

We read articles, bookmark courses, star GitHub repos - and still feel stuck.

Before talking about how to sharpen your skills, it’s worth addressing the real problem.

What Usually Goes Wrong (And Why Growth Feels Slow)

Here’s a pattern many developers fall into:

You learn a framework quickly
You get productive
You ship features
You repeat the same patterns for months (or years)

You’re working hard, but not stretching.

Most skill stagnation happens because:

You optimize for delivery, not learning
You avoid uncomfortable problems
You rely too much on tools instead of understanding fundamentals
You confuse experience with improvement

This isn’t a motivation issue.
It’s a practice issue.

Let’s make this concrete.

A Short Case Study: The “Busy but Stuck” Developer

A mid-level developer (let’s call them Jacob) worked on a production system for 3 years.
Jacob:

Shipped features consistently
Knew the codebase well
Was reliable and fast

But during interviews, Jacob struggled with:

System design questions
Debugging unfamiliar code
Explaining trade-offs
Writing clean solutions outside their daily stack

Why?
Because Jacob had been solving the same category of problems repeatedly.

The job rewarded output - not growth.

Once Jacob changed how they practiced (not how much), things improved rapidly.

That’s what the rest of this article focuses on.

1. Strengthen Fundamentals Before Chasing New Tools

Frameworks change. Fundamentals don’t.

If you feel stuck, it’s often because you’re building on shaky ground:

Data structures
Algorithms
Memory basics
Networking fundamentals
How the runtime actually works

You don’t need to become theoretical - but you do need clarity.

Actionable tip:
Pick one weak fundamental per month and go deep.
Not videos - code and explain it to yourself.
If you can’t explain it simply, you don’t understand it yet.

2. Read Code More Than You Write It

Most developers underestimate this.

Reading good code teaches:

Naming
Structure
Error handling
Design decisions
Trade-offs

Reading bad code teaches even more.

Actionable tip:
Each week, read:

One well-maintained open-source file
One messy legacy file (your own or others)

Ask:

Why was this written this way?
What would I change - and why?

3. Practice Debugging, Not Just Coding

Real-world skill shows up when things break.

If your workflow avoids debugging, you’re missing a core skill.

Strong developers:

Reproduce issues systematically
Narrow scope quickly
Validate assumptions
Read logs like a story

Actionable tip:
When a bug appears, resist fixing it immediately.
First, write down what you think is happening.
Then confirm or disprove it.

This builds reasoning, not reflex.

4. Build Small Projects With Constraints

Side projects fail when they’re too big.
The goal isn’t to ship a startup - it’s to practice decision-making.
Constraints force learning:

Limited memory
No third-party libraries
Time-bound features
Performance limits

Actionable tip:

Build something small with one hard rule, like:
“No framework”
“Only standard library”
“Must load under 100ms”

Constraints expose gaps fast.

5. Learn to Explain Your Code Clearly

If you can’t explain your solution, it’s probably fragile.

Explaining forces:

Clear thinking
Simpler design
Better naming
Awareness of edge cases

This is why senior developers sound calm - they’ve rehearsed clarity.

Actionable tip:
After finishing a task, explain it out loud (or in writing) as if teaching a junior dev.

If you ramble, refactor the code.

6. Stop Copy-Pasting Blindly

Copy-paste is useful - but dangerous when unchecked.

If you paste without understanding:

You import bugs
You miss trade-offs
You stall long-term growth

Actionable tip:
For every copied snippet:

Rewrite it from memory
Change one part intentionally
Explain why it works

This turns copying into learning.

7. Get Feedback From Code, Not Opinions

Generic feedback like “looks good” doesn’t sharpen skills.

What helps:

Failing tests
Performance regressions
Real users
Production incidents
Code reviews with specifics

Actionable tip:
Treat feedback as data, not judgment.
Ask:

What failed?
Under what conditions?
Why didn’t I anticipate it?

Growth comes from friction.

Final Thought

Sharpening software development skills isn’t about:

More tutorials
More tools
More hustle

It’s about deliberate discomfort.
The best developers aren’t the busiest - they’re the most intentional about how they practice.
If you fix how you learn, progress follows naturally.

Concurrency vs Parallelism in Swift - A Simple Guide Every iOS Developer Should Read

Andrea Sunny — Wed, 04 Feb 2026 12:36:51 +0000

If you’ve ever had your app freeze mid-scroll or wondered why that long download blocks the UI, you’ve already met Swift’s two superheroes (or troublemakers, depending on how you use them):
Concurrency and Parallelism.

At first glance, they sound like fancy synonyms. In reality? They’re different - and knowing _how_they differ makes your code smoother and your users happier.

In this article, we’ll explore these concepts in a way that finally clicks- without drowning in theory.
(Original blog inspo: Appxiom’s Concurrency and Parallelism in Swift)

Concurrency - Doing Many Things at Once

Think of concurrency like your brain when it tries to juggle multiple tabs in your head:

Respond to UI gestures
Fetch network data
Parse JSON
Update database

The app isn’t doing all those things at the exact same moment.
Instead, it’s switching between tasks intelligently so that nothing feels blocked.

In Swift, when we talk about concurrency, we’re talking about:

Structured concurrency (async/await)
Tasks and task groups
Dispatch queues

Concurrency lets your app handle multiple flows of work without freezing the main thread.

Real-World Analogy

You’re cooking a meal and talking on the phone. You’re not cooking two meals simultaneously, but you switch between tasks fast enough that dinner gets done and your friend doesn’t notice you’re busy.

Parallelism - Doing Truly Simultaneous Work

Parallelism is when work actually happens at the same time - not just in quick succession.
This usually requires:

Multiple CPU cores
Tasks that can run independently
Work that doesn’t need shared state

In Swift, this often looks like:

Dispatching tasks to concurrent queues
Using Task groups to run independent work in parallel

Real-World Analogy

You and a friend are cooking two dishes at the same time. Each of you has your own stove and tools. Both dishes actually cook simultaneously.

Swift Example (High-Level)

Let’s say you want to download two images.
Concurrent (interleaved):

async let image1 = download(url1)
async let image2 = download(url2)

let results = await (image1, image2)

Swift will interleave tasks so neither blocks the main thread.

Parallel (actually simultaneous under the hood):
When those async let tasks land on separate cores, the system can run them in parallel. The result? Faster aggregate execution.

Whether concurrency becomes parallelism depends on:

Workload
CPU availability
System scheduling

But the key is: you write concurrency, and the system can enable parallelism automatically.

Why You Should Care (Beyond Definitions)

At first, these might feel like academic words. But here’s why they matter:

Your UI Will Stay Responsive

If you run long tasks on the main thread, the UI stutters **or **freezes. Deployment success doesn’t matter if users can’t scroll.

You Can Process Work Efficiently

When tasks are independent (like multiple downloads), concurrency can “divide and conquer,” and the system may make it parallel.

You Avoid Race Conditions

Swift’s concurrency model helps you avoid data races with protection like actors and task isolation.

When to Use What

Use concurrency when you have multiple tasks that should not block each other or the UI (network calls, storage access, parsing).
Use parallelism when tasks are large, independent, and can actually run simultaneously (like data crunching).

In Swift, you write concurrent code, and the runtime decides whether it runs in parallel.

Quick Insights from Real App Development

Here are a few practical rules of thumb:

Don’t ever do long work on the main thread - that’s a freeze.
Prefer async/await over callbacks - it’s easier to reason about.
Use task groups when you have multiple independent jobs.
If work doesn’t require shared state, they’re good candidates for parallelism.
Rely on Swift concurrency’s scheduler - it knows cores better than you do.

TL;DR

Term	What It Means	Example
Concurrency	Multiple tasks appearing to run at the same time	UI + Network calls interleaved
Parallelism	Tasks actually run at the same time on different cores	Multiple downloads on multiple cores

Concurrency is about coordination.
Parallelism is about simultaneous execution.
Swift’s modern concurrency features make both approachable without pain - as long as you understand the difference.

Bonus Tip

If performance matters (and it always does), start thinking about:

Is your task blocking?
Can work be isolated?
Can Swift’s concurrency model help avoid shared state?

Once you do, a lot of headaches disappear.

Reference

Original blog: Concurrency and Parallelism in Swift

Simplify GIF Handling in iOS with SwiftyGIF

Andrea Sunny — Fri, 23 Jan 2026 05:08:10 +0000

Animated GIFs are everywhere - loading indicators, onboarding screens, empty states, reactions. They’re a simple way to make an app feel more alive. But when it comes to handling GIFs in iOS, things can quickly get… annoying.

If you’ve tried displaying GIFs using native APIs, you’ve probably run into issues like:

complex frame handling,
unnecessary memory usage,
limited control over playback,
and messy code that’s hard to maintain.

This is where a dedicated solution makes a big difference.

Why Native GIF Handling Falls Short

UIImage and UIImageView work great for static images, but animated GIFs are a different story. To get them working properly, you often end up:

manually managing image frames,
loading everything into memory at once,
and writing extra logic just to control animation behavior.

For apps that display GIFs frequently, this approach doesn’t scale well and can impact performance.

A Simpler Approach: SwiftyGIF

SwiftyGIF is a lightweight library built specifically to simplify GIF handling in iOS apps. Instead of dealing with low-level image processing, it provides a clean abstraction for loading and playing GIFs smoothly.

Some key advantages:

Efficient frame loading and memory management
Smooth animation playback
Easy control over looping and animation state
Cleaner, more readable code

For developers who want animated content without unnecessary complexity, this approach is far more practical.

When Does This Matter?

Using a library like SwiftyGIF makes sense when:

your app relies on animated feedback or micro-interactions,
GIFs are part of your UI or branding,
or performance and memory usage matter on long-running screens.

Even small improvements in animation handling can significantly enhance the user experience.

Learn More

If you’re interested in a step-by-step walkthrough of how SwiftyGIF works and how to integrate it into an iOS project, the original article covers this in detail:

Source: How SwiftyGif Simplifies GIF Handling in iOS Apps
The guide goes into practical examples and usage patterns that are helpful for real-world iOS apps.

What Most Swift Developers Miss About Data Structures

Andrea Sunny — Mon, 12 Jan 2026 12:14:14 +0000

When working with Swift, it’s easy to focus on features like optionals, protocols, or SwiftUI. But regardless of what you’re building, data structures sit at the core of every application.
Choosing the right data structure can affect:

performance,
memory usage,
readability,

and how easily your code scales over time.
This post highlights some key ideas around data structures in Swift and points to a detailed guide that explores them in depth.

Why Data Structures Matter in Swift

Swift’s standard library provides several powerful, highly optimized data structures such as:

Array
Dictionary
Set

While these are commonly used, it’s not always obvious when one should be preferred over another. For example:

When is an array better than a set?
Why are dictionary lookups generally fast?
How do value semantics affect performance?

Understanding these trade-offs helps you write more predictable and efficient Swift code.

A Practical Perspective

The referenced blog takes a practical, real-world approach to data structures in Swift. Instead of focusing only on theory, it discusses:

how each structure behaves internally,
common use cases in application development,
and performance considerations that show up in everyday coding.

This makes it especially useful for developers building iOS or macOS apps, or anyone revisiting Swift fundamentals.

Who Will Find This Useful?

You’ll likely benefit if you are:

learning Swift and want to strengthen your foundations,
working on iOS or macOS applications,
optimizing existing code,
or preparing for interviews where data structure knowledge matters.

Strong fundamentals in data structures often lead to cleaner logic and better architectural decisions.
For a deeper and more structured explanation of data structures in Swift, you can check out the full blog here: Data Structures in Swift.

If you have tips, performance insights, or alternative approaches when using Swift data structures, feel free to share them in the comments - always great to learn from the community.

Top APM Tools to Watch in 2026 - What Every Developer Should Know

Andrea Sunny — Wed, 07 Jan 2026 12:25:11 +0000

If you’ve ever shipped a feature only to hear users complain about “laggy,” “crashy,” or “weird behavior,” you know this truth:

Performance issues don’t always crash - they leak.

They leak user trust, revenue, and developer productivity.

That’s why Application Performance Monitoring (APM) tools are more than dashboards - they’re sanity insurance for modern apps, especially as systems become distributed, mobile-first, and AI-powered.

Here’s a curated list of the best APM tools for 2026, why they matter, and when to use them - from mobile to enterprise stacks:

1. Sentry Exception-Centric Monitoring With Context

Sentry has become a favorite for many developers because it combines error capture with rich context - meaning it doesn’t just show you an error, it shows you the breadcrumbs that led to it.

Why it’s worth attention:

Captures stack traces with environment data
Shows events with user context and history
Supports web, mobile (iOS/Android), and backend
Integrations with Slack, GitHub, Jira, etc.

Best for:
Teams that want clear, actionable error insights without drowning in metrics.

When to pick it:
If your app crashes silently or you want to track unexplained bugs in production.
Website: Sentry

2. Bugsee - Mobile First, Video + Network + Crash Recording

Bugsee is one of the more mobile-centric APM tools. Instead of just capturing logs, it records video replays of user sessions along with performance data - screen touches, network calls, console logs, and crashes - in one place.

Why it’s cool:

Session replay + performance metrics
Auto-captures network calls
Visual insight into bugs
Great for UX-heavy mobile experiences

Best for:
Mobile teams that want to see the bug like a user saw it.

When to pick it:
If reproducing bugs is consistently painful and you need visual context.
Website: Bugsee

3. Appxiom - APM With Business Impact + Mobile Focus

Appxiom stands out by linking performance issues directly to user and business impact. It’s not just about did it crash? it answers - did it affect conversions? Did it hurt retention?

Why it’s trending:

Version Analytics (track releases & regressions) and Quality score
30+ bug types mapped to business goals
Goal Friction Impact (measures the impact of each goals in real numbers - the goal failures and reasons)
Flutter, iOS, Android support
Alerts with Slack/Jira integration

Best for:
Mobile teams who want impact-aware monitoring - not just error counts.

When to pick it:
If your performance metrics need business context (goal completion, revenue, churn).
Website: Appxiom

4. Datadog - Enterprise-Grade Full-Stack Observability

Datadog is more than APM - it’s full-stack observability across infrastructure, logs, traces, and metrics. In 2026, it continues to dominate at scale.

Why it’s a top pick:

Distributed tracing across microservices
Real-time dashboards
AI-driven anomaly detection
Logs + metrics + traces in one pane

Best for:
Large organizations with hybrid cloud architectures.

When to pick it:
When your performance story spans services, containers, and cloud infra.
Website: Datadog

5. New Relic - Simplified, Usage-Based Observability

New Relic has reinvented itself with transparent pricing and a unified observability platform. It’s easy to adopt and powerful in depth.

Key strengths:

Unified logs, traces, and metrics
Real User Monitoring (RUM) built-in
Alerts and workflows for teams
Flexible pricing

Best for:
Teams that want one observability platform with a decent learning curve.

When to pick it:
If you want strong performance insights without tool sprawl.
Website: New Relic

6. Bugsnag - Stability Focused With Intelligent Alerts

Bugsnag has a strong focus on application stability. Its error reports include detailed metadata that helps teams diagnose issues fast.

Standout features:

Stability score per release
Automatic grouping of similar errors
Breadcrumb trails before failure
Multi-platform support

Best for:
Apps where stability is a key KPI - especially customer-facing products.

When to pick it:
If you want to track regressions and see trend stability over time.
Website: Bugsnag

Quick Comparison (At a Glance)

Tool	Best Strength	Ideal For
Sentry	Deep error context	Developers fixing logic bugs
Bugsee	Session replay for mobile	UX-heavy mobile apps
Appxiom	Business-impact performance insights	Developers + QA Engineers + Product Managers
Datadog	Full-stack observability	Enterprise/cloud-native stacks
New Relic	Unified observability, easy onboarding	Simpler, broad insight needs
Bugsnag	Stability tracking	Release regression monitoring

Wrapping Up

APM tools are no longer just “nice to have.”
They’re essential for:

Faster debugging
Better release confidence
Lower support cost
Higher user trust

Whether you’re running a microservice backend or a mobile app with millions of users, the APM landscape in 2026 has something for you. Pick tools that match your team size, tech stack, and performance goals - and let them do the heavy lifting.

DEV Community: Andrea Sunny

Building an Offline-First Android App with Jetpack Compose (2026 Guide)

Why Offline-First Apps Matter

Tech Stack for Offline Android Apps

Latest Android Dependency Versions (2026)

Room Database

WorkManager

Activity Compose

Step 1 - Create Your Room Entity

Step 2 - DAO Layer

Step 3 - Configure Room Database

Step 4 - Retrofit Networking

Step 5 - WorkManager for Background Sync

Step 6 - Jetpack Compose UI

Offline-First Architecture Flow

Common Mistakes Developers Make

1. Treating APIs as the Source of Truth

2. Syncing Too Frequently

3. Ignoring Conflict Resolution

What Does “Offline Capable” Mean?

Recommended Android Architecture in 2026

Why This Architecture Scales Well

Advanced Improvements You Can Add

Paging 3

DataStore

Hilt Dependency Injection

Network Monitoring

Encryption

Final Thoughts

Sqflite Flutter: A Simple Way to Add Local Database Support in Flutter Apps

What is Sqflite?

Why Developers Use Sqflite Flutter Solutions

1. Offline Support

2. Better Performance

3. Structured Data Storage

Common Sqflite Flutter Use Cases

Things Beginners Usually Struggle With

Recommended Sqflite Flutter Tutorial

Sqflite vs Other Flutter Storage Packages

Final Thoughts

The Hidden Problem in Most Flutter Location Implementations

The Problem Most Developers Don’t Notice

Why Location Services Are Harder Than They Look

What Most Implementations Get Wrong

A Better Way to Think About Location in Flutter

Where Things Get Interesting

Final Thought

Read the Full Guide

How Do You Extend Jetpack Compose Components Without Making Them Messy?

What the Decorator Pattern Actually Means

Why This Pattern Works So Well in Compose

A Simple Implementation Walkthrough

1. Create the Base Component

2. Create Decorators

3. Apply Decorators

4. Use the Decorated Button

Why This Pattern Matters in Real Apps

The Real Value of Patterns in Compose

If You Want the Full Walkthrough

Final Thought

Being a Fresher Developer Is Harder Than It Looks

The Gap No One Warns You About

When “Just Ask” Isn’t That Simple

The Invisible Pressure to Prove Yourself

Burnout Starts Quietly for Freshers

Why Seniors Often Don’t Feel This the Same Way

What Actually Helps (From a Fresher’s POV)

To Freshers Reading This

To Seniors Reading This

The Human Side of Writing Code (That We Rarely Talk About)

Every Developer Knows This Feeling

A Quiet Moment Every Developer Knows

Writing Code Is Quietly Emotional

Debugging Is a Conversation With Yourself

Code Reviews Are Human Moments

Burnout Doesn’t Come From Code - It Comes From Pressure

Why We Keep Doing This Anyway

Code Is a Record of Thought

How to Confidently Test Jetpack Compose UI with Espresso

Why UI Testing Matters (and What Usually Fails)