DEV Community: Nasir

A Beginner’s Introduction to Widgets in Flutter

Nasir — Sat, 11 Jul 2026 12:22:38 +0000

Flutter widgets

A Beginner’s Introduction to Widgets in Flutter

Welcome, fresh meat. Today, we’ll be talking about what widgets really are, so you can get a new perspective because being told that “Everything is a widget” is a really vague description, don’t you think? That’s why I’m here to do my best to demystify them.

Dart Classes

Coming from a web dev background, the concept of widgets is gonna hit harder than a truck moving at relativistic speeds (ok, that’s a bit too much, but you get the point). I want you to just drop your current mental models of widgets for a bit, except if they're already solid.

At its core, a widget is an instance of a class or in more formal terms, an object. Flutter works hand in hand with the Dart programming language but with a twist. Enough talking, let’s create our own class to see the concept in action.

class Player {
  final String name;
  final int health;

 const Player({
  required this.name,
  required this.health,

  });
}

Create a new file called player.dart, then let’s talk about the code above.

Note: That Player class isn’t a Widget, just a normal Dart class.

Classes in Dart begin with writing the “class” keyword followed by the name of the class then a set of curly braces. Classes have variables called parameters — they’re essentially the things that describe or give us info about the class. In Dart, we use the “final” keyword when we’re very sure we are not going to use the assigning operator “=”(it’s the equal sign for assigning values to variables) to change the value of that parameter.

Then there’s that “const Player({}).” part of the code. That is something called a constructor. A constructor is a function that runs immediately a class is initialized, we’ll talk about initialization soon. The “required” keyword means the constructor will not run unless you pass in arguments for each of its parameters. To top it all off, the “this” keyword is referring to the class itself which in our case is Player. So when we write this.name, we’re actually referring to Player.name, etc.

Initialization Of Classes

So, you’ve made a class, but how do you actually use it, you ask? This isn’t a widget that allows us to draw things in the UI, but we’re gonna use a workaround. Just a heads-up, but, Flutter won’t allow you to directly write anything other than a widget in the UI. Let’s create a new page called home_page.dart:

import 'package:flutter/material.dart';
import 'package:widget_article/player.dart';
class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Player(name: "Nasir", health: 50)
    );
  }
}

If you put that in your code editor, you’ll receive an argument error. The body parameter of the Scaffold widget expects a widget and anything else gets rejected. So how do we go about this? Well, we use something called an IIFE or Immediately Invoked Function Expression.

Don’t panic it’s actually an intuitive name for this expression when we break it down. An IIFE has this structure:

import 'package:flutter/material.dart';
import 'package:widget_article/player.dart';
class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override 
  Widget build(BuildContext context) {
    return Scaffold(
      body:(){}()
    );
  }
}

The thing is, when you create a function, it’s dormant until you “call” or as it’s generally called “Invoke” it. When we wrote Player(”Nasir”, 50), we invoked the constructor function. Before we did that, the constructor function wasn’t doing anything.

import 'package:flutter/material.dart';
import 'package:widget_article/player.dart';
class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override 
  Widget build(BuildContext context) {
    return Scaffold(
      body:(){
        final player = Player(name: "Nasir", health: 10000000);
       return Text(player.name + player.health.toString());
      }()
    );
  }
}

With the IIFE, we can write logic, assign variables and just do normal coding and then directly assign widgets the variables we made. In the IIFE we made, we created an instance of the Player class we made called player then passed the hardcoded parameters, name and health to a text widget so we can actually see it in our UI (Heh, wondering why my health increased from 50 to that large number? I levelled up big time).

Note: Technically, you could just declare the player variable in the build method right above the Scaffold widget, but…After a few variables, you’ll get what I like to call “variable hell” in your build method.

Actual Widgets

Well, using Dart classes in our UI required quite the setup, but actual custom widgets just make life easier, when it comes to drawing stuff in the UI at least. Now, you might ask, “Why create custom widgets when we can just use the standard ones Flutter offers”, and the answer is simple “To be lazy”.

As developers, we hate repetition, as it deprives us of room to be lazy. Enough talking, let me explain with an illustration. Let’s create a nice-looking container in our home_page.dart file:

import 'package:flutter/material.dart';

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override 
  Widget build(BuildContext context) {
    return Scaffold(
      body:Column(
        children: [
         Container(
          width: 200,
          height: 100,
          padding: EdgeInsets.all(8.0),
          decoration: BoxDecoration(
            color: Colors.blue,
            borderRadius: BorderRadius.circular(12.0)
          ),
          child: Center(
              child:Text(
            "Overly-styled box",
            style: TextStyle(color: Colors.white)
          )),
         ),
        ],
      )
    );
  }
}

Also, don’t forget to make sure your main.dart file looks something similar to this:

import 'package:flutter/material.dart';
import 'package:widget_article/home_page.dart';
void main(){
  runApp(
    MaterialApp(
      home: HomePage(),
    )
  );
}

Wow, that’s a really nice box. But what if we need five more? We’d have to copy and paste our Container widget five more times. Yeah, your home_page.dart would get bloated and wouldn’t be clean in any way whatsoever; that’s why we create a custom widget.

Create a new file called overly_styled_box.dart like so:

import 'package:flutter/material.dart';
class OverlyStyledBox extends StatelessWidget {
  const OverlyStyledBox({super.key});

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

I don’t want to talk about the technical side of this too much so I’ll explain the key things you need to know for now. When creating custom widgets, about 80% of the time, they’ll always be StatelessWidgets. Think about Stateless Widgets as widgets that don’t have variables in their build method for now. You can assign them parameters because they’re just glorified classes that return widgets directly, so we don’t have to use IIFEs.

Using Custom Widgets In The UI

So, we’ve made our custom widget, but it returns a plain container — let’s change that by making it return our overly-styled box. Just copy and paste the container inside our home_page.dart file and paste it like so:

import 'package:flutter/material.dart';
class OverlyStyledBox extends StatelessWidget {
  const OverlyStyledBox({super.key});

  @override
  Widget build(BuildContext context) {
    return  Container(
          width: 200,
          height: 100,
          padding: EdgeInsets.all(8.0),
          decoration: BoxDecoration(
            color: Colors.blue,
            borderRadius: BorderRadius.circular(12.0)
          ),
          child: Center(
              child:Text(
            "Fancy box",
            style: TextStyle(color: Colors.white)
          )),
         );
  }
}

Now that we have our complete custom container, we can delete the ugly container in our main.dart and replace it with an instance of OverlyStyledBox:

import 'package:flutter/material.dart';
import 'package:widget_article/overly_styled_box.dart';

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override 
  Widget build(BuildContext context) {
    return Scaffold(
      body:Column(
        children: [
        OverlyStyledBox()
        ],  
      )
    );
  }
}

Isn’t it just beautiful? Well, not more beautiful than me, but you get the point. It makes our code look so clean. But what if we want to change the color or text of each OverlystyledBox? Our current setup hardcodes everything, but this is where your newly-attained knowledge of Dart classes comes in.

We’ll create two parameters for the OverlyStyledBox so we can pass in different arguments.

import 'package:flutter/material.dart';
class OverlyStyledBox extends StatelessWidget {
  final String text;
  final Color backgroundColor;
  const OverlyStyledBox({
    super.key,
    required this.text,
    required this.backgroundColor
    });

  @override
  Widget build(BuildContext context) {
    return  Container(
          width: 200,
          height: 100,
          padding: EdgeInsets.all(8.0),
          decoration: BoxDecoration(
            color: backgroundColor, //Replaced "Colors.blue" with the backgroundColor parameter
            borderRadius: BorderRadius.circular(12.0)
          ),
          child: Center(
              child:Text(
            text, //Replaced "Fancy box" with the text parameter
            style: TextStyle(color: Colors.white)
          )),
         );
  }
}

Now, our OverlyStyledBox expects two arguments for its color and text parameters, so you’ll probably wanna check the home_page.dart file because, it won’t work unless you pass in the required arguments.

Note: Remember to always save your pages/files after every new change.

import 'package:flutter/material.dart';
import 'package:widget_article/overly_styled_box.dart';

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override 
  Widget build(BuildContext context) {
    return Scaffold(
      body:Column(
        children: [
        OverlyStyledBox(text: "Fancy Box 1", backgroundColor: Colors.red,),
        SizedBox(height: 8,),
        OverlyStyledBox(text: "Fancy box 2", backgroundColor: Colors.purple)
        ],  
      )
    );
  }
}

Now, we can customize the text in the container and background color without writing any more boilerplate. I mean, just look at this:

I hope you were able to follow along and understand the basic concept of widgets in Flutter. Congratulations, you are now 10x lazier and can make reusable widgets with ease for your next projects. If this article helped, drop a comment! See you soon!

Search Bars in Flutter

Nasir — Fri, 10 Jul 2026 08:07:49 +0000

How To Make A functioning Search Bar in Flutter

So, you wanna make a search bar huh? Well you’re in luck, because, I’m going to guide you through just that. I know we all know what search bars are, but let’s look at what they really do, and how they do it.

The Search Bar

At its core, a search bar dynamically “filters” a list. Yeah, that’s it. Let’s dive into the code. We’ll be searching through a list of fruits that we’ll store in hive, so let’s go ahead and make a basic search bar.

import 'package:flutter/material.dart';
class MySearchBar extends StatelessWidget {
  const MySearchBar({
    super.key,
    });

  @override
  Widget build(BuildContext context) {
    return TextField(
    decoration: InputDecoration(
     labelText: "Search",
     focusedBorder: OutlineInputBorder(borderSide: BorderSide(color: const Color.fromARGB(255, 29, 253, 36))),
     border: OutlineInputBorder(borderSide: BorderSide.none),
     enabledBorder: OutlineInputBorder(),
     prefixIcon: Icon(Icons.search)
    ),
    );
  }
}

So this is the structure of our custom search bar. In the inputDecoration of a textField, there are borders you can set based on the state of the search bar, but in our case we’re only going to be using three of those borders.

Think of the border parameter as the default border that flutter gives us when we don’t explicitly style our textfield. It’s usually a boring underline widget so I set its borderSide to none. Think of borderSide as a term for the actual border around the textfield. The enabledBorder is a border we can style as we please and it’s the border we see before we even click on the search bar. To top it all off, the focusedBorder is the border we see when we actually click on the search bar which makes it “active”

Making The Search Bar Actually Search

Well a search bar that doesn’t search is just a bar(or something). You’ve probably noticed that when you search stuff on platforms, content is returned in real-time. In flutter, we can’t use just a normal list — we have to make our list alive so we can make changes and the UI updates without us having to go through reloading hell.

import 'package:flutter/material.dart';
import 'package:search_bar_article/custom_widgets/my_search_bar.dart';
class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
String searchQuery = ''; 
final ValueNotifier<List<String>> dynamicFruits = ValueNotifier(
  [
    "Apple",
    "Coconut",
    "Guava",
    "Banana"
  ]);
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(actions: [
    SizedBox(
      width: 200,
      child: MySearchBar())
      ],),
      body: Column(
        children: [

        ],
      ),
    );
  }
}

What’s that ValueNotifier thingy you ask? Well think of it as a special type of container that allows the UI to get redrawn immediately any change in the data it holds occur without us having to reload the app each time. — sorta like a stream. In our example, it’s storing a list of fruits (I’m no botanist so I probably added stuffs that aren’t fruits) that we’re going to display in our UI.

We need a string to capture the text from the search bar which we’ll call searchQuery and to make sure the searchQuery is equal to the text we are currently typing, we’re gonna need to add an onChanged function to MySearchBar. The onChanged function is at its core, a function that allows you to do stuff as the content inside the search bar changes or in layman’s terms, as you type.

import 'package:flutter/material.dart';
class MySearchBar extends StatelessWidget {
  final void Function(String) onChanged;
  const MySearchBar({
    super.key,
    required this.onChanged
    });

  @override
  Widget build(BuildContext context) {
    return TextField(
      onChanged: onChanged,
    decoration: InputDecoration(
     labelText: "Search",
     focusedBorder: OutlineInputBorder(borderSide: BorderSide(color: const Color.fromARGB(255, 29, 253, 36))),
     border: OutlineInputBorder(borderSide: BorderSide.none),
     enabledBorder: OutlineInputBorder(),
     prefixIcon: Icon(Icons.search)
    ),
    );
  }
}

What “final void Function(String) onChanged;” means is this a void function i.e it doesn’t return anything, but, it accepts a String as an argument. If the function didn’t have any parameters, we wouldn’t need to write Function(String) and we’d just use a VoidCallBack instead.

 child: MySearchBar(onChanged: (value){
        setState(() {
          searchQuery = value;
        });
      },))

