Forem: supriya shah

Jetpack Compose: remember vs rememberSaveable

supriya shah — Mon, 23 Mar 2026 09:09:36 +0000

Originally published on Medium:
https://medium.com/@supsabhi/jetpack-compose-remember-vs-remembersaveable-75ff37f8047e

What it is?When to Use? your beginner friendly guide

Imagine this: You’re filling out a login form on your Android app, typing your email and password carefully. Just as you’re about to hit submit, you accidentally rotate your phone. Poof! All your entered data disappears, and you have to start over. Frustrating, right?

This common scenario highlights one of the most crucial concepts in modern Android development with Jetpack Compose: state management.

When building Android apps with Jetpack Compose, managing state is one of the most important tasks you’ll encounter.

Whether you’re a beginner just starting your journey in Compose or an experienced developer looking to deepen your understanding, mastering remember() and rememberSaveable() is essential to make apps UI interactive and responsive to user actions. Keeping track of UI information — like user inputs, button clicks, or toggle switches — ensures your app behaves reliably and smoothly.

What is “State” in Simple Terms?

Think of state as your app’s memory.In UI programming, state is just information your app needs to “remember” to correctly show the screen. For example:

The current text in a search box.
How many times a button has been clicked.
Whether a switch is on or off.
In a counter app, the current number is the state.
In a shopping cart, the list of items and total price represent state.
When this information changes, the UI updates to reflect it. Jetpack Compose uses mutable state objects like mutableStateOf() to track these changes reactively.

In short it’s any data that can change over time and affects what users see on their screen.

Real-world analogy: State is like the current page number in a book you’re reading. As you progress through the book (interact with your app), the page number (state) changes, and this determines what content you see.

In traditional Android development with XML layouts, managing state was complex and error-prone. Jetpack Compose revolutionizes this by making UI a function of state. When state changes, the UI automatically updates to reflect those changes.

Recomposition is Compose’s way of updating the UI when state changes. Jetpack Compose UI functions can be called multiple times (this is called recomposition).Think of it as automatically redrawing parts of your screen when something changes. However, there’s a catch: during recomposition, local variables get reset to their initial values unless we use special state holders.

Without remember, every time your UI recomposes, your variable would reset to its initial state, losing any user input or interaction.

What is remember()?

remember() is a Compose function that stores a value in memory during composition and returns the same value across recompositions. It’s like giving your Composable function a short-term.It saves the state in a temporary bundle behind the scenes, so user input or important UI state remains even after an activity is recreated.

What is rememberSaveable()?

rememberSaveable() is like remember() with superpowers. It not only stores values across recompositions but also survives configuration changes like screen rotation, theme changes, and even process death in some cases. rememberSaveable uses Android’s SavedStateHandle behind the scenes, storing state in a bundle, so it can survive these changes automatically.

How It Differs from remember()

The key difference lies in persistence:

remember(): Survives recomposition only
rememberSaveable(): Survives recomposition + configuration changes

Use remember() when:

Temporary UI state: Button pressed states, animation values, scroll positions
Derived state: Calculated values that can be easily recomputed
Performance-critical scenarios: High-frequency updates where serialization overhead matters
Large objects: Complex objects that don’t need to survive configuration changes

Use rememberSaveable() when:

User input: Form fields, search queries, text input
Important user progress: Game scores, shopping cart contents
User preferences: Selected options, filter settings
Navigation state: Selected tabs, current page indices

Not managing state correctly can lead to frustrating UX, where your app forgets what the user was doing,your UI becomes essentially broken. Variables reset on every recomposition, and changes don’t trigger UI updates.

One of the common misconception: “My composable only runs once.” In reality, composables can recompose many times.

Always assume your composable function will be called multiple times. That’s why below best practices are very much important

State hoisting: Keep state at the lowest common parent
Single source of truth: Don’t duplicate state across composables
Immutable state: Use immutable data classes when possible
Avoid side effects in composition: Use LaunchedEffect or DisposableEffect
Test configuration changes: Always test your app by rotating the device

Pro tip: For large datasets, save only the essential identifier (like a selected ID) in rememberSaveable() and recreate the full object using remember().

Below is a Simple Example Showing the Difference

@Composable
fun WithoutRememberExample() {
var text = mutableStateOf("")
TextField(
value = text,
onValueChange = { text = it },
label = { Text("Type something") }
)
}

Here, every time Composable redraws (recomposes), text gets reset to empty, so any input is lost immediately — even when you type a character. The UI isn’t interactive at all because it never “remembers” what you typed.

@Composable
fun RememberExample() {
var text by remember { mutableStateOf("") }
TextField(
value = text,
onValueChange = { text = it },
label = { Text("Type something") }
)
}

Here the typed text is remembered only when the UI updates.

But if you rotate the screen, text will reset to empty.

@Composable
fun RememberSaveableExample() {
var text by rememberSaveable { mutableStateOf("") }
TextField(
value = text,
onValueChange = { text = it },
label = { Text("Type something") }
)
}

Here, text will still hold after device rotation or UI recreation.

Understanding the difference between remember() and rememberSaveable() is crucial for building robust, user-friendly Android applications.Remember, becoming proficient with Compose state management takes practice.Start with simple examples and you will reach there sooner.

👏 Found this helpful?

If this article helped you understand Jetpack Compose state management, please give it a clap and follow me for more Android development tutorials!

💬 Questions or suggestions? Drop a comment below — I read and respond to every one!

🔄 Share this article with fellow Android developers who might find it useful.

Happy coding! 🚀

Lazy Grids in Jetpack Compose

supriya shah — Tue, 17 Mar 2026 05:43:46 +0000

Originally published on Medium:
https://medium.com/@supsabhi/lazy-grids-in-jetpack-compose-8a80f52421c9

🧩 Mastering Grids in easy way
Ever opened an app and felt overwhelmed by a long, never-ending list? Or maybe you’ve needed to show a bunch of beautiful photos or product cards without cramming them into a tiny space?

You know, the ones that scroll vertically and show these items one after another. But what if you want to show these items side by side, like a gallery, product catalog, or contact cards?

That’s where the mighty Grid Layout comes in to save the day!

🏛 Classic Android Grids
In classic Android (XML days), developers often used:

GridLayout or RecyclerView with GridLayoutManager for arranging UI components
GridView for bigger, scrollable lists — like image thumbnails or product tiles in shopping apps
💡 So… what exactly is a Grid Layout?
A Grid is like a shelf with rows and columns.
It’s a way to organize items into rows and columns so everything is neat, tidy, and easy to find.

We use grid layouts whenever we need to display a collection of items that are:

Visually Similar — Like a gallery of product images or thumbnails
Equal in Importance — Unlike a news feed where the top item is most important, items in a grid usually hold similar weight
High in Quantity — It’s a much better use of screen space than a vertical list when you have dozens of things to show
⚡ Jetpack Compose Grids Got Lazy!
In Jetpack Compose, there are mainly two ways to arrange items:

1. GridLayout
Good for static, small-to-medium datasets
Builds the whole UI upfront, so if you have a lot of items, it may slow things down
Best for forms or dashboards where all elements should be shown at once
No built-in “lazy loading” here

