Andrea Bizzotto

Case Study: Automating UI/Integration Tests with Flutter Driver and Codemagic

Wed, 30 Oct 2019 03:00:18 +0000

Written by: Andrea Bizzotto of Coding With Flutter

Unit tests and widget tests are a great way of testing classes, functions and widgets in isolation. However, it is just as important to test that all these moving parts work together as a whole.

And when dealing with complex apps with many screens, it is hard and error-prone to manually test multiple user journeys.

Integration tests help us automate this process, and we can use them to test our Flutter apps on a real device or emulator.

So in this article, we will learn how to write integration tests using Flutter driver, and see how they differ from widget tests.

And we will use them to test a user journey for an existing open source app built with Flutter & Firebase.

Finally, we will see how to run them with Codemagic, either on an emulator, or a real device powered by the AWS Device Farm.

Application overview

We will use this open source app as an example:

Reference Authentication Flow with Flutter & Firebase

This app shows how to use different sign-in methods to authenticate with Firebase. It already implements a sign-in and sign-out flow that is composed of four steps:

This flow is a good candidate for an automated integration test (UI test to be precise, more on this below).

So our goal is to write a test that can loop through the four steps above by interacting with the UI, and verify that the correct widgets are in place after every interaction.

And because integration tests run with Flutter driver, we will be able to see the app run on the simulator as the test executes:

Integration tests or UI tests?

Our application uses Firebase authentication to sign-in the user. And in general, you apps will be using various services to talk to the network or other external inputs (e.g. location updates).

So, should integration tests run with a real or mocked network service?

While there is value in testing the whole product end-to-end, there are also some risks:

you don’t want to pollute the production environment with network requests from test code.
testing with the real network service can be slow at best, and unreliable at worst.

So in my apps I always mock the network service. This gives me a more controlled environment where I can stub network calls, and even decide how long they should take to respond. This makes my tests more predictable and reliable.

Strictly speaking, this means that I’m writing UI tests. Because I’m mimicking the behaviour of real users, by simulating their interaction with the app via gestures. For clarity, I will stick with the term integration test for the rest of the article, as this is how they are called in Flutter.

With that said, let’s get back to our example.

Mocking the authentication service

In practice, we want to run an integration test for the entire app, so there needs to be a way to inject a mock authentication service at the top of the widget tree.

In my example project, I have accomplished this by defining this enum:

enum AuthServiceType { firebase, mock }

And when I create the Flutter app, I inject the desired AuthServiceType like so:

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

class MyApp extends StatelessWidget {
  // [initialAuthServiceType] is made configurable for testing
  const MyApp({this.initialAuthServiceType = AuthServiceType.firebase});
  final AuthServiceType initialAuthServiceType;

  @override
  Widget build(BuildContext context) {
    // top-level providers and MaterialApp here
    // create real or mock authentication service based on initialAuthServiceType.
  }
}

With this setup, the production app will always use the Firebase authentication service, while test code can use a mock service instead.

And in general, I recommend injecting all service classes at the top of the widget tree (above MaterialApp), so that it is easier to swap them out when configuring widget and integration tests.

With this in mind, we’re ready to add our integration tests.

Adding integration tests with Flutter Driver

According to the official documentation, integration tests require two steps:

deploy an instrumented application to a real device or emulator.
“drive” the application from a separate test suite, checking to make sure everything is correct along the way.

This is different to how widget tests are run, where we use a test environment that is much simpler (and faster) than a full-blown UI system.

NOTE: If you’re not familiar with integration tests, I recommend reading An introduction to integration testing from the Flutter documentation.

Step one is to add the flutter_driver package to the pubspec.yaml file:

dev_dependencies:
  flutter_driver:
    sdk: flutter 

And to create our integration tests, we can define a project-level folder with two files:

test_driver/
  app_test.dart
  app.dart

Inside the app.dart file, we can add the following:

// project-specific imports
import 'package:firebase_auth_demo_flutter/main.dart';
import 'package:firebase_auth_demo_flutter/services/auth_service_adapter.dart';
// flutter-specific imports
import 'package:flutter/material.dart';
import 'package:flutter_driver/driver_extension.dart';

void main() {
  // This line enables the extension.
  enableFlutterDriverExtension();

  // Call the `main()` function of the app, or call `runApp` with
  // any widget you are interested in testing.
  runApp(MyApp(initialAuthServiceType: AuthServiceType.mock));
}

Note how we’re passing AuthServiceType.mock when we create the MyApp widget.

Then we can start implementing the app_test.dart file, by adding the standard boilerplate code for the FlutterDriver:

// Imports the Flutter Driver API.
import 'package:flutter_driver/flutter_driver.dart';
import 'package:test/test.dart';

void main() {
  FlutterDriver driver;

  // Connect to the Flutter driver before running any tests.
  setUpAll(() async {
    driver = await FlutterDriver.connect();
  });

  // Close the connection to the driver after the tests have completed.
  tearDownAll(() async {
    if (driver != null) {
      driver.close();
    }
  });
}

After this, we can add a quick test to check the health status of our Flutter Driver extension. It’s a good idea to run this before any other tests.

test('check flutter driver health', () async {
  final health = await driver.checkHealth();
  expect(health.status, HealthStatus.ok);
});

Credit: Darshan Kawar, who wrote this good article about Testing Flutter UI with Flutter Driver.

Next, we can add a method that we will use to add a short delay between UI interactions. As we will see, this is used only for demo purposes:

Future<void> delay([int milliseconds = 250]) async {
  await Future<void>.delayed(Duration(milliseconds: milliseconds));
}

With this in place, we can start writing the first test:

test('sign in anonymously, sign out', () async {
  // 1. find and tap anonymous sign in button
  final anonymousSignInButton = find.byValueKey(Keys.anonymous);
  // 2. check to fail early if the auth state is authenticated
  await driver.waitFor(anonymousSignInButton);
  // 3. add small delay for demo recording
  await delay(750);
  // 4. interact with UI
  await driver.tap(anonymousSignInButton);
});

On step 1, we use the find object to get a handle to a widget by key.

Note: this is not the same finder used with widget tests, and the value passed to byValueKey needs to be a String, not a Key object.

In fact, things will break if we use this import in the integration tests:

import 'package:flutter_test/flutter_test.dart';

Instead, we should use only the symbols defined in the flutter_driver package:

import 'package:flutter_driver/flutter_driver.dart';

And since we’re referencing widgets by key, I defined a Keys class to avoid duplication and hard-coded strings across the production and test code:

class Keys {
  // list of widget keys that need to be accessed in the test code
  static const String anonymous = 'anonymous';
  static const String logout = 'logout';
  static const String alertDefault = 'alertDefault';
  static const String alertCancel = 'alertCancel';
}

Accordingly, in my sign-in page I will have a button, defined like this:

SignInButton(
  key: Key(Keys.anonymous),
  text: Strings.goAnonymous,
  color: Colors.lime[300],
  textColor: Colors.black87,
  onPressed: isLoading ? null : () => _signInAnonymously(context),
),

Let’s get back on track. Here’s our test once again:

test('sign in anonymously, sign out', () async {
  // 1. find and tap anonymous sign in button
  final anonymousSignInButton = find.byValueKey(Keys.anonymous);
  // 2. check to fail early if the auth state is authenticated
  await driver.waitFor(anonymousSignInButton);
  // 3. add small delay for demo recording
  await delay(750);
  // 4. interact with UI
  await driver.tap(anonymousSignInButton);
});

In step 2, we ask the driver to wait until we find the anonymous sign-in button. It is good practice to check this before any UI interaction takes place, to ensure that we’re in the initial sign-in page and we’re showing the correct buttons.

In fact, we should always keep in mind that the application state can change across tests. In other words, multiple integration tests are “sharing” the same application, and can introduce side effects if each test doesn’t return to the initial application state.

Step 3 adds a small delay, and step 4 dispatches a tap gesture to the button.

As a result, the (mock) authentication service is called, with a request to sign-in the user. All the mock service does is to wait for a short delay, and change its internal state to indicate that the user is signed-in. When this happens, the application updates itself and shows the home page:

All good so far, but our test implementation is not complete yet.

Next, we want to find and tap the logout button:

// find and tap logout button
final logoutButton = find.byValueKey(Keys.logout);
await driver.waitFor(logoutButton);
await delay(750); // for video capture
await driver.tap(logoutButton);

This works just like our previous code. We reference a button by key, and wait for the driver to find it. Once the home page is presented, all UI animations are complete, and we return from the first await call.

And once we have a logout button, we can tap on it.

In this specific flow, the app shows a dialog asking for logout confirmation:

And by now, we know how to deal with this:

// find and tap confirm logout button
final confirmLogoutButton = find.byValueKey(Keys.alertDefault);
await driver.waitFor(confirmLogoutButton);
await delay(750); // for video capture
await driver.tap(confirmLogoutButton);

After we tap on the logout confirmation button, another call is made to sign-out with the mock authentication service. In turn, this updates the authentication status.

Finally, we want to check that we’re back to the sign-in page. And we can complete our test with one final line:

// try to find anonymous sign in button again
await driver.waitFor(anonymousSignInButton);

All in all, this is the code for the entire test:

