Posts on bettercoding.dev

Drift – Using an SQLite Database with Flutter

Wed, 09 Oct 2024 00:00:00 +0000

This article is part of the Data Storage in Flutter series.

In some previous tutorials, I showed you how to use sembast and isar as a local data storage for your Flutter apps. This time, we are going to use the drift package to store our data in an SQLite database.

I will use the same app structure as in the other two tutorials to keep them comparable and only talk about the differences here.

SQLite is a very commonly used database for mobile apps, this makes it a very safe choice. Since it’s a relational SQL database this means that it requires the user to specify the data structure in the form of database tables. That is a different approach to databases like sembast which stores any type of JSON data.

The drift package helps us to take away some of the heavy lifting. That way, we don’t need to write any SQL statements – but we can if we wish.

You can find the source code for this tutorial on GitHub: https://github.com/bettercoding-dev/drift-sqlite

Prerequisites

There four packages are needed for adding drift to your project: drift, drift_flutter, drift_dev and build_runner. Together with the packages for riverpod and freezed this is what our dependencies should look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


dependencies:
 drift: ^2.20.3
 drift_flutter: ^0.2.0
 flutter:
 sdk: flutter
 flutter_riverpod: ^2.5.1
 freezed_annotation: ^2.4.4
 json_annotation: ^4.9.0
 riverpod_annotation: ^2.3.5

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^4.0.0
 build_runner: ^2.4.13
 riverpod_generator: ^2.4.3
 freezed: ^2.5.7
 json_serializable: ^6.8.0
 drift_dev: ^2.20.3

To add them all at once, you can use this command:

flutter pub add drift drift_flutter flutter_riverpod freezed_annotation json_annotation riverpod_annotation dev:build_runner dev:riverpod_generator dev:freezed dev:json_serializable dev:drift_dev

The drift package also relies on code generation. To watch for changes and rebuild the generated classes, use:

dart run build_runner watch --delete-conflicting-outputs

The `CakeTable`

In contrast to sembast, where we had no schema definition at all, and isar where the schema could be derived from a data class, when using drift we need to manually specify our database table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import 'package:drift/drift.dart';
import 'package:local_storage_sqlite_drift/cake/model/cake.dart';

@UseRowClass(Cake)
class CakeTable extends Table {
 IntColumn get id => integer().autoIncrement()();

 TextColumn get name => text()();

 IntColumn get yummyness => integer()();
}

This is relatively simple, but we need to be careful to have our CakeModel and the CakeTable in sync. Notice the @UseRowClass annotation. This binds the Cake class to this table and helps deserialize the data when reading the database.

Creating a Database

With drift we need to create a class to specify our database.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


import 'package:drift/drift.dart';
import 'package:drift_flutter/drift_flutter.dart';
import 'package:local_storage_sqlite_drift/cake/database/cake_table.dart';
import 'package:local_storage_sqlite_drift/cake/model/cake.dart';

part 'cake_database.g.dart';

@DriftDatabase(tables: [CakeTable])
class CakeDatabase extends _$CakeDatabase {
 CakeDatabase() : super(_openConnection());

 @override
 int get schemaVersion => 1;

 static QueryExecutor _openConnection() {
 return driftDatabase(name: 'cake_database');
 }
}

Using the @DriftDatabase (line 7) annotation we mark our database class and specify the tables that should exist in the database.

The super constructor (line 9) requires us to pass in a QueryExecutor object that opens the database. We can use the driftDatabase function for this case.

In line 12 we need to specify a schema version. This becomes relevant when migrating between different versions of the database.

As with the other tutorials, we create a provider for the database. With drift this can be done synchronously.

1
2
3
4
5
6
7


import 'package:local_storage_sqlite_drift/common/database/cake_database.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'global_providers.g.dart';

@riverpod
CakeDatabase database(DatabaseRef ref) => CakeDatabase();

Implementing `CakeRepsoitory` with `drift`

Finally, let’s implement the CakeRepository. For simple database operations as we use in this case, drift offers us so-called managers. We can access the functions for the CakeTablelike this:

database.managers.cakeTable

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


import 'package:drift/drift.dart';
import 'package:local_storage_sqlite_drift/cake/model/cake.dart';
import 'package:local_storage_sqlite_drift/cake/repository/cake_repository.dart';
import 'package:local_storage_sqlite_drift/common/database/cake_database.dart';

class DriftCakeRepository implements CakeRepository {
 final CakeDatabase database;

 const DriftCakeRepository(this.database);

 @override
 Future deleteCake(int cakeId) =>
 database.managers.cakeTable.filter((cake) => cake.id(cakeId)).delete();

 @override
 Stream<List<Cake>> getAllCakesStream() => database.managers.cakeTable.watch();

 @override
 Future<int> insertCake(Cake cake) =>
 database.managers.cakeTable.create(
 (o) =>
 o(
 name: cake.name,
 yummyness: cake.yummyness,
 ),
 );

 @override
 Future updateCake(Cake cake) =>
 database.managers.cakeTable
 .filter((row) => row.id(cake.id))
 .update((o) =>
 o(
 name: Value(cake.name),
 yummyness: Value(cake.yummyness)
 )
 );
}

Lines 11–13: To delete a single instance, we need to first create a filter on a Cake with the given id, and can then call the delete function.
Lines 15–16: The watch function allows us to listen to changes to the table’s content. Since we specified Cake as the “row class” deserialization happens automatically.
Lines 19–26: Inserting takes a few more lines of code. Here we have to use the create function and manually map the Cake attributes.
Lines 29–37: Updating works similarly to inserting data. The only difference is that we first need to filter which rows should be affected, and then use the update function.

Summary

In this tutorial you learned how to use drift to use SQLite as your app’s data storage.

We specified a table that matches our data model, initialized a database and implemented the CakeRepository to create, update, delete and read data from the database.

Of course, drift comes with a ton more of features. If you plan to use this package for your next app, I’d recommend you checking out the documentation: https://drift.simonbinder.eu.

Using Isar as a Reactive Database for Flutter

Mon, 07 Oct 2024 00:00:00 +0000

This article is part of the Data Storage in Flutter series.

Almost every app relies on storing data locally on the device. In the past, I already created tutorials for how to use the sembast package.

Initially, I wanted to write a tutorial on the hive package, but the last release was made over two years ago. Instead, the developers created a new package called * *isar**, which is now the recommended alternative.

The Cake App revisited

As the basis of this tutorial, I will use the same structure as I already used in my tutorial “Using sembast with riverpod”. Therefore, I will here mainly talk about the differences, since the UI and the state management are completely identical.

As always, the source code of this example is available on GitHub: https://github.com/bettercoding-dev/isar-reactive-database

What is a reactive database?

First, let’s quickly have a look at what I mean with reactive databases. In a conventional database, when you make changes to the data (create, update, delete something), the changes are applied and that’s it. This means, to display the changes in the UI, you will have to explicitly read the database to get the most recent data.

Some modern databases, like isar, allow listening to changes in the data. You can create a stream to the database, which automatically updates every time the data changes. This way, instead of manually pulling the data from the database, every time something changes, the database actively pushes changes to the UI.

In our case, isar provides a watch function that can be used on queries, so everytime the query result changes, the UI updates automatically.

Using `isar` as a reactive local storage

Prerequisites

First, let’s have a look at the dependencies we need for this tutorial. The dependencies section in our pubspec.yaml should look like this

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


dependencies:
 flutter:
 sdk: flutter
 flutter_riverpod: ^2.5.1
 freezed_annotation: ^2.4.4
 isar: ^3.1.0+1
 isar_flutter_libs: ^3.1.0+1
 json_annotation: ^4.9.0
 path_provider: ^2.1.4
 riverpod_annotation: ^2.3.5

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^4.0.0
 isar_generator: ^3.1.0+1
 build_runner: ^2.4.13
 riverpod_generator: ^2.4.0
 freezed: ^2.5.2
 json_serializable: ^6.8.0

To quickly install the dependencies, you can run:

flutter pub add flutter_riverpod freezed_annotation isar isar_flutter_libs json_annotation path_provider riverpod_annotation dev:isar_generator dev:build_runner dev:riverpod_generator dev:freezed dev:json_serializable

Initializing Isar

Before we can use isar we need to initialize the database. In the global_providers.dart file, let’s create a new provider for our database.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import 'package:isar/isar.dart';
import 'package:isar_reactive_database/cake/model/cake.dart';
import 'package:path_provider/path_provider.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'global_providers.g.dart';

@riverpod
Isar isar(IsarRef ref) => throw UnimplementedError();

Future<List<Override>> initProviders() async {
 final overrides = <Override>[];

 final directory = await getApplicationDocumentsDirectory();
 final isar = await Isar.open([CakeSchema], directory: directory.path);

 overrides.add(isarProvider.overrideWithValue(isar));

 return overrides;
}

We’re using riverpod overrides to initialize the database before running the app. We put the database in the ApplicationsDocumentsDirectory that we retrieved with the help of the path_provider package.

Note, that we also need to reference the CakeShema here. We will shortly see where this comes from, when looking at the data model.

In case you’re wondering how the riverpod overrides work, hat a look at this blog post.

The Cake Model

The isar package required to annotate models that should be stored in the database with the @Collection() annotation. Using code generation with the build_runner package, this will create code to store the model in the database. That way also the CakeSchema is created, that we used when initializing the database above.

Although it is not required, I would still recommend using freezed with your models. This way, you’ll get handy functions as copyWith and hashCode.

The only thing that you need to do, to make freezed and isar work together, is to use ignore field on the annotation and create a getter for the model’s id.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:isar/isar.dart';

part 'cake.freezed.dart';

part 'cake.g.dart';

@freezed
@Collection(ignore: {'copyWith'})
class Cake
 with _$Cake {
 const Cake._();

 const factory Cake({
 required int id,
 required String name,
 required int yummyness,
 }) = _Cake;


 @override
 Id get id => id;

 factory Cake.fromJson(Map<String, dynamic> json) => _$CakeFromJson(json);
}

The `CakeRepository` with `isar`

As with the tutorial on sembast, the CakeRepository interface looks the same:

1
2
3
4
5
6
7
8
9


abstract interface class CakeRepository {
 Future<int> insertCake(Cake cake);

 Future updateCake(Cake cake);

 Future deleteCake(int cakeId);

 Stream<List<Cake>> getAllCakesStream();
}

Notice the getAllCakesStream() function. Using the returned Stream, we can make our UI update without manually querying the database.

Finally, let’s have a look at the isar-specific implementation of the repository:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import 'package:isar/isar.dart';
import 'package:isar_reactive_database/cake/model/cake.dart';
import 'package:isar_reactive_database/cake/repository/cake_repository.dart';

class IsarCakeRepository implements CakeRepository {
 final Isar isar;

 const IsarCakeRepository(this.isar);

 @override
 Future deleteCake(int cakeId) =>
 isar.writeTxn(() {
 return isar.cakes.delete(cakeId);
 });

 @override
 Stream<List<Cake>> getAllCakesStream() {
 return isar.cakes.where().watch(fireImmediately: true);
 }

 @override
 Future<int> insertCake(Cake cake) =>
 isar.writeTxn(() {
 return isar.cakes.put(cake);
 });

 @override
 Future updateCake(Cake cake) =>
 isar.writeTxn(() {
 return isar.cakes.put(cake);
 });
}

Actually, the implementation is dead simple. In comparison to other databases, isar takes care of serialization and deserialization for us. This way, there’s almost no code left for us to write.

For all writing operations on the isar database, the package requires us to wrap the code in writeTxn functions. This means that we’re creating transactions for our operations.

Transactions are a way to group database operations. If one of the operations fails, all operations in the same transactions are reversed as well. Or in other words: the operations are only persisted if all the operations are successful.

To create a query, we can use the where() function on an isar collection. If we don’t specify any parameters, all objects are returned.

Using the watch function, we can listen to any changes of this query. With fireImmediately: true we tell the stream, to immediately emmit the latest data when a listener connects. Otherwise, the stream would only return data once the data changes the first time.

Summary

With isar it is very straightforward to create a local database. The watch function on queries is very helpful to listen for database changes. In comparison to sembast, isar uses code generation, to handle serialization and deserialization for us.

The isar database also comes with a lot of other features, like indexes, links and a query builder. To learn more about these features, be sure to check out their documentation.

Riverpod: How to initialize a SYNC Provider with an ASYNC Value?

Sat, 05 Oct 2024 00:00:00 +0000

Sometimes it is quite tricky to work with riverpod providers. Especially, when you want to initialize a provider with an async value.

Showing the version of your app

Here, I show you how you can structure your app to resolve this issue. In this example, we are going to display the version of the app using the package_info_plus package.

If you check the package’s documentation, you can see that reading this information returns a Future. So how can we initialize a Provider without making it a AsyncProvider?

PackageInfo packageInfo = await PackageInfo.fromPlatform();

Example

The trick is to decouple awaiting the Future and initializing the Provider. We can use the loading time before the app actually starts to fetch the necessary information. The user will probably see the splash screen for a couple of milliseconds longer, but later, we can synchronously access the data.

We can then use riverpod Overrides to set the loaded data to a provider. Let’s have a look how this can look like:

You can find the source code of this example on GitHub: https://github.com/bettercoding-dev/riverpod-sync-provider-async-value

`main.dart`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_async_init/global_providers.dart';
import 'package:riverpod_async_init/version_page.dart';

void main() async {
 WidgetsFlutterBinding.ensureInitialized();
 final overrides = await initGlobalProviders();

 runApp(
 ProviderScope(
 overrides: overrides,
 child: const MainApp(),
 ),
 );
}

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

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

Here, you can see that we call initGlobalProviders right before we actually run the app. The main function can be async, this means we can resolve our futures here.

Apps show a splash screen when staring. So all waiting done here will be done while the splash screen is shown.

We can then hand the overrides to the ProviderScope. This is a riverpod specific widget that contains all the providers states.

`global_providers.dart`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


import 'package:package_info_plus/package_info_plus.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'global_providers.g.dart';

@riverpod
PackageInfo packageInfo(PackageInfoRef ref) => throw UnimplementedError();

Future<List<Override>> initGlobalProviders() async {
 final overrides = <Override>[];

 // init package info
 final packageInfo = await PackageInfo.fromPlatform();
 overrides.add(packageInfoProvider.overrideWithValue(packageInfo));

 return overrides;
}

We use the global_providers.dart file to define our PackageInfo provider. But instead of directly assigning a value to the provider, we’ll throw an error.

The initialization is done in the initGlobalProviders function, which is then called in main.dart as we saw earlier.

We use the overrideWithValue function of the provider to instead of throwing an error provide the given value.

`version_page.dart`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_async_init/global_providers.dart';

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

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 final packageInfo = ref.watch(packageInfoProvider);

 return Scaffold(
 appBar: AppBar(
 title: const Text('Version Info'),
 ),
 body: ListView(
 children: [
 ListTile(
 title: const Text('App Name'),
 subtitle: Text(packageInfo.appName),
 ),
 ListTile(
 title: const Text('Package Name'),
 subtitle: Text(packageInfo.packageName),
 ),
 ListTile(
 title: const Text('Version'),
 subtitle: Text(packageInfo.version),
 ),
 ],
 ),
 );
 }
}

Finally, in the UI we can simply read the provider and then access the values without having to await anything.

Summary

In this example I showed you how to structure your app to resolve Futures before starting the app and using Overrides update a providers value at a later time.

JWT Authentication in Flutter – Tutorial & Follow-Along

Thu, 03 Oct 2024 00:00:00 +0000

You can find the source code for this tutorial on GitHub: https://github.com/bettercoding-dev/flutter-jwt-auth.

If you want to code some parts of the app yourself, checkout the follow-along branch. There, I removed some code, so you can implement it yourself. This will help you to understand better and improve your coding skills.

What is JWT authentication?

Before we start, let us have a quick look at what JWT even means. JWT stands for JSON Web Tokens. It is basically a JSON object encoded into a base64 string and signed with a secret key.

The token is issued and signed by a server and sent to a client after a successful login. Now the client can include this token in all its requests to the server. The server can then take a look at the token and verify that it has not expired and that the signature matches.

You can think of it as a ticket for an amusement park or public transport. You show it to someone, and they will verify that the ticket has not expired and that the ticket is not fake. If everything is fine, you can use the service.

JWT refresh tokens

To prevent users from being signed out every time the token expires, it is common for the server to issue two types of tokens: a token used for authenticate the calls, and a refresh token, that can be used to ask the server for a new token.

You can learn more about JWT on https://jwt.io.

You can think of the refresh token as a second way to login. Instead of sending your credentials to the server, the refresh token is used. But in contrast to a normal login, the token refresh takes place in the background and the user will not notice it.

In this tutorial, we will set up our Flutter app to use tokens for authentication, and request new tokens using refresh tokens.

Prerequisites

The app that we are creating in this tutorial will be relatively simple. It will allow the user to log in and log out and to display the current server time in the app. The request for fetching the server time is authenticated and is only allowed for logged-in users.

Before we start, download the project from: https://github.com/bettercoding-dev/flutter-jwt-auth.

Let’s have a look at our project structure. It uses the same architecture as explained in this tutorial.

If you have checked out the code from the repo, you can see the following folders and files in the lib folder.

main.dart: the entry point of the app
global_providers.dart: globally needed riverpod providers are created here, especially the initialization of Dio will be of interest here
time: includes all files needed for fetching the time and displaying it in the app
common: non-feature-specific files
auth: authentication-specific files.
- client: implementation of authentication REST calls login and refresh.
- interceptor: contains AuthInterceptor that we will use to authenticate our calls and implement refresh handling
- model: contains a simple model AuthData containing both tokens
- repository: abstraction layer that handles authentication-specific operations
- state: contains AuthController, which handles authentication-specific state.

We will focus on implementing the AuthInterceptor and the AuthController.

The test server

To actually test our implementation, the source code also contains a small server that issues tokens and includes an authenticated API-Endpoint.

You can start it with the following command:

dart server/shelf-jwt-test-server/bin/server.dart

This will run the server on localhost at port 8080.

If you are using the iOS Simulator, that you are good to go. For the Android Emulator, you will need to change the baseUrl of the API to 10.0.2.2. If you are using a real device, you will need to replace the IP with the address of your computer.

You can change the baseUrl in global_providers.dart.

I built the server using the shelf package. You can also check out a standalone version of the server on Github: https://github.com/bettercoding-dev/shelf-jwt-test-server.

Implementing `AuthController`

First, let us implement the AuthController. It’s responsible for holding and manipulating authentication-specific state.

In this example, it is implemented as a riverpod Notifier. This means we need to implement the build method first.

