Skip to main content

A month of Flutter: WIP save users to Firestore

Originally published on

Today was supposed to be simple. Take form valuessave 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 UserServiceto 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.
  userService: UserService(
    firebaseAuth: FirebaseAuth.instance,
    firestore: Firestore.instance,
RegisterForm was updated to call on submit if the form is valid. _submit will also grab photoUrland set it directly on _formData.
Future<void> _submit() async {
  if (_formKey.currentState.validate()) {;
    _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.
  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 {
    @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
      return true;
    } catch (e) {
      return false;

  Map<String, dynamic> _newUserData(Map<String, String> formData) {
    return <String, dynamic>{}
      ..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 formDatatype.
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


Popular posts from this blog

CloudSense: the Future of Advertising

With the whole cloud taking off and more and more services switching to a push it into the cloud, leave it there until you need it, and pull it out model. I can only imagine what will be switching to this model soon. Oh wait. I can imagine.


Reading an article about how Avril Lavigne is supposed to have a $2 million check "appear" in her mailbox because of the absurd number of streams her videos get from YouTube got me thinking about creator compensation. The problem Avril is having is, a) Google wants to keep the money, and b) Google is having trouble figuring out how to monetize video streams. But on a grander scale it is whoever puts the ads on the page that gets the money not the content creator.

Little known @Twitter and @TwitterAPI tips and tricks

Be sure to comeback as new tips and tricks get added. If you know of anything I missed be sure to let me know.

Static URL for profile images based on screen_name:

* This performs a http redirect to the actual profile image URL. Currently https redirects to http. You can also add "?size={mini | bigger | normal}" to get specific sizes.

Redirect to profile based on user_id:

In_reply_to_status_id mentions:

* In the web interface new mentions are only replies if they start with @screen_name. By pushing @screen_name further along in the string your followers who do not follow @screen_name will still see the status.

Profile image sizes:

* By default you get the original image size you can add _mini, _normal, and …

Installing Storytlr the lifestreaming platform

"Storytlr is an open source lifestreaming and micro blogging platform. You can use it for a single user or it can act as a host for many people all from the same installation."

I've been looking for something like Storytlr for a few months now or at least trying to do it with Drupal. While I love Drupal and FeedAPI I did not want to spend all that time building a lifestream website. So I've been playing around with Storytlr instead and found it very easy. Here is how I got it up and running on a Ubuntu EC2 server. You can also check out the official Storytlr install instructions.

LAMP stack installed and running.Domain setup for a directory.MySQL database and user ready to go.Lets get started!
Get the code: wget tar -xvzf storytlr-0.9.2.tgzYou can find out the latest stable release on Storytlr's downloads page.

Import the database:
Within protected/install is database.sql. Import this into your empt…