2. Lazy Lists & Lazy Grids
Smart approach — only composes what’s visible on screen
Includes LazyColumn (for vertical lists) and LazyVerticalGrid (for grids)
Only creates as many views as fit on the screen plus a few extra for smooth scrolling
Fast and memory-friendly, especially for huge lists

🧠 LazyList vs LazyGrid — When to Use What?
Both LazyLists and LazyGrids are “lazy” because they only load the items currently visible on screen, saving battery and memory.

🪄 LazyList (LazyColumn, LazyRow)
Displays items one after another (vertically or horizontally)
Shows sequential content, so each item takes one entire row or column
Perfect for feeds, chat screens, or any single-column list
🧩 LazyGrid (LazyVerticalGrid, LazyHorizontalGrid)
Displays items in rows and columns, forming a neat grid layout
Shows content in a collection manner, so each item takes up one cell in the grid
Perfect for e-commerce product grids, image galleries, or dashboards
🧰 Types of Grids in Jetpack Compose
Jetpack Compose provides two main grid types out of the box:

LazyVerticalGrid
Scrolls vertically, items arranged in columns
Think of your phone’s photo gallery
LazyHorizontalGrid

Scrolls horizontally, items arranged in column
Also great for galleries or horizontally scrolling product carousels
Both work exactly like LazyColumn or LazyRow, but with the magic of multiple columns or rows.

🚀 Quick Example: LazyVerticalGrid

LazyVerticalGrid(
    columns = GridCells.Fixed(3) // 3 columns
) {
    items(20) { index ->
        Text("Item $index", modifier = Modifier.padding(8.dp))
    }
}

columns = GridCells.Fixed(3) → We’re asking for 3 fixed columns
Want an adaptive grid that fits as many columns as possible with at least 100dp width?

LazyVerticalGrid(
    columns = GridCells.Adaptive(minSize = 100.dp)
) {
    items(50) { index ->
        Text("Adaptive $index", modifier = Modifier.padding(8.dp))
    }
}

🧩 GridCells Properties — The Secret Sauce

The real power of LazyVerticalGrid lies in how you define its columns using the GridCells object.

Here are the main ways:

GridCells.Fixed(count) — Sets an exact number of columns. Use when you always want, say, 3 columns, no matter the screen size (great for photo galleries)
GridCells.Adaptive(minSize) — Creates as many columns as will fit, ensuring each column is at least a certain size. Makes your grid responsive across devices
GridCells.FixedSize(size) — Sets an exact width for each column and fills the screen. Less common, but useful for rigid layouts

🏁 Final Thoughts
Lazy Grids in Jetpack Compose are a total game-changer for displaying items in a flexible, scrollable grid — without dealing with RecyclerView adapters or XML layouts.

They’re powerful, adaptive, and super easy to use. Once you try them, you’ll never want to go back.

So go ahead — build that gallery, product grid, or dashboard with LazyVerticalGrid and let Compose handle the heavy lifting! 🚀

Grid layouts are everywhere in Android, and Jetpack Compose’s Lazy grids make building them for modern apps super easy.

💡 Detailed source code and more Compose examples are available on my GitHub — check it out and explore!

https://github.com/supsabhi/GridLayoutDemo.git

Build a Cross-Platform QR Code Scanner in .NET MAUI using ZXing.Net.MAUI

supriya shah — Fri, 06 Feb 2026 07:12:32 +0000

Originally published on Medium:
https://medium.com/@supsabhi/build-a-cross-platform-qr-code-scanner-in-net-maui-using-zxing-net-maui-5638b479372d

A step-by-step beginner’s guide to integrating QR and barcode scanning easily in your MAUI app
If you want to build a cross-platform app with QR code scanning in .NET MAUI, there are several ways to do it. You can use libraries like ZXing.Net.Maui.Controls, Camera.MAUI, IronQR, or Google Vision ML Kit.

Each has its own strengths:

- ZXing is open-source and widely adopted.
- IronQR offers a simple and commercial-ready cross-platform library.
- Google Vision ML Kit provides a machine learning–based alternative.

But today, we’ll focus on ZXing.Net.MAUI, one of the most popular and developer-friendly options.

In this guide, you’ll learn everything you need to integrate ZXing QR Code Scanner in .NET MAUI — including installation, initialization, permissions, and a working example with XAML and C# code.
We’ll also cover useful options like torch and scan area, common issues, and testing tips.

🧩 Why Choose ZXing for .NET MAUI?
There are plenty of reasons developers prefer ZXing.Net.MAUI when adding barcode or QR code scanning features to their apps:

Open-source and widely used — trusted by many developers.
Supports multiple barcode types — QR, EAN, Code128, PDF417, and more.
Works across platforms — Android, iOS, and Windows (WinUI).
Includes both live camera scanning and image decoding.
Easy to integrate and customize — choose barcode formats, enable torch, or adjust detection options.
Actively maintained and community-supported, ensuring stability and updates.

⚙️ 1. Prerequisites
Before diving in, make sure you have the following ready:

✅ The latest .NET SDK *(recommended *.NET 8)
✅ Visual Studio 2022 or later with the Mobile development with .NET workload installed
✅ A working .NET MAUI project

If you’re new to MAUI, open Visual Studio → Create New Project → choose .NET MAUI App.

📦 2.Installation
Step 1: Install the ZXing.Net.MAUI NuGet Package
Think of a NuGet package as a toolbox that adds new features to your app.
To enable QR scanning, install the ZXing.Net.Maui.Controls package.

Option 1 — Using CLI:

dotnet add package ZXing.Net.Maui.Controls --version 0.4.0

Option 2 — Using Visual Studio:

Right-click on your .NET MAUI project in Solution Explorer.
Select Manage NuGet Packages…
Go to the Browse tab and search for ZXing.Net.Maui.Controls.
Click Install.
This gives you access to ready-to-use UI controls such as the camera scanner view.

Step 2: Initialize ZXing in MauiProgram.cs

Your MAUI app needs to know that ZXing is part of the project. You do this by registering the barcode reader service in MauiProgram.cs.


using ZXing.Net.Maui;
public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .UseBarcodeReader(); // register ZXing
        return builder.Build();
    }

💡 Note: Depending on the package version, you may need to use
.UseZXingNetMaui() instead of .UseBarcodeReader().

Step 3: Add Camera Permissions

Since scanning requires camera access, your app must request permissions or it’ll show a black screen.

🔹 Android

Edit Platforms/Android/AndroidManifest.xml:

<uses-permission android:name="android.permission.CAMERA" />

For Android 6.0 (API 23) and above, request permission at runtime:

var status = await Permissions.RequestAsync<Permissions.Camera>();
if (status != PermissionStatus.Granted)
{
    // Handle permission denied
}

🔹 iOS

Open Platforms/iOS/Info.plist and add:

<key>NSCameraUsageDescription</key>
<string>This app uses the camera to scan QR codes.</string>

If you plan to scan images from the gallery, also add:

<key>NSPhotoLibraryUsageDescription</key>
<string>This app accesses your photo library to scan QR codes from images.</string>

🔹 Windows (WinUI)

Edit Package.appxmanifest and enable Webcam under Capabilities.

🎥 3. Create the Scanner UI in XAML

Now let’s design the UI. ZXing provides a CameraBarcodeReaderView control for real-time scanning.