Use dart run build_runner watch --delete-conflicting-outputs to regenerate code.

`build`

The build method is responsible to initialize the state. For us, this means to check our storage if there are any stored tokens available and update the state accordingly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@override
Future<AuthData?> build() async {
 final storageRepository = ref.watch(storageRepositoryProvider);

 final token = await storageRepository.getToken();
 final refreshToken = await storageRepository.getRefreshToken();

 if (token != null && refreshToken != null) {
 return AuthData(token: token, refreshToken: refreshToken);
 } else {
 return null;
 }
}

The StorageRepository uses the flutter_secure_storage package to safely store the tokens on the device.

`login`

Next, let us implement the login. In this simplified example, we only take a username to log in. Our test server does not care about a password.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Future<void> login(String username) async {
 final authRepository = ref.read(authRepositoryProvider);
 final storageRepository = ref.read(storageRepositoryProvider);

 state = await AsyncValue.guard(() async {
 final authData = await authRepository.login(username);
 await storageRepository.storeToken(authData.token);
 await storageRepository.storeRefreshToken(authData.refreshToken);
 return authData;
 });
}

We are initiating a login call using the AuthRepository. If everything works as expected, AuthData will be returned. We store the received data in using the StorageRepository and set our state.

The AsyncValue.guard function is a cool helper from riverpod. If everything works as expected, a AsyncData object ist returned. If an error is thrown inside the guarded function, an AsyncError is returned.

`refreshToken`

The refreshToken function is very similar to the login. But instead of using the username to authenticate, we check if a refreshToken is available and use that one instead. In case of success, we update the state with the new tokens.

If the token refresh fails (most likely because the refresh token expired as well), we are going to log out the user.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Future<void> refreshToken() async {
 final authRepository = ref.read(authRepositoryProvider);
 final storageRepository = ref.read(storageRepositoryProvider);
 final authData = state.valueOrNull;
 if (authData != null) {
 try {
 final newTokens =
 await authRepository.refreshToken(authData.refreshToken);
 storageRepository.storeToken(newTokens.token);
 storageRepository.storeRefreshToken(newTokens.refreshToken);
 state = AsyncData(newTokens);
 } on DioException {
 await logout();
 rethrow;
 }
 }
}

`logout`

Logging out using JWT is pretty straightforward. All we need to do is to remove our tokens from the storage and clear the state;

1
2
3
4
5
6
7
8


Future<void> logout() async {
 state = await AsyncValue.guard(() async {
 final storageRepository = ref.read(storageRepositoryProvider);
 await storageRepository.deleteToken();
 await storageRepository.deleteRefreshToken();
 return null;
 });
}

Implementing `AuthInterceptor`

Interceptors are a way to add functionality to Dio when sending requests, receiving responses or handling errors. The functions of an interceptor are called every time one of these three events occurs, and allow to make modifications to the HTTP calls.

Adding Interceptors

The interceptors can be added when creating a new instance of Dio. In our case, this is done in the global_providers.dart file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@riverpod
Dio dio(DioRef ref) {
 final dio = Dio(
 BaseOptions(
 baseUrl: 'http://localhost:8080',
 contentType: Headers.jsonContentType,
 ),
 );

 dio.interceptors.add(PrettyDioLogger());
 dio.interceptors.add(AuthInterceptor(ref, dio));

 return dio;
}

We add two interceptors here. The PrettyDioLogger will print all requests and responses to the console. This helps debug in case of errors.

Secondly, we add our AuthInterceptor to the interceptors list.

Adding the `Authorization` header

When you open the auth_interceptor.dart file, you can see that there are two functions we would like to override.

For adding JWT to outgoing requests, the onRequest function is the one we want to implement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@override
void onRequest(RequestOptions options, RequestInterceptorHandler handler) async {
 final authData = await ref.read(authControllerProvider.future);
 final token = authData?.token;
 if (token != null) {
 options.headers['Authorization'] = 'Bearer $token';
 }

 super.onRequest(options, handler);
}

It’s actually not too complicated. We first check the state of the AuthController, if a token is available. If not, we cannot do anything and just leave the request as it is.

In case we have an available token, we add it as an Authorization header, as you can see in line 6. Remember to add Bearer in front of your token.

Now you can start the app and click the login button. You should se the token and the refresh token values, as well as the current server time displayed on the screen.

If you click on “Refresh” a new request will be sent to the server asking for an updated time. This will work as long as your token is valid (15 seconds in this case). After that, you have to log in again to get a new token.

Implement Token Refresh

Since it would be annoying to log in again every time the token expires, let us use the refresh token to update our tokens.

We are going to do that by implementing the onError function of the interceptor.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


@override
void onError(DioException err, ErrorInterceptorHandler handler) async {
 final isRetry = err.requestOptions.extra['isRetry'] == true;

 // if response is unauthorized
 if (err.response?.statusCode == 401 && !isRetry) {
 try {
 final authData = await ref.read(authControllerProvider.future);
 final refreshToken = authData?.refreshToken;

 if (refreshToken != null) {
 await ref.read(authControllerProvider.notifier).refreshToken();

 final options = err.requestOptions;
 options.extra['isRetry'] = true;
 final response = await dio.fetch(options);

 handler.resolve(response);
 } else {
 super.onError(err, handler);
 }
 } on DioException catch (error, trace) {
 log('cannot refresh', error: error, stackTrace: trace);
 super.onError(error, handler);
 }
 } else {
 super.onError(err, handler);
 }
}

Line 3: Here we are checking for an extra called isRetry. This is a flag that we set below in line 15 to mark a request when we retry to get data from the server after updating the tokens. That way, we avoid endless loops when retrying failed requests over and over again.
Line 6: We check if the request failed because it was unauthorized, and if we haven’t retried this request already.
Lines 8–11: We get hold of our refresh token. If we do not have a refresh token, we cannot refresh and simply let the call fail (line 20).
Line 12: We call the AuthController to refresh the tokens. If that throws a DioException we fail the call as well (line 24).
Lines 14–18: After refreshing the tokens, we give the request another go. After setting the isRetry extra, we use dio.fetch to execute the request once again. If it successfully returns a response, we use the response to resolve the error.

Try the token refresh

Now, when we start our app and log in, you can now keep pressing “Refresh” although the token has expired. If you check the logs, you can see that in the background, the app has been refreshing the tokens.

Notice that the refresh token can expire. If this is the case, you get logged out.

Summary

In this tutorial, we have learned how to set up a Dio interceptor to use JSON Web Tokens to authenticate against an API.

We used a refresh token to prevent the user from being logged out continuously, but instead refresh the authentication token instead.

The tokens are stored in an encrypted storage, and we use riverpod Notifier to keep track of the authentication state.

A Simple Flutter Architecture for accessing REST APIs

Wed, 25 Sep 2024 00:00:00 +0000

REST APIs are a common way to implement communication between an app and a server. In this tutorial, I show you how I structure my Flutter apps in a simple, yet scalable way to retrieve and send data from/to a server and display it in the app.

The source code for this tutorial can be found on GitHub: https://github.com/bettercoding-dev/flutter-rest-api-architecture.

Architecture

We will use MVVM (Model-View-ViewModel) as the foundation of our app.

The model describes the data that we are using and should be displayed in our app. In our example it will be users that have a name, email address and a avatar.

The view refers to the UI that displays the data. In Flutter these are our widgets.

The view model contains the logic of our app. For this tutorial, this will be a riverpod Notifier that holds and handles state changes.

Additionally, we will implement a repository layer (or data layer) that is responsible for fetching data for a source. We are going to add abstraction here to easily switch between different sources.

Required Packages

For this tutorial, I will add the following packages to my app:

riverpod: a powerful state management and dependency injection solution
freezed: generates utility functions for data classes
retrofit: generates REST API client functions
json_serializable: generates fromJson and toJson functions
dio: a Dart http client

You can use this command to install all the dependencies:

flutter pub add flutter_riverpod riverpod_annotation freezed_annotation json_annotation retrofit dio dev:riverpod_generator dev:build_runner dev:custom_lint dev:riverpod_lint dev:freezed dev:json_serializable dev:retrofit_generator

Afterward, your dependencies should look something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


dependencies:
 flutter:
 sdk: flutter
 flutter_riverpod: ^2.5.1
 freezed_annotation: ^2.4.4
 json_annotation: ^4.9.0
 retrofit: ^4.4.1
 riverpod_annotation: ^2.3.5

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^4.0.0
 riverpod_generator: ^2.4.3
 build_runner: ^2.4.12
 custom_lint: ^0.6.7
 riverpod_lint: ^2.3.13
 freezed: ^2.5.7
 json_serializable: ^6.8.0
 retrofit_generator: ^9.1.2

The `User` Model

Let’s start with modeling our model. We are going to use the free Reqres API to fetch a list of users. A user is specified like this:

1
2
3
4
5
6
7


{
 "id": 2,
 "email": "janet.weaver@reqres.in",
 "first_name": "Janet",
 "last_name": "Weaver",
 "avatar": "https://reqres.in/img/faces/2-image.jpg"
}

We use this information to derive a User class that contains this data. Using freezed and json_serializable we generate useful functions such as copyWith and toJson;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import 'package:flutter/foundation.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'user.freezed.dart';

part 'user.g.dart';

@freezed
class User with _$User {
 const factory User({
 required int id,
 required String email,
 @JsonKey(name: 'first_name') required String firstName,
 @JsonKey(name: 'last_name') required String lastName,
 required String avatar,
 }) = _User;

 factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
}

Let’s start the build_runner to generate the required files.

dart run build_runner watch --delete-conflicting-outputs

The Repository Layer

Next, we define our repository layer. Here we will create an abstraction for being able to switch between different data sources as needed.

In this example, we will create an interface UserRepository defining the functions of the repository and create two concrete implementations:

MockUserRepository is going to be a mock implementation. This can be used to quickly test your implementation, or start working even though the API might not be yet ready to be used.
ApiUserRepository is going to be the actual implementation using the API Client generated with retrofit.

The `UserRepository` interface

We use the interface class to define which functions the implementations should have. To keep this tutorial short, we will focus on a single function:

1
2
3
4
5


import 'package:src/user/model/user.dart';

abstract interface class UserRepository {
 Future<List<User>> getAllUsers();
}

The `MockUserRepository`

Before actually implementing API calls, let’s create a mock repository first. This way we can start working on the rest of the app before actually needing access to the API. In many projects, APIs might not be available in the early stages of the project, this way you can still start working.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


import 'package:src/user/model/user.dart';
import 'package:src/user/repository/user_repository.dart';

class MockUserRepository implements UserRepository {
 static const _mockUsers = [
 User(
 id: 1,
 email: 'Tim@testmail.com',
 firstName: 'Tim',
 lastName: 'Tester',
 avatar: 'https://reqres.in/img/faces/1-image.jpg',
 ),
 User(
 id: 2,
 email: 'toby@testmail.com',
 firstName: 'Toby',
 lastName: 'Tester',
 avatar: 'https://reqres.in/img/faces/2-image.jpg',
 ),
 ];

 @override
 Future<List<User>> getAllUsers() async {
 // add delay to mimic an api call
 await Future.delayed(const Duration(milliseconds: 300));
 return _mockUsers;
 }
}

Back in the file of the UserRepository, create a riverpod provider returning the MockUserRepository.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:src/user/model/user.dart';
import 'package:src/user/repository/mock_user_repository.dart';

part 'user_repository.g.dart';

@riverpod
UserRepository userRepository(ref) => MockUserRepository();

abstract interface class UserRepository {
 Future<List<User>> getAllUsers();
}

At this point, we can define which implementation of UserRepository is made available for this provider.

The `UserController`

Now, we implement the ViewModel layer of the app. We are going to create a UserController class which is a riverpod Notifier.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:src/user/model/user.dart';
import 'package:src/user/repository/user_repository.dart';

part 'user_controller.g.dart';

@riverpod
class UserController extends _$UserController {
 @override
 Future<List<User>> build() async {
 final userRepository = ref.watch(userRepositoryProvider);
 return userRepository.getAllUsers();
 }
}

As you can see, the implementation is quite simple. In line 11 we use the riverpod ref.watch function to retrieve our user repository instance. Since we defined it to be a MockUserRepository we will be getting mock users from the repository.

Notice that the controller itself has no knowledge which implementation is used. We can later swap the mock implementation with an api implementation without needing to touch the controller again.

The UI

Let’s create new page for our application and name it UserListPage.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:src/user/state/user_controller.dart';

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

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 final state = ref.watch(userControllerProvider);

 return Scaffold(
 appBar: AppBar(
 title: const Text('Users list'),
 ),
 body: state.when(
 loading: () =>
 const Center(
 child: CircularProgressIndicator(),
 ),
 error: (error, trace) =>
 Center(
 child: Text('Error: $error'),
 ),
 data: (users) =>
 ListView.builder(
 itemCount: users.length,
 itemBuilder: (context, index) {
 final user = users[index];
 return ListTile(
 leading: CircleAvatar(
 backgroundImage: NetworkImage(user.avatar),
 ),
 title: Text('${user.firstName} ${user.lastName}'),
 );
 },
 ),
 ),
 );
 }
}

Extending the ConsumerWidget class gives us access to riverpod’s WidgetRef that we use to watch the UserController state.

We handle loading and error state and render the list of users and some of their attributes.s

To make riverpod work, we need to wrap our App widget with a ProviderScope. Finally, we set the UserListPage as the home attribute of the MaterialApp widget.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:src/user/ui/user_list_page.dart';

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

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

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

Now, we can start the app and examine our list of users.

API connection using `retrofit`

Now that we’re able to display the list of users in our app, let’s add the API connection.

The API response

A full sample response of our api looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


{
 "page": 1,
 "per_page": 6,
 "total": 12,
 "total_pages": 2,
 "data": [
 {
 "id": 1,
 "email": "george.bluth@reqres.in",
 "first_name": "George",
 "last_name": "Bluth",
 "avatar": "https://reqres.in/img/faces/1-image.jpg"
 },
 {
 "id": 2,
 "email": "janet.weaver@reqres.in",
 "first_name": "Janet",
 "last_name": "Weaver",
 "avatar": "https://reqres.in/img/faces/2-image.jpg"
 },
 {
 "id": 3,
 "email": "emma.wong@reqres.in",
 "first_name": "Emma",
 "last_name": "Wong",
 "avatar": "https://reqres.in/img/faces/3-image.jpg"
 },
 {
 "id": 4,
 "email": "eve.holt@reqres.in",
 "first_name": "Eve",
 "last_name": "Holt",
 "avatar": "https://reqres.in/img/faces/4-image.jpg"
 },
 {
 "id": 5,
 "email": "charles.morris@reqres.in",
 "first_name": "Charles",
 "last_name": "Morris",
 "avatar": "https://reqres.in/img/faces/5-image.jpg"
 },
 {
 "id": 6,
 "email": "tracey.ramos@reqres.in",
 "first_name": "Tracey",
 "last_name": "Ramos",
 "avatar": "https://reqres.in/img/faces/6-image.jpg"
 }
 ],
 "support": {
 "url": "https://reqres.in/#support-heading",
 "text": "To keep ReqRes free, contributions towards server costs are appreciated!"
 }
}

We can see that the data attribute contains a list of User objects that we created earlier. To correctly parse the response, we create another model called UserListResponse. To simplify the model, we ignore all attributes that we don’t use in the app.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


import 'package:flutter/foundation.dart';
import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:src/user/model/user.dart';

part 'user_list_response.freezed.dart';

part 'user_list_response.g.dart';

@freezed
class UserListResponse with _$UserListResponse {
 const factory UserListResponse({
 required List<User> data,
 }) = _UserListResponse;

 factory UserListResponse.fromJson(Map<String, dynamic> json) =>
 _$UserListResponseFromJson(json);
}

The `UserApiClient`

For the base configuration of our API we’re required to create an instance of the Dio class. Let’s create a provider for that.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import 'package:dio/dio.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'global_providers.g.dart';

@riverpod
Dio dio(DioRef ref) =>
 Dio()
 ..options = BaseOptions(
 baseUrl: 'https://reqres.in/api',
 );

Now that we have our response model, we create a class called UserApiClient which uses the retrofit package to generate our API calls.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


import 'package:dio/dio.dart';
import 'package:retrofit/retrofit.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:src/global_providers.dart';
import 'package:src/user/client/user_list_response.dart';

part 'user_api_client.g.dart';

@riverpod
UserApiClient userApiClient(UserApiClientRef ref) =>
 UserApiClient(
 ref.watch(dioProvider),
 );

@RestApi()
abstract class UserApiClient {
 factory UserApiClient(Dio dio) = _UserApiClient;

 @GET('/users')
 Future<UserListResponse> getUserList();
}

Notice, that we also created a riverpod provider for accessing an instance of UserApiClient.

The `UserApiRepository`

Finally, we create a ApiUserRepository that uses the UserApiClient to fetch some data from the API.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


import 'dart:developer';

import 'package:src/user/client/user_api_client.dart';
import 'package:src/user/model/user.dart';
import 'package:src/user/repository/user_repository.dart';

class ApiUserRepository implements UserRepository {
 final UserApiClient client;

 const ApiUserRepository(this.client);

 @override
 Future<List<User>> getAllUsers() async {
 try {
 final response = await client.getUserList();
 return response.data;
 } catch (error, trace) {
 log('could not fetch users', error: error, stackTrace: trace);
 rethrow;
 }
 }
}

As a last step, we need to replace the MockUserRepository with the newly created ApiUserRepository in the provider.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:src/user/client/user_api_client.dart';
import 'package:src/user/model/user.dart';
import 'package:src/user/repository/api_user_repository.dart';

part 'user_repository.g.dart';

@riverpod
UserRepository userRepository(ref) =>
 ApiUserRepository(
 ref.watch(userApiClientProvider),
 );

abstract interface class UserRepository {
 Future<List<User>> getAllUsers();
}

As we refresh our app, we can now see that mock users have been replaced by actual users from the API.

Take away

In this tutorial, you’ve learned how to structure your app to fetch data from an API and display it in your app.

We used abstraction in the repository layer to be able to replace a mock implementation with the API implementation later in the development process.

I’ve used this basic structure in many different projects from a couple of hundreds to tens of thousands of lines of code.

Consistent Spacing – Improve your Flutter App with this Package

Tue, 24 Sep 2024 00:00:00 +0000

Consistency is a key factor in a good, usable application. Having inconsistent spacing in your app, is unpleasant for the user’s eyes. They might not be able to put the finger on it, but they will feel that there’s something not right.

And it’s not even difficult to be consistent. This tutorial shows you how to define consistent spacings in your Flutter app and how to use spacing_generator to generate simple-to-access SizedBox and EdgeInsets instances.

