When we were building Cenlo we needed a local database that could run seamlessly across desktop platforms. We had to make a choice between sqlite3 and sqflite. In this guide, I’ll break down the core differences between them, how they work under the hood, and the patterns we used to make our choice.

Contents

1. What is SQLite?

2. The Flutter way of implementing SQLite

3. The two approaches

5. How to choose

6. Closing statement

7. About the Author

What is SQLite?

SQLite is a relational database engine that gets embedded into an application’s code and runs without a server unlike other relational databases like PostgreSQL or MySQL. The actual data, tables, schemas etc. live inside a single portable binary (either .sqlite or .db) making it a perfect for running lightweight applications on edge hardware.

Fact: SQLite is the most deployed pieces of software with an estimated trillion active sqlite db instances running across all major operating systems. (Source)

Despite all the advantages of SQLite its biggest architectural drawback is one write at a time. Though, over the years the SQLite has had support for WAL (Write Ahead Logging) mode allowing for multiple readers but the single write constraint remains. None the less, that is not a problem when running SQLite locally which is exactly what this article is intended towards. Why is it not a problem running it locally? Well, when running locally it only processes actions from one device compared to thousands or millions of devices for applications running on client-server architecture. SQLite can handle such transactions with ease with extremerely rare occurences of hitting nail in the head.

Note: SQLite is also available for server and intrested readers can check out projects like turso or pocketbase (I intend to write about PocketBase in future).

The flutter way of implementing SQLite?

Coming towards Flutter implementing sqlite is easy. Install a package, initialize it in the main function, configure and you should be good to go. But thats not all, choosing which package to install is also important as there are multiple choices and these work differently under the hood. Two of them stand out particularly as these are the most prominent and well maintained namely sqlite3 and sqflite. Both of them have their own approaches towards how they integrate SQLite engine, their API’s, encryption support and most importantly support for asynchronous code execution.

We will look into both of them and by the end of this article you should be able to choose which one to use for your local-first flutter app (At least I hope so…)

The two approaches

sqflite: Sqflite is one of the most popular packages in the flutter ecosystem due to its developer friendly API and its asynchronous, non-blocking nature making it easier to integrate. It is beginner friendly and is a great choice if your application targets mobile operating systems i.e Android and iOS.

Under the hood, it utilizes platfrom channels to interact with the underlying SQLite engine. Due to its reliance on platform channels, bindings must be implemented and maintained separately for each operating system.

This architectural descision is responsible for the added friction when adding support for new platforms, which is why sqflite is currently limited to Android, iOS, and macOS only.

sqlite3: Sqlite3, on the other hand uses Dart’s FFI (Foreign Function Interface) allowing it to run natively across all platforms (even on the web via WASM). It is a wrapper over the native C bindings of SQLite making it highly performant and maintainable.

One drawback of the sqlite3 plugin is that it lacks asynchronous support out of the box, though this can be easily resolved by pairing it with the sqlite_async package. This does introduces some fiction as additonal configuration is required but is totally worth it if your application targets both desktop (Windows, macOS, Linux) and mobile (Android, iOS) or Web.

Its biggest downside, however, is its API , which prefers writing direct, raw SQL strings unlike sqflite, which uses of type-safe programmatic interface. This grants developers great level of control over the database execution, but is not developer friendly.

Its low level API is a big reason why sqlite3 is rarely used directly in flutter applications, instead it is used as a dependency of a highly popular ORM (Object Relational Mapper) Drift. (I intend to write about drift soon)

How to choose

If you ask me performance is not the reason I will make my choice, as forementioned in the article, a local-first application involves only a single device reading and writing to its own storage, data operations will still be exceptionally fast and transactions happen in the blink of an eye.

It actuallty narrows down to target platforms, ease of integration, and the level of control the developer requires.

1. Targeting by Platform (A Straightforward Choice)

• Mobile-Only (Android & iOS): Go with sqflite. It is easy to integrate, async by default and is battle-tested for mobile.
• Desktop or Cross-Platform (Desktop + Mobile): Go with sqlite3. Its Dart FFI layer ensures your database logic works seamlessly across Windows, Linux, and macOS without platform-specific friction.
• Web Integration: sqlite3 is your only choice.

2. Balancing Control and Integration: Getting the Best of Both Worlds

The ultimate dilemma lies in balancing ease of integration with granular control:

• sqflite gives you immediate ease of integration with its safe, async, programmatic API—but bounds you to mobile platforms.
• sqlite3 gives you absolute control over raw SQL and universal platform support—but forces you into a rigid, low-level, synchronous developer experience.

To truly get the best of both worlds make use of an ORM like drift. It builds upon sqlite3 and provides access to safe, developer-friendly, and non-blocking asynchronous API associated with sqflite ensuring smooth UI performance across all platforms. At the same time, it provides direct control over the database by allowing the execution of raw SQL strings using the customStatement API whenever complex or highly optimized queries are required.

We leveraged Drift + sqlite3 architecture when building local storage for Cenlo. It provided type safe api generation via build runner, execution of raw sql strings for higher degree of control and compatibility across platforms.

Closing statement

I hope this article clarifies the core differences between sqlite3 and sqflite, helping you choose the right fit for your next project. More importantly, the goal is to help developers shift their perspective away from database plugins or benchmarks toward high-level ecosystems like Drift which offer a more scalable architecture for modern, cross-platform apps.

With that, I will take your leave. Please drop your feedback or questions in the comment section below . I’d love to hear which database approach you are using for your apps! Thanks for reading the article, and I will see you in the next one.

About the Author

Hi I am Bhavesh, I am a Software Engineer and Flutter Developer. I love working with Flutter for developing cross platform apps. Its been a few months since I am working on Cenlo, its a time tracking application that is local first and uses machine learning models to classify user activity. I am passionate about local-first architecture, privacy-centric software and I enjoy exploring the evolving landscape of edge computing.

Local Persistant Storage in Flutter : Getting Started with HiveDB

Store data with local persistance in flutter apps with the help of hive database.

GitHub - isar/hive: Lightweight and blazing fast key-value database written in pure Dart.

Overview

I have used HiveDB for local persistant storage in many of my apps and it is one of my favorite storage soutions when it comes to ease of use. I recently noticed that the docs for HiveDB are down and are not accessible. The pacakge is not maintained anymore and was last updated 2 years ago(as of Oct 2024), yet has a popularity score of 100% and is one of the most used databases for local persistance storage.

Since the docs are down I thought of writing a Getting Started guide for HiveDB.

We will discuss about the following in this article

1. What is Hive Database?
2. Getting Started with Hive
3. Basic Hive Concepts
4. Generating TypeAdapters
5. Creating a simple Todo List app
6. Conclusion

What is Hive Database?

Hive is a lightweight, efficient NoSQL database specifically designed for local persistent storage for Flutter applications. It is a high performant database with a key-value storage model. This makes it appropriate for use in scenerios were quick data retrival is crucial. Hive allows creation of someting called as TypeAdapters which allow storing any type object, in addition to the primitive data types like List, Map, DateTime, BigInt and Uint8List that hive supports out of the box.

