In this article, you’ll learn how to integrate this type of authorization with Permit.io in Nuxt.

Table of Contents

• Table of Contents

• What is the Difference Between Authentication and Authorization?

• What is Role Based Access Control (RBAC)?

• What are the Benefits of Using Authorization As A Service?

• What We’ll Be Building

• How to Plan RBAC with Permit.io

• How to Setup Permit.io in Nuxt

• How to Control API Access with Nuxt Middleware

• How to Test RBAC in the Community Dashboard

• Summary

What is the Difference Between Authentication and Authorization?

When building applications, we often carry out authentication together with authorization. However, these two concepts are essentially different.

Authentication is verifying who a user is. During the authentication process, the user usually needs to log in with some identifier like email, phone, username, with Google, with Microsoft, and so on.

Authorization specifies the resources an authenticated user can view and what they can do in the application. Authorization tells a user's access rights after that user has been successfully authenticated.

For example, authentication is a user logging in with email and password or verifying their phone number with SMS. On the other hand, authorization is a writer creating and editing posts while only admins can approve and publish those posts.

The primary purpose of authentication is to establish a user's identity before granting them access to the system. The main goal of authorization is to control user actions and protect sensitive data or resources.

What is Role Based Access Control (RBAC)?

Role-Based Access Control (RBAC) is an authorization model that you can use to manage and restrict access to system resources. It is based on the responsibilities, duties, or roles of users.

In RBAC, roles represent predefined sets of permissions that tell which actions a user can execute in an application. These roles are then assigned to users based on their job functions or responsibilities.

In common systems, anyone can assign permissions to individual users. In RBAC, we group permissions into roles. In turn, we assign these roles to users. For example, in a community dashboard, users might have roles like “Admin”, “Mentor”, or “Member”.

Aside from Role-Based Access Control, other popular authorization models exist such as Attribute-Based (ABAC) and Relationship-based (ReBAC) access controls. Attribute-Based Access Control uses a wide range of attributes and fits constantly changing systems. You could also combine it with Role-Based Access Control. For more info, see the Permit.io article on RBAC vs. ABAC.

What are the Benefits of Using Authorization As A Service?

You can build authorization models yourself in your application. But it may be time-consuming and cost-ineffective in the long run.

Using an external provider for authorization allows you to focus on the business logic in your applications. The benefits of outsourcing authorization are similar to using a third party like Auth0 or Firebase for Authentication.

Authorization as a Service provides a solution for managing user access and permissions in applications. When you use such an authorization solution, you enjoy enhanced security, granular access policies’ control, auto-scaling policies, reduced maintenance burden, faster upgrades, robust logging, and so on.

Permit.io is free to use for up to a 1000 Monthly Active Users, and has a UI and API for RBAC, ABAC, and ReBAC.

To Get Started with Permit.io:

• Go to app.permit.io

• Create an account

• Create a workspace (in your account)

What We’ll Be Building

A community dashboard connects members within a community or forum. It is a platform where they can interact and access resources.

For demo purposes of RBAC, we’ll build a simple community dashboard that will include 3 types of content (entities): posts, materials, and announcements.

The code we will be using is at https://github.com/obumnwabude/rbac-community-dashboard. It consists of a Nuxt repo with its server configured for API calls and its front end built with Vue. Clone it with git and explore the code in an editor/IDE.

In the server, we will expose GET, POST, and DELETE endpoints for each entity (posts, materials, and announcements). In Nuxt, you can use the HTTP verb in the file name for the endpoint handler. So we can have posts.get.ts*, posts.delete.ts, materials.post.ts,* and so on, with each file containing the respective handler for the involved API endpoint.

In addition, the server files store and retrieve entities from JSON files. You should have a robust database setup in your product. For this project, we’ll use local JSON files to build a minimum reproducible example with focus on roles and authorization.

In the front end, we have four pages: three for the entities and a settings page. There is also a simple navigation: a bottom bar on smaller screens and a sidebar on wider ones. Each entity page shows a list of its items and a small form to create new ones.

Furthermore, the demo code uses tailwindcss to style everything quickly. The settings page contains hardcoded user examples and roles for the demo. When testing, toggle the current user and see the roles in action.

This article focuses on the parts of the code that deal with authorization. For the backend and the UI specifics of the community dashboard, we will only overview them. After that, we will deep dive into RBAC touchpoints.

How to Plan RBAC with Permit.io

Overall, planning authorization means mapping out “who” can carry out an action on “what”. In RBAC, we define roles and then assign them to users. The roles and users combo is the “who” part of the authorization.

The “what” side refers to the entities or resources that your application provides or manages. For this article’s example, we’ve chosen our resources as Posts, Materials, and Announcements.

Actions are user activity. The most common actions are “create”, “read”, “update”, and, “delete”. Per resource in your application, you can use these four actions, add more, or omit some. In this article, our resources will each have all four actions.

When planning authorization, define resources alongside the “actions” users can execute on each resource. After that, define roles. For each role, specify what actions a user holding that role can carry out on each resource. The mapping of resources, actions, and roles allows you to define the authorization policies of your application.

Permit.io makes it easy to edit policies. In Permit.io, you have an intuitive dashboard where you can create resources and their actions, create roles, and merge both with policy tables.

For our Community Dashboard example, we will create three roles with incremental access: member, mentor, and admin. For each role, we’ll allow read access to all resources. However, each role has different management access levels to the resources as follows:

• Members can view all entities but can only create or delete posts.

• Mentors can view all entities and can create or delete posts and materials.

• Admins can create, view, and delete all entities.

Assigning roles to actions in resources is the same as editing policies.

How to Setup Permit.io in Nuxt

For our demo project, you need to run npm install, create a .env file, and export your Permit token.

However, if you are building a new project, to setup Permit in Nuxt, first install it with npm.

npm install permitio

After that, create a .env file and add your PERMIT_TOKEN. Get the token from the dashboard.

PERMIT_TOKEN=permit_key_XXXXXXXXXXXXXXXXXXXXX

To make this token available to the Nuxt runtimeConfig, add it to the nuxt.config.ts file. Also, add permitio (alongside other dependencies) in the transpile array of the build property of the Nuxt config file.

This addition is to account for Nuxt’s specific optimizations. Your nuxt.config.ts file should look like the following:

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  // ... other properties

  build: {
    transpile: ['axios', 'permitio', 'pino']
  },
  runtimeConfig: {
    permitToken: process.env.PERMIT_TOKEN
  }
});

After these, Permit.io should be available to your server code in Nuxt. You can now use in it middleware code to check for permissions.

How to Control API Access with Nuxt Middleware

In simple terms, middleware is code that runs before a target handler. In Nuxt, you can add middleware for API endpoints by creating necessary files in a middleware directory contained in the top-level server directory.

Since we are dealing with permissions, we will name our middleware file permissions.ts. Here, you’ll check if a user is permitted to take an action on a given resource.

Permit.io makes this easy with a simple .check method that returns a Boolean indicating if the user is permitted.

await permit.check(user, action, resource);

For this simple example community dashboard, our middleware code will first try to determine the user and action from the request properties. The example code achieves that in crude ways. They are enough to explain the concept and you should use more robust industry-standard methods for this.

After that, in the example code below, we construct the Permit object using our permit token and the default public PDP (Policy-Decision-Point microservice)’s endpoint. The Permit PDP is open-source. If you wish, you can set up your local/personal PDP by following the steps here.

import { Permit } from 'permitio';

export default defineEventHandler(async (event) => {
  // Only check permissions if the request is a POST or DELETE request
  const { method, path } = event;
  if (method !== 'POST' && method !== 'DELETE') return;

  // Ensure authorization header is present
  let authorization = event.node.req.headers['authorization'];
  if (!authorization) throw new Error('Unauthorized');

  // Extract the user from the authorization header. This is for example
  // purposes only. In a real application, you would use a JWT library or
  // better authentication methods in your API.
  const user = authorization.split(' ')[1];
  if (!user) throw new Error('Unauthorized');

  // Extract the resource from the path. This is for example purposes only.
  let resource = path.split('/').reverse()[0]; // get the last part of the path
  resource = resource.slice(0, -1); // remove the trailing 's' 
  // Capitalize the first letter
  resource = resource.charAt(0).toUpperCase() + resource.slice(1);

  // Set the action on the resource from the request method. 
  // This is for example purposes only. In a real application, you would
  // have a more robust way to determine the action. 
  const action = method === 'POST' ? 'create' : 'delete';

  // Construct the Permit object. Use the token from runtime config.
  const config = useRuntimeConfig(event);
  const permit = new Permit({
    pdp: 'https://cloudpdp.api.permit.io',
    token: config.permitToken
  });

  // Check if the user is permitted to create the resource. 
  // If not, throw an error.
  const isPermitted = await permit.check(user, action, resource);
  if (!isPermitted) throw new Error('Unauthorized');
});

As you can see, if the Permit checker fails, an error will be thrown. This will make Nuxt to prevent unauthorized resource management in your system. Such separation of concerns is efficient, especially in Authorization.

How to Test RBAC in the Community Dashboard

The settings page works together with the stores/permissions.ts file to complete the flow in the front end. We hardcoded the roles and the “user IDs” to ease toggling and testing. You definitely won’t have this in a production application. You can integrate CASL for permission checks in a frontend.

In this demo community dashboard, the UI touchpoints only allow edits of entities for which the acting user has the right roles. In other words, you can only add or delete an entity if the current role in the settings page allows that. Let’s see this in action.

In the Permit.io dashboard, create three test users: “example-member”, “example-mentor”, and “example-admin”. Assign the respective roles to each user.

Start up the Nuxt app by running npm run dev. Visit localhost:3000 in your browser and explore the role-based authorization in the demo community dashboard.

You can see that when you set the Current User to admin, you can create and delete announcements, but when set to guest, you can only view entities and not manage them. With this, we’ve fully implemented authorization.

Summary

You can be more efficient in building your application by focusing on business logic and outsourcing crucial parts like authorization.

In this article, you learned how you can use an authorization solution (Permit.io) to implement Role-Based Access Control in a demo community dashboard with Nuxt. You can also use Permit in any other kind of application (not just community dashboards).

When planning authorization, define resources alongside the “actions” users can execute on each resource. After that, define roles as the permissions the users can have.

Cheers!

In this article, we’ll explore how to achieve this combination for app-wide state in Flutter.

Table of Contents

• What is App-wide State in Flutter?

• What is a Stream in Dart?

• How to Create a Stream in Dart

• How to Create Singleton Class Instances (or Services)

• How to Manipulate State (streams) Within Services

• How to Use Dart Streams in Flutter Widgets

• How to Make a Service Depend on Another

• How to Improve Streams with rxdart Classes and Extensions

• How to Update State in AppLifecycle Callbacks

• Flexibility in State Management

• Summary

What is App-wide State in Flutter?

App-wide state comprises all variables that are relevant to multiple widgets at the same time. By app-wide state, we don't mean the state that is attached to StatefulWidgets. Those are ephemeral state. Updating them requires local or scoped calls to setState.

In Flutter, app-wide state usually has a separate logical management from UI code. This separated logic is called a state management architecture. We have many state management architectures with which we can engineer app-wide state. Examples include Provider, InheritedWidget, Riverpod, Bloc, Redux, Stacked, and so on. Each of these state management architectures are efficient, good, and opinionated.

While your choice of architecture could vary based on different factors, consider adopting the following architecture in your projects. It involves using Dart streams and services (singleton classes) for keeping track of your app's state.

What is a Stream in Dart?

A stream continuously emits values. You can listen to a stream and constantly get new values when they are emitted. Streams in Dart are the equivalent of Observable in JavaScript.

In Dart, streams are different from futures. The difference is that while a future resolves to one value, a stream will continuously emit various values during its life.

Let's say we have a counter stream that keeps track of some current integer count. This count could be incremented or decremented. To use the values emitted by this counter stream, you listen to the counter. Listening implies calling the .listen method on the stream and handling the emitted value.

counter.listen((int value) => print('Got $value.'));

How to Create a Stream in Dart

The Stream class comes with multiple factory constructors. They allow you to create various streams for various purposes. They include:

• Stream.empty

• Stream.value

• Stream.error

• Stream.fromFuture

• Stream.fromFutures

• Stream.fromIterable

• Stream.multi

• Stream.periodic

• Stream.eventTransformed

Each constructor serves a specific purpose as its name suggests.

Another technique of creating a Stream is by obtaining it from a StreamController. You will have to create the StreamController yourself. The advantage of doing this is that the controller allows you to add values to it. When you add values to the controller, they get emitted to listeners of its stream.

import 'dart:async';

void main() {
  final counterCtrl = StreamController<int>();
  counterCtrl.stream.listen(print);
  counterCtrl.add(1); // prints 1
}

The problem with the default StreamController from the dart:async library is that it allows only one listener. It is unicast. If you attempt attaching another listener to this stream obtained from StreamController, it will throw a "bad state" error.

This issue is solved by the BehaviorSubject class from the rxdart package. Technically, BehaviorSubject is a StreamController. The difference is that it has more features like:

1. Allows multiple listeners (very important).

2. Caches the latest emitted value or error.

3. Emits the latest cached value/error to a new listener once it newly subscribes.

4. Allows you to synchronously read the current (or last emitted) value from it.

5. Allows you to add values to it if it doesn't yet have any listener (the default StreamController doesn’t allow this).

The rxdart package extends the capabilities of Dart streams. For example, it provides you with BehaviorSubject. Also, it exposes classes and extensions that allow more stream manipulations. To use the rxdart package, add it to your project's dependencies from pub using the following command:

flutter pub add rxdart

