TODD KERPELMAN: Hey there, Android developers.
Interested in getting started with Firebase
in your Android apps?
Well, you've come to the right place.
Let's get started on this episode of "Firecasts."
[MUSIC PLAYING]
So this here is my little sample app.
I've got a button that I can click on
and some text that updates, and I'm
going to get it set up to start working with Firebase.
Go ahead and grab your own basic app to work with.
It doesn't really have to look like mine.
Honestly, as long as it's some kind of Android app,
you should be fine.
Now, there are two main parts to getting the Firebase platform
up and running, adding your app to the Firebase console
and installing the SDK.
And there are two ways to do that,
either by heading over to the Firebase console directly
or by using the Firebase Assistant in Android Studio.
Now, we've made some recent improvements
to the Firebase Assistant that's made it easier to work with.
But personally I think it's worth
taking the time to get to know the Firebase console.
So that's what we're going to do here.
So let's get started.
And as with most projects, we get
to start with the most exciting part, and that's making sure
my app fulfills all the minimum requirements and prerequisites.
[APPLAUSE]
I know.
It's not even my birthday!
So first off, let's head over to the documentation.
And here I can see the various API targets and tools
that I need to get started.
Obviously, depending on when you're watching this video,
exact version numbers might look slightly different.
So go with what you see in the documentation,
not with what I'm saying in this video.
So first, let's see if my Android Studio is mostly
up to date.
I just recently updated to version 3.6.2,
and it looks like this is still the latest version of Android
studio so I'm good here.
Next, it looks like I need to target
a minimum API of 16 or later.
Let me open up my app-level build.gradle file.
And here I can see my minimum SDK is version 19,
so that's OK.
I also need to make sure I'm running Gradle 4.1 or later.
I can find that out by opening my gradle-wrapper.properties
file here.
And it looks like I have version 5.6.4, so that's good.
Next, I need to make sure I'm using
the new and improved AndroidX support libraries
and have the right setting in my project to support those.
So I can make sure I have the AndroidX enabled
by opening up my gradle.properties file
and looking for this line here.
And then let's make sure I'm using an up-to-date version
of the Gradle plugin.
And I could find this in my project-level build.gradle
file, and this looks good.
And finally, I need to make sure my compileSdkVersion is
version 28 or later.
I'll go back to my app-level Gradle file,
and it looks like I'm good there, too.
Finally, since I'm going to run this on an emulator,
the documentation recommends that I
run this on one with Google Play available.
I'll pick this Pixel 3a running Android P from my ABD Manager.
But for best results, go ahead and pick any device
with the Play Store icon here.
All right.
Time to start creating a project.
In order to do that, let's visit the console over
at firebase.google.com/console.
Again, the UI here might look a little different
than what you have on your screen,
but the general concepts should remain the same.
Now, when you first visit the Firebase console,
you'll see a few options here for what to do next.
Depending on your situation, you might
see a list of existing Firebase projects,
or you might just have an Add Project button.
I'm going to go ahead and click that,
because I do want to create a new project.
But before we go further, let me take a moment
to explain the difference between projects and apps.
A project can contain one or more apps.
All apps in the same project use the same Cloud Firestore,
Realtime Database, and cloud storage back-ends,
and you can view combined analytics data
across all apps in the same project.
You can also use features like Firebase Cloud Messaging
or in-app messaging to talk to all of your apps at once.
You don't have to, but you can, which is sometimes convenient.
So our recommendation is, if you've
got versions of the same app on different platforms,
such as Android, iOS, and the web,
you'll want to connect each of those platform-specific apps
to the same Firebase project.
This way, your users can access the same data
if they switch back and forth between different versions
of your app, and you can use different Firebase products,
like Remote Config or FCM, to target all apps at once, and so
on.
On the other hand, if your apps really are different,
and you don't need to share that much data between them,
you should put those in different Firebase projects.
And for those of you building white-label or multi-tenant
apps, we generally recommend using a separate Firebase
project for each of your customers
in order to keep that data nicely separated.
So if your iOS or web team has already created a Firebase
project for their app, you should probably
just select that project and add your Android app to it.
But if you're the first one to be adding Firebase capabilities
to your app, lucky you.
You get to be the one to create the new Firebase project,
and that's what I'm going to do here.
So I'm going to create a new project here
I could give it a name, although you'll
notice I also have this dropdown box underneath the name.
This gives me the option to add Firebase features
to any existing Google Cloud projects I have access to.
Now, this will still keep all the capabilities
of your existing Google Cloud project,
while adding in the new services needed for Firebase.
So if you're working on a project
that you've already set up through Google Cloud,
make sure you pick that.
Don't create a new Firebase project.
In my case, I am starting a brand-new project,
so I'll type in a new name.
And you can see, it's giving me a little ID string here,
which will get updated as I type.
This is the project ID, which is a globally unique identifier
for your project across Firebase and Google Cloud.
It's not really publicly facing, so don't worry too much.
If you see random characters at the end or anything like this.
It doesn't really matter.
I'm going to click on the Continue button,
and now I get to choose whether or not to add
Google Analytics to my project.
Enabling Analytics will allow me to use
a number of useful features, such as A/B testing, running
Firebase predictions, and getting crash-free user
reports.
If I don't enable Analytics, I won't
be able to use those features.
It's totally optional, so go with whatever works for you.
Personally, I'm going to keep Analytics enabled.
Now, if you do, you're going to need to associate this project
with an account.
Now, a Google Analytics account isn't an account like a Gmail
account or anything.
It's really just a folder of Analytics projects.
It's mostly just there for organizational purposes.
Some developers like to have separate accounts
for each project.
Me, I have one for all of my test projects.
And so that's where this is going.
Now I can proceed to the next step, which is actually
creating the project.
Firebase will think for a few moments,
and then I will have a shiny new project to work with.
Ooh, it still has that new-project smell.
[SNIFFS]
Mmm.
OK, the next step is actually adding my Android app
to this project I'm going to go ahead and click on the Android
icon here, and I have a few fields to fill out.
First step, adding my Android package name,
also known as your application ID.
In my case it's com.example.buttonclicker,
but go ahead and use your own package name here.
The app nickname is strictly internal and just
a way of identifying my app in a user-friendly way,
in the Firebase console.
I'm going to go ahead and call it Button Clicker Android.
Finally, I'm being asked to optionally add
the SHA-1 hash of my debug signing certificate,
so my app can kind of prove that it belongs to me.
Yeah, that's an oversimplification.
Go check out the docs for a real answer.
Note that this is optional.
It's really only used in a few situations,
like Firebase Dynamic Links and Google sign-in,
so you can leave it out or provide it later
in your Firebase project settings.
In fact, I kind of recommend leaving this out
until you need it, because you can't
have the same combination of package name and SHA-1
hash in more than one place.
And if somebody else on your project team
ends up registering your app in a test project with your shared
production key, and then decide you want to register it
in a different project later on, you're
going to have to hunt down that original project
and delete the signature, and that might be kind of a hassle,
particularly if you have a lot of folks in your company
that have access to that SHA-1.
So you know what?
I'm not even going to do this right now.
If you want to do it, follow the instructions at the link here.
But for now, I'm going to move on to the next step, which
is to download this JSON file.
I'm going to download google-services.json
by clicking this button.
And then I'm going to drag it into the right place
in my Android project.
Let's see.
Here on my project panel, I'm going
to switch my view from Android to project,
which gives me more of a file-system-y view
of my project.
And then I'm going to drag that JSON file I just downloaded
into my button-clicker/app folder.
Now, if we look at this file, you
can see that it basically contains a bunch of constants
that the Firebase SDK needs to configure itself correctly.
It's got the name of my project, the cloud storage
bucket I might use, some OAuth Client IDs, and so on.
Now, none of this is secret, but you should really only share
this file with your team.
If you're making an open-source demo app to be shared publicly
with the world, you'll probably want
anybody who runs their own version of this app
to generate their own version of this file
to hook up to their very own Firebase project.
In my case, I'm not going to be sharing that publicly.
This is just for me personally, which
is why I told Android Studio to go ahead and check it
into my Git repository.
OK, next we're being told to make a few Gradle changes.
In a somewhat unusual move, I guess,
the first change we need to make is in our project-level.gradle
file.
So let me open this one up and confirm first
that Google is listed in my build script repositories
and in my all projects repositories.
And it is.
Then I'll copy this line into my dependency section
to make sure that we're using this plugin here.
By the way, don't confuse this with Google Play services.
This is just the plug-in that parses that JSON file we added.
OK, next up, let's open up our app-level Gradle file.
That's this one.
And this is where you're going to add the dependencies
for the Firebase Android libraries
that you're going to be working with.
Now, the first thing I have to do
is apply that Google services plugin
in my app.gradle file, which I can
do by copying and pasting this line up at the beginning
of my file.
Now, because I said I'm using Analytics in my project,
the console is helpfully giving me
a line I can use to load up the Analytics library.
Again, these numbers will probably
be quite different than what you're seeing
when you watch this video.
So let me copy and paste that into my Gradle file, like so,
and I'll click Sync Now.
Now, if you want to add other libraries,
There's a full list of them over in the Android
Getting Started documentation, down in the Available Libraries
section.
Just make sure you have the right tab selected,
since these library names are sometimes
different between Java and Kotlin.
So in fact, let me copy over this line to use the cloud
storage for Firebase library.
Now, one thing I will point out is,
you can sometimes run into strange and hard-to-track-down
errors if your libraries are out of sync.
So if you go ahead and update one of your libraries
to the latest version, make sure you update the rest of them,
too.
Gee, in fact, it looks like my Analytics library is already
slightly out of date.
So I could update it by copying and pasting this line,
but it looks like Android Studio is helpfully
telling me the same thing.
So let's fix it that way.
And if all this versioning work sounds
like a hassle to deal with, hey, you're in luck.
There's actually a fairly new way to handle all of this
called a Bill of Materials .
Basically, a Bill of Materials is an officially published list
of libraries and their version numbers that
work well together.
So let's try using one of these instead.
So if you have Gradle version 5 or later, and as you recall,
I do, you can head on over to the Bill of Materials
section of the documentation, and then
you can just copy and paste this line here into your Gradle
dependencies.
Then, and this is important, go ahead
and remove your version numbers from
these individual libraries.
Gradle will then find the versions of these libraries
in this Bill of Materials and use those for my app.
Then, when you want to update to the latest version of Firebase,
you just update this one Bill of Materials
version instead of all the individual libraries.
The only thing I noticed is that Android Studio
doesn't seem to tell you when your Bill of Materials
version is old.
You'll need to go to the Android release notes
section of the documentation and see what the latest version is.
That will also tell you exactly what
library version is in each one of these things,
in case you were curious.
OK, so I once again sync my file,
and I should have Firebase properly installed and working.
So how can I make sure I did this right?
Well, let's see.
If I run my app, and I search my logcat for Firebase,
I see this line.
And that should be enough to confirm that Firebase
is properly initialized.
Don't worry too much about this line underneath.
I see that sometimes when I'm working on the emulator.
Finally, you might notice the console is also
waiting to see if it's gotten any contact from your app.
To be honest, I don't always find
this dialog super reliable.
But it seems like it generally finds my app
if I go ahead and move it to the background like this.
Ah, there we go.
But hey, while we're here, let's go ahead and add an Analytics
caller, too.
Now this isn't in Analytics tutorial.
That's a whole separate video.
So I'll keep this simple.
First, let me add a lateinit variable
to store my Analytics reference.
I will initialize it here in my onCreate.
Then let me go ahead and make an Analytics call in my app.
Let's see here.
Maybe I will add a custom event for clicking the button.
Then let me jump into my terminal
and set my logging level to verbose for both FA and FA-SVC.
These are the Analytics tags.
And if you're wondering how I knew this,
I read the documentation.
So now let's restart my app.
Once it starts up, I'm going to head on over to my logcat,
and I can see one Analytics message here.
But I think to properly view my Firebase message logs,
it helps to select Firebase from this dropdown on the right.
Hopefully, you have something similar
in your own version of Android Studio.
And now, when I click my buttons,
these button click events are properly
being logged by the Firebase SDK for Google Analytics.
Nice.
Now that you have Firebase properly set up and initialized
in your app, there's lots more you can do.
You can store, query, and sync data from the cloud using Cloud
Firestore, our globally scalable NoSQL database,
use Firebase Auth to easily sign-in your users from
a variety of sign-in providers, record custom events and user
properties in Analytics, and combine that with Remote Config
to run A/B tests or personalize your app,
add services like Crashlytics-- you can find out exactly where
your app is crashing and why--
and much more.
If you want to find out more, why not
subscribe to our YouTube channel?
You can also check out the Firebase documentation
or play around with any of our sample apps.
Have fun creating, and I will see you soon
on another episode of "Firecasts."
[MUSIC PLAYING]