Getting Started with Hive

In order to use hive we need to add the following dependencies to the pubspec.yaml file

dependencies:
  analyzer: ^4.7.0
  flutter:
    sdk: flutter
  #hiveDB related packages
  hive: ^2.2.3
  hive_flutter: ^1.1.0

dev_dependencies:
  flutter_test:
    sdk: flutter
  #package to generate dart code
  build_runner: ^2.4.8
  #hive generator for generating type adapters
  hive_generator: ^1.1.0

Let’s first go through the dependencies

1. hive: The package required to use hive database
2. hive_flutter: This package makes it easier to use hive in flutter apps.
3. build_runner: This package is used to generate dart code.
4. hive_generator: This package is used to generate TypeAdapters which can be stored in hive boxes.

Next, we need to initialize hive in the main function

import 'package:flutter/material.dart';
import 'package:hive_flutter/hive_flutter.dart';

void main() async {
  //Initialize Hive
  await Hive.initFlutter();
  runApp(const MainApp());
}

This will initialize hive and will store the hive box in a valid directory which changes based on the operating system. By default, Hive is initialized in the application documents directory. We can optionally specify the directory in which Hive should be initialized.

await Hive.initFlutter('path_to_directory');

This is all the setup needed in order to start using hive. Just add all the required dependencies and use await Hive.initFlutter(); to initialize hive, that’s it.

Basic Hive Concepts

In order to work with hive we need to know about some basic hive concepts.

Hive Boxes

Hive stores data inside boxes in the form of key-value pair. We first need to open a hive box before storing any data. This can be done by using the openBox command

var todosBox = await Hive.openBox('todos');

This will create a hive box where we can store our data. If we navigate to the directory where we have initilized Hive we will notice a new file by the name of todos.hive. For example, if a windows application is launched, then the box files by the extension of .hive can be found in Documents dir. This is the file which will store all the key-value pairs.

Operations on Hive Boxes

We can easily perform CRUD(Create, Read, Update, Delete) operations on Hive Boxes.

  //Initialize Hive
  await Hive.initFlutter();

  // Open the box after initializing Hive
  var todosBox = await Hive.openBox('todos');
  
  //CREATE
  // Store title using put method by specifying the key and value to store
  todosBox.put('title', 'Football Match');
  debugPrint('Length: ${todosBox.length}');
  
  //READ
  // Retrive the title using get method by specifying the key
  var title = todosBox.get('title');
  debugPrint('Title : $title');

  //UPDATE
  // Update the title using the put method by specifying the key
  todosBox.put('title', 'Grocery Shopping');
  // Retrive the updated title using get by specifying the key
  title = todosBox.get('title');
  debugPrint('Updated title: $title');

  //DELETE
  // delete data using delete by specifying the key
  todosBox.delete('title');
  debugPrint('Length: ${todosBox.length}');

We have performed CRUD operations on todosBox using put(), get() and delete() methods. These methods all have a required parameter ‘key’ which is used to store and access data.

Hive also supports auto incrementing keys which allows storing data without specifying ‘key’, instead hive automatically generates incrementing indices and provides methods like add(), getAt(), putAt() and deleteAt() for CRUD operations.

We can strore any data in hive as long as we are storing primitive data types, but that’s no fun. What if we want to store some custom data? This is were TypeAdapters come into paly.

Generating TypeAdapters

Hive allows storing custom objects with the help of TypeAdapters, but creating TypeAdapters requires boilerplate code. Fortunately, we can make use of build_runner package to generate TypeAdapters with the help of hive_generator.

In order to generate TypeAdapers we need to do some setup. Let’s look at todo_model.dart.

//FILE: todo_model.dart
import 'package:hive/hive.dart';

//specify name of the part file which will be generated by hive_generator
part 'todo_model.g.dart';
 
//Specify the HiveType with a type id between 0 and 233
//NOTE: No two TypeAdapters can have the same typeId
@HiveType(typeId: 0)
class Todo {
  //Annotate class members with HiveField with each 
  //HiveField having incrementing index
  @HiveField(0)
  String title;
  @HiveField(1)
  String description;
  
  //Default value can be specified if needed
  @HiveField(3, defaultValue: false)
  bool isDone;
  
  Todo({
    required this.title,
    required this.description,
    this.isDone = false,
  });
}

Now, let’s breakdown the structure of todo_model.dart

First: We have specified the name that the generated file will have as todo_model.g.dart here ‘g’ specifies that it is a generated file.

Second: We have annotated the class with HiveType which takes an index. Every single class annotated with HiveType should have a unique index between 0 to 233

Third: We have annotated the class members with HiveField each having a incrementing index. Also we have specified defaultValue for isDone so if no value is provided isDone will default to false. HiveField can have a range of 0 to 255

That’s is thats all the code that we need for generating a TypeAdapter . Now, in order to generate a TypeAdapter type the below command in terminal window.

dart run build_runner build

After executing the command a file named todo_model.g.dart will be generated in the same folder as todo_model.dart . This file will contain the code generated by hive_generator package.

The file will have a class named TodoAdapter extending TypeAdapter<Todo> and all the logic that is required to convert data from and to binary. We do not need to know any more information about this file.

Next Up, in order to use the TypeAdapter, we first need to register it.

void main() async {
  //Initialize Hive  
  await Hive.initFlutter();
  //Register a TypeAdapter
  Hive.registerAdapter(TodoAdapter());
}

Now, that we have learned about all basic concepts of Hive and can kick things off by looking at a Todo List app.

Creating a simple Todo List app

The Todo List app will have a HomePage widget with a ListView and a FloatingActionButton.

1. The initStatemethod creates a box called as todosBoxand calls loadTodos.The loadTodos function fetches the list of todos stored in the todosBox. After fetching the Todo items from the box it parses it as list and stores in todosList
2. If the todosList is not empty then List View will return ListTiles. Each ListTile will have its

• title as title of the Todo,
• subtitle as the description of Todo and a
• Checkbox as the traling widget which will track isDone property of Todo
• IconButton as leading widget for deleting the Todo

3. On pressing the FloatingActionButton a SimpleDialog will be displayed with two TextFields for title and description of the Todo. Pressing ADD will add the Todo to the todosBox.

4. CRUD operations are handelled by these function functions

• addTodo(): The addTodo function takes a Todo object as a parameter and adds it to todosBox. If the addition is successful, it updates the todosList by appending the newly created todo.
• deleteTodo(): The deleteTodo function provides users with the ability to remove completed or unnecessary todo items from their lists. It accepts an index and attempts to delete the corresponding todo from the todosBox. If successful, it updates the todosList to remove the deleted item.
• changeCompletionStatus(): The changeCompletionStatus accepts an index and a boolean value, this function enables users to toggle the completion status of a specific todo item. When called, it retrieves the todo from the Hive database, updates its isDone property according to the provided value, and saves the modified todo back into the todosBox. This function also updates the todosList to reflect the change.

Here is the complete code:

//FILE: todo_model.dart
import 'package:hive/hive.dart';

