Originally published on bendyworks.com.

This is it. 31 blog posts in 31 days. Writing a month of flutter has been a ton of work but also lots of fun and a good learning experience. I really appreciate how supportive and and positive everyone as been.

Publishing experience

For the series I’ve been posting on bendyworks.com, DEV, my personal blog, and Medium. After publishing to these sites, I would put the Bendyworks link on Twitter, Reddit, and the Flutter Study Group Slack.

Posting to DEV was easy as they use Markdown just like the Bendworks blog. DEV also has built in support for a series of posts so it’s easy to read the entire series. I did have to manually upload any embedded images. DEV also has a number of liquid tags for embedding things like GitHub issues that I didn’t make as much use of as I should have.

Blogger is rich text so it was easy to copy/paste the rendered posts. This would hotlink all the images though so I had to remove them and manually re-upload them.

Medium will only support canonical links if you import from a URL for some reason. They would grab any images and host them on their CDN so no manual uploading. Importing would lose all the code snippet formatting though so I would have to fix all of that.

Engagement

Bendyworks received the most page views which is not surprising since those were the URLs shared on Twitter/Reddit/Slack. DEV was second with with Medium and my blog getting negligible views.

For engagement DEV was the leader with lots of ❤️ and Twitter close behind. Reddit had some upvotes but not that many and only a few claps came from Medium.

The real breakout for me here was DEV. I had never posted anything or used it much but I found the community very friendly and engaging. I received a lot more activity from the 600+ followers up built up there than the almost 9000 followers I have on Twitter. If you’re not on DEV yet, sign up and follow me.

Goals

Kicking off I had three main goals

• Become a better Flutter developer
• Practice writing concise blog posts
• Practice writing project requirements

I certainly become a better Flutter developer and learned a lot along the way. I would like to try more architecture patterns but the need to always be publishing didn’t leave me with much room for exploration. Maybe I could have written more “I tried this and here why it didn’t work” posts but I felt pressure to always deliver progress.

I am much better at throwing words onto a page and coming out with a decent post. One aspect of blogging that I constantly struggle with is keeping posts small and digestible. It’s easy to get into the mindset that posts have to be long and perfect. Short and to the point is usually better though.

Working on improving project requirements kind of fell by the wayside as I tried to keep up with posting every day. It just wasn’t a priority.

App

The app isn’t done yet but it has Sign in with Google, a home stream, and fancy animations.

AnnotatedRegion

Miguel submitted a pull request fixing a bug on Android where the bottom navigation theme would break on sign in. He fixed it by wrapping the HomePage Scaffold in an AnnotatedRegion widget.

AnnotatedRegion<SystemUiOverlayStyle>( value: lightSystemUiOverlayStyle, child: Scaffold(/* ... */), )

Thanks

A huge thank you goes to Pearl for proofreading every single post and reviewing all the code, sometimes late at night at the last minute. I couldn’t have done a month of Flutter without her help.

Thanks also to: Unsplash for all the featured images. @NinaLimpi and unDraw for the fantastic illustrations. @tommy_emo_ for the awesome icon.

All of you for reading along and your feedback and support.

What’s next

I’m going to keep developing Birb and writing about it as “a month+ of Flutter”. Just don’t expect posts every day. For example I’d like to finally get a readme written and take a second look at something I didn’t get running before.

Follow me on Twitter and DEV for future posts and GitHub for code changes.

Code changes

• #69 Apply AnnotatedRegion that fixes

Originally published on bendyworks.com.

For the last post before the month’s wrap up tomorrow, I wanted to do something more fun: use a hero animation between the home page list and the individual post page.

When I first implemented the Hero animation it never worked going back from a PostPage to the HomePage. The reason was that HomePage would get rerendered and that would generate new fake posts. So I moved the fake data generation up a level to MyApp and pass it into HomePage. This is more realistic as going to the HomePage shouldn't request the Posts every time.

HomePage(
  title: 'Birb',
  posts: _loadPosts(context),
)

The PostPage implementation is a simple StatelessWidget that takes Post and renders a PostItem. This will become more complex as things like comments and likes are implemented but works for now.

class PostPage extends StatelessWidget {
  const PostPage({
    Key key,
    @required this.post,
  }) : super(key: key);

  final Post post;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Post'),
        centerTitle: true,
        elevation: 0.0,
      ),
      body: SingleChildScrollView(
        child: Padding(
          padding: const EdgeInsets.fromLTRB(16.0, 16.0, 16.0, 8.0),
          child: PostItem(post),
        ),
      ),
    );
  }
}

With PostItem being used to render on the HomePage and on the PostPage, wrapping the Image in a Hero is handled in a single place. tag is how Hero knows what to transition between pages.

