How to Implement Room Database CRUD in Android with RecyclerView (Step-by-Step Kotlin Guide)

In this blog, we will learn how to implement complete CRUD (Create, Read, Update, Delete) operations using Room Database in Android with Kotlin. This guide covers a practical implementation using RecyclerView to display data and perform real-time updates.

We will build a simple user management feature where users can add, view, update, and delete records. The project uses modern Android development practices including Coroutines, LiveData for observing database changes, and a clean adapter-based RecyclerView setup.

By the end of this tutorial, you will understand how to:
Insert data into Room Database
Observe and display data using LiveData
Update existing records dynamically
Delete items directly from RecyclerView
Structure your code for better scalability

class RoomDatabaseActivity : AppCompatActivity() {
    private lateinit var binding: ActivityRoomDatabaseBinding
    private lateinit var db: AppDatabase

    private lateinit var userAdapter: UserAdapter
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        binding = DataBindingUtil.setContentView(this, R.layout.activity_room_database)
        ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main)) { v, insets ->
            val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
            v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom)
            insets
        }
        initView()
    }

    private fun initView() {
        db = DatabaseBuilder.getInstance(this@RoomDatabaseActivity)

        userAdapter = UserAdapter(onDelete = { userData ->
            lifecycleScope.launch {
                db.userDao().deleteUser(userData)
            }
        }, onUpdate = { userData ->
            lifecycleScope.launch {
                db.userDao().updateUser(
                    userData.copy(name = userData.name + " Updated")
                )
            }
        })

        binding.rvUser.adapter = userAdapter
        binding.rvUser.layoutManager = LinearLayoutManager(this)

        binding.btnSubmit.setOnClickListener {
            if (binding.edtAge.text.toString().isNotEmpty() && binding.edtName.text.toString()
                    .isNotEmpty()
            ) {
                lifecycleScope.launch {

                    db.userDao().insertUser(
                        User(
                            name = binding.edtName.text.toString().trim(),
                            age = binding.edtAge.text.toString().toInt()
                        )
                    )
                }
            } else {
                Toast.makeText(this, "Enter Name & Age", Toast.LENGTH_SHORT).show()
            }
        }

        lifecycleScope.launch {
            db.userDao().getAllUsers().observe(this@RoomDatabaseActivity) { userList ->
                userAdapter.setData(userList)
            }
        }
    }
}

implement Room Database in Android with Kotlin, including Entity, DAO, CRUD operations, and a singleton database setup using best practices.

Database class

@Database(entities = [User::class], version = 1)
abstract class AppDatabase: RoomDatabase() {
    abstract fun userDao(): UserDao
}

User Table(Model)

@Entity(tableName = "user_table")
data class User(
    @PrimaryKey(autoGenerate = true)
    val id: Int = 0,
    val name: String,
    val age: Int
)

UserDao Class

@Dao
interface UserDao {
    // CREATE
    @Insert
    suspend fun insertUser(user: User)

    // READ
    @Query("SELECT * FROM user_table")
    fun getAllUsers(): LiveData<List<User>>

    // UPDATE
    @Update
    suspend fun updateUser(user: User)

    // DELETE
    @Delete
    suspend fun deleteUser(user: User)
}

Create Database Instance


object DatabaseBuilder {
    private var INSTANCE: AppDatabase? = null

    fun getInstance(context: Context): AppDatabase {
        return INSTANCE ?: synchronized(this) {
            val instance = Room.databaseBuilder(
                context.applicationContext,
                AppDatabase::class.java,
                "user_db"
            ).build()
            INSTANCE = instance
            instance
        }
    }
}

Adapter For Display Data