//specify name of the part file which will be generated by hive_generator
part 'todo_model.g.dart';
 
//Specify the HiveType with a type id between 0 and 233
//NOTE: No two TypeAdapters can have the same typeId
@HiveType(typeId: 0)
class Todo {
  //Annotate class members with HiveField with each 
  //HiveField having incrementing index
  @HiveField(0)
  String title;
  @HiveField(1)
  String description;
  
  //Default value can be specified if needed
  @HiveField(3, defaultValue: false)
  bool isDone;
  
  Todo({
    required this.title,
    required this.description,
    this.isDone = false,
  });
}

///FILE: main.dart
/// The main function initializes Hive and runs the Flutter application.
import 'package:flutter/material.dart';
import 'package:hive_flutter/hive_flutter.dart';
import 'package:lib/todo_model.dart';
void main() async {
  await Hive.initFlutter();
  Hive.registerAdapter(TodoAdapter());
  await Hive.openBox<Todo>('todos');

  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: HomePage(),
    );
  }
}

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

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

class _HomePageState extends State<HomePage> {
  late Box<Todo> todosBox;
  List<Todo> todosList = [];
  bool isLoading = true;

  final TextEditingController _titleController = TextEditingController();
  final TextEditingController _descriptionController = TextEditingController();

  @override
  void initState() {
    super.initState();
    todosBox = Hive.box<Todo>('todos');
    loadTodos();
  }

  /// Loads todos from the Hive box and stores it in todosList.
  Future<void> loadTodos() async {
    setState(() {
      isLoading = true;
    });
    todosList = todosBox.values.toList();
    setState(() {
      isLoading = false;
    });
  }

  /// Adds a new todo to the Hive box and updates the todosList.
  Future<void> addTodo({
    required Todo todo,
  }) async {
    try {
      await todosBox.add(todo);
      setState(() {
        todosList.add(todo);
      });
      debugPrint('${todo.title} added successfully');
    } catch (e) {
      debugPrint('Error: $e');
    }
  }

  /// Deletes a todo from the Hive box and updates the todosList.
  Future<void> deleteTodo(int index) async {
    try {
      await todosBox.deleteAt(index);
      setState(() {
        todosList.removeAt(index);
      });

      debugPrint('Todo Removed Successfully');
    } catch (e) {
      debugPrint('Error: $e');
    }
  }

  /// Changes the completion status of a todo and updates the todosList.
  Future<void> changeCompletionStatus(int index, {required bool value}) async {
    try {
      Todo todo = todosBox.getAt(index)!;
      todo.isDone = value;
      await todosBox.putAt(index, todo);
      setState(() {
        todosList[index] = todo;
      });
      debugPrint('${todo.title} marked ${value ? 'complete' : 'incomplete'}');
    } catch (e) {
      debugPrint('Error: $e');
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Todo List'),
      ),
      body: isLoading
          ? const Center(
              child: CircularProgressIndicator(),
            )
          : todosList.isEmpty
              ? const Center(
                  child: Text("No Todos Created"),
                )
              : ListView.builder(
                  shrinkWrap: true,
                  itemCount: todosList.length,
                  itemBuilder: (context, index) {
                    return ListTile(
                      title: Text(
                        todosList[index].title,
                        style: TextStyle(
                          decoration: todosList[index].isDone
                              ? TextDecoration.lineThrough
                              : null,
                        ),
                      ),
                      subtitle: Text(
                        todosList[index].description,
                        style: TextStyle(
                          decoration: todosList[index].isDone
                              ? TextDecoration.lineThrough
                              : null,
                        ),
                      ),
                      leading: Checkbox(
                        value: todosList[index].isDone,
                        onChanged: (value) {
                          changeCompletionStatus(index,
                              value: !todosList[index].isDone);
                        },
                      ),
                      trailing: IconButton(
                        onPressed: () async {
                          await deleteTodo(index);
                        },
                        icon: const Icon(
                          Icons.delete_forever,
                          color: Colors.redAccent,
                        ),
                      ),
                    );
                  },
                ),
      floatingActionButton: FloatingActionButton(
        onPressed: () async {
          showDialog(
            context: context,
            builder: (context) {
              return SimpleDialog(
                title: const Text("Create a Todo"),
                contentPadding:
                    const EdgeInsets.symmetric(vertical: 18, horizontal: 16),
                children: [
                  Column(
                    children: [
                      TextField(
                        controller: _titleController,
                        decoration: const InputDecoration(
                            border: OutlineInputBorder(), label: Text("Title")),
                      ),
                      const SizedBox(
                        height: 12,
                      ),
                      TextField(
                        controller: _descriptionController,
                        decoration: const InputDecoration(
                            border: OutlineInputBorder(),
                            label: Text("Description")),
                      )
                    ],
                  ),
                  const SizedBox(height: 22),
                  Row(
                    mainAxisAlignment: MainAxisAlignment.spaceAround,
                    children: [
                      ElevatedButton(
                          onPressed: () {
                            Navigator.of(context).pop(widget);
                          },
                          child: const Text("CANCEL")),
                      ElevatedButton(
                        onPressed: () async {
                          if (_titleController.text.isEmpty) {
                            ScaffoldMessenger.of(context).showSnackBar(
                                const SnackBar(
                                    duration: Duration(milliseconds: 200),
                                    content: Text("Title cannot be empty")));
                          } else {
                            addTodo(
                              todo: Todo(
                                title: _titleController.text,
                                description: _descriptionController.text,
                              ),
                            ).then((_) {
                              _titleController.clear();
                              _descriptionController.clear();
                            });
                          }
                          Navigator.of(context).pop();
                        },
                        child: const Text("ADD"),
                      ),
                    ],
                  )
                ],
              );
            },
          );
        },
        child: const Icon(Icons.add),
      ),
    );
  }
}

This is how the output will look,

Conclusion

In this article, we explored Hive, a lightweight and fast NoSQL database for Flutter applications. We learned how to set up Hive, understood its basic concepts, and generated TypeAdapters for our data models. We also created a simple Todo List app to see how Hive works in action.

Hive is a great choice as it offers a simple and efficient way to manage local data. Even though Hive is no longer maintained it is still used by many developers. Its ease of use, performance, and flexibility make it a great choice.

Happy coding!

Understanding Flex Family in flutter for creating Responsive Layouts

Note: This blog assumes that you are using vscode, Android Studio or IntelliJ as IDE.

This is the third part in the Creating Responsive Layouts series and focuses on Flexible and Expanded widgets. The previous article can be found here.

In this blog we will look how Flexible and Expanded widgets work and learn how to use them for creating a Responsive Layouts in Flutter.

1. A bit about the Flex family
2. Introduction Flexible and Expanded widgets
3. Understanding the flex factor
4. Conclusion

So, without a further ado lets jump right in.

A bit about the Flex family

To kick things of let’s first discuss about the flex family of widgets.

Well, Flex is acthually a class, but we will be refering the widget’s that use Flex as its parent(super class) being part of the flex family.