Open your XAML page (e.g., ScannerPage.xaml) and add:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage
    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:zxing="clr-namespace:ZXing.Net.Maui;assembly=ZXing.Net.MAUI"
    x:Class="MyMauiApp.Pages.ScannerPage">
<Grid RowDefinitions="*,Auto" Padding="10">
        <!-- Camera scanner view -->
        <zxing:CameraBarcodeReaderView 
                        x:Name="cameraView"
                        BarcodesDetected="CameraView_BarcodeDetected"
                        IsScanning="True"
                        IsTorchOn="False"
                        IsDetecting="True"
                        VerticalOptions="FillAndExpand" 
                  />
        <!-- Result Label -->
            <StackLayout Grid.Row="1" 
             Orientation="Horizontal" 
              HorizontalOptions="Center">
            <Label x:Name="ResultLabel"
            Text="No code scanned yet" 
            VerticalOptions="Center" />
        </StackLayout>
    </Grid>
</ContentPage>

x:Name="cameraView" → gives a name to access it in C#.
IsDetecting="True" → enables live scanning.
BarcodesDetected="CameraView_BarcodeDetected" → triggers when a QR code is found.

💻 4. Handle Scanned Results in Code-Behind

Open the code-behind file (ScannerPage.xaml.cs) and implement your scan logic.

using ZXing.Net.Maui;
using ZXing.Net.Maui.Controls;
public partial class ScannerPage : ContentPage
{
    bool _isProcessing = false;
    public ScannerPage()
    {
        InitializeComponent();
    }
    private void CameraView_BarcodeDetected(object sender, BarcodeDetectionEventArgs e)
    {
        var result = e.Results?.FirstOrDefault();
        if (result == null) return;
        if (_isProcessing) return;
        _isProcessing = true;
        MainThread.BeginInvokeOnMainThread(async () =>
        {
            cameraView.IsDetecting = false;
            ResultLabel.Text = result.Value ?? "Empty";
            await DisplayAlert("Scanned", result.Value, "OK");
            // Resume scanning if needed
            cameraView.IsDetecting = true;
            _isProcessing = false;
        });
    }
    protected override void OnDisappearing()
    {
        base.OnDisappearing();
        cameraView.IsDetecting = false;
    }
}

🛠️ 5. Common Problems & Fixes

Black Screen or Blank Preview

Usually caused by missing camera permission.
Always check and request permissions at runtime.

No Barcode Detected

Check lighting conditions or camera focus.
Move the device closer to the QR code.
Ensure IsDetecting="True" is set.

⚡ Optimize Scanning Performance

Restrict formats for faster detection:

cameraView.Options = new BarcodeReaderOptions {   
  Formats = BarcodeFormats.QrCode // or BarcodeFormats.All 
};

2.Use TryHarder = true for difficult lighting conditions.

🧠 Final Thoughts

That’s it! You’ve now integrated a fully functional QR Code Scanner in .NET MAUI using ZXing.Net.MAUI.

ZXing is open-source, cross-platform, and easy to set up, making it an excellent choice for most use cases. With just a few steps — installing the package, setting up permissions, and adding the XAML and C# logic — your MAUI app can now read QR codes and barcodes in real time.

Whether you’re building a kiosk, attendance app, or mobile tool, ZXing.Net.MAUI gives you the flexibility and reliability you need.

[Boost]

supriya shah — Fri, 30 Jan 2026 06:09:14 +0000

Master Method Overloading and Overriding in Android (Kotlin) Development

supriya shah ・ Jan 30

#android #programming #software #computerscience

Master Method Overloading and Overriding in Android (Kotlin) Development

supriya shah — Fri, 30 Jan 2026 06:08:22 +0000

Originally published on Medium:
https://medium.com/@supsabhi/master-method-overloading-and-overriding-in-android-kotlin-development-46a8f2da6d07

Method overloading and method overriding are very common and core techniques in OOPS programming. When you build apps, you must have come across these terms. They sound similar, but they do completely different jobs! They let you reuse and extend code in smart ways by allowing you to write clean, reusable, and flexible code.

Overloading = same name, different parameters.
Overriding = subclass replaces/extends behavior of a parent class method.

Let’s look more deeply into each one of these.

Method Overloading
Method overloading happens when multiple methods share the same name but have different parameter lists. What it means is there are multiple functions with the same name but different signatures. These differences can be in the number, type, or order of parameters. This different signature allows the compiler to pick the correct function when you call it.

So, you can say that the main goal of overloading is to make your code more readable and flexible.

A few important things need to be considered in Kotlin are:

The compiler resolves which function to call at compile time (this is called Compile-Time Polymorphism) because it knows the parameter types beforehand.
It doesn’t require inheritance. Overloading can happen entirely within one class.
Example:


class Calculator {
    fun sum(a: Int, b: Int): Int {
        return a + b
    }
fun sum(a: Int, b: Int, c: Int): Int {
        return a + b + c
    }
    fun sum(a: Double, b: Double): Double {
        return a + b
    }
}
fun main() {
    val calc = Calculator()
    println(calc.sum(2, 3))        // uses (Int, Int)
    println(calc.sum(2, 3, 4))     // uses (Int, Int, Int)
    println(calc.sum(2.5, 3.5))    // uses (Double, Double)
}

Here, all the methods have the same name sum, but they differ either in their parameter number or in parameter type.

In Kotlin, you might see overloading in functions like Toast.makeText()as below

Toast.makeText(Context context, CharSequence text, int duration)
Toast.makeText(Context context, int resId, int duration)

Overloading with extension functions or top-level functions also works — Kotlin treats overloads in that scope too.
You need to be careful with ambiguous overloads: if two overloads are too similar and the compiler cannot clearly pick one, you’ll get an “overload resolution ambiguity” error.

When & why to use overloading

When you have a method that logically does the same thing but you want to support different kinds of inputs (e.g., load(image: String), load(image: Uri), load(image: File)).
When you want to improve readability: you don’t need many method names like loadStringImage, loadUriImage; you just overload load().

Method Overriding

Overriding is about inheritance. You have a base (parent) class that defines a method (or abstract method), and a subclass (child class) provides its own implementation of that method (same signature) so that when you call it on the subclass instance, the subclass version runs. This supports runtime polymorphism. You’re essentially taking the parent’s generic instruction and giving it a specific, custom implementation in the child.

As Android development is built on inheritance, you constantly override functions that the Android system (the parent) defines.
When you create an Android Activity, you inherit the onCreate() method from a parent class like AppCompatActivity.
The parent has a default onCreate() that handles basic setup. You override it to add your specific code.

Also in Kotlin:

Classes and methods are final by default (i.e., cannot be inherited/overridden) unless you mark them with open.
In the subclass, you must use the override keyword to indicate you are overriding.
You can call the parent version via super.methodName() if needed.
For example, all lifecycle methods like onCreate(), onStart(), onPause() are open in the Activity class, so you can override them.

class MainActivity : AppCompatActivity() {
    override fun onPause() {
        super.onPause() // calls the original method from AppCompatActivity
        // your custom logic here
        Log.d("MainActivity", "App is paused")
    }
}

Here:
override → tells Kotlin we’re redefining a method from the parent.
super.onPause() → calls the original version in the parent class (AppCompatActivity), to keep the Android lifecycle working properly.
Then, we can add our own logic below or above that call.