class UserAdapter(
    private val onDelete: (User) -> Unit,
    private val onUpdate: (User) -> Unit
) : RecyclerView.Adapter<UserAdapter.ViewHolder>() {
    private var list = ArrayList<User>()

    fun setData(data: List<User>) {
        list.clear()
        list.addAll(data)
        notifyDataSetChanged()
    }

    override fun onCreateViewHolder(
        parent: ViewGroup,
        viewType: Int
    ): ViewHolder {
        val binding =
            ItemUserDesignBinding.inflate(LayoutInflater.from(parent.context), parent, false)
        return ViewHolder(binding)
    }

    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        val itemData = list[position]
        holder.setData(itemData, onDelete, onUpdate)

    }

    override fun getItemCount(): Int {
        return list.size
    }

    class ViewHolder(private val binding: ItemUserDesignBinding) :
        RecyclerView.ViewHolder(binding.root) {
        fun setData(itemData: User, onDelete: (User) -> Unit, onUpdate: (User) -> Unit) {
            binding.tvName.text = itemData.name
            binding.tvAge.text = itemData.age.toString()

            binding.btnDelete.setOnClickListener {
                onDelete(itemData)
            }

            binding.btnUpdate.setOnClickListener {
                onUpdate(itemData)
            }
        }
    }
}

This guide demonstrates how to implement Room Database in Android using Kotlin. It covers creating an Entity to define the table structure, a DAO for handling CRUD operations, and a Database class to manage data access.

A singleton pattern is used to ensure a single instance of the database throughout the app. LiveData is utilized to observe data changes and automatically update the UI, making the app more reactive and efficient.

Overall, this setup provides a simple and scalable approach to local data storage in Android applications.

Trying to solve a frustrating problem: why is debugging AI systems still so unclear?

I’ve been thinking about something that keeps coming up when working with AI systems. When a model gives a wrong or weird output, it’s surprisingly hard to figure out what actually went wrong. Most of the time we’re digging through logs
or guessing where things broke.
As part of the AWS AI Ideas hackathon, I started building a concept called AutopsyAI. The idea is to look at the full pipeline from input to output and try to explain where things might have failed, instead of just showing the final result. It’s still early and not a full product yet, more like an attempt to explore whether this problem is worth solving in a structured way.
Curious how others here deal with this. If you’ve worked with AI systems in production, how do you debug failures today? Does this feel like a real problem, or is it already solved better than I think?

Please do checkout my article and support it!
https://builder.aws.com/content/3AeXXMtLdDuPwRL4xcEjJEBoQkB/aideas-autopsyai-the-missing-debugger-for-ai-systems

Spider-Man fragman izle! Spider-Man Brand New Day fragman yayınlandı mı, nereden izlenir?

Sinema dünyasının en ikonik süper kahramanlarından biri olan Spider-Man, yeni filmi Spider-Man: Brand New Day ile yeniden gündemin merkezine yerleşti. Sony Pictures tarafından başlatılan kapsamlı tanıtım süreci, klasik fragman lansmanlarının ötesine geçerek küresel bir dijital etkinliğe dönüştü. Peki, Spider-Man Brand New Day fragman yayınlandı mı, nereden izlenir? Spider-Man fragman izle! Detaylar…

Same Framework, Different Engine: Porting AI Coding Workflows from Claude Code to Codex CLI

TL;DR

  • I built a sub-agent workflow framework for Claude Code that solved context exhaustion through specialized agents and structured workflows
  • For 8 months, Codex CLI had no sub-agents — the framework was Claude Code-only
  • Codex finally shipped sub-agent support — I expected days of migration, it took an afternoon
  • What surprised me most: if you design workflows around agent roles and context separation rather than tool-specific features, your investment survives platform shifts

The 8-Month Wait

Back in July 2025, I released the first version of this workflow as a Claude Code boilerplate. By October 2025, it had evolved into a full sub-agent framework — specialized agents for every phase of development, from requirements analysis through TDD implementation through quality gates. The idea was pretty simple: break complex coding tasks into specialized roles (requirement analyzer, technical designer, task executor, quality fixer…), give each agent a fresh context, and orchestrate them through structured handoffs. No single agent ever hits the context ceiling because no single agent tries to do everything.

The problem? Codex CLI had no sub-agent capability. Codex had been around since mid-2025, and I wanted the same workflow there too. So I kept trying to bridge the gap.

First, I built an MCP server in August 2025 that let any MCP-compatible tool — Codex, Cursor, whatever — define and spawn sub-agents through a standard protocol. It worked, but MCP added a layer of indirection that wasn’t there in Claude Code’s native sub-agents.