The source code for this tutorial can be found on GitHub: https://github.com/bettercoding-dev/spacing-generator.

How not to do spacings

Let’s look at this bad example. In this code we hard-code the spaces in the UI, which over time leads to inconsistencies. Especially, when working on larger projects, with multiple developers, it’s difficult to maintain consistent spacings this way.

Sooner or later one will forget that you agreed on using 16 pixels as your preferred spacing for cards and uses 20 pixels instead.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


import 'package:flutter/material.dart';

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

 @override
 Widget build(BuildContext context) {
 return SizedBox(
 height: 200,
 child: Card(
 margin: const EdgeInsets.all(20),
 child: Padding(
 padding: const EdgeInsets.all(16),
 child: Row(
 crossAxisAlignment: CrossAxisAlignment.stretch,
 mainAxisSize: MainAxisSize.max,
 children: [
 Image.network(
 'https://picsum.photos/id/429/100',
 fit: BoxFit.cover,
 ),
 const SizedBox(width: 10),
 Expanded(
 child: Column(
 crossAxisAlignment: CrossAxisAlignment.stretch,
 children: [
 Text(
 'My favorite restaurant',
 style: Theme
 .of(context)
 .textTheme
 .titleMedium,
 ),
 const SizedBox(height: 4),
 Text(
 'Come here and try',
 style: Theme
 .of(context)
 .textTheme
 .bodyMedium,
 ),
 const Spacer(),
 Row(
 mainAxisAlignment: MainAxisAlignment.end,
 children: [
 TextButton(
 onPressed: () {},
 child: const Text('Details'),
 ),
 const SizedBox(width: 6),
 ElevatedButton(
 onPressed: () {},
 child: const Text('Visit'),
 ),
 ],
 )
 ],
 ),
 )
 ],
 ),
 ),
 ),
 );
 }
}

Also, what happens if your design team suddenly decides to now use 8 instead of 10 pixel spacings? Let’s find a better solution for this.

Set up

To use the spacing_generator package, we need to add it to our app.

If you have the Flutter Version Manager installed use this command (recommended). This ensures you’re using the same version as this tutorial.

fvm flutter pub add spacing_generator_annotation dev:spacing_generator dev:build_runner

Otherwise, simply call:

flutter pub add spacing_generator_annotation dev:spacing_generator dev:build_runner

Afterward, your dependencies should look like this:

dependencies:
 flutter:
 sdk: flutter
 spacing_generator_annotation: ^0.3.0

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^4.0.0
 spacing_generator: ^0.4.0+5
 build_runner: ^2.4.12

Define the spaces

Next, let’s create a file spaces.dart, where we will define a set of spaces that we want to use throughout the app.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

part 'spaces.g.dart';

@Spacing()
class SpaceDefinitions {
 static const small = 4.0;
 static const standard = 8.0;
 static const large = 16.0;
}

Notice the @Spacing() annotation. It tells the spacing_generator package to take the values defined in this class and generate EdgeInset and SizedBox instances for them.

Now, let’s start the build_runner to generate the code. Again you can skip the fvm command.

fvm dart run build_runner build

Apply the generated spacings

Finally, let us apply the generated spacings to the example widget we saw before.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


import 'package:flutter/material.dart';
import 'package:spacing_generator_tutorial/spaces.dart';

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

 @override
 Widget build(BuildContext context) {
 return SizedBox(
 height: 200,
 child: Card(
 margin: context.paddings.allLarge,
 child: Padding(
 padding: context.paddings.allLarge,
 child: Row(
 crossAxisAlignment: CrossAxisAlignment.stretch,
 mainAxisSize: MainAxisSize.max,
 children: [
 Image.network(
 'https://picsum.photos/id/429/100',
 fit: BoxFit.cover,
 ),
 context.spaces.horizontalStandard,
 Expanded(
 child: Column(
 crossAxisAlignment: CrossAxisAlignment.stretch,
 children: [
 Text(
 'Good Card',
 style: Theme
 .of(context)
 .textTheme
 .titleMedium,
 ),
 context.spaces.verticalSmall,
 Text(
 'We use consistent spacings here.',
 style: Theme
 .of(context)
 .textTheme
 .bodyMedium,
 ),
 const Spacer(),
 Row(
 mainAxisAlignment: MainAxisAlignment.end,
 children: [
 TextButton(
 onPressed: () {},
 child: const Text('Details'),
 ),
 context.spaces.horizontalSmall,
 ElevatedButton(
 onPressed: () {},
 child: const Text('Visit'),
 ),
 ],
 )
 ],
 ),
 )
 ],
 ),
 ),
 ),
 );
 }
}

Now, instead of using hard-coded values, we reference our generated spaces. This way, we don’t need to worry about the actual pixel value, but rather only need to remember the name.

If you plan to change the spacings in the future, simple update the values in SpaceDefinitions, regenerate the code and all spacings in your app update automatically as well.

Take away

Although being consistent is one of the key-principals of UX, it’s often ignored during development. This is unfortunate, since using consistent spacings isn’t difficult at all. With packages like spacing_generator it is really simple to define a set of consistent spacings and reuse them throughout your app. It might look like a small think, but it instantly improves the perceived quality of your app.

10 Flutter Packages You Must Know In 2022

Sat, 19 Mar 2022 00:00:00 +0000

One thing I love about Flutter and the Dart environment is the immense number of packages that are available. Most of them really make a developer’s life easier. This is why I want to share with you 10 packages that I think you need to know.

My 10 Favorite Packages

1. Beamer

Beamer is a package that build on the Flutter Navigator 2.0 API. It allows for defining your app’s routing in a declarative way (opposed to Navigator 1.0 that uses an imperative approach). It is simple to use, comes with many examples and includes features like guards, nested routing and also allows a lot of customization.

2. Flutter Flavorizr

If you have ever tried to set up a multi-environment (development, staging, production) application in Flutter, you probably know that it can get tricky having multiple iOS schemas, Android flavors, icons, Firebase configurations and more that you need to handle.

The flutter_flavorizr package comes to the rescue here. It allows you to specify your app structure in the pubspec.yaml file and lets you generate an app stub. This comes really handy and safes you a lot of time!

3. Flutter Launcher Icons

A similar package is flutter_launcher_icons. It allows you to generate all the launcher icons you need from a single source. Packages like these make your life so much easier :)

4. Shimmer

You want to get rid of the boring old CircularProgessIndicator? Use the shimmer package to create some cool placeholders while your app is loading data. The package is highly customizable yet really easy to use.

5. Riverpod

State management is a topic with many opinions and strong feelings involved. There are many good solutions out there, but for me, riverpod ( respectively flutter_riverpod) is the preferred solution. For me, it’s both simple enough, yet very powerful which makes the perfect combination for my needs.

Unsurprisingly, this is also why I have written several blog posts on how I use Riverpod like: Tutorial: Simple Riverpod App Architecture in Flutter, Tutorial: Using Sembast with Riverpod, or Tutorial: Simple Themes in Flutter using Riverpod.

Have you noticed that Riverpod is an acronym of Provider? If you reorder the letters of Provider you’ll get Riverpod. :)

6. Charts Flutter

If you have a lot of data that you want to display in your app, charts are a good idea. Nevertheless, creating charts yourself can be a tedious task. Luckily, charts_flutter gives you the tools you need to display your data in a well readable fashion.

I have used this library to create statistics of expenses tracked in my travel expense tracker app, Trexpense.

7. In App Review

Once your app hits the stores, a good rating helps your app to be found by new users. You can increase the number of reviews by elegantly asking your users to give you a rating from directly within the app. The in_app_review package allows you to show this dialog with next to no configuration effort needed.

8. Freezed

By no means a secret, and an essential package I’m using in almost all of my apps is freezed. This package generates many convenient functions for your data ( model) classes and allows you to create sealed (or union) classes. Together with the next two packages in the list, it forms a dream team for apps connecting to a REST API.

9. JSON Serializable

In combination with freezed, json_serializable makes it more than easy to convert a Dart class to and from JSON. In its basic form, it does not require any configuration, but it allows you exactly define how the serialization processes should work if you need to adapt.

10. Retrofit

Like the Android library of the same name, retrofit makes it effortless to generate everything that is necessary for sending and receiving data from a REST API. It works perfectly with freezed and json_serializable and this is why I use this “trinity” in many of my apps.

Conclusion

There are many great packages out there, almost every one of them helps you to save a lot of time in your development process. These packages are far from all the packages I use, and it was hard to decide on my favorite 10 packages.

I’m curious which packages you like the most! Leave me a comment below and tell me which packages I have missed in my listing.

Using Sembast with Riverpod

Mon, 03 Jan 2022 00:00:00 +0000

This article is part of the Data Storage in Flutter series.

In my tutorial Sembast as local data storage in Flutter, I used BLoC for state management. This time, I will create the same example application using Riverpod.

Sembast is a NoSQL database that can be used as a local storage in your Flutter application. It is fast and easy to use for storing JSON data locally. As in the previous tutorial using BLoC, we will build an app to add, edit, delete and view a list of yummy cakes.

The source code to this tutorial is available on GitHub: https://github.com/bettercoding-dev/sembast-riverpod.

Prerequisite

As always, we start with a clean new project. (See 5 Things I do when starting a new Flutter project for more information).

Next, let’s add our dependencies to pubspec.yaml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


name: sembast_riverpod
description: Using Sembast with Riverpod
publish_to: 'none'
version: 1.0.0+1

environment:
 sdk: ">=2.15.1 <3.0.0"

dependencies:
 flutter:
 sdk: flutter
 sembast: ^3.1.1+1
 flutter_riverpod: ^1.0.3
 freezed_annotation: ^1.1.0
 json_annotation: ^4.4.0
 path_provider: ^2.0.8

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^1.0.0
 json_serializable: ^6.1.3
 freezed: ^1.1.1
 build_runner: ^2.1.7

flutter:
 uses-material-design: true

Of course, we will use sembast and flutter_riverpod for our project. For our Cake model class, we will use freezed to help us generate some convenience functions for us. For this, we also need to add freezed_annotations, json_annotations, json_serializable and build_runner to the dependencies (and dev_dependencies). Finally, we also need to add path_provider – this package will be used for locating the correct directory to store our Sembast database file.

flutter_lints is now default for each new Flutter project. This package helps to find bad coding practices and helps to improve your code.

Next, we create a file called global_providers.dart and add the following code:

1
2
3
4
5
6


import 'package:riverpod/riverpod.dart';
import 'package:sembast/sembast.dart';
import 'package:sembast/sembast_io.dart';

final databaseProvider =
 Provider<Database>((_) => throw Exception('Database not initialized'));

Here we defined a Provider for our Sembast Database. But for now, it is not implemented yet. This is because the initialization of the database will be async, but we want to avoid using a FutureProvider. We will use Riverpod’s overrides to bind the initialized database to this provider later.

We will do this in our main.dart file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:path_provider/path_provider.dart';
import 'package:sembast/sembast_io.dart';
import 'package:sembast_riverpod/global_providers.dart';
import 'package:path/path.dart';
import 'package:sembast_riverpod/pages/home_page.dart';

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

 final appPath = await getApplicationDocumentsDirectory();
 appPath.createSync(recursive: true);
 final dbPath = join(appPath.path, 'cakes.db');
 final database = await databaseFactoryIo.openDatabase(dbPath);

 runApp(
 ProviderScope(
 overrides: [
 databaseProvider.overrideWithValue(database),
 ],
 child: const CakeApp(),
 ),
 );
}

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

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

Line 10: This line ensures that packages that use native code (such as path_provider) have access to native code API’s. For more info, see this post on stackoverflow.
Lines 12-15: Here, we initialize our Sembast database. First, we use path_provider to get our app’s documents directory (line 12) and create it if it does not yet exist (line 13). In line 14 we create a path for our database file (called cakes.db) and finally open the Sembast database (line 15).
Lines 17-24: Here we run our app and initialize Riverpod’s ProviderScope. This is also where we override the databaseProvider and assign it our initialized database (line 20).
Lines 27-36: This is all we need for defining our CakeApp. It will open our HomePage that we will create later.

The Cake Model

Next, we create our Cake model class that holds all information about the cakes we want to display. For this, we create a new folder models and add a cake.dart file. We’ll be using freezed to generate some functions for us.

The _$Cake, _Cake and _$CakeFromJson objects will not be found by your IDE or editor when you first define your model. They are generated by freezed later when calling the dart run build_runner build --delete-conflicting-outputs command.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import 'package:freezed_annotation/freezed_annotation.dart';

part 'cake.g.dart';

part 'cake.freezed.dart';

@freezed
class Cake with _$Cake {
 const factory Cake({
 @Default(-1) int id,
 required String name,
 required int yummyness,
 }) = _Cake;

 factory Cake.fromJson(Map<String, dynamic> json) => _$CakeFromJson(json);
}

Lines 3-5: We use freezed and json_serializable to generate some handy functions for our Cake model (such as toString, copyWith, toJson, fromJson, …). The generated code is put to the files specified in line 3 and 5. We can link them to this file using the part keyword.
Line 7: Don’t forget the @freezed decorator!
Lines 8-16: Here we define our model class. We use two factory constructors. The first one (lines 9-13) is used to define the attributes of our model, the second one tells freezed to a fromJson constructor (line 15).

Check out the [freezed](https://pub.dev/packages/freezed) page on pub.dev or watch this video for more information.

Now that we specified everything call

dart run build_runner build --delete-conflicting-outputs

to generate code once or

dart run build_runner watch --delete-conflicting-outputs

to watch for file changes, to continuously generate code.

The Cake Repository

In this section, we will finally use Sembast to read, write and update data to our local database. As with the Sembast tutorial using BLoC, we create an abstract CakeRepository first, to allow abstraction. In a new repositories directory, add a file called cake_repository.dart with this content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import 'package:sembast_riverpod/models/cake.dart';

abstract class CakeRepository {
 Future<int> insertCake(Cake cake);

 Future updateCake(Cake cake);

 Future deleteCake(int cakeId);

 Stream<List<Cake>> getAllCakesStream();
}

In comparison to the other tutorial, we will now take advantage of the improved Sembast library, that now allows to receive changes to the database as a stream.

So, let’s implement the Repository in a new file called sembast_cake_repository.dart.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:sembast/sembast.dart';
import 'package:sembast_riverpod/global_providers.dart';
import 'package:sembast_riverpod/models/cake.dart';
import 'package:sembast_riverpod/repositories/cake_repository.dart';

final cakeRepositoryProvider = Provider(
 (ref) => SembastCakeRepository(
 database: ref.watch(databaseProvider),
 ),
);


class SembastCakeRepository implements CakeRepository {
 final Database database;
 late final StoreRef<int, Map<String, dynamic>> _store;

 SembastCakeRepository({required this.database}) {
 _store = intMapStoreFactory.store('cake_store');
 }

 @override
 Future<int> insertCake(Cake cake) => _store.add(database, cake.toJson());

 @override
 Future<void> updateCake(Cake cake) =>
 _store.record(cake.id).update(database, cake.toJson());

 @override
 Future deleteCake(int cakeId) => _store.record(cakeId).delete(database);

 @override
 Stream<List<Cake>> getAllCakesStream() =>
 _store.query().onSnapshots(database).map(
 (snapshot) => snapshot
 .map((cake) => Cake.fromJson(cake.value).copyWith(id: cake.key))
 .toList(growable: false),
 );
}

Lines 7-11: Here, we define our Riverpod provider to provide the SembastCakeRepository to other parts of our application and inject its dependencies.
Lines 14-20: We create a new class that implements the abstract CakeRepository. The SembastCakeRepository contains two properties: database and _store that inject and create in the constructor.
Lines 22-30: Inserting, updating and deleting with Sembast is really simple. Here we make use of the generated toJson functions.
Lines 32-38: With Sembast it is also possible to listen to changes in your database and receive the updated data as a Stream. We can do this, by creating a query on the _store (an empty query returns all objects). The onSnapshots functions is where Sembast returns us the stream of changes. We convert the snapshots into a list of Cakes.

The Cake Page

Finally, all that is left is the user interface. As described in my blog post Tutorial: Simple Riverpod App Architecture in Flutter, we will have three files:

home_page.dart: Here, we define how the UI looks like.
home_controller.dart: In this file, we will handle use input.
home_state.dart: This file will hold the state of the HomePage.

Add all these files into a new pages directory.

home_state.dart

1
2
3
4
5
6


import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:sembast_riverpod/repositories/sembast_cake_repository.dart';

final cakesProvider = StreamProvider(
 (ref) => ref.watch(cakeRepositoryProvider).getAllCakesStream(),
);

This simple file only holds one Provider: cakesProvider is a StreamProvider that uses the CakeRepository to get a stream of all available cakes.

home_controller.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


import 'dart:math';

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:sembast_riverpod/models/cake.dart';
import 'package:sembast_riverpod/repositories/cake_repository.dart';
import 'package:sembast_riverpod/repositories/sembast_cake_repository.dart';

final homeControllerProvider = Provider(
 (ref) => HomeController(
 cakeRepository: ref.watch(cakeRepositoryProvider),
 ),
);

class HomeController {
 static const flavors = ['apple', 'orange', 'chocolate'];
 final CakeRepository cakeRepository;

 HomeController({required this.cakeRepository});

 Future<void> delete(Cake cake) async {
 await cakeRepository.deleteCake(cake.id);
 }

 Future<void> edit(Cake cake) async {
 final updatedCake = cake.copyWith(yummyness: cake.yummyness + 1);
 await cakeRepository.updateCake(updatedCake);
 }

 Future<void> add() async {
 final flavorIndex = Random().nextInt(flavors.length - 1);
 final newCake = Cake(
 name: 'My yummy ${flavors[flavorIndex]} cake',
 yummyness: Random().nextInt(10),
 );
 await cakeRepository.insertCake(newCake);
 }
}

Lines 8-12: Here, we create a Provider that will make the HomeController available to the HomePage.
Lines 14-18: The HomeController class contains a list of flavors that will be used when creating a new Cake. It also holds a reference to the CakeRepository that will be used to handle the different user interactions.
Lines 20-36: We add functions to allow the handling of delete, edit, and add actions by the user. Delete will remove the cake from the database, edit will increase the yummyness factor by one, and add will randomly add a new flavored cake to the database. Since the stream will automatically update, there is no need to query the database manually.

home_page.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:sembast_riverpod/pages/home_controller.dart';
import 'package:sembast_riverpod/pages/home_state.dart';

class HomePage extends ConsumerWidget {
 const HomePage({Key? key}) : super(key: key);

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 final controller = ref.watch(homeControllerProvider);
 final cakes = ref.watch(cakesProvider);

 return Scaffold(
 appBar: AppBar(
 title: const Text('My Favorite Cakes'),
 ),
 body: cakes.when(
 loading: () => const Center(child: CircularProgressIndicator()),
 error: (error, trace) => Center(child: Text(error.toString())),
 data: (cakes) => ListView.builder(
 itemCount: cakes.length,
 itemBuilder: (context, index){
 final cake = cakes[index];
 return ListTile(
 title: Text(cake.name),
 subtitle: Text('Yummyness: ${cake.yummyness}'),
 leading: IconButton(
 icon: const Icon(Icons.thumb_up),
 onPressed: () => controller.edit(cake),
 ),
 trailing: IconButton(
 icon: const Icon(Icons.delete),
 onPressed: () => controller.delete(cake),
 ),
 );
 },
 )
 ),
 floatingActionButton: FloatingActionButton(
 child: const Icon(Icons.add),
 onPressed: () => controller.add(),
 ),
 );
 }
}