test('sign in anonymously, sign out', () async {
  // find and tap anonymous sign in button
  final anonymousSignInButton = find.byValueKey(Keys.anonymous);
  // Check to fail early if the auth state is authenticated
  await driver.waitFor(anonymousSignInButton);
  await delay(750); // for video capture
  await driver.tap(anonymousSignInButton);

  // find and tap logout button
  final logoutButton = find.byValueKey(Keys.logout);
  await driver.waitFor(logoutButton);
  await delay(750); // for video capture
  await driver.tap(logoutButton);

  // find and tap confirm logout button
  final confirmLogoutButton = find.byValueKey(Keys.alertDefault);
  await driver.waitFor(confirmLogoutButton);
  await delay(750); // for video capture
  await driver.tap(confirmLogoutButton);

  // try to find anonymous sign in button again
  await driver.waitFor(anonymousSignInButton);
});

The last thing to do is to run our integration test:

flutter drive --target=test_driver/app.dart

And then, we can sit back and relax as Flutter driver runs the test on our simulator (look, no hands 😀):

For reference, this is a stripped-out log of the output from Flutter driver:

Starting application: test_driver/app.dart
Running Xcode build...                                                  
                                                   
 ├─Assembling Flutter resources...                          10.8s
 └─Compiling, linking and signing...                        12.0s
Xcode build done.                                           27.0s
Configuring the default Firebase app...
flutter: Observatory listening on http://127.0.0.1:62531/q6q6Nbol1fU=/
Configured the default Firebase app __FIRAPP_DEFAULT.

[info ] FlutterDriver: Connecting to Flutter application at http://127.0.0.1:62531/q6q6Nbol1fU=/
[trace] FlutterDriver: Isolate found with number: 844330546624811
[trace] FlutterDriver: Isolate is paused at start.
[trace] FlutterDriver: Attempting to resume isolate
[trace] FlutterDriver: Waiting for service extension
[info ] FlutterDriver: Connected to Flutter application.
00:01 +0: check flutter driver health
00:01 +1: sign in anonymously, sign out
00:07 +2: (tearDownAll)
00:07 +2: All tests passed!
Stopping application instance.

Note how the test took 7 seconds to run. This would run faster if we removed the artificial delays. But it’s worth noting that running integration tests takes longer than widget and unit tests.

Still, we can now write integration tests that cover almost all the user flows in our app, which is great! 🚀

And our testers will be super-delighted, as they will no longer need to do this by hand. 🙏

Running on Codemagic

Having unit, widget and integration tests is good.

But it’s even better to run them automatically every time we open or update a pull request.

And this is where Codemagic comes in.

Codemagic offers a user-friendly UI that makes it easy to automate the testing and delivery of our apps.

And when it comes to testing, we can configure our builds to run Flutter tests (unit and widget) and Flutter Driver tests (integration):

Not only that, but we can choose to run on the iOS simulator, Android emulator, and even on a real device running on the AWS Device Farm.

And because end-users will be using your apps on real devices, running automated tests in this way is very important.

So for this project, I have setup an AWS account, and registered an AWS access key ID and AWS secret access key as outlined here.

And after configuring this on Codemagic, I ran my tests, and got the desired results for the integration tests in my build log:

Run 'sylph run 2019-10-22 01:09:31.259' completed 1 of 1 jobs.
  Result: PASSED
  Device minutes: 7.98 (5.57 metered).
  Counters:
    skipped: 0
    warned: 0
    failed: 0
    stopped: 0
    passed: 3
    errored: 0
    total: 3

Downloading artifacts...
Downloading artifacts to /tmp/sylph_artifacts/sylph_run_2019-10-22_01_09_31.259/test_concurrent_runs/android_pool_1/Google_Pixel_2-Google_Pixel_2-8.0.0
results=[{result: true}]
Concurrent runs completed.
Sylph run completed in 12m:32s:975ms.
Sylph run 'sylph run 2019-10-22 01:09:31.259' succeeded.

Conclusion

In this article we have seen how to setup and write integration tests for our Flutter apps with Flutter Driver.

We have gained more insight into how integration tests work, and how they differ from widget tests.

And we have seen how to use them to test user flows, using my reference authentication demo app.

Finally, we have automated the entire process by setting up a workflow to run all the tests on Codemagic. And we have seen how to test on real devices with the AWS Device Farm.

And if we want to go further, we can even write integration tests to record the performance of our app. This way, we can ensure that the UI works smoothly on a variety of devices running on AWS Device Farm.

For more in-depth information on some of the topics covered in this article, I recommend reading the following resources:

The full source code for the reference authentication demo is available on GitHub:

Reference Authentication Flow with Flutter & Firebase

What do you think? Do you write integration tests for your Flutter apps, or plan to? Let me know on Twitter at @biz84. You can also check my other tutorials at codingwithflutter.com.

Flutter & Firebase Full Course: Special Launch Offer

Mon, 09 Sep 2019 03:00:18 +0000

After nearly one year of intense work, my full Flutter course is finally ready and publicly available!

Over the last few months, many students have enrolled and gave it great praise, making it one of the highest-rated courses on Udemy.

For that, I’m immensely grateful!

And now, the course is complete with 23 hours of content.

Enroll now with these links to take advantage of my launch sale:

$9.99 - LAUNCH10 (first 50 students)

$11.99 - LAUNCH12 (next 50 students)

$14.99 - DART15 (everyone else)

Note: this is offered with a 30-Day Money-Back Guarantee.

Who is this course for?

This is a beginner & intermediate-level course. It is ideal for:

Beginners who are getting started with Flutter & Firebase.
Developers who already understand the basics, and want to build production-ready Flutter apps following best practices.
Developers who want to write apps on iOS and Android with a single code-base.

What’s in the course?

All the basics are covered, so that you can start with Dart, Flutter & Firebase from scratch.

But there is a lot more.

You will learn how to build a complete, production-ready app for iOS & Android, following a practical, hands-on approach.

Important concepts are explained with clear diagrams. You will always learn what you will be building and why, and then how to do it.

The following topics are covered:

Introduction to Dart
Setup instructions for macOS & Windows
Building Layouts
Navigation
Firebase Authentication (including Google & Facebook auth)
State Management (stateless and stateful widgets)
Streams & reactive apps
Forms, input handling and validation
Material, Cupertino and platform-aware widgets
InheritedWidget and Provider
BLoCs
State Management with Provider
Databases and Cloud Firestore
Forms, ListViews, Date & Time pickers
Advanced stream operations with RxDart
Unit & Widget tests with mockito

Course Structure

The course has a linear structure:

Each lesson builds on top of the previous one.

Each section covers a different topic.

So you can follow the course from beginning to end, or choose the topics you’re most interested in.

In any case, the course contains a wealth of practical advice, along with tips and techniques that I have battle-tested in my work.

Great Reviews Already!

The course has an exceptional rating of 4.8 stars, which is one of the highest for Flutter (and Udemy overall).

Here are some reviews from students that have taken it:

“Clear explanations, a useful practical application that demonstrates all the core things essential to building an app ready for release into the wild. Every step taken is clearly and thoroughly explained, plus downloadable code for every section of this course. A fantastic current course and is proving invaluable for strategies for building ideas for my own app. Cannot praise this course and Andrea’s presentation highly enough.” - Cheryl Kirsten

“I can’t recommend this course highly enough, as a professional developer looking for a fast track into Flutter development Andrea’s course has paid for itself many times over, the state management section alone is worth the price of admission.. the entire course is perfectly paced and provides a wealth of practical advice and just enough code to kickstart your own Flutter projects. Just excellent.” - Bruce Rees

“There are a lot of courses on Udemy that claim to be a “complete course on Flutter”, but this TRULY is a complete course on Flutter. Andrea teaches you how to write production ready code that can easily be scaled, and teaches you concepts that go far beyond just “making it work”. He’s very response to message, and is constantly improving the content. Amazing course! “ - Zeeshan Syed

“I’ve taken several Flutter courses online and have found them very useful in their own right. This course, however, has done the BEST job in covering and explaining (a) best practices (specifically around modularizing your code and structuring your project accordingly) and (b) the always controversial Flutter state management. Andrea provides examples of the varying state management concepts and it’s easy to grasp the advantages and shortcomings of each. I highly recommend this course if you’re looking for a deeper-dive into building a much more complete and production-ready app.” - J Mendoza

“Not only does the instructor provide syntax to use for a flutter/dart implementation for this app, but he also takes the viewer through progression of implementations to help explain various ways to implement and why. This is very rare to see and so much more effective. One of the best of the courses or tutorials I’ve seen on Udemy, lynda, or YouTube for programming languages. Certainly the best of the Flutter tutorials so far. Definitely, above expectations!” - Gadgetologist

Do you want to become a competent Flutter developer?

If you want to fast-track your Flutter learning.

If you want to support my work.

This is the time to buy my course at an incredibly discounted price.

And recommend it to your friends as well.

Enroll Today - starting at only $9.99

$9.99 - LAUNCH10 (first 50 students)

$11.99 - LAUNCH12 (next 50 students)

$14.99 - DART15 (everyone else)

NOTE: Courses are often on sale on Udemy, and this one is no different. However, buying the course with an instructor coupon is the best way to support my work. And by using the links above you can get it at a great price.

I hope that you will join other students that are learning Flutter with my course.

Happy coding!

LEARN FLUTTER TODAY

Dart Features for Better Code: Types and working with parameters

Mon, 22 Jul 2019 03:00:18 +0000

This tutorial presents some of the fundamental features of the Dart language, and shows how to use them in practice.

Using them correctly leads to code that is clear, lightweight, and more robust.

1. Type inference

The Dart compiler can automatically infer the type of variables from their initializer, so that we don’t have to declare the type ourselves.

In practice, this means that we can convert this code:

String name = 'Andrea';
int age = 35;
double height = 1.84;

to this:

var name = 'Andrea';
var age = 35;
var height = 1.84;

This works because Dart can infer the type from the expression on the right side of the assignment.

We could declare a variable like this:

var x;
x = 15;
x = 'hello';

In this case, x is declared first and initialized later.

Its type is dynamic, meaning that it can be assigned from expressions of different types.

Takeaway

Dart will infer the correct type when using var, as long as variables are declared and initialized at the same time.

2. final and const

When a variable is declared with var, it can be assigned again:

var name = 'Andrea';
name = 'Bob';

In other words:

var means multiple assignment.

This is not allowed with final:

final name = 'Andrea';
name = 'Bob'; // 'name', a final variable, can only be set once

Final in practice

It is very common to use final when declaring properties inside widget classes. Example:

class PlaceholderContent extends StatelessWidget {
  const PlaceholderContent({
    this.title,
    this.message,
  });
  final String title;
  final String message;
  
  // TODO: Implement build method
}

Here, the title and message can’t be modified inside the widget, because:

final means single assignment.

So, the difference between var vs final is about multiple vs single assignment. Now let’s look at const:

const

const defines a compile-time constant.

const is used to define hard-coded values, such as colors, font sizes and icons.

But we can also use a const constructor when defining widget classes.

This is possible, as long as everything inside the widget is also a compile-time constant. Example:

class PlaceholderContent extends StatelessWidget {
  const PlaceholderContent({
    this.title,
    this.message,
  });
  final String title;
  final String message;

  @override
  Widget build(BuildContext context) {
    return Center(
      child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: <Widget>[
          Text(
            title,
            style: TextStyle(fontSize: 32.0, color: Colors.black54),
          ),
          Text(
            message,
            style: TextStyle(fontSize: 16.0, color: Colors.black54),
          ),
        ],
      ),
    );
  }
}

And if a widget has a const constructor, it can be built like this:

const PlaceholderContent(
  title: 'Nothing here',
  message: 'Add a new item to get started',
)

As a result, this widget is optimised by Flutter, as it is not rebuilt when the parent changes.

Takeaway:

final means single assignment
const defines a compile-time constant
const widgets are not rebuilt when their parent changes.
Prefer const over final when possible

3. Named & positional parameters

In Dart we define named parameters by surrounding them with curly ({}) braces:

class PlaceholderContent extends StatelessWidget {
  // constructor with named parameters
  const PlaceholderContent({
    this.title,
    this.message,
  });
  final String title;
  final String message;
  
  // TODO: Implement build method
}

This means that we can create the widget above like this:

PlaceholderContent(
  title: 'Nothing here',
  message: 'Add a new item to get started',
)

As an alternative, we could omit the curly braces in the constructor to declare positional parameters:

// constructor with positional parameters
const PlaceholderContent(
  this.title,
  this.message,
);

As a result, parameters are defined by their position:

PlaceholderContent(
  'Nothing here', // title at position 0
  'Add a new item to get started', // message at position 1
)

This works, but it quickly gets confusing when we have many parameters.

Named parameters help with this, because they make the code easier to write (and read).

By the way, you can combine positional and named parameters like so:

// positional parameters first, then named parameters
void _showAlert(BuildContext context, {String title, String content}) {
  // TODO: Show Alert
}

It is common for Flutter widgets to have a single positional parameter, followed by named parameters. The Text widget is a good example of this.

As a guideline, I always want my code to be clear and self-explanatory. And I choose to use named or positional parameters accordingly.

4. @required & default values

By default, named parameters can be omitted.

Omitting a named parameter is the same as giving it a null value.

And sometimes, this leads to unintended consequences.

In the example above, we could define a PlaceholderContent() and forget to pass in the title and message.

And this would lead to a red screen with an error, because we would then be passing null data values to the Text widgets, which is not allowed.

@required to the rescue

We can annotate any required parameters like so:

const PlaceholderContent({
  @required this.title,
  @required this.message,
});

And the compiler will emit a warning if we forget to pass them in.

Still, if we want we can pass null values explicitly:

PlaceholderContent(
  title: null,
  message: null,
)

And the compiler is happy with this.

To prevent passing null values, we can add some assertions:

const PlaceholderContent({
  @required this.title,
  @required this.message,
}) : assert(title != null && message != null);

Our code is safer with this change, because:

@required adds a compile-time check
assert adds a runtime check

And if we add asserts to our code, then runtime errors are much easier to fix, because they will point exactly to the line that caused the error.

non-nullable types

@required and assert make our code safer, by they feel a bit clunky.

It would be nicer if we could specify that an object cannot be null at compile time.

This is accomplished with non-nullable types, which were built into Swift and Kotlin from the start.

And non-nullable types are currently being implemented in the Dart language.

So we can cross fingers and hope they arrive soon. 🤞

Default values

Sometimes it is useful to specify some sensible default values.

This is easy in Dart:

const PlaceholderContent({
  this.title = 'Nothing here',
  this.message = 'Add a new item to get started',
}) : assert(title != null && message != null);

With this syntax, if the title and message are omitted, then the default values are used.

By the way, default values can be specified with positional parameters as well:

int sum([int a = 0, int b = 0]) {
  return a + b;
}
print(sum(10)); // prints 10

Wrap up

Code is written for machines to execute, and for other humans to read.

Life is short. Be nice and write good code 😉

It makes your apps more robust and performant.
It helps teammates and your future self.

Happy coding!

LEARN FLUTTER TODAY

The Future of SwiftyStoreKit: Maintainers Needed

Sun, 14 Jul 2019 06:00:18 +0000

TL;DR:

SwiftyStoreKit needs maintainers.
The project has now a dedicated Slack channel. Join here.

Back in 2015, I created SwiftyStoreKit to make in-app-purchases easier on Apple platforms.

The project has been very popular, with thousands of developers using it in their own apps.

And for a long time, I have managed to keep it going as a sole maintainer.

However, I can no longer keep the project growing and deal with all the GitHub issues.

Instead, I propose that SwiftyStoreKit should be made for the community, by the community.

SwiftyStoreKit on Slack

To that effect, I created a public Slack channel with three primary purposes:

Finding new maintainers for the project
Discuss new feature requests and how to best implement them
General Q/A about the project

Finding new maintainers is the most pressing issue, as my involvement is very limited (and has been since the beginning of 2018).

Maintainer’s guide to SwiftyStoreKit

Implementing bug fixes and new features in SwiftyStoreKit is not easy:

The project is used in production by thousands of apps, across iOS, macOS and tvOS.
In-app purchases only work if configured correctly in App Store Connect.
StoreKit itself is a very old framework that has its own problems.

New code should be tested on all platforms and have adequate test coverage.

But that’s not enough.

Testing all the possible end-to-end configurations (iOS, macOS, tvOS in sandbox/production) is hard, before even considering iTunes downtime and possible account/IAP configuration issues.

And this makes the job of the maintainer particularly hard.

To find the best way forward, I added a #maintainers Slack channel. Use this to register your interest as a maintainer. 😉

Wrap Up

SwiftyStoreKit is a very popular project, and has served developers well over the years.

I’d like for it to continue doing so, even as my involvement winds down.

If you’d like to contribute, join the Slack channel.

NOTE: I will not be moderating this workspace, so it’s up to you all to be nice with each other.

PS. I’m considering to move SwiftyStoreKit to its own organization on GitHub. Aside from this GitHub guide, is there anything I should be aware of (installation issues etc.)?

Happy coding!

Flutter State Management: setState, BLoC, ValueNotifier, Provider

Tue, 09 Jul 2019 02:00:18 +0000

This article is a write-up of the highlights in this video 👆, where we compare different state management techniques.

As an example, we use a simple authentication flow. This sets a loading state while a sign-in request is in progress.

For simplicity, this flow is composed of three possible states:

These are represented by the following state machine, which includes a loading state and an authentication state:

When a sign-in request is in progress, we disable the sign-in button and show a progress indicator.

This example app shows how to handle the loading state with various state management techniques.

The main navigation for the sign-in page is implemented with a widget that uses a Drawer menu to choose between different options:

The code for this is as follows:

class SignInPageNavigation extends StatelessWidget {
  const SignInPageNavigation({Key key, this.option}) : super(key: key);
  final ValueNotifier<Option> option;

  Option get _option => option.value;
  OptionData get _optionData => optionsData[_option];

  void _onSelectOption(Option selectedOption) {
    option.value = selectedOption;
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(_optionData.title),
      ),
      drawer: MenuSwitcher(
        options: optionsData,
        selectedOption: _option,
        onSelected: _onSelectOption,
      ),
      body: _buildContent(context),
    );
  }

  Widget _buildContent(BuildContext context) {
    switch (_option) {
      case Option.vanilla:
        return SignInPageVanilla();
      case Option.setState:
        return SignInPageSetState();
      case Option.bloc:
        return SignInPageBloc.create(context);
      case Option.valueNotifier:
        return SignInPageValueNotifier.create(context);
      default:
        return Container();
    }
  }
}

This widget shows a Scaffold where:

the AppBar’s title is the name of the selected option
the drawer uses a custom built MenuSwitcher
the body uses a switch to choose between different pages

Reference flow (vanilla)

To enable sign-in, we can start with a simple vanilla implementation that doesn’t have a loading state:

class SignInPageVanilla extends StatelessWidget {
  Future<void> _signInAnonymously(BuildContext context) async {
    try {
      final auth = Provider.of<AuthService>(context);
      await auth.signInAnonymously();
    } on PlatformException catch (e) {
      await PlatformExceptionAlertDialog(
        title: 'Sign in failed',
        exception: e,
      ).show(context);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Center(
      child: SignInButton(
        text: 'Sign in',
        onPressed: () => _signInAnonymously(context),
      ),
    );
  }
}

When the SignInButton is pressed, we call the _signInAnonymously method.

This uses Provider to get an AuthService object, and uses it to sign-in.

NOTES

AuthService is a simple wrapper for Firebase Authentication. See this article for more details.
The authentication state is handled by an ancestor widget, that uses the onAuthStateChanged stream to decide which page to show. I covered this in a previous article.

setState

The loading state can be added to the previous implementation by:

Converting our widget to a StatefulWidget
Declaring a local state variable
Using it inside our build method
Updating it before and after the call to sign in.

This is the resulting code:

class SignInPageSetState extends StatefulWidget {
  @override
  _SignInPageSetStateState createState() => _SignInPageSetStateState();
}

class _SignInPageSetStateState extends State<SignInPageSetState> {
  bool _isLoading = false;

  Future<void> _signInAnonymously() async {
    try {
      setState(() => _isLoading = true);
      final auth = Provider.of<AuthService>(context);
      await auth.signInAnonymously();
    } on PlatformException catch (e) {
      await PlatformExceptionAlertDialog(
        title: 'Sign in failed',
        exception: e,
      ).show(context);
    } finally {
      setState(() => _isLoading = false);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Center(
      child: SignInButton(
        text: 'Sign in',
        loading: _isLoading,
        onPressed: _isLoading ? null : () => _signInAnonymously(),
      ),
    );
  }
}

Top Tip: Note how we use a finally clause. This can be used to execute some code, whether or not an exception was thrown.

BLoC

The loading state can be represented by the values of a stream inside a BLoC.

And we need some extra boilerplate code to set things up:

class SignInBloc {
  final _loadingController = StreamController<bool>();
  Stream<bool> get loadingStream => _loadingController.stream;

  void setIsLoading(bool loading) => _loadingController.add(loading);

  dispose() {
    _loadingController.close();
  }
}

class SignInPageBloc extends StatelessWidget {
  const SignInPageBloc({Key key, @required this.bloc}) : super(key: key);
  final SignInBloc bloc;

  static Widget create(BuildContext context) {
    return Provider<SignInBloc>(
      builder: (_) => SignInBloc(),
      dispose: (_, bloc) => bloc.dispose(),
      child: Consumer<SignInBloc>(
        builder: (_, bloc, __) => SignInPageBloc(bloc: bloc),
      ),
    );
  }

  Future<void> _signInAnonymously(BuildContext context) async {
    try {
      bloc.setIsLoading(true);
      final auth = Provider.of<AuthService>(context);
      await auth.signInAnonymously();
    } on PlatformException catch (e) {
      await PlatformExceptionAlertDialog(
        title: 'Sign in failed',
        exception: e,
      ).show(context);
    } finally {
      bloc.setIsLoading(false);
    }
  }

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<bool>(
      stream: bloc.loadingStream,
      initialData: false,
      builder: (context, snapshot) {
        final isLoading = snapshot.data;
        return Center(
          child: SignInButton(
            text: 'Sign in',
            loading: isLoading,
            onPressed: isLoading ? null : () => _signInAnonymously(context),
          ),
        );
      },
    );
  }
}

In a nutshell, this code:

Adds a SignInBloc with a StreamController<bool> that is used to handle the loading state
Makes the SignInBloc accessible to our widget with a Provider/Consumer pair inside a static create method.
Calls bloc.setIsLoading(value) to update the stream, inside the _signInAnonymously method
Retrieves the loading state via a StreamBuilder, and uses it to configure the sign-in button.

Note about RxDart

BehaviourSubject is special stream controller that gives us synchronous access to the last value of the stream.

As an alternative to BloC, we could use a BehaviourSubject to keep track of the loading state, and update it as needed.

I will update the GitHub project to show how to do this.

ValueNotifier

A ValueNotifier can be used to hold a single value, and notify its listeners when this changes.

This is used to implement the same flow:

class SignInPageValueNotifier extends StatelessWidget {
  const SignInPageValueNotifier({Key key, this.loading}) : super(key: key);
  final ValueNotifier<bool> loading;

  static Widget create(BuildContext context) {
    return ChangeNotifierProvider<ValueNotifier<bool>>(
      builder: (_) => ValueNotifier<bool>(false),
      child: Consumer<ValueNotifier<bool>>(
        builder: (_, ValueNotifier<bool> isLoading, __) =>
            SignInPageValueNotifier(
              loading: isLoading,
            ),
      ),
    );
  }

  Future<void> _signInAnonymously(BuildContext context) async {
    try {
      loading.value = true;
      final auth = Provider.of<AuthService>(context);
      await auth.signInAnonymously();
    } on PlatformException catch (e) {
      await PlatformExceptionAlertDialog(
        title: 'Sign in failed',
        exception: e,
      ).show(context);
    } finally {
      loading.value = false;
    }
  }

  @override
  Widget build(BuildContext context) {
    return Center(
      child: SignInButton(
        text: 'Sign in',
        loading: loading.value,
        onPressed: loading.value ? null : () => _signInAnonymously(context),
      ),
    );
  }
}

Inside the static create method, we use a ChangeNotifierProvider/Consumer with a ValueNotifier<bool>. This gives us a way to represent the loading state, and rebuild the widget when it changes.

ValueNotifier vs ChangeNotifier

ValueNotifier and ChangeNotifier are closely related.

In fact, ValueNotifier is a subclass of ChangeNotifier that implements ValueListenable<T>.

This is the implementation of ValueNotifier in the Flutter SDK:

/// A [ChangeNotifier] that holds a single value.
///
/// When [value] is replaced with something that is not equal to the old
/// value as evaluated by the equality operator ==, this class notifies its
/// listeners.
class ValueNotifier<T> extends ChangeNotifier implements ValueListenable<T> {
  /// Creates a [ChangeNotifier] that wraps this value.
  ValueNotifier(this._value);

  /// The current value stored in this notifier.
  ///
  /// When the value is replaced with something that is not equal to the old
  /// value as evaluated by the equality operator ==, this class notifies its
  /// listeners.
  @override
  T get value => _value;
  T _value;
  set value(T newValue) {
    if (_value == newValue)
      return;
    _value = newValue;
    notifyListeners();
  }

  @override
  String toString() => '${describeIdentity(this)}($value)';
}

So, when should we use ValueNotifier vs ChangeNotifier?

Use ValueNotifier if you need widgets to rebuild when a simple value changes.
Use ChangeNotifier if you want more control on when notifyListeners() is called.

Note about ScopedModel

ChangeNotifierProvider is very similar to ScopedModel. In fact these pairs are almost equivalent:

ScopedModel ↔︎ ChangeNotifierProvider
ScopedModelDescendant ↔︎ Consumer

So you don’t need ScopedModel if you are already using Provider, as ChangeNotifierProvider offers the same functionality.

Final comparison

The three implementations (setState, BLoC, ValueNotifier) are very similar, and only differ in how the loading state is handled.

Here is how they compare:

setState ↔︎ least amount of code
BLoC ↔︎ most amount of code
ValueNotifier ↔︎ middle ground

So setState works best for this use case, as we need to handle state that is local to a single widget.

You can evaluate which one is more suitable on a case-by-case basis, as you build your own apps 😉

Keeping track of the currently selected option is also a state management problem:

I first implemented this with a local state variable and setState, inside the custom drawer menu.

However, the state was lost after sign-in in, because the drawer was removed from the widget tree.

As a solution, I decided to store the state with a ChangeNotifierProvider<ValueNotifier<Option>> inside the LandingPage:

class LandingPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Used to keep track of the selected option across sign-in events
    final authService = Provider.of<AuthService>(context);
    return ChangeNotifierProvider<ValueNotifier<Option>>(
      builder: (_) => ValueNotifier<Option>(Option.vanilla),
      child: StreamBuilder<User>(
        stream: authService.onAuthStateChanged,
        builder: (context, snapshot) {
          if (snapshot.connectionState == ConnectionState.active) {
            User user = snapshot.data;
            if (user == null) {
              return Consumer<ValueNotifier<Option>>(
                builder: (_, ValueNotifier<Option> option, __) =>
                    SignInPageNavigation(option: option),
              );
            }
            return HomePage();
          } else {
            return Scaffold(
              body: Center(
                child: CircularProgressIndicator(),
              ),
            );
          }
        },
      ),
    );
  }
}

Here, the StreamBuilder controls the authentication state of the user.

And by wrapping this with a ChangeNotifierProvider<ValueNotifier<Option>>, I’m able to retain the selected option even after the SignInPageNavigation is removed.

In summary:

StatefulWidgets don’t remember their state after they are removed.
With Provider, we can choose where to store state in the widget tree.
This way, the state is retained even when the widgets that use it are removed.

ValueNotifier requires a bit more code than setState. But it can be used to remember the state, by placing a Provider where appropriate in the widget tree.

Source code

The example code from this tutorial can be found here:

State Management Comparison: [ setState ❖ BLoC ❖ ValueNotifier ❖ Provider ]

All these state management techniques are covered in-depth in my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

Happy coding!

LEARN FLUTTER TODAY

Flutter: Designing an Authentication API with Service Classes

Mon, 17 Jun 2019 02:00:18 +0000

In the previous articles we have seen how to create a simple authentication flow with firebase_auth and the Provider package:

These techniques are the basis for my Reference Authentication Flow with Flutter & Firebase.

