DEV Community: Jhin Lee

Why I Built llamadart: Offline Local LLM Inference for Dart/Flutter

Jhin Lee — Sun, 15 Feb 2026 02:30:51 +0000

I built a desktop AI-powered writing assistant, and cloud inference with Gemini worked great.

But I needed one more mode: offline AI.

I wanted the app to work on flights, unstable connections, and restricted environments where outbound API access is unavailable. That pushed me toward local inference with llama.cpp and GGUF models.

The biggest friction was native packaging. Cross-platform C++ setup is powerful, but it usually means extra work before product work: toolchains, linker/runtime quirks, per-architecture builds, and CI maintenance.

So I started llamadart with one practical goal:

Make local LLM inference in Dart/Flutter usable without forcing app developers to manually build llama.cpp first.

What llamadart is

llamadart is a Dart/Flutter package for local GGUF inference on top of llama.cpp, with a Dart-first API and streaming support.

Core references:

Package: https://pub.dev/packages/llamadart
Source: https://github.com/leehack/llamadart
Main docs: https://github.com/leehack/llamadart/blob/main/README.md

Architecture overview

High-level structure:

App Layer (Flutter UI / CLI / API server)
        |
        v
LlamaEngine (stateless orchestration)
        |
        +--> ChatSession (stateful history + context trimming)
        |
        +--> ChatTemplateEngine (detect/render/parse/tool grammar)
        |
        v
LlamaBackend abstraction
        |
        +--> NativeLlamaBackend (isolate + FFI)
        |
        +--> Web backend (bridge runtime path)

Implementation links:

LlamaEngine: https://github.com/leehack/llamadart/blob/main/lib/src/core/engine/engine.dart
ChatSession: https://github.com/leehack/llamadart/blob/main/lib/src/core/engine/chat_session.dart
ChatTemplateEngine: https://github.com/leehack/llamadart/blob/main/lib/src/core/template/chat_template_engine.dart
LlamaBackend interface: https://github.com/leehack/llamadart/blob/main/lib/src/backends/backend.dart
Native backend: https://github.com/leehack/llamadart/blob/main/lib/src/backends/llama_cpp/llama_cpp_backend.dart
Web backend: https://github.com/leehack/llamadart/blob/main/lib/src/backends/webgpu/webgpu_backend.dart

Build hook deep dive: how native binaries are delivered

This is the part I cared about most.