Line 6: Instead of StatelessWidget, we extend from ConsumerWidget to get access to WidgetRef in our build function.
Lines 11-12: Using the WidgetRef we can listen to the homeControllerProvider and cakesProvider.
Lines 18-21: The StreamProvider returns an AsyncValue. This class gives us access to a when function to handle different states of the stream. We can specify widgets for loading, error, and data (success) state.
Lines 21-38: We simply use a ListView to display the Cakes. Every ListTile has two buttons: one to increase yummyness and one to delete the Cake. We simply use the controller to handle the clicks.
Lines 40-43: Finally, to add new Cakes we create a FloatingActionButton that also uses the controller to delegate the action.

When we now run our application, this is what we should see. Our app should behave the same as in Tutorial: Sembast as local data storage in Flutter, but uses Riverpod for state management.

The source code to this tutorial is available on GitHub: https://github.com/bettercoding-dev/sembast-riverpod.

Summary

No matter which state management solution we use, Sembast is a solid database package for storing your local data in a NoSQL way. In this tutorial, I transformed the tutorial using BLoC into a Riverpod-driven application.

Which state management solution do you prefer? Do you also use Sembast for storing your data, or do you use packages like Hive or sqflite?

Simple Riverpod App Architecture in Flutter

Mon, 15 Nov 2021 00:00:00 +0000

Introduction

The riverpod package is a great Flutter package for state management. It comes with good documentation (that you can find here), but it can be a bit tricky to set up an app architecture using this package.

In this tutorial, we are going to write a very basic app, showing how a Flutter app can be structured when using Riverpod.

You can find the source code for this tutorial on

GitHub: https://github.com/bettercoding-dev/riverpod-architecture.

Data Flow

Let’s have a look at data flow within our app.

First, our app will have a state. A state can be a set of data that defines what to show to the user. In our example, this will be a list of entries that will be displayed in the app.

The user interface (UI) is updated according to the state. Every time the state changes, our UI is recreated with the new data.

When there are user interactions with the UI – such as button clicks – these events are forwarded to the controller. The controller is then responsible for performing actions accordingly and update the state.

The repository is responsible for managing the data. In our app, it will hold a list of entries, provide a way to fetch them and allow the add and remove these entries.

Prerequisites

Now, that we have a basic understanding, how the components of our app should look like, it’s time to start a new project.

I always perform a few steps when creating a new project, like cleaning up my pubspec.yaml and main.dart file. Take a look at my article 5 Things I do when starting a new Flutter project for more information.

Once the project is created, add [flutter_riverpod](https://pub.dev/packages/flutter_riverpod) to your dependencies. It is the only package we need for this tutorial, and our pubspec.yaml file should look like this afterward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


name: simple_riverpod_architecture
description: Simple Riverpod architecture

publish_to: 'none'

version: 1.0.0+1

environment:
 sdk: ">=2.12.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter
 flutter_riverpod: ^1.0.0

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^1.0.0

flutter:
 uses-material-design: true

Also, we need to wrap our app in a ProviderScope to make Riverpod work.

1
2
3


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

Entry Repository

First, we start by creating a repository. This repository will be absolutely minimalistic and is just thought to mimic a repository that we would use in a larger app, such as a repository reading from a database or accessing a REST API.

We create a new folder in our src directory and name it repositories. Inside this directory add a file called entry_repository.dart.

Add following class:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


class EntryRepository {
 final List<String> _entries = [];

 Future addEntry(String entry) async {
 await Future.delayed(const Duration(milliseconds: 100));
 _entries.add(entry);
 }

 Future removeEntry(String entry) async {
 await Future.delayed(const Duration(milliseconds: 100));
 _entries.remove(entry);
 }

 Future<List<String>> allEntries() async {
 await Future.delayed(const Duration(milliseconds: 200));
 return _entries;
 }
}

You might be wondering, why use async functions with Future.delayed()here. This is to simulate how a repository would behave when – for example – loading data from an API. These requests would be async as well, and it makes sense to have a look at how to handle asynchronous calls.

Riverpod for Dependency Injection (DI)

Now, that we have a repository, we will have a look at how to use Riverpod to provide the EntryRepository to other parts of the app.

One cool thing about Riverpod is that we can use its providers also to inject dependencies into other components. Let’s have look how this works.

class A {}
class MockA extends A {}
class B {
A a = A()
}

In this example, class B directly creates an instance of class A. This has the disadvantage that if we want to replace the way A is created, it is necessary to make changes to class B. One situation, where we probably want to replace A, is when testing our application. It is a common pattern to use mock instances instead of real instances.

For more information about mocking, read: https://flutter.dev/docs/cookbook/testing/unit/mocking.

So, how can we solve this problem with Riverpod? We simply need to create a Provider for each component that we want to inject into another component.

For the example above, we can use Riverpod this way:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// A

final aProvider = Provider((ref) {
 return A(); // or return MockA();
});

class A {}

class MockA extends A {}

// B

final bProvider = Provider((ref) {
 final a = ref.watch(aProvider);
 return B(a);
});

class B {
 final A a;

 B(this.a);
}

We created a Provider called aProvider that is responsible for providing an instance of A. In tests, we could override this Provider to return a mock version of A instead.

We also created a Provider bProvider that constructs an instance of class B. You can see, that we used ref.watch(aProvider) to retrieve an instance of A from aProvider and then return a new instance of B the result.

So, for our project, this means that we need to create a Provider for our EntryRepository. I like placing this Provider on top of the provided class:

1
2
3
4
5
6
7


import 'package:flutter_riverpod/flutter_riverpod.dart';

final entryRepositoryProvider = Provider((_) => EntryRepository());

class EntryRepository {
 ...
}

State & Controller

We are going to create new directories pages/home in the src directory. In home put a new file called home_page_controller.dart. This file is going to hold the state and the controller of our home page that we will create later.

First, we create a new Provider called entriesProvider that holds the state of the entries we want to display.

1
2
3
4
5
6
7


import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:simple_riverpod_architecture/repositories/entry_repository.dart';

final entriesProvider = FutureProvider((ref) {
 final entryRepository = ref.watch(entryRepositoryProvider);
 return entryRepository.allEntries();
});

This should look similar to what we did earlier. One difference is that we now need to use a FutureProvider instead of a Provider. This is necessary because entryRepository.allEntries() returns a Future instead of a synchronous value.

Next, we add a class called HomePageController. This class will be responsible for handling UI events.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class HomePageController {
 final ProviderRef ref;
 final EntryRepository entryRepository;

 HomePageController({required this.ref, required this.entryRepository});

 addEntry(String entry) {
 entryRepository.addEntry(entry);
 ref.refresh(entriesProvider);
 }

 removeEntry(String entry) {
 entryRepository.removeEntry(entry);
 ref.refresh(entriesProvider);
 }
}

You can see, that HomePageController has two attributes: ref and entryRepository. We are going to inject them later when creating a Provider for our controller.

The ProviderRef gives us access to functions involving the state of our app. It is used in lines 9 and 14 to tell the entriesProvider to refresh its state once we performed actions on our EntryRepository.

Finally, to make the HomePageController available in our UI, we also need to add a Provider for this class.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


...

final homePageControllerProvider = Provider((ref) {
final entryRepository = ref.watch(entryRepositoryProvider);
return HomePageController(ref: ref, entryRepository: entryRepository);
});

...

class HomePageController {
...
}

User Interface

As the last step, we will create a HomePage widget to view and manipulate entries in a list. If you have created a home_page.dart file already, move it to src/pages/home. Otherwise, create the file in this directory.

Instead of a StatelessWidget, we will use a ConsumerWidget for our page. ConsumerWidget is part of the Riverpod package and offers us an additional WidgetRef parameter for the build() method. This parameter we can use to access the Providers we created earlier.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


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

class HomePage extends ConsumerWidget {
 const HomePage({Key? key}) : super(key: key);

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 return Scaffold(
 appBar: AppBar(
 title: const Text('Entries Management'),
 ),
 );
 }
}

We utilize this ref to retrieve the elements provided by entriesProvider. Here we also see how beautifully this can be done with Riverpod:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


class HomePage extends ConsumerWidget {
 const HomePage({Key? key}) : super(key: key);

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 return Scaffold(
 appBar: AppBar(
 title: const Text('Entries Management'),
 ),
 body: ref.watch(entriesProvider).when(
 loading: () => const Center(child: CircularProgressIndicator()),
 error: (error, trace) => Center(child: Text(error.toString())),
 data: (data) =>
 ListView.builder(
 itemCount: data.length,
 itemBuilder: (context, index) {
 final item = data[index];
 return ListTile(title: Text(item));
 },
 ),
 ),
 );
 }
}

We use ref.watch() to listen to changes of the state of our entriesProvider. The watch function returns an AsyncValue that allows us to call the when function to provide different widgets depending on the state (* loading*, error, data) of the Future. This is a really convenient way to provide loading and error widgets.

Interactivity

Now, let’s add away to add and remove entries. For this, we add 2 methods to our HomePage.

1
2
3
4
5
6
7


onAdd(WidgetRef ref) {
 ref.read(homePageControllerProvider).addEntry(DateTime.now().toString());
}

onRemove(WidgetRef ref, String entry) {
 ref.read(homePageControllerProvider).removeEntry(entry);
}

We use the passed WidgetRef to access the HomePageController using the read function. Now we can simply call the functions of the controller.

When onAdd is called, we simply add a new entry containing the current data. When onRemove is called, we pass the entry that should be deleted to the controller.

WidgetRef comes with two functions to access providers: watch and read. watch should be used when you want to listen for changes to the provided value. This makes sense when being used for building widgets. In callbacks like button clicks or similar, we do care about changes made to the provider. In this case, we use the read function to access the provider.

Have a look at Riverpod’s documentation for more information on reading providers.

Next, we will link this functions with the UI. For adding new entries to our list, we create a FloatingActionButton. The delete action will be done when tapping an element in the list. Finally, the HomePage should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:simple_riverpod_architecture/pages/home/home_page_controller.dart';

class HomePage extends ConsumerWidget {
 const HomePage({Key? key}) : super(key: key);

 onAdd(WidgetRef ref) {
 ref.read(homePageControllerProvider).addEntry(DateTime.now().toString());
 }

 onRemove(WidgetRef ref, String entry) {
 ref.read(homePageControllerProvider).removeEntry(entry);
 }

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 return Scaffold(
 appBar: AppBar(
 title: const Text('Entries Management'),
 ),
 body: ref.watch(entriesProvider).when(
 loading: () => const Center(child: CircularProgressIndicator()),
 error: (error, trace) => Center(child: Text(error.toString())),
 data: (data) =>
 ListView.builder(
 itemCount: data.length,
 itemBuilder: (context, index) {
 final item = data[index];
 return ListTile(
 title: Text(item),
 onTap: () => onRemove(ref, item),
 );
 },
 ),
 ),
 floatingActionButton: FloatingActionButton(
 child: const Icon(Icons.add),
 onPressed: () => onAdd(ref),
 ),
 );
 }
}

We are done! It’s time to run the app and view what we have built.

The source code of this tutorial can be found on

GitHub: https://github.com/bettercoding-dev/riverpod-architecture.

Summary

So, shortly, wrap up what we have learned in this tutorial.

First, we had a look at how the data flow in our app is going to look like. We learned which parts we need in our app and created the according components.

Second, we saw that we can use Riverpod not only for state management, but also for dependency injection and why it makes sense so build our app this way.

Finally, we built our user interface that interacts with a controller and reacts to changes in the app state that we created used Riverpod.

I hope this tutorial helps you to understand how to structure your app using Riverpod. Let me know in the comments if you want to see more tutorials about Riverpod on this blog. Also, if you have any questions about this tutorial, comment below.

5 Things I do when starting a new Flutter project

Sun, 14 Nov 2021 00:00:00 +0000

Thinking about a project name

Although it sounds trivial, the first thing I do when creating a new Flutter project is to think about how I want to * name the project*. This is necessary for naming the project directory.

The name of the project will also be part of the bundle identifier in iOS and the package name in Android. They can be a bit tiresome to change, so better think of a meaningful name right away.

Project name and platforms are the first things that I check when creating a new Flutter project

2.) Clean up `pubspec.yaml`

By default, pubspec.yaml includes a tremendous number of comments. Although they might be useful if you are new to Flutter, I like to get rid of all of them. In my opinion, the comments make it hard to understand the content of the file.

3.) Clean up `main.dart`

Next, I like to remove all the sample code from the main.dart file. Usually, this is what my main.dart file looks like when I start a new project:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


import 'package:flutter/material.dart';
import 'package:simple_riverpod_architecture/home_page.dart';

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

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

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

Additionally, I added a new file called home_page.dart and added the most basic implementation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import 'package:flutter/material.dart';

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

 @override
 Widget build(BuildContext context) {
 return const Scaffold(
 body: Center(child: Text('Hello World')),
 );
 }
}

4.) Run the app

Now, that I have the most basic app possible, I will run the project. This way, I make sure everything is set up successfully. Since Flutter supports hot reload, I now also see my develop process immediately as I code along.

5.) Initialize git

Lastly, I initialize version control on the project. This can be simply done by running

git init
git add .
git commit -m "initial commit"

This initializes git on the projects, adds all files and creates a first commit. Having set up version control allows me to check what changes I have made since the last commit and lets me roll back changes.

I do not set up an origin right away, this I do later when I decide I want to have my project saved in a repository.

Video Recording and Replay with Flutter

Thu, 04 Nov 2021 00:00:00 +0000

Recording videos and preview the result can be easily done in Flutter. This tutorial shows how to create a record and replay flow using the camera and video_player packages.

Introduction

In this tutorial, we will use the camera and the video_player package to create a Flutter app flow to record and replay videos. The recorded video could then be used to – for example – upload it to a server.

First, we will start by creating a page which allows us to view the camera input and record a video.

Once the video has been recorded, we will open another page replaying the recorded video and allow the user to either accept or dismiss the video.

The source code of this tutorial is available on GitHub: https://github.com/bettercoding-dev/flutter-video.

Prerequisites

We first start with creating a new Flutter project.

Next, we clean up our pubspec.yaml file and add the necessary dependencies. After that, the content of pubspec.yaml should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


name: flutter_video
description: Flutter Video Flow

publish_to: 'none' # Remove this line if you wish to publish to pub.dev

version: 1.0.0+1

environment:
 sdk: ">=2.12.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter
 camera: ^0.9.4+3
 video_player: ^2.2.6 

dev_dependencies:
 flutter_test:
 sdk: flutter
 flutter_lints: ^1.0.0

flutter:
 uses-material-design: true

You can see that we included the camera and the video_player packages.

iOS-specific prerequisites

To make the packages work in iOS we need to insert following code into ios/Runner/Info.plist:

1
2
3
4
5
6
7
8
9


<key>NSCameraUsageDescription</key>
<string>Needed for recording videos.</string>
<key>NSMicrophoneUsageDescription</key>
<string>Needed for recording videos.</string>
<key>NSAppTransportSecurity</key>
<dict>
 <key>NSAllowsArbitraryLoads</key>
 <true/>
</dict>

Make sure to put this code within the existing dict block (before </dict>).

Android-specific prerequisites

We also need to modify one of the Android-specific files. To make the plugins work on Android, it is necessary to increase the minSdkVersion to 21. This can be done in the android/app/build.gradle file. Just search for minSdkVersion and replace the value. (Make sure you are not confusing android/build.gradle with android/app/build.gradle)

Don’t for get to run pub get after altering the pubspec.yaml file.

For our main.dart file, we will replace old its content with this code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


import 'package:flutter/material.dart';
import 'package:flutter_video/camera_page.dart';

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

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

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

Note that CameraPage does not exist yet, but we will create it in the next step.

Viewing Camera Input using the `camera` Plugin

Next, we are going to implement CameraPage that will show the input of the camera and lets us record a video. For this, let’s create a file called camera_page.dart and create a StatefulWidget. The stub of this file should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import 'package:flutter/material.dart';

class CameraPage extends StatefulWidget {
 const CameraPage({Key? key}) : super(key: key);

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

class _CameraPageState extends State<CameraPage> {
 @override
 Widget build(BuildContext context) {
 return Container();
 }
}

Because there is some initialization going on before we can access the camera, we need to display some loading state while the initialization is in progress.

For this, we create a variable _isLoading in our _CameraPageState and check the state in the build function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


class _CameraPageState extends State<CameraPage> {
 bool _isLoading = true;
 late CameraController _cameraController;

 @override
 void dispose() {
 _cameraController.dispose();
 super.dispose();
 }