Then import it in your project's Dart files. From there, you can create BehaviorSubject (more robust StreamController) that can allow multiple listeners while allowing you to control them (adding values to the streams).

import 'package:rxdart/rxdart.dart';

void main() {
  // Create a BehaviorSubject.
  //
  // Asides from creating the BehaviorSubject, we can also  
  // immediately add a value to it using Dart's cascade operator.
  final counterBS = BehaviorSubject<int>()..add(0);

  counterBS.stream.listen(print); // prints 0
  counterBS.stream.listen(print); // prints 0
  counterBS.add(1); // prints 1 twice
}

Now that we can create streams (and listen to them), we need the exact same streams to be available to every part of our Flutter apps.

To ensure that it is the same instance of streams that different parts of our Flutter apps are accessing, we can expose the streams from singleton class instances that we create in the project.

How to Create Singleton Class Instances (or Services)

When something is called a singleton, it means only one of it exists. For example, we can say the sun is a singleton star because we have only one sun.

When it comes to programming, we use a singleton when we need the same copy of an object everywhere. Already, the static properties of a class are singletons to every instance of that class. When you declare a field or method as static, you're telling the runtime engine to always reuse the same static item.

This explains why static properties are used as constants. It's another reason why we use them without instantiating an object. Furthermore, in Flutter, we conventionally use static properties as a means to obtain new or existing instances of a class. For example, many Flutter classes (MediaQuery, Navigator, ThemeData, and so on) have a static .of method for obtaining their instances.

In this streams and services architecture, we expose only one instance from a class with the static keyword. At the same time, we hide that class constructor. Hiding the constructor ensures that no other Dart code outside the Dart file can create another instance of the same class. Doing this maintains the instance as a singleton.

Following common conventions, we can call this class a service. Any other Dart file in the project can listen to the exposed stream(s) from the service class and always get updated values emitted to it.

Services here are holders of app-wide state. Each service is a logical container of related features. In any other part of the code, through these services, we can access app-wide state variables (in our case, streams). In a production application, we could have an authentication service, another for notifications, another for files, and so on.

To have an app-wide available service (singleton class) with a stream in it:

1. Create a service class.

2. Create a private constructor (so that no other Dart code outside the class can instantiate it).

3. Create a static private instance of that very class.

4. Expose this private instance as the singleton.

5. Create a private BehaviorSubject in that class.

6. Expose the BehaviorSubject stream as a public static getter from the class.

/* In counter_service.dart file */
import 'package:rxdart/rxdart.dart';

// 1. Create a class
// 
// The class name with "Service" appended to it indicates 
// that it is an app-wide state object.
class CounterService {
  // 2. Create a private constructor.
  //
  // This "just-underscore" constructor works. If we want, we could  
  // still add a name after the underscore. The main thing is that 
  // underscore makes the constructor to be a private one.
  CounterService._();

  // 3. Create a static private instance.
  // 
  // Prefixing underscore (_) to the variable name makes it private.
  // By being private, no other Dart code outside this file can directly 
  // access it.
  static final _instance = CounterService._();

  // 4. Expose this private instance as the singleton.
  static CounterService get instance => _instance;

  // 5. Create a private BehaviorSubject.
  final _counterBS = BehaviorSubject<int>()..add(0);

  // 6. Expose the BehaviorSubject's Stream.
  Stream<int> get countStream => _counterBS.stream;

  // Also, if need be, expose the BehaviorSubject's current as a getter.
  int get currentCount => _counterBS.value;
}

/* In any other Dart file in the project */
import 'counter_service.dart'

// Attach a listener to the stream
CounterService.instance.countStream.listen((count) {
   // Use the count as use wish. Code you write within this 
   // listener's block will be called whenever count is 
   // update/re-emitted.

   print(count); // prints 0
});

// Read the current stream value just once without subscribing
print(CounterService.instance.currentCount); // prints 0

How to Manipulate State (Streams) Within Services

Most times, each service will have multiple streams. This is as expected, given that, for a given logical state feature, there would be multiple variables affecting it. Therefore, where need be, don't hesitate to declare multiple BehaviorSubject (while exposing their streams) within the same service class.

For each stream, you want to control its data. That's why we are using BehaviorSubject, so that we can add values to it when there is a need to update state.

Different events (whether from the user or your servers) can be the cause of such state updates. You want to trigger state updates (or add values to streams) anytime those events occur.

You could always poll your backend and emit changes to your streams if any event happens. You could also emit values based on changes in other services. In addition, if need be, services should also expose relevant methods that will update their streams. In turn, other parts of the app can call these methods and trigger changes. The obvious advantage is that every listener will respectively get the new stream value emitted to them.

/* In counter_service.dart file */
import 'package:rxdart/rxdart.dart';

class CounterService {
  CounterService._();
  static final _instance = CounterService._();
  static CounterService get instance => _instance;

  final _counterBS = BehaviorSubject<int>()..add(0);
  Stream<int> get countStream => _counterBS.stream;
  int get currentCount => _counterBS.value;

  // Incrementing/Decrementing the counter will trigger state updates.
  void incrementCount() => _counterBS.add(currentCount + 1);
  void decrementCount() => _counterBS.add(currentCount - 1);
}

/* In another Dart file in the project */
import 'counter_service.dart'

void main() {
  final service = CounterService.instance;
  service.countStream.listen(print); // prints 0
  service.incrementCount(); // causes 1 to be printed
  service.decrementCount(); // causes 0 to be printed
}

For a more concrete example, let's say we have an AuthenticationService. It declares some _userBS and exposes a currentUser stream with type Stream<User?>, the user will be valid if authenticated or null if signed out. This auth service will naturally have signIn and signOut which can both add values to _userBS. The sign-up and login screens can each call signIn whereas the “switch account” and “log out” buttons can each call signOut.

/* In user.dart */
// A simple user with only email and username for demo purposes. 
// Your User model/schema would have more properties.
class User {
  final String email;
  final String username;

  const User(this.email, this.username);
}

/* In authentication_service.dart */
import 'package:rxdart/rxdart.dart';
import 'user.dart';

class AuthenticationService {
   AuthenticationService._();
   static final _instance = AuthenticationService._();
   static AuthenticationService instance => _instance;

   // User BehaviorSubject and its stream.
   final _userBS = BehaviorSubject<User?>()..add(null);
   Stream<User?> get currentUser => _userBS.stream;

   // signIn adds a new User to the stream.
   void signIn(String email, String username}) {
     _userBS.add(User(email, username));
   }

   // signOut sets the currentUser as null
   void signOut() => _userBS.add(null);

   // signIn and signOut methods that tamper the state could do other 
   // actions like recording analytics or carrying out navigation.
   // Also, they could do some validation or run some checks before
   // emitting values. The idea is that you get comfortable with
   // updating the values of BehaviorSubject (hence emitting streams) 
   // from controlled methods within the service.
}

Another state manipulation point is at initializing services. Some streams may warrant an asynchronous initializer before they should be used. You can define init methods in the services, and call the methods before calling runApp in the topmost main method in Flutter.

init methods may be "localStorage"-saved values from previous app runs. They can make API calls, check permissions, or set up EventChannel listeners. When you call them before runApp, be sure to call ensureInitialized() from WidgetsFlutterBinding before initializing the services. This is especially mandatory if any of the service init code will access a PlatformChannel.

/* authentication_service.dart */
// ... imports
class AuthenticationService {
  // ... other code

  // initialize the service and carry-out other setups if need be.
  Future<void> init() async => _userBS.add(await _fetchSavedUser());
}

/* main.dart */
import 'package:flutter/material.dart';
import 'authentication_service.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  // Initialize the service to be sure it is up and running before
  // launching the app. You could also initialize other services here.
  // Only do this if they are carrying out asynchronous executions,
  // and the results need to be ready before the UI launches.
  await AuthenticationService.instance.init();

  runApp(const MyApp());
}

How to Use Dart Streams in Flutter Widgets

Flutter comes with a built-in StreamBuilder widget. It takes a stream and a builder function. This builder function will get a BuildContext and snapshot data about the stream. The function should always return a widget.

When building UIs, you can wrap UI parts that depend on or display values emitted from app-wide streams in StreamBuilders. That way, once the stream emits a value, Flutter auto-rebuilds the children widget of the StreamBuilders with the latest values.

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

class CounterWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: CounterService.instance.countStream, // The stream to listen to
      initialData: CounterService.instance.currentCount, // Initial value
      builder: (context, snapshot) {
        // Check if the snapshot has data
        if (snapshot.hasData) {
          return Text('Counter: ${snapshot.data}', style: TextStyle(fontSize: 24));
        } else {
          // Handle any error or empty state
          return Text('Loading...', style: TextStyle(fontSize: 24));
        }
      },
    );
  }
}

StreamBuilders are great tools. However, there are times when it is not suitable to use them. For example:

• When a given UI screen depends on multiple streams that are exposed by the same or different services.

• When you want to do some computation on the stream values before rendering them in the UI.

In those cases, we need to listen to the streams separately in initState, set values through setState calls (to update the UI), and dispose of the StreamSubscriptions in the StatefulWidget's dispose method.

Listening to the streams separately allows us to perform any customizations or to merge data when the streams emit values. In addition, we make our UI code easier to read given that we’ve taken out logic-related code from the build method. However, we should do this only when necessary: StreamBuilders will, most of the time, be sufficient.

import 'dart:async';

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

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

  @override
  _CounterStatefulWidgetState createState() => _CounterStatefulWidgetState();
}

class _CounterStatefulWidgetState extends State<CounterStatefulWidget> {
  late StreamSubscription<int> counterSub;
  int count = CounterService.instance.currentCount;

  @override
  void initState() {
    super.initState();

    // Initialize the stream subscription
    counterSub = CounterService.instance.countStream.listen((count) {
      // Update state on new stream value
      setState(() => this.count = count);
    });
  }

  @override
  void dispose() {
    // Dispose of the stream subscription to avoid memory leaks
    counterSub.cancel();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Text('Counter: $count', style: TextStyle(fontSize: 24));
  }
}

The example above demonstrates listening and disposing from outside the build method. The example is not a good use case of when you should do that.

How to Make a Service Depend on Another

In complex applications, it's common to have services that depend on each other. The dependent service can listen to streams and call methods of the independent service. Also, the dependent service can import and reference the independent service just as we’ve been doing in UI code above.

For instance, if we are building an e-commerce app, a CartService may depend on an AuthenticationService to fetch carts and orders for the signed-in user. If the user signs out, some currentUser stream in the AuthenticationService will emit null. In turn, the listening CartService will update the cart. When next a new user signs in, it will fetch the new cart.

import 'package:rxdart/rxdart.dart';
import 'authentication_service.dart';

// Item model representing a cart item.
class CartItem {
  final String name;
  final int quantity;

  const CartItem(this.name, this.quantity);
}

// CartService to manage the user's shopping cart.
class CartService {
  // ...

  // Dependency on AuthenticationService.
  final _auth = AuthenticationService.instance;

  final _cartItemsBS = BehaviorSubject<List<CartItem>>();
  Stream<List<CartItem>> get cartStream => _cartItemsBS.stream;

  CartService() {
    // Listen to the currentUser stream in AuthenticationService.
    _auth.currentUserStream.listen((user) {
      if (user == null) {
        // User signed out, clear the cart.
        _clearCart();
      } else {
        // User signed in, fetch their cart.
        _fetchCartForUser(user.email);
      }
    });
  }

  // Method to clear the cart (called on sign-out).
  void _clearCart() {
    _cartItemsBS.add([]);  // Emit an empty list to clear the cart.
  }

  // Method to fetch the cart for a signed-in user (simulated).
  Future<void> _fetchCartForUser(String email) async {
    // ...
  }
}

Watch out for circular dependency problems when your services depend on each other. Circular dependency occurs when two services inter-depend on themselves. This scenario is usually inevitable as business logic grows.

When faced with it, lift the state they want to co-share to a different service and import this new service into the others. Another solution is to use Dart’s late keywords when importing the interdependent services. You can also find ways to ensure that variable accessing is within functions and not at some top-level declaration.

How to Improve Streams with rxdart Classes and Extensions

Asides from having service methods that update streams, you can also have new or improved streams based on existing ones, by using rxdart classes and extensions.

An example class is CombineLatestStream. It takes multiple streams and a combiner function to return a new stream that will re-emit the combined latest values of the source streams (depending on the optional combiner).

import 'package:rxdart/rxdart.dart';

class MultipliedCounterService {
  // ... 

  final _counterBS = BehaviorSubject<int>()..add(0);
  final _multiplierBS = BehaviorSubject<int>()..add(2);

  Stream<int> get combinedStream => CombineLatestStream(
        [_counterBS.stream, _multiplierBS.stream],
        (values) => values[0] * values[1],
      );

  void incrementCounter() => _counterBS.add(_counterBS.value + 1);
  void changeMultiplier(int mul) => _multiplierBS.add(mul);
}

Another good stream method is debounceTime. This is a stream extension that is useful for ignoring frequent emissions and processing the latest value after a delay (like when searching). An emission will only occur after the set duration and when there is no other emission in between that time. It helps avoid excessive API calls by waiting for a period of inactivity before emitting the latest value.

import 'package:rxdart/rxdart.dart';

class SearchService {
  // ... 

  final _searchQueryBS = BehaviorSubject<String>()..add('');

  // Stream with debouncing to emit values only after a
  // 300ms delay. For example: keystrokes will be bundled at once.
  Stream<String> get debouncedSearchQueryStream =>
      _searchQueryBS.stream.debounceTime(Duration(milliseconds: 300));

  void updateSearchQuery(String query) => _searchQueryBS.add(query);
}