We will now see how use service classes to encapsulate 3rd party libraries and APIs, and decouple them from the rest of the application. We will use authentication as a concrete example of this.

TL;DR:

Write a service class as an API wrapper that hides any implementation details.
This includes API methods with all their input and output (return) arguments.
(optional) create a base abstract class for the service class, so that it’s easier to swap this with a different implementation

Problem Statement

In the previous article, we used this code to sign in the user with FirebaseAuth:

class SignInPage extends StatelessWidget {
  Future<void> _signInAnonymously() async {
    try {
      // retrieve firebaseAuth from above in the widget tree
      final firebaseAuth = Provider.of<FirebaseAuth>(context);
      await firebaseAuth.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }
  ...
}

Here we use Provider.of<FirebaseAuth>(context) to retrieve an instance of FirebaseAuth.

This avoids the usual problems with global access (see my previous article about global access vs scoped access for more details).

However, we are still accessing the FirebaseAuth API directly in our code.

This can lead to some problems:

How to deal with breaking changes in future versions of FirebaseAuth?
What if we want to swap FirebaseAuth with a different auth provider in the future?

Either way, we would have to update or replace calls to FirebaseAuth across our codebase.

And once our project grows, we may add a lot of additional packages. These may include shared preferences, permissions, analytics, local authentication, to name a few common ones.

This multiplies the effort required to maintain our code as APIs change.

Solution: create service classes

A service class is simply a wrapper.

Here is how we can create a generic authentication service based on FirebaseAuth:

class User {
  const User({@required this.uid});
  final String uid;
}

class FirebaseAuthService {
  final FirebaseAuth _firebaseAuth = FirebaseAuth.instance;

  // private method to create `User` from `FirebaseUser`
  User _userFromFirebase(FirebaseUser user) {
    return user == null ? null : User(uid: user.uid);
  }

  Stream<User> get onAuthStateChanged {
    // map all `FirebaseUser` objects to `User`, using the `_userFromFirebase` method
    return _firebaseAuth.onAuthStateChanged.map(_userFromFirebase);
  }

  Future<User> signInAnonymously() async {
    final user = await _firebaseAuth.signInAnonymously();
    return _userFromFirebase(user);
  }

  Future<void> signOut() async {
    return _firebaseAuth.signOut();
  }
}

In this example, we create a FirebaseAuthService class that implements the API methods that we need from FirebaseAuth.

Note how we have created a simple User class, which we use in the return type of all methods in the FirebaseAuthService.

This way, the client code doesn’t depend on the firebase_auth package at all, because it can work with User objects, rather than FirebaseUser.

With this setup, we can update our top-level widget to use the new service class:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Provider<FirebaseAuthService>(
      builder: (_) => FirebaseAuthService(),
      child: MaterialApp(
        theme: ThemeData(
          primarySwatch: Colors.indigo,
        ),
        home: LandingPage(),
      ),
    );
  }
}

And then, we can replace all calls to Provider.of<FirebaseAuth>(context) with Provider.of<FirebaseAuthService>(context).

As a result, all our client code no longer needs to import this line:

import 'package:firebase_auth/firebase_auth.dart';

This means that if any breaking changes are introduced in firebase_auth, any compile errors can only appear inside our FirebaseAuthService class.

As we add more and more packages, this approach makes our app more maintainable.

As an additional (and optional) step, we could also define an abstract base class:

abstract class AuthService {
  Future<User> signInAnonymously();
  Future<void> signOut();
  Stream<User> get onAuthStateChanged;
}

class FirebaseAuthService implements AuthService {
  ...
}

With this setup, we can use the base class type when we create and use our Provider, while creating an instance of the subclass in the builder:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Provider<AuthService>( // base class
      builder: (_) => FirebaseAuthService(), // concrete subclass
      child: MaterialApp(
        theme: ThemeData(
          primarySwatch: Colors.indigo,
        ),
        home: LandingPage(),
      ),
    );
  }
}

Creating a base class is extra work though. It may only be worth when we know that we need to have multiple implementations at the same time.

If this is not the case, I recommend writing only one concrete service class. And since modern IDEs make refactoring tasks easy, you can rename the class and its usages without pain if needed.

For reference, I’m using a base AuthService class with two implementations in my Reference Authentication Flow project.

This is so that I can toggle between a Firebase and a mock authentication service at runtime, which is useful for testing and demo purposes.

Showtime

Here is a video showing all these techniques in practice, using my Reference Authentication Flow as an example:

Conclusion

Service classes are a good way of hiding the implementation details of 3rd party code in your app.

They can be particularly useful when you need to call an API method in multiple places in your codebase (analytics and logging libraries are a good example of this).

In a nutshell:

Write a service class as an API wrapper that hides any implementation details.
This includes API methods with all their input and output (return) arguments.
(optional) create a base abstract class for the service class, so that it’s easier to swap this with a different implementation

Happy coding!

Source code

The example code from this article was taken from my Reference Authentication Flow with Flutter & Firebase:

Reference Authentication Flow with Flutter & Firebase

In turn, this project complements all the in-depth material from my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

LEARN FLUTTER TODAY

Flutter: Global Access vs Scoped Access with Provider

Mon, 10 Jun 2019 02:00:18 +0000

In the previous article we have seen how to build a simple authentication flow with Flutter & Firebase.

As part of this, we created three widgets:

A SignInPage, used to sign in the user
A HomePage, used to sign out the user
A LandingPage, used to decide which page to show

And these are composed together in the following widget tree:

As the diagram shows, all these widgets access FirebaseAuth as a global singleton variable:

// SignInPage
await FirebaseAuth.instance.signInAnonymously();
// HomePage
await FirebaseAuth.instance.signOut();
// LandingPage
FirebaseAuth.instance.onAuthStateChanged;

Many 3rd party libraries expose their APIs via singletons, so it is not uncommon to see them used like this.

However, global access via singletons leads to code that is not testable.

And in this case, our widgets become tightly coupled to FirebaseAuth.

In practice, this means that:

we cannot write a test to verify that signInAnonymously() is called when the sign-in button is pressed.
we can’t easily swap FirebaseAuth with a different authentication service if we want to.

And we need to address these issues if we want to write clean, testable code.

So in this article we will explore a better alternative to global access.

And I will show how to write an API wrapper for FirebaseAuth in a follow-up article.

Global Access vs Scoped Access

There is one main problem with global access. And we can use our example code to illustrate this:

class SignInPage extends StatelessWidget {
  Future<void> _signInAnonymously() async {
    try {
      await FirebaseAuth.instance.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }
  ...
}

Here, the SignInPage asks for an instance of FirebaseAuth directly.

A better approach would be to tell our SignInPage what it needs, by passing a FirebaseAuth object to its constructor:

class SignInPage extends StatelessWidget {
  SignInPage({@required this.firebaseAuth});
  final FirebaseAuth firebaseAuth;
  Future<void> _signInAnonymously() async {
    try {
      await firebaseAuth.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }
  ...
}

This approach is called constructor injection.

Note: Widgets in the Flutter SDK are created this way. Arguments are passed to the constructor, and used inside the widget. This guarantees that there are no side effects, because widgets are pure components that only depend on arguments that are passed explicitly.

So, should we always pass dependencies to the constructors of our widgets?

Not so fast.

Flutter uses composition heavily.

This often results in very nested widget trees, and can lead to this scenario:

Here, we have three consumer widgets that require synchronous access to a FirebaseUser object.

This object is only available inside the StreamBuilder of the LandingPage.

In order for our consumer widgets to access FirebaseUser, we would have to inject it to all intermediate widgets, even if they don’t need it directly.

I’ve been there. Trust me, it’s not fun.

To avoid this, you may be tempted to get the user with a call to FirebaseAuth.instance.currentUser(). However, this is an asynchronous method that returns a Future<FirebaseUser>. And we shouldn’t need to call an async API to get an object that we already retrieved.

So constructor injection doesn’t scale well when we need to propagate data down the widget tree.

And it is also very impractical with widgets that require a lot of arguments. Example:

class SomeComplexWidget extends StatelessWidget {
  SignInPage({@required this.firebaseAuth, @required this.firestore, @required this.sharedPreferences});
  final FirebaseAuth firebaseAuth;
  final Firestore firestore;
  final SharedPreferences sharedPreferences;
  
  // complex logic here
}

I love a lot of boilerplate code - nobody ever said.

Luckily, there is a solution.

Scoped Access

Scoped access is about making objects available to an entire widget sub-tree.

Flutter already uses this technique. If you ever called Navigator.of(context), MediaQuery.of(context) or Theme.of(context), then you have used scoped access.

Under the hood, this is implemented with a special widget called InheritedWidget.

And while you could build your own widgets based on InheritedWidget, this can also lead to a lot of boilerplate code.

Well, thanks to the community, there is a better way.

Enter Provider

This library by Remi Rousselet and the Flutter team makes life easier.

In a nutshell, Provider is a dependency injection system for your Flutter apps. We can use it to expose objects of any kind (values, streams, models, BLoCs) to our widgets.

So let’s see how to use it.

We can add Provider to our pubspec.yaml file:

// pubspec.yaml
dependencies:
  provider: ^3.0.0

And we can update our example app to use it, by making two changes:

Add a Provider<FirebaseAuth> to the top of our widget tree
Use Provider.of<FirebaseAuth>(context) where needed, instead of FirebaseAuth.instance.

Note: As an alternative to Provider.of, you could use Consumer, which is also part of the Provider package. This page on the official Flutter documentation covers their usage and differences in detail.

The updated widget tree for our example app looks like this:

The top three widgets (MyApp, Provider and MaterialApp), can be composed like this:

import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';

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

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Provider<FirebaseAuth>(
      builder: (_) => FirebaseAuth.instance,
      child: MaterialApp(
        title: 'Flutter Demo',
        theme: ThemeData(
          primarySwatch: Colors.indigo,
        ),
        home: LandingPage(),
      ),
    );
  }
}