 @override
 Widget build(BuildContext context) {
 if (_isLoading) {
 return Container(
 color: Colors.white,
 child: const Center(
 child: CircularProgressIndicator(),
 ),
 );
 } else {
 return CameraPreview(_cameraController);
 }
 }
}

We also added a CameraController variable and show a CameraPreview once the loading is done. Since this won’t work unless the _cameraController has been initialized, we continue with this step.

Initializing the `CameraController`

First, let’s create a function called _initCamera.

1
2
3
4
5
6
7


_initCamera() async {
 final cameras = await availableCameras();
 final front = cameras.firstWhere((camera) => camera.lensDirection == CameraLensDirection.front);
 _cameraController = CameraController(front, ResolutionPreset.max);
 await _cameraController.initialize();
 setState(() => _isLoading = false);
}

Line 2: Request all available cameras from the camera plugin.
Line 3: Selecting the front-facing camera.
Line 4: Create an instance of CameraController. We are using the CameraDescription of the front camera and setting the resolution of the video to the maximum.
Line 5: Initialize the controller with the set parameters.
Line 6: After the initialization, set the _isLoading state to false.

Finally, we call the _initCamera() function in initState().

1
2
3
4
5


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

When you now start the app, you should be able to see a preview of your front camera.

Recording Video

To start recording the video, we will add a record button. It should overlay the video preview, so we will put the CameraPreview and the button into a Stack widget.

Simply replace the content of the else branch with this code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


return Center(
 child: Stack(
 alignment: Alignment.bottomCenter,
 children: [
 CameraPreview(_cameraController),
 Padding(
 padding: const EdgeInsets.all(25),
 child: FloatingActionButton(
 backgroundColor: Colors.red,
 child: Icon(_isRecording ? Icons.stop : Icons.circle),
 onPressed: () => _recordVideo(),
 ),
 ),
 ],
 ),
);

Now, we need to create a new state variable _isRecording and set it to false.

1

bool _isRecording = false;

Finally, let’s create a _recordVideo() function to handle the button click. This function should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


_recordVideo() async {
 if (_isRecording) {
 final file = await _cameraController.stopVideoRecording();
 setState(() => _isRecording = false);
 final route = MaterialPageRoute(
 fullscreenDialog: true,
 builder: (_) => VideoPage(filePath: file.path),
 );
 Navigator.push(context, route);
 } else {
 await _cameraController.prepareForVideoRecording();
 await _cameraController.startVideoRecording();
 setState(() => _isRecording = true);
 }
}

Line 2: We need to handle both, start and stop recording actions. Therefore, we need to check if the video is currently recording.
Line 3: If the video is recording, we will stop it. The stopVideoRecording() function returns a file containing the recorded video.
Line 4: We update the state and set _isRecording to false.
Lines 5-9: Finally, with the recorded file, we will open the VideoPage to let the user check on the recorded video. (Note: VideoPage does not exist yet. It will be added in the next step)
Line 11: If the video is not yet recording, we tell the CameraController to prepare for recording.
Line 12: Once the preparation is done, we start the actual recording.
Line 13: Finally, we set the current state to _isRecording = true.

Replaying the Recorded Video

For replaying the recorded video, create a new file called video_page.dart and add a StatefulWidget, like we did for the CameraPage.

The VideoPage needs to accept a path to the recorded file. So, we add a new attribute filePath:

1
2
3
4
5
6
7
8


class VideoPage extends StatefulWidget {
 final String filePath;

 const VideoPage({Key? key, required this.filePath}) : super(key: key);

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

For the _VideoPageState class, we start by creating a VideoController and a function to initialize it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class _VideoPageState extends State<VideoPage> {
 late VideoPlayerController _videoPlayerController;

 @override
 void dispose() {
 _videoPlayerController.dispose();
 super.dispose();
 }

 Future _initVideoPlayer() async {
 _videoPlayerController = VideoPlayerController.file(File(widget.filePath));
 await _videoPlayerController.initialize();
 await _videoPlayerController.setLooping(true);
 await _videoPlayerController.play();
 }

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

Line 2: We add a new _videoPlayerController variable.
Lines 4-8: Don’t forget to dispose the VideoPlayerController once the State gets disposed.
Line 11: Create a new VideoPlayerController from the file path that we passed to this widget.
Line 12: Initialize the VideoPlayerController before we can start it.
Line 13: To play the video over and over again, we enable looping.
Line 14: Finally, we start the video.

As the last step, let’s define our UI. It should have an AppBar to accept or dismiss the video. And – of course – contain a VideoPlayer widget to replay the video. The build function for this widget could look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


@override
Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: const Text('Preview'),
 elevation: 0,
 backgroundColor: Colors.black26,
 actions: [
 IconButton(
 icon: const Icon(Icons.check),
 onPressed: () {
 print('do something with the file');
 },
 )
 ],
 ),
 extendBodyBehindAppBar: true,
 body: FutureBuilder(
 future: _initVideoPlayer(),
 builder: (context, state) {
 if (state.connectionState == ConnectionState.waiting) {
 return const Center(child: CircularProgressIndicator());
 } else {
 return VideoPlayer(_videoPlayerController);
 }
 },
 ),
 );

}

Line 3: We use a Scaffold to create our page.
Lines 4-16: Add an AppBar that is transparent and includes an additional “OK” action. There, you could implement additional functionality to e.g. forward the video to a server.
Line 17: This parameter is set, to stretch the video behind the AppBar.
Lines 18-27: We use a FutureBuilder to show a CircularProgressIndicator as long as the initialization takes place. As soon as the initialization is done, the VideoPlayer is shown, replaying the video.

And, we are all done.

You can now start the app to record and replay videos.

Summary

In this tutorial, we used the camera and video_player packages to create a flow recording and replaying a video with Flutter.

The source code of this tutorial is available on GitHub: https://github.com/bettercoding-dev/flutter-video.

Implementing Swipe Actions in Flutter ListView

Tue, 24 Aug 2021 00:00:00 +0000

Swipe gestures are a handy way to add actions to a ListView in Flutter. In this tutorial, we are going to implement two swipe actions – swipe to delete and toggle favorite – and have a look at using a Snackbar for adding an undo action.

Goal of this Tutorial

We are going to implement a simple app displaying a list of ice cream flavors. By swiping a list element to the right, we will add or remove the flavor as a favorite flavor.

Swiping to the left will be a swipe-to-delete action and removes the element from the list. In this case, a Snackbar is shown offering to undo the delete action.

The code for this tutorial is available on GitHub.

Prerequisite

First, we start by creating a new Flutter app and clean up the generated project code. For this tutorial we do not need any dependencies, so my pubspec.yaml looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


name: list_view_swipe
description: List View Swipe Example
publish_to: 'none'
version: 1.0.0+1

environment:
 sdk: ">=2.12.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter

flutter:
 uses-material-design: true

Next, we clean up our main.dart. We remove most of the boilerplate code, which leaves us with the following code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import 'package:flutter/material.dart';
import 'package:list_view_swipe/list_page.dart';

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

class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 debugShowCheckedModeBanner: false,
 home: ListPage(),
 );
 }
}

Finally, we create a new file called list_page.dart and add a StatefulWidget called ListPage. We set up a basic Scaffold with and AppBar like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import 'package:flutter/material.dart';

class ListPage extends StatefulWidget {
 const ListPage({Key? key}) : super(key: key);

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

class _ListPageState extends State<ListPage> {
 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text('Flavors'),
 ),
 );
 }
}

Now, when we build our app it should look like this:

Displaying a list of flavors

To have some content that we can display in our list, we continue by creating a new file called flavor.dart and add a simple class holding all information we need to know about an ice cream flavor.

Every flavor has a name of type String and an attribute isFavorite which is a bool and is false by default. This is our Flavor class:

1
2
3
4
5
6
7
8
9


class Flavor {
 final String name;
 final bool isFavorite;

 Flavor({required this.name, this.isFavorite = false});

 Flavor copyWith({String? name, bool? isFavorite}) =>
 Flavor(name: name ?? this.name, isFavorite: isFavorite ?? this.isFavorite);
}

You can see that I have also added a copyWith function. Since our Flavor is immutable – all its attributes are final, thus unchangeable – this function helps us to create a new version of a Flavor with adjusted attributes. We will use this function later to toggle the isFavorite flag of the Flavors.

Next, we go back to flavor_list.dart and add a list of Flavors to _ListPageState.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class _ListPageState extends State<ListPage> {
 final List<Flavor> flavors = [
 Flavor(name: 'Chocolate'),
 Flavor(name: 'Strawberry'),
 Flavor(name: 'Hazelnut'),
 Flavor(name: 'Vanilla'),
 Flavor(name: 'Lemon'),
 Flavor(name: 'Yoghurt'),
 ];

 ...
}

To display our Flavors, we use a ListView. We use the builder factory to create a performance optimized ListView. Using the builder factory, only elements are generated that are currently displayed on the screen. Elements that do not fit on the screen are only created on demand.

Let’s look at the build function of _ListPageState:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


 @override
Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text('Flavors'),
 ),
 body: ListView.builder(
 itemCount: flavors.length,
 itemBuilder: (context, index) {
 final flavor = flavors[index];
 return ListTile(
 title: Text(flavor.name),
 );
 },
 ),
 );
}

We specify the number of flavors that are available using the itemCount attribute and define how the ListView should build the list items by implementing the itemBuilder callback.

For every item, we fetch the corresponding flavor (line 10) and then use a ListTile to display the name of the Flavor.

Next we add an icon to each ListTile indicating whether the Flavor is a favorite or not. For this, we add the following line to the ListTile:

1

trailing: Icon(flavor.isFavorite ? Icons.favorite : Icons.favorite_border),

Now, let’s have a look at our app again.

Swipe Action: Toggle Favorite

Next, we add a swipe action to toggle the favorite state of a flavor. For this, we wrap the ListTile in a Dismissible widget. A Dismissible requires to have a Key, so we add it like this:

1
2
3
4
5
6


Dismissible(
 key: Key(flavor.name),
 child: ListTile(
 ...
 ),
);

Now you can see that you are able to move your ListTiles.

To give the user a hint about the action that is going to happen, we add a background attribute to the Dismissible widget.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


...
background: Container(
 color: Colors.green,
 child: Align(
 child: Padding(
 padding: const EdgeInsets.only(left: 16),
 child: Icon(Icons.favorite),
 ),
 alignment: Alignment.centerLeft,
 ),
),
...

When swiping an item to the right, we see a green background with a favorite icon.

Finally, there are two things left to do: First, we need to prevent the item from being removed from the list when it is swiped to the right. Second, we need to add an action to the swipe gesture.

To keep the item in the list, we need to implement the confirmDismiss callback of Dismissible. It provides us the direction in which the item has been swiped and requires us to return true if the item should be deleted. We also use this callback to add an action to the swipe gesture.

1
2
3
4
5
6
7
8


confirmDismiss: (direction) async {
 if (direction == DismissDirection.startToEnd) {
 setState(() {
 flavors[index] = flavor.copyWith(isFavorite: !flavor.isFavorite);
 });
 return false;
 }
},

Now, when swiping from start to end – left to right in our case – we update the state of our ListPage. We do this by calling the setState function and replacing the Flavor at position index with a copy with inverted isFavorite flag.

We return false to signal that we do not want our item removed from the list.

Swipe Action: Swipe to delete

Now, we want to add a second action: the item should be deleted when it is swiped to the left side. Additionally, we want to add a different background for this action.

For this, we copy the Container we added to background and add it to secondaryBackground attribute for Dismissible.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


...
secondaryBackground: Container(
 color: Colors.red,
 child: Align(
 child: Padding(
 padding: const EdgeInsets.only(right: 16),
 child: Icon(Icons.delete),
 ),
 alignment: Alignment.centerRight,
 ),
),
...

We adjust the color to Colors.red, change the padding from left to right, replace the icon, and change the alignment to centerRight.

When we swipe our item to the left side, we see that the secondaryBackground is used.

Next, we are going to extend the confirmDismiss callback. We add an else block to handle our delete action. Here, we are going to show a SnackBar with a SnackBarAction. Let’s see what this looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 confirmDismiss: (direction) async {
 if (direction == DismissDirection.startToEnd) {
 ...
 } else {
 bool delete = true;
 final snackbarController = ScaffoldMessenger.of(context).showSnackBar(
 SnackBar(
 content: Text('Deleted ${flavor.name}'),
 action: SnackBarAction(label: 'Undo', onPressed: () => delete = false),
 ),
 );
 await snackbarController.closed;
 return delete;
 }
 },

First, in line 5, we add a variable to store our decision whether the item should be deleted.

In line 6 we use the ScaffoldMessenger to show a SnackBar and store the returned SnackBarController. We need this instance later in line 12 to wait for the SnackBar to close.

The SnackBar contains a Text content (line 8) and defines a SnackBarAction (line 9). The action changes the delete variable to false, indicating that the item should not be deleted.

After the SnackBar has been closed, we return the decision whether to delete the item.

Finally, we need to implement onDismissed to actually remove the item from our List, to match the state of the UI.

The callback should look like this:

1
2
3
4
5


onDismissed: (_) {
 setState(() {
 flavors.removeAt(index);
 });
},

We ignore the callback parameter and replace it with _. We use the setState function to redraw our UI and remove the item from the list.

Finally

The complete ListPage should now look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85


import 'package:flutter/material.dart';
import 'package:list_view_swipe/flavor.dart';

class ListPage extends StatefulWidget {
 const ListPage({Key? key}) : super(key: key);

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

class _ListPageState extends State<ListPage> {
 final List<Flavor> flavors = [
 Flavor(name: 'Chocolate'),
 Flavor(name: 'Strawberry'),
 Flavor(name: 'Hazelnut'),
 Flavor(name: 'Vanilla'),
 Flavor(name: 'Lemon'),
 Flavor(name: 'Yoghurt'),
 ];

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text('Flavors'),
 ),
 body: ListView.builder(
 itemCount: flavors.length,
 itemBuilder: (context, index) {
 final flavor = flavors[index];
 return Dismissible(
 key: Key(flavor.name),
 background: Container(
 color: Colors.green,
 child: Align(
 child: Padding(
 padding: const EdgeInsets.only(left: 16),
 child: Icon(Icons.favorite),
 ),
 alignment: Alignment.centerLeft,
 ),
 ),
 secondaryBackground: Container(
 color: Colors.red,
 child: Align(
 child: Padding(
 padding: const EdgeInsets.only(right: 16),
 child: Icon(Icons.delete),
 ),
 alignment: Alignment.centerRight,
 ),
 ),
 confirmDismiss: (direction) async {
 if (direction == DismissDirection.startToEnd) {
 setState(() {
 flavors[index] = flavor.copyWith(isFavorite: !flavor.isFavorite);
 });
 return false;
 } else {
 bool delete = true;
 final snackbarController = ScaffoldMessenger.of(context).showSnackBar(
 SnackBar(
 content: Text('Deleted ${flavor.name}'),
 action: SnackBarAction(label: 'Undo', onPressed: () => delete = false),
 ),
 );
 await snackbarController.closed;
 return delete;
 }
 },
 onDismissed: (_) {
 setState(() {
 flavors.removeAt(index);
 });
 },
 child: ListTile(
 title: Text(flavor.name),
 trailing: Icon(flavor.isFavorite ? Icons.favorite : Icons.favorite_border),
 ),
 );
 },
 ),
 );
 }
}

We used the Dismissible widget to create swipe actions to toggle the favorite state and to remove items. It allows us to handle the gesture differently depending on the swipe direction. Furthermore, we can specify different background per swipe direction.

To offer an undo action, we used a SnackBar with a SnackBar action.

Simple Themes in Flutter using Riverpod

Tue, 10 Aug 2021 00:00:00 +0000

Adding a dark and a light mode is becoming increasingly popular in app development. In this tutorial, we will write a Flutter app with a light and a dark theme and extend Flutter’s ThemeData with custom attributes.

Goal of this Tutorial

In this tutorial, we will have a look at how to add a dark and a light theme to your Flutter project. Further, we will implement the functionality to switch between dark and light mode directly within your app.

Since often it is necessary to have custom, theme-specific attributes, we will have a look on how to solve this problem. This tutorial also shows how to load theme-specific assets.

You can check out the code for this tutorial on GitHub. Use the template branch as a starting point, or create your own project. The finished app is on branch solution.

Prerequisites

Before we start, we need to create a new Flutter project. We will be using a Flutter version supporting null-safety for this tutorial.

Furthermore, we need to add flutter_riverpod as dependency.

Lastly, we need to create an asset folder right in your root directory and reference it in our pubspec.yaml file. This allows us to load images from this directory later.

The pubspec.yaml should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


name: theming
description: bettercoding.dev - Theming

publish_to: 'none'
version: 1.0.0+1

environment:
 sdk: ">=2.12.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter
 flutter_riverpod: ^0.14.0+3

dev_dependencies:
 flutter_test:
 sdk: flutter

flutter:
 assets:
 - assets/

Dark and Light Theme: Specifying the look

Next, we create a theme.dart file in our lib folder. This file will contain the heart of our app. Here we will specify our ThemeDatas and create some utility classes and functions.

Let’s start with defining our themes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import 'package:flutter/material.dart';

// THEME PROVIDERS

// THEMES
// light
final _theme = ThemeData();

//dark
final _darkTheme = ThemeData();

// EXTENSIONS AND CLASSES

Here you can be creative how you want to style the app. This is how I defined my _theme and _darkTheme. Just make sure you set the brightness of your ThemeData correctly, so that the correct fallback values can be used.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import 'package:flutter/material.dart';

// THEME PROVIDERS

// THEMES
// light
final _theme = ThemeData(
 primaryColor: Colors.deepPurple,
 elevatedButtonTheme: ElevatedButtonThemeData(
 style: ElevatedButton.styleFrom(
 primary: Colors.deepPurple,
 shape: StadiumBorder(),
 ),
 ),
 textTheme: TextTheme(
 headline1: TextStyle(
 fontSize: 48,
 fontWeight: FontWeight.bold,
 color: Colors.black87,
 ),
 headline2: TextStyle(
 fontSize: 36,
 fontWeight: FontWeight.bold,
 color: Colors.black54,
 )),
);

//dark
final _darkTheme = ThemeData(
 brightness: Brightness.dark,
 primaryColor: Colors.deepPurple,
 elevatedButtonTheme: _theme.elevatedButtonTheme,
 textTheme: _theme.textTheme.apply(
 displayColor: Colors.white,
 bodyColor: Colors.white,
 ),
);

// EXTENSIONS AND CLASSES

Custom Attributes: Extending ThemeData

Often, you want to have additional theme-specific attributes, but extending ThemeData does not really work well ( if at all). For this tutorial, we are going to assume that we want to size our images differently on light and on dark mode.

To solve this problem, we create a new class CustomThemeData right under // EXTENSIONS AND CLASSES and add an imageSize attribute.

The class should look like this:

1
2
3
4
5
6
7


class CustomThemeData {
 final double imageSize;

 CustomThemeData({
 this.imageSize = 100,
 });
}

A size of 100 is used as the default value. Add any attributes to this class that you need in your app.

Now we create instances of CustomThemeData for both, light and dark theme and put them right below their corresponding ThemeData instances.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import 'package:flutter/material.dart';

// THEME PROVIDERS

// THEMES
// light
final _theme = ThemeData(...);

final _customTheme = CustomThemeData(
 imageSize: 150,
);

//dark
final _darkTheme = ThemeData(...);

final _customDarkTheme = CustomThemeData();

// EXTENSIONS AND CLASSES
...

In this case, images will have a size of 150 in the light theme, whereas the dark theme will fall back on the default value of 100.

To glue it all together, we create an extension that makes our CustomThemeData available to use.

1
2
3
4