The rxdart package provides more classes and stream extensions that will be useful to you, even if you don’t use this architecture. Check them out later on.

How to Update State in AppLifecycle Callbacks

When a user minimizes or leaves your application and comes back, some external things you rely on for data may have changed.

For example, when you prompt a user to grant any permissions, the operating system displays a popup over your application. Programmatically, the displayed popup caused your app to lose focus or go into background mode. When the popup is gone, your app resumes focus and you need to detect whether you got the permissions.

Equally, if you are managing the contents of a specific File Explorer Directory within your application (like converted music, encrypted docs, call logs, and so on), when your app goes in background, there could be changes to that directory from the user, which are worth detecting when the user comes back.

Sometimes, you may want to know when the user comes back to your application for authentication purposes, like terminating a session if they stayed away for too long and they need to re-authenticate. Other times, you may want to refresh app contents, to retain the user, as you can do if building a social media app.

In all these cases, we need a way to programmatically know when our app comes back to the user's focus after the user had left. Luckily, Flutter provides us with AppLifecycleState and a way to react to changes to them.

An app’s lifecycle refers to its various states while it is running. In Flutter, AppLifecycleState includes detached, resumed, inactive, hidden, and paused. In the above example cases, anytime the user comes back to the app, the app’s lifecycle state becomes AppLifecycleState.resumed.

We can react to lifecycle changes and call our service methods when a particular state occurs. To listen to lifecycle changes, your service class should add the WidgetsBindingObserver mixin to its declaration. Then you should override didChangeAppLifecycleState with a callback. This callback should handle states it is interested in.

import 'package:flutter/material.dart';

class PermissionService with WidgetsBindingObserver {
  // ...

  Future<void> checkPermissions() async {
    // ... 
  }

  @override
  Future<void> didChangeAppLifecycleState(AppLifecycleState state) async {
    if (state == AppLifecycleState.resumed) {
      await checkPermissions();
    }
    // you can check for the other states too and handle as expected.
  }
}

Flexibility in State Management

There are multiple choices and flavors for state management in the Flutter community. Most of the time, the same features can always be built with any state management of choice.

With that in mind, be flexible with state management architectures in Flutter. They are not some hard cast rules. Bend and play around with them to suit your unique app cases as there is no "one size fits all" here.

You can play around with streams and services. You could use getIt for obtaining singletons. getIt also allows you to obtain scoped singletons, that is, singletons attached to a navigator or a logical part of features (within a search for example).

You can also combine this architecture with others. Like declaring and managing streams as explained here but in providers or cubits. Or bringing in features of other architectures into services you declare as described in this article.

Just be sure you know what you're doing and that you understand how to coordinate the variables representing app state. Preferably, document your choice of architectures in your codebase for future reference.

Summary

In summary, we have explored an efficient architecture for managing app-wide state in Flutter using Dart streams and singleton services.

We've also seen how to manipulate streams, how to use them in UI code, make services depend on each other, improve streams using rxdart, and handle app lifecycle changes.

Remember that state management in Flutter is flexible, and no one solution fits all. Tailor your choice of state management architecture to fit your specific app needs.

In this article, we will explore how Flutter is platform-agnostic through how it renders user interfaces and through platform channels.

Table of Contents

• What is Platform-Agnosticism?
• How Native and other Cross-Platform Apps work
• How Flutter Apps are Different from their Host Apps
• How Does Flutter Render User Interfaces (UIs)?
• How Do Platform Channels Work in Flutter?
• Method Channels
• Event Channels
• Packages and Plugins
• Summary

What is Platform-Agnosticism?

Platform-agnosticism is a relative measure of how an app works the same way, irrespective of the operating system on which the app is running.

When we say that an app or tool is platform-agnostic, users expect the same experience on that given application across their different devices.

To be platform-agnostic is to be indifferent to the device or the operating system. Users don't know the technical hurdle behind an app's architecture. They want to enjoy your app. That's why you should give them the same experience across various platforms.

Flutter apps run in a platform-agnostic manner. Flutter apps work the same way on different platforms. This gives users (and developers) a seamless experience.

This article explores how Flutter does this. But before diving in, let's look at how native and other cross-platform tools handle their applications.

How Native and other Cross-Platform Apps Work

Operating systems or platforms (Android, iOS, Linux, macOS, Windows, and so on) specify how to build applications on them. They provide developers with the required APIs for apps to work.

When applications run, they constantly communicate with the underlying operating system. These native apps display buttons, icons, text, and other UI elements as platform-provided or OEM widgets. They also have access to device services like audio, Bluetooth, camera, and so on.

To build an application for a specific operating system, you normally use the programming language(s) and SDKs specified by that platform.

How Native Apps Work

Initially, if you wanted your app to be available on multiple platforms, you'd have to build the same app for each platform but with separate SDKs as each platform requires. This also implies separate codebases, different developers, and more coding time.

Well, nowadays, we mostly use cross-platform tools to build apps. They use the same codebase to build applications on multiple operating systems. They solve the problem of multiple developer skillset and long development time by using the same codebase.

Cross-platform application frameworks have their rules and languages too. Nevertheless, behind the scenes, they still compile the code you wrote into what each platform needs. Examples of such cross-platform tools include Flutter, React Native, Xamarin, and so on.

Each framework has its underlying mechanisms to compile across multiple operating systems. Other frameworks (outside Flutter) are usually tightly-coupled to the target platform. They use bridges to access platform services. The bridge also renders the app's UI by using the target platform's specific UI components. Furthermore, some cross-platform apps sometimes use webview to render UIs.

How Cross-Platform Apps Work

The above is not how Flutter works. Flutter uses a different and innovative approach to build cross-platform apps. It does this by ensuring that the app is the same irrespective of the host platform.

Flutter is platform-agnostic. Flutter apps are technically separate from their host app.

How Flutter Apps are Different from their Host Apps

When Flutter builds an app for a target platform, it ships an inner Flutter app and the Flutter engine within the built app. For example, when we build a Flutter codebase for Android, we will obtain an APK (an Android "installable"). Within this Flutter-built APK will be the Flutter engine and the Flutter app.

With this, the inner Flutter app performs similarly on each platform. When a user launches the "host" app on their device, the Flutter engine starts up and in turn, launches the inner Flutter app. Given that the engine runs Flutter, it will always run the same thing on whatever platform.

The advantage of separating Flutter apps from their host apps is platform-agnosticism. In other words, having the same app and user experience across every platform.

If the platform was to run the app contents directly or if it was a cross-platform bridge, we would have differences and discrepancies in how the app runs across various operating systems. This is because each operating system has its unique way of running apps.

Because Flutter apps run independently from their host apps, the Flutter framework lifts UI rendering and service access into the Flutter app (through the Flutter engine). That way, the Flutter app is more in charge and has better control over how the app feels.

For rendering UIs, the Flutter app draws Flutter widgets on a "canvas" in the host app. To access services, the Flutter app uses platform channels to interact with the host app when needed.

How Flutter Apps Work

How Does Flutter Render User Interfaces (UIs)?

At the core of Flutter's platform-agnostic UI rendering is a pipeline, orchestrated by multiple UI layers. These layers include the embedder, the Flutter engine (with Skia or Impeller), and your Flutter App's UI.

The embedder serves as the bridge between the Flutter engine and the host platform. It provides an agnostic Application Binary Interface (ABI) for the Flutter Engine. It is written in the host platform's native programming language. It is deployed per platform. In other words, each platform has its embedder. Flutter uses the embedder to interface with the underlying operating system.

The Flutter engine executes Dart code, manages assets, handles events, and most importantly, renders UI. It draws (or rasterizes user interfaces) the same way irrespective of the platform. Hence, achieving platform-agnosticism.

The Flutter engine uses Skia or Impeller for low-level rendering tasks. Skia is an open-source graphics library with a robust set of drawing capabilities. Skia makes it possible to create smooth UIs.

Recently, we've got Impeller. Impeller provides a new rendering runtime for Flutter. It is already the default rendering tool in iOS devices and is coming soon to Android. It is an improvement to and should replace Skia.

On the host platform, Flutter accesses a black "canvas" (or the screen) and renders with its tools. On the web, it is the same thing but with a slight difference. There is no embedder (because there is no operating system). However, we convert UI directly from the Flutter framework into CanvasKit rendering.

Whether we are using the embedder and Flutter engine to render an app on any operating system or relying on Dart to JavaScript transpilation to render on browsers, Flutter apps are the same on the painted UI.

The "Canvas"es used by Flutter for Each Platform

The rendering layers of Flutter Apps in Operating Systems and Browsers

This entire architecture makes it possible that if a new operating system arises, we will only need to replicate the embedder with the expected Flutter engine ABI for that new OS. Once done, all existing Flutter apps will easily work on the OS.

Aside from UI rendering, Flutter is also platform-agnostic with the help of Platform Channels.

How Do Platform Channels Work in Flutter?

In Flutter, platform channels serve as important communication routes at runtime between the Flutter framework and the host app (or the underlying native platform). Platform channels act as bridges between platform-agnostic Dart code and platform-specific functionalities.

Platform channels enable seamless integration of platform-specific features into Flutter apps. With them, you can leverage the capabilities of each target platform while maintaining a unified codebase.

With platform channels, Flutter achieves platform-agnosticism by abstracting away platform-specific details. As a result, you can write Flutter code that can seamlessly run on multiple platforms without extraneous modification.

There are two types of platform channels: method channels and event channels.

Method Channels

They are the most used. They facilitate bidirectional communication between Dart code and native platform code.

Through method channels, Flutter apps can invoke platform-specific methods, passing parameters and receiving results asynchronously. The reverse is also obtainable. The host (or native side of the) app can call methods defined inside the Flutter app.

This allows you to access platform-specific APIs, system services, and hardware functionalities, such as accessing device sensors, interacting with native UI components, or integrating with platform-specific SDKs.

Systematic Diagram of MethodChannels

Event Channels

Event channels transmit asynchronous events from the native platform to Dart code. They are useful in cases where the native platform needs to notify the Flutter app of asynchronous events or updates.

Good examples of such scenarios include:

• Receiving sensor data in real time
• Handling push notifications
• Monitoring system-level events, and so on.

Event channels are crucial. With them, you can build reactive, event-driven apps that respond to changes in the underlying platform in a platform-agnostic manner.

Your Dart code needs to listen to event streams. These streams' values are emitted from the underlying platform. But how you handle them within the Dart facing side of the Flutter is usually the same way, hence platform-agnosticism.

Packages and Plugins

A Flutter package is reusable code that can extend your app. More than 25000 Flutter packages are deployed on pub.dev. There is already a package(s) of platform-specific features that you want to implement in your app.

The Flutter framework itself is relatively small. It is the contribution of the community that builds these packages that makes the entire ecosystem large.

While there are many packages for Flutter-direct features, some provide platform-dependent features (like Camera, Location, Permissions, and so on). These platform-dependent packages use platform channels and plugins behind the scenes.

Plugins in Flutter are packages that encapsulate platform-specific functionality and expose them to Dart code through method and event channels. They act as wrappers around platform channels, providing a unified API surface for accessing platform-specific features. They abstract away the complexities of interacting with platform channels.

However, if there is no plugin for a feature you are building (which is rare), you can use platform channels. They make the Flutter code work the same way, no matter the platform. You will have to write the platform-specific method or event handlers in the programming languages specified by the involved platforms.

Platform Channels Programming Languages

Summary

Understanding Flutter's platform-agnosticism is important in appreciating the innovative architecture powering Flutter.

From how it renders user interfaces the same way on every device, to how it can run device-specific code at runtime, Flutter gives you a smooth developer experience and highly performant apps.

When next you use Flutter, don't be surprised how it achieves the same application on different devices.

Cheers!

In this article, we will explore how we can obtain a valid BuildContext outside the scope of its natural availability.

Table Of Contents

• Introduction
• The essence of the BuildContext in Flutter
• The need for a BuildContext outside UI code
• Having a globally available navigatorKey
• A note on Navigator 2.0
• Using navigatorKey's NavigationState to show toasts
• Summary

Introduction

Flutter is a UI toolkit for building desktop, mobile, and web apps. Flutter is a framework that allows you to build apps in the Dart programming language.

In Flutter, you build UIs by composing widgets. A widget is any logical piece of what is renderable on the screen like Icon, Image, Text, and so on.

Composing widgets involves setting them as a child or as children of other parent widgets. In other words, you are building a widget tree. All the widgets in your UI tree have access to the BuildContext.

The Essence of the BuildContext in Flutter

The BuildContext provides important app-wide configuration information to all widgets in the widget tree.

The BuildContext is to Flutter widgets what water is to our body. Just as water circulates round our system with nutrients and oxygen, so does the BuildContext provide runtime-specific values to every widget in our apps.

In Flutter, you commonly create a widget by extending the StatelessWidget or StatefulWidget (and its State) classes.

In both cases, you have to override the build method. In the build method, you must return another widget. By this way, you keep building the widget tree.

Image Source: https://groups.google.com/g/flutter-dev/c/jfPgd5FS6EM

All build methods take only one argument: the BuildContext. You need the BuildContext in Flutter to render the UI. It is indispensable. The Flutter framework itself provides the BuildContext to each widget's build method.

The BuildContext gives you access to getters and methods like:

• findAncestorStateOfType: a typed method that returns the State object of the specified StatefulWidget.
• getInheritedWidgetOfExactType: a typed method that returns a requested widget type that is found upper in the widget tree.
• mounted: a bool which tells whether the widget in context is in view.

There are other useful getters and methods available on the BuildContext. Outside them, the BuildContext is also important because through it, we can obtain the app's active instance of specific classes. For example: MediaQuery, Navigator, Theme, and so on.