We have to add an onChanged function to MySearchBar or we’ll get an error about incomplete parameters. In the onChanged function, that variable value is the live text in our search bar so we use setState to update our searchQuery string to the value each time you type in the search bar.

Setting up the UI

Phew…..well that was quite the long section, but this is where the real fun starts.

 body: Column(
        children: [
       Expanded(child: ValueListenableBuilder(
        valueListenable: dynamicFruits, 
        builder: (context, value, widget){
      final filteredFruits = value.where((fruit){
        final fruitMatch = fruit.toLowerCase().contains(searchQuery.toLowerCase());
        if (searchQuery.isEmpty){
          return true;
        }
        return fruitMatch;
      }).toList();
          return ListView.builder(
          itemCount: filteredFruits.length,
          itemBuilder: (context, index) {
            final fruit = filteredFruits[index];
            return Container(
              width: 400,
              decoration: BoxDecoration(
                color: Colors.grey
              ),
              child: Text(fruit),
            );
          }));
        }))
        ],
      ),

We used a ValueListenableBuilder as it allows the UI to redraw each time the dynamicFruits list changes. Our list of fruits won’t change unless we filter it by using the .where() method.

The .where() method accepts a callback which must have an argument. The argument corresponds to each element in our list and in our case, strings. We create a Boolean called fruitMatch and all that does is it looks at the name of the fruit in lowercase (That’s why we used the .toLowerCase method) and checks if it “contains” the searchQuery in lowercase (That explains the .contains method). You might probably wondering why we have to convert dynamicFruits and the searchQuery to lowercase, and that’s because strings are case-sensitive; “Apple” and “apple” are two different strings so that’s why we used the .toLowerCase method. So by returning the fruitMatch Boolean, the .where method will effectively filter out elements that match our query but we have to return true if searchQuery is empty so that it’ll return all the elements. Then we hook that bad boy to a ListView builder so we can see our data in the UI.

Congratulations, you are now a searcher (its a word, I think) capable of creating functional search bars in your various apps. I hope you were able to add that search bar you’ve always wanted. Good luck!

How to create Data models and perform basic CRUD operations in Flutter with Hive

Nasir — Wed, 08 Jul 2026 16:17:15 +0000

Hive Tutorial

How to create Data models and perform basic CRUD operations in Flutter with Hive

Working with local databases can be a lot to take in, but making data models helps make things structured and easier to work with. A data model is essentially a class that defines the structure of your data. A data model can be literally anything, like Dog, Expense, Player, etc.

In Flutter, it all begins with installing these packages in your pubsec.yaml file: hive_flutter, hive in your dependencies, and build_runner, hive_generator in your dev_dependencies.

Now, hive_flutter and hive allow you to work with Hive, which, as you may or may not already know, is a local database that allows you to store directly on your device. while the build_runner allows us to create an essential “part” of the data model with the aid of the hive_generator, so Hive can store custom data.

After saving your YAML file, you’ll most definitely receive a dependency error, so all you have to do is change the version of the build runner to ^2.4.13, like so:

Setting up your code

To make our lives easier, we’re going to structure the architecture of our project like so:

Before we do anything at all, we need to do two very important things first

Setting up Hive
Creating the data model

Hive Setup

To setup hive, go to your main.dart file and make sure your main.dart looks something like this:

First of all, we add the async keyword to allow us to attach the await keyword so that the app doesn’t freeze while Hive is being set up, then WidgetsFlutterBinding.ensureInitialized() makes sure that Flutter has all its widgets ready before even setting up Hive.

Secondly, await Hive.initFlutter() actually initializes Flutter, and to top it all off, await Hive.openBox(”animalBox”) creates a new Table or “Box” as Hive calls it, which is where we’ll actually store instances of our data model. You can choose any name for your box, but it’s highly recommended to use a name that tells you what the box stores, so you don’t get confused later on.

Creating and “registering” the Data Model

In this section, we’ll be going through creating the Data model in question, so we’ll create an animal Data model, but before diving into the code, we need to identify some of the features that make an animal a well, umm, animal. Some features are the name, the sound they make, and the number of legs.

Create a new file in the models folder we made earlier called “animal_model.dart”. You can choose any name, but I like this because it’s really descriptive. Your animal_model.dart file should look like this:

Let’s take it from the top. That “part ‘animal_model.g.dart’” allows us to create the other essential “part” of the animal_model, so that Hive can store it, as Hive is usually used to store key-value pairs.