extension CustomTheme on ThemeData {
 CustomThemeData get custom =>
 brightness == Brightness.dark ? _customDarkTheme : _customTheme;
}

Now, our custom theme attributes can be accessed using:

1
2
3
4
5
6
7
8


Theme.of
(
context
)
.
custom
.
imageSize

Amazing, right?

Providing our themes using Riverpod

After creating the style of our themes, we need to provide them to our MaterialApp widget. We are going to use * Riverpod* for this purpose. If you are not familiar with Riverpod checkout riverpod.dev.

We create following two providers below // THEME PROVIDERS:

1
2
3


// THEME PROVIDERS
final theme = Provider((ref) => _theme);
final darkTheme = Provider((ref) => _darkTheme);

Next, we continue in the main.dart file. A very basic implementation could look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Container();
 }
}

First, we need to define a ProviderScope. This is required by Riverpod to work. Afterwards, our main function is defined this way:

1
2
3


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

So far, the app won’t do much. Let’s replace the Container with something more useful.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Consumer(
 builder: (context, watch, _) =>
 MaterialApp(
 theme: watch(theme),
 darkTheme: watch(darkTheme),
 home: Container(),
 ),
 );
 }
}

We need to wrap our MaterialApp with a Consumer widget from the Riverpod package. Consumer offers us the watch function that we will use to read (‘watch’) the values offered by our Providers.

By default, Flutter uses the brightness (light or dark mode) from the underlying system. For now, we leave it like this, but we will return later to implement switching themes within the app ( see: Theme Switching: changing the Theme within the App).

Finally, it is time to create a page that we want to show when the app starts. We create a file main_page.dart and add a StatelessWidget MainPage.

Feel free to be creative here. I’ll go with the following code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


import 'package:flutter/material.dart';

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

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text('bettercoding.dev – theming'),
 ),
 body: Padding(
 padding: const EdgeInsets.all(16),
 child: Column(
 crossAxisAlignment: CrossAxisAlignment.stretch,
 children: [
 const SizedBox(height: 16),
 Text(
 'Welcome!',
 textAlign: TextAlign.center,
 style: Theme
 .of(context)
 .textTheme
 .headline1,
 ),
 const SizedBox(height: 16),
 Text(
 'This is a tutorial about theming.',
 textAlign: TextAlign.center,
 style: Theme
 .of(context)
 .textTheme
 .headline2,
 ),
 Spacer(),
 ElevatedButton(
 child: Text('Click me!'),
 onPressed: () {},
 )
 ],
 ),
 ),
 );
 }
}

Don’t forget to replace the Container with MainPage at the home attribute of your MaterialApp.

Now, let’s build our app.

So far, so good. A basic implementation of the app is ready. But there is more.

Theme-specific Assets: Different images for light and dark mode

Very often, it is necessary to use different versions of an image when working with themes. As with the text color, the color of an image in dark theme needs to change.

In the assets folder, upload an image that you want to use for light mode and call it logo.png. Create a subfolder called dark and upload the dark mode version of the image with the same name.

The folder structure should look like this:

In theme.dart, we add a function imageForName to the CustomTheme extension.

1
2
3
4
5
6
7
8
9


// EXTENSIONS AND CLASSES
extension CustomTheme on ThemeData {
 AssetImage imageForName(String name) {
 final path = brightness == Brightness.dark ? 'assets/dark' : 'assets/';
 return AssetImage('$path/$name');
 }

 ...
}

The function checks the current brightness and builds the path to the asset accordingly. Let’s use this function to add an image to the MainPage.

Add the following lines between Spacer and ElevatedButton:

1
2
3
4
5
6
7
8
9


Image
(
image: Theme.of(context).imageForName('logo.png'),
height: Theme.of(context).custom.imageSize,
),
Spacer
(
)
,

Don’t forget to import your theme.dart file, so your extension functions can be used.

Here we make use of two extension functions we built earlier. imageForName loads a theme-specific image from the assets. Just pass the correct name of the file and the function resolves the correct asset for you.

custom.imageSize lets us access a theme-specific attribute that we defined earlier.

Let’s build the app again and see what we have got.

We see that our app shows different images and adjusts the size according to what we have specified in our CustomThemeData.

Theme Switching: changing the Theme within the App

Finally, we are going to implement the functionality to switch between light and dark mode by clicking a button. For this, we create a new StateProvider in theme.dart, just below the other providers.

final themeMode = StateProvider((ref) => ThemeMode.light);

A StateProvider is a provider that holds a changeable state. We initialize this state with ThemeMode.light. This means, by default, our app will always open in light mode. This might not be ideal, but we’ll have a look at alternatives in “Persisting the current Theme”.

Next, we go to main.dart and set the themeMode of our MaterialApp widget. The widget should now look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


MaterialApp
(
theme: watch(theme),
darkTheme: watch(darkTheme),
themeMode: watch(themeMode).state
,
home
:
MainPage
(
)
,
)

And finally, let’s implement the onPressed callback of our ElevatedButton in main_page.dart.

1
2
3
4
5
6
7
8
9


ElevatedButton
(
child: Text('Click me!'),
onPressed: () {
final state = context.read(themeMode).state;
context.read(themeMode).state =
state == ThemeMode.light ? ThemeMode.dark : ThemeMode.light;
},
)

The context.read function – don’t forget to import the Riverpod library! – allows us to access the StateProvider. First, we read the state to see which mode is currently active. Then we assign a new value to the state – dark mode if we are currently in light mode and vice versa.

Setting the state causes all widgets that are watching the themeMode StateProvider to rebuild, using the new value. In our case, this is the MaterialApp widget.

Clicking the button, switches between light and dark mode.

Voilà! We now can conveniently switch between the different themes from within our app. In a larger app, you would probably add the logic setting the state of our themeMode StateProvider to your settings page.

Persisting the current Theme

One drawback this solution has is that the selected theme is reset once you restart the app. In order to keep the state over time, it is necessary to persist it at some point. Using shared preferences would be a possible solution.

I have implemented a solution in the persist_theme branch of the project repository. If you would like me to add a tutorial on how I did this, let me know by leaving a comment.

Finally

In this tutorial, we saw how light and dark mode can be implemented in Flutter using Riverpod. Additionally, we created a way to extend ThemeData with custom attributes and how to load theme-specific assets.

Like always, there are certainly other possible solutions as well. If you want me to implement this example using different packages than Riverpod, or if you have any suggestions to my solution, write me a comment below.

Starting a new Flutter Project: 10 questions you need to answer

Mon, 02 Aug 2021 00:00:00 +0000

Beginning a new project leaves you with many decisions to make. You should know supported platforms, languages and screen sizes before you start coding. This article shows you 10 things you should think about before starting a new Flutter project.

A Fresh start: Before you start a new Flutter project

Starting a new Flutter project is like starting to build a new house. At first there are almost unlimited options what you could build. But there are some decisions you need to make that define the outcome of your project.

How many floors should your house have? What type of architecture should be used? So before you start building, you start planning.

The same should apply for software projects. Before you begin coding, you should think about a few things first.

10 Questions

1. Which state management library do you use?

State management strongly defines the architecture of your Flutter app. Thus, deciding which state management approach you want to use, will be one of the first things you need to do when starting a new Flutter project.

Where for a small app you might end up just using Flutter’s setState() mechanism, with larger apps you’ll definitely want to go with a more advanced approach.

Popular libraries that base on Flutter’s InheritedWidget are Provider and Riverpod. If you are looking for reactive approaches, libraries like Bloc or Redux might be your way to go.

Have a look at the official Flutter documentation for a detailed overview of state management solutions.

2. Which platforms do you need to support?

With Flutter, you cannot only build apps for Android and iOS, but also for Web, Windows, Linux and macOS. Although, you can also add support to platforms later on, it is better to know your platforms in advance.

Whereas mobile apps work with taps and gestures, desktop apps should also support things like keyboard shortcuts and mouse interactions like right click or the mouse wheel. Adding these features later on will be more effort than just building them into your app from the start.

3. Which screen sizes do you support?

A similar question before kicking off a new Flutter project is, which screen sizes you should support. This is not only dependent on which platforms you choose to support, but also if you want to have tablet support.

Larger screen sizes offer you the possibility to put more information on one screen, which changes how you navigate through your app. For example: a tablet version can use a master-detail view on one screen, whereas the mobile version would need to put the master and the detail view on separate screens.

Changing the navigation within your app later can be a very annoying task. So better think about this before you start your project.

4. Which languages do you support?

You can target more users if you translate your app into multiple languages. Also, if you only release your app in one language, it is a good practice to have all translations in one place. This makes it easier to update names and also allows you to stay on top of your wordings.

Look at the Flutter documentation to learn how internationalizing Flutter apps works. If you are using IntelliJ, Android Studio or Visual Studio Code, I can recommend the Flutter Intl plugin. This plugin handles a lot of tasks needed for internationalization.

5. Do you need Navigator 2.0?

Flutter offers you to use two ways to build navigation within your app. Originally (using Navigator 1.0), navigation works by pushing or popping pages to/from a navigation stack. This works well for simple apps, but has limitations when you want to use deep linking or target the web.

Navigator 2.0 offers a more sophisticated approach to navigation. It gives you more control on how navigation in your app works, but requires you to set up a bunch of classes to make it work. It definitely makes sense for larger app – especially for web, but would be overkill for your tiny three to four screens app.

6. Do you need Flutter Version Manager?

If you work on multiple Flutter projects, it is likely that these projects use different Flutter versions. Although it’s best practice to use the newest version, upgrading might not have to the highest priority of your project tasks.

Usually, the Flutter SDK is installed somewhere on your computer as a directory with a bunch of files. If you have multiple versions of Flutter, you need several of these directories.

Before managing your Flutter SDKs becomes to tiresome, it may be time to install the Flutter Version Manager (fvm). This tool lets you set a Flutter version for each of your project and manages them for you.

7. Should you support multiple themes?

More and more apps support a light and a dark theme. When you are going to begin a new Flutter project, you should make sure if you want to have multiple themes.

It is much easier to add themes afterwards if you plan your architecture accordingly. This – for example – includes putting your theme configuration in a central place, instead of styling your widgets inline.

For more information about theming in Flutter, checkout this tutorial.

8. Which git repository do you use?

Don’t forget to commit and push your source code to a repository. This keeps your code stored in a safe place, even if your computer breaks or gets stolen.

So, before starting a new Flutter project, checkout services like GitHub or Bitbucket, that offer you free private repositories.

9. Is Flutter the right framework for your project?

Flutter is a great framework, but is it the right one for your project? There are some reasons why native app development would be a better fit.

For example, apps that have a strong hardware focus (e.g. need to read data from sensors or external hardware) might be easier to implement using native app development for Android and iOS.

Another example, when native app development should be preferred is, when you want to build an app with a strong native look and feel. That means using all native UI elements and animations. This is where Flutter sometimes have problems – especially with iOS specific design elements.

For more information about this question, read this article about cross-platform vs native development.

10. Do you need a CI/CD pipeline?

If you know that your new Flutter project is going to be somewhat bigger, you should also think about using a CI/CD pipeline.

The purpose of a CI/CD pipeline is to regularly run a set of tasks that help to improve your software’s quality. Most commonly, tests and static analysis are run on your code and a new version of your app is being built.

This way you will quickly see if there are problems with your app.

There are multiple providers that offer CI/CD pipelines for Flutter: CodeMagic, Bitrise or Appcircle.

Summary

There are many questions you should ask yourself before beginning a new flutter project. What platforms do you target? Which languages do you need to support? Do you need a dark theme? Should you use Bloc, or maybe Riverpod?

Going through this list before starting a new Flutter project helps you to make sure you do not forget an important aspect of your app. Many things become more and more difficult to add the further you progress within your project.

Is there anything missing in this list? Let me know by writing a comment below.

Cross-platform or Native Android/iOS? The best choice for your project.

Wed, 28 Jul 2021 00:00:00 +0000

My story with cross-platform development

When I first heard about cross-platform mobile app development, I thought it was something about the Apache Cordova framework.

At first, I was excited about the possibility to have a single code base for Android and iOS apps, but this excitement quickly faded when I actually tried it out. It was difficult to make good-looking apps, and the performance wasn’t anything close to native apps.

This was why a returned to native Android development, and it took me a couple of years to give cross-platform development another try. This time, Flutter was my framework of choice.

And wow, what a difference!

My Flutter apps ran smoothly and even looked good – at least if you don’t want to build natively looking iOS apps.

Perfect, right? Why still bother with native app development? Well, unfortunately it’s not that simple. There are many advantages from cross-platform frameworks compared to native development, but so are there many reasons to stick with native mobile app development.

So what should you choose? In this article, I want to list the arguments for cross-platform development and those for native Android/iOS app development to help you decide what to use for your next project.

You should use cross-platform frameworks when…

Cross-platform frameworks allow building apps for different platforms like iOS and Android using one single code base. Let’s start with the arguments for using cross-platform frameworks like Flutter or React Native.

… you have limited resources

Having a shared code base is a huge benefit of cross-platform frameworks. Especially, if you work alone (or in a small team), have deadlines or a tight budget, this is a big plus.

Instead of essentially writing your app twice (let’s assume you’re building for Android and iOS), you just need to code it once and then build different versions for your target platforms.

Of course, this does not quite halve your development time. There are always situations where you need to handle some platform specific problems, or you need to consider differences in the design guidelines between Android and iOS.

Also, you need to be aware that you are building, signing and deploying/releasing the apps is different on Android and iOS.

Nevertheless, cross-platform frameworks allow you to reach your goal faster (thus cheaper) and with fewer people needed.

… you use all custom UI elements

If you just want to use standard UI components to make your app look like a truly native Android or iOS app, you might be in trouble with cross-platform frameworks.

Whereas React Native supports displaying native UI elements, Flutter comes with a set of UI Elements that primarily focuses on Google’s Material Design used by Android. Although there is also a set of components mimicking their iOS counterparts, they probably won’t be enough for building a native looking app.

This might be no problem at all if you decide to design and build custom elements anyway. In this case, you can save a lot of time when you only have to style a component once and then use it for all your platforms.

… you build a ‘rather standard’ app

Fetching data from an API, displaying it in your app, receiving user input, and sending the data back to a server. If this is the basic flow of your app, this is where cross-platform frameworks shine.

You need to receive a bit stream over a Bluetooth connection? That’s where cross-platform frameworks might not be so great. At least, you will have to write some platform specific code to access the device’s hardware (or hope someone already did it and released a library).

… you want to build for web and desktop as well

“Done” with your app and decide you also want to release a web and a desktop app? Flutter also supports building for web and desktop operating systems.

So if your app is already able to handle large screens (e.g. for tablets) you might just release it for desktop and web as well.

…you are web developer

When you are a web developer, cross-platform frameworks are closer to the frameworks you are familiar with. React Native is based on React.js – so if you know that already it shouldn’t be too hard for you to start working on mobile apps.

But also Flutter uses similar concepts. Although Flutter does not use JavaScript or TypeScript, it uses Dart which is very similar.

You should use native Android / iOS when…

As already mentioned above, there are still cases where it makes sense to develop your mobile app natively. Most likely this is the case when advanced hardware support is required.

… you just need one platform

When you only need to develop for either Android or iOS you naturally only have one code base. In this case, there’s no need to use a cross-platform framework.

Of course, you should also keep in mind that you might want to support other platforms some months (or years) later.

… you write a hardware focused app

When you build your app around sensor data or external devices, a native app might be the better choice.

In hardware focused apps, a lot of your code will be platform specific. Especially, if you do not have a lot of UI components, the amount of code you would share using cross-platform frameworks would be rather small.

Also, you won’t release web or desktop versions of these type of apps, since you won’t even have access to the hardware needed.

… you already know your Frameworks

If you already have lots of experience writing Android and iOS apps natively, it might make sense continuing to do so.

Learning a new framework takes some time, and if you are not familiar with the concepts of React Native or Flutter, this will slow down your development process.

So, if you do not want to spend time reading the docs and searching for libraries, stick with what you have.

… you use heavy animations

Cross-platform frameworks cannot quite compete in terms of performance when compared to their native counterparts (although Flutter gets close).

If you rely on many heavy animations in your app, these usually perform better using native development. Have a look at this article on Medium with an in-detail performance analysis between Flutter, React Native and native apps.

… you want to use a native style

If you want all UI elements and animations to feel as native as possible, you should write a native app. Sounds obvious, right?

This might not be so true for Android apps, since Flutter as well focuses on Material Design, but Flutter’s iOS elements library is incomplete and apparently does not have the highest priority on the Flutter roadmap.

Summary (tl;dr)

Both cross-platform frameworks and native Android and iOS apps have their advantages and drawbacks.

Cross-platform frameworks like Flutter and React Native allow to release your apps from a single code base. If you use custom UI elements and focus on apps reading from and writing to APIs and displaying data, these frameworks shine. Also, if you are a web developer who wants to get started with mobile app development, Flutter or React Native are the better way for you.

Native apps have their strengths if you want to build hardware-centered apps or include heavy animations. Also, the advantages of cross-platform frameworks vanish, if you only need to develop for a single platform.

If you are already experienced writing Android and/or iOS apps, you might not want to learn a new framework with different concepts. Although, it might be worth in the long run, so see it as an investment.

In conclusion, whether you should use a cross-platform approach or develop your app natively depends on different factors. You will have to specifically weigh them according to your project and your experience.

Your Input

Are there any more things to consider when deciding between cross-platform and native development? Leave a comment below and let my know what you think.

Super Simple Hero Animation in Flutter

Wed, 03 Jun 2020 00:00:00 +0000

Creating animations when you natively develop an app for Android or iOS is rarely done. Most of the time it is too complicated, and the budget restricts adding anything fancy to an app.

Therefore, I was positively surprised when I discovered how simple it is to add basic animation to my apps when developing with Flutter.

In this tutorial, I want to show you how to create a very simple app where you can select an item from a list to open in detail view. To make the transitions between list view and detail view more appealing, we will add a so-called hero animation.

A hero animation basically consists of a piece of content that is brought over from one screen to another. This supports the user’s understanding of the context of the app.

Let’s have a look how our app should look like:

Prerequisite

We start by creating a new Flutter project. This time I name it super_simple_hero_animation. Like in my other tutorials, we start by cleaning up our project.

We go with the most basic configuration of our pubspec.yaml and main.dart file.

pubspec.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


name: super_simple_hero_animation
description: Super Simple Hero Animation
publish_to: 'none' # Remove this line if you wish to publish to pub.dev
version: 1.0.0+1

environment:
 sdk: ">=2.7.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter

flutter:
 uses-material-design: true

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import 'package:flutter/material.dart';
import 'package:super_simple_hero_animation/home_page.dart';

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

