Cloud Firestore

We want a database that all apps can read from and write to. Firestore provides a NoSQL database with storage and tools to access that data. Being NoSQL it is highly flexible, maybe more flexible than you’re comfortable with. If you’ve worked with MongoDB, Cassandra, or CouchDB, then you know what we’re talking about here. The major difference with Firestore is the fact that the database itself and its backend engine are maintained by Google instead of by you and me. All we need to do is access the data.

Firestore exposes API endpoints for the data. After your app identifies itself to Firestore, it can read and write data at those endpoints. Kind of sounds like the RESTful interface we discussed in the last chapter, right? Firestore does support an interface that has some features of REST, but it is different enough that I wouldn’t categorize it as RESTful. Instead, we use a Dart library that takes care of the heavy lifting of authenticating our app and setting up private communications. We will call methods in that library like Firestore.get(‘people’) or Firestore.set(‘categories’). This turns out to be much more streamlined once we set it up. (But the setup isn’t super simple.)

Cloud Functions

Your app is almost certainly involved in processing data. Some of those algorithms might be very, very complex. But the fact is that your users’ devices are probably more than capable of handling those things.

“So why not just process everything in my app? ”, you ask. Because if it is on the device, the algorithms could be reverse-engineered by any attacker who downloads your Flutter app. Any secret business processes will be exposed and the logic could be tampered with. Any of your API keys would be stored on your device and could be read. So we would rather not put any sensitive data or processing on the device. Let’s put it on the server where it’s out of reach.

And what about processes or data that require sharing between two or more apps? You need a server for those things.

Cloud Functions are written in JavaScript and run on demand in a Node environment on Google’s servers when certain triggers fire like a record is added to Firestore or updated in Firestore, a user logs in, or someone simply makes an Ajax request to a particular URL .

Authentication

Firebase Authentication makes it (relatively) easy to add authentication to your app. Sure, you could add usernames and passwords to your app by brute force, but you’d have to worry about setting up the user tables and writing the authentication logic and hashing the passwords and handling forgotten passwords and all that. With Firebase Authentication, you get all of that functionality along with authentication via Facebook, Github, Twitter, and of course Google itself. Your users can choose to use their own username/password combinations or even do two-factor authentication by SMS message on their mobile devices .

(1) Creating a Firebase project

After logging in to Google, visit console.firebase.google.com and you’ll see your console which will eventually feature a list of your projects. Click the button to create a new project. Give the project a name like “Learning Flutter” (Figure 12-1). Figure 12-2 shows the project is good to go.

Now imagine that this project had a web interface and a database backend and was being accessed by a Flutter app on iPhones and on Androids. This would be one project with multiple apps. As with multiple projects, Google allows each project to have multiple apps. Each app will have its own settings since the environments all have different demands. Before we’re finished, we’ll set up one each for iOS and Android. But first, we should create our database and at least one collection (aka table).

(2) Creating the database

Go back to your project’s dashboard. You’ll see a menu choice to develop with a database. Go ahead and choose to create a new database (Figure 12-3).

Choose to start it out in test mode just so we can easily verify that our code works. You’ll want to add rules in a real-world app which you can add at any time. Hit “Next”.

This step is asking where the bulk of your users will be physically located (Figure 12-4). It guesses based on your current location, and honestly, any location will work fine. Just take the default and hit “Done”. This creates the database.

A NoSQL database does have keys and values, but they do not have a fixed structure. In other words, each document in a collection might have different fields than others in that same collection. This is the major difference between traditional databases and NoSQL databases and is the toughest thing to get used to.

Now we’ll create a collection. Hit Start Collection and give it an id. Then you’ll be able to add one or more documents (Figure 12-5).

You’ll now be able to see your lone document in the Cloud Firestore viewer. From here, you can add documents, delete documents, and alter documents.

It’s nice that we can maintain the database right from the Firebase web site, but our goal is obviously to do that from our app. So we must configure our iOS and Android apps to read from Cloud Firestore.

(3) Creating an iOS app