A common pattern is to call the static .of method on the class of interest and provide our BuildContext (or just "context") to this .of method.

final isLandscape = MediaQuery.of(context).orientation == Orientation.landscape;
final hasConfirmed = Navigator.of(context).pop(false);
final lightTheme = Theme.of(context).copyWith(brightness: Brightness.light);

The .of is the most common pattern. However, there are other more direct, specific, and rare use cases of such static getters that rely on the context.

final isDarkTheme = Theme.brightnessOf(context) == Brightness.dark;

You can also create static getters of instances of your classes that rely on the BuildContext. You can learn more about how to do that (through InheritedWidget) here.

As we see, the following are why we need the BuildContext:

• To build widgets,
• To access resources,
• To obtain instances of classes,
• and so on.

The need for a BuildContext outside UI code

The BuildContext is naturally available inside all build methods and inside the State class of StatefulWidgets. Most method calls with context inside these scopes will work as intended.

In minor occasions, you will need to access the BuildContext from where it is not naturally available. You will want to obtain runtime instances outside of UI code (outside build methods and State classes).

This is usually difficult as we can't instantiate a BuildContext of our own. We only have access to one once our app has started running.

Popular reasons of accessing the BuildContext this way is either when performing navigation, when showing alerts and modals in non-UI code, or when triggering UI updates from changes in the app's state architecture.

Also, when a user opens a notification, we want to navigate the user to the target screen if the app is already open. We need the BuildContext to do this.

Having a globally available navigatorKey

A solution to always having a BuildContext in Flutter is by providing one yourself at the start of the application.

The top-most widget of Flutter apps is usually either CupertinoApp, MaterialApp, or WidgetsApp. In other words, they are the entry-point of our application.

These "app" widgets take an optional navigatorKey parameter. It has the type of GlobalKey<NavigatorState>. This NavigatorState-specific GlobalKey has a BuildContext attached to it once the app is running.

When you create a navigatorKey and give it to the top-most "app" widget, your Flutter app will keep the BuildContext it is using in your navigatorKey. That way, you can have access to the BuildContext wherever you have access to the navigatorKey.

Create and expose the navigatorKey as a static final variable from a global utility class. Provide it to the top-most "app" widget. Then obtain the context from this globally-available class wherever you need it.

/* In services/navigation_service.dart */
class NavigationService {
  static final navigatorKey = GlobalKey<NavigatorState>();

  // ... other methods and getters
}

/* In main.dart */
import 'package:flutter/material.dart';

import 'services/navigation_service.dart';

void main() => runApp(const MyApp());

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      navigatorKey: NavigationService.navigatorKey, // line of interest
      home: const Scaffold(body: Center(child: Text('BuildContext'))),
    );
  }
}

/* In services/modal_service.dart */
import 'package:flutter/material.dart';

import 'services/navigation_service.dart';

Future<T?> showModal<T>(Widget modal) async {
  return await showModalBottomSheet<T>(
    context: NavigationService.navigatorKey.currentContext!,
    backgroundColor: Colors.transparent,
    isScrollControlled: true,
    builder: (_) => modal,
  );
}

In the example above, you can see how we can call showModalBottomSheet from a non-widget file by using the context from the navigatorKey. This will only work if this key has been attached to the top-most "app" widget as shown in the code snippet.

This way of accessing the BuildContext has always been around. We can see it in use in the Stacked Architecture.

You could keep the navigatorKey in an entirely different class from some NavigationService. It could also be a standalone global variable in your Flutter project. Furthermore, you could make it available through the state management architecture you are using.

The manner in which you make the navigatorKey globally available is up to you. What is necessary is that you provide one to Flutter when you need the BuildContext outside UI code.

A note on Navigator 2.0

There is a special configuration that is worthy of mention at this point.

The top-most "app" widgets (CupertinoApp, MaterialApp, and WidgetsApp) all have a .router constructor. This constructor is different from the direct equivalent because it creates an app that uses a Router instead of a Navigator.

Specifically, the .router apps allow us to perform declarative navigation (router.go) instead of only imperative navigation (navigator.push and navigator.pop).

Declarative navigation works well with deep linking (when mobile apps open URLs) and with the browser history (a plus to Flutter web).

These .router constructors don't take a navigatorKey argument. However, they can accept various router-specific classes as arguments. In these classes, you can provide a navigatorKey in one way or the other.

For example, go_router is a well-known package for Navigator 2.0 in Flutter. It abstracts out the complexities of those router-specific classes.

Now, the GoRouter constructor, as you will expect, accepts a navigatorKey argument. This way, if you are using it, you can still have access to the BuildContext in any non-UI code in your Flutter project.

Using navigatorKey's NavigationState to show toasts

An added advantage of having an attached navigatorKey is when we want to toast information to the user.

We can do this by adding an OverlayEntry (with a toast widget) into the overlay of NavigatorState that is attached to our navigatorKey.

With the help of a Timer, the toast gets dismissed after a few seconds:

/* In services/toast_service.dart */
import 'dart:async';

import 'navigation_service.dart';

Widget _toast(String text) => Container(
    padding: const EdgeInsets.fromLTRB(16, 12, 16, 12),
    decoration: BoxDecoration(
      borderRadius: BorderRadius.circular(6),
      color: Colors.teal,
    ),
    child: Text(text),
  );

class ToastService {
  static OverlayEntry? _entry;
  static Timer? _timer;

  static show(String text) {
    _dismiss();
    _entry = OverlayEntry(builder: (context) => _Toast(text));
    NavigationService.navigatorKey.currentState!.overlay!.insert(_entry!);
    _timer = Timer(const Duration(seconds: 5), _dismiss);
  }

  static _dismiss() {
    try {
      _timer?.cancel();
      _timer = null;
      _entry?.remove();
      _entry = null;
    } catch () {
    }
  }
}

/* In services/auth_service.dart */
import 'toast_service.dart';

class AuthService {
  static void login({required String email, required String password}) async {
    // ... calling the API

    // toast after a successful login
    ToastService.show('Welcome Back!');
  }
}

Summary

"context" is something you will always use in Flutter.

When you need it outside the build method (or State classes), create a navigatorKey and attach it to the top-most "app" widget.

You can then access the same context that your UI code uses from this key from anywhere within the Flutter project.

Cheers!

But if you ever lose access to all your 2FA methods, you have lost your account. How do you prevent such loss?

In this article, we will look at two-factor authentication (2FA), its methods, and how to prevent account loss because of using it.

Table of Contents

• What is Two-Factor Authentication (2FA)?
• Methods of Two-Factor Authentication
• The problem with Two-Factor Authentication
• How to Protect Yourself from Losing Access to Your Accounts
• Backup and write down the recovery code(s)
• Backup and write down the authenticator app seed
• Set up more than one 2FA method
• Always update 2FA methods
• Set up recovery email and phone
• Summary

What is Two-Factor Authentication (2FA)?

Two-Factor Authentication is an extra security setting for your account that many platforms have enabled.

It is an extra security setting because you already have some "first" way of authenticating yourself. This "first" way could be password sign-in or federated identity sign-in. Federated identity means signing in with another provider, like Apple, Facebook, Google, and so on.

Two-Factor authentication helps reduce unauthorized access to your data or account. It is a second sign-in step to verify that you are the owner of the account. So, in addition to your first sign-in method, you will have to complete this second step (hence two-factor) to access your account.

Two-Factor authentication is not about using and securing your passwords. That one is basic account security. We are talking about an advanced security step where, after entering your password, you still need to enter some code or complete some action before you gain access to your account.

In this article, platform means any place where you can sign in and sign out. freeCodeCamp, LinkedIn, and Twitter are examples of platforms. In this article, a platform is a place where you have an account.

Some platforms don't offer 2FA. You might have relatively little data with them. So 2FA would be overkill there. On the other hand, the major and mainstream platforms where you can have an account offer 2FA. These are platforms where a user's account is worth hacking.

In most platforms, 2FA is optional. In a few, however, you are required to set up 2FA from the very first time you access the account and you can't turn it off. In other words, 2FA is a must-do on a few platforms.

You should set up 2FA where it is available. To set up 2FA, go to the security settings of your account on a supporting platform. Set up 2FA using at least of one the specified methods and you are good to go. On subsequent sign-ins, you will need to complete 2FA to enter the account.

Methods of Two-Factor Authentication

Methods of 2FA refer to the various ways to set up 2FA. They are as follows:

1. Security Key 2FA
2. Phone number 2FA
3. Authenticator app 2FA
4. Sign-In prompt
5. Recovery code(s)

Security keys are USB or Bluetooth keys that you can connect to your device. They are physical 2FA devices and seem to be the most secure. This is because it is highly unlikely that a hacker would come and steal the key from your house.

To set up 2FA using keys, plug in the key or connect via Bluetooth and complete the steps. You can then use the key in consequent sign-ins. You have to buy these keys from the market or online to use them.

Phone number 2FA involves receiving a One-Time Password (OTP) code either via call or SMS. Provide a phone number and the platform sends an OTP to it. Sometimes, you could receive an automated call with the code. Either way, enter the code in the platform and you have successfully set up the phone number 2FA.

On subsequent sign-ins to access your account, after entering your password, you will receive an OTP code to that phone. Enter the code to gain access to your account.

Authenticator apps generate a 6-digit code every minute. There are many authenticator apps, like Google Authenticator, Microsoft Authenticator, and others.

To set up an authenticator app, you either scan a QR code or enter a seed phrase. The platform where your account resides will provide you with either of these. Scan or enter the phrase and you will keep getting a unique 6-digit code every minute.

In the next sign-ins, after entering your password, paste the latest 6-digit code from the authenticator app and you are in.

Sign-in prompts are not as common as other 2FA methods. Not all platforms have this feature. It involves authorizing your sign-in from an app or website of that platform where you are already signed in.

GitHub and Google have these features. With the GitHub app, you can complete 2FA by entering a number on the screen from the app/website you signed in to. Google does it together with your Android device and your Google account.

Aside from the above 2FA methods, we also have recovery codes. Recovery codes are a one-time-use code that you can use to complete 2FA. You can access them under the 2FA settings of your account.

In fact, once you set at least one 2FA method on your account, the platform autogenerates these recovery codes for you. These codes are like a backup option for 2FA. You are meant to use them when you don't have access to the other 2FA methods.

The Problem with Two-Factor Authentication

The problem with 2FA is that if you lose access to all the methods you've set up, you've permanently lost access to that account. Let me explain.

2FA ensures that it is the correct user that is accessing an account. That's why we have those above secondary methods aside from your password. 2FA can only be enabled or disabled while signed in.

But aside from the recovery codes, there is no other recovery mechanism. If you lose the security keys, phone number, devices with the authenticator apps and previous sign-ins, and the recovery codes, your account is gone. Not even the account support for that platform can help you.

This is not the common "Forgot Password" feature, where the platform sends a unique link or code to your email or phone to reset your password. This is 2FA. Once you lose all 2FA methods you had set, your account is gone. Support can't give you the recovery codes because they don't know them. Those codes are encrypted with your account's access (only you can access them when you are signed in).

Does this mean that you shouldn't set up 2FA?

No. It means that in addition to setting up 2FA, you have to guard your 2FA methods. Remember that it is security that led us to 2FA. Well, 2FA itself also needs security. So you have to secure it.

From here, we will be looking at the various things you can do to prevent account loss due to Two-Factor Authentication.

How to Protect Yourself from Losing Access to Your Accounts

1. Backup and write down the recovery code(s)

All platforms that grant 2FA also give a recovery code(s). Always back them up. Copy and save the recovery codes securely somewhere of your choice. Hide them discretely online. Encrypt them in some vaulted storage.

Most importantly, write them down. Like use your hand and write with a pen in some diary or book you won't lose. You can equally print and store them with your documents and certificates. Just protect each recovery code per platform in the most secure way you're able.

Also, don't store the recovery code of an account in that same account. No one keeps spare keys inside the house. You give out your spare keys to trusted persons or keep them in other places where you can go retrieve them when need be. This is because if your main key goes missing while you are out, you can go and retrieve the spares. You can't retrieve the spare keys when they are inside the house and you are locked out.

In the same vein, it makes no sense to keep the recovery codes of your Google Account's 2FA inside your account's Google Drive or in a private Google Doc owned by the same account. When you will need it, you can't get it.

Recovery codes are one-time-use codes. You can't reuse the same recovery code for another 2FA session. You shouldn't really be using your recovery codes. If you start using them, it is a sign that you need to either update your 2FA methods, turn off 2FA temporarily, or regenerate a new set of recovery codes (to replace the used ones).

You can always copy out your recovery codes. Also, you can always generate a new set of recovery codes in each platform. Every platform permits that. Remember that you have to be signed in to do all these things.

Also, anytime you disable or turn off two-factor authentication in your account settings, the previous recovery codes become invalid. If you enable 2FA again, you will need to re-backup and re-write the new recovery codes.

Make sure you store recovery code(s) for each platform in multiple and different places.

2. Backup and write down the authenticator app seed

When setting up the authenticator app 2FA, don't use the QR code option. Go for the seed option. The seed for authenticator apps comes as a series of about 20 to 40 alphanumeric characters. When the platform shows you this seed, first write it down.

Write down the authenticator app seed in your diary or in some book you've set aside for backup. If possible, copy it out and print it. Equally backup the seed for each platform in some other online media where you can retrieve it from. You want to minimize your chances of losing these seeds.

Each minute, authenticator apps generate 6-digit codes based on the seed and not based on the app itself or the platform. If you paste that same seed into another authenticator app, the two apps will be generating the exact same 6 digits, every minute. In fact, if you re-use that exact same phrase to recreate another 2FA entry in the same authenticator app, the two entries will be generating the same 6-digit code per minute.