Then, we can update our LandingPage to use Provider:

class LandingPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // retrieve firebaseAuth from above in the widget tree
    final firebaseAuth = Provider.of<FirebaseAuth>(context);
    return StreamBuilder<FirebaseUser>(
      stream: firebaseAuth.onAuthStateChanged,
      builder: (context, snapshot) {
        if (snapshot.connectionState == ConnectionState.active) {
          FirebaseUser user = snapshot.data;
          if (user == null) {
            return SignInPage();
          }
          return HomePage();
        } else {
          return Scaffold(
            body: Center(
              child: CircularProgressIndicator(),
            ),
          );
        }
      },
    );
  }
}

And do the same with the SignInPage and HomePage to use Provider:

class SignInPage extends StatelessWidget {
  Future<void> _signInAnonymously() async {
    try {
      // retrieve firebaseAuth from above in the widget tree
      final firebaseAuth = Provider.of<FirebaseAuth>(context);
      await firebaseAuth.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }
  ...
}

class HomePage extends StatelessWidget {
  Future<void> _signOut() async {
    try {
      // retrieve firebaseAuth from above in the widget tree
      final firebaseAuth = Provider.of<FirebaseAuth>(context);
      await firebaseAuth.signOut();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }
  ...
}

Note about BuildContext: We can retrieve the FirebaseAuth object because we pass a BuildContext variable to Provider.of<FirebaseAuth>(context). You can think of context as the position of a widget in the widget tree.

Remember when I said that constructor injection is impractical with deeply nested widget trees?

Well, Provider makes objects accessible to an entire widget sub-tree.

So every time you need to propagate data down the widget tree, Provider should light-up in your brain. 💡

Wrap up

In this article we have learned about scoped access as an alternative to global access.

And we have seen how to use Provider as a dependency injection system for Flutter.

By the way, this was just a basic introduction.

There are many advanced use cases where we need to make multiple objects accessible to our widgets. Some objects may have inter-dependencies. And we may need different kinds of providers.

Provider supports all these cases. I will write more about it in the future.

For now, you can see how I’m using it in my Reference Authentication Flow with Flutter & Firebase on GitHub:

Reference Authentication Flow with Flutter & Firebase

And for a more in-depth coverage of Provider and how to use it for state management, you can check my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

Happy coding!

References

LEARN FLUTTER TODAY

Super Simple Authentication Flow with Flutter & Firebase

Mon, 03 Jun 2019 02:00:18 +0000

User authentication is a very common requirement for a lot of apps.

In this article we implement a simple authentication flow in Flutter, in less than 100 lines of code.

As part of this, we will see how to:

use FirebaseAuth to sign in anonymously.
use StreamBuilder to present different screens depending on the authentication status of the user.

This is the basis of my Reference Authentication Flow with Flutter & Firebase on GitHub.

So, let’s start from the basics.

Initial setup

We will use Firebase Authentication for this example.

After creating a new Flutter project, we can add firebase_auth to the dependencies section of our pubspec.yaml file:

// pubspec.yaml
dependencies:
  flutter:
    sdk: flutter
  firebase_auth: 0.11.1+3

Then, we need to configure our Flutter app to use Firebase. This guide explains what to do step-by-step:

Add Firebase to your Flutter app

The two most important steps are:

Add GoogleServices-info.plist and google-services.json to the iOS and Android projects, otherwise the app will crash at startup.
Enable anonymous sign-in in the Firebase console, as we will use it in this example.

I cover all these steps in detail in my Flutter & Firebase course.

Let’s code

Our application will have two pages, called SignInPage and HomePage, which are both stateless widgets:

Then we will have another widget called LandingPage. We will use this to decide which page to show depending on the authentication status of the user.

Here is the entire widget tree of this app:

Let’s implement this in code.

SignInPage

First, the SignInPage:

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

class SignInPage extends StatelessWidget {

  Future<void> _signInAnonymously() async {
    try {
      await FirebaseAuth.instance.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Sign in')),
      body: Center(
        child: RaisedButton(
          child: Text('Sign in anonymously'),
          onPressed: _signInAnonymously,
        ),
      ),
    );
  }
}

All this does is to show a centered RaisedButton, which calls _signInAnonymously() when pressed.

This method calls FirebaseAuth.instance.signInAnonymously() and awaits for the result.

NOTES

try/catch is used to catch any exceptions. We can use this to alert the user if sign-in fails.
await FirebaseAuth.instance.signInAnonymously() returns a FirebaseUser, but our code doesn’t use the return value. That’s because we will handle the authentication status of the user somewhere else.

Speaking of which…

LandingPage

We use this widget class to decide which page to show:

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

class LandingPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StreamBuilder<FirebaseUser>(
      stream: FirebaseAuth.instance.onAuthStateChanged,
      builder: (context, snapshot) {
        if (snapshot.connectionState == ConnectionState.active) {
          FirebaseUser user = snapshot.data;
          if (user == null) {
            return SignInPage();
          }
          return HomePage();
        } else {
          return Scaffold(
            body: Center(
              child: CircularProgressIndicator(),
            ),
          );
        }
      },
    );
  }
}

This page uses two main ingredients:

The FirebaseAuth.instance.onAuthStateChanged stream. This receives a new value each time the user signs in or out.
A StreamBuilder of type FirebaseUser. This takes onAuthStateChanged as an input stream, and calls the builder when the stream is updated.

So when a call to FirebaseAuth.instance.signInAnonymously() succeeds, a new FirebaseUser is added to onAuthStateChanged.

As a result, the builder is called and we can extract the FirebaseUser from snapshot.data. And we use this to decide which page to show:

FirebaseUser user = snapshot.data;
if (user == null) {
  return SignInPage();
}
return HomePage();

Also note how we’re checking the connectionState of the snapshot:

if (snapshot.connectionState == ConnectionState.active) {
  // do something
}

This can be any of four possible values: none, waiting, active, done.

When the application starts, the builder is first called with ConnectionState.waiting. We can use this to show a centered CircularProgressIndicator().

Once the authentication status is determined, the connectionState becomes active, and our builder is called again.

In summary, we have three possible authentication states:

unknown
user signed-in
user not signed-in

And this code is all we need to handle them:

if (snapshot.connectionState == ConnectionState.active) {
  FirebaseUser user = snapshot.data;
  if (user == null) {
    return SignInPage();
  }
  return HomePage();
} else {
  return Scaffold(
    body: Center(
      child: CircularProgressIndicator(),
    ),
  );
}

Moving on…

HomePage

This class is similar to the SignInPage:

import 'dart:async';
import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutter/material.dart';

class HomePage extends StatelessWidget {

  Future<void> _signOut() async {
    try {
      await FirebaseAuth.instance.signOut();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Home Page'),
        actions: <Widget>[
          FlatButton(
            child: Text(
              'Logout',
              style: TextStyle(
                fontSize: 18.0,
                color: Colors.white,
              ),
            ),
            onPressed: _signOut,
          ),
        ],
      ),
    );
  }
}

This code calls FirebaseAuth.instance.signOut() when the logout button is pressed.

On success, a null value is added to onAuthStateChanged. As a result, the builder in our LandingPage is called again, and this time we return a SignInPage().

Finishing up

Almost there. Now we just need to update our main.dart file, to pass the LandingPage() to the home argument of MaterialApp:

import 'package:flutter/material.dart';

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

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.indigo,
      ),
      home: LandingPage(),
    );
  }
}

All in all, this entire flow takes less than 100 lines of code.

Here is the code for the entire example:

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

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

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.indigo,
      ),
      home: LandingPage(),
    );
  }
}

class LandingPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StreamBuilder<FirebaseUser>(
      stream: FirebaseAuth.instance.onAuthStateChanged,
      builder: (context, snapshot) {
        if (snapshot.connectionState == ConnectionState.active) {
          FirebaseUser user = snapshot.data;
          if (user == null) {
            return SignInPage();
          }
          return HomePage();
        } else {
          return Scaffold(
            body: Center(
              child: CircularProgressIndicator(),
            ),
          );
        }
      },
    );
  }
}

class SignInPage extends StatelessWidget {

  Future<void> _signInAnonymously() async {
    try {
      await FirebaseAuth.instance.signInAnonymously();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Sign in')),
      body: Center(
        child: RaisedButton(
          child: Text('Sign in anonymously'),
          onPressed: _signInAnonymously,
        ),
      ),
    );
  }
}

class HomePage extends StatelessWidget {

  Future<void> _signOut() async {
    try {
      await FirebaseAuth.instance.signOut();
    } catch (e) {
      print(e); // TODO: show dialog with error
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Home Page'),
        actions: <Widget>[
          FlatButton(
            child: Text(
              'Logout',
              style: TextStyle(
                fontSize: 18.0,
                color: Colors.white,
              ),
            ),
            onPressed: _signOut,
          ),
        ],
      ),
    );
  }
}

This uses just a single main.dart file. I advise to put widget classes in separate files in your own projects ;)

Conclusion

We have seen how to build a simple authentication flow with Firebase.

This example doesn’t use any fancy app architecture.

