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]