Basically, the sub classes that extend the Flex and related classes are part of the “flex family” of widgets.

For some beginners, Flex might be a new word and might confuse them. But, we have all used Flex widget in the form of Row and Column. If we look at the code of Row and Column they both extend the Flex class. The only difference being the Axis direction. Row by default has direction of Axis.horizontal and Column by default has direction of Axis.vertical.

So we can say that,

Row is a Flex widget which lay’s out its childrens “horzontally” and Column is a Flex widget which lay’s out its childrens “vertically”.

Alos, We can put Flexible and Expanded widgets in the same family because of the close relation that these widgets have with the other Flex family widgets.

Now, since we have discussed about the Flex widgets its time to move to the next section.

Introduction Flexible and Expanded widgets

Let’s say we have a Row with some fixed size widgets in it. As we keep on adding more widgets we will arrive at the point were the widgets might not fit themselves in this Row and flutter will throw the RenderFlex overflowed error that we all hate.

The reason we had this error in the first place was because of the use of fixed size widgets. The first lesson to keep in mind while creating responsive layouts is

“Do Not Use Fixed Values for Determining Widget Size”

If using fixed values for sizing widgets we might end up getting the RenderFlex Overflowed error in one device or the other. So what’s the solution?

Well, the solution is eazy peasy. We can use relative sizes with help from either MediaQuery or LayoutBuilder widgets. Problem Solved….

Well, technically, the problem is solved and we won’t get any errors, but, here are some thing we need to consider before using MediaQuery or LayoutBuilder.

1. Both MediaQuery and LayoutBuilder require a little boilerplate code before they can be of any use.
2. As discussed in previous articles of the series, using MediaQuery excessively can lead to performance issues. Same can be said about LayoutBuilder, any changes in constraints will result in rebuilding of the entire widget tree returned by builder function.
3. Even if we can deal with the above two reasons, we will need to make calculations, which can get ugly if you are bad at math as I am, ahh… just kidding. The calculations in such cases are usually simple but it’s better to avoid them whenever possible.

Due to the above reasons it is best to avoid using MediaQuery or LayoutBuilder, inside the flex widgets.

So, what can we do? Are there any options? Maybe some prebuilt widget……

This is were Flexible and Expanded come into play. The good thing about these widgets is that they are a part of the flex family and were made for use inside flex widgets for relative sizing of the childern widgets.

The biggest adavntage of Flexible and Expanded widget is that, it does not require any boilerplate code and it extremely easy to use.

First, let’s have a look on how to use the Flexible widget,

import 'package:flutter/material.dart';

class FlexibleExample extends StatelessWidget {
  const FlexibleExample({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Row(
        children: [
          Flexible(
            flex: 1,
            child: Container(
              color: Colors.red,
              height: 100,
              child: const Center(child: Text('Flex 1')),
            ),
          ),
          Flexible(
            flex: 2,
            child: Container(
              color: Colors.green,
              height: 100,
              child: const Center(child: Text('Flex 2')),
            ),
          ),
          Flexible(
            flex: 1,
            child: Container(
              color: Colors.blue,
              height: 100,
              child: const Center(child: Text('Flex 1')),
            ),
          ),
        ],
      ),
    );
  }
}

The above code uses Flexible widget for determing the width of the child Containers. We have specified the flex value which tells Flexible the amount of space that should be accquired by the child widget. The first(red) and last(blue) Container have the same flex value of 1 and will accquire less space in comparison to the second(green) Container which has a flex value of 2 accquiring more space, twice as much as first and second containers in our case. We can say that,

“Higher” the flex value = “Larger” the space accquired

Now, coming towards the Expanded widget, if we look at the code for Expanded it is just a Flexible widget with its FlexFit fit defaulting to FlexFit.tight. Specifiing the FlexFit as tight makes a Flexible fill all the remaining space and for the ease of use and understanding, this Flexible is “termed” as Expanded.

Let’s take a look at another code:

import 'package:flutter/material.dart';

class ExpandedExample extends StatelessWidget {
  const ExpandedExample({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Row(
        children: [
          Flexible(
            flex: 10,
            child: Container(
              color: Colors.red,
              height: 100,
              child: const Center(child: Text('Flex 1')),
            ),
          ),
          Container(
            color: Colors.green,
            height: 100,
            width: 200,
            child: const Center(child: Text('Fixed Width Container')),
          ),
          Expanded(
            child: Container(
              color: Colors.teal,
              height: 100,
              child: const Center(child: Text('Expanded')),
            ),
          ),
        ],
      ),
    );
  }
}

In the code for ExpandedExample we have a Flexible widget, a fixed width Container and an Expanded widget inside a Row. The Flexible widget accquires the most space with a flex of 10, fixed width container accquires a width of 200 and the Expanded widget fills the remaining space.

If we were to run the same code across devices of different screen dimensions we would get the same output. Aint’t that great.

OK. All of that is good, but what’s the thing with the flex value. Higher the flex value means larger the space accquired is understandable, but

How does flutter calculates the size of widgets based on flex value?

Well, that brings us to the next section of the article.

Understanding the flex factor

In order to fully understand how Flexible and Expanded work it is essential to understand the flex value or we can also say the “flex factor”.

The flex factor informs flutter about the amount of space the Flexible should accquire across the main axis. We can say that,

Flex Factor determines the amount of space a Flexible should accquire relative to other widgets.

This could be understood by a taking simple example,

The Pizzamigos

Let’s say there were three friends who have ordered a large pizza and they decide to distribute the pizza based on how hungry they are. The first friend is not that hungry so get’s a single pizza slice. The second friend is starving and gets 5 pizza slices. The third firend is hungry as well gets 4 slices.

Now, going by that analogy,

The pizza is the “available space”,

friends are the “widgets” and

slices are the “flex factor”.

Suppose that we have available width of 400px and we use a Row with three Containers. Since we want a responsive layout we use Flexible to hold containers and specify the flex factor as 1, 5 and 4 respectively.

Now, during layout process after determining the available space, flutter

1. First adds the flex values 1 + 5 + 4 = 10 and calculates the size of individual part 1 part = 400px/10 = 40px
2. Then it, sub divides the available width into 10 parts.
3. Next flutter calculates space requested by each Flexible via flex factor

• The first container with a flex factor of 1 gets 1 part from the available space (1 * 40 pixels = 40 pixels).
• The second container with a flex factor of 5 gets 5 parts from the available space (5 * 40 pixels = 200 pixels).
• The third container with a flex factor of 4 gets 4 parts from the available space (4 * 40 pixels = 160 pixels).

Just like the pizza slices are divided among the friends based on how hungry they are, the available space in a Row or Column or Flex is divided among the widgets based on their respective flex factors. This ensures that space distribution relative and helps in Creating Responsoive Layouts.

Conclusion

In this article, we had an overview of Flex family in Flutter and origins of Row and Column widgets. Then we learned about Flexible and Expanded widgets, which help in creating responsive layouts by relatively sizing widgets based the flex factor. We also had a look at how the flex factor determines the size of widgets. Understanding these concepts is essential for designing flexible and well-balanced layouts in Flutter.