Hero(
  tag: post.id,
  child: ClipRRect(
    child: Image.network(post.imageUrl),
    borderRadius: BorderRadius.circular(10.0),
  ),
)

The last piece is navigating from PostList to PostPage when a user taps on a PostItem. I'll handle this with an InkWell widget so there is a nice Material ripple.

InkWell(
  onTap: () => _navigateToPost(context, post),
  child: PostItem(post),
)

The navigation is more complex then opening the registration page for two reasons. Named routes don’t support parameters and I wanted a simple transition between the rest of the content on the page.

void _navigateToPost(BuildContext context, Post post) {
  Navigator.of(context).push(
    PageRouteBuilder<PostPage>(
      pageBuilder: (
        BuildContext context,
        Animation<double> animation,
        Animation<double> secondaryAnimation,
      ) {
        return PostPage(post: post);
      },
      transitionsBuilder: (
        BuildContext context,
        Animation<double> animation,
        Animation<double> secondaryAnimation,
        Widget child,
      ) {
        return FadeTransition(
          opacity: animation,
          child: child,
        );
      },
    ),
  );
}

Here I will push a PageRouteBuilder onto the navigation stack. PageRouteBuilder has two key builders in use here. pageBuilder builds the widget that should be rendered as the new page and transitionBuilder specifies how to transition between the old and new pages. Note that this FadeTransition is not related to implementing Hero earlier.

The tests for PostPage is simple and just checking that PostItem is rendered. I did update the PostItem test to expect that its Hero widget had the correct tag value.

expect(tester.widget<Hero>(hero).tag, post.id);

PostsList tests had to be wrapped in a MaterialApp as InkWell must have a Material widget ancestor.

The navigation and animation from PostsList to PostPage is now doing more work so I replaced several pump pauses with pumpAndSettle.

Here is the fancy Hero animation:

Code changes

WIP: Add post page with hero animation by abraham · Pull Request #68 · abraham/birb

Originally published on bendyworks.com.

Yesterday I implemented saving new users to Firestore but I wasn’t happy with the implementation. So today I refactored everything, well not everything but a lot. There are still areas for improvement but I like the general pattern being used now.

Now there is a top level ScopedModel that tracks the current authentication status. This sets up a listener on FirebaseAuth and Firestore and will get pushed changes when either have changed. Children widgets that need to change functionality based on authentication status will get rerendered as needed.

A couple of the less important changes that I’ll get out of the way now.

• Auth was renamed to AuthService
• The Firestore rules were updated to allow a user to read their own user document
• Registration/sign in success SnackBar was replaced with an unstyled welcome view
• HomePage got routeName added

In MyApp's build, MaterialApp has been wrapped in ScopedModel<CurrentUserModel>. I put ScopedModel at the top because authentication changing will touch almost all of the app.

ScopedModel<CurrentUserModel>(
  model: CurrentUserModel.instance(),
  child: MaterialApp(
    debugShowCheckedModeBanner: false,
    title: 'Birb',
    theme: buildThemeData(),
    home: const HomePage(title: 'Birb'),
    routes: <String, WidgetBuilder>{
      RegisterPage.routeName: (BuildContext context) =>
          const RegisterPage(),
    },
  ),
)