And sometimes, keeping things simple is a good idea. As Albert Einstein once said:

Everything Should Be Made as Simple as Possible, But Not Simpler

However, Einstein wasn’t a software developer. 😄

And the code I presented has two major drawbacks:

1) Global Access

The LandingPage, SignInPage, HomePage all access FirebaseAuth via the instance singleton variable.

This is not recommended because the resulting code is not testable.

2) Direct use of FirebaseAuth

Using FirebaseAuth directly in our widgets is not a good idea.

This can cause problems if our application grows, and we decide to use a different authentication provider in the future.

In the next article we will see how to address these concerns. We will do this by:

moving from global access to scoped access with Provider
writing an authentication service class as a wrapper for FirebaseAuth

By the way, I cover all these topics (and much more) in my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

Happy coding!

LEARN FLUTTER TODAY

Widget-Async-Bloc-Service: A Practical Architecture for Flutter Apps

Tue, 21 May 2019 06:00:00 +0000

Difficulty level: Intermediate/advanced. All opinions are my own.

Introduction

State management is a hot topic in Flutter right now.

Over the last year, various state management techniques were proposed.

The Flutter team and community have not (yet) settled on a single “go-to” solution.

This makes sense, because different apps have different requirements. And choosing the most appropriate technique depends on what we’re trying to build.

Truth be told, some state management techniques have proven very popular.

Scoped Model is known for its simplicity.
BLoCs are also widely used, and they work well with Streams and RxDart for more complex apps.
Most recently at Google I/O, the Flutter team showed us how to use the Provider package and ChangeNotifier to propagate state changes across widgets.

Having multiple choices can be a good thing.

But it can also be confusing. And choosing a technique that will work and scale well as our apps grow is important.

What’s more, making the right choice early on can save us a lot of time and effort.

My take on state management and app architecture

Over the last year I’ve been building a lot of Flutter apps, big and small.

During this time, I have encountered and solved many problems.

And I have learned that there is no silver bullet for state management.

However, after building things and taking them apart over and over, I have fine-tuned a technique that works well in all my projects.

So in this article I introduce a new architectural pattern that I have defined by:

borrowing a lot of ideas from existing patterns
tweaking them to suit the needs of real-world Flutter apps

Before we see what this pattern looks like, let me define some goals.

This pattern should:

Be easy to understand, once the fundamental building blocks are clear
Be easy to replicate when adding new features
Build upon clean architecture principles
Work well when writing reactive Flutter apps
Require little or no boilerplate code
Lead to testable code
Lead to portable code
Favour small, composable widgets and classes
Integrate easily with asynchronous APIs (Futures and Streams)
Scale well with apps that increase in size and complexity

Out of the existing state management techniques for Flutter, this pattern builds most heavily on BLoCs, and is quite similar to the RxVMS architecture.

Without further ado, I am pleased to introduce:

Shorthand: WABS (which is cool because it contains my initials :D)

This architectural pattern comes in four variants.

Widget-Bloc-Service

Widget-Service

Widget-Bloc

Widget only

NOTE: aside from the Widget item, the BLoC and Service items are both optional.

In other words: you can use or omit them as appropriate on a case-by-case basis.

Now, let’s explore the full implementation with a more detailed diagram:

First of all, this diagram defines three application layers:

The UI layer: this is always necessary as it is where our widgets live.
The data layer (optional): this is where we add our logic and modify state.
The service layer (optional): this is what we use to communicate to external services.

Next, let’s define some rules for what each layer can (and cannot) do.

Rules of play

UI Layer

This is where we put our widgets.

Widgets can be stateless or stateful, but they should not include any explicit state management logic.

An example of explicit state management is the Flutter counter example, where we increment the counter with setState() when the increment button is pressed.

An example of implicit state management is a StatefulWidget that contains a TextField managed by a TextEditingController. In this case we need a StatefulWidget because TextEditingController introduces side effects (I discovered this the hard way), but we are not managing any state explicitly.

Widgets in the UI layer are free to call sync or async methods defined by blocs or services, and can subscribe to streams via StreamBuilder.

Note how the diagram above connects a single widget to both the input and output of the BLoC. But we can use this pattern to connect one widget to the input, and another widget to the output:

In other words, we can implement a producer → consumer data flow.

The WABS pattern encourages us to move any state management logic to the data layer. So let’s take a look at it.

Data Layer

In this layer we can define local or global application state, as well as the code to modify it.

This is done with business logic components (BLoCs), a pattern first introduced during DartConf 2018.

BLoC was conceived to separate the business logic from the UI layer, and increase code reuse across multiple platforms.

When using the BLoC pattern, widgets can:

dispatch events to a sink
be notified of state updates via a stream

According to the original definition, we can only communicate with BLoCs via sinks and streams.

While I like this definition, I find it too restrictive in a number of use cases. So in WABS I use a variant of BLoC called Async BLoC.

Just like with BLoCs, we have output stream(s) that can be subscribed to.

However, the BLoC input(s) can include a synchronous sink, an asynchronous method, or both.

In other words, we go from this:

to this:

The asyncrhonous method(s) can:

Add zero, one or more values to the input sink.
Return a Future<T> with a result. The calling code can await for the result and do something accordingly.
Throw an exception. The calling code can detect this with try/catch and show an alert if desired.

Later on, we will see a full example of how useful this is in practice.

More on BLoCs

An Async BLoC can define a StreamController/Stream pair, or the equivalent BehaviorSubject/Observable if using RxDart.

If we want, we can even perform advanced stream operations, like combining streams with combineLatest. And just to be clear:

I recommend having multiple streams in a single BLoC if they need to be combined in some way.
I discourage having multiple StreamControllers in a single BLoC. Instead, I prefer breaking up the code in two or more BLoC classes, for better separation of concerns.

Things we should/shouldn’t do in the data layer / BLoCs

BLoCs should only contain pure Dart code. No UI code, no importing Flutter files, or using a BuildContext inside BLoCs.
BLoCs should not call 3rd party code directly. This is the job of service classes.
The interface between Widgets and BLoCs is the same as the interface between BLoCs and services. That is, BloCs can communicate directly with service classes via sync/async methods, and be notified of updates via streams.

Service layer

Service classes have the same input/output interface as BLoCs.

However, there is one fundamental distinction between services and BLoCs.

BLoCs can hold and modify state.
Services can’t.

In other words, we can think of services as pure, functional components.

They can modify and transform data they receive from 3rd party libraries.

Example: Firestore service

We can implement a FirestoreDatabase service as a domain-specific API-wrapper for Firestore.
Data in (read): This transforms streams of key-value pairs from Firestore documents into strongly-typed immutable data models.
Data out (write): This converts data models back to key-value pairs for writing to Firestore.

In this case, the service class performs simple data manipulation. Unlike BLoCs, it doesn’t hold any state.

A note about terminology: Other articles use the term Repository when referring to classes that talk to 3rd party libraries. Even the definition of the Repository pattern has evolved over time (see this article for more info). In this article, I don’t make a clear distinction between Service and Repository.

Putting things together: the Provider package

Once we have defined our BLoCs and services, we need to make them available to our widgets.

For some time now, I have been using the provider package by Remi Rousselet. This is a full dependency injection system for Flutter, based on InheritedWidget.

I really like its simplicity. Here is how to use it to add an authentication service:

return Provider<AuthService>(
  builder: (_) => FirebaseAuthService(), // FirebaseAuthService implements AuthService
  child: MaterialApp(...),
);

And this is how we could use it to create a BLoC:

return Provider<SignInBloc>(
  builder: (_) => SignInBloc(auth: auth),
  dispose: (_, bloc) => bloc.dispose(),
  child: Consumer<SignInBloc>(
    builder: (_, bloc, __) => SignInPage(bloc: bloc),
  ),
);

Note how the Provider widget takes an optional dispose callback. We use this to dispose BLoCs and close the corresponding StreamControllers.

Provider gives us a simple and flexible API that we can use to add anything we want to our widget tree. It works great with BLoCs, services, values and more.

I’ll talk in more detail about how to use Provider in some of my upcoming articles. For now, I highly recommend this talk from Google I/O:

Pragmatic State Management in Flutter (Google I/O’19)

Now that we have seen how WABS works conceptually, let’s use it to build a sign in flow with Firebase authentication.

Here is a sample interaction from my Reference Authentication Flow with Flutter & Firebase:

A few observations:

When sign-in is triggered, we disable all buttons and show a CircularProgressIndicator. We set a loading state to true to do this.
When sign-in succeeds or fails, we re-enable all buttons and restore the title Text. We set loading=false to do this.
When sign-in fails, we present an alert dialog.

Here is a simplified version of the SignInBloc used to drive this logic:

import 'dart:async';
import 'package:firebase_auth_demo_flutter/services/auth_service.dart';
import 'package:meta/meta.dart';

class SignInBloc {
  SignInBloc({@required this.auth});
  final AuthService auth;

  final StreamController<bool> _isLoadingController = StreamController<bool>();
  Stream<bool> get isLoadingStream => _isLoadingController.stream;

  void _setIsLoading(bool isLoading) => _isLoadingController.add(isLoading);

  Future<void> signInWithGoogle() async {
    try {
      _setIsLoading(true);
      return await auth.signInWithGoogle();
    } catch (e) {
      rethrow;
    } finally {
      _setIsLoading(false);
    }
  }

  void dispose() => _isLoadingController.close();
}

Note how the public API of this BLoC only exposes a Stream and a Future:

Stream<bool> get isLoadingStream;
Future<void> signInWithGoogle();

This is in line with our definition of Async BLoC.