For reading the entire blog,

A Deep Dive into Layout Builder: Creating Responsive Layouts in Flutter

Note: This blog assumes that you are using vscode, Android Studio or IntelliJ as IDE.

This is the second part of the Creating Responsive Layouts series and focuses on Layout Builders. The first part was about Media Query and can be found here.

In this blog we will be exploring Layout Builder and understand how it contributes in creating Responsive Layouts in Flutter.

1. What is Layout Builder?
2. How to use Layout Builder?
3. Creating Responsive layouts using Layout Builder
4. Conclusion

So, without a further ado lets get started.

What is Layout Builder?

Layout Builder is an amazing widget in flutter which provides information about the constraints that are enforced by the parent widget. As a beginner, one might mix up constraints and size, but there is a difference.

BoxConstraints or constraints are basically a set of four values minimum and maximum width and minimum and maximum height which are padded down by the parent widget, whereas Size refers to the acthual dimensions of the widget after the layout has been rendered. Size of a widget cannot be bigger or smaller than maximum and minimum constraints.

So, to sum it up we can say that,

A widget can have a any “size” as long as it fits within the “constraints”, which are enforced by the parent widget.

This is were LayoutBuilder comes in. See, LayoutBuilder is the widget which informs about those incoming constraints. Once we know what the constraints are, we can then craft the layout to fit the available space in an efficient way.

BoxConstraints, that is everything LayoutBuilder has to offer, there is nothing more. Next up let’s discuss how to use LayoutBuilder.

How to use Layout Builder?

Using LayoutBuilder must be eazy, just give it a child…… wait, wait, wait…hold on, LayoutBuilder does not have a child property as rest of the widgets.

As the name suggests it is a Builder widget and instead of child it has a required builder property, this builder property is acthually a Widget Function that takes two required parameters, BuildContext and BoxConstraints and then returns a Widget. This is how we to do it

import 'package:flutter/material.dart';

void main() {
  runApp(const MainApp());
}

class MainApp extends StatelessWidget {
  const MainApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: LayoutBuilderExample()); //Used LayoutBuilderExample() as home
  }
}

class LayoutBuilderExample extends StatelessWidget {
  const LayoutBuilderExample({super.key});

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder( //Used Layout Builder
      builder: (context, constraints) { //This is how we implement builder function
        return Container(   //The widget returned by builder function
          width: constraints.maxWidth, //set the width based on constraints
          height: constraints.maxHeight, //set the height based on constraints
          color: Colors.purple,
        );
      },
    );
  }
}

In the above code we have defined a StatelessWidget called as LayoutBuilderExample, used as home, whose build method returns a LayoutBuilder. In the builder function we have specified two parameters BuildContext context and BoxConstraints constraints, which are the constraints passed down by the parent widget. In our case the parent widget is the device screen itself so constraints will be same as screen dimensions. Next, the LayoutBuilder returns a purple Container whose dimensions are based on constraints incoming from the parent widget. We have specified the width and height of the container to occupy the maximum space the parent widget has to offer by using maxWidth and maxHeight properties respectively.

Now lets paint the same container but this time we will use minWidth and minHeight for specifying values for width and height respectively.

// Modify the LayoutBuilderExample as follows 
LayoutBuilder(
      builder: (context, constraints) {
        //Some Print Statements
        debugPrint(
            "Max Width: ${constraints.maxWidth}\t\t\tMax Height: ${constraints.maxHeight}");
        debugPrint(
            "Min Width: ${constraints.minWidth}\t\t\tMin Height: ${constraints.minHeight}");

        return Container(
          width: constraints.minWidth, //use minWidth instead of maxWidth
          height: constraints.minHeight, //use minHeight instead of maxHeight
          color: Colors.purple,
        );
      },
    );

Aaand…. nothing changed. We still get the exact same output. Does that mean both min and max values are the exact same? To verify that we have have already included some print statements in our code. On checking the console of the IDE, we find that the output of print statements show exact same value for min and max values of width and height respectively. But why are the min and max constraints the exact same? Is there some problem?

Well, there is no problem, its just how flutter renders the widgets. It is essential to understand how constraints work and how it affets the rendering of a widget. Fortunately, all of that is clearly explained in an article by Marcelo Glasberg, which can also be found in flutter docs here.

I recommend the readers to check article by Marcelo Glasberg before reading further, as it is important to understand constraints to fully grasp the concepts discussed in this article.

Creating Responsive layouts using Layout Builder

Now, lets move towards the most intresting section of the article which is creating responsive layouts using LayoutBuilder. We will also look at some exceptions that developers might face while creating responsive layouts while using LayoutBuilder.

So, LayoutBuilder informs us about constraints, and we can leverage this information to create responsive layouts. But how exactly?

Well, by now we know that constraints is a set of four doubles minWidth, minHeight, maxWidth and maxHeight incoming from parent widget. If you look at the code with which we created purple container, we have used the values of maxWidth and maxHeight for defining containers dimension. In our case parent was the screen so the incoming constraints were the acthual height and the width of the screen due to which the container filled the entire screen. Also the reasons due to which we observed the same results when using minWidth and minHeight were because, of the incoming constraints being tight(min and max constraints are the same).

OK. Now, let’s look at another example where we can use layout builder to do the same thing we used MediaQuery for. In the first article of the series we looked at a small code snippet(here) which used MediaQuery to get the device dimensions and return either desktop, tablet or mobile layout.

We can achive the same functionality using LayoutBuilder. Here’s how,

//I recommend readers to read the comments for better understanding of code

import 'package:flutter/material.dart';

void main() {
  runApp(const MainApp());
}

class MainApp extends StatelessWidget {
  const MainApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: LoadLayout());
  }
}

class LoadLayout extends StatelessWidget {
  const LoadLayout({super.key});

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder( //Used Layout Builder
      builder: (context, constraints) {
        if (constraints.maxWidth >= 1024) {
          return buildDesktopLayout(parentConstraints: constraints);
        } else if (constraints.maxWidth >= 600) {
          return buildTabletLayout(parentConstraints: constraints);
        } else {
          return buildMobileLayout(parentConstraints: constraints);
        }
      },

      //Alternatively switch-case can be used instead of if-else
      // builder: (context, constraints) {
      //   return switch (constraints.maxWidth) {
      //     >= 1024 => buildDesktopLayout,
      //     >= 600 => buildTabletLayout,
      //     _ => buildMobileLayout,
      //   }(parentConstraints: constraints);
      // },
    );
  }
}

//layout functions desktop
Widget buildDesktopLayout({required BoxConstraints parentConstraints}) {
  return Scaffold(
    appBar: AppBar(
      title: Text(
          //display acthual height of the screen
          "Desktop(Acthual Height: ${parentConstraints.maxHeight})"), 
    ),
    body: buildBody(color: Colors.indigo),
  );
}
//layout functions tablet
Widget buildTabletLayout({required BoxConstraints parentConstraints}) {
  return Scaffold(
    appBar: AppBar(
      title: Text("Tablet(Acthual Height: ${parentConstraints.maxHeight})"),
    ),
    body: buildBody(color: Colors.purple),
  );
}
//layout functions mobile
Widget buildMobileLayout({required BoxConstraints parentConstraints}) {
  return Scaffold(
    appBar: AppBar(
      title: Text("Mobile(Acthual Height: ${parentConstraints.maxHeight})"),
    ),
    body: buildBody(color: Colors.teal),
  );
}