ScopedModel takes a model, which in this case is CurrentUserModel (I'm not 100% in on that name yet) and acts similar to an InheritedWidget. Any children can find and interact with the CurrentuserModel instance or be conditionally rendered based on its state.

Coming from a background in web development, I thinkf of Models differently than ScopedModel does. Typically I think of models as single data objects like a blog post or tweet. In ScopedModel land, it's more like a store or state machine and can manage the state of several things.

I have set the CurrentStatusModel to have one of three statues:

enum Status {
  Unauthenticated,
  Unregistered,
  Authenticated,
}

• Unauthenticated is the initial default
• Unregistered the user has authenticated through Firebase
• Authenticated is when the user has authenticated, agreed to the Terms of Service, and a User document has been saved to Firestore

Here is the new CurrentUserModel definition:

class CurrentUserModel extends Model {
  CurrentUserModel({
    @required this.firestore,
    @required this.firebaseAuth,
    @required this.userService,
  });

  CurrentUserModel.instance()
      : firestore = Firestore.instance,
        firebaseAuth = FirebaseAuth.instance,
        userService = UserService.instance(),
        authService = AuthService.instance() {
    firebaseAuth.onAuthStateChanged.listen(_onAuthStateChanged);
  }

  Status _status = Status.Unauthenticated;
  Firestore firestore;
  FirebaseAuth firebaseAuth;
  UserService userService;
  User _user;
  FirebaseUser _firebaseUser;
  AuthService authService;

  static CurrentUserModel of(BuildContext context) =>
      ScopedModel.of<CurrentUserModel>(context);

  User get user => _user;
  Status get status => _status;
  FirebaseUser get firebaseUser => _firebaseUser;

  Future<void> signIn() {
    return authService.signInWithGoogle();
  }

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

  Future<void> register(Map<String, String> formData) async {
    await userService.createUser(_firebaseUser.uid, formData);
  }

  Future<void> _onAuthStateChanged(FirebaseUser firebaseUser) async {
    if (firebaseUser == null) {
      _firebaseUser = null;
      _user = null;
      _status = Status.Unauthenticated;
    } else {
      if (firebaseUser.uid != _firebaseUser?.uid) {
        _firebaseUser = firebaseUser;
      }
      _status = Status.Unregistered;
      if (firebaseUser.uid != _user?.id) {
        _user = await userService.getById(_firebaseUser.uid);
      }
      if (_user != null) {
        _status = Status.Authenticated;
      }
    }

    notifyListeners();
    _listenToUserChanges();
  }

  void _onUserDocumentChange(DocumentSnapshot snapshot) {
    if (snapshot.exists) {
      _user = User.fromDocumentSnapshot(snapshot.documentID, snapshot.data);
      _status = Status.Authenticated;
    } else {
      _user = null;
      _status = Status.Unregistered;
    }
    notifyListeners();
  }

  void _listenToUserChanges() {
    if (_firebaseUser == null) {
      return;
    }
    // TODO(abraham): Does this need any cleanup if uid changes?
    firestore
        .collection('users')
        .document(_firebaseUser.uid)
        .snapshots()
        .listen(_onUserDocumentChange);
  }
}

I have created a named constructor so that I can call CurrentUserModel.instance() and it will use the default services. The number of services this relies on is large and I think can be cleaned up in the future.

The first neat bit is firebaseAuth.onAuthStateChanged.listen(_onAuthStateChanged). This adds a listener to FirebaseAuth and anytime the user signs in or signs out the callback will be called.

There is a static of method for the convenience of being able to call CurrentUserModel.of(context) for easy access to the state.

static CurrentUserModel of(BuildContext context) =>
    ScopedModel.of<CurrentUserModel>(context);

The signIn, signOut, and register methods perform as they are named. They do consolidate a number of service dependencies into CurrentUserModel but I'm not sure this is the best place to have them.

_onAuthStateChanged is the work horse of this class. Anytime FirebaseAuth changes, this gets called and has to figure out what's going on. In essence if there is no user, it clears all the state, if the user is new or different it tries to get the User document. Lastly it will notify children that the state has changed and will start listening to changes to the User document.

_listenToUserChanges will listen to Firestore for changes to the authenticated user's document. One neat aspect is it can start listening before the document even exists and will get notified when it's created (from registering).

Lastly in CurrentUserModel is _onUserDocumentChange. If the document exists the user is authenticated and registered.

I also added a User model. It doesn't do much yet but handles taking a Firestore document and and turning it into a more manageable class instance.

To make implementation easier, I added a SignOutAction widget to the AppBar in HomePage. This simply renders an Icon and calls CurrentUserModel.of(context).signOut() on tap.

Another change in HomePage is to wrap the SignInFab widget in a ScopedModelDescendant<CurrentUserModel>. This will cause it to get rebuilt when CurrentUserModel notifies its children of state changes. The builder callback has to return a Widget so I just return an empty Container if the user is authenticated.

Widget _floatingActionButton() {
  return ScopedModelDescendant<CurrentUserModel>(
    builder: (
      BuildContext context,
      Widget child,
      CurrentUserModel model,
    ) =>
        model.user == null ? const SignInFab() : Container(),
  );
}

RegisterPage similarly gets updated with a ScopedModelDescendant<CurrentUserModel> wrapper. This use is being a little smarter and will show the form if the user is authenticated but not registered and a welcome message once the user finishes registering. This message will need to be improved.

ScopedModelDescendant<CurrentUserModel>(
  builder: (
    BuildContext context,
    Widget child,
    CurrentUserModel model,
  ) {
    if (model.status == Status.Unregistered) {
      return const RegisterForm();
    } else if (model.status == Status.Authenticated) {
      return const Center(
        child: Text('Welcome'),
      );
    } else {
      return const CircularProgressIndicator();
    }
  },
)

I haven’t fleshed out all the tests yet but a lot of the code now has dependencies on CurrentUserModel so I added a simple appMock to makes this easier.

ScopedModel<CurrentUserModel> appMock({
  @required Widget child,
  @required CurrentUserModel mock,
}) {
  return ScopedModel<CurrentUserModel>(
    model: mock,
    child: MaterialApp(
      home: Scaffold(
        body: child,
      ),
      routes: <String, WidgetBuilder>{
        RegisterPage.routeName: (BuildContext context) => const RegisterPage(),
      },
    ),
  );
}

Code changes

• #66 Create user in Firestore

Originally published on bendyworks.com.

Today was supposed to be simple. Take form values, save them in Firestore. It works but the current implementation is messy so I’m going to walk through the work in progress (WIP) code and refactor it tomorrow.

The larger architectural change was creating a UserService to handle getting and creating users. This approach works but creates a complex dependency injection pattern that requires a lot of duplicate code and mocking in test. These are some of the current changes and what I don't like about the implementation:

RegisterPage now takes a UserService which in turn takes FirebaseAuth and Firestore instances. Doing this once wouldn't be so bad but I've had to instantiate UserService in several places. I'd like to find a better approach than UserService.

RegisterPage(
  userService: UserService(
    firebaseAuth: FirebaseAuth.instance,
    firestore: Firestore.instance,
  ),
)

RegisterForm was updated to call FormState.save on submit if the form is valid. _submit will also grab photoUrl and set it directly on _formData.

Future<void> _submit() async {
  if (_formKey.currentState.validate()) {
    _formKey.currentState.save();
    _formData['photoUrl'] = widget.firebaseUser.photoUrl;

    final bool result =
        await widget.userService.addUser(widget.firebaseUser.uid, _formData);
    if (result) {
      _showSnackBar(context, 'Welcome ${_formData['fullName']}');
      Navigator.pushNamed(context, HomePage.routeName);
    } else {
      _showSnackBar(context, 'Error submitting form');
    }
  }
}

_formData['key'] is clumsy so I'd like to refactor it to use _formData.key instead. The onSaved callback on TextFormField takes the input value and sets it on _formData.

TextFormField(
  initialValue: widget.firebaseUser.displayName,
  decoration: const InputDecoration(
    labelText: 'Full name',
  ),
    validator: (String value) {
      if (value.trim().isEmpty) {
      return 'Full name is required';
    }
  },
  onSaved: (String value) => _formData['fullName'] = value,
)

RegisterForm now takes a FirebaseUser and a UserService. You might notice the repetitiveness repetitiveness of UserService. The FirebaseUser is used to pre-fill the form name fields so users can just submit the form if they want to use their Google registered names.

Here is how RegisterForm is called in RegisterPage:

Widget _formWhenReady() {
  return _firebaseUser == null
      ? const CircularProgressIndicator()
      : RegisterForm(
          firebaseUser: _firebaseUser,
          userService: UserService(
            firestore: Firestore.instance,
            firebaseAuth: FirebaseAuth.instance,
          ),
        );
}

RegisterPage has a new _getCurrentUser method that will set the _firebaseUser state. Until _firebaseUser is set, CircularProgressIndicator is displayed. Checking if there is a current user is going to happen a lot in the application so this needs to be much simpler to do.

Future<void> _getCurrentUser() async {
  final FirebaseUser user = await widget.userService.currentUser();
  setState(() {
    _firebaseUser = user;
  });
}

UserService itself is fairly simple.

class UserService {
  UserService({
    @required this.firestore,
    @required this.firebaseAuth,
  });

  final Firestore firestore;
  final FirebaseAuth firebaseAuth;

  Future<FirebaseUser> currentUser() {
    return firebaseAuth.currentUser();
  }

  Future<bool> addUser(String uid, Map<String, String> formData) async {
    try {
      await firestore
          .collection('users')
          .document(uid)
          .setData(_newUserData(formData));
      return true;
    } catch (e) {
      return false;
    }
  }

  Map<String, dynamic> _newUserData(Map<String, String> formData) {
    return <String, dynamic>{}
      ..addAll(formData)
      ..addAll(<String, dynamic>{
        'agreedToTermsAt': FieldValue.serverTimestamp(),
        'createdAt': FieldValue.serverTimestamp(),
        'updatedAt': FieldValue.serverTimestamp(),
      });
  }
}

It takes Firestore and FirebaseAuth instances so that it can get the currentUser or create a new document with setData. I don't like having to inject UserService in multiple places and I would like to cleanup the formData type.

FieldValue.serverTimestamp() is a special Firestore value that will use the server timestamp when the document gets saved.

In the tests I’m now having to mock a lot more stuff. This is making the tests more verbose and harder to read and change. Come back tomorrow to see the exciting conclusion of the refactor.

Code changes

• #66 9a631f7 Create user in Firestore

Originally published on bendyworks.com.

When a user signs in with Google I’m going to create a user document in Firestore. Each authenticated user should only be able to create one user document. These documents will eventually be readable by other users so Firestore needs to have server(less)-side validation to keep the data as correct as possible.

Right now I’m working on registering users so I’m only going to implement create rules, not read, update, etc.

match /users/{userId} {
  allow create: if isOwner(userId) &&
                  // TODO: enable after bug fix https://github.com/firebase/firebase-tools/issues/1073
                  //  validCreateTimestamps() &&
                  validCreateUser();
}

This will allow user documents to be created if the owner has the same ID and the document being created passes validation.

Validation of timestamps is being skipped because of a bug in the emulator that causes tests to hang. I’ve also been considering moving createdAt and updatedAt timestamps into Cloud Functions but I'm not ready to make that commitment yet.

User document creation is primarily validated with two tests. One to make sure an authenticated user can create their own document and one to make sure a user can’t create a document for someone else.

@test
async 'can create self'() {
  const uid = this.user().uid;
  const user = this.db({ uid }).collection('users').doc(uid);
  await firebase.assertSucceeds(user.set(this.validUser));
}

@test
async 'can not create someone else'() {
  const user = this.db(this.user()).collection('users').doc(uuid.v4());
  await firebase.assertFails(user.set(this.validUser));
}

Additionally, there are several tests that iterate over a number of invalid values and assert they fail.

There are a number of helper methods I’ve defined in firestore.rules:

function isOwner(userId) {
  return request.auth != null &&
          request.auth.uid == userId;
}

The isOwner helper checks to see if the user document ID matches that of the current authenticated user.

function validString(key) {
  return data()[key].trim() == data()[key] &&
          data()[key].size() > 0;
}

The validString helper checks to see that a required string has a value.

function validUrl(url) {
  return url.matches('https://[a-zA-Z].+');
}

The validUrl helper checks that a string starts with https://. I'm pretty sure this will not correctly validate some URLs but this value should generally be set to a Google CDN so I don't think invalid hosts will come up.

function validCreateTimestamps() {
  return data().updatedAt == request.time &&
          data().createdAt == request.time;
}

validCreateTimestamps checks that the updatedAt and createdAt values match the time on the request. This works because the client will set that value with a constant that Firestore will replace with the current time.

function validUser() {
  // TODO: prevent extra fields
  return validString('nickname') &&
          validString('fullName') &&
          validString('photoUrl') &&
          validUrl(data().photoUrl);
}

function validCreateUser() {
  return validUser() &&
          data().agreedToTermsAt == request.time;
}

The final two helpers are to validate a user document leveraging all the other helpers. One TODO I've left for the future is to make sure all fields on the document are on an allowed list.

I’m not completely happy with how the server tests are currently organized. I will probably do some cleanup in the future to try and make everything more elegant. I plan on adding faker.js for fun too.

Code changes

• #64 Add Firestore rules for creating users

Originally published on bendyworks.com.

One aspect of using Firestore for my data backend means I need to be certain my security rules are configured correctly. Otherwise users might be able to read or write date they shouldn’t have access to.

A few days ago I set up Firestore in the server directory. I'm going to continue that work and configure tests to run on the Firestore emulator based off of the typescript-qickstart example.

In package.json I'll add some devDependencies and define several scripts. Node package scripts can be run with npm run <name>.

• postinstall will set up the Firestore emulator after npm install is run in the scripts directory
• start-emulator will will do just that
• pretest will compile the project's TypeScript files before the test script is run
• test will run the actual tests within the test directory using mocha test runner
• posttest will cleanup the test *.js and *.js.map files created during pretest
• ci uses a handy Node package start-server-and-test to start the emulator, wait for it to be ready, run the tests, and then shut down

I created a new tsconfig.json file with npx tsc --init. The two main changes I made were to target es6 instead of es5 and enable experimentalDecorators for the mocha-typescript package.

Within test/firestore.ts I'm defining a FirestoreTest class that will handle loading the rules, and setting up and tearing down test databases. mocha-typescript will use a new instance of this class for each test. Each instance will use a different projectId to avoid different test runs from interfering with each other.

The Cloud Firestore emulator persists data. This might impact your results. To run tests independently, assign a different project ID for each, independent test. When you call firebase.initializeAdminApp or firebase.initializeTestApp, append a user ID, timestamp, or random integer to the projectID.

Test your security rules

I changed firestore.rules so there was an allowed rule and a denied rule. These will be updated with real rules before the next deploy.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read: if true;
      allow write: if false;
    }
  }
}