So we can say that when overriding an Android lifecycle method (like onCreate), you often call super.onCreate(...) inside your overridden function.
This is you saying, “Do the Parent’s basic setup first, and then run my special code.”

Why to use overriding

To customize or extend behavior of a base class method in a subclass.
To implement interfaces or abstract classes: you provide concrete implementations in subclasses.

The Quick Summary: The Difference That Matters
Think of it this way:

Overloading is about variety (one name, many parameter options). It happens horizontally within one class. It lets you create multiple versions of the same method with different inputs.
Overriding is about specialization (one name, one parameter set, one new action). It happens vertically down the inheritance chain. It lets you modify how inherited methods behave.
Mastering these two concepts is key to writing clean, logical, and truly Object-Oriented Kotlin code in your Android applications!

MVVM vs Clean Architecture: Key Differences and How They Work Together in Android

supriya shah — Thu, 22 Jan 2026 08:55:12 +0000

Originally published on Medium:
https://medium.com/@supsabhi/mvvm-vs-clean-architecture-1ecaba107209

Imagine you’re building a house.Before you even pick colors or furniture, you need a blueprint of the building — that’s your architecture.

Then, inside the house, you decide how specific rooms work — that’s your design pattern.

In Android development, the story is exactly the same.
👉 Clean Architecture is the blueprint for the entire building.
👉 MVVM is the design pattern you choose for your living room and kitchen area.

They don’t compete — they work together.

🧩 Architecture vs Design Pattern
We can say that architecture is nothing but a big picture that tells us about the overall structure of a building (or an app).

In software development, it’s like putting your most valuable asset — your core business logic — in a protected vault at the center of your app.

A design pattern, on the other hand, is a small, proven solution to a recurring problem inside that architecture.

🧱 Clean Architecture — The Blueprint
Clean Architecture focuses on maintainability and scalability.
It follows one golden rule:

🧭 The inner circle never knows anything about the outer circle.

What does that mean?
The core logic doesn’t care if you’re showing data on a phone, tablet, or smart TV.
The core logic doesn’t care if data comes from Room, a remote API, or a simple text file.
So, even if your UI or database changes, your core business logic remains untouched.
This is achieved through the** Dependency Inversion Principle (DIP)** — outer layers must implement the interfaces defined by the inner layers. It’s like flipping dependencies upside down so your core never depends on external tools.

🧠 The Domain Layer (The Brain / The Core)
What it is: The innermost layer holding your core business rules.
Key Components: Entities: Pure data models like Userand Use Cases: Actions like LoginUserUseCase.

💾 The Data Layer (The Storage / The Muscles)

What it is: Handles fetching, storing, and managing data from external systems.
Key Components:Repositories: Decide where to fetch data from — network or local database.Data Sources: Retrofit for network calls, Room for local storage.Connection: Implements the interfaces defined in the Domain Layer.

📱 The Presentation Layer (The Face / The Output)

What it is: Responsible for showing data and capturing user actions.
Key Components: Activities, Fragments, Composables (Views), and ViewModels.
The Role: Talks to the Domain Layer (via Use Cases) to get data and uses a pattern like MVVM to manage the UI state.

✅ In summary:
Clean Architecture is highly maintainable, easy to test, and independent of frameworks — though it can feel complex initially and needs a bit more setup.

🎯 MVVM Pattern — The UI Hero
MVVM (Model–View–ViewModel) focuses on keeping the Presentation Layer clean and reactive.
Its main goal? Make the View as “dumb” as possible.

🔹 View (Activity / Fragment / Composable)
Role: The screen. Draws UI elements and handles user input (clicks, swipes, typing).
Key Action: Observes the ViewModel for data changes and sends user actions back to it.

🔹 ViewModel (The Screen’s Brain)
Role: Holds UI state — what to display, whether to show a loading spinner, etc.
Survives configuration changes (like screen rotation).
Acts like a middle manager between View and Model.
Key Action:
Doesn’t reference Android Views directly.
Talks to Use Cases from the Domain Layer.
Updates observable data (LiveData, StateFlow).

🔹 Model (The Data Source)
Role: Represents your actual data — users, products, etc.
Key Action: Usually maps to your Domain/Data Layers.
The ViewModel doesn’t handle data logic itself — it delegates to a Use Case.

⚙️ How MVVM Works
User clicks a button → ViewModel reacts → Fetches data from Model → Updates UI automatically

The View simply watches the ViewModel’s data and updates itself.
That makes debugging easy — you always know where your data came from.

However, if too much logic creeps into the ViewModel, it can become messy.

🏁 Clean Architecture + MVVM = Perfect Combo

We can now say that:

Clean Architecture = Macro-level strategy (big picture)
MVVM = Micro-level pattern (how UI works)

MVVM can live inside Clean Architecture as the bridge between the UI layer and the business logic layer.

You can use MVVM without Clean Architecture, but your code will be less scalable and harder to test.

Clean Architecture provides the Domain and Data layers (the app’s brain and muscles).
MVVM provides the Presentation Layer (the face) — making the final UI clean, efficient, and testable.

🧭 Final Thoughts

🏗️ Clean Architecture = The entire building plan.
🎨 MVVM = The design pattern for your rooms.
💡 Together = A solid, flexible, and testable Android app.
Start small:
Apply MVVM first, then gradually refactor your project toward Clean Architecture as it grows.
That’s how you move from “it works” to “it scales beautifully.” 🚀

Sockets in Android: From WebSockets to Socket.IO (with Jetpack Compose Example)

supriya shah — Mon, 19 Jan 2026 07:06:27 +0000

Originally published on Medium:
https://medium.com/@supsabhi/sockets-in-android-from-websockets-to-socket-io-with-jetpack-compose-example-5773828ba05b

Real-time updates are a real challenge! Every time we play games or use a chat application, the instant updates on screen always amaze us. How does the app receive updates without constantly refreshing APIs?
The answer is “Sockets.” Let’s dive deeper into sockets, explore different types, focus on IO sockets, and see how to implement them in Android Jetpack Compose.

A socket is like a live communication channel between your Android app and a server. Unlike standard HTTP APIs where you request data and wait for a reply, sockets remain connected and enable two-way communication. Think of it as a direct digital pipe — data can flow both ways, supporting fast, two-way updates without repetitive polling.

In practice, you can distinguish between HTTP and sockets like this:
HTTP: You send a request, the server replies, communication happens, and the process ends.
Sockets: Sockets can be viewed as ,suppose in the process of opening a phone call, you pick up phone and “keep the call alive” and both sides can talk anytime

There are different types of sockets, each used for specific purposes:

WebSockets: WebSocket is a W3C and IETF standardized protocol that offers a persistent channel over a single TCP connection. You can send or receive as much data as needed, without reopening new HTTP requests. It’s lightweight, efficient, and ideal for streaming data. WebSockets are commonly used in live sports updates, stock prices, collaborative docs, and IoT device status — where low latency and immediate updates are essential.
Socket.IO: Socket.IO isn’t a protocol, but a full-featured library built on top of WebSockets (with fallbacks). It manages fallbacks, reconnections, broadcasting, event naming, and more. It’s easier for developers because it solves real-world connection issues out of the box. Socket.IO is mainly used for chat apps, live games, and push notification dashboards.
Raw TCP/UDP Sockets: These are low-level protocols. TCP enables reliable raw byte transfer and is used in file transfer and messaging. UDP is faster but less reliable than TCP and is used in video streaming and gaming. Raw TCP/UDP sockets offer custom device-to-device control and binary protocol capabilities.
Let’s focus more on our star: Socket.IO.