//buildBody  function
Widget buildBody({required Color color}) {
  return LayoutBuilder(
    builder: (context, constraints) {
      return Container(
        width: constraints.maxWidth, //width based on maxWidth constraint
        height: constraints.maxHeight, ////width based on maxWidth constraint
        color: color,
        child: Center(
          child: Text(
            //display available height and width
            "Width:${constraints.maxWidth} , Height:${constraints.maxHeight} ", 
            style: TextStyle(
              color: Colors.white,
              fontSize: constraints.maxWidth *
                 0.04, //fontSize based on incoming maxWidth constraint
              fontWeight: FontWeight.bold,
            ),
          ),
        ),
      );
    },
  );
}

Here is the breakdown of the code,

In the code above we have a widget called as LoadLayout which returns a LayoutBuilder. Since LoadLayout is used as home, the parent is screen itself and screen dimensions are constraints. We have defined three functions called buildDesktopLayout(), buildTabletLayout(), buildMobileLayout() which are returned by the builder function based on the maxWidth constraint. Each of the layout function takes parentConstraint as a parameter and returns a Sacffold which has an appBar whose title is a Text widget which the name of the layout and the maxHeight constraint. For the body of the Scaffold we have used a function called as buildBody(). It takes a color parameter. This function also returns a LayoutBuilder. Its builder function returns a Container whose color property is set to ‘color’ which is passed during function call. Container’s child is a Centre whose child is a Text widget which displays the incoming constraints.

Select Windows(windows-x64) as the device in IDE and run the application.

Initially, it will return buildDesktopLayout() with indigo color and since our application is responsive we can resize the app and see the magic. As the width is reduced and certain breakpoint is reached different layouts are returned by LayoutBuilder of LoadLayout. Also since we have used maxWidth to set fontSize, the font size reduces as the window shrinks horizontally.

There is one thing all of us might have noticed and that is the height. Why is the height displayed differently on the appBar and on the body? That is because LayoutBuilder, as we all know by now, informs about constrains incoming from the parent. Since we have two LayoutBuilders used at different places with different parents we get different constraints.

The first LayoutBuilder is used by LoadLayout whose parent is the screen itself, so naturally, the constraints will be tight and will be equal to acthual dimensions of the screen. In our code we have passed these constraints to the parentConstraints parameter of layout functions and displayed the acthual height in the appBar.

The second LayoutBuilder is used by buildBody() function which is called by layout functions as the Scaffold’s body. So for buildBody() function‘s LayoutBuilder it is the Scaffold who is the parent. Since the appBar is already present, the available space will be less and vertical constraint i.e the height, will be reduced. This is the available height which is displayed at the Centre of the Container by the Text widget. Also, the fontSize of the text is adjusted based on maxWidth, so as the window is resized, the text responds to these changes and adjusts its size accordingly.

Isn’t that great. We can use LayoutBuilder anywere in the Widget tree make informed decisions about the layout based on the availabiliy of space. This allows us to create responsive layout which looks alomost identical across various devices and platforms. We can combime MediaQuery and LayoutBuilder to create responsive apps. But thats not all there other things like GridView, ListView, Responsive Text etc. that are needed to be taken into account for creating a trully responsive app. In further parts we will look at each of these and discuss about Creating Responsive Layouts.

Conclusion

Using LayoutBuilder in Flutter apps is a helps in adjusting layouts dynamically based on available space, making sure the app looks great on any device. The combination of LayoutBuilder with other widgets like MediaQuery allows making informed layout decisions, enhancing both usability and user experience. Whether designing for mobile, tablet, or desktop, LayoutBuilder provides information needed to build responsive apps.

I hope that this blog provided you with the information required about LayoutBuilder and helped in understanding how responsive layouts are created.

For reding the entire blog,

A Deep Dive into MediaQuery: Creating Responsive Layouts in Flutter

Note: This blog assumes that you are using vscode, AndroidStudio or IntelliJ as IDE.

In this medium blog we will discuss about Media Query class and find how it helps in creating Responsive Layouts in Flutter.

1. What is Media Query?
2. How to use MediaQuery?
3. Exploring the MediaQuery class.
4. Creating Responsive layouts using Media Query.
5. Best Practices while using MediaQuery.
6. Conclusion

So, without a further ado lets begin.

1. What is Media Query?

In Flutter, MediaQuery is a widget that provides information about the device’s screen and user preferences. It allows developers to build responsive and adaptive user interfaces by giving access to various details about the screen’s size, orientation, pixel density, and more. How, you ask?

Just use,

//Use this anywere in the Widget tree where BuildContext context is available
 MediaQuery.of(context);

And you will now have access to everything MediaQuery has to offer.

But how MediaQuery acthually does this?

MediaQuery achives this using BuildContext which provides a high-level overview of the current state of the device screen by creating an instance of something called as MediaQueryData. It is MediaQueryData which gives access to screen’s size, orientation, pixel density, and more.

By utilizing MediaQuery developers can create layouts that can morph to fit in device screen based on device width, device height, orientation, brightness, etc. and create consistent layout on devices of various screen sizes and Platforms(Android, IOS, Windows, Linux and Web).

2. How to use MediaQuery?

As discussed above its quite easy to use MediaQuery, just use the of() method and you are good to go, the only requirement is BuildContext. MediaQuery can be used anywere in the widget tree where the BuildContext is available.

Next, in order to access the data provided by MediaQuery.of(context) you can create a variable of type MediaQueryData, let’s say mediaQuery. Now once we have instance of MediaQueryData, just use “ mediaQuery. ” and you will be able to see everything MediaQueryData has to offer.(Assuming you are using vscode, Android Studio or IntelliJ IDE)

Putting all things together, this is how you use MediaQuery.

//NOTE: only use MediaQuery where BuildContext context is available

//EITHER you can specify the type for mediaQuery as MediaQueryData
final MediaQueryData mediaQuery = MediaQuery.of(context);

//OR eleminate the type and let dart infer it
final mediaQuery = MediaQuery.of(context);

//Voilla, now you have access to everything MediaQuery has to offer.

All of that is right but what is the deal with BuildContext and it being “available” in order to use MediaQuery?

Look, it’s simple and nothing to be worried about. Here is the thing, every widget in flutter application(Stateless, Stateful or Inherited Widget) has a build() method which is used to build a widget and is a necessary override while creating any widget. This build method takes a required argument which is (drumroll…), BuildContext.

Now, since BuildContext is available to all the widgets inside the build() method and we can use the MediaQuery.of() method and pass the BuildContext to it.

We will typically write something like this in order to create a Widget and use MediaQuery.of(context) inside the build(BuildContext context) method where theBuildContext is available.