The initial tests for the user collection in user_rules_test.ts look like this:

@suite
class Users extends FirestoreTest {
  @test
  async 'can read'() {
    const user = this.db().collection('users').doc('alice');
    await firebase.assertSucceeds(user.get());
  }

  @test
  async 'can not write'() {
    const user = this.db().collection('users').doc('alice');
    await firebase.assertFails(user.set({ nickname: 'alice' }));
  }
}

The @suite, @test, and class style is supported by mocha-typescript. One of the reasons I chose TypeScript instead of JavaScript is because the types are similar to Dart much of the time.

I created a success test and a failure test to as proof of concept while setting up all the tooling. They get a database handle and assert that it can be read or written to.

I can now run npm run ci and see the following:

  Users
    ✓ can read (162ms)
    ✓ can not write (95ms)
  2 passing (462ms)

The next step will be to get these tests running along with the existing CI.

Code changes

• #62 Set up Firestore rules tests

Originally published on bendyworks.com.

For this festive day of Christmas, I’m going to do something more fun and add a fancy icon. For android I will be using an adaptive icon so that it looks good in any shape and has a nice wiggle of movement.

A big thank you goes to @tommy_emo_ for creating this awesome design.

There is a nice flutter_launcher_icons package that makes the technical implementation easy.

To start, require flutter_launcher_icons as a dev_dependency in pubspec.yaml. Then there will be a new flutter_icons key added with several values.