Note: The name of the file before the .g.dart must match the exact name of the model file, which in our case is “animal_model”

We create a basic class, but with some tweaks. The class must extend HiveObject so Hive knows that it isn’t the normal key-value pairs, but allows it to store it. The “@HiveType(typeId:0)” just tells Hive “Hey, this is a custom type of data, and since it’s the first of the custom types we created, we set its typeId to 0.”

In a normal class, we just list out its parameters, but since this is a HiveObject we have to explicitly tell Hive where to store these parameters of the Data model in the box, so we use “@HiveField” followed by the index of each parameter.

After all that’s outta the way, we use the build_runner to generate the animal_model.g.dart file, and don’t panic if you see red squiggly lines under part “animal_model.g.dart”. It’s all part of the process.

Open up your terminal (Heh, here’s a shortcut on windows. Ctrl+Shift+~) then type “dart run build_runner build”. You’ll see the .g.dart file inside the models folder we created. Before we proceed, if you encounter any error, just run “dart run build_runner build --delete-conflicting-outputs” and what this does is prevent the build_runner from generating corrupted code by ensuring it takes care of all redundant data.

Now, for the moment of truth. Go to your main.dart and “register” the model adapter. A TypeAdapter is just a fancy tool that turns our custom object/Data model into something that Hive can work with as if it were a normal value.

Note: It’s recommended to register your adapter before opening your box.

Performing basic CRUD operations.

CRUD or Create ,Read, Update, and Delete operations are the holy trinity of the database world or quadrinity(Definitely sure that’s not a word, but bear with me). To kick things off, we’ll create a new file in our services folder called hive_service.dart and this is where we’ll write out all the code that will allow us to perform CRUD operations on our box.

The createNewAnimal function has parameters name, sound and numberOfLegs which will serve as the arguments for the AnimalModel. We use Hive.box(”animalBox”) to get access to the box which we already opened in our main.dart file. Finally, we use box.add() to literally add a new instance of AnimalModel to our box.

To delete an instance, we use the box.deletAt() method to delete it based on its index in the box.

But hold up, that code above is ok, but not great. We’ll most likely run into issues later because we didn’t specify the data type of the box, or to be more precise, the data type of what it’s storing, which is our AnimalModel. We’ll also have to specify the data type in our main.dart file.

Hooking up Hive to the UI

The moment we’ve all been waiting for is finally here. I’d like to assume that we’ve already created the home_page.dart file I made earlier, but if we haven’t, here’s a structure you could follow:

Our current page is, well, empty, but that will change very soon. We’re going to be using something called a ValueListenableBuilder, and just think of it as a tool that allows you to access our hive box and its values. It also allows us to return widgets for each entry in the box.

….So umm here’s our UI….I know, I know, I have some explaining to do. We first of all create a parent column widget in order to resolve the spacing issues we’d get from our listview builder, but I’ll talk more about that soon.

The ValueListenableBuilder has two key parameters of interest to us: valueListenable, and our builder. The valueListenable allows us to set up a channel or a stream to our hive box by attaching .listenable() to it. This way, we can listen to real-time data from Hive without having to reload the app every time we wanna see a change in our box.

The builder is essentially a function that allows us to return widgets and gives us access to the listenable piece of data, which in our case, is our “animalBox” hive box. it takes three arguments which are, context, value(which is just our hive box, but we have to make sure we specify its data type), and widget.

We return a ListView builder so we can fetch live data into our UI with ease, and set the itemcount parameter to the length of the “animals” list we made. final animals = box.values.toList(); takes all the values of our hive box and returns them as a list in order to make our lives easier. The itembuilder parameter of the ListView builder essentially allows us to track each element of a list.

final AnimalModel animal = animals[index]; refers to each individual AnimalModel in our list, and we top it all off by using a listTile to return the parameters of each AnimalModel in the box.

Oh yeah, I did say that I would explain why we used a Column. You probably noticed I wrapped the ValueListenableBuilder in an “Expanded” Widget, and what this does is it ensures the ListView only takes the space available in the visible screen. In layman's terms, it prevents the ListView from stretching to infinity.

Congratulations, you have a working offline app capable of storing questionable stuff, but I hope you were able to get a grip on everything we’ve worked on so far. Run your main.dart file and see your app in action!!