All the magic happens in the signInWithGoogle() method. So let’s review this again with comments:

Future<void> signInWithGoogle() async {
  try {
    // first, add loading = true to the stream sink
    _setIsLoading(true);
    // then sign-in and await for the result
    return await auth.signInWithGoogle();
  } catch (e) {
    // if sign in failed, rethrow the exception to the calling code
    rethrow;
  } finally {
    // on success or failure, add loading = false to the stream sink
    _setIsLoading(false);
  }
}

Just like a normal BLoC, this method adds values to a sink.

But in addition to that, it can return a value asynchronously, or throw an exception.

This means that we can write code like this in our SignInPage:

// called by the `onPressed` callback of our button
Future<void> _signInWithGoogle(BuildContext context) async {
  try {
    await bloc.signInWithGoogle();
    // handle success
  } on PlatformException catch (e) {
    // handle error (show alert)
  }
}

This code looks simple enough. And it should be, because all we need here is async/await and try/catch.

And yet, this is not possible with the “strict” version of BLoC that only uses a sink and a stream. For reference, implementing something like this in Redux is… uhm… not fun! 😅

Async-BLoC may seem like a small improvement to BLoC, but it makes all the difference.

A note on handling exceptions

By the way, another possible way of handling exceptions would be to add an error object to the stream, like so:

Future<void> signInWithGoogle() async {
  try {
    // first, add loading = true to the stream sink
    _setIsLoading(true);
    // then sign-in and await for the result
    return await auth.signInWithGoogle();
  } catch (e) {
    // add error to the stream
    _isLoadingController.addError(e);
  } finally {
    // on success or failure, add loading = false to the stream sink
    _setIsLoading(false);
  }
}

Then, in the widget class we could write code like this:

class SignInPage extends StatelessWidget {
  SignInPage({@required this.bloc});
  final SignInBloc bloc;
  
  // called by the `onPressed` callback of our button
  Future<void> _signInWithGoogle(BuildContext context) async {
    await bloc.signInWithGoogle();
  }
   
  void build(BuildContext context) {
    return StreamBuilder(
      stream: isLoadingStream,
      builder: (context, snapshot) {
        if (snapshot.hasError) {
          // show error
          showDialog(...);
        }
        // build UI based on snapshot
      }
    )
  }
}

However, this is bad for two reasons:

It shows a dialog inside the builder of the StreamBuilder. This is not great because the builder is only supposed to return a widget, and not execute any imperative code.
This code lacks clarity. The place where we show the error is completely different from the place where we sign in.

So, don’t do this, and use try/catch as shown above. 😉

Moving on…

Can we use WABS to create an `Async-Service`?

Of course. As I said before:

BLoCs can hold and modify state.
Services can’t.

However, their public-facing APIs obey the same rules.

Here’s an example of a service class for a database API:

abstract class Database {
  // CRUD operations for Job
  Future<void> setJob(Job job);
  Future<void> deleteJob(Job job);
  Stream<List<Job>> jobsStream();

  // CRUD operations for Entry
  Future<void> setEntry(Entry entry);
  Future<void> deleteEntry(Entry entry);
  Stream<List<Entry>> entriesStream({Job job});
}

We could use this API to write and read data to/from Cloud Firestore.

The calling code could define this method to write a new Job to the database:

Future<void> _submit(Job job) async {
  try {
    await database.setJob(job);
    // handle success
  } on PlatformException catch (e) {
    // handle error (show alert) 
  }
}

Same pattern, very simple error handling.

Comparison with RxVMS

In this article, I have introduced Widget-Async-BLoC-Service as an adaptation of existing architectural patterns in Flutter.

WABS is most similar to the RxVMS pattern by Thomas Burkhart.

There is even a close match between the individual layers:

WABS	RxVMS
Widget	View
Async	RxCommand
BLoC	Manager
Service	Service

The main differences between the two are that:

WABS uses the Provider package, while RxVMS uses the GetIt service locator
WABS uses simple async methods to handle UI events, while RxVMS uses RxCommand.

RxCommand is a powerful abstraction to handle UI events and updates. It removes the boilerplate code required to create a StreamController/Stream pair with BLoCs.

It does however come with a bigger learning curve. For my use cases Async-Bloc does the job and is simpler, despite a bit of extra boilerplate.

I also like that WABS can be implemented without any external libraries (aside from the Provider package).

Ultimately choosing one or the other depends on your use cases, but also personal preference and taste.

Should I use BLoCs in my apps?

BLoCs come with a steep learning curve. To understand them, you need to also be familiar with Streams and StreamBuilder.

When working with streams, there are various considerations to make:

what is the connection state of the stream? (none, waiting, active, done)
is the stream single or multiple subscription?
StreamController and StreamSubscription always need to be disposed
dealing with nested StreamBuilders can lead to thorny debugging issues when Flutter rebuilds the widget tree

All of this adds more overhead to our code.

And when updating local application state (e.g. propagating state from one widget to another), there are simpler alternatives to BLoC. I plan to write about this on a follow-up article.

In any case, I found BLoCs very effective when building realtime apps with Firestore, where the data flows from the backend into the app via streams.

In this scenario, it is common to combine streams or perform transformations with RxDart. BLoCs are a great place to do this.

Conclusion

This article was an in-depth introduction to WABS, an architectural pattern that I have been using for some time in multiple projects.

Truth be told, I have been been refining this over time, and I didn’t even have a name for it until I wrote this article.

As I said before, architectural patterns are just tools to get our job done. My advice: choose the tools that make more sense for you and your projects.

And if you use WABS in your projects, let me know how it works for you. 😉

Happy coding!

Source code

The example code from this article was taken from my Reference Authentication Flow with Flutter & Firebase:

Reference Authentication Flow with Flutter & Firebase

In turn, this project complements all the in-depth material from my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

References

LEARN FLUTTER TODAY

Flutter & Firebase: Reference Authentication Demo

Fri, 17 May 2019 04:00:18 +0000

Today I’m sharing a new open source project, showing how to implement a full authentication flow with Flutter & Firebase:

Reference Authentication Flow with Flutter & Firebase

I created this as a follow up from my YouTube series on Flutter & Firebase authentication.

This is also a complement to my Flutter & Firebase Udemy course (now available for early access - read the full announcement here).

This project shows how to:

use the various Firebase sign-in methods
build a robust authentication flow
use appropriate state management techniques to separate UI, logic and Firebase authentication code
handle errors and present user-friendly error messages
write production-ready code following best practices

Preview

Google Sign-in

Facebook Sign-in

Email & Password auth

Note that this is a reference implementation. You can use it to add Firebase authentication to your own projects.

The code is very modular, so you can pick & choose which parts you need.

It is also meant to be a good testing ground for various state management techniques.

What’s next

In follow-up articles I will show how to implement existing flows in this app with different state management techniques.

This will lead to a detailed comparison of BLoCs, ValueNotifier and ChangeNotifier, on a real-world codebase that you could use in production.

I’ll keep it short for today. You can grab the source code here:

Reference Authentication Flow with Flutter & Firebase

By the way, a lot of the techniques used in this project are explained in great detail, and implemented step-by-step in my Flutter & Firebase Udemy course.

This course is now available for Early Access. Use this link to enroll (discount code included):

Flutter & Firebase: Build a Complete App for iOS & Android

Happy Coding!

Andrea Bizzotto

Case Study: Automating UI/Integration Tests with Flutter Driver and Codemagic

Application overview

Integration tests or UI tests?

Mocking the authentication service

Adding integration tests with Flutter Driver

Running on Codemagic

Conclusion

Flutter & Firebase Full Course: Special Launch Offer

Special Launch Promo Codes

Who is this course for?

What’s in the course?

Course Structure

Great Reviews Already!

Do you want to become a competent Flutter developer?

Enroll Today - starting at only $9.99

LEARN FLUTTER TODAY

Dart Features for Better Code: Types and working with parameters

1. Type inference

2. final and const

Final in practice

const

3. Named & positional parameters

4. @required & default values

@required to the rescue

non-nullable types

Default values

Wrap up

LEARN FLUTTER TODAY

The Future of SwiftyStoreKit: Maintainers Needed

SwiftyStoreKit on Slack

Maintainer’s guide to SwiftyStoreKit

Wrap Up

Flutter State Management: setState, BLoC, ValueNotifier, Provider

Main Navigation

Reference flow (vanilla)

setState

BLoC

Note about RxDart

ValueNotifier

ValueNotifier vs ChangeNotifier

Note about ScopedModel

Final comparison

Bonus: Implementing the Drawer Menu

Source code

LEARN FLUTTER TODAY

Flutter: Designing an Authentication API with Service Classes

Problem Statement

Solution: create service classes

Showtime

Conclusion

Source code

LEARN FLUTTER TODAY

Flutter: Global Access vs Scoped Access with Provider

Global Access vs Scoped Access

Scoped Access

Enter Provider

Wrap up

References

LEARN FLUTTER TODAY

Super Simple Authentication Flow with Flutter & Firebase

Initial setup

Let’s code

SignInPage

LandingPage

HomePage

Finishing up

Conclusion

LEARN FLUTTER TODAY

Widget-Async-Bloc-Service: A Practical Architecture for Flutter Apps

Introduction

My take on state management and app architecture

The Widget-Async-BLoC-Service Pattern

Rules of play

UI Layer

Data Layer

Service layer

Putting things together: the Provider package

A real-world example: Sign-In Page

Can we use WABS to create an Async-Service?

Can we use WABS to create an `Async-Service`?