flutter_icons:
  android: true
  ios: true
  image_path_android: assets/icon/ic_launcher_xxxhdpi.png
  image_path_ios: assets/icon/ios.png
  adaptive_icon_background: assets/icon/ic_background.png
  adaptive_icon_foreground: assets/icon/ic_foreground.png

android and ios set to true specifies that the tool should build icons for both Android and iOS.

Then there are four images defined:

• image_path_android will be used for the Android app and should be a full icon with transparent edges. This will get several sizes generated by the tool so I use the xxxhdpi size as the source image.
• image_path_ios will be used for the iOS app and should not have any transparent edges. It is the same as the adaptive icon but with both layers in one image.
• adaptive_icon_background is the background scene of the adaptive icon. For Birb it's the sun and hills.
• adaptive_icon_foreground is the forground of the adaptive icon. For Birb it's the bird.

Once those four images were added to the assets/icon directory I ran the flutter_launcher_icons tool to generate the correct assets and added all the changes to git.

$ flutter packages pub run flutter_launcher_icons:main
Android minSdkVersion = 16
Creating default icons Android
Overwriting the default Android launcher icon with a new icon
Creating adaptive icons Android
Overwriting default iOS launcher icon with new icon

The new icon on Android’s home screen with a rounded square shape:

The new icon in Android’s app switcher with a circle shape:

The new icon on iOS’s home screen:

The new icon in iOS’s app switcher:

Code changes

• #61 Add adaptive icons

Originally published on bendyworks.com.

After a user signs in with Google and registers, their info needs to be saved to a databasee. I’m going to use Firebase Firestore as my backend. Within the birb codebase I'm going to create a server directory and initialize a Firestore project inside it using firebase-tools.

$ firebase init

######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

/home/abraham/Development/birb

? Which Firebase CLI features do you want to setup for this folder? Press Space to select features, then Enter to confirm your choices.
 ◯ Database: Deploy Firebase Realtime Database Rules
❯◉ Firestore: Deploy rules and create indexes for Firestore
 ◯ Functions: Configure and deploy Cloud Functions
 ◯ Hosting: Configure and deploy Firebase Hosting sites
 ◯ Storage: Deploy Cloud Storage security rules

I choose the same Firebase project being used for authentication, the default Firestore Rules file, and the default Firestore indexes file. By default .firebaserc is not .gitignored. I have added my .firebasrc to .gitignore because this is an open source project. Anyone who forks Birb will need to set up their own Firebase project.

In the Firebase console I will now enable Firestore for the project.

Here are the default firestore.rules that just say don't allow reads or writes.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Deploying the rules is handled with the firebase-tools Node package.

$ npx firebase deploy

=== Deploying to 'birb-app-dev'...

i  deploying firestore
i  firestore: checking firestore.rules for compilation errors...
i  firestore: reading indexes from firestore.indexes.json...
✔  firestore: rules file firestore.rules compiled successfully
i  firestore: uploading rules firestore.rules...
✔  firestore: deployed indexes in firestore.indexes.json successfully
✔  firestore: released rules firestore.rules to cloud.firestore

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/birb-app-dev/overview