Then in December 2025, Codex shipped experimental Agent Skills support. I saw an opening and built sub-agents-skills — cross-LLM sub-agent orchestration packaged as Agent Skills, routing tasks to Codex, Claude Code, Cursor, or Gemini. Closer, but still not native sub-agents.

Through all of this, my main development stayed on Claude Code. The context separation and the small context windows of the time made it the clear choice for serious work. Codex filled a supporting role — I used it for skills refinement and as an objective reviewer on complex implementations, a fresh set of eyes from a different LLM.

I don’t use hooks extensively — I prefer keeping tasks small and baking quality gates into the completion criteria themselves. So what I was really waiting for was native sub-agent support in Codex, which would let the full orchestration workflow run without workarounds.

On March 16, 2026, Codex CLI shipped sub-agent support. During pre-release validation, I noticed something encouraging: Codex followed the workflow stopping points more strictly than expected. If the behavior stabilizes, it could be a viable primary development tool, not just a supporting one.

The port took almost no effort.

What “Near-Zero Migration” Actually Looks Like

When I say “the same framework,” I mean it. The core architecture didn’t change:

User Request
    ↓
requirement-analyzer → scale determination [STOP for confirmation]
    ↓
technical-designer → Design Doc
    ↓
document-reviewer [STOP for approval]
    ↓
work-planner → phased task breakdown [STOP]
    ↓
task-decomposer → atomic task files
    ↓
Per-task 4-step cycle:
  task-executor → escalation check → quality-fixer → git commit

22 sub-agents. 26 skills. The same stopping points, the same quality gates, the same TDD enforcement.

What changed was the container format, not the content:

Aspect Claude Code Codex CLI
Agent definitions Markdown with YAML frontmatter (agents/*.md) TOML files (.codex/agents/*.toml)
Skills location skills/ .agents/skills/
Tool declarations Explicit in frontmatter (tools: Read, Grep, Glob...) Not needed (inferred from sandbox mode)
Skill references Comma-separated names [[skills.config]] arrays
Config directory .claude/ .codex/

That’s it. The agent instructions — the actual substance of what each agent knows and does — are the same. The workflow logic is the same. The quality criteria are the same.

Why This Worked: Design Decisions That Paid Off

It worked for a surprisingly simple reason — three choices I made early on:

1. Natural Language as the Interface Layer

Every sub-agent’s behavior is defined in natural language instructions, not in platform-specific tool calls. The requirement-analyzer isn’t wired to Claude Code’s Agent tool or Codex’s spawn_agent — it follows a written protocol: “Extract task type, determine scale (1-2 files = Small, 3-5 = Medium, 6+ = Large), identify ADR necessity, output structured JSON.”

This means the instructions work on any LLM-powered agent system that can read text and follow procedures. In practice, that turned out to be enough. The framework is fundamentally a set of well-written job descriptions, not a set of API integrations.

2. Context Separation as Architecture

The core insight from the original article still applies: each agent runs in a fresh context without inheriting bias from previous steps. The document-reviewer doesn’t know what the technical-designer was “thinking” — it just reviews the output. The investigator explores without confirmation bias from whoever reported the bug.

This isn’t a Claude Code feature or a Codex feature. It’s an architectural pattern that happens to be implementable on both platforms once they support sub-agents.

3. Structured Handoffs Over Shared State

Agents communicate through artifacts (documents, JSON outputs, task files), not through shared memory or conversation threading. The technical-designer writes a Design Doc. The work-planner reads that Design Doc. Neither needs to know which platform spawned the other.

docs/
├── prd/          # PRD artifacts
├── adr/          # Architecture decision records
├── design/       # Design documents
├── plans/        # Work plans
│   └── tasks/    # Atomic task files (1 commit each)

This file-based protocol turned out to be surprisingly platform-agnostic.

The Framework in Action

codex-workflows ships as an npm package:

npx codex-workflows install

This drops the full agent and skill infrastructure into your project. From there, you invoke recipe skills that orchestrate the sub-agents:

Recipe What It Does
$recipe-implement Full lifecycle: requirements → design → implementation → quality
$recipe-design Requirements → design documents only
$recipe-build Execute pre-planned tasks autonomously
$recipe-diagnose Problem investigation → root cause → solutions
$recipe-front-build React/TypeScript implementation with frontend-specific agents
$recipe-fullstack-implement Cross-layer features with layer-aware task routing

Each recipe automatically loads the right foundational skills (coding standards, testing principles, documentation criteria) and spawns the right sequence of agents with the right stopping points.

Here’s what a real session looks like. I ran $recipe-implement Add a login screen with email/password and a simple auth API in Codex CLI against a fresh project with placeholder files:

1. Requirement analysis — the first mandatory stop:

• Spawned Plato [requirement-analyzer] (gpt-5.4-mini medium)

• Updated requirement analysis is now confirmed:
  - Scope: email/password login form, local mock auth abstraction,
    hardcoded success credentials [email protected] / password123,
    inline success message only
  - Route: fullstack
  - Scale: medium
  - ADR: not required

  Please confirm this analysis and answer these three questions:
  1. Should the auth API be a real HTTP endpoint, or is a local/mock
     API abstraction enough?
  2. What credentials should succeed initially?
  3. On successful login, should it only show success, navigate
     somewhere, or persist auth state too?

The workflow stops and waits. No implementation starts until I confirm scope.

2. Parallel design — backend and frontend at the same time:

• Spawned Volta [technical-designer] (gpt-5.4-mini medium)
  └ Create a backend Design Doc...

• Spawned Pasteur [technical-designer-frontend] (gpt-5.4-mini medium)
  └ Create a frontend Design Doc...

• Spawned Epicurus [document-reviewer] (gpt-5.4-mini medium)
  └ Review login-backend-design.md...

• Spawned Bohr [document-reviewer] (gpt-5.4-mini medium)
  └ Review login-frontend-design.md...

• Spawned Euclid [design-sync] (gpt-5.4-mini medium)
  └ Verify consistency between Design Docs...

Five agents in parallel: two designers, two reviewers, one cross-layer sync checker. Each running in its own fresh context.

3. Design gate — another mandatory stop:

• The design gate is now clean enough to stop for approval.

  - Backend design: approved
  - Frontend design: approved
  - Cross-layer sync: NO_CONFLICTS

  Aligned contract:
  - Success: { ok: true }
  - Failure: { ok: false, error }
  - Inline success copy is UI-owned, not backend-owned

  Please approve the design docs so I can move to
  acceptance-test generation and the work plan.

4. Autonomous execution after batch approval:

› batch approval

• Spawned Ohm [task-decomposer] (gpt-5.4-mini medium)

• Verification passed:
  - npm test
  - npm run build

After batch approval, the framework decomposed the work plan into tasks and executed them autonomously — no more stopping points until the quality gates pass.

The whole flow from $recipe-implement to green tests took one session. The same flow, the same stopping points, the same agent roles that I’ve been running on Claude Code for months.

Getting Started

The framework is open source:

If you’re already using the Claude Code version, the Codex version follows the same patterns. If you’re new to both, pick whichever CLI you’re already using — the workflow knowledge transfers either way.

npx codex-workflows install

The whole port changed config file formats and directory conventions. The agent instructions — the part that actually matters — didn’t need a single edit. That’s the thing I’d want to know if I were deciding whether to invest time in workflow design for AI coding tools.

If you’ve been running sub-agent workflows with either Claude Code or Codex CLI, I’d be curious how your setup compares. What worked? What broke?

Low Code

Quick Picks

Use Case Best Choice Why
Backend-as-a-service PocketBase Single binary with auth, database, file storage, and realtime API
Internal tool builder Appsmith Drag-and-drop UI builder connecting to any database or API
Full app platform Budibase Database, UI builder, automations, and hosting in one package
Spreadsheet → database NocoDB Turn any SQL database into a collaborative spreadsheet interface

Why Self-Host Low-Code?

Firebase costs scale unpredictably. Retool charges $10-50/user/month. Airtable is $20/seat/month. Supabase’s free tier limits you, and paid starts at $25/month. Self-hosted low-code platforms give you the same rapid development capabilities — databases, APIs, UI builders, auth — without per-user pricing or vendor lock-in. For internal tools, prototypes, and small apps, the cost savings are significant.

The Full Ranking

1. PocketBase — Best Backend-as-a-Service

PocketBase is a Firebase alternative in a single Go binary. It provides a SQLite database with a REST API, real-time subscriptions, file storage, authentication (email/password, OAuth2), and an admin dashboard — all in one 15 MB executable. No Docker required (though Docker works fine). No dependencies. No configuration files.

The developer experience is exceptional: define your data schema in the admin UI, and a full CRUD API appears instantly. Client SDKs for JavaScript/TypeScript make frontend integration trivial.

Pros:

  • Single binary — no dependencies, no configuration
  • SQLite database with auto-generated REST API
  • Real-time subscriptions via SSE
  • Built-in auth (email, OAuth2, admin)
  • File storage with thumbnails
  • Admin dashboard for schema management
  • JavaScript/Dart SDKs
  • Extremely lightweight (~15 MB binary, ~20 MB RAM)

Cons:

  • SQLite only (not suited for high-concurrency writes)
  • Single-server only (no clustering)
  • Relatively new (less enterprise-proven)
  • Limited plugin ecosystem
  • No built-in UI builder

Best for: Solo developers and small teams building apps, prototypes, or backends without infrastructure overhead.

[Read our full guide: How to Self-Host PocketBase]

2. Appsmith — Best Internal Tool Builder

Appsmith lets you build internal tools by dragging UI widgets onto a canvas and connecting them to databases (PostgreSQL, MySQL, MongoDB) and APIs (REST, GraphQL). No frontend code — just configure data sources, drag buttons and tables, and write JavaScript for logic. It’s the self-hosted equivalent of Retool.

Pros:

  • Drag-and-drop UI builder (50+ widgets)
  • Connect to any database or API
  • JavaScript for business logic
  • Git-based version control
  • Role-based access control
  • Audit logging
  • Template gallery for common tools
  • Active development

Cons:

  • Requires MongoDB + Redis
  • Heavier resource usage (~500 MB RAM)
  • UI builder has a learning curve
  • Some advanced features are enterprise-only
  • Not for public-facing apps (designed for internal tools)

Best for: Building admin panels, CRUD dashboards, and internal tools without writing frontend code.

3. Budibase — Best Full App Platform

Budibase combines a database, UI builder, and automation engine in one platform. Create tables (or connect to external databases), design screens, add automations (triggered by data changes, webhooks, or schedules), and deploy apps — all from a single web interface. It’s the most complete self-hosted low-code platform.

Pros:

  • Built-in database + external database connections
  • UI builder with responsive design
  • Automation engine (triggers, actions, conditions)
  • Role-based access control
  • REST API for each app
  • App publishing with custom domains
  • Active open-source development

Cons:

  • Requires CouchDB + MinIO + more services
  • Complex Docker setup (5+ containers)
  • Resource-heavy (~1 GB RAM for the full stack)
  • Newer project — still maturing
  • Some automations limited in the free edition

Best for: Teams building complete internal applications with data, UI, and automation.

4. NocoDB — Best Spreadsheet Interface

NocoDB turns any MySQL, PostgreSQL, or SQLite database into a collaborative Airtable-like spreadsheet. Connect your existing database and browse data through grid views, form views, kanban boards, and gallery views. It doesn’t replace your database — it adds a user-friendly layer on top.

Pros:

  • Connects to existing databases (no migration needed)
  • Grid, kanban, gallery, and form views
  • Filters, sorts, and grouping
  • API auto-generated for each table
  • Collaborator roles and permissions
  • Webhook automations
  • Lightweight

Cons:

  • Not a full app builder (no custom UI screens)
  • Limited automation compared to Budibase
  • Complex formulas less powerful than Airtable
  • Requires an existing database or uses internal SQLite

Best for: Teams who need a friendly interface for existing databases without building a custom admin panel.

Comparison Table

Feature PocketBase Appsmith Budibase NocoDB
Primary use Backend-as-a-service Internal tool builder Full app platform Database UI
Database Built-in (SQLite) Connect to external Built-in + external Connect to external
UI builder No (API only) Yes (drag-and-drop) Yes (pages/screens) Views (grid, kanban)
Auth Built-in (email, OAuth2) Built-in (RBAC) Built-in (RBAC) Built-in (roles)
Real-time Yes (SSE) No No Via webhooks
Automations No Workflows Yes (trigger-based) Webhooks
API Auto-generated REST Per-app Per-app REST Auto-generated
File storage Built-in Via integration Via MinIO Via attachment field
Docker support Optional (single binary) Official Official Official
RAM usage ~20 MB ~500 MB ~1 GB ~200 MB
License MIT Apache 2.0 GPL-3.0 (v2) AGPL-3.0

Honorable Mentions

  • ToolJet — Similar to Appsmith (internal tool builder with drag-and-drop). Good alternative if Appsmith doesn’t fit your workflow.
  • Directus — API-first headless CMS that wraps any SQL database. Overlaps with NocoDB but adds more content management features.
  • Strapi — Headless CMS with a content type builder. More CMS than low-code, but useful for content-driven apps.

How to Choose

Need a backend for your app? PocketBase. Single binary, instant API, minimal ops.

Building internal tools? Appsmith. Drag widgets, connect data, ship.

Full app with data + UI + automation? Budibase. Most complete self-hosted low-code platform.

Friendly interface for existing databases? NocoDB. Airtable experience on your own data.

Related

FREE AI CODE ASSISTANTS THAT ACTUALLY WORK 4

Ollama open source models

PART 4 OF 5: The Privacy-First Local AI Tools

5 Free AI Code Assistants – Tools That Auto-Complete, Refactor & Debug Your Code

Not everyone wants their code sitting on someone else’s server. Whether it’s company policy, client confidentiality, or you just don’t love the idea of your codebase training someone’s model — this part is for you.

These tools run locally or give you full control over your data. And yes, they’re still free.

16.Ollama + Continue.dev

This combo is the ultimate free local AI setup. Ollama lets you run open-source models like CodeLlama, DeepSeek Coder, or Mistral right on your own machine. Pair it with Continue.dev in VS Code and you have a fully offline AI code assistant that rivals paid tools. Your code never leaves your computer. Full stop.

Ollama open source models

Using Continue with ollama guide

17.LM Studio

LM Studio gives you a beautiful desktop app to download and run AI models locally. It has a built-in chat interface and an OpenAI-compatible local server, which means you can connect it to tools like Continue or any app that supports custom API endpoints. Great for non-technical setup. Just click, download a model, and go.

LmStudio free

Try it out

18.Tabby (Open Source)

Tabby is a self-hosted AI coding assistant. You deploy it on your own machine or server and it gives you GitHub Copilot-style completions without any data leaving your environment. It supports VS Code and JetBrains and has a clean dashboard to monitor usage. A little more setup involved but totally worth it for teams with privacy requirements.

Tabby ai coding assistant

Try it out

19.FauxPilot
This is an open-source, self-hosted alternative to GitHub Copilot. It uses the same API format as Copilot, which means it drops right into editors that already support Copilot. You run it on your own hardware, pick your own model, and get real-time completions with zero cloud dependency. Requires a decent GPU to run smoothly.

FauxPilot github copilot Open source alternative

Try it out

20.CodeGeeX (Free)

CodeGeeX is an open-source multilingual code generation tool developed by Tsinghua University. It runs locally, supports over 100 programming languages, and has a VS Code plugin that’s easy to set up. It’s not as well-known in the Western dev community but the code quality is solid and the privacy story is clean.

CodeGeeX

Try it out

Part 4 wrapped! Last one coming up. Part 5 covers the most exciting new wave of AI coding tools that are just starting to gain traction. These are the ones to watch in 2025 and beyond.