class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 home: HomePage(),
 );
 }
}

Hero Animation Part 1: The Master Page

In a new file home_page.dart we create our master page – the page containing a list of elements. Every element consists of an image and a name. Perfect application for the ListTile widget.

home_page.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import 'package:flutter/material.dart';
import 'package:super_simple_hero_animation/detail_page.dart';

class HomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(title: Text("Super Simple Hero Animation")),
 body: ListView.builder(itemBuilder: (context, index) {
 return ListTile(
 leading: CircleAvatar(
 child: ClipOval(
 child: Hero(
 tag: "avatar-$index",
 child: Image.network("https://picsum.photos/seed/$index/800"),
 ),
 ),
 ),
 title: Text("Item #$index"),
 onTap: () => _openDetail(context, index),
 );
 }),
 );
 }

 _openDetail(context, index) {
 final route = MaterialPageRoute(
 builder: (context) => DetailPage(index: index),
 );
 Navigator.push(context, route);
 }
}

Lines 7 - 8: We wrap everything in a Scaffold widget and add an AppBar with a title.
Line 9: To create a ListView, we use the builder factory method and simply create an infinite list.
Lines 10 - 12: As the leading element of our ListTile, we use the CircleAvatar widget. It takes care of the size and the padding of our image. The ClipOval widgets makes sure our image is circular.
Lines 13 - 16: To create a hero animation, we simply need to wrap our image into a Hero widget. It must have a unique tag. The exact tag also needs to be used again in our next step when creating the detail view.
Within the Hero widget, we load a network image from picsum.photos. Using /seed/$index makes sure we always get the same image depending on our list index.
Lines 19 - 20: We add a title to each element and install a listener to react on tab events.
Lines 26 - 31: When a tile is tapped, we navigate to the DetailPage and pass the index of the tapped tile as an argument.

Hero Animation Part 2: The Detail Page

The detail_page.dart contains our DetailPage widget. It will only consist of a large SliverAppBar showing an image.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


import 'package:flutter/material.dart';

class DetailPage extends StatelessWidget {
 final int index;

 const DetailPage({this.index});

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 body: CustomScrollView(
 slivers: <Widget>[
 SliverAppBar(
 expandedHeight: 300,
 flexibleSpace: FlexibleSpaceBar(
 title: Text("Item #$index"),
 background: Hero(
 tag: "avatar-$index",
 child: Image.network(
 "https://picsum.photos/seed/$index/800",
 fit: BoxFit.cover,
 ),
 ),
 ),
 ),
 ],
 ),
 );
 }
}

Line 4: To be able to construct the correct hero tag and to load the same image as in the ListTile, we need to know the unique index of the tapped tile.
Lines 10 - 14: Again, we wrap everything in a Scaffold and set a CustomScrollView as the body widget. The CustomScrollView allows us to add a SliverAppBar which – in contrast to a normal AppBar – allows us to specify a certain height.
Lines 15 - 16: We use a FlexibleSpaceBar to set a title and a background image to our SliverAppBar.
Lines 17 - 23: The most important part is that our background image is again wrapped in a Hero widget with the same tag as the tapped list element. If this is the case, Flutter takes care of the animation. Pretty cool, ha?
For the Image we use the same URL that we have used before. In this case, the Image is already cached and will load quickly. We use BoxFit.cover to tell the Image to cover all the available space.

When we now run the app, we have a cool little animation when navigating between our master and detail page. And that without having to write any complicated animation code.

Conclusion

Creating simple animations in Flutter is simple. Including them in your app can make it look smoother and more appealing in no time. Now that you know how to use the Hero widget, there is no excuse for boring looking apps anymore ;)

Simple Responsive Master-Detail View in Flutter with BLoC

Wed, 27 May 2020 00:00:00 +0000

I have a confession to make. Most of the time when developing apps, I did not think about supporting tablets. I did not bother thinking about how to structure my app that it also can be used on a larger screen.

Mostly, the reason I did not add tablet support to my apps was because I thought it would take me far more time to implement. I won’t say that supporting multiple screens won’t require more work, but it is also simpler than you think.

In this tutorial, I want to demonstrate how to create a simple responsive master-detail view application in Flutter. The app will contain a list of items, each of them can be clicked to show more detail.

You can also checkout the complete project from github.

Prerequisite

Like in my other tutorials about creating a splash screen and using Sembast as your data storage solution, we start this tutorial by creating a new Flutter project and cleaning up all the comments from pubspec.yaml and main.dart.

We let our main.dart file be for this moment and start by adding the required dependencies to our pubspec.yaml.

pubspec.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


name: master_detail
description: Responsive Master/Detail
publish_to: 'none'
version: 1.0.0+1

environment:
 sdk: ">=2.7.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter
 equatable: ^1.1.1
 flutter_bloc: ^4.0.0

flutter:
 uses-material-design: true

This should look familiar to you. The only thing I added here are the dependencies to equatable and flutter_bloc.

Equatable will help us to compare objects by its values rather than by reference, and flutter_bloc will provide us with the framework we use for state management.

A simple data class

First, we need a class containing the data we want to show in the app. We keep this to an absolute minimum and create a class Item under a new directory data that has two attributes: name and detail.

data/item.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import 'package:equatable/equatable.dart';

class Item extends Equatable {
 final String name;
 final String detail;

 Item(this.name, this.detail);

 factory Item.fromItem(Item item){
 if (item == null) {
 return null;
 } else {
 return Item(item.name, item.detail);
 }
 }

 @override
 List<Object> get props => [name, detail];
}

Lines 9 - 15 define a copy constructor that does nothing else than creating a new instance of Item with the same attribute values as the instance passed via the parameter.

Line 18 overrides the props getter that is required since Item extends Equatable. All elements of the list returned as props are used when comparing instances of Item.

The Logic using the Bloc Pattern

We are using the BLoC (business logic component) pattern in this example. We already included flutter_bloc in the pubspec.yaml before. To generate the boilerplate code, I use the Bloc Code Generator in Android Studio. This reduces the amount of code I have to write, but it is not required to use this plugin.

First, create a new directory and call it bloc. In Android Studio, right-click on the directory → New → Bloc Generator → New Bloc and enter “master_detail” as the name. Check “Do you want to use equatable” and click on ok. This will generate 4 files: bloc.dart, master_detail_event.dart, master_detail_state.dart, and master_detail_bloc.dart.

bloc/bloc.dart

1
2
3


export 'master_detail_bloc.dart';
export 'master_detail_event.dart';
export 'master_detail_state.dart';

This file simply allows importing these three files using one import statement: If you import bloc.dart, these files listed here are imported.

bloc/master_detail_event.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


import 'package:equatable/equatable.dart';
import 'package:master_detail/data/item.dart';

abstract class MasterDetailEvent extends Equatable {
 const MasterDetailEvent();
}

class LoadItemsEvent extends MasterDetailEvent {
 @override
 List<Object> get props => [];
}

class AddItemEvent extends MasterDetailEvent {
 final Item element;

 AddItemEvent(this.element);

 @override
 List<Object> get props => [element];
}

class SelectItemEvent extends MasterDetailEvent {
 final Item selected;

 SelectItemEvent(this.selected);

 @override
 List<Object> get props => [selected];
}

In this file, we create three Events that can be sent to our bloc to request a state change. All three Events extend our abstract class MasterDetailEvent and we again use Equatable for comparison.

The LoadItemsEvent notifies the bloc to load all existing items. AddItemEvent requests to add a new item specified by the event’s attribute element. SelectItemEvent will be used to notify the bloc that an Item has been selected in the list.

bloc/master_detail_state.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


import 'package:equatable/equatable.dart';
import 'package:master_detail/data/item.dart';

abstract class MasterDetailState extends Equatable {
 const MasterDetailState();
}

class LoadingItemsState extends MasterDetailState {
 @override
 List<Object> get props => [];
}

class NoItemsState extends MasterDetailState {
 @override
 List<Object> get props => [];
}

class LoadedItemsState extends MasterDetailState {
 final List<Item> elements;
 final Item selectedElement;

 LoadedItemsState(this.elements, this.selectedElement);

 @override
 List<Object> get props => [selectedElement, ...elements];
}

Where an event is the input to our bloc, a state is what our bloc will give us in return. For this example, our app will have 3 different states: LoadingItemsState, NoItemsState and LoadedItemsState.

Depending on the state, we will display different UI elements in our app. Where LoadingItemsState and NoItemsState do not contain any additional information, the LoadedItemsState holds a list of Items and the currently selected Item.

bloc/master_detail_bloc.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


import 'dart:async';

import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:master_detail/data/item.dart';

import 'bloc.dart';

class MasterDetailBloc extends Bloc<MasterDetailEvent, MasterDetailState> {
 List<Item> _items = [];
 Item _selected;

 @override
 MasterDetailState get initialState => LoadingItemsState();

 @override
 Stream<MasterDetailState> mapEventToState(MasterDetailEvent event,) async* {
 if (event is AddItemEvent) {
 _items.add(event.element);
 } else if (event is SelectItemEvent) {
 _selected = event.selected;
 }
 yield* _loadItems();
 }

 Stream<MasterDetailState> _loadItems() async* {
 if (_items.isEmpty) {
 yield NoItemsState();
 } else {
 final newState = LoadedItemsState([..._items], Item.fromItem(_selected));
 yield newState;
 }
 }
}

This class is the heart of our business logic. For simplicity, we do not use any kind of database in this example, but we are going to store the list of items and the selected item as attributes of the bloc (lines 9 & 10).

If you want to know how to use a real database storage for your app, have a look at my tutorial “Sembast as local data storage in Flutter”. Let me know in the comments if you would like another tutorial about Sembast, using the bloc pattern instead of Flutter’s default state management.

Let’s have a look at the mapEventToState function. Here we receive all events that are sent to our block. The aim of the function is to figure out which state the app should have depending on the received events.

First, we check if the event is an AddItemEvent. In this case, we add the received item (passed through the event as a parameter) to our list. Second, we check if the event is a SelectItemEvent. If this is the case, we assign the selected element to our variable.

After handling any of the events, we call the _loadItems function. All it does is to create a new state depending on if there are no items (NoItemsState) or there are some items stored in the bloc (LoadedItemsState).

Note that we do not explicitly handle the LoadItemsEvent. Since _loadItems is called regardless of which event we receive, we do not need any other functionality to be executed when a LoadItemsEvent is received.

The responsive Master-Detail UI

Finally, we are going to build the UI for our application. For the UI files, create a new directory called ui. First, we have a look at the files master.dart and detail.dart.

ui/master.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:master_detail/bloc/bloc.dart';
import 'package:master_detail/data/item.dart';
import 'package:master_detail/ui/detail.dart';

class Master extends StatefulWidget {
 @override
 _MasterState createState() => _MasterState();
}

class _MasterState extends State<Master> {
 int elementCount = 0;
 MasterDetailBloc _bloc;

 @override
 void initState() {
 super.initState();
 _bloc = BlocProvider.of(context);
 _bloc.add(LoadItemsEvent());
 }

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text("Master"),
 actions: <Widget>[
 IconButton(icon: Icon(Icons.add), onPressed: _addItem)
 ],
 ),
 backgroundColor: Color(0xffefefef),
 body: BlocBuilder(
 bloc: _bloc,
 builder: (context, state) {
 if (state is LoadingItemsState) {
 return Center(child: CircularProgressIndicator());
 } else if (state is NoItemsState) {
 return Center(child: Text("No Items"));
 } else if (state is LoadedItemsState) {
 return ListView.builder(
 itemCount: state.elements.length,
 itemBuilder: (context, index) {
 final item = state.elements[index];
 return ListTile(
 title: Text(item.name),
 selected: item == state.selectedElement,
 onTap: () => _selectItem(context, item),
 );
 },
 );
 }
 throw Exception("unexpected state $state");
 },
 ),
 );
 }

 _addItem() {
 final newItem = Item(
 "name $elementCount",
 "This is the detail for element $elementCount",
 );
 _bloc.add(AddItemEvent(newItem));
 elementCount++;
 }

 _selectItem(BuildContext context, Item item) {
 _bloc.add(SelectItemEvent(item));
 if (MediaQuery
 .of(context)
 .size
 .shortestSide < 768) {
 final route = MaterialPageRoute(builder: (context) => Detail());
 Navigator.push(context, route);
 }
 }
}

If you have worked with bloc before, this should look familiar. We have a stateful widget Master here. In its state we retrieve the MasterDetailBloc we have created earlier (line 19) and use it in a BlocBuilder to create the UI depending on its state.

What is interesting here – from the perspective of building a responsive app – is line 70: Here we check if the screen is smaller than 768 (which we will then classify as a smartphone). When selecting an item on a small screen size like this, we need to navigate to a different view to show the detailed information about the item. For a tablet, this is not necessary, since we have plenty of space to show this information right next to the Master list.

ui/detail.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:master_detail/bloc/bloc.dart';

class Detail extends StatefulWidget {
 @override
 _DetailState createState() => _DetailState();
}

class _DetailState extends State<Detail> {
 MasterDetailBloc _bloc;

 @override
 void initState() {
 super.initState();
 _bloc = BlocProvider.of<MasterDetailBloc>(context);
 }

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text("Detail"),
 ),
 body: BlocBuilder(
 bloc: _bloc,
 builder: (context, state) {
 if (state is LoadedItemsState) {
 return Center(
 child: Text(state.selectedElement?.detail ?? "No item selected"),
 );
 } else {
 return Container();
 }
 },
 ),
 );
 }
}

The Detail widget looks very similar to the Master widget. It also retrieves the MasterDetailBloc and uses BlocBuilder to build a state-dependent UI. Here, we use the LoadedItemsState’s selectedElement attribute to get the detailed information to display.

ui/home_page.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


import 'package:flutter/material.dart';
import 'package:master_detail/ui/detail.dart';
import 'package:master_detail/ui/master.dart';

class HomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return LayoutBuilder(
 builder: (context, constraints) {
 if (constraints.maxWidth > 768) {
 return _TabletHomePage();
 } else {
 return _MobileHomePage();
 }
 },
 );
 }
}

class _MobileHomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Master();
 }
}

class _TabletHomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Row(
 children: <Widget>[
 Container(width: 300, child: Master()),
 Expanded(child: Detail())
 ],
 );
 }
}

For our main screen (HomePage) we use a LayoutBuilder to decide if we want to display the tablet or the mobile version of our screen. As in the master.dart file, we set our breakpoint to 768 pixels to decide whether the device is a tablet.

For the mobile version of the HomePage (_MobileHomePage) we only display the Master widget. For the tablet version ( _TabletHomePage) we show both: Master and Detail. We limit the width of the Master widget to 300px and let the Detail take the rest of the space.

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:master_detail/bloc/bloc.dart';
import 'package:master_detail/ui/home_page.dart';

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

class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return BlocProvider(
 create: (context) => MasterDetailBloc(),
 child: MaterialApp(home: HomePage()),
 );
 }
}

Finally, all that is left is to adapt the main.dart file to run our application. We use BlocProvider to make our MasterDetailBloc available throughout the widget tree and create a very basic MaterialApp showing our HomePage.

Now when we run the app on a smartphone the app uses two separate views to display the master (overview) widget and the detail widget. On a tablet we are making use of the additional screen space to display both widgets next to each other.

Summary

In this tutorial, we had a look at how to create a responsive master-detail view app in Flutter. By using the bloc pattern, it is easy to have independent widgets reacting on a common state of the app.

As mentioned before, you can find the complete project on github.

I hope this tutorial helps you to make your Flutter apps also available for larger screens without putting too much additional effort in the development process.

Sembast as local data storage in Flutter

Wed, 13 May 2020 00:00:00 +0000

Almost every app needs to store data locally on the user’s device. One option would be using SQLite, but with Flutter, I prefer the Sembast library. Sembast is a NoSQL database which allows storing data in a JSON format.

In this tutorial, I will show you how to use Sembast as your local data storage in your Flutter app. I will not only show you how it can be used, but also how to integrate it in your app architecture.

As an example, we will create a simple app to store a list of our favorite cakes. Everyone loves cakes, right? 🎂

The complete source code of this tutorial is available on Github: https://github.com/stefangaller/flutter_sembast_local_data_storage

This tutorial shows how to use Sembast using the BLoC pattern. I have also created a tutorial for Riverpod: Tutorial: Using Sembast with Riverpod.

Prerequisite

As with my last tutorial “Simple Flutter app initialization with Splash Screen using FutureBuilder” we will start by creating a new Flutter project and cleaning up the boilerplate code. I will name the project it sembast_tutorial.

The pubspec.yaml and the main.dart file should look like this:

pubspec.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


name: sembast_tutorial
description: A simple Sembast tutorial

publish_to: 'none' # Remove this line if you wish to publish to pub.dev
version: 1.0.0+1

environment:
 sdk: ">=2.7.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter

dev_dependencies:
 flutter_test:
 sdk: flutter

flutter:
 uses-material-design: true

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


import 'package:flutter/material.dart';

void main() => runApp(CakeApp());

class CakeApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 title: 'My Favorite Cakes',
 home: HomePage(),
 );
 }
}

class HomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text("My Favorite Cakes"),
 ),
 );
 }
}

The “Cake” Entity

First, we create a new file called cake.dart. This file will contain our data class Cake. This entity will have an id, a name, and a yummyness factor.

cake.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


class Cake {
 final int id;
 final String name;
 final int yummyness;

 Cake({this.id, this.name, this.yummyness});

 Map<String, dynamic> toMap() {
 return {
 'name': this.name,
 'yummyness': this.yummyness
 };
 }

 factory Cake.fromMap(int id, Map<String, dynamic> map) {
 return Cake(
 id: id,
 name: map['name'],
 yummyness: map['yummyness'],
 );
 }

 Cake copyWith({int id, String name, int yummyness}){
 return Cake(
 id: id ?? this.id,
 name: name ?? this.name,
 yummyness: yummyness ?? this.yummyness,
 );
 }
}

Let’s see what this code does in more detail:

Lines 2-6: Here we specify all our attributes and create a default constructor for all attributes in line 6.
Lines 8-13: The toMap function is used to convert our data into a Map so we can later store it into our Sembast database. We don’t need to add the id into the map here.
Lines 15-21: When reading the data from Sembast we will receive it as a Map. The fromMap factory constructor allows us to create a Cake instance from an id and this Map.
Lines 23-30: It is common practice in Dart to use immutable data objects (notice the final keyword used for our attributes in lines 2-4). If we want to change an attribute we will create a copy of the object but with the desired attribute using the copyWith function.