This is why the authenticator app seed is as important as the 2FA recovery codes. If you lose access to the device that your 2FA authenticator app is on, you can put your seeds in another authenticator and get back the 6-digit codes for 2FA. Protect these seeds too. Because if someone has both your passwords and seeds, then they have access to your accounts.

Backing up and writing down authenticator app seeds is necessary and it is under-preached. Many people don't realize that device loss means account loss if the authenticator app was their only 2FA method and if they didn't save the seed and recovery codes somewhere.

A device crash can happen. The Operating System might crash and you may lose apps and data. The authenticator app could be mistakenly uninstalled. Backing up and writing down the seeds prevent these circumstances from affecting your 2FA setups.

You can reinstall the authenticator app and reconfigure the entries of each account from your saved seed, without needing to go to the account settings of each platform. Also, you will be capable of continuing to use your two-factor authentication methods, without needing to re-backup or re-write down a new set of recovery codes.

If you've already set up the authenticator app 2FA, and you didn't save the original seed your account's platform gave you, please, please, please go and reconfigure the authenticator app 2FA in your security settings. You might have to just disable only the authenticator app and turn it back on. While re-enabling, make sure you back up and write down the seed. You don't want to live the experience of being locked out of your account.

3. Set up more than one 2FA method

Setting up more than one method for two-factor authentication reduces your chances of account loss. The idea is to ensure that you always have access to at least one (if not all) 2FA methods. You can set up all the available 2FA methods per platform account.