Socket.IO smooths over many networking headaches, especially for mobile: reconnection logic, event-centric APIs, message buffering during downtimes, and support for various network topologies. It certainly deserves special recognition.

Implementation in Android Jetpack Compose
Below is an example of live updating a dashboard based on the server’s latest information.
(First, add implementation

'io.socket:socket.io-client:2.1.0'

to your build.gradle.)

Make sure the socket client version matches the server version.
Also, add the internet usage permission in your manifest.

Data Model Class

data class DashBoardMessage(val var1: String, val var2: String, val var3: String)
ViewModel

class DashBoardViewModel : ViewModel() {
    var latestMessage by mutableStateOf<DashBoardMessage?>(null)
        private set

    private val socketManager = SocketManager()

    fun start() {
        socketManager.connect { message ->
            latestMessage = message
        }
    }

    override fun onCleared() {
        super.onCleared()
        socketManager.disconnect()
    }
}

Socket Manager

class SocketManager {
    private var socket: Socket? = null

    fun connect(onMessage: (DashBoardMessage) -> Unit) {
        try {
            val opts = IO.Options().apply { forceNew = true }
            socket = IO.socket("https://your-socket-server.com", opts)

            socket?.on(Socket.EVENT_CONNECT) {
                Log.d("SocketIO", "Connected")
            }

            socket?.on("message") { args ->
                if (args.isNotEmpty() && args[0] is JSONObject) {
                    val json = args[0] as JSONObject
                    val msg = DashBoardMessage(
                        var1 = json.optString("var1"),
                        var2 = json.optString("var2"),
                        var3 = json.optString("var3")
                    )
                    Handler(Looper.getMainLooper()).post {
                        onMessage(msg)
                    }
                }
            }

            socket?.connect()
        } catch (e: Exception) {
            e.printStackTrace()
        }
    }

    fun disconnect() {
        socket?.disconnect()
        socket?.off()
    }
}

Compose Screen


@Composable
fun DashboardScreen(viewModel: DashBoardViewModel = viewModel()) {
    val msg = viewModel.latestMessage

    LaunchedEffect(Unit) {
        viewModel.start()
    }

    Column(modifier = Modifier.padding(16.dp)) {
        Text("Var1: ${msg?.var1 ?: ""}")
        Text("Var2: ${msg?.var2 ?: ""}")
        Text("Var3: ${msg?.var3 ?: ""}")
    }
}

With this setup, you get real-time, event-driven updates in a Compose UI. Incoming messages instantly update the screen, and sending a message emits it to the server — no need for manual thread handling or traditional callbacks.

Sockets might sound technical, but with tools like Socket.IO, creating a real-time, mobile-friendly Android app becomes straightforward.

So next time you need live updates — whether for a parking system, chat app, or stock ticker — reach for sockets instead of hammering your APIs.
GitHub Repository for Hands-On Reference

To make this article more practical and hands-on, I’ve published a public GitHub repository that demonstrates everything discussed above.

📂 GitHub Repository:
https://github.com/supsabhi/IoSocketJetPack.git

LazyColumn vs RecyclerView: A Developer’s Guide to Modern Android Lists

supriya shah — Fri, 16 Jan 2026 09:28:33 +0000

Originally published on Medium:
https://medium.com/@supsabhi/lazycolumn-vs-recyclerview-a-developers-guide-to-modern-android-lists-aecae66c3356

Making the right choice for your Android app’s scrollable content
Just imagine, you’re building an Android app that needs to display a list of items — maybe it’s a social media feed, a shopping cart, or a contact list. Practically, there will be very few apps which will not have any kind of list. While developing an app when a developer needs to choose between the tried-and-true RecyclerView or embrace Jetpack Compose’s LazyColumn, the real struggle starts.

This decision isn’t just about following the latest trends. It’s about choosing the right tool that will make your code cleaner, your app more performant, and your development experience smoother.

For years, RecyclerView was the standard. With Jetpack Compose, LazyColumn brings a new, more human-friendly approach. But what really sets them apart?

Let’s dive deep into both approaches and help you make an informed decision.

Traditional Tried RecyclerView
RecyclerView has been the backbone of Android list displays since 2014. It replaced ListView with a more flexible and efficient design, introducing the ViewHolder pattern and giving developers granular control over how items are displayed and recycled.

Basically, RecyclerView is nothing but a robust, flexible way of showing long lists or grids of views. It acts as a sophisticated recycling system. Instead of creating a new view for every item in your list (which would be memory-intensive), it creates just enough views to fill the screen plus a few extras, saving both memory and processor work. As you scroll, views that disappear from the top are recycled and reused for new items appearing at the bottom.

But as they say, “everything comes with a price.” RecyclerView too has its own challenges; we will look into it in detail. First, let’s see how one can set up RecyclerView in an application:

// Data class
data class Task(val id: Int, val title: String, val isCompleted: Boolean)
// ViewHolder
class TaskViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
    private val titleText: TextView = itemView.findViewById(R.id.task_title)
    private val checkbox: CheckBox = itemView.findViewById(R.id.task_checkbox)

    fun bind(task: Task, onTaskToggle: (Task) -> Unit) {
        titleText.text = task.title
        checkbox.isChecked = task.isCompleted
        checkbox.setOnCheckedChangeListener { _, isChecked ->
            onTaskToggle(task.copy(isCompleted = isChecked))
        }
    }
}
// Adapter
class TaskAdapter(
    private var tasks: List<Task>,
    private val onTaskToggle: (Task) -> Unit
) : RecyclerView.Adapter<TaskViewHolder>() {

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): TaskViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_task, parent, false)
        return TaskViewHolder(view)
    }

    override fun onBindViewHolder(holder: TaskViewHolder, position: Int) {
        holder.bind(tasks[position], onTaskToggle)
    }

    override fun getItemCount() = tasks.size

    fun updateTasks(newTasks: List<Task>) {
        tasks = newTasks
        notifyDataSetChanged()
    }
}

So basically, how RecyclerView is set up is:

Adapter: Custom code links your data to the list items
ViewHolder: Custom classes track references for each view in an item for fast updates
LayoutManager: Controls if your list is vertical, horizontal, or grid
XML layouts: Most code is separate from display — declarative UI felt far away here
Now let’s review deeper about RecyclerView’s strengths and its challenges.

RecyclerView’s Strengths
1. Battle-Tested Performance RecyclerView has been optimized over nearly a decade. It handles large datasets efficiently and provides smooth scrolling even on older devices.

2. Extensive Customization Want custom animations? Multiple view types? Complex layouts? RecyclerView gives you the tools to build almost anything. The ItemDecorator system lets you add dividers, spacing, and custom decorations with precision.

RecyclerView’s Challenges
1. Boilerplate Overload Look at that code above. For a simple list, you need a ViewHolder, an Adapter, layout files, and proper setup. That’s a lot of ceremony for displaying a list.