On the overview page for your project, you should see buttons for creating apps in your project (Figure 12-6).

Click the iOS button.

Provide a name for the app (Figure 12-7).

After you register the app, you’ll see a view like Figure 12-8.

Download GoogleService-info.plist and store it in the iOS/Runner/Runner directory (Figure 12-8). You’ll know you’re in the right folder when you see Info.plist. Don’t be distracted by the diagram they show you. It will look different because they’re showing the Xcode version of a project, but you’re working in a Flutter project.

Connecting to Firebase will be easier if we use certain tools provided to us by Google. This means they need to be downloaded and installed into our iOS/xcode project. iOS uses CocoaPods to manage dependencies.³ We should create a Podfile if we don’t already have one. Follow the instructions next to add a Podfile and create the .xcworkspace file (Figure 12-9).

Copy this code in Figure 12-10 so your app reaches out to Firebase to connect on startup. This is the firebase login logic.

At this point, when your app runs, it knows which Firebase account and project it is associated with. Only an app with this .plist file will be able to connect to your app. Of course, when you compile the app and distribute it to devices through the Apple App Store, they’ll all be connecting to this one Firebase account. This is normal and to be expected. Each user who runs it will check in with Firebase. You should see activity in your Firebase console. Firebase is now listening for it and will provide you with analytics data.

Since we’re creating a cross-platform app, we should probably also do the same with Android. Remember, they’re completely different environments so the steps will be different.

(4) Creating an Android app

Remember where we chose iOS earlier? Now click the Android button shown in Figure 12-11.

Although the steps are different, the application id or package name should be the same. Enter it into the dialog (Figure 12-12).

That SHA-1 certificate is optional for most applications. You can leave it blank for now but go back and generate the certificate if you need it for Google Sign-in or phone number authentication.

Install the google-services.json file

Going through the next step, the wizard will create a google-services.json file and will tell you where to save it (Figure 12-13).

This file has all kinds of important settings in it, especially the project numbers and app ids that will tell your app where to ask for data from Google Firestore. With all of this in a config file, you won’t have to hard-code it in your app’s source code.

Note that it should be saved in the app folder at the same level as the app-level build-gradle file. Speaking of which, our next step is to edit that file.

Adding to the gradle files

Android projects have Gradle files which manage libraries, much like Podfiles do for iOS. There is a project-level Gradle file and an app-level Gradle file. They are both confusingly named build.gradle (Figure 12-14).

Add this classpath to the dependencies section of the project-level build.gradle file, NOT the one under app:

buildscript {

    dependencies {

        ( other things may be here already )

        classpath 'com.google.gms:google-services:X.Y.Z'

    }

}

Of course, use the latest version number instead of X.Y.Z like earlier. Then add this implementation to the dependencies section of the app-level build.gradle file:

dependencies {

    ( other things will be here already )

    implementation 'com.google.firebase:firebase-core:X.Y.Z'

}

And add this apply plugin to the bottom of the same app-level build.gradle file:

apply plugin: 'com.google.gms.google-services'

Tell the IDE to sync the gradle files. In Android Studio, you’ll see a “Sync now” link. Go ahead and click it .

(5) Adding FlutterFire plugins

Almost there! At this point we have the groundwork laid to use Firebase with our app. We just have to add the Firebase plugins for Flutter and start coding. It turns out that Google provides one common library for Firebase itself and one library plugin for each Firebase product. We’ll need the common library plugin and the Cloud Firestore plugin.

Of course if we use other Firestore products, we’ll need to add the appropriate plugin, but we won’t have to re-do any of the other preceding steps; once for the project is sufficient.

To get a collection

To query

And unfortunately that’s about it. It does not support any fuzzy logic like wildcards, “contains,” or “like.” If you need full-text searching, the Firebase team recommends a third-party service like Algolia. See https://firebase.google.com/docs/firestore/solutions/search for more details.

To upsert

The word “upsert” means that if the document exists, it is updated, but if it does not exist, it is added. Firestore does both of these operations with the setData method.

To delete

Obviously there is nothing returned from the delete so no need for a .then().