//Example Usage 1
//MediaQuery being used inside a widget

class MyCustomWidget extends StatelessWidget {
  const MyCustomWidget({super.key});
  @override
  Widget build(BuildContext context) {
    //this MediaQueryData instance can be only used
    //inside the build method where the context is available
    final MediaQueryData mediaQuery = MediaQuery.of(context);

    return Scaffold(
      body: Center(
        child: Container(
          width: mediaQuery.size.width * 0.5, //50% of screen width
          height: mediaQuery.size.height * 0.5, //50% of screen height
          color: Colors.blue,
        ),
      ),
    );
  }
}

Another question: Can we use MediaQuery outside widgets?

The short answer is YES. But there are things we must know.

Remember the only requirement for using MediaQuery.of(context) is BuildContext. This means that one can define a function and use BuildContext as its parameter. Then MediaQuery can be used inside the function block.

This approach is usually used to create reusable code blocks or to create a separate function to manage a growing widget tree ensuring code maintainability.

Note: Such a function should be only called where build context is available, preferably inside the widget’s build() method.

Check the below example.

//Example Usage 2
//MediaQuery being used inside a function

class MyCustomWidget extends StatelessWidget {
  const MyCustomWidget({super.key});
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: customContainer(context), //call customContainer and pass context
      ),
    );
  }
}

//A funtion using MediaQuery

Container customContainer(BuildContext context) {
  final mediaQuery = MediaQuery.of(context);
  return Container(
    width: mediaQuery.size.width * 0.5, //50% of screen width
    height: mediaQuery.size.height * 0.5, //50% of screen height
    color: Colors.blue,
  );
}

Both the approaches will produce the same output i.e, a blue Container occupying 50% of screen width and 50% of screen height .

That all we need to know about using MediaQuery in flutter.

Now let’s move to some important aspects of MediaQuery and see what MediaQuery offers and how we can utilise it.

3. Exploring the MediaQuery class.

Now, we have covered all the basics of MediaQuery and we are ready to start exploring the MediaQuery or should I say MediaQueryData class. Remember, as discussed in previous sections it is MediaQueryData that provides information about device screen and user preferences.

Media Query has multiple data members(properties) that contain information about device specific information like devicePixelRatio, orientation, padding, size, etc. Let’s go through all such important data members.

Note: I will be covering the important and most used data members and not all of them. Consider reading the docs for a detailed info

A. Data members containing information about “Device Screen”

1. devicePixelRatio: Device Pixel Ratio or DPR refers to the ratio between the physical pixels on screen and logical pixels. Physical pixels are the acthual pixels present on the display of the device, whereas one logical pixel corrosponds to ‘n’ number of physical pixels. We can say something like 1 logical pixel corrospond to 3 physical pixels. If DPR for a device is 3 then, 3 physical pixels will be used to draw a line which is 1px wide. Logical Pixels are same across various devices and are used to maintain “visual consistancy”. DPR is mostly used in dealing with images with different resolutions to maintain consistancy. This is how to use devicePixelRatio

//devicePixelRatio is useful when dealing with images heiping
//in pixel perfect rendering
final double dpr = MediaQuery.of(context).devicePixelRatio;

2. padding: Padding in context of MediaQuery refers to the amount of space reserved by operating system like the system status bar(the one were we see the time and battery percentage, etc.) and the bottom region which is used for naviagtion and other puropses which may vary from one platform to other. Padding is of type EdgeInsets and has four offsets, namely botton, top, right and left. Bottom padding will have some value if the keyboard is not visible, if keyboard is Up then bottom padding will be reduced to “0”. This is how to use padding

//padding helps in determining the position and amount of pixels reserved by 
//the operating system for its own puropses
final EdgeInsets padding = MediaQuery.of(context).padding;
debugPrint("Padding => Bottom: ${padding.bottom}, Top: ${padding.top}, Left: ${padding.left}, Right: ${padding.right}");

3. orientation: Orientation is as simple as it gets. It refers to the alignment and positioning of the device. There are two types of orientations, Landscape and Potrait. In Potrait orienatation the width of device is smaller than the height and in Landscape orientation it just gets reversed, now the width is larger and height is smaller. Orientation plays a crucial role in determining the layout of the application, as changing the orientation affects the amount of information or data that can be displayed on the screen. A good application is one which accounts for different orientations. This is how to use orientation

//orientation helps in determining the position and alignment of device
final Orientation orientation= MediaQuery.of(context).orientation;
if(orientation == Orientation.landscape){
  debugPrint("Device is in Landscape mode");
}else{
  debugPrint("Device is in Potrait mode");
}

4. size: Size is the most used data member offered by the MediaQueryData class and provides a lot of information about the device screen. But we will be talking about three, namely width, height and aspectRatio. As the name suggests width gives the device width, height gives the device height and aspectRatio gives the ratio of device width to device height. This is how to use size

//size property helps in getting device screen dimensions
final Size size = MediaQuery.of(context).size;
debugPrint("Size => Width: ${size.width}, Height: ${size.width}, AspectRatio: ${size.aspectRatio}");

5. viewInsets : ViewInsets is of type EdgeInsets. viewInsets is used to determine the amount of space consumed by the keyboard when it is visible. If the keyboard is not visible the all the four offsets of viewInsets i.e bottom, top, right and left will be “0”. View Insets bottom offset will be non zero when the keyboard is up and every other offset will be zero (always). This is how to use viewInsets

//viewInsets property helps in determining weather the keyboard is up or not
//If the keyboard is up then bottom property of viewInsets will provide the 
//amount of space consumed by the keyboard
final EdgeInsets viewInsets = MediaQuery.of(context).viewInsets;
if(viewInstes.bottom > 0){
debugPrint("Keyboard is UP");
}

6. viewPadding: ViewPadding is also of type EdgeInsets and is similar to padding in a lot of ways. The only difference between padding and viewPadding is bottom value of padding becomes “0” when keyboard is visible whereas viewPadding despite the visibility of keyboard has a non zero bottom value for viewPadding. Basically viewPadding remembers what the bottom padding was unlike padding which forgets bottom padding value and sets it to “0”. Everything else is same. Consider using viewPadding instead of padding for consistant layouts. This is how to use viewPadding

//viewPadding property does not forget what the bottom padding was
//even if the keyboard is visible
final EdgeInsets viewPadding = MediaQuery.of(context).viewPadding;
debugPrint("ViewPadding => Bottom: ${padding.bottom}, Top: ${padding.top}, Left: ${padding.left}, Right: ${padding.right}");

B. Data Members containing information about “User Prefrences

1. accessibleNavigation: Accessible Navigation is of type bool and returns true if screen reader service like TalkBack(for Android) or VoiceOver(for IOS) are enabled. This allows developer to craft apps that are asseccible to users with visual impairments. This is how to use accessibleNavigation

//accessibleNavigation returns if screen reader service is enabled by the user
final bool scrReaderStatus = MediaQuery.of(context).accessibleNavigation;
if(scrReaderStatus == true){
  debugPrint("The screen reader service is enabled");
  //DO Something
}