2. XML Layout Dependencies You’re still tied to XML layouts, which means context switching between Kotlin and XML files. Design-time previews can be limited.

3. Manual State Management Updating lists requires careful state management. Forget to call notifyItemChanged() and your UI won't update. Call notifyDataSetChanged() too often and performance suffers.

Let’s Check Out the New Player in the Market: LazyColumn
LazyColumn arrived with Jetpack Compose, representing a fundamental shift in how we build Android UIs. Instead of the imperative “how” of RecyclerView, LazyColumn focuses on the declarative “what.”

LazyColumn is the Compose-native component for vertically scrolling lists. The best part: there’s no Adapter, no XML, just Kotlin in a “what, not how” style.

@Composable
fun TaskList(
    tasks: List<Task>,
    onTaskToggle: (Task) -> Unit,
    modifier: Modifier = Modifier
) {
    LazyColumn(
        modifier = modifier.fillMaxSize(),
        verticalArrangement = Arrangement.spacedBy(8.dp),
        contentPadding = PaddingValues(16.dp)
    ) {
        items(tasks) { task ->
            TaskItem(
                task = task,
                onToggle = { onTaskToggle(it) }
            )
        }
    }
}
@Composable
fun TaskItem(
    task: Task,
    onToggle: (Task) -> Unit,
    modifier: Modifier = Modifier
) {
    Card(
        modifier = modifier.fillMaxWidth(),
        elevation = CardDefaults.cardElevation(defaultElevation = 2.dp)
    ) {
        Row(
            modifier = Modifier
                .fillMaxWidth()
                .padding(16.dp),
            horizontalArrangement = Arrangement.SpaceBetween,
            verticalAlignment = Alignment.CenterVertically
        ) {
            Text(
                text = task.title,
                style = MaterialTheme.typography.bodyLarge,
                modifier = Modifier.weight(1f)
            )
            Checkbox(
                checked = task.isCompleted,
                onCheckedChange = { onToggle(task.copy(isCompleted = it)) }
            )
        }
    }

}
Now here, if you notice carefully, you will see that there are no adapters, no view holders, no layout inflation. Just describe what you want.

LazyColumn’s Strengths:
1. Simplicity and Code Readability LazyColumn provides a simple way to develop, increasing code readability. You can see the entire list structure at a glance without jumping between multiple files.

2. Automatic State Management When your state changes, Compose automatically recomposes only the affected items. No need to manually manage notify calls.

3. Built-in Modern Features Spacing, padding, and arrangements are built-in. Need sticky headers? Just use stickyHeader {}. Want different item types? Use multiple items {} blocks.

4. Type Safety Everything is strongly typed. No more casting views or dealing with position-based lookups that might fail at runtime.

Performance Comparison
In case of memory usage, both LazyColumn and RecyclerView use similar lazy loading strategies. They only create and maintain views/composables for visible items plus a small buffer.

If we want to compare scrolling performance, then RecyclerView has a slight edge in raw scrolling performance due to its mature optimizations and lower-level control. However, LazyColumn’s performance is excellent and continues to improve with each Compose release.

The Verdict
The verdict can be sorted down as:

Both RecyclerView and LazyColumn are excellent tools for different contexts.

LazyColumn is the future for new projects, teams embracing modern Android development, and applications prioritizing development velocity and maintainability.

RecyclerView remains the right choice for projects with established View-based architectures, teams with deep RecyclerView expertise, or applications with extremely demanding performance requirements.

For lists with frequent state changes or dynamic data: LazyColumn’s model makes these scenarios less error-prone, and animations come much easier.

The key is making an informed decision based on your specific context rather than following trends blindly. Both tools can help you build great Android apps — choose the one that fits your project best.

What’s your experience with LazyColumn vs RecyclerView? Have you made the switch, or are you still evaluating? Share your thoughts and challenges in the comments below.

Unlocking NFC: Reading MIFARE Cards with Jetpack Compose

supriya shah — Wed, 14 Jan 2026 12:01:14 +0000

Originally published on Medium:
https://medium.com/@supsabhi/unlocking-nfc-reading-mifare-cards-with-jetpack-compose-bf250171d1f1

NFC (Near Field Communication) is one of those technologies we use almost daily — without even realising it. From tapping your phone at the supermarket checkout to scanning an access badge at work, NFC has quietly become a part of our everyday lives.

If you’re building an Android app that involves card reading — for public transportation, access control, loyalty programs, or event tickets — understanding how to implement NFC tag reading is essential. In this post, we’ll explore how to read MIFARE Classic tags using Android and Jetpack Compose.

Before diving into the implementation, let’s briefly talk about the types of NFC tags you may encounter. NFC Forum classifies tags into Type 1 to Type 5, and among the most popular families are:

MIFARE Classic — Found in transport cards, hotel keys, and loyalty cards. Widely used, but not the most secure.

MIFARE Ultralight — Low-cost and used for disposable tickets or event passes.

MIFARE DESFire — Designed for higher-security applications, but more expensive.

NTAG Series — Known for better security and compatibility. A solid choice for general-purpose usage.

Each has its pros and cons.Selection of card depends on your app’s needs — security, cost, and data volume.

Let’s build a basic app that can read MIFARE Classic tags. We’ll use Jetpack Compose for UI and handle NFC in a standard way.

Step 1: Add Required Permissions and Features
In your AndroidManifest.xml, declare NFC permissions and features:

<uses-permission android:name="android.permission.NFC" />
<uses-feature android:name="android.hardware.nfc" android:required="true" />

Also, add an intent-filter and meta-data block to capture the tag:

<intent-filter>
    <action android:name="android.nfc.action.TECH_DISCOVERED" />
</intent-filter>
<meta-data
    android:name="android.nfc.action.TECH_DISCOVERED"
    android:resource="@xml/nfc_tech_filter" />

And create a res/xml/nfc_tech_filter.xml file with:

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <tech-list>
        <tech>android.nfc.tech.MifareClassic</tech>
    </tech-list>
</resources>

Step 2: Capture the Tag in MainActivity
Set up the NFC adapter and foreground dispatch in your MainActivity:

class MainActivity : ComponentActivity() {
    private var nfcAdapter: NfcAdapter? = null
    private val viewModel: NfcViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        nfcAdapter = NfcAdapter.getDefaultAdapter(this)
        setContent {
            NfcScreen(viewModel)
        }
    }
override fun onResume() {
        super.onResume()
        val intent = Intent(this, javaClass).apply {
            addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP)
        }
        val pendingIntent = PendingIntent.getActivity(this, 0, intent, PendingIntent.FLAG_MUTABLE)
        nfcAdapter?.enableForegroundDispatch(this, pendingIntent, null, null)
    }
    override fun onPause() {
        super.onPause()
        nfcAdapter?.disableForegroundDispatch(this)
    }
    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        val tag = intent.getParcelableExtra<Tag>(NfcAdapter.EXTRA_TAG)
        tag?.let {
            val result = readMifareClassic(it)
            viewModel.updateNfcData(result)
        }
    }
}

Step 3: Read MIFARE Classic Data
This function reads data from each block of a MIFARE Classic tag:

fun readMifareClassic(tag: Tag): String {
    val mfc = MifareClassic.get(tag) ?: return "Not a MIFARE Classic tag"
    val sb = StringBuilder()
try {
        mfc.connect()
        val sectorCount = mfc.sectorCount
        for (sector in 0 until sectorCount) {
            val auth = mfc.authenticateSectorWithKeyA(sector, MifareClassic.KEY_DEFAULT)
            if (auth) {
                val blockCount = mfc.getBlockCountInSector(sector)
                val blockIndex = mfc.sectorToBlock(sector)
                for (block in 0 until blockCount) {
                    val data = mfc.readBlock(blockIndex + block)
                    sb.append("Sector $sector Block $block: ${data.joinToString(" ") { "%02X".format(it) }}\n")
                }
            } else {
                sb.append("Sector $sector: Authentication failed\n")
            }
        }
    } catch (e: IOException) {
        sb.append("Error: ${e.localizedMessage}")
    } finally {
        try { mfc.close() } catch (_: IOException) {}
    }
    return sb.toString()
}

Step 4: Store and Display the Data Using ViewModel + Compose
We’ll use a ViewModel to hold the NFC data and update the UI reactively.

class NfcViewModel : ViewModel() {
    var nfcData by mutableStateOf("Scan a MIFARE Classic tag")
        private set
fun updateNfcData(data: String) {
        nfcData = data
    }
}

The Jetpack Compose UI:

@Composable
fun NfcScreen(viewModel: NfcViewModel) {
    val nfcData = viewModel.nfcData
    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text("Scan MIFARE Tag", fontSize = 24.sp)
        Spacer(modifier = Modifier.height(16.dp))
        Text(text = nfcData, fontSize = 18.sp, color = Color.DarkGray)
    }
}

That’s it — you now have a working Android app that can scan and read MIFARE Classic NFC tags using Jetpack Compose!

This is just the foundation. You can expand this to:Write to NFC tags,Authenticate with custom keys,Handle different tag types (Ultralight, DESFire, NTAG),Encrypt/decrypt data blocks

Final Thoughts
While MIFARE Classic is commonly used, it’s worth noting that it has some known security weaknesses. For sensitive data, consider more secure alternatives like MIFARE DESFire or NTAG cards. Always choose your NFC tech based on the use-case.

Whether you’re building an access control system or creating an innovative event app, integrating NFC can take your user experience to the next level.

Let me know in the comments if you’d like a follow-up post on writing to NFC tags ?

Exploring Supabase for Android: A Modern Alternative to Firebase

supriya shah — Mon, 12 Jan 2026 06:52:02 +0000

Originally published on Medium:
https://medium.com/@supsabhi/exploring-supabase-for-android-a-modern-alternative-to-firebase-f8a61ddb886b
For years, Firebase has been the go-to solution for Android developers needing user authentication, simplified backend development, and features like push notifications. It’s been so popular that, for many, it was the only real choice. But now, there’s a new contender in the arena: Supabase.

What is Supabase?
Founded in 2020, Supabase is an open-source, serverless platform designed to make backend development easier and more flexible. It serves as a powerful alternative to Firebase, offering a robust set of features that cover everything from authentication to real-time data updates.

If you’re an Android developer, you’ll appreciate that Supabase is built on top of PostgreSQL, a relational database. This means your data is stored in tables with rows and columns, and you can use full-fledged SQL queries — a big difference from Firebase’s document-based, JSON storage.

Key Features of Supabase
Multiple Authentication Options: Supports email/password, social logins, and more.

Real-Time Updates: Perfect for apps that need live data synchronization.
Push Notifications: Easy to set up and integrate.
Strong Security: Leverages PostgreSQL’s Row-Level Security (RLS) for fine-grained access control.
Easy Setup: Designed for quick onboarding and minimal configuration.

Getting Started with Supabase on Android
To use Supabase in your Android project, you’ll need to include the Supabase libraries and a networking client — most commonly, Ktor. If you’re not familiar with Ktor, I’ve written a detailed guide on how to integrate it into your project, which you can find here.

Adding Dependencies
In your app-level build.gradle, add the following:


plugins {
    kotlin("plugin.serialization")
}
dependencies {
    // Navigation
    implementation(libs.androidx.navigation.compose)
    // Network Image 
    implementation(libs.coil.compose)
    // Supabase
    implementation(platform(libs.supabase.bom))
    implementation(libs.realtime.kt)
    implementation(libs.postgrest.kt)
    implementation(libs.ktor.client.android)
    implementation(libs.kotlinx.serialization.json)
}

And in your project-level build.gradle:

plugins {
    kotlin("jvm") version "2.0.0"
    kotlin("plugin.serialization") version "2.0.0"
}

Setting Up Your Database
Create a Supabase Account:
Go to supabase.com and create a new project.
Create a Table:
For this example, let’s make a simple “vehicle” table with the following columns:
id (Primary key, auto-increment)

name (Text)

model (Text)

year (Integer)

For simplicity, we’ll skip enabling Row-Level Security (RLS) for now, but we’ll enable real-time updates.

Creating the Data Model

Back in your Android project, let’s define a data class Vehicle

data class Vehicle(
    val id: String? = null,
    val name: String,
    val model: String,
    val year: Int,
)

Initializing the Supabase Client

In MainActivity, let’s set up the Supabase client

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            SupaVehicleAppTheme {
                val supabaseClient = createSupabaseClient(
                    supabaseKey = "YOUR_SUPABASE_KEY",
                    supabaseUrl = "YOUR_SUPABASE_URL"
                ) {
                    install(Realtime)
                    install(Postgrest)
                    httpConfig {
                        this.install(WebSockets)
                    }
                }
            }
        }
    }
}

You’ll find your project’s API key and URL in the Supabase dashboard under the project API information section.

Performing CRUD Operations

Here’s how you can interact with your Supabase database from your Android app:

Fetch Vehicles:

suspend fun getVehicleList() =
    supabase.from("vehicle")
        .select()
        .decodeList<Vehicle>()

Insert a Vehicle:

suspend fun insertVehicle(vehicleToAdd: Vehicle) {
    supabase.from("vehicle").insert(vehicleToAdd)
}

Delete a Vehicle:

suspend fun deleteVehicle(vehicleToDelete: Vehicle) {
    supabase.from("vehicle").delete {
        filter {
            Vehicle::id eq vehicleToDelete.id
        }
    }
}

Update a Vehicle:

suspend fun updateVehicle(vehicleToUpdate: Vehicle) {
    supabase.from("vehicle").update(
        {
            set("name", vehicleToUpdate.name)
        }
    ) {
        filter {
            eq("id", vehicleToUpdate.id)
        }
    }
}

Upsert a Vehicle:

Upsert is a handy operation that either inserts a new row or updates an existing one if it already exists.

suspend fun upsertVehicle(vehicleToUpsert: Vehicle) {
    supabase.from("vehicle").upsert(vehicleToUpsert)
}

Wrapping Up

With these basic operations, you can manage your data in Supabase and display it in your app as needed. Supabase is a flexible, open-source alternative to Firebase, especially if you prefer relational databases and full SQL support.From managing real-time data to implementing secure authentication, Supabase offers a modern and developer-friendly backend solution.

I hope this guide helps you get started with Supabase on Android. If you have any questions or want to dive deeper, feel free to reach out!