Installing the cloud_firestore package in pubspec.yaml happens last.

Before integrating with the Flutter code, I’m going to write some rules with so come back soon for that article.

Code changes

• #57 Add Firestore

Originally published on bendyworks.com.

With the new user registration form in place, it’s time to make sure the form is tested and will work as expected.

There are basically five different states that need to be tested.

Default state

This is the view users will first arrive to and here I’m testing that all the components are present as expected.

testWidgets('Renders', (WidgetTester tester) async {
  await tester.pumpWidget(app);

  expect(find.text('Register'), findsOneWidget);
  expect(find.text('I agree to the Terms of Services and Privacy Policy'),
      findsOneWidget);
  expect(find.byType(TextFormField), findsNWidgets(2));
  expect(find.byType(OutlineButton), findsOneWidget);
  expect(find.byType(Checkbox), findsOneWidget);
});

To succesfully submit the form, I require the user to provide a nickname and a full name. In the test those values will be provided with enterText. After filling out the two TextFormFields and submitting the form, I wait a tick for the success SnackBar to render.

testWidgets('Form can be submitted', (WidgetTester tester) async {
  await tester.pumpWidget(app);
  final Finder nickname = find.widgetWithText(TextFormField, 'Nickname');
  final Finder fullName = find.widgetWithText(TextFormField, 'Full name');
  final Finder submit = find.widgetWithText(OutlineButton, 'Register');

  expect(find.text('Form submitted'), findsNothing);

  await tester.enterText(nickname, 'Jess');
  await tester.enterText(fullName, 'Jess Sampson');

  await tester.tap(submit);
  await tester.pump();

  expect(find.text('Form submitted'), findsOneWidget);
});

The success SnackBar is a temporary placeholder so that I have an in-app confirmation the form was submitted. Once user registration logic is in place this messaging to the user will change.

void _submit() {
  if (_formKey.currentState.validate()) {
    const SnackBar snackBar = SnackBar(content: Text('Form submitted'));

    Scaffold.of(context).showSnackBar(snackBar);
  }
}

Required fields

Next there are two tests to make sure the nickname and full name fields are required. This checks that the required message was displayed and that the success message was not displayed.

testWidgets('Form requires nickname', (WidgetTester tester) async {
  await tester.pumpWidget(app);
  final Finder submit = find.widgetWithText(OutlineButton, 'Register');
  await tester.tap(submit);
  await tester.pump();

expect(find.text('Nickname is required'), findsOneWidget);
  expect(find.text('Form submitted'), findsNothing);
});

There are some improvements that could be made this error display. If a user focuses an errored TextFormField and enters a letter, the error message should disappear. I've created an issue to implement this in the future.

If a user disables the Terms of Service/Privacy Policy checkbox, they are not longer permitted to register. Here I am testing that the submit button is disabled if the checkbox is unchecked.

The WidgetTester#widget method is a way to get a reference to a finder's actual widget. This is how I'm testing to see if the submit button is disabled. Usually you should test UI that the user can see but in this case the state of the button is conveyed to the user through its styling.

testWidgets('Submit disabled if TOS unchecked', (WidgetTester tester) async {
  await tester.pumpWidget(app);
  final Finder submit = find.widgetWithText(OutlineButton, 'Register');
  final Finder tos = find.byType(Checkbox);

  expect(tester.widget<OutlineButton>(submit).enabled, isTrue);

  await tester.tap(tos);
  await tester.tap(submit);
  await tester.pump();

  expect(tester.widget<OutlineButton>(submit).enabled, isFalse);
  expect(find.text('Form submitted'), findsNothing);
});

Code changes

• #54 Add registration form

Originally published on bendyworks.com.

After a user navigates to the registration page, they should be able to enter their name and agree to the Terms of Service/Privacy Policy.

I’ll start by updating RegisterPage to render a RegisterForm widget that I'll create in a minute. Wrapped around the form is a SingleChildScrollView. This scroll view is for when the keyboard in open and the form can't fit in the visible space.

Scaffold(
  appBar: AppBar(
    title: const Text('Register'),
    centerTitle: true,
    elevation: 0.0,
  ),
  body: const SingleChildScrollView(
    child: Padding(
      padding: EdgeInsets.fromLTRB(16.0, 16.0, 16.0, 8.0),
      child: RegisterForm(),
    ),
  ),
);

The majority of the work is going to be handled in the new RegisterForm. The initial StatefulWidget structure is based on Flutter's building a form with validsation recipe.

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

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