For reducing complexity of this tutorial, we do not use any external libraries for generating the code used in our data model. If you want to avoid writing the toMap, fromMap and copyWith functions yourself, you can use libraries like freezed and json_serializable to generate these functions.

Initialization: open the Sembast database

For this step will first add Sembast, GetIt and path_provider to our project. Sembast will be used as our database implementation and GetIt to make this database available throughout our app. The path_provider library is used to retrieve the application directory on the device. This directory will be home of our database.

To add the libraries, we specify them as dependencies in pubspec.yaml. The dependencies section should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


...

dependencies:
 flutter:
 sdk: flutter
 sembast: ^2.4.3
 get_it: ^4.0.2
 path_provider: ^1.6.7

...

Don’t forget to run flutter pub get to download the dependencies.

For the app initialization, we will use a similar approach we have used in the tutorial “Simple Flutter app initialization with Splash Screen using FutureBuilder”. Therefore, we will continue by creating a file called init.dart.

init.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import 'package:get_it/get_it.dart';
import 'package:path_provider/path_provider.dart';
import 'package:path/path.dart';
import 'package:sembast/sembast.dart';
import 'package:sembast/sembast_io.dart';

class Init {
 static Future initialize() async {
 await _initSembast();
 }

 static Future _initSembast() async {
 final appDir = await getApplicationDocumentsDirectory();
 await appDir.create(recursive: true);
 final databasePath = join(appDir.path, "sembast.db");
 final database = await databaseFactoryIo.openDatabase(databasePath);
 GetIt.I.registerSingleton<Database>(database);
 }
}

The interesting part is the _initSembast function.

Lines 13 and 14 retrieve the application document directory of the app and creates it if necessary.
Line 15 builds the path for our database file. Make sure to import path.dart to have access to the join function.
In line 16 we use the Sembast databaseFactoryIo to open the database.
Line 17 registers the database to GetIt. This allows us to access our database instance as a singleton from anywhere in the app.

Cake Repository: Providing access to the database

In the next step, we will create a repository to store and receive our Cake instances to and from the Sembast database. It is good practice to define an abstract class to define the interface of your repository. Using this approach, you can later simply exchange your database implementation for another one easily.

cake_repository.dart

In this file, we just define an abstract class CakeRepository with two functions insertCake and getAllCakes that we will implement using Sembast.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import 'cake.dart';

abstract class CakeRepository {

 Future<int> insertCake(Cake cake);

 Future updateCake(Cake cake);

 Future deleteCake(int cakeId);

 Future<List<Cake>> getAllCakes();
}

sembast_cake_repository.dart

The implementation isn’t complicated either:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import 'package:get_it/get_it.dart';
import 'package:sembast/sembast.dart';
import 'package:sembast_tutorial/cake.dart';
import 'package:sembast_tutorial/cake_repository.dart';

class SembastCakeRepository extends CakeRepository {
 final Database _database = GetIt.I.get();
 final StoreRef _store = intMapStoreFactory.store("cake_store");

 @override
 Future<int> insertCake(Cake cake) async {
 return await _store.add(_database, cake.toMap());
 }

 @override
 Future updateCake(Cake cake) async {
 await _store.record(cake.id).update(_database, cake.toMap());
 }

 @override
 Future deleteCake(int cakeId) async{
 await _store.record(cakeId).delete(_database);
 }

 @override
 Future<List<Cake>> getAllCakes() async {
 final snapshots = await _store.find(_database);
 return snapshots
 .map((snapshot) => Cake.fromMap(snapshot.key, snapshot.value))
 .toList(growable: false);
 }
}

Line 6: We create a new class SembastCakeRepository extending our abstract CakeRepository. We could later also create something like a SQLiteCakeRepository or a FirebaseCakeRepository. This way we stay flexible.
Line 7: Here we use GetIt to retrieve the Database instance that we registered earlier.
Line 8: With Sembast we have multiple stores in one database. Here, we create a reference to our store with the name cake_store. Don’t worry, we don’t need to create the store ourselves. Sembast makes sure we can write to the store.
Lines 11 - 13: This is all it takes to add a new Cake to the store. The add function requires a reference of the database and the data in form of a map. We can use our toMap function here, we created earier. The function returns the key of the newly created entry.
Lines 16 - 18: with _store.record we can directly access a database record by its ID. We will use this here to explicitly update this record with the new data.
Line 21 - 23: Very similar to updating a record is deleting one. Again we fetch the record with _store.record and then call the delete function.
Lines 26 - 31: This function returns a list of all cakes in the store. Line 27 executes the query to retreive all cakes from the store. We then need to convert the Map retreived from the store to a Cake object again. Lukily we have created the fromMap factory before. Don’t forget to convert the result to a List before returning. Forgetting this call will lead to error, which is hard to debug.

init.dart

Finally, all that is left is to register our SembastCakeRepository to GetIt. Therefore, we will edit our init.dart file. We create a new function _registerRepositories where we do the registration, and we call this function in the initialize function. The code should look like this:

1
2
3
4
5
6
7
8


 static Future initialize() async {
 await _initSembast();
 _registerRepositories();
 }

 static _registerRepositories(){
 GetIt.I.registerLazySingleton<CakeRepository>(() => SembastCakeRepository());
 }

Note that in line 7 we use CakeRepository as the generic type, but register a SembastCakeRepository. Later you could register a different implementation of CakeRepository here.

Putting it all together: The User Interface

Finally, we are going to connect our code and put it to use. First, we need to clean up a little. We will move the HomePage class to a separate file and convert the CakeApp class to a StatefulWidget. Also, we are going to add our initialization logic to the main.dart file.

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


import 'package:flutter/material.dart';
import 'package:sembast_tutorial/home_page.dart';
import 'package:sembast_tutorial/init.dart';

void main() => runApp(CakeApp());

class CakeApp extends StatefulWidget {
 @override
 _CakeAppState createState() => _CakeAppState();
}

class _CakeAppState extends State<CakeApp> {
 final Future _init = Init.initialize();

 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 title: 'My Favorite Cakes',
 home: FutureBuilder(
 future: _init,
 builder: (context, snapshot){
 if (snapshot.connectionState == ConnectionState.done){
 return HomePage();
 } else {
 return Material(
 child: Center(
 child: CircularProgressIndicator(),
 ),
 );
 }
 },
 ),
 );
 }
}

As you can see, this file still looks very similar to what we created in this tutorial. The only difference here is that we used a StatefulWidget. This is necessary, since some of the Sembast code is required to run after the runApp function (line 5) and this way it does.

home_page.dart

This is the heart of our app. On our HomePage we are going to display a list of our Cakes and allow them to be added, edited and deleted.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


import 'dart:math';

import 'package:flutter/material.dart';
import 'package:get_it/get_it.dart';
import 'package:sembast_tutorial/cake.dart';
import 'package:sembast_tutorial/cake_repository.dart';

class HomePage extends StatefulWidget {
 @override
 _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
 CakeRepository _cakeRepository = GetIt.I.get();
 List<Cake> _cakes = [];

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

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text("My Favorite Cakes"),
 ),
 body: ListView.builder(
 itemCount: _cakes.length,
 itemBuilder: (context, index) {
 final cake = _cakes[index];
 return ListTile(
 title: Text(cake.name),
 subtitle: Text("Yummyness: ${cake.yummyness}"),
 trailing: IconButton(
 icon: Icon(Icons.delete),
 onPressed: () => _deleteCake(cake),
 ),
 leading: IconButton(
 icon: Icon(Icons.thumb_up),
 onPressed: () => _editCake(cake),
 ),
 );
 },
 ),
 floatingActionButton: FloatingActionButton(
 child: Icon(Icons.add),
 onPressed: _addCake,
 ),
 );
 }

 _loadCakes() async {
 final cakes = await _cakeRepository.getAllCakes();
 setState(() => _cakes = cakes);
 }

 _addCake() async {
 final list = ["apple", "orange", "chocolate"]..shuffle();
 final name = "My yummy ${list.first} cake";
 final yummyness = Random().nextInt(10);
 final newCake = Cake(name: name, yummyness: yummyness);
 await _cakeRepository.insertCake(newCake);
 _loadCakes();
 }

 _deleteCake(Cake cake) async {
 await _cakeRepository.deleteCake(cake.id);
 _loadCakes();
 }

 _editCake(Cake cake) async {
 final updatedCake = cake.copyWith(yummyness: cake.yummyness + 1);
 await _cakeRepository.updateCake(updatedCake);
 _loadCakes();
 }
}

I will assume here that you already know how to build UIs in Flutter and won’t explain what is happening in the build function.

Line 14: Since we have registered our CakeRepsitory to GetIt we are able to retrieve and use it here.
Line 15: Our state contains a list of all our Cakes. We use Flutter’s state management to update this list.
Lines 54 - 57: Here we simply call our repository to fetch all cakes from the database. After this has completed, we use Flutter’s setState function to update the list items and trigger a redraw of the list.
Lines 59 - 66: The first 3 lines simply generate a name and a yummyness randomly. With these values, we create a new Cake instance and call the insertCake function on our CakeRepository to insert the Cake. After this, we reload our list by calling _loadCakes().
Lines 68 - 71: Deleting a Cake is even simpler. Again, we use our CakeRepository and reload the list afterwards.
Lines 73 - 77: Here we want to increase the yummyness of the Cake. We make use of the copyWith function to add 1 to the current yummyness. Again, we use the CakeRepository to update and reload the list.

And that’s it! 🎉

Let’s start the app and see what we have accomplished. It allows you to do add, edit, and delete objects using a Sembast database. Most importantly, you also see how an architecture looks like for integrating Sembast into your app.

Summary

We have created a simple app with a local storage using Sembast. First, we have set up a data Entity to store. We needed to create some functions for converting to and from a map there.

Next, we initialized our Sembast database and made it available in the app with GetIt. Using the database, we have implemented a repository allowing us to read and write to the Sembast database.

Finally, in the last step, we added a user interface to add, edit and remove cakes and display them in a list.

I hope you enjoyed to the tutorial, and it gave you an idea on how to integrate Sembast as a local database to your app.

Simple Flutter app initialization with Splash Screen using FutureBuilder

Thu, 07 May 2020 00:00:00 +0000

Most of the apps do run some kind of initialization code when the app starts. Doing this in a **synchronous/blocking ** manner makes your app look frozen for the duration of this process. A better solution is to initialize your app in the background and show the user a splash screen in the meanwhile.

In this blog entry I’m going to give you a step-by-step guide on how to initialize your Flutter app and show a splash screen using FutureBuilder.

Prerequisite

Before we start we will need to set up a new Flutter project. If you are new to Flutter I recommend that you follow the steps of the official tutorial first.

Use the IDE/editor of your choice to start a new Flutter project. Let’s name the project initialization. First get rid of all the boilerplate code. I usually start my apps with pubspec.yaml and main.dart looking like this:

pubspec.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


name: initialization
description: Initialization with Splash Screen
version: 1.0.0+1

environment:
 sdk: ">=2.1.0 <3.0.0"

dependencies:
 flutter:
 sdk: flutter

dev_dependencies:
 flutter_test:
 sdk: flutter

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import 'package:flutter/material.dart';

void main() => runApp(InitializationApp());

class InitializationApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 title: 'Initialization',
 home: HomePage(),
 );
 }
}


class HomePage extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: Text("Initialization"),
 ),
 );
 }
}

The Initialization Logic

Now that we have set up the basis of the app it is time to do create a place where we want to do the initialization of our app. Therefore I will create a new file and name it init.dart. Of course I could also do the initialization within the main.dart file, but as your app grows the number of lines in your initialization logic can get quite bulky.

init.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class Init {
 static Future initialize() async {
 await _registerServices();
 await _loadSettings();
 }

 static _registerServices() async {
 //TODO register services
 }

 static _loadSettings() async {
 //TODO load settings
 }
}

The Init class contains one static public function initialize which we will later call in the main.dart file to start the initialization.

Note the async keyword in the function declaration. Many initialization routines are built to run asynchronously. To being able to wait for those to finish we use the await keyword. This requires our initialize function to also be in an async context. Async functions implicitly return a Future. A Future can be seen as an object that contains information about the state of an async function.

A more detailed guide on the async-await can be found on the official dart website.

The Init class also contains two private functions (inicated by the leading underscore): _registerServices and _loadSettings. These are examples of how you could strucuture your initialization process in order to keep your code easy to read.

To keep this example simple, we won’t do any real initialization here. Anyways, to simulate heavy initialilzation going on in our app we can add a delay to our initialization functions using Future.delayed.

The two functions now should look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


static _registerServices() async {
 print("starting registering services");
 await Future.delayed(Duration(seconds: 1));
 print("finished registering services");
}

static _loadSettings() async {
 print("starting loading settings");
 await Future.delayed(Duration(seconds: 1));
 print("finished loading settings");
}

The Splash Screen

Now that we have some initialization logic for our app startup, we create a splash screen that can be displayed while the initialization takes place. For a proper project strucuture we will create a new file and name it splash_screen.dart.

splash_screen.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


import 'package:flutter/material.dart';

class SplashScreen extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 return Material(
 child: Column(
 mainAxisAlignment: MainAxisAlignment.center,
 children: <Widget>[
 Text(
 "Initialization",
 style: TextStyle(
 fontSize: 32,
 fontWeight: FontWeight.bold,
 ),
 ),
 SizedBox(height: 20),
 CircularProgressIndicator()
 ],
 ),
 );
 }
}

Let’s go through the lines in this file in more detail.

Line 3: SplashScreen extends StatelessWidget. We do not need to handle any state in this widget, only show a static splash screen page, so StatelessWidget is best suited for our purpose.
Line 6: We wrap everything in a Material widget. This makes sure that the default text style is properly set.
Line 7 & 8: To organize the Text and the CircularProgressIndicator we use the Column Widget. To center the children of the Column vertically we set the mainAxisAlignment to MainAxisAlignment.center.
Line 10 - 18: Add a Text with some custom style. To make sure there is a bit of space between the Text and the CircularProgressIndicator we add a SizedBox with a height of 20px between the two widgets.

And that’s it: A really simple splash screen. Of course, you can be creative here and create something more beautiful :) Leave a comment below this post with your recommendation how you think a splash screen should look like. Let’s put it all together in the next step.

Putting it together: Show the Splash Screen during Initialization

Now we move back to main.dart to wire up all the parts we have implemented before. We will use a FutureBuilder to monitor the state of our initialization logic and show our SplashScreen while the initialization is still in progress.

main.dart

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


...

class InitializationApp extends StatelessWidget {

final Future _initFuture = Init.initialize();

@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Initialization',
home: FutureBuilder(
future: _initFuture,
builder: (context, snapshot){
if (snapshot.connectionState == ConnectionState.done){
return HomePage();
} else {
return SplashScreen();
}
},
),
);
}
}

...

Let’s see what we did here:

Line 5: Here we call our initialize function. Since it’s an async function it will run in the background and won’t stop the rest of the app from executing. The Future returned by initialize is stored in a private variable ( note the _ ) so we can use it with the FutureBuilder below.
Lines 11 & 12: Instead of directly assigning HomePage to the home attribute of our MaterialApp, we’ll put a FutureBuilder here. This widget will observe the Future provided by the future attribute and will rebuild once the state of the Future changes.
Lines 13 - 19: The builder attribute allows us to specify which widget should be displayed depending on our future’s state. As all builder functions in Flutter it provides a BuildContext. But what is more interesting here is the snapshot parameter. This parameter allows us to have a look at the state of our Future. To see whether it has completed running we will check its connectionState. The state that is the most interesting to us is ConnectionState.done. This state tells us that the Future has completed executing and the initialization has finished: time to display our HomePage. In any other cases we will display our SplashScreen.

And that’s it. When you start your app now, you will see a splash screen that is displayed while the initialization takes place. A look at the console during startup shows what part of the initialization has been executed. So if everything is initialized the console should display something like:

flutter: starting registering services
flutter: finished registering services
flutter: starting loading settings
flutter: finished loading settings

It might also make sense to handle errors that can occur during your initialization process. You can use snapshot.hasError in your build function to check if there has been an error.

Summary

Using FutureBuilder it is really simple to show a splash screen during your apps startup initialization. All you need is an initialization function that is able to run asynchronously and have a FutureBuilder reacting to the state of your initialization code.

Posts on bettercoding.dev

Drift – Using an SQLite Database with Flutter

Prerequisites

The CakeTable

Creating a Database

Implementing CakeRepsoitory with drift

Summary

Using Isar as a Reactive Database for Flutter

The Cake App revisited

What is a reactive database?

Using isar as a reactive local storage

Prerequisites

Initializing Isar

The Cake Model

The CakeRepository with isar

Summary

Riverpod: How to initialize a SYNC Provider with an ASYNC Value?

Showing the version of your app

Example

main.dart

global_providers.dart

version_page.dart

Summary

JWT Authentication in Flutter – Tutorial & Follow-Along

What is JWT authentication?

JWT refresh tokens

Prerequisites

The test server

Implementing AuthController

build

login

refreshToken

logout

Implementing AuthInterceptor

Adding Interceptors

Adding the Authorization header

Implement Token Refresh

Try the token refresh

Summary

A Simple Flutter Architecture for accessing REST APIs

Architecture

Required Packages

The User Model

The Repository Layer

The UserRepository interface

The MockUserRepository

The UserController

The UI

API connection using retrofit

The API response

The UserApiClient

The UserApiRepository

Take away

Consistent Spacing – Improve your Flutter App with this Package

How not to do spacings

Set up

Define the spaces

Apply the generated spacings

Take away

10 Flutter Packages You Must Know In 2022

My 10 Favorite Packages

1. Beamer

2. Flutter Flavorizr

3. Flutter Launcher Icons

4. Shimmer

5. Riverpod

6. Charts Flutter

7. In App Review

8. Freezed

9. JSON Serializable

10. Retrofit

Conclusion

Using Sembast with Riverpod

Prerequisite

The Cake Model

The Cake Repository

The Cake Page

home_state.dart

home_controller.dart

home_page.dart

The `CakeTable`

Implementing `CakeRepsoitory` with `drift`

Using `isar` as a reactive local storage

The `CakeRepository` with `isar`

`main.dart`

`global_providers.dart`

`version_page.dart`

Implementing `AuthController`

`build`

`login`

`refreshToken`

`logout`

Implementing `AuthInterceptor`

Adding the `Authorization` header

The `User` Model

The `UserRepository` interface

The `MockUserRepository`

The `UserController`

API connection using `retrofit`

The `UserApiClient`

The `UserApiRepository`

2.) Clean up `pubspec.yaml`

3.) Clean up `main.dart`

Viewing Camera Input using the `camera` Plugin

Initializing the `CameraController`