llamadart uses Dart build hooks (official docs: https://dart.dev/tools/hooks). Build hooks are executed automatically by the Dart SDK during run, build, and test to compile or download native assets.

For FFI context, Dart also documents this under C interop: https://dart.dev/interop/c-interop#build-hooks

Hook entry point

The hook implementation is here:

https://github.com/leehack/llamadart/blob/main/hook/build.dart

build.dart reads target metadata from hook input (BuildInput) and reports resolved assets through BuildOutputBuilder as CodeAsset entries.

Related official APIs:

Hooks package: https://pub.dev/packages/hooks
BuildInput and BuildOutputBuilder: https://pub.dev/documentation/hooks/latest/hooks/
Code assets package: https://pub.dev/packages/code_assets
CodeAsset API: https://pub.dev/documentation/code_assets/latest/code_assets/CodeAsset-class.html

What happens at build/run time

The hook runs a deterministic local-first pipeline:

Resolve target platform and architecture from hook input.
Map (os, arch) to a concrete release asset filename (for example, libllamadart-linux-x64.so).
Try local packaged binary (third_party/bin/...) first.
If missing, try cache (.dart_tool/llamadart/binaries/...).
If cache miss, download from GitHub Releases.
Copy to hook output directory with standardized runtime filename.
Report the asset as DynamicLoadingBundled() so Dart can bundle and load it.

On Apple targets, the hook also handles binary thinning when needed (lipo) so the reported artifact matches the active architecture.

How GitHub is used

llamadart uses GitHub Releases as the binary distribution layer.

In the hook, the release URL is pinned by a llama.cpp tag constant:

const _llamaCppTag = 'b8011';
const _baseUrl =
    'https://github.com/leehack/llamadart/releases/download/$_llamaCppTag';

That gives stable, tag-based binary resolution instead of "latest" behavior.

The automation that produces those release assets is here:

https://github.com/leehack/llamadart/blob/main/.github/workflows/llama_cpp_auto.yml

That workflow builds artifacts across target OS/arch matrices, uploads release assets, regenerates bindings when needed, and updates the pinned hook tag.

Runtime FFI resolution

At runtime, FFI symbols are linked to the hook-provided asset via annotations like:

@Native: https://api.dart.dev/dart-ffi/Native-class.html
@DefaultAsset: https://api.dart.dev/dart-ffi/DefaultAsset-class.html

In llamadart, generated bindings use this default asset pattern:

https://github.com/leehack/llamadart/blob/main/lib/src/backends/llama_cpp/bindings.dart

That avoids per-platform dynamic library path logic in app code.

Why this matters in practice

This hook + release model gives a practical DX benefit:

Package users avoid manual local llama.cpp build steps in the common case.
First build can fetch the correct binary for the target.
Subsequent builds use cache/local artifacts.
App code stays focused on model lifecycle and inference logic, not native packaging scripts.

A quick note on dinja

While implementing chat-template compatibility, I ran into another gap: GGUF models expose Jinja templates, but template behavior differs significantly across model families.

I could not find a Dart Jinja package tuned for this multi-template LLM use case, so I built dinja (source: https://github.com/leehack/dinja).

In llamadart:

Template handlers render prompts with dinja.
JinjaAnalyzer does AST-level capability checks (system role, tool-call shape, typed content, thinking tags).
ChatTemplateEngine routes handlers and supports custom overrides/registration.

Relevant links:

Handlers directory: https://github.com/leehack/llamadart/tree/main/lib/src/core/template/handlers
Jinja analyzer: https://github.com/leehack/llamadart/blob/main/lib/src/core/template/jinja/jinja_analyzer.dart
Template engine: https://github.com/leehack/llamadart/blob/main/lib/src/core/template/chat_template_engine.dart

Minimal usage example

import 'dart:io';
import 'package:llamadart/llamadart.dart';

Future<void> main() async {
  final engine = LlamaEngine(LlamaBackend());

  try {
    await engine.loadModel('path/to/model.gguf');

    final session = ChatSession(
      engine,
      systemPrompt: 'You are a helpful writing assistant.',
    );

    await for (final chunk in session.create([
      LlamaTextContent('Rewrite this paragraph in a concise style.'),
    ])) {
      stdout.write(chunk.choices.first.delta.content ?? '');
    }
  } finally {
    await engine.dispose();
  }
}

Closing

I built llamadart because my app needed both online model quality and reliable offline execution, without turning native build management into the main project.

If you are building AI features in Dart/Flutter and need local inference, I would love feedback:

How to use GoLang in Flutter Application - Golang FFI

Jhin Lee — Wed, 20 Dec 2023 02:35:14 +0000

GoLang is a very powerful language that is easy to use. Writing a GoLang program and compiling it to a binary file is very easy. Golang is very useful in writing high-performance and low-latency applications, but it needs improvement in GUI. Flutter is a compelling cross-platform UI framework. It allows you to write a beautiful application effortlessly. Mixing GoLang and Flutter is an excellent idea to write a high-performance and beautiful application.

In this article, we will see how to compile a GoLang-based library and create a Flutter plugin package for a Flutter application.

What is FFI?

FFI stands for Foreign Function Interface. It is a way to call functions written in other languages from Dart. FFI helps use libraries written in other languages in a Flutter application. Flutter supports FFI for Android, iOS, Linux, macOS, and Windows. In this article, we will see how to use FFI.

In Dart, the programming language used to write Flutter applications, we can use the dart:ffi package to use FFI. The dart:ffi package is used to call functions written in other languages from Dart. We can use the dart:ffi package to call functions written in C, C++, or Rust. In this article, we will see how to use the dart:ffi package to call functions in GoLang.

Create a plugin project for Flutter

The Flutter plugin can contain Dart and platform-specific code written in Kotlin, Swift, Objective-C, or GoLang. We can use a Flutter plugin to add functionality to a Flutter application.

The below command will create a Flutter plugin project named native_add. The native_add project will support Android, iOS, Linux, macOS, and Windows. The native_add project will have a lib folder that contains the Dart code and an example folder that contains a Flutter application to test the plugin.

 $ flutter create --platforms=android,ios,macos,windows,linux --template=plugin_ffi native_add
 $ cd native_add

Create a GoLang library

The plugin project we created in the previous step will have a src folder. The src folder will have a cpp folder that contains the C++ code. We will create a GoLang library in the src folder. The GoLang library will have a function to add two numbers.

First, we will create a go.mod file. The go.mod file defines the module name and the GoLang version. The go.mod file is used to manage dependencies. We will not use any dependencies in this article.

// go.mod file
module go_code

go 1.21.3

Second, we will create a sum.go file. The sum.go file will have a function to add two numbers. The sum.go file will also have a function called enforce_binding. The enforce_binding function enforces the binding in the ios application. The Dart code will not use the enforce_binding function, but it was the trick I found to make the library linked correctly for iOS.

Above each function we want to expose, we will add a comment //export <function_name>. The //export <function_name> comment exposes the function to other languages. We must also use the type C.int instead of int in the function signature. The C.int type is used to make the function compatible with other languages.

// sum.go file
package main

import "C"

//export sum
func sum(a C.int, b C.int) C.int {
  return a + b
}

//export enforce_binding
func enforce_binding() {}

func main() {}

Compile the GoLang library for Android

Since we are compiling the GoLang library for Android, we must use cross-compilation. Modern Android devices mostly use arm64 or x86_64 architectures. We will compile the GoLang library for both arm64 and x86_64 architectures.

export ANDROID_OUT=../android/src/main/jniLibs
export ANDROID_SDK=$(HOME)/Library/Android/sdk
export NDK_BIN=$(ANDROID_SDK)/ndk/23.1.7779620/toolchains/llvm/prebuilt/darwin-x86_64/bin

# Compile for x86_64 architecture and place the binary file in the android/src/main/jniLibs/x86_64 folder
CGO_ENABLED=1 \
GOOS=android \
GOARCH=amd64 \
CC=$(NDK_BIN)/x86_64-linux-android21-clang \
go build -buildmode=c-shared -o $(ANDROID_OUT)/x86_64/libsum.so .

# Compile for arm64 architecture and place the binary file in the android/src/main/jniLibs/arm64-v8a folder
CGO_ENABLED=1 \
GOOS=android \
GOARCH=arm64 \
CC=$(NDK_BIN)/aarch64-linux-android21-clang \
go build -buildmode=c-shared -o $(ANDROID_OUT)/arm64-v8a/libsum.so .

Now we can use the libsum library in the Dart code using FFI.

DynamicLibrary.open('libsum.so');

Compile the GoLang library for iOS

We need some extra steps to cross-compile the Golang library and use it for iOS. iOS only supports static libraries. So, we need to compile the GoLang library as a static library. We also need to modify the podspec file to use the static library in the Flutter plugin. Another thing to note is that we need to create xcframework for iOS. The xcframework is used to support both simulator and device architectures.

# build_ios.sh file
#!/bin/sh
export GOOS=ios
export CGO_ENABLED=1
# export CGO_CFLAGS="-fembed-bitcode"
# export MIN_VERSION=15

SDK_PATH=$(xcrun --sdk "$SDK" --show-sdk-path)

if [ "$GOARCH" = "amd64" ]; then
    CARCH="x86_64"
elif [ "$GOARCH" = "arm64" ]; then
    CARCH="arm64"
fi

if [ "$SDK" = "iphoneos" ]; then
  export TARGET="$CARCH-apple-ios$MIN_VERSION"
elif [ "$SDK" = "iphonesimulator" ]; then
  export TARGET="$CARCH-apple-ios$MIN_VERSION-simulator"
fi

CLANG=$(xcrun --sdk "$SDK" --find clang)
CC="$CLANG -target $TARGET -isysroot $SDK_PATH $@"
export CC

go build -trimpath -buildmode=c-archive -o ${LIB_NAME}_${GOARCH}_${SDK}.a

The above script will create a static library for iOS. We must use the script to build the static library for both simulator and device architectures.


# Compile for x86_64 simulator architecture
GOARCH=amd64 \
SDK=iphonesimulator \
LIB_NAME=libsum \
./build_ios.sh

# Compile for arm64 simulator architecture
GOARCH=arm64 \
SDK=iphonesimulator \
LIB_NAME=libsum \
./build_ios.sh

# Compile for arm64 device architecture
GOARCH=arm64 \
SDK=iphoneos \
LIB_NAME=libsum \
./build_ios.sh

The above script will create three static libraries. Before creating the xcframework, we must combine the two static libraries for the simulator architecture. The lipo command can combine the two static libraries.

lipo \
-create \
libsum_arm64_iphonesimulator.a \
libsum_amd64_iphonesimulator.a \
-output libsum_iphonesimulator.a

Now we can create the xcframework using the below command.

xcodebuild -create-xcframework \
-output ../ios/libsum.xcframework \
-library ios-arm64/libsum.a \
-headers ios-arm64/libsum.h \
-library ios-simulator/libsum.a \
-headers ios-simulator/libsum.h

The libsum.xcframework will be created in the ios folder.

We need to modify the podspec file to use the xcframework. We must add the lines below to the podspec file under the ios folder.

s.public_header_files = 'Classes/**/*.h'
s.vendored_frameworks = 'libsum.xcframework'

After some trial and error, I found that we need to use the library in the Classes folder to link it properly. So, we create binding.h and EnforceBinding.swift files under the Classes folder.

The binding.h file will have the below code.

void enforce_binding();

The EnforceBinding.swift file will have the below code.

public func dummyMethodToEnforceBundling() {
    enforce_binding() // disable tree shaking
}

Now, we can use the libsum library in the Dart code using FFI.

// The libsum library is statically linked in the native_add so we only need to load native_add.
DynamicLibrary.open('$native_add.framework/native_add');

Create a binding in Dart using `ffigen`

The ffigen tool generates the Dart code to use the GoLang library. We will create a ffigen.yaml file to configure the ffigen tool. The config.yaml file will have the below code.

# Run with `flutter pub run ffigen --config ffigen.yaml`.
name: NativeLibrary
description: Bindings to `src/sum.h`.
output: 'lib/generated_bindings.dart'
headers:
  entry-points:
    - 'src/libsum.h'
preamble: |
  // ignore_for_file: always_specify_types
  // ignore_for_file: camel_case_types
  // ignore_for_file: non_constant_identifier_names
  // ignore_for_file: unused_field
  // ignore_for_file: unused_element
comments:
  style: any
  length: full

Now, we can run the ffigen tool to generate the Dart code.

flutter pub run ffigen --config ffigen.yaml

The ffigen tool will generate the generated_bindings.dart file under the lib folder based on the libsum.h file in src folder that was generated by the go build command in the previous step.

Use the GoLang library in Dart

Now, we can use the GoLang library in the Dart code. We can use the DynamicLibrary.open method to load the library. We can use the NativeLibrary class to call the functions in the GoLang library.

// lib/native_add.dart
import 'dart:ffi';
import 'dart:io';

import 'generated_bindings.dart';

int sum(int a, int b) => _bindings.sum(a, b);

const String _libName = 'native_add';

/// The dynamic library in which the symbols for [NativeAddBindings] can be found.
final DynamicLibrary _dylib = () {
  if (Platform.isMacOS || Platform.isIOS) {
    return DynamicLibrary.open('$_libName.framework/$_libName');
  }
  if (Platform.isAndroid || Platform.isLinux) {
    return DynamicLibrary.open('libsum.so');
  }
  if (Platform.isWindows) {
    return DynamicLibrary.open('$_libName.dll');
  }
  throw UnsupportedError('Unknown platform: ${Platform.operatingSystem}');
}();

/// The bindings to the native functions in [_dylib].
final NativeLibrary _bindings = NativeLibrary(_dylib);

Now, we can use the sum function in the Dart code from the Flutter project that uses this plugin.

import 'package:native_add/native_add.dart' as native_add;
native_add.sum(1, 2);

Conclusion

In this article, we checked how to use GoLang in a Flutter application. We created a GoLang library and compiled it for Android and iOS. We also created a Flutter plugin to use the GoLang library in a Flutter application. We used the ffigen tool to generate the Dart code to use the GoLang library. We also checked how to use the GoLang library in the Dart code.

I also created a sample project to demonstrate using GoLang in a Flutter application. You can find the sample project in the below link. The example also contains the script to compile the GoLang library for MacOS.
https://github.com/leehack/flutter_golang_ffi_example
It's still missing for Windows and Linux but it should be much easier than for Android and iOS. Like Android or iOS, we must cross-compile and link the GoLang library for Windows and Linux in the CMake file.

Due to the lack of information, I had to spend a lot of time figuring out how to use GoLang in a Flutter application. This article will help you to use GoLang in a Flutter application.

Let's build a full-stack dart app

Jhin Lee — Thu, 20 Jul 2023 20:33:57 +0000

I've been working with Flutter for a while and love it. It's an excellent tool for building cross-platform applications. But what if you want to build a full-stack application? We will explore how to build a full-stack application using Flutter and Dart.

The complete example code: https://github.com/leehack/fullstack_dart_todo

What will we build?

The todo application with Flutter and Dart! We will use Flutter for the client and Dart Frog for the server. Flutter will display the UI, and Dart Frog will handle the business logic and data storage.

Why full-stack in Dart?

The most significant benefit of using Dart for full-stack development is that you can use the same language on both the client and server. It means that you don't have to learn two different languages, which makes it easier to get started with full-stack development. Of course, you can also share your code between the client and server, which is a huge benefit.

Project Structure

We will use the mono-repo structure for this project. We will create three packages: backend, frontend, and shared. shared package will contain all the code that is shared between the client and server. backend package will contain all the code for the server(Dart Frog) and frontend package will contain all the code for the client(Flutter).

Shared package (packages/todo)

todo_entity.dart - The Todo data model with the business logic.
todo_repository.dart - The repository interface. The backend will implement it for storing data. The frontend will implement it for communicating with the backend.

Backend package (packages/backend_frog)

routes/todos/index.dart - The rest api handlers for the route https://address.com/todos. It handles the GET and POST requests.
routes/todos/[id].dart - The rest api handlers for the route https://address.com/todos/[id]. It handles each todo item's GET/PUT/DELETE requests.
lib/data/in_memory_todo_repository.dart - The repository implementation of the in-memory database.
routes/todos/_middleware.dart - Dependency Injection of the in-memory database that handlers will use.

Frontend package (packages/frontend_flutter)

data/remote_todo_repository.dart - The repository implementation of the remote database (rest api client).
providers/todo_list_provider.dart - The riverpod provider handles business logic and data storage.
presentation folder - The UI code for widgets.
pages/todo_page.dart - The todo page displays the todo list and form.

Mono-repo setup

We will use melos to manage the mono-repo. Melos is a tool for managing Dart projects with multiple packages.

Install melos cli



    dart pub global activate melos

Create a project folder and initialize the melos workspace



    mkdir fullstack_dart_todo
    cd fullstack_dart_todo
    mkdir packages

Add the following to the pubspec.yaml file:



    name: remote_todo

    environment:
      sdk: '>=2.18.0 <3.0.0'

Add the melos as a development dependency:



    dart pub add melos --dev

Add the following to the melos.yaml file:



    name: remote_todo

    packages:
      - packages/*

    scripts:
      analyze:
        exec: Dart analyze .

Now you can run the melos bs for bootstrapping the mono-repo. Bootstrapping has two primary roles:

Installing all package dependencies (internally using pub get).
Locally linking any packages together.

Every time creating a new package, you must run the melos bs command. If you clone the project from GitHub, you must run the melos bs command.

Create the backend package with the Dart Frog

We'll use the Dart Frog framework for the backend. Dart Frog is built on top of shelf and mason and is inspired by many tools, including remix.run, next.js, and express.js.

We need to install the dart_frog_cli first.



    dart pub global activate dart_frog_cli

Now we are ready to create the backend project.



    cd packages
    dart_frog create backend_frog
    cd backend_frog

Start the dev server:



    dart_frog dev

By default, it opens the web server at http://localhost:8080. You can see the default page. Thanks to the hot reload, you can see the changes immediately.

Create the frontend package with the Flutter

We'll use Flutter for the frontend. Flutter is Google's UI toolkit for building beautiful, natively compiled mobile, web, and desktop applications from a single codebase.

Let's create the Flutter project under the packages folder.



    cd packages
    flutter create frontend_flutter
    cd frontend_flutter

Create the pure Dart shared package

The shared package will contain all the code that is shared between the client and server. We will create the pure dart package since it has no UI code.

Let's create the library project under the packages folder.



    cd packages
    dart create -t package todo
    cd todo

To make the backend and frontend projects use the shared package, we must add the dependency to each project's pubspec.yaml file (backend_frog, frontend_flutter).



    dependencies:
      todo: ^0.0.1

Once we run the melos bs command, the shared package will be linked to the backend and frontend project.

So, now we have everything ready to start the coding!

Global Architecture

The shared package has the Todo data model and the repository interface. The backend and frontend packages implement the repository interface. The backend implements it as the in-memory database, and the frontend implements it as the rest api client. The Todo entity is the data model with the business logic that will be referenced in both the backend and frontend packages.

Backend

The backend is a simple CRUD application that exposes REST APIs. It uses the in-memory database for storing data. The in-memory database is a simple List that stores the Todo data model. The backend has two routes: https://address.com/todos and https://address.com/todos/[id]. The first route handles the GET and POST requests. The second route handles each todo item's GET/PUT/DELETE requests.

Routes

Dart Frog uses directory-based routing. Each route is a directory with the *.dart file. index.dart represents the root route of the path. For example, the routes/todos/index.dart represents the https://address.com/todos route. The routes/todos/[id].dart represents the https://address.com/todos/[id] route.

Handlers for /todos in routes/todos/index.dart ```dart

Future onRequest(RequestContext context) async {
return switch (context.request.method) {
HttpMethod.get => await _get(context),
HttpMethod.post => await _post(context),
_ => Response(statusCode: HttpStatus.notFound)
};
}

Future _get(RequestContext context) async {
final todos = await context.read().fetchAll();
final json = [for (var todo in todos) todo.asMap];
return Response.json(body: json);
}

Future _post(RequestContext context) async {
final json = await context.request.json() as Map;
final todo = await context.read().add(Todo.fromMap(json));
return Response.json(body: todo.asMap);
}


* Handlers for `/todos/[id]` in `routes/todos/[id].dart`
  ```dart


  Future<Response> onRequest(RequestContext context, String id) async {
    return switch (context.request.method) {
      HttpMethod.get => await _get(context, id),
      HttpMethod.put => await _put(context, id),
      HttpMethod.delete => await _delete(context, id),
      _ => Response(statusCode: HttpStatus.notFound)
    };
  }

  Future<Response> _get(RequestContext context, String id) async {
    final todo = await context.read<TodoRepository>().getById(id);

    return Response.json(body: todo.asMap);
  }

  Future<Response> _put(RequestContext context, String id) async {
    final json = await context.request.json() as Map<String, dynamic>;
    final todo = Todo.fromMap(json);
    await context.read<TodoRepository>().updateById(todo);
    return Response();
  }

  Future<Response> _delete(RequestContext context, String id) async {
    final json = await context.request.json() as Map<String, dynamic>;
    final id = json['id'] as String;
    await context.read<TodoRepository>().deleteById(id);
    return Response();
  }

Each handler does the simple thing. Just call the repository methods and return the response. The repository is injected into the handler using the dependency injection with the middleware.

Dependency Injection with the middleware

Dart Frog supports the dependency injection natively. We can inject the repository into the handler using the middleware. The middlewares are also directory based. For example, routes/todos/_middleware.dart is the middleware for the routes/todos route. The _middleware.dart file is a particular file name that represents the middleware for the directory.



InMemoryTodoRepository? _todoData;

Handler middleware(Handler handler) {
  return handler.use(
    provider<TodoRepository>(
      (context) => _todoData ??= InMemoryTodoRepository(),
    ),
  );
}

The code above injects the InMemoryTodoRepository into the provider so the handler can access the repository. Thanks to the middleware with the dependency injection, we can easily use it from the handler as below.



await context.read<TodoRepository>()

Repository with in-memory database

I said it's a database, but it's just a simple List. It's not an actual database. It's just an example. The repository interface is in the shared package. The backend implements it as the in-memory database repository. The repository contains the List of Todo data model.



  class InMemoryTodoRepository implements TodoRepository {
    /// Local data
    List<Todo> data = [];

    /// Get List of [Todo]
    List<Todo> get todos => data;

    @override
    Future<Todo> getById(String id) async {
      return data.firstWhere((todo) => todo.id == id);
    }

    /// Add a new [todo] and return [Todo] with new id
    @override
    Future<Todo> add(Todo todo) async {
      final newTodo = todo.copyWith(id: const Uuid().v4());
      data = [...data, newTodo];
      return newTodo;
    }

    @override
    Future<void> deleteById(String id) async {
      data = [
        for (final t in data)
          if (t.id != id) t
      ];
    }

    @override
    Future<List<Todo>> fetchAll() async {
      return data;
    }

    @override
    Future<void> updateById(Todo todo) async {
      data = [
        for (final t in data)
          if (t.id == todo.id) todo else t
      ];
    }
  }

As you can see, it has some CRUD methods for mutating the List<Todo> data.

Frontend

The Frontend app is written in Flutter. It uses the Riverpod for state management and dependency injection. Same as the backend architecture, we store the implemented repository in the provider so the todoListProvider can access the repository. The todoListProvider is the riverpod provider that handles the business logic of the todo list.

Presentation and pages

There are two folders for UI code: presentation and pages. The presentation folder contains the code for widgets. The pages folder contains the UI code for pages. The pages/todo_page.dart is the main page that displays the todo list and form using the TodoListView and TodoTextField widgets in the presentation folder. main.dart is the entry point of the Flutter application that displays the TodoPage.

In the body of the TodoPage, it renders a column with the TodoListView and TodoTextField widgets.



const Column(
  children: [
    Padding(
      padding: EdgeInsets.all(16.0),
      child: TodoTextField(),
    ),
    Expanded(child: SelectionArea(child: TodoListView())),
  ],
),

The TodoTextFiled Widget is a simple text field that handles the input and submits the todo item. When the user submits the text field, it's calling todoListProvier's add method.



class _TodoTextFieldState extends ConsumerState<TodoTextField> {
  final controller = TextEditingController();
  final focusNode = FocusNode();

  @override
  Widget build(BuildContext context) {
    return TextField(
      decoration: const InputDecoration(
        hintText: 'Enter a new todo',
      ),
      focusNode: focusNode,
      controller: controller,
      onSubmitted: (value) async {
        await ref.read(todoListProvider.notifier).add(
              Todo(id: '', title: value),
            );
        controller.clear();
        focusNode.requestFocus();
      },
    );
  }
}

The TodoListView Widget is a simple list view that displays the todo list. It watches the todoListProvider and rebuilds the list view when the todo list is changed. When the user clicks the checkbox, it calls todoListProvier's toggle method.



class TodoListView extends ConsumerWidget {

  const TodoListView({super.key});

@override

  Widget build(BuildContext context, WidgetRef ref) {

    return switch (ref.watch(todoListProvider)) {

      AsyncData(:final value) => ListView.builder(

          padding: const EdgeInsets.all(16),

          itemCount: value.length,

          itemBuilder: (context, index) => TodoItem(todo: value[index]),

        ),

      AsyncLoading() => const Center(child: CircularProgressIndicator()),

      _ => const Center(child: Text("Error")),

    };

  }

}

class TodoItem extends ConsumerWidget {

  const TodoItem({super.key, required this.todo});

final Todo todo;

@override

  Widget build(BuildContext context, WidgetRef ref) {

    return Row(

      mainAxisAlignment: MainAxisAlignment.spaceBetween,

      children: [

        Text(todo.title),

        Checkbox(

          value: todo.isDone,

          onChanged: (value) {

            ref.read(todoListProvider.notifier).toggle(todo);

          },

        ),

      ],

    );

  }

}

Business logic with the Riverpod

The todoListProvider is the riverpod's AsyncNotifier provider that handles the business logic of the todo list. It calls the RemoteTodoRepository's methods for communicating with the backend. When it's initialized, it calls the fetchAll method of the TodoRepository to fetch all the Todo items from the backend and cache them. The add and toggle methods call the add and updateById methods of the TodoRepository. It updates the backend todo list and renews the local cache with the latest todo items in the provider.



@riverpod

class TodoList extends _$TodoList {

  @override

  FutureOr<List<Todo>> build() {

    return ref.read(todoRepositoryProvider).fetchAll();

  }

Future<void> add(Todo todo) async {

    state = await AsyncValue.guard(() async {

      await ref.read(todoRepositoryProvider).add(todo);

      return ref.read(todoRepositoryProvider).fetchAll();

    });

  }

void toggle(Todo todo) async {

    state = await AsyncValue.guard(() async {

      await ref

          .read(todoRepositoryProvider)

          .updateById(todo.copyWith(isDone: !todo.isDone));

      return ref.read(todoRepositoryProvider).fetchAll();

    });

  }

}

Rest API Client

RemoteTodoRepository is the rest api client for communicating with the backend, which is implementing the TodoRepository interface. It uses the http package for making the HTTP request. It's calling the http package's get, post, put, and delete methods for communicating with the backend.



class RemoteTodoRepository implements TodoRepository {

  @override

  Future<Todo> add(Todo todo) async {

    final client = http.Client();

    final response = await client.post(

      Uri.parse("$baseURL/todos"),

      headers: {

        'Origin': 'http://localhost:8080',

        'Content-Type': 'application/json',

      },

      body: jsonEncode(todo.asMap),

    );

    final json = response.body;

<span class="k">return</span> <span class="n">Todo</span><span class="o">.</span><span class="na">fromMap</span><span class="p">(</span><span class="n">jsonDecode</span><span class="p">(</span><span class="n">json</span><span class="p">));</span>



}

@override

  Future<void> deleteById(String id) async {

    final client = http.Client();

    await client.delete(

      Uri.parse("$baseURL/todos/$id"),

      headers: {

        'Origin': 'http://localhost:8080',

        'Content-Type': 'application/json',

      },

    );

  }

@override

  Future<List<Todo>> fetchAll() async {

    final client = http.Client();

    final response = await client.get(

      Uri.parse("$baseURL/todos"),

      headers: {

        'Origin': 'http://localhost:8080',

        'Content-Type': 'application/json',

      },

    );

    final json = response.body;

<span class="k">return</span> <span class="p">[</span><span class="k">for</span> <span class="p">(</span><span class="kd">final</span> <span class="n">todo</span> <span class="k">in</span> <span class="n">jsonDecode</span><span class="p">(</span><span class="n">json</span><span class="p">))</span> <span class="n">Todo</span><span class="o">.</span><span class="na">fromMap</span><span class="p">(</span><span class="n">todo</span><span class="p">)];</span>



}

@override

  Future<Todo> getById(String id) async {

    final client = http.Client();

    final response = await client.get(

      Uri.parse("$baseURL/todos/$id"),

      headers: {

        'Origin': 'http://localhost:8080',

        'Content-Type': 'application/json',

      },

    );

    final json = response.body;

<span class="k">return</span> <span class="n">Todo</span><span class="o">.</span><span class="na">fromMap</span><span class="p">(</span><span class="n">jsonDecode</span><span class="p">(</span><span class="n">json</span><span class="p">));</span>



}

@override

  Future<void> updateById(Todo todo) async {

    final client = http.Client();

    await client.put(

      Uri.parse("$baseURL/todos/${todo.id}"),

      headers: {

        'Origin': 'http://localhost:8080',

        'Content-Type': 'application/json',

      },

      body: jsonEncode(todo.asMap),

    );

  }

}

Summary

We've built a full-stack application with Flutter and Dart. We used Flutter for the client and Dart Frog for the server. Flutter displayed the UI, and Dart Frog handled the business logic and data storage. We used the mono-repo structure for the project. We created three packages: backend, frontend, and shared. shared package contained all the code that is shared between the client and server. backend package contained all the code for the server(Dart Frog) and frontend package contained all the code for the client(Flutter).

We would need to run performance benchmarks to use dart as the backend language before we decided to build a production application, but the development experience was great. I liked the basic tooling of the dart_frog. It's simple and easy to use, like Flutter. I also liked the dependency injection with the middleware. I could build the full-stack application with the Dart Frog without spending too much time learning the framework.

The complete code example is available at https://github.com/leehack/fullstack_dart_todo

How to use Firebase Emulator suite for Flutter

Jhin Lee — Thu, 29 Jun 2023 14:38:25 +0000

The Firebase provides an emulator suite for the local dev environment. The suite allows us to run the Firebase on the local machine. So, we can locally use Cloud Firestore, Realtime Database, Cloud Storage for Firebase, Authentication, Firebase Hosting, Cloud Functions (beta), Pub/Sub (beta), and Firebase Extensions (beta) for the app we are working on.

More detail can be found at https://firebase.google.com/docs/emulator-suite

Pre-Requisite

The Flutter project is initialized for the Firebase: https://firebase.google.com/docs/flutter/setup

Install the Emulator Suite

Setup the Emulator Suite with this command under the project directory:



firebase init emulators

Start the Emulator Suite



firebase emulators:start

Run the Flutter app using the Emulators

Add this lines of code in the main() in main.dart



void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // Initialize Firebase
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  // Use Firebase Emulators
  if (kDebugMode) { // Only for debug mode.
    try {
      final emulatorHost = defaultTargetPlatform == TargetPlatform.android
          ? "10.0.2.2"
          : "localhost";
      FirebaseStorage.instance.useStorageEmulator(emulatorHost, 9199);
      FirebaseFirestore.instance.useFirestoreEmulator(emulatorHost, 8080);
    } catch (e) {
      // ignore: avoid_print
      print(e);
    }
  }
  // Start Flutter Application
  runApp(const MyApp());
}

The code example makes the app use FireStorage and Firestore Emulators in debug mode. It also provides Web UI(http://localhost:4000) for easy inspection.

How to screenshot a widget in the flutter

Jhin Lee — Wed, 23 Nov 2022 00:32:06 +0000

Define a global key

GlobalKey previewContainer = GlobalKey();

Wrap the screenshot area with RepaintBoundary

FittedBox(
    fit: BoxFit.contain,
    child: RepaintBoundary(
        key: previewContainer,
        child: Container( // The widget to capture
            width: 500,
            height: 500,
            color: Colors.blue,
        ),
    ),
)

Screenshot for the widget

Future<Uint8List> _capture() async {
    RenderRepaintBoundary boundary = previewContainer.currentContext
        ?.findRenderObject() as RenderRepaintBoundary;
    final image = await boundary.toImage(pixelRatio: 2);
    final byteData = await image.toByteData(format: ImageByteFormat.png);
    return byteData!.buffer.asUint8List();
}

Journey to the clean architecture for my flutter app

Jhin Lee — Mon, 31 Oct 2022 19:15:31 +0000

Motivation

When I started my flutter project two years ago, Android Jetpack architecture inspired me a lot. DataBinding between ViewModel and View using LiveData that comes from the data layer passing through the repository and so on, as I mentioned in another posting

(I cannot find this diagram anymore from the official google document. They added the domain layer as an optional recommendation: link)

My project folder structure was something like this:

- lib
  - repositories
    - a_repository.dart
    - b_repository.dart
  - models
    - a_model.dart
    - b_model.dart
  - services
    - a_service.dart
    - b_service.dart
  - ui
    - pages
      - pageA
        - a_page.dart
        - a_viewmodel.dart
      - pageB
        - b_page.dart
        - b_viewmodel.dart
    - widgets
      - a_widget.dart
      - b_widget.dart
  - main.dart
  - DI.dart

DI.dart wasn't truly doing the dependency injection. Still, I was initializing all global dependencies as singletons to inject them into the page-scoped ViewModels when initializing the page.

The problem with this approach was that the ViewModel held too much business logic. If I needed to use similar logic for another page, I had to reimplement the logic in the ViewModel. Eventually, I started adding ViewModels in a shared folder and reusing them directly from the widgets, creating another instance of the ViewModel. It reduced the code duplication, but it made it look messy. Whenever I tried to add a new feature, it was confusing where I should put the new codes.

Clean architecture

After some research, I decided to apply the clean architecture I've used for a golang backend project. The clean architecture was quite famous for the flutter project, too, since it's a recommended architecture by BLoC, a popular state management library in dart.

Layer-First structure

I started to restructure the directory based on the layer. (At this moment, I also decided to use riverpod instead of provider)

- lib
  - data
    - remote
      - repositories
        - a_repository_impl.dart
        - b_repository_impl.dart
      - models
        - a_model.dart
        - b_model.dart
      - services
        - a_service.dart
        - b_service.dart
      - data_provider.dart
  - domain
    - entities
      - a_entity.dart
      - b_entity.dart
    - repositories
      - a_repository.dart
      - b_repository.dart
    - usecases
      - featureA
        - get.dart
        - get_many.dart
      - featureB
        - get.dart
        - get_by_filter.dart
    - providers
      - feature_a_usecase_provider.dart
      - feature_b_usecase_provider.dart
  - presentation
    - states
      - a_state_provider.dart
      - b_state_provider.dart
    - pages
      - pageA
        - a_page.dart
      - pageB
        - b_page.dart
    - widgets
      - a_widget.dart
      - b_widget.dart
  - main.dart

The repositories in the domain layer are abstract classes that interface between the domain and the data layer. The data_provider.dart initialize the service and repository providers. The providers in the domain layer are initializing the usecases using repository providers defined in data_provider.dart. The states in the presentation layer only access entities and usecase providers in the domain layer.

The model is a service-specific model that holds entity getter(mapper)

// a_model.dart
class ModelA {
    ModelA({this.name});
    final name;

    EntityA get entity => Entity(name: name);
}

The service can locally or remotely access the raw data source

// a_service.dart
abstract class ServiceA {
    ModelA get(String a);
}
class ServiceAImpl implements ServiceA {
    ModelA get(String a) {
        return ModelA(name: "test");
    }
}

The implementation of the repository that accesses the service

// a_repository_impl.dart
class RepositoryAImpl implements RepositoryA {
    RepositoryAImpl(this.service);
    final ServiceA service;
    EntityA get(String id) {
        return service.get(id).entity;
    }
}

Initialize services and repositories(Services are private)

// data_provider.dart
final _serviceAProvider = Provider<ServiceA>((_) => ServiceAImpl());
final repositoryAProvider = Provider<RepositoryA>(
    (ref) => RepositoryAImpl(ref.watch(_serviceAProvider)),
);

Domain entity that application uses

// a_entity.dart
class EntityA {
    EntityA({this.name});
    final name;
}

Interfacing between domain and data layer

// a_repository.dart
abstract class RepositoryA {
    EntityA get(String id);
}

The usecase can access the repository

// featureA/get.dart
abstract class GetA {
    EntityA execute(String id);
}
class GetAImpl implements GetA {
    GetAImpl(this.repo)
    final RepositoryA repo;

    EntityA execute(String id) {
        return repo.get(id)
    }
}

The states in the presentation layer access the usecase through the provider

// feature_a_usecase_provider.dart
final getAProvider = Provider<GetA>((ref) => 
    GetImpl(ref.watch(repositoryAProvider)),
);

States are globally shared and accessible from widgets

// a_state_provider.dart
final stateAProvider = StateNotifierProvider<EntityA>((ref){
    return StateANotifier(EntityA(), ref);
});
class StateANotifier extends StateNotifier<EntityA> {
    StateANotifier(super.state, this.ref)
    final Ref ref;

    void fetch(String id) {
        state = ref.watch(getAProvider).execute(id);
    }
}

Widget accesses the states

// a_widget.dart
class WidgetA extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final stateA = ref.watch(stateAProvider);
    return InkWell(
      onTap: () => ref.read(stateAProvider.notifier).fetch(),
      child: Text('${stateA.name}'),
    );
}

After the massive refactoring of the architecture (Even though it looks like there are a lot of boilerplate codes), I was pretty satisfied. I don't need to think twice about where to put which logic. Every business logic goes to the usecase and entity. If the view needs to update the state, I create the StateNotifierProvider. The Widgets only focus on the viewing part. The separation gives better testability and lets the codes keep the single responsibility rule.

Feature-First structure

After the refactoring, the only problem I had was that it was not easy to navigate the source code. When implementing a feature, I wished all related codes were grouped. Since the codes are split based on the layer, It was pretty easy to lose my focus.
So, I decided to do another refactoring for a feature-first structure.

- lib
  - features
    - featureA
      - domain
        - entity
          - a_entity.dart
        - repository
          - a_repository.dart
        - usecases
          - get.dart
          - get_many.dart
      - data
        - repositories
          - a_repository_impl.dart
        - models
          - a_model.dart
        - services
          - a_service.dart
        - data_provider.dart
      - providers
        - feature_a_usecase_provider.dart
    - featureB
      - domain
        - entity
          - b_entity.dart
        - repository
          - b_repository.dart
        - usecases
          - get.dart
          - get_many.dart
      - data
        - repositories
          - b_repository_impl.dart
        - models
          - b_model.dart
        - services
          - b_service.dart
        - data_provider.dart
      - providers
        - feature_b_usecase_provider.dart
  - presentation
    - states
      - a_state_provider.dart
      - b_state_provider.dart
    - pages
      - pageA
        - a_page.dart
      - pageB
        - b_page.dart
    - widgets
      - a_widget.dart
      - b_widget.dart
  - main.dart

For the code-wise, nothing changed. Some might wonder why I didn't put the presentation in the feature directory. I still don't have a conclusion on this, but I thought the UI should use different domains, and I didn't want to cross-reference between features. I didn't specify above, but I put the shared codes in the core feature. It's the only exception that other features can reference.

Conclusion

I don't have any good recommendations for a small project or team if the clean architecture is a good choice or not since it requires some boilerplate codes. But It gives us a good separation between layers and domains, making the code more testable. It can take time to write the pattern every time adding a new feature, but the time can be easily compensated by focusing on implementing a single domain feature. There's no perfect architecture or solution. One day, we need to refactor our code base. A library we've been using probably doesn't fit our needs anymore or introduces security vulnerabilities. The well-structured architecture allows quickly switching a library or refactoring a part of your code.

References

Journey to the riverpod for my flutter app.

Jhin Lee — Mon, 31 Oct 2022 01:59:38 +0000

In this article, I'd like to talk about how I ended up using Riverpod as a state management system for my flutter app.

Provider with MVVM
get_it for global dependencies
Riverpod

Provider with MVVM

When I started the flutter project as a newbie two years ago, I wanted to build something similar to the MVVM pattern I used to use for Android application development. After some research, I found Provider the most straightforward option. (I wasn't even thinking of state management at that time)

So, I was doing something like this at the entry point of the app:

final serviceA = ServiceA();
final serviceB = ServiceB();
MultiProvider(
  providers: [
    Provider<RepoA>(create: (_) => RepoA(service:serviceA)),
    Provider<RepoB>(create: (_) => RepoB(service:serviceA)),
    Provider<RepoC>(create: (_) => RepoC(service:serviceB)),
  ],
  child: MaterialApp(),
)

I've been initializing the services and repositories at the application launch time and adding them into the Provider using the MultiProvider. It allowed the ViewModels of each page to access the repositories. (Yes, one view, one ViewModel)

class ViewModelA with ChangeNotifier {
  ViewModelA(this.repo) {
    init();
  }
  final RepoA repo;
  String title;

  Future<void> init() async {
    title = "test";
    notifiyListeners();
  }
}

// Wrap the page with ChangeNotifierProvider
class PageA extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => new ViewModelA(Provider.of<RepoA>(context, listen: false)),
      child: PageView(),
  );
}

I could access the' ViewModel' in any widgets used in the PageView using the Selector.

Selector<ViewModelA, String>(
  selector: (_, vm) => vm.title,
  builder: (_, data, __) {
    return Text('title: ${data}');
  }
)

It was annoying to write the boilerplate codes of the Selector every time I needed to use variables in the ViewModel, but I helped to reduce unnecessary rendering. So far, It's not bad.

After growing the code bases with many repositories and services, I realized that every time I add more repositories in the global provider scope with the MultiProvider, it creates the cascading tree in the widget hierarchy. It made debugging super tricky with the Widget Inspector tool.

One day, I decided to remove MultiProvider and convert all global dependencies as singletons. Technically they were already singletons but just living in the Provider scope anyway.

get_it for global dependencies

After some research, I found the get_it looked promising.
I replaced MultiProvider with getIt singletons at the application start:

final serviceA = ServiceA();
final serviceB = ServiceB();
getIt.registerSingleton<RepoA>(RepoA(service:serviceA));
getIt.registerSingleton<RepoB>(RepoB(service:serviceA));
getIt.registerSingleton<RepoC>(RepoC(service:serviceB));

And the View and ViewModel like this:

class ViewModelA with ChangeNotifier {
  // This allows passing mocked repository to the ViewModel for testing purposes
  ViewModelA(RepoA? repo): _repo = repo ?? GetIt.get<RepoA>() {
    init();
  }
  final RepoA _repo;
  String title;

  Future<void> init() async {
    title = "test";
    notifiyListeners();
  }
}

class PageA extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => new ViewModelA(),
      child: PageView(),
  );
}

Now, I don't see the cascading tree in the widget inspector, and much more comfortable debugging the widgets. I also liked it because the widget doesn't need to know what dependencies the ViewModel needs. Thanks to the GetIt can give it to me without context. But I still have a slow application start problem.

A few months later, I wanted to tackle the start-up time issue and realized I might have a few options.

Use lazy singleton with GetIt.
Go for another approach.

I could have converted the global dependencies to lazy singleton with GetIt so that it doesn't need to initialize all dependencies at the application start. However, It would still keep in the memory until the app completely shut down. I wanted something that could automatically initiate and de-initiate based on the need.
So another round of research started!

Riverpod

In the meantime, I also was working on a react project that uses the React Query, and even though it's not a client-side state management library, I found it a simple and nice way of managing states. I wanted to have something similar but for flutter. Finally, the Riverpod caught my eye. The developer of the Provider developed Riverpod as a successor of the Provider. (Later, I found Recoil is the one I've been looking for in the React app for client state management, and it has a lot of similarities with Riverpod)

As a first step, I converted all singleton services and repositories into Riverpod providers. I also defined abstract classes for better testability.

abstract class ServiceA {}
class ServiceAImpl implements ServiceA {}
abstract class ServiceB {}
class ServiceBImpl implements ServiceB {}

abstract class RepoA {
  Future<List<Entity>> getMany();
}
class RepoAImpl implements RepoA {
  RepoAImpl(this.service)
  final ServiceA service;

  @override
  Future<List<Entity>> getMany() {
    return service.getMany();
  };
}
abstract class RepoB {}
class RepoBImpl implements RepoB {
  RepoBImpl(this.service)
  final ServiceA service;
}
abstract class RepoC {}
class RepoCImpl implements RepoC {
  RepoCImpl(this.service)
  final ServiceB service;
}

final serviceAProvider = Provider<ServiceA>((_) => ServiceAImpl());
final serviceBProvider = Provider<ServiceB>((_) => ServiceBImpl());

final repoAProvider = Provider<RepoA>((ref) => RepoAImpl(ref.watch(serviceAProvider)));
final repoBProvider = Provider<RepoB>((ref) => RepoBImpl(ref.watch(serviceAProvider)));
final repoCProvider = Provider<RepoC>((ref) => RepoCImpl(ref.watch(serviceBProvider)));

I also started getting rid of the ViewModels. Since I can now define a state as a provider that is accessible from any widgets, the ViewModel was too heavy as a state. This way, I was able to write more reusable codes.

Create state providers

// Simple future state provider
final stateAProvider = FutureProvider<List<EntityA>>((ref) {
  return ref.watch(repoAProvider).getMany();
});

// State provider with notifier that contains methods.
final stateBProvider = StateNotifierProvider<EntityB>((ref) {
  return StateBNotifier(EntityB(), ref.watch(repoAProvider));
});

class StateBNotifier extends StateNotifier<ThemeMode> {
  StateBNotifier(super.state, this.repo);
  final RepoA repo;

  void fetch() {
    state = repo.getMany();
  }
}

I can access the providers from widgets.

class WidgetA extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final stateB = ref.watch(stateBProvider);
    return InkWell(
      onTap: () => ref.read(stateBProvider.notifier).fetch(),
      child: Text('${stateB.name}'),
    );
}

With the Riverpod, I could make the state lighter and more reusable. I often create a container widget that holds the state that wraps the pure widgets. This way, the design widget is reusable as a design widget without business context. Providers and widgets are all unit-testable by simply mocking the repository or other dependency of the Provider.

Build a flutter theme switcher with riverpod

Jhin Lee — Sun, 30 Oct 2022 15:03:45 +0000

With this article, I added dark and light themes in the MaterialApp.

Material 3 theme recipe for the flutter app

Jhin Lee ・ Oct 30 '22

#flutter #m3 #theme #material

Now it's time to add a toggle switch in the app. I'll use riverpod. One of the famous framework people uses for state management. As expressed in the official document, It's more caching framework itself, but It's helpful to cache the global states.

Setup the riverpod

Add the riverpod package
```
flutter pub add flutter_riverpod
```

Wrap the MainApp with the ProviderScope
From:

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

To:

void main() {
  runApp(const ProviderScope(child: MyApp()));
}

Implement the theme toggle switch

Add the themeModeProvider

final themeModeProvider = StateProvider<ThemeMode>((ref) {
  return ThemeMode.dark;
});

Convert the MyApp as ConsumerWidget and watch the provider

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final themMode = ref.watch(themeModeProvider);
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        useMaterial3: true,
        colorScheme: lightColorScheme,
        textTheme: textTheme,
      ),
      darkTheme: ThemeData(
        useMaterial3: true,
        colorScheme: darkColorScheme,
        textTheme: textTheme,
      ),
      themeMode: themMode, // Apply them theme
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

Every time the themeModeProvider changes, the widget rebuilds and assigns the new value to the themeMode

final themMode = ref.watch(themeModeProvider);

Add the toggle button

Consumer(builder: (context, ref, child) {
  final theme = ref.watch(themeModeProvider);
  return IconButton(
      onPressed: () {
        ref.read(themeModeProvider.notifier).state =
            theme == ThemeMode.light
                ? ThemeMode.dark
                : ThemeMode.light;
      },
      icon: Icon(theme == ThemeMode.dark
          ? Icons.light_mode
          : Icons.dark_mode));
})

The complete code can be found on github

Material 3 theme recipe for the flutter app

Jhin Lee — Sun, 30 Oct 2022 02:44:28 +0000

Apply Color scheme

1. Create the color scheme and export it using the theme builder.

https://m3.material.io/theme-builder

For collaborating with UI designers, it can be generated from Figma as well:
https://www.figma.com/community/plugin/1034969338659738588/Material-Theme-Builder
https://www.figma.com/community/file/1035203688168086460

The web version of the theme builder creates the color_schemes.g.dart file with an example(main.g.dart).
Copy the color_schemes.g.dart file into the project.

2. Set the theme with the MaterialApp()



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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(useMaterial3: true, colorScheme: lightColorScheme),
      darkTheme: ThemeData(useMaterial3: true, colorScheme: darkColorScheme),
      themeMode: ThemeMode.light, // Default is system
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

The themeMode is the system by default. Change and verify if the colors are good.

Apply typography

1. Create a typography file



// Example typography.dart file
import 'package:flutter/material.dart';
import 'package:google_fonts/google_fonts.dart';

final textTheme = TextTheme(
  displayLarge: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 57,
    height: 64 / 57,
    letterSpacing: -0.25,
  ),
  displayMedium: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 45,
    height: 52 / 45,
  ),
  displaySmall: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 36,
    height: 44 / 36,
  ),
  headlineLarge: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 32,
    height: 40 / 32,
  ),
  headlineMedium: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 28,
    height: 36 / 28,
  ),
  headlineSmall: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 24,
    height: 32 / 24,
  ),
  titleLarge: GoogleFonts.inter(
    fontWeight: FontWeight.w700,
    fontSize: 22,
    height: 28 / 22,
  ),
  titleMedium: GoogleFonts.inter(
    fontWeight: FontWeight.w600,
    fontSize: 16,
    height: 24 / 16,
    letterSpacing: 0.1,
  ),
  titleSmall: GoogleFonts.inter(
    fontWeight: FontWeight.w600,
    fontSize: 14,
    height: 20 / 14,
    letterSpacing: 0.1,
  ),
  labelLarge: GoogleFonts.inter(
    fontWeight: FontWeight.w700,
    fontSize: 14,
    height: 20 / 14,
  ),
  labelMedium: GoogleFonts.inter(
    fontWeight: FontWeight.w700,
    fontSize: 12,
    height: 16 / 12,
  ),
  labelSmall: GoogleFonts.inter(
    fontWeight: FontWeight.w700,
    fontSize: 11,
    height: 16 / 11,
  ),
  bodyLarge: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 16,
    height: 24 / 16,
  ),
  bodyMedium: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 14,
    height: 20 / 14,
  ),
  bodySmall: GoogleFonts.inter(
    fontWeight: FontWeight.w400,
    fontSize: 12,
    height: 16 / 12,
  ),
);

In the example, I used GoogleFont. Should you wish to use the google font, add the package.



flutter pub add google_fonts

Adjust the values according to the design.

2. Apply the typography to MaterialApp (textTheme)



      theme: ThemeData(
        useMaterial3: true,
        colorScheme: lightColorScheme,
        textTheme: textTheme,
      ),
      darkTheme: ThemeData(
        useMaterial3: true,
        colorScheme: darkColorScheme,
        textTheme: textTheme,
      ),

How to use the theme in your widgets

By default, everything should be set with the theme we defined. You can use these methods if you need to override them for some widgets.



// Method 1 - Read from the context and apply
final color = Theme.of(context).colorScheme.primary;
Container(color: color);

// Method 2 - Wrap the widget with the Theme
Theme(
      data: Theme.of(context).copyWith(
        textTheme: Theme.of(context)
            .textTheme
            .apply(displayColor: Colors.white, bodyColor: Colors.white),
      ),
      child: Widget(),
)

Never hard code colors or text styles.

The complete code can be found on github

Interesting Dart Syntax: mixin application class

Jhin Lee — Sat, 29 Oct 2022 14:07:44 +0000

Recently I just got to know this dart syntax. You can define a class with a mixin like this:

class Foo = Bar with Baz;

Without the syntax, you would probably do this:

class Foo extends Bar with Baz {
  Foo(): super();
}

Currently, there is an issue in DDC with the syntax, so probably better not to use it for the flutter web project yet:

Error with private variable setters in mixins on dart web. #50119

TimWhiting posted on Oct 03, 2022

dart --version 2.19.0-266.0.dev, also on stable / beta channels web / chrome

Very similar issue to https://github.com/dart-lang/sdk/issues/44636.

Simplest reproduction so far: Edit: See @schultek's minimum sample below for a simpler reproduction.

dart create -t web-simple call_stack_overflow && cd call_stack_overflow
Replace main with the following

import 'dart:html';
import 'package:riverpod/riverpod.dart';

void main() {
  final container = ProviderContainer();
  final value = container.read(stringValue.state);
  querySelector('#output')?.text = 'Your ${value.state} app is running.';
}

final stringValue = StateProvider.autoDispose((ref) => 'Hello world');

Add Riverpod to pubspec with riverpod: ^2.0.0
Run sample with webdev serve
Visit web app and check the console.

Stack overflow on private setter in a mixin. Making the field in the package public shifts the error to another private member.

 .......
    at set [_keepAliveLinks] (auto_dispose.dart:42:7)
    at set [_keepAliveLinks] (auto_dispose.dart:42:7)
    at set [_keepAliveLinks] (auto_dispose.dart:42:7)
    at AutoDisposeProviderElementMixin.<computed> (auto_dispose.dart:6:24)
    at StateProviderElement_AutoDisposeProviderElementMixin$36.__ (base.dart:81:48)
    at new AutoDisposeStateProviderElement.__ (auto_dispose.dart:42:7)
    at AutoDisposeStateProvider.new.createElement (auto_dispose.dart:31:44)
    at [_create] (container.dart:49:32)
    at framework._StateReader.new.getElement (container.dart:41:52)
    at container.dart:434:37
    at framework.ProviderContainer.new.readProviderElement (container.dart:466:14)
    at ProviderElementProxy.new.read (proxy_provider_listenable.dart:112:25)
    at framework.ProviderContainer.new.read (container.dart:257:20)
    at main$ (main.dart:25:26)
    at main.dart.bootstrap.js:273:10
    at Array.forEach (<anonymous>)
    at window.$dartRunMain (main.dart.bootstrap.js:272:32)
    at <anonymous>:1:8
    at Object.runMain (client.js:8777:21)

Originally reported here: https://github.com/rrousselGit/riverpod/issues/1713

I tried creating a more minimal sample, but was unsuccessful.

View on GitHub

But I pretty much like the syntax that makes the code cleaner.

Start the flutter monorepo project

Jhin Lee — Wed, 26 Oct 2022 00:30:11 +0000

Basic recipe to start monorepo project for flutter

Install melos (more details about melos: https://melos.invertase.dev/)
```
dart pub global activate melos
```

Create a project folder

mkdir flutter_project
cd flutter_project

Add melos.yaml file

name: flutter_skeleton

packages:
  - packages/**
  - apps/**

command:
  bootstrap:
    usePubspecOverrides: true

scripts:
  analyze:
    exec: flutter analyze .
  outdated:
    exec: flutter pub outdated
  test:
    exec: flutter test

Create .gitignore and add pubspec_overrides.yaml in it.

Create the main app

mkdir apps # create dir for applications
cd apps
flutter create main_app

Add a library package

cd .. # go back to the root dir of the project
mkdir packages # create dir for shared packages
cd packages 
flutter create --template=package lib_example

Bootstrap melos
```
melos bs # melos bootstrap
```

Try melos scripts added in melos.yaml file

melos analyze # run analyze for all packages
melos test # run test for all packages
melos outdated # check outdated pub dependencies for all packages
melos upgrade # Update dependencies for all packages

That's it! Now you have the monorepo project ready to start. You can open the root directory with vscode or IntelliJ(Or Android Studio). melos already bootstrapped the IntelliJ project. Nothing to do with vscode, but you can install the extension if it makes your life easier.

More information: https://melos.invertase.dev/ide-support

Use the shared package from the main app

Add the package name as a dependency in the pubspec.yaml

Something like:

dependencies:
  lib_example:
    path:../packages/lib_example

You can indicate the package version instead of the path if you ever published the package to the pub.dev. I had to put path because flutter pub outdated doesn't respect the pubspec_overrides.yaml for the local dependency for the moment.

The complete code can be found on github

Optimize Flutter iOS Build using ccache

Jhin Lee — Mon, 24 Oct 2022 01:31:46 +0000

Liquid syntax error: Unknown tag 'endraw'

DEV Community: Jhin Lee

Why I Built llamadart: Offline Local LLM Inference for Dart/Flutter

What llamadart is

Architecture overview

Build hook deep dive: how native binaries are delivered

Hook entry point

What happens at build/run time

How GitHub is used

Runtime FFI resolution

Why this matters in practice

A quick note on dinja

Minimal usage example

Closing

How to use GoLang in Flutter Application - Golang FFI

What is FFI?

Create a plugin project for Flutter

Create a GoLang library

Compile the GoLang library for Android

Compile the GoLang library for iOS

Create a binding in Dart using ffigen

Use the GoLang library in Dart

Conclusion

Let's build a full-stack dart app

What will we build?

Why full-stack in Dart?

Project Structure

Shared package (packages/todo)

Backend package (packages/backend_frog)

Frontend package (packages/frontend_flutter)

Mono-repo setup

Create the backend package with the Dart Frog

Create the frontend package with the Flutter

Create the pure Dart shared package

Global Architecture

Backend

Routes

Dependency Injection with the middleware

Repository with in-memory database

Frontend

Presentation and pages

Business logic with the Riverpod

Rest API Client

Summary

How to use Firebase Emulator suite for Flutter

Pre-Requisite

Install the Emulator Suite

Start the Emulator Suite

Run the Flutter app using the Emulators

How to screenshot a widget in the flutter

Define a global key

Wrap the screenshot area with RepaintBoundary

Screenshot for the widget

Journey to the clean architecture for my flutter app

Motivation

Clean architecture

Layer-First structure

Feature-First structure

Conclusion

References

Journey to the riverpod for my flutter app.

Provider with MVVM

get_it for global dependencies

Riverpod

Build a flutter theme switcher with riverpod

Material 3 theme recipe for the flutter app

Jhin Lee ・ Oct 30 '22

Setup the riverpod

Implement the theme toggle switch

Material 3 theme recipe for the flutter app

Apply Color scheme

1. Create the color scheme and export it using the theme builder.

2. Set the theme with the MaterialApp()

Apply typography

1. Create a typography file

2. Apply the typography to MaterialApp (textTheme)

How to use the theme in your widgets

Interesting Dart Syntax: mixin application class

Error with private variable setters in mixins on dart web. #50119

Start the flutter monorepo project

Basic recipe to start monorepo project for flutter

Create a binding in Dart using `ffigen`