class _RegisterFormState extends State<RegisterForm> {
  final GlobalKey<FormState> _formKey = GlobalKey<FormState>();
  bool _agreedToTOS = true;

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.start,
        children: <Widget>[
          TextFormField(
            decoration: const InputDecoration(
              labelText: 'Nickname',
            ),
            validator: (String value) {
              if (value.trim().isEmpty) {
                return 'Nickname is required';
              }
            },
          ),
          const SizedBox(height: 16.0),
          TextFormField(
            decoration: const InputDecoration(
              labelText: 'Full name',
            ),
            validator: (String value) {
              if (value.trim().isEmpty) {
                return 'Full name is required';
              }
            },
          ),
          Padding(
            padding: const EdgeInsets.symmetric(vertical: 16.0),
            child: Row(
              children: <Widget>[
                Checkbox(
                  value: _agreedToTOS,
                  onChanged: _setAgreedToTOS,
                ),
                GestureDetector(
                  onTap: () => _setAgreedToTOS(!_agreedToTOS),
                  child: const Text(
                    'I agree to the Terms of Services and Privacy Policy',
                  ),
                ),
              ],
            ),
          ),
          Row(
            children: <Widget>[
              const Spacer(),
              OutlineButton(
                highlightedBorderColor: Colors.black,
                onPressed: _submittable() ? _submit : null,
                child: const Text('Register'),
              ),
            ],
          ),
        ],
      ),
    );
  }

  bool _submittable() {
    return _agreedToTOS;
  }

  void _submit() {
    _formKey.currentState.validate();
    print('Form submitted');
  }

  void _setAgreedToTOS(bool newValue) {
    setState(() {
      _agreedToTOS = newValue;
    });
  }
}

It starts out with a GlobalKey to uniquely identify the form. This will be used later on to validate the state of the form.

There is also _agreedToTOS, this is a boolean property that is updated to match if the TOS/PP checkbox is checked. If a user unchecks the checkbox, this boolean will turn to false and the submit button will be disabled.

That brings up an intersting API design for OutlinedButton:

If the onPressed callback is null, then the button will be disabled and by default will resemble a flat button in the disabledColor.

So if _agreedToTOS is true, _submittable will be true and the button will have a onPressed callback. If the value is false, the callback will be set to null and the button will be in a disabled state`.

OutlineButton(
  highlightedBorderColor: Colors.black,
  onPressed: _submittable() ? _submit : null,
  child: const Text('Register'),
)

The TextFormFields are pretty straightforward. They get some decoration with a labelText since you should always label your inputs. They also get a validator that just checks to see if it has a value or not.

TextFormField(
  decoration: const InputDecoration(
    labelText: 'Nickname',
  ),
  validator: (String value) {
    if (value.trim().isEmpty) {
      return 'Nickname is required';
    }
  },
),

I choose to go with nickname and full name because I don't want to make assumptions about names.

TextFormFields are by default filled but I like outlined so I'm updating the theme. With the addition of these theme changes, the ThemeData definition was growing pretty large so I moved it to its own theme.dart file.

ThemeData(
  brightness: Brightness.light,
  primaryColor: Colors.white,
  accentColor: Colors.white,
  scaffoldBackgroundColor: Colors.white,
  textSelectionHandleColor: Colors.black,
  textSelectionColor: Colors.black12,
  cursorColor: Colors.black,
  toggleableActiveColor: Colors.black,
  inputDecorationTheme: InputDecorationTheme(
    border: const OutlineInputBorder(
      borderSide: BorderSide(color: Colors.black),
    ),
    enabledBorder: OutlineInputBorder(
      borderSide: BorderSide(color: Colors.black.withOpacity(0.1)),
    ),
    focusedBorder: const OutlineInputBorder(
      borderSide: BorderSide(color: Colors.black),
    ),
    labelStyle: const TextStyle(
      color: Colors.black,
    ),
  ),
);

The important change is the addition of inputDecorationTheme. This sets the border style to be outlined and customizes the color based on the state of the input.

There are a couple of other theme changes:

• toggleableActiveColor changes the color of the checkbox.
• cursorColor changes the color of the blinking cursor in an input.
• textSelectionColor changes the highlight color when text is selected.
• textSelectionHandleColor changes the color of the handlers to select more or less text.

One addition I made was to wrap the text for the checkbox in a GestureDetector so that if a user taps on the label, it will toggle the checkbox value.

GestureDetector(
  onTap: () => _setAgreedToTOS(!_agreedToTOS),
  child: const Text(
    'I agree to the Terms of Services and Privacy Policy',
  ),
)

Here are some screenshots of the registration form in several different states:

Empty form:

Filled out form:

Disabled form:

Form with errors

Come back tomorrow to see how I’ll test the various states of the form.

Code changes

• #54 Add registration form