2. alwaysUse24HourFormat : This data member is of type bool and is related to the time format the user has configured on his device. There are two time formats 12 hour(AM/PM) and 24 hour format. If the user has opted for 24 hour format then alwaysUse24HourFormat will return true, else it will return false. This property is used when creating apps that display time on the app like a todo list app or a clock app. This is how to use alwaysUse24HourFormat

//alwaysUse24HourFormat returns true if the 
//user has opted for 24 Hour time format in device settings
final bool is24Hr = MediaQuery.of(context).alwaysUse24HourFormat;
if(is24Hr == true){
  debugPrint("The user has opted for 24 hr time format");
  //DO Something
}

3. boldText: Bold Text can be considered as an accessibility feature and is of type bool. If user has enabled Bold Text in device settings then the text appears enhanced or bold. If the user has enabled bold text the boldText property will return true. We can make adjustments to the TextStyles fontWeight porperty to handel such situations. This is how to use boldText

//boldText returns true if user has enabled "Bold Text"
//switch in device accessibility settings
final bool usingBoldText = MediaQuery.of(context).boldText;
//Somewere inside widget tree
Text(
  'Hello, World!',
  style: TextStyle(
    fontWeight: usingBoldText == true ? FontWeight.bold : FontWeight.normal),
  ),
);

//NOTE: It will be better to change the font weight app wide using the 
//themeData property of the MaterialApp

4. disableAnimations: Disable Animations property is of type bool and returns true if the user has disabledAnimations. This is usually done by users who have motion sensitivity or users who just prefer a static user interface. The good thing is MediaQuery provides a way by which we can account for such changes. This is how to use disableAnimations

//disableAnimations returns true if user has disabled animations
//in device accessibility settings
final bool hasDisabledAnimation = MediaQuery.of(context).disableAnimations;
if(hasDisabledAnimation == true){
  debugPrint("User has disabled animations");
  //Implement the logic to disable animations 
}

5. platformBrightness: Platform Brightness is the property which developers will find using often. It tells weather user has enabled light theme or dark theme. platformBrightness returns an emum called Brighthess which has two values light and dark. It is common for users to change the system theme mode based on time of the day or just personal preference, so accounting for such changes is must. This is how to use platformBrightness

//platformBrightness helps in determining which theme is used 
//by the user
final Brightness platformBrightness = MediaQuery.of(context).platformBrightness;
if(platformBrightness == Brightness.dark){
  debugPrint("System is using dark mode");
  //Load the ThemeData configured for dark theme
} else{
  debugPrint("System is using light mode");
  //Load the ThemeData configured for dark theme
}

//NOTE: The MaterialApp provides a way to deal with platform brightness
//It has a property called as themeMode which is of type ThemeMode 
//and is used to load themes based on value passed to themeMode property

return MaterialApp(
  theme: ThemeData.light(), //light theme
  darkTheme: ThemeData.dark(), //dark theme
  //Automatically switches between dark and light theme based on "system theme"
  themeMode: ThemeMode.system, 
  home: MyHomePage(),
);

I have covered some of the most used data members of the MediaQueryData class but this is not all of them. Be sure to check the documentation for MediaQueryData to learn more.

4. Creating Responsive layouts using Media Query.

Now, we have came a long way exploring Media Query and are familier with its in’s and out’s. This is the right time to discuss about creating responsive designs and the role of Media Query in creating responsive apps.

Media Query tells us about the device screen which is basically everything that is required to build a responsive layout. What are you waiting for, just start using Media Query and create responsive layous.

Well….yeah that’s all.

Look what I said is true, MediaQuery is the very essencce of creating responsive layout in flutter, but that’s not all of it. Let me explain.

So, calm down.

Knowing what MediaQuery is and utilizing MediaQuery for creating Responsive Layouts are flip sides of the same coin. It is esssential understanding both of them to create what is called as a “Responsive App ”, one that is visually consistent, offers optimal user experience acrross wide range of devices, adapts and uses the available space in best possible way, so on and so fourth. Covering all of that in a single blog post is not possible, but don’t worry as this is just the first part and next parts will make it way more clear.

Now, since we have included the section about responsive layouts in the blog post, lets see a tiny example that will demonstrate the power of MediaQuery in creating responsive app.

Let’s say you are coding a application and it will be used on smartphones, tablets, desktop and web as well. Thats a lot of screens to account for. How do we know which device screen the app is been used on, and how can MediaQuery help in this situation?

You can use something like this which determines the type of layout based on screen width

double screenWidth = MediaQuery.of(context).size.width;
double screenHeight = MediaQuery.of(context).size.height;

if (screenWidth >= 1024) {
  // Desktop layout
  return buildDesktopLayout();
}else if (screenWidth >= 600) {
  // Tablet layout
  return buildTabletLayout();
}else {
  // Mobile layout
  return buildMobileLayout();
}

This is one of the most used approaches while creating responsive layout, but the above code only accounts for screen width and there are a many things to consider. It’s best to save them for later parts.

Till then,

Best Practices while using MediaQuery

Media Query is a great, but using it can be expensive. Why, you ask?

Using MediaQuery.of(context) returns an instance of MediaQueryData which has multiple data members, so any change in any of the data members(properties) of MediaQueryData class results in rebuilding of the widget. Any minor change and the entire widget gets rebuilt, and this is expensive. But how expensive can it be?

To understand this, let’s say that the user has toggled the system theme from light to dark, now since brightness is a data member of MediaQueryData class this will result in rebuilding of all the widgets that depend on MediaQueryData. And if you have multiple MediaQueries used in different parts of the application, it will have significant impact on the performance of the application.

It is best to avoid the use MediaQueryData or use it in a separate widget so that only that widget rebuilds rather than the entire parent widget.

If not MediaQueryData the how do we get information about the device screen and user perferences?

Don’t worry, flutter has one alternate way.

As an example, instead of using MediaQuery.of(context).size, we can use MediaQuery.sizeOf(context), this will only result in rebuilding of widget when size property of MediaQueryData changes. This is a much better approach as changes in something like system theme will not result in rebuilding the widgets depending on MediaQuery.sizeOf(context).

Every data member of MediaQueryData class we discussed about can be retrived using MediaQuery.{property}of(context) instead of MediaQuery.of(context).{property}.

If we only need devicePixelRatio using MediaQuery.devicePixelRatioOf(context) will be better than using MediaQuery.of(context).devicePixelRatio;

Same can be said about all the other data members or properties of MediaQueryData class. We can leveragethis to minimize dependency on MediaQuery.of(context) or MediaQueryData class

Conclusion

In conclusion, MediaQuery is an essential tool for building responsive and adaptive user interfaces in Flutter. By leveraging MediaQuery, developers can create layouts that can adjust themselves to fit various screen sizes, orientations, and device types, ensuring a consistent and optimal user experience across smartphones, tablets, desktops, and the web.

I hope that this blog has provided you with the information required about MediaQuery and a overview of Responsive Design.

And for reding the entire blog,