For USB/Bluetooth security key, you can use the same key for all your accounts across various platforms. For your phone number, you can use the same phone number across each account on each platform. (But some platforms don't permit you to have multiple accounts with the same phone number. Have this in mind if you fall into that category).

The authenticator app seed for each account per platform is different. But you can use the same authenticator app for all accounts in which you've set up 2FA. Just remember to back up and write down the seeds as mentioned in the previous section.

So for each platform, you want to ensure that you have set more than one 2FA method. You can receive an SMS with some phone number. You have a working authenticator app. You've backed up and written down the authenticator app seed and 2FA recovery codes. And where you can, you've equally set up the USB/Bluetooth security key.

4. Always update 2FA methods

Things can happen that warrant updating your 2FA methods. Updating 2FA methods include removing or adding some methods. You can equally change the settings of the same method.

For example, let's say you never had a security key in your account. But you had set up 2FA with a phone number and authenticator app. Then you just bought a new security key. You can go and add the security key in your 2FA settings as a new method. On the other hand, if you lose your USB/Bluetooth security key, you can disable the security key option. Then when you buy a new one, you can put it back in your settings.

If you lost your all backups and written-down versions of your authenticator app seeds and 2FA recovery codes, you can regenerate new ones and re-backup and re-write down. You really shouldn't lose everything. Such loss is not good. Well, anything is possible. Prevention is the only remedy as there is no cure in the world for complete 2FA loss.

Also, it is okay to turn off 2FA if you need to. 2FA is recommended and necessary. But if you see the need to, turn it off for the moment. Then set it up back sometime later on.

5. Set up recovery email and phone

Backup email and phone are not really a 2FA thing. The reason is they are always there whether you configure two-factor or not. Most major platforms permit you to set a recovery email and or a recovery phone number for your account. These recovery assets come in handy when you forget your password and not when you lose 2FA.

Well, we are talking about security, so it is worth mentioning that you should have recovery email and phone properly set up where possible.

In some platforms, your account or your recovery phone number can be different from your 2FA phone number. Your 2FA phone number must always be one where you can receive an OTP (via call or SMS) and use it to complete the 2FA step.

Summary

You want to lock out malicious access to your account. But you don't want to lock out yourself.

In this guide, we've looked at how to best use the two-factor authentication feature across various accounts. At the same time, we've also seen how you can ensure that you don't lose access to your account because you tried securing it in the first place.

Back up and write down recovery codes and authenticator app seeds. Set up multiple 2FA methods. Always review and update your 2FA settings. Do these and be rest assured of the best online security.

Cheers!

This article will explain what Stacked architecture is and will guide you through creating a simple Todo App in Flutter with Stacked.

Table of Contents

• Intro to App State and Flutter Widgets
• Why Do You Need State Management Architectures in Flutter?
• What is Stacked Architecture?
• About the Todo App We Will be Building
• How to Setup Flutter and the Todos Service
• How to build the Todo App's UI
• Note on Other Stacked Features
• Summary

Intro to App State and Flutter Widgets

State refers to any data you use in rendering your UI. It could be user-generated or from your servers or backend.

In Flutter, the app's User Interface (UI) is a function of State. In other words, your UI at any given point in time is a visual representation of your app's state.

Still, in Flutter, you use widgets to build different parts of the app's UI. A widget in Flutter is a piece or unit of the UI. Essentially, a Flutter application is a big tree of widgets. Examples of widgets are AppBar, Container, Icon, Image, Text, and so on.

Flutter has two types of widgets: StatelessWidgets and StatefulWidgets. You use StatefulWidgets in Flutter to build widgets that have State.

To tell Flutter that some state has changed in your application, you call the [setState](https://api.flutter.dev/flutter/widgets/State/setState.html) function (available only inside StatefulWidgets) and Flutter will rebuild the widget tree based on state data that has changed.

Widgets in Flutter don't change. They are immutable. Flutter paints UIs efficiently at about 60 frames per second.

At each frame paint, Flutter checks the widget tree. If any widgets have changed, Flutter gets rid of them and replaces them with new widgets that have the changed state.

Why Do You Need State Management Architectures in Flutter?

setState is good. It is an optimal way of handling UI and state because it encourages a declarative programming style (which is the best way to code UIs).

But then as your Flutter codebase grows, you will realize that you will always make calls to setState. Your Flutter app will have so many widgets that depend on huge and changing state data. This causes your code to be clogged up.

Using state management architectures across frameworks and libraries helps with Separation of concerns, clean code, and scaling. State management is also helpful when multiple developers are contributing to the same codebase. Architectures also help with code testability.

So to build robust apps, you should use state management where you need it. By default, setState is your go-to option for state management. But as you begin adopting architectures, you will use other available state management options in Flutter.

In Flutter, every widget has a build method that returns its tree of widgets. The build method takes a BuildContext with which it can access important data about the app or perform tasks like navigation or showing dialogs.

InheritedWidget is a built-in approach for accessing state from a widget higher in the widget tree. It accesses state from this higher widget with the help of the BuildContext.

[ChangeNotifier](https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html) is a Flutter class that does as its name says. It notifies listeners about changes in its values. You can extend this class and call its [notifyListeners();](https://api.flutter.dev/flutter/foundation/ChangeNotifier/notifyListeners.html) method which you can in turn use to update the UI where need be. Popular state management options in Flutter use ChangeNotifier. For example, Provider.

Some state management architectures find a way to navigate or show dialogs without the BuildContext in the build method. That way they can do these crucial parts of the app in files not containing widgets. And if they need to update the UI, they use notifyListeners(). Such is the case with Stacked architecture.

What is Stacked Architecture?

Stacked is a modern Flutter state management with top-notch separation of concerns and dependency injection.

Separation of concerns involves separating all UI code from logic code. Such separation is important for the maintainability of your Flutter project.

For example, with separation of concerns properly set up in your codebase, if there are updates to your backend API, you would only need to update the files that deal with the API logic. You won't necessarily need to update the UI code. This minimizes bugs that could happen while coding.

Dependency injection (or inversion of control) is a popular programming technique. For a given block of code, dependence injection is the fact that that block does not configure the things it needs to function (dependencies) by itself.

With dependency injection, you provide a class with the services (dependencies) it needs for proper functioning. In turn, these services abstract out and handle the app's business logic.

For example, a weather service can take care of fetching weather details and a weather display widget will use this service to display the data. This widget doesn't know how to set up the service. All it knows is that it will receive the weather data it needs to display from the weather service class in some way.

Stacked implements separation of concerns and dependency injection by building Flutter code around 3 entities: Views, ViewModels, and Services.

Views handle only UI code and are linked to ViewModels. ViewModels accompany views and handle UI logic. ViewModels use services. Views should never access services.

Stacked was founded by Dane Mackier and is now being maintained by the community. Dane Mackier is a GDE (Google Developer Expert) for Dart and Flutter. He used other popular state management architectures and combined their advantages in building Stacked.

Note that Stacked uses ChangeNotifier.

About the Todo App We Will Be Building

To keep things simple, we will build a one-screen dark-mode Todo App with Stacked architecture.

The app will display a message if there are no todos yet. However, if there are Todos, it will display all the todos one after the other.

Each Todo will have a "checkable circle" at its left to indicate whether it has been completed or not. At its right, a Todo will have a button (with a dash icon) to remove the Todo. The Todo's text content will fill the center or major part of the screen.

We will also have a floating action button (with a plus icon) to create new todos.

In addition to the above, we will store Todos to some browser or device storage with Hive. As a result, on closing and re-opening the Todo App, all previously created Todos will be restored.

Todos been restored after browser reload

Because this is Stacked architecture, we will have a TodosService that will take care of managing Todos. We will also have a TodosScreen (for the UI). The TodosScreen will have a View and a ViewModel.

That said, let's start coding.

If you don't want to code along, the final code is here.

How to Setup Flutter and the Todos Service

1. Install Flutter

First, you'll need to have Flutter installed and working properly. If you do, you can get to step two. You can also get to step two if you don't want to follow along.

If you don't have Flutter installed, install it by following the steps for your operating system here.

Run the flutter doctor -v command in your terminal. If all the listed options have a good check or green color, then you are good to continue. If any of the results have errors, search the error online and you'll find solutions to the problem.

2. Create the Flutter Project

Run the following command to create a new Flutter project:

flutter create todo

This creates a new Flutter project with todo as the name of the app. If you want a different app name (aside from todo), use it instead of todo.

3. Add the Packages

We need to add the [stacked](https://pub.dev/packages/stacked) Flutter package to project. It will provide us with necessary classes (like ViewModels), given that we are building with the Stacked Architecture.

We also need to install another package to help with dependency injection or services. To keep things simple, we will use the [get_it](https://pub.dev/packages/get_it) package for "getting" services in this Todo App.

Because we want to persist todos across app closes with Hive, we will also need to add the [hive](https://pub.dev/packages/hive) and [hive_flutter](https://pub.dev/packages/hive_flutter) packages.

Change the terminal's focus directory to be inside the todo Flutter project you just created above. Run the following command in the same terminal:

cd todo

If you used a different app name, use it with the cd command instead of todo.

Run the following command in your terminal to add get_it, hive, hive_flutter, and stacked in the Flutter project.

flutter pub add get_it hive hive_flutter stacked

4. Create a Todo Model

We are building a Todo App meaning that we will be interacting with Todos. A Todo, in the context of the code, is an entity that we will be manipulating.

To keep things simple, a Todo will be a Dart class with just three properties:

1. id: Uniquely identifying string for each Todo.
2. completed: Boolean value to indicate the status of the Todo
3. content: The actual text content of the Todo.

Open the Flutter project in your favorite editor.

Create a new folder with name models inside the lib folder. Inside this newly created models folder, create a new file with name todo.dart.

Paste the following into the newly created lib/models/todo.dart file:

class Todo {
  final String id;
  bool completed;
  String content;

  Todo({required this.id, this.completed = false, this.content = ''});
}

Notice that the id property is required for each todo. However, by default, a Todo is not completed and has empty content.

5. Create the TodoAdapter (for Hive)

Hive works well with primitive types (like bools, ints, strings, and so on). But to properly retrieve and save custom types (like our Todo model) from and to browser or device storage, Hive needs us to create adapters for our custom types.

Create a file named todo.adapter.dart in the lib/models folder. The todo.adapter.dart should accompany the todo.dart file.

Paste the following into the newly created lib/models/todo.adapter.dart file:

import 'package:hive_flutter/hive_flutter.dart';

import 'todo.dart';

class TodoAdapter extends TypeAdapter<Todo> {
  @override
  final int typeId = 1;

  @override
  Todo read(BinaryReader reader) {
    final numOfFields = reader.readByte();
    final fields = <int, dynamic>{
      for (int i = 0; i < numOfFields; i++) reader.readByte(): reader.read(),
    };
    return Todo(
      id: fields[0] as String,
      completed: fields[1] as bool,
      content: fields[2] as String,
    );
  }

  @override
  void write(BinaryWriter writer, Todo obj) {
    writer
      ..writeByte(3)
      ..writeByte(0)
      ..write(obj.id)
      ..writeByte(1)
      ..write(obj.completed)
      ..writeByte(2)
      ..write(obj.content);
  }
}

The above code basically provides read and write methods for Hive to retrieve and store a Todo.

6. Create the TodosService

Create a new folder with name services inside the lib folder. Inside this newly created services folder, create a new file with name todos.service.dart.

Paste the following into the newly created lib/services/todos.services.dart file:

import 'dart:math';

import 'package:hive_flutter/hive_flutter.dart';
import 'package:stacked/stacked.dart';

import '../models/todo.dart';

class TodosService with ReactiveServiceMixin {
  final _todos = ReactiveValue<List<Todo>>(
    Hive.box('todos').get('todos', defaultValue: []).cast<Todo>(),
  );
  final _random = Random();

  List<Todo> get todos => _todos.value;

  TodosService() {
    listenToReactiveValues([_todos]);
  }

  String _randomId() {
    return String.fromCharCodes(
      List.generate(10, (_) => _random.nextInt(33) + 80),
    );
  }

  void _saveToHive() => Hive.box('todos').put('todos', _todos.value);

  void newTodo() {
    _todos.value.insert(0, Todo(id: _randomId()));
    _saveToHive();
    notifyListeners();
  }

  bool removeTodo(String id) {
    final index = _todos.value.indexWhere((todo) => todo.id == id);
    if (index != -1) {
      _todos.value.removeAt(index);
      _saveToHive();
      notifyListeners();
      return true;
    } else {
      return false;
    }
  }

  bool toggleStatus(String id) {
    final index = _todos.value.indexWhere((todo) => todo.id == id);
    if (index != -1) {
      _todos.value[index].completed = !_todos.value[index].completed;
      _saveToHive();
      notifyListeners();
      return true;
    } else {
      return false;
    }
  }

  bool updateTodoContent(String id, String text) {
    final index = _todos.value.indexWhere((todo) => todo.id == id);
    if (index != -1) {
      _todos.value[index].content = text;
      _saveToHive();
      return true;
    } else {
      return false;
    }
  }
}

Understanding Reactive Services in Stacked

The TodosService class declaration comes with a ReactiveServiceMixin. This is where Stacked features start coming in.

With Stacked, services by default are not reactive. However, you need to make a service reactive if any other parts of the project code (other services or ViewModels) have to "react" to changes in the values of the service.

If a service is reactive, that is, has the ReactiveServiceMixin, it means that that service will have at least one ReactiveValue among its properties. It also means that the service has to call [listenToReactiveValues](https://pub.dev/documentation/stacked/latest/stacked/ReactiveServiceMixin/listenToReactiveValues.html) with a list of the reactive values in that service.

The idea behind reactivity is that when the reactive values change (either from user interaction or your backend server), the service can update listeners of that value that there are changes. In turn, these listeners can rebuild UIs just as if setState was called from within the widget.

About the TodosService class

In our case, the TodosService class has only one private reactive _todos field. _todos keeps a ReactiveValue of TodoList. This private reactive _todos is also given to the list of reactive values to listen to in the constructor (listenToReactiveValues).

This is where Hive comes in. With Hive, you store data as key-value pairs inside boxes. For our app, we are using a 'todos' box. Inside that box, we are using the 'todos' key to retrieve stored todos.

 Hive.box('todos').get('todos', defaultValue: []).cast<Todo>(),

The empty list ([]) defaultValue is necessary. For the first time, the Todo App is run on a device that had never stored todos before, so the empty list will be returned instead.

Casting the retrieved value as a Todo object is also important (.cast<Todo>()). If you omit that step, Flutter will throw errors.

The TodosService class provides a todos getter for accessing the value of the private reactive TodoList (_todos.value).

List<Todo> get todos => _todos.value;

The TodosService class also provides methods for manipulating Todos and their properties (removeTodo, toggleStatus, and updateTodoContent). Each of these methods takes the Todo's id and uses the id to carry out the appropriate action.

Notice that all these methods call the private _saveToHive() method. The reason is whenever todos are updated, the updates are saved to our local storage with Hive. So that if the app is closed and re-opened, the latest state of todos will be loaded back.

Also notice that these methods call notifyListeners(). It is part of the idea behind having only a getter for todos (and no setter). So that whenever there are updates (from these methods), we can call notifyListeners() (if need be) and do appropriate logic (like _saveToHive).

notifyListeners() is the equivalent of setState() but this time not inside a StatefulWidget. It tells possible listeners (like the upcoming TodosScreenViewModel) that the todos getter has changed. In turn, the ViewModel will rebuild the UI of its view and render the new state of the todos.

It is worth pointing out that updateTodoContent doesn't call notifyListeners(). We will point out the reason why when we will build the UI of the TodosScreenView.

Notice the private _randomId() method that returns a random string of 10 characters. The newTodo() method uses _randomId() to set the id of a new Todo and inserts that new Todo at the beginning of the TodoList.

If you want new Todos to be added at the end of the list, use _todos.value.add(Todo(id: _randomId())); instead of _todos.value.insert(0, Todo(id: _randomId())); in the newTodo() method.

The entire above pattern of using a service introduces code structure and makes the code easier to read (compared to if everything was in a widget).

This service pattern becomes very useful if we were saving the todos to some external API and fetching them back on app load. But that will be beyond the scope of simply introducing Stacked Architecture.

6. Setup the Service Locator

Create a new folder with the name app inside the lib folder. Inside this newly created app folder, create a new file with the name locator.dart.

Paste the following into the newly created lib/app/locator.dart file:

import 'package:get_it/get_it.dart';

import '../services/todos.service.dart';

final locator = GetIt.instance;

setupLocator() {
  locator.registerLazySingleton(() => TodosService());
}

Here, out of convention, we named the GetIt instance locator. After all, that name reflects what it does. It locates services. Other developers might want to use getIt or some other descriptive name for this service locator. That's okay.

We have a setupLocator() function that registers our TodosService with the locator. If we had other services, we would register them here in a similar way.

We need to call the setupLocator() function before the entire Flutter app launches. This way the services are available to any widgets that the Flutter app will need.

Delete the entire contents of the lib/main.dart file and paste the following in there:

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

import 'app/locator.dart';
import 'models/todo.adapter.dart';
import 'ui/views/todos_screen_view.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await Hive.initFlutter();
  Hive.registerAdapter(TodoAdapter());
  await Hive.openBox('todos');

  setupLocator();

  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: const TodosScreenView(),
      theme: ThemeData.dark(),
      title: 'Flutter Stacked Todos',
    );
  }
}

WidgetsFlutterBinding.ensureInitialized() is the first statement in the same main method.

In simple terms, we use this statement because Flutter asks us to always include it as the first thing in the main method anytime we want to do some other stuff (like Hive.initFlutter() or setupLocator()) before launching the Flutter app with runApp().

Notice that we are initializing Hive, registering the TodoAdapter, and opening the 'todos' box in the main method. This is the last part of setting up Hive.

Also notice that we are now calling the setupLocator() function inside the main method and before the final runApp call to launch the Flutter app.

We used a dark theme in our MaterialApp by setting the theme property to ThemeData.dark(). This dark theme is just for styling – you can remove it if you prefer the default light theme. You can also customize the app's theme as you wish.

Our lib/main.dart file currently has errors. The error is that the TodosScreenView widget does not exist and we set it as the home property of our MaterialApp.

If you are using a Flutter-enabled IDE, you'll notice that the above have been indicated as errors.

No worries, we will create those files now.

How to Build the Todo App's UI

The Different Types of ViewModels

In Stacked, think ViewModels first before their Views. This will help you gather the dependencies that the corresponding view needs before actually building the view.

Stacked comes with different ViewModel types. In Stacked, you have BaseViewModels, ReactiveViewModels, FutureViewModels, StreamViewModels, and MultipleFutureViewModels. Use each one based on your current need.

Use ReactiveViewModels if your View or its ViewModel will need to use reactive values from reactive services.

We will use the reactive ViewModel type for our TodosScreenViewModel. We are using a ReactiveViewModel because we will need the reactive todos getter in the TodosScreen.

1. Create the TodosScreenViewModel

Create a new folder with name ui inside the lib folder. Inside this newly created ui folder, create another folder named todos_screen. Then inside the new todos_screen folder, create a new file with name todos_screen_viewmodel.dart.

Paste the following into the newly created lib/ui/todos_screen/todos_screen_viewmodel.dart file:

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

import '../../app/locator.dart';
import '../../models/todo.dart';
import '../../services/todos.service.dart';

class TodosScreenViewModel extends ReactiveViewModel {
  final _firstTodoFocusNode = FocusNode();
  final _todosService = locator<TodosService>();
  late final toggleStatus = _todosService.toggleStatus;
  late final removeTodo = _todosService.removeTodo;
  late final updateTodoContent = _todosService.updateTodoContent;

  List<Todo> get todos => _todosService.todos;

  void newTodo() {
    _todosService.newTodo();
    _firstTodoFocusNode.requestFocus();
  }

  FocusNode? getFocusNode(String id) {
    final index = todos.indexWhere((todo) => todo.id == id);
    return index == 0 ? _firstTodoFocusNode : null;
  }

  @override
  List<ReactiveServiceMixin> get reactiveServices => [_todosService];
}

Notice how we have access to the _todosService with the help of locator. We override the reactiveServices getter on ReactiveViewModels and provide the _todosService to this list.

That way, whenever notifyListeners() is called inside TodosService, this TodosScreenViewModel will be notified and it will rebuild the UI as necessary.

From TodosScreenViewModel, we expose the removeTodo, toggleStatus, and updateTodoContent methods from the service to the TodosScreenView (which will come up later).

You might wonder why we need to do this. Why not just expose the service itself or rather access the service from the View or widget itself?

The point here is architectural rules and separation of concerns. Remember that the Stacked architecture states that Views should never access services.

Besides, we are doing this because we are keeping things simple. If the app grows bigger than this and we begin to add features to the views, you will realize that the TodosScreenViewModel will have to do other logic before or after making calls to the service's methods. In that case, we won't do such direct method exposure.

This is evident in the newTodo() method of TodosScreenViewModel. It calls the _todosService.newTodo() function to create a new empty Todo. Then it goes ahead and requests focus on the first or just-created Todo's node (_firstTodoFocusNode.requestFocus()).

That way, the cursor will automatically focus on the text input field of the newly created empty Todo after it is created. You will see this in action when we create the TodosScreenView.

The getFocusNode method returns this _firstTodoFocusNode if the Todo calling it is the first Todo. This call will be made from the UI in the TodosScreenView (coming up later on).

Note on the late keyword

The late keyword attached to the directly exposed service methods is necessary.

Dart is beautiful. late is a feature from Dart that says we are sure that these methods will be assigned later on (from the service) after the ViewModel has been instantiated.

If you remove the late keyword, Dart will complain with "The instance member '_todosService' can't be accessed in an initializer." This complaint is valid.

The complaint comes up because, when the TodosScreenViewModel has been instantiated, Dart is not sure if, at the time when it needs to instantiate those exposed methods (that had late in front of them), the '_todosService' has completed its initialization to be available for the methods.

Generally, instance members can't self initialize each other. The exception is either using the late keyword (as we did) or doing such initialization in the constructor.

Behind the scenes, the late keyword delays the initialization of the dependent instance members (in this case, the directly exposed methods) till the independent instance member (in this case, _todosService) has completed its initialization.

We didn't do these initializations in the constructor because it will make the code longer. And besides, it has the same effect as using late.

2. Create the TodosScreenView

Create a new file with name todos_screen_view.dart inside the lib/ui/todos_screen folder. In other words, the todos_screen_view.dart file should accompany its ViewModel file: todos_screen_viewmodel.dart.

Paste the following into the newly created lib/ui/todos_screen/todos_screen_view.dart file:

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

import 'todos_screen_viewmodel.dart';

class TodosScreenView extends StatelessWidget {
  const TodosScreenView({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return ViewModelBuilder<TodosScreenViewModel>.reactive(
      viewModelBuilder: () => TodosScreenViewModel(),
      builder: (context, model, _) => Scaffold(
        appBar: AppBar(title: const Text('Flutter Stacked Todos')),
        body: ListView(
          padding: const EdgeInsets.symmetric(vertical: 16),
          children: [
            if (model.todos.isEmpty)
              Opacity(
                opacity: 0.5,
                child: Column(
                  children: const [
                    SizedBox(height: 64),
                    Icon(Icons.emoji_food_beverage_outlined, size: 48),
                    SizedBox(height: 16),
                    Text('No todos yet. Click + to add a new one.'),
                  ],
                ),
              ),
            ...model.todos.map((todo) {
              return ListTile(
                leading: IconButton(
                  icon: Icon(
                    todo.completed ? Icons.task_alt : Icons.circle_outlined,
                  ),
                  onPressed: () => model.toggleStatus(todo.id),
                ),
                title: TextField(
                  controller: TextEditingController(text: todo.content),
                  decoration: null,
                  focusNode: model.getFocusNode(todo.id),
                  maxLines: null,
                  onChanged: (text) => model.updateTodoContent(todo.id, text),
                  style: TextStyle(
                    fontSize: 20,
                    decoration:
                        todo.completed ? TextDecoration.lineThrough : null,
                  ),
                ),
                trailing: IconButton(
                  icon: const Icon(Icons.horizontal_rule),
                  onPressed: () => model.removeTodo(todo.id),
                ),
              );
            }),
          ],
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: model.newTodo,
          child: const Icon(Icons.add),
        ),
      ),
    );
  }
}

About the TodosScreenView

The first line after the declaration of the build method is a return statement. This statement returns a ViewModelBuilder widget for the TodosScreenViewModel.

This is another aspect of Stacked architecture. It explains what we mean by Views being attached to ViewModels. In essence, we use ViewModelBuilders to render a View.

That way the View has access to the public properties and methods of its ViewModel. Also, calling notifyListeners() inside the ViewModel auto-updates the View's UI. Furthermore, most (if not all) UI logic that is not declarative should be moved to the ViewModel.

This explains why we shifted the logic of the first Todo's FocusNode to the TodosScreenViewModel.

The body of the TodosScreenView's Scaffold is a ListView for all the Todos gotten from model.todos.

However, the first member of the ListView is a conditional Opacity widget with 0.5 opacity. Its child is a Column for empty state with spacing, a teacup icon, and Text for children.

We used ListTile to display each Todo. It is a convenience widget that takes leading, title, and trailing widgets for the left, center, and right parts of the screen.

Note on Right-To-Left: ListTile is a good widget, and Flutter is a good framework. They both are internationalized. If this app was run on a device naturally set with a right-to-left locale (in Arabic for example), the app will be mirrored. So the leading, title, and trailing widgets of ListTiles will be right, center, and left parts of the screen instead.

The leading widget on the ListTile is an IconButton whose icon is either an empty or checked circle depending on if the Todo is completed or not. The onPressed callback on the IconButton toggles the status of the Todo.

The title (center) widget on the ListTile is a TextField with no decoration. No decoration here means it has no backgrounds, borders, or underlines. The aim is to give the user the feeling that they can just read their Todo content, while at the same time, the ability to edit the content is in the same place.

The [TextEditingController](https://api.flutter.dev/flutter/widgets/TextEditingController-class.html) given to the TextField is used to set the text content on the field from the content of the Todo. Setting maxLines to null on the TextField is telling Flutter that text in the TextField can span across multiple lines.

The onChanged callback updates the text content of the attached Todo. This callback is called for every keystroke or edit of text. We are doing this to keep all Todos always in sync with the UI.

We didn't call notifyListeners() in this callback (updateTodoContent) in the TodosService to prevent the cursor from jumping (given that we are making the call for each keystroke).

If notifyListeners() was called in this callback, the UI would be rebuilt each time, and the cursor would keep jumping back to the start of the TextField after each keystroke.

3. Run the Todo App

If you are using a Flutter-enabled IDE, you should be able to run the above app on a preconfigured device already.

If you are not, no problem – run the following command in the same terminal. Or rather, make sure that you are in the same project folder in the terminal, then run the command:

flutter run

It should run the Flutter app on an available device or ask you to choose a device and then run the application on it.

You should be able to create Todos, mark them as complete, and remove them.

If you've gotten this far, Congratulations on building a Todo App with the Stacked Architecture!

For a mini-recap, the files inside your lib folder now should be:

• app/locator.dart
• models/todo.adapter.dart
• models/todo.dart
• services/todos.service.dart
• ui/todos_screen/todos_screen_view.dart
• ui/todos_screen/todos_screen_viewmodel.dart
• main.dart

You can get the final code on GitHub here.

Note on Other Stacked Features

There is more to using the Stacked architecture. The above Todo App was one-screen only and it did not need any navigation.

You will need to configure Navigation or Routing in most if not all applications you'll build with Flutter. Navigation is a necessity once you have more than one screen in the Flutter App.

Stacked lets you configure an @StackedApp decoration on an empty Dart class. This decoration can take routes and dependencies info as in the following snippet:

@StackedApp(
  routes: [MaterialRoute(page: TodosScreenView, initial: true)],
  dependencies: [LazySingleton(classType: TodosService)],
)
class App {
  // This class has no puporse besides housing the annotation that
  // generates the required functionality.
}

You'd then need to add build_runner and stacked_generator packages to the Flutter project. Then in development, you keep the following command running:

flutter pub run build_runner build --delete-conflicting-outputs

This command will generate the contents of the setupLocator() function for you. And it is the generated file (and function) that you would add to the main method in lib/main.dart.

Furthermore, the Stacked architecture also has a [stacked_services](https://pub.dev/packages/stacked_services) package. This package helps with configuring crucial services like bottom sheet, dialog, navigation, and snack bar, without the BuildContext, inside ViewModels.

All these introduce convenience and give you a better developer experience while using Stacked.

But these features would be overkill for the simple Todo App we just built. That's why we didn't include them.

The idea is to understand the fundamentals behind the Stacked architecture and be able to use the architecture in your large-scale Flutter projects.

The stress is on large-scale. In reality, if you are building anything simple, you won't need to use any state management architecture. Even a simple Todo App.

But in this article, I aimed to get you started with Stacked Architecture and I needed something simple (like this Todo App) to explain the concepts.

Of course, you can still use Stacked to build simple things. That's what we just did with a Todo App. But understand that you will enjoy the benefits of Stacked when you start adding more features like saving todos to some server, authentication, grouping todos into categories, and more in the Todo App.

Summary

State Management architectures are good ways to structure Flutter projects. They are optional but can become a necessity if you are building a complex application or if more than one person is contributing to the same codebase.

These architectures find a way to update the UI without the default calls to setState(). Stacked is one such architecture. It uses notifyListeners() to update the UI.

A key feature of Stacked is carrying out crucial services like navigation without the BuildContext. We didn't explore that feature in this Todo App. But have it in mind as you go further with using Stacked.

Your Stacked apps should have widgets inside View files. Views should be tied to ViewModels and UI logic should take place here. Services should be used for the app's business logic and APIs. They should be used by other services or ViewModels.

We've used this simple 3-entity structure to build a functional Todo App. You can use the same pattern to build bigger and better apps. Better still, you can refactor existing applications to follow this pattern and have cleaner code.

We also used Hive to save and retrieve Todos after closing and re-opening the Flutter application. Hive is a lightweight package and can serve similar purposes in your apps.

The freeCodeCamp mobile app is built with Flutter. It is open-source and was built using Stacked architecture. You can contribute to the freeCodeCamp app here.

Cheers!

In this article, I'll explain in detail the various benefits of using Flutter so you can decide whether to use it for your next project.

Top Benefits of Flutter

1. Flutter is Cross-Platform
2. How Flutter is Cross-Platform
3. Flutter Has a Powerful UI Engine
4. How Flutter Renders UIs
5. Flutter Has Great State Management
6. Flutter Provides a Great Developer Experience
7. Flutter Has a Wonderful Developer Community
8. Summary

Now let's look at each of these features in more detail.

Flutter is Cross-Platform

Software is cross-platform when it is available for different Operating Systems. You want your product to have such cross-platform ability so users on any device can use your product comfortably.

Having support for desktop, mobile, and web platforms is tough. For desktop, you will need to write code for macOS (with Swift), Linux (with C), and Windows (with C++). For mobile, you will need to write code for Android (with Kotlin/Java and XML) and iOS (with Swift).

To make your product accessible as a website, you have to use HTML, CSS, and JavaScript. Or, use any frontend JavaScript framework like Angular, React, or Vue.

Making applications for the various desktop and mobile operating systems requires separate SDKs and skillsets. In the past, you would've needed to hire developers who were proficient at each platform to implement your app on each of those platforms. This is expensive.

To add a feature, you would've needed to update the code across all these platforms which is tedious.

How Flutter is cross-platform

Flutter code can run on desktop, mobile, and web platforms. So, you don't need to hire developers for each platform. You need to write the code only once in Flutter and you can rest assured that the app will work across the other platforms. So, Flutter is cheap.

Adding features to your app is fast because you only have to make code updates once in Flutter and that's all.

Same Flutter app working on desktop, mobile, and web.

The Flutter framework gives you APIs for painting and events (through widgets). It also provides APIs for platform-specific services (through method channels). So Flutter exposes everything to you to build the app in any way you want it. That's how cross-platform works.

Adapted from https://youtu.be/l-YO9CmaSUM

Don't worry about performance. Naturally, Dart can compile to native code. So, the performance of Flutter apps is close (if not equal to) that of native apps.

Dart's Ahead-Of-Time compiler is used to bundle the Flutter code. It is used when you launch the flutter build command. During the build step, only the app and the Flutter engine are shipped. This makes the built app small in size (very close to a native app).

Flutter Has a Powerful UI Engine

UI rendering in Flutter is pixel-perfect. As a Flutter developer, you are in charge of every pixel painted on the device screen.

Flutter achieves this with the help of its engine. The Flutter engine is in charge of interpreting Flutter code to exactly what is drawn on the device's screen. Each Flutter app (built for any given platform) contains the engine which handles painting at runtime.

This also explains how Flutter is efficiently cross-platform, in terms of UI rendering. But this is more about the efficiency of the engine. The Flutter engine uses Skia for graphics. Skia is a 2D graphics library that handles graphics rasterization on various hardware and software.

The Flutter engine doesn't only contain Skia. It also has implementations of Flutter's core APIs (like texts and network I/O) at basic levels.

The Flutter engine is so powerful that it can efficiently re-render UIs at a speed of 60 frames per second (60 fps). So when there are UI changes or animations, the engine makes them so fast as if it was a native application.

How Flutter Renders UIs

Flutter uses composition aggressively. Composition here means widgets have widgets, which in turn have widgets, and so on. Everything in Flutter is a widget and Flutter UI code is essentially a big tree of widgets.

Behind the scenes, Flutter keeps 3 separate trees for the UI. We normally code the outermost widget tree. In turn, the Flutter engine creates an Element and a RenderObject tree based on the widget tree.

In essence, each widget has its own corresponding Element and RenderObject. These last two entities are in charge of the actual representation of widgets on the device screen. Widgets themselves just hold the UI properties (like color, padding, shadows, and so on) that we set ourselves.

When UI is re-rendered, Flutter always destroys and rebuilds any changed widget (because widgets are immutable). However, it only replaces a linked Element or RenderObject if need be.

These extra UI trees explain how the widget tree is destroyed and rebuilt in each frame of the 60 fps rendering speed and yet the UI is re-rendered properly.

The 3 UI trees, adapted from https://youtu.be/996ZgFRENMs

The 3 UI trees with the Center widget as an example. Adapted from https://youtu.be/996ZgFRENMs

Flutter Has Great State Management

State refers to data that your application needs to render its UI at any point in time. It could be user-generated or from your servers or backend.

In general, Flutter has two types of widgets: StatelessWidgets and StatefulWidgets. Anytime you will need to update the UI based on state, simply use a StatefulWidget ahead of time. Then to update the UI, call setState() anywhere inside the State class of a StatefulWidget and Flutter will rebuild the UI tree.

This setState() mechanism turns out to be the most efficient out there. It is also the React style of updating UI based on state. UI programming should be declarative and setState() simply advocates that.

You should call setState() after asynchronous code has been executed (if any). This is because it is part of the main UI thread and blocking calls can hijack the UI rendering process.

If you have processes that are highly CPU intensive in a Flutter app, consider using Dart Isolates to carry out those processes, then call setState() with the data you get when processing is complete.

Sometimes, you may need access to state not scoped to a particular widget. At that point, you need a State Management architecture. There are a good number of them to choose from. These architectures provide state at an app-wide level without reconfiguring in each widget.

Available options include Provider, Riverpod, Redux, InheritedWidget, Stacked, and many more.

Another advantage of these architectures is that a good number of them permit good separation of concerns and dependency injection (or inversion of control).

In simpler terms, separation of concerns gives you the ability to write UI-specific code separate from logic-specific code. This way, if you want to debug, or change the packages or APIs you're using, you'll do them easily from one place (without fear of damaging the codebase). Besides, it promotes clean code too.

Dependency Injection involves the use of services or something similar to obtain what widgets need to work without the widgets configuring the services themselves. Some architectures like Stacked permit you to manage app-wide states without the BuildContext.

This pattern is useful because, in StatelessWidgets, the BuildContext is available only within the build method and you might need to use stuff outside it. So you could do other things like BottomSheet, Navigation, Toast, and so on without BuildContext.

Flutter Provides a Great Developer Experience

There are many reasons the developer experience with Flutter is awesome. Here are a few of them:

Flutter has only one programming language – Dart.

Programming on its own is a demanding activity. Frameworks, libraries, and tools shouldn't make coding tougher.

When coding for some platforms you usually write code in more than one programming language. For example, while coding for frontend web, you will alternate between HTML, CSS, and JavaScript files to manage a given portion of your webpage.

Flutter makes coding easy because you write in just one programming language: Dart. So most of the time, the logic and UI properties for a given portion of your Flutter app will be in the same Dart file.

Also, Flutter and Dart are written in plain English. Widget names and their properties reflect what they are. While coding Flutter, you are less likely to have any headaches understanding a given widget and or its use case(s).

Flutter has hot-reloading.

Dart is a modern programming language that comes with an Ahead-Of-Time (AOT) and a Just-In-Time (JIT) compiler.

The JIT compiler gives the feel that Dart is rather interpreted in runtime. In other words, it makes it possible for changes to Dart files to reflect immediately without needing to recompile the file, as is the case with some programming languages like C or Java.

Flutter leverages the JIT for development. Flutter ships a Dart VM to the platform in which the app's code is hosted. That way, when you launch the flutter run command, pressing r in that terminal ships in the changes in dart files, without recompiling the whole app. This instantaneous, yet cross-platform change-reflecting feature of Flutter is called hot-reloading.

Flutter also has hot-restarting. Hot restarting is achieved by pressing R (uppercase instead of lowercase this time). Hot restarting restarts the app entirely.

You need to do a hot-restart instead if you change some important parts of the Flutter code. For example, changing class declarations or their superclasses will need a hot restart.

Flutter is universal.

Flutter is available for each Operating System. So you won't need to migrate or use a particular Operating System to create apps with Flutter as is the case with iOS apps (where you need an Apple computer).

Flutter smoothly integrates with popular IDEs. Android Studio, IntelliJ, and VS Code (Visual Studio Code) have plugins or extensions for Flutter. So you can manipulate Flutter commands directly in the IDE without using the terminal.

Editing Flutter as an Android app in Android Studio

Editing Flutter as a Windows app in VS Code

Android Studio is relatively demanding in terms of computing resources. If your laptop is not up to 8GB RAM, don't feel left out.

Setting up Flutter auto-detects your Operating System and browsers. Flutter is available for the web (to run Flutter apps in browsers). So you can test Flutter code in your browser or as a desktop app if RAM or CPU capacity could be a problem.

There is also dartpad.dev, flutlab.io, and flutterflow.io that let you create Flutter apps online, in the browser. You will find these useful as they do not require as many computing resources as running Flutter for Android or iOS.

Flutter DevTools

Dart naturally comes with a set of utilities for optimizing and debugging Dart code. This suite of tools is accessible from the browser or IDE you are using. While coding Flutter, using DevTools will shorten your coding time and give you deep insights into your app.

Flutter DevTools include indispensable tooling like an inspector, a debugger, a performance monitor, a network monitor, logger, and more.

Flutter DevTools

Flutter Has a Wonderful Developer Community

The Flutter framework is relatively small... – from the Flutter Docs

The Flutter team themselves acknowledge the community. In itself, the Flutter framework is relatively small compared to the entire Flutter ecosystem. Flutter is Open Source.

Around Flutter there are so many developers that have extended the framework. These developers have published more than 24,000 packages on pub.dev. Each package has at least one widget you can import to your Flutter app.

If you have issues with Flutter or come across errors while using Flutter, you will find a solution once you search about it online. Chances are there are GitHub issues or Stackoverflow questions on what you are looking for. Stackoverflow has a lot of Flutter developers willing to help you, so don't hesitate to ask questions with the Flutter tag.

Flutter Groups and GDGs are tech communities, found in various countries. Annually, these communities organize a Flutter-only event commonly known FlutterFest. Some FlutterFest events are in person while some are virtual. These events bring the community members together for Flutter, Flutter, and more Flutter.

That said, you should use Flutter because you are not alone. You are confident that there are people around you that equally use it too and can help you when you are in need.

Also, maintenance and future support for Flutter look promising. Fuchsia is an upcoming open-source operating system. Asides from the current cross-platform support, Flutter for Fuchsia is available.

Summary

In summary, use Flutter because of the many benefits you will gain.

You will have a cross-platform application whose UI is pixel perfect and state properly managed. You will also enjoy your development experience and will leverage the Flutter community.

Cheers to the many Flutter apps you will build.

Helpful Resources

• How is Flutter different for app development
• How Flutter renders Widgets
• Flutter Architectural Overview
• List of state management approaches
• How to Implement any UI in Flutter

This is not a tutorial on building an app. It is rather a guide that will help you implement any UI you come across into an app you already have. This tutorial also explains a wide variety of UI concepts in Flutter.

Table of Contents

• What is Flutter?

• Widgets in Flutter

• The Widget Tree

• How to Implement any UI in Flutter
  1. Implement Top Left; Down Right
  2. Choose a Widget
  3. Use widget groups
  a. Column/Row
  b. Stack Widget
  4. Create custom widgets
  5. Add more customization
  a. Container Widget
  b. GestureDetector / InkWell

• How to Implement Scrolling Interfaces

• About CustomPaint

• Summary

What is Flutter?

Flutter is an open source framework by Google for building beautiful, natively compiled, multi-platform applications from a single codebase. – (source: flutter.dev)

In Flutter, contrary to most frameworks, Dart is the only programming language you use to code. This is an underemphasized benefit of Flutter. Especially for a tool that can build desktop, mobile, and web applications.

Most UI platforms use more than one language. For example, in front-end web development, you have to write HTML, CSS, and JavaScript. For Android, you have to write Kotlin (or Java) and XML. But in Flutter, it's just one language: Dart.

Coupled with the only-one-programming-language benefit, Flutter is simple because everything in Flutter is a widget. For example AnimatedWidget, BottomNavigationBar, Container, Drawer, ElevatedButton, FormField, Image, Opacity, Padding, ...

This is part of what makes Flutter easy to use – it's basically plain English. Widget names reflect what they are and their properties are easy to understand.

Widgets in Flutter

A widget is a Dart class that either extends StatefulWidget or StatelessWidget.

Your local Flutter installation comes with several widgets. To check out the widgets available by default, open the packages folder of your Flutter installation in your preferred editor. Then search across all files for "extends StatefulWidget" and "extends StatelessWidget" and take note of the number of results.

As of Flutter 2.10, you will get 408 StatefulWidgets and 272 StatelessWidgets. That is a total of 680 widgets available for you to use and implement UIs.

These widgets typically have all you need. But at times they may not be enough. pub.dev, Dart and Flutter's package manager, have many more widgets you can use to implement UIs.

It is difficult to count the widgets in pub.dev. But searching an empty string (don't enter anything in the search bar and then press the search icon) and setting the SDK to Flutter returns the current total number of published packages.

At the time of writing, there are more than 23000 Flutter packages in pub.dev. Each package has at least one widget. This means that you have more than 23000 widgets from pub.dev to implement, in addition to the available 680. This means that you can really implement any UI you want easily in Flutter.

Adding to the many available widgets, you can also create your own widgets as you implement UIs.

The Widget Tree

The following is part of the code you get when you create a new Flutter project and remove the comments:

 @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }

The parent Scaffold takes the appBar, body, and floatingActionButton parameters. In turn, the AppBar also takes a title parameter that has a Text value.

body takes a Center value that has a Column child. The Column in turn has two Texts as children. The FloatingActionButton takes the onPressed callback, 'Increment' tooltip, and an Icon for a child.

Flutter widget tree breakdown

This is a simple widget tree. It has parents and descendants. child and children are common properties of most Flutter widgets. As widgets continuously take more widget children, your app gradually grows into a large widget tree.

As you implement UIs in Flutter, bear in mind that you are building a widget tree. You will notice that your code indents inwards from the left margin. It seems to develop some kind of virtual greater than sign (of empty space) at the left.

Note: Huge indentation levels are a sign that you need to refactor your code. It means that you need to extract some widget hierarchy into a separate widget.

How to Implement Any UI in Flutter

1. Write your code starting at the top left and move down to the bottom right

You'll implement the UI widget after widget according to each element's position in the UI. So you will first write code for things that appear at the top of the UI. Then you keep writing code for the other items moving down the page until you reach the bottom of that UI.

This is intuitive.

On the horizontal axis, go from left to right. If need be, or if it is a right-to-left UI, then implement it from right to left instead.

2. Choose a Widget

Next you'll need to logically determine the widget you want to use for a given UI element. At a bare minimum, for a given UI element, you will use simple widgets you're familiar with based on what their names say they do.

Chances are the name of what the UI component looks like is the name of the widget. If you find it hard to make a choice, a quick online search will give you the answers. Flutter has a great online community.

3. Use widget groups

If a group of UI items is arranged vertically, one after another, use a Column. If they are arranged horizontally, one after another, use a Row. If they are placed on top of each other, use a Stack, with the floating widgets wrapped in Positioned widgets.

a. Column/Row

Inside a Column or Row, you can change or adjust how the widgets will align themselves on the main or cross axis. Use their CrossAxisAlignment and MainAxisAlignment properties for such adjustments.

For the cross axis, you can align to center, end, start, and stretch. For the main axis, you can align to center, end, space around, space between, space evenly, and end.

In a Column, the vertical axis is the main axis while the horizontal axis is the cross axis. In a Row, the horizontal axis is the main axis while the vertical axis is the cross axis.

Adapted from https://arzerin.com/2019/11/20/flutter-column/

Adapted from https://arzerin.com/2019/11/20/flutter-row/

In Columns and Rows, if you want a particular child widget to take as much available space as possible, wrap that widget inside an Expanded widget. If you are familiar with web frontend, you'll notice that Columns and Rows are like display: flex; in CSS.

b. Stack Widget

With Stack, the last widget(s) in the children's list appears on top of the earlier children.

You might have to edit the Stack's alignment to indicate the relative positions of the widgets. Like topCenter, center, bottomEnd, and so on.

The Stack's size is calculated based on non-positioned widgets (Widgets in the children list not wrapped in a Positioned parent). When coding, remember that your Stack should either have at least one non-positioned widget, or it should be wrapped in a parent widget that explicitly sets the Stack's size.

Positioned takes any or all of bottom, top, left, right. They set the child's position relative to the Stack. Negative values move the child in the opposite direction. However, negative values clip parts of the child out. Use clipBehavior: Clip.none on the Stack to show all the parts of the positioned widget.

Full code here.

4. Create custom widgets

As you build the widget tree, you will notice two things:

1. Either a chunk of the tree grows too big and it is a logical unit on its own.

2. Or some chunks or sets of widgets might repeat themselves with slight changes.

These are two indications that you should refactor your code. It means that you should extract out those widgets and define them in another Dart file.

Your code editor will help you with refactoring. With or without the editor, all you need to do is:

1. Create a new Dart file. The file name should reflect the new widget's name.

2. Create a new class that extends StatefulWidget or StatelessWidget, depending on if the new widget has State or not.

3. Then return the widget chunk from a build method.

4. (Optional) If need be, your new Dart class can take positional or named parameters to its constructor to customize the widget's look.

// in counter_display.dart
import 'package:flutter/material.dart';

class CounterDisplay extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
        mainAxisAlignment: MainAxisAlignment.center,
      children: [
        Text('You have pushed the button this many times:'),
        Text('$counter', style: TextStyle(fontSize: 24)),
      ],
    );
  }
}

// in main.dart
//
// ... 
  body: Center(child: CounterDisplay()),
// ...

You will build many custom widgets and they in turn will be descendants to more custom widgets, and that's fine. The widget tree is meant to continuously grow as the need arises.

5. Add more customization

You won't customize widgets only because of refactoring and repetitions (DRY code). You will create custom widgets because of the UI you are implementing.

You will create custom widgets because the many available widgets don't always meet the exact needs of a given UI. You'll need to combine them in some special way to implement a particular UI.

a. Container Widget

Container is a powerful widget. You can style it in different ways. If you are used to web frontend, you'll notice that it is like a div in HTML.

Container is a base widget. You can use it to create any UI piece.

Some Container parameters are constraints, decoration, margin, padding, transform, among others. Of course, Container takes a child which can be any widget.

The decoration property can take a BoxDecoration, which in turn can take several other properties. This is the heart of Container's flexibility. BoxDecoration takes parameters like border, borderRadius, boxShadow, color, gradient, image, shape, among others.

With these parameters and their values, you can implement any UI to your taste. You can use Container instead of the many material widgets that Flutter comes with. That way your app is to your taste.

b. GestureDetector / InkWell

GestureDetector as the name implies detects user interactions. Not every UI piece is a button. And while implementing UIs you will need some widgets to react to user actions. In such a case, use GestureDetector.

GestureDetector can detect different types of gestures: taps, double taps, swipes, ... GestureDetector of course takes a child (which can be any widget), and different callbacks for different gestures like onTap, onDoubleTap, onPanUpdate (for swipes), ...

Note: By default, when users interact with the empty spaces in the child of GestureDetectors, the callbacks are not called. If you want your GestureDetector to react to gestures on empty space (within its child), then set the behavior property of the GestureDetector to HitTestBehavior.translucent.

GestureDetector(
  // set behavior to detect taps on empty spaces
  behavior: HitTestBehavior.translucent,
  child: Column(
    children: [
      Text('I have space after me ...'),
      SizedBox(height: 32),
      Text('... that can detect taps.'),
    ],
  ),
  onTap: () => print('Tapped on empty space.'),
)

InkWell is similar to GestureDetector. It responds to some gestures that GestureDetector responds to. However, it shows ripple effects when interacted with (which GestureDetectors don't).

From https://stackoverflow.com/q/58285012/13644299

InkWell must have a Material ancestor. So, if your topmost widget is MaterialApp you need not worry. Else, wrap the InkWell in a Material.

You should also do this wrapping if you are changing the colors of the InkWell's parent or child. If you don't, the ripple won't show. You also have to set the color of the Material widget for the ripple to show. You can set the color to Colors.transparent and Flutter will take care of the rest.

How to Implement Scrolling Interfaces

Scrolling is a little delicate topic. By default, widgets don't scroll in Flutter. If your Column or Row will be scrollable, use a ListView instead. ListView takes children parameter too.

ListView also has factory constructors like ListView.builder and ListView.separated. The builder gives you more control over the build process of the children whereas the separated takes into account a Separator (like Divider for example).

By default, ListViews scroll their children vertically. However, you can change the scrollDirection of a ListView to Axis.horizontal to scroll its children horizontally.

At times, you might want to use SingleChildScrollView instead of ListView. As the name implies, it takes a single child and it can scroll. You can pass widget groups as its child.

There are other scrolling widgets.

But take special note of CustomScrollView. It gives you huge control of scrolling, unlike the others. It takes slivers, which in turn are scrolling widgets with powerful scroll mechanisms.

SliverFillRemaining, SliverFillViewport, SliverGrid, SliverList, SliverPersistentHeader among others, are examples of widgets you include in the list of slivers. Most of these widgets take a delegate, which handles how scrolling occurs.

A good case to use CustomScrollView is with SliverAppBar, where you want the AppBar to be expanded by default and shrunk on scroll.

Another example could be with a DraggableScrollableSheet where you keep some action button sticked to the bottom.

About CustomPaint

This is where Flutter gave ultimate flexibility to the UI world.

CustomPaint is to Flutter what the Canvas API is to HTML or SVG is to images.

CustomPaint is a widget in Flutter that gives you the ability to design and draw without limitations. It gives you a canvas on which you can draw with a painter.

From https://blog.codemagic.io/flutter-custom-painter/

You will rarely use CustomPaint. But be aware that it exists. Because there might be very complex UIs that widget combinations might not implement them and you will have no choice than drawing with CustomPaint.

When that time comes, it won't be hard for you because you are already familiar with other widgets.

Summary

For a given UI piece, choose a widget, write its code, build the widget with other widgets, and see what great UI you are implementing with Flutter.

Implementing UIs is a major part of mobile, web, and desktop app development. Flutter is a UI toolkit that build cross-platform for those platforms. Flutter's declarative nature and its widget abundance make UI implementation simple.

Keep implementing UIs in Flutter. As you do, it will become second nature to you. And you will be able to implement any UI in Flutter.