Effortless Android Logging with Timber and Kotlin

supriya shah — Thu, 08 Jan 2026 08:49:29 +0000

Originally published on Medium:
https://medium.com/@supsabhi/effortless-android-logging-with-timber-and-kotlin-f0aaa0a701b7

Logging is a cornerstone of Android development. It helps you track down bugs, monitor app behavior, and understand what’s happening under the hood-both during development and after your app is live. In short, logging is your best friend when coding!

But let’s be honest: Android’s built-in Log class, while functional, can get unwieldy in bigger projects. Managing log tags, filtering output, and cleaning up before release can quickly become a headache.

That’s where Timber comes in-a lightweight, open-source logging library created by Jake Wharton that makes logging in Android (especially with Kotlin) much more pleasant.

What Makes Timber Special?

Concise and Clean: Timber’s API is simple and removes the need for repetitive boilerplate code.
Automatic Tag Generation: No more hardcoded tags-Timber automatically uses your class name as the tag
Customizable Trees: Timber introduces the concept of “trees,” which let you control how and where logs are output. For example, you can send logs to crash reporting tools or filter them by build type.
Production Safety: By default, Timber encourages you to disable logs in release builds, helping prevent sensitive information from leaking or cluttering production logs
Setting Up Timber in Your Android App

Step 1: Add the Dependency

In your app-level build.gradle:

implementation 'com.jakewharton.timber:timber:5.0.1'

(Check for the latest version before adding.)

Step 2: Initialize Timber in Your Application Class

The best place to “plant” your Timber trees is in your custom Application class. This ensures logging is set up as soon as your app starts.

class MyApp : Application() {
override fun onCreate() {
super.onCreate()
if (BuildConfig.DEBUG) {
Timber.plant(Timber.DebugTree())
} else {
Timber.plant(ReleaseTree()) // Custom tree for release
}
}
}

DebugTree automatically tags logs with the calling class name, making debugging easier.
For production, you can implement a custom ReleaseTree to filter or redirect logs as needed.
Don’t forget to declare your Application class in the AndroidManifest.xml:

<application
android:name=".MyApp"
…>
</application>

Step 3: Logging in Your Code

Replace all usages of Log.d, Log.e, etc., with Timber’s methods:

Timber.d("Debug message")
Timber.i("Info message")
Timber.w("Warning message")
Timber.e("Error message: %s", error)
You can use string templates for dynamic content: Timber.d(“User id: $userId”).

All standard log levels (verbose, debug, info, warn, error) are supported.
Advanced Usage: Custom Trees and Extensions

Custom Trees

Timber’s tree system lets you define how logs are handled. For example, you can create a tree that sends errors to Firebase Crashlytics or Sentry:

class CrashReportingTree : Timber.Tree() {
override fun log(priority: Int, tag: String?, message: String, t: Throwable?) {
if (priority >= Log.WARN) {
// Send to crash reporting
}
}
}

Plant your custom tree in release builds to capture only important logs.

Kotlin Extensions

Libraries like timberkt provide Kotlin-specific extensions, making logging even more idiomatic:

Timber.d { "User id: $userId, name: ${user.name}" }

The lambda is only evaluated if the log will actually be printed, improving performance.
Why Choose Timber?

No More Manual Tags: Timber generates tags for you, so you don’t have to manage them manually.
Easy Cleanup: You can disable logging in release builds with a single line, so you never have to hunt down and remove log statements by hand.
Customizable Behavior: In production, you can route logs to crash reporting services instead of Logcat, ensuring you only capture what matters most.
Automatic Metadata: Timber can include class names, line numbers, and more, making your logs more informative.
Final Thoughts

Timber isn’t just another logging library-it’s a thoughtful enhancement to your Android development workflow. With concise syntax, automatic tagging, and customizable trees, Timber makes logging a breeze without sacrificing control or safety.

So next time you’re about to write Log.d(“TAG”, “Some message”), give Timber a try. It might just change the way you log forever.

Happy Coding!

Clean Architecture Made Simple: A Koin DI Walkthrough for Android

supriya shah — Wed, 07 Jan 2026 08:30:13 +0000

Originally published on Medium:
https://medium.com/@supsabhi/clean-architecture-made-simple-a-koin-di-walkthrough-for-android-c1f6fd95a718
Dependency injection (DI) is a staple in modern Android development. Whether you’re a seasoned pro or just getting your feet wet, you’ve probably encountered DI’s benefits: loose coupling, modularity, reduced redundancy, and improved reusability. But the real magic of DI often reveals itself as your app grows in size and complexity-suddenly, managing dependencies by hand becomes a headache you didn’t see coming.

At first, DI frameworks can seem intimidating. Many developers, when first introduced to DI, think, “Why do I need this extra layer? Isn’t it just making things more complicated?” And, to be fair, some DI frameworks do live up to that reputation-they can be complex and require a significant investment of time to learn and implement.

But not all DI frameworks are created equal. If you’re looking for a straightforward, Kotlin-first solution, let me introduce you to Koin.

Koin is a lightweight dependency injection framework designed specifically for Kotlin and Kotlin Multiplatform projects. Whether you’re building an Android app, a multiplatform project, or even a backend with Ktor, Koin has you covered. Developed by Kotzilla and a vibrant open-source community, Koin is known for its simplicity, minimal setup, and intuitive syntax.

If you want to streamline your Android architecture with as little boilerplate as possible, Koin is an excellent choice. Let’s walk through how you can implement Koin in your next Android project.

Step 1: Add Koin to Your Project
First, add the Koin dependency to your app-level build.gradle file

implementation "io.insert-koin:koin-android:3.5.3

(Be sure to check for the latest version before adding.)

Step 2: Create Your Classes
Let’s set up a simple example with a repository and a ViewModel:

class LocationRepository {
    fun getLocation(): String = "Dubai"
}

class LocationViewModel(private val repository: LocationRepository) {
    fun getLocation() = repository.getLocation()
}

Step 3: Define Koin Modules
A Koin module tells the framework how to provide your dependencies. Here’s how you can define one for a network client, repository, and ViewModel:

val appModule = module {
    single { NetworkClient() }
    single { LocationRepository(get()) }
    viewModel { LocationViewModel(get()) }
}

single creates a singleton instance.
viewModel is a Koin extension for providing ViewModels.
Step 4: Initialize Koin in Your Application Class
Next, set up Koin in your Application class:

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

And don’t forget to declare your custom Application class in your AndroidManifest.xml:

<application
    android:name=".MyApp"
    ... >
</application>

Step 5: Inject Dependencies Where You Need Them
Now, you can inject your dependencies directly into your Android components. For example, in an Activity:

class MainActivity : AppCompatActivity() {
private val viewModel: LocationViewModel by inject()
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        println(viewModel.getLocation())
    }
}

Wrapping Up
Koin brings a modern, pragmatic approach to dependency injection in Android. Its concise syntax, absence of code generation, and seamless Kotlin integration make it a favorite for developers who value simplicity and maintainability. By following these steps, you can quickly set up Koin and enjoy cleaner, more modular code in your Android projects.

Ready to take your architecture to the next level? Give Koin a try in your next Android app-you might just wonder how you ever coded without it.

That’s all for now. Happy coding, and see you in the next article!