Add Firebase to your cross-platform React Native or Flutter app (Google I/O ’18)
Articles Blog

Add Firebase to your cross-platform React Native or Flutter app (Google I/O ’18)

August 29, 2019


[MUSIC PLAYING] KAT FANG: Hi, everyone. I hope you’ve enjoyed
the past three days and are ready for just one
last talk before we all have to leave Google I/O this year. My name is Kat. I’m a software engineer
on the Firebase team. KIANA MCNELLIS: And I’m
Kiana from Firebase Developer Relations. KAT FANG: We as developers
never have enough time and we’re always looking for new
tools to help us build faster. So today, we’re
going to take apps that we have built on
cross-platform frameworks and add Firebase to them to
take them to the next level. KIANA MCNELLIS: So over
the past couple weeks, I’ve been building this app. I think it’s pretty cool. It’s a photo
scavenger hunt where you have a different
category each time, and it gives you
a couple options. So for this one up here on the
screen, we have tech gadgets. So maybe we’ll get an option
between a phone and a laptop to take a picture of. And the neat thing about
this is it was actually written on Flutter, which is a
cross-platform framework that uses Dart, a modern reactive
language, and then it compiles down to native interfaces. So you can still get featured
on either the iOS or Android app stores. KAT FANG: And since I come
from a web background, I’ve built the same
app using React Native. React Native is another
cross-platform framework, but instead of
writing in Dart, I can use JavaScript, which
I’m more comfortable with. There are a lot of different
cross-platform apps. You might have heard– cross-platform frameworks. You might have heard
of Xamarin or Ionic. Today, we’re focused on
Flutter and React Native. All of these allow you to
develop in one code base, but target multiple platforms. And we can choose
the one which we’re most familiar with the language
and the tooling around in. So long as we don’t need down
to the metal performance, this can save us lots of
time if we develop this way. So before we get
too much further, let’s check out a demo
of the app we have built. So this is a Flutter app
that Kiana has been building. We have this nice
tutorial, which tells us we’ll be taking pictures,
and along the way we’ll get some trophies. Here is our progress screen. We can see the different
levels we’ve already completed. And let’s go ahead and
check out the next level. Here we’ll need to upload
a picture of a hat. Nice hat. And this goes to the server,
verifies it’s actually a hat, and tells our app
that we can continue. And here we have won
our first trophy. Awesome. So let’s go back to our slides. KIANA MCNELLIS: So I think
we built a pretty nice app, don’t you? KAT FANG: Yeah. KIANA MCNELLIS: But
unfortunately, this is our user base right now–
me, you, and a couple friends from our office. How can we make our user
base look like this, with users from all
over the world engaged in actively using it? Unfortunately, right
now our user base is actually more
looking like this. The people who we
have gotten to use it don’t have a great experience,
and they’re not even getting to the second level. So how do we increase
our user engagement? We’ve tried adding some ads. I’ve done some
sharing with friends. But what’s next? KAT FANG: This is where
Firebase can help us. Firebase, like the frameworks
we’ve been building in, is also cross-platform. So it’s a good fit. Flutter and React Native allow
us to build how our app looks and its functionality,
effectively acting as our front end code,
while Firebase provides tools and services that our
apps can connect to, giving us the power
we would normally get by running our own back end. To do this, we’ve
used integrations that already exist. To integrate Firebase
with Flutter, we’re using the
FlutterFire plugin, and to integrate it
with React Native, we use the React
Native Firebase module. This allows us to add all of
the features of Firebase, which can help us
understand our users, discover issues, and tweak
it so that our users will love our app. So let’s go back to the
issue that Kiana mentioned. We have lots of people giving
up, not a whole lot of usage, people are leaving
us bad reviews. It’s not great. It turns out 50% of all issues
that people leave bad reviews for are due to
things like the app crashing or hanging
due to network issues or heavy resource usage. These are all errors that we as
developers can fix and should fix. When I see it in my own app
locally, I can debug it easily. But even if I know these
issues exist in the wild, sometimes it can be hard
to find them because I can’t reproduce them locally. Firebase allows us
to add observability. Google Analytics for
Firebase automatically gives us metrics such
as revenue and week over week retention,
which versions of our app are being used by people. But to gain specific insights,
we can add custom analytics, and this allows
us to track things like what levels
are people reaching, which are the easiest options
in our scavenger hunt. With performance
monitoring, I’ll be able to measure latency. Out the door we get traces
for things like app start and network requests, but
we can add custom traces to get fine-grained
measurements of latency. With Crashlytics, we’ll get
a report every single time a crash happens in the wild. And this is very useful
for finding those issues that people aren’t
reporting to us. With native apps,
we just drop it in and we’ll get the line of code
that the crash happened on. With cross-platform apps, we’ll
have to capture the crashes ourselves, but then we
can use the custom logging functionality of Crashlytics
to log them to the servers. Now analytics and
performance monitoring are both available on
Flutter and React Native, while Crashlytics is
only available on React Native module right now. However, if you like what you
see and you’re using Flutter, all of these are open
source repositories. So feel free to contribute. To streamline our
demo, we’ve already done a little bit of setup. We’ve created our project,
Firehunt, and in our project we’ve created apps for each of
our iOS and Android versions for React Native and Android– React Native and Flutter. We’ve then dropped
in the modules we’ll want to use for Firebase. Here we’re using Firebase Core
for analytics, Performance for performance monitoring, and
Crashlytics needs the Fabric and Crashlytics CocoaPods. For Android, we would be
doing something similar, but using Gradle. And lastly, we’ve done
a little more setup with Crashlytics,
which you can read the documentation for here. OK, so setup all out of the way. Let’s jump to our actual demo. What do we get as soon
as we’ve set this up? We’ll get an overview with
analytics for our apps. But it looks like none of our
apps have very many users. The numbers aren’t going
to be so interesting. So let’s go take a sneak
peak at Bingo Blast, which is an app that’s been out in
the wild a little bit longer. Here’s our analytics
dashboard, and as you can see we have our daily
users in green, our weekly users in purple,
and our monthly users in blue. And we can scroll down to
get other metrics as well, such as how much revenue
the app is making and what versions of the
app people are using. And if we scroll
down to the bottom, we can see where in the world
people are using our app from. So in this case, a
lot of people are playing Bingo Blast in the US,
but also all around the world. We can also take a
look at the Events tab, and this shows us
the user events that are tracked in our app. We get a bunch of these for
free, such as app installs or app removals, and session
starts, but this is also where we’ll be able to add– where we’ll be able to see
our custom analytics events, such as when people level up. If we check out
our audiences, this is where we can
segment our user base and target different Firebase
features to different segments later on. Here we’ve grouped things by
purchasers, and even purchasers by locality. So we can have features which
are targeted specifically to, say, people in Australia. All right, let’s
actually get a look at what adding a custom analytic
event looks like in code. Here we’re using React Native. We’ll be doing
something similar if we were doing this in Flutter. The first thing we’ll need to do
is import our Firebase module. And here we have the
image picker screen. This is the screen which
allows you to pick an image and receives the
verification from the server. If we have the right image,
it will call complete level. And if we have the wrong image,
it will call wrong image. So we want to add a custom
analytics event when someone completes the level. Let’s go ahead and do that. Here we’ve given the
name of our analytics event to be level, the number
that this level is, reached. And we’re calling
Firebase dot analytics dot log event in order
to actually log that to the server. So let’s go ahead
and run our app. Skip the tutorial since
we know what we’re doing. Let’s look for a
cookie, and we’ll use this picture of a
cookie that we took before. Submit that to be verified. And it looks like our
verification worked, and we won a trophy. Awesome. So now let’s take a
look in the console. We can see that these custom
analytics events are coming through in the debug view. And this will give
us a good idea of how our analytics
will be coming in as we add them to our app. So here we can see we have a
bunch of screen views, a bunch of clicks with user
engagement, and finally, we can also see that level 3
has in fact been reached. All right, so while we’re
still in the console, let’s take a look at what we get
from performance monitoring out the gate. I’ve added no custom code. The only thing I did was add
the CocoaPod to my iOS version, or my Gradle dependency
in my Android app, and here we can already see
the sorts of traces we can get. I’ve got no major issues,
but I do a minor issue with app start. It’s taking almost
600 milliseconds. That’s probably a
slow enough start that unless I give
someone a progress screen, it might turn them
off from my app. We can also take a look
at the network requests. And from this we
can see that all of our requests,
our network requests are in fact successful,
but there’s this one here, which is taking two seconds. That’s kind of slow. Let’s dig into it. This is the end point
that verifies our image. And it’s probably
slow because we have to upload a large
image on occasion. It depends on whatever
our user provides. So maybe an
optimization we can make is making our image
smaller, or somehow speeding up our machine learning
algorithm on the back end. That, however, is a problem
for my back end self tomorrow or the day afterwards. OK, so what about Crashlytics? That was a good overview
of performance monitoring. Let’s go back to
the code and see how we can add
Crashlytics to pick up the crashes that are happening. If we go see our app and
check out the Trophies tab, we’ll see that there’s a crash. This was reported to me
by Kiana, thankfully, a couple hours ago. And we can use this to see how
Crashlytics actually works. So again, we’re in
our trophy screen. The first thing we’re going
to do is import Firebase. And when we get an error,
we’ll use the global handler to capture it and log
it to Crashlytics. Here we’ll grab the stack trace,
log that, and record the error. So now if we run it, we’ll be
able to capture the crashes. Yup, and that’s
just not working. So let’s go to the console
and see what that actually produced. We can go into our
first issue here. And our stack trace here
looks like a whole bunch of native mumbo jumbo. Not very useful if what
I’m actually developing is a React Native app. But we can take a
look at the logs, and we can see that
this was due to– actually, let’s go to
the previous stack trace. If you hit the arrow– yeah. That one will give us this
nice stack trace, which tells us that in
our trophy screen, we’ve typed in rendered trophs. Looks like a typo to me. So let’s go ahead and fix that. All right, we’ll just
add two more letters, run our app again,
and now we’ll actually be able to see the trophies
that we have rightfully earned. So now that we’ve fixed all
of the issues in our app, what else can we do? KIANA MCNELLIS: So if we
go back to the slides, the next step in
what we want to do is try to start experimenting
with our user base. By adding Cloud Messaging and
Remote Config into our app, we can start experimenting
with different engagement strategies, run tests
with subsets of our users, and then we’ll be
able to see what’s working using that
analytics we just added. So the first step is with
Firebase Cloud Messaging, which is the easiest
way to add push notifications into your app. It works across the
iOS and Android, just like Flutter
and React Native. And once it’s setup, we
can instantly send a push notification to all our users. Plus, if we add a little
bit of extra code, we can actually take
that notification, put it into our
app, and then run some custom code to do an
interaction based off of that. We can even target our messages
based off things like locale and people’s experience
with our app. So how does it work? Well, we either
have our Firebase console send a notification
up to our server, or you can actually run
your own API server that does things programmatically. Then once it’s at
our Cloud Messenger, it’ll send a notification
out to all our users who have registered notification
tokens with Firebase. So let’s switch back to the
code and see how it works. So here we have our
Flutter pubspec dot yaml, and we’re just going to start
out by adding our Firebase Messaging plugin. Cool. And then we run packages get
and it gets our new values. Then we’re going to go ahead,
and this is our main content screen, and we’re just going
to import our new package. And of course, it hit it
because Dart is pretty awesome. Then in our content
state, we’re going to just go ahead and
create that variable and then initialize it. So in here you can see that
we request a notification permission, and this
is mainly for iOS. It’ll pop up a question
to our users asking, hey, do you want to enable messaging? And it’s just one of
those required things that iOS makes you do. But you can also see that
we get the token here. And if you save that
to your database, you can actually target that
specific user for a custom notification later. Then we are going to add some
extra configuration code, and this will allow us to
handle the notification right in our app. The first two, on
launch and on resume, are if our user hits
the notification and we’re not
currently in the app, it will send that data
on to us and then we’ll do things like navigating
to the right page. However, if we’re
already in the app, we want to alert the
user of that notification because the system’s not going
to handle it automatically. So we go ahead and
show the alert, and then handle that code. So the final thing we
want to do is go over to our Android manifest. And we’re going to register
a custom intent handler just so we make sure that Flutter
sends that notification right to our app. Cool. Let’s run that. And while it’s running, let’s
go ahead to our console. And we’ll go down to
our Cloud Messaging tab. And here we can create
a new notification. Let’s do something like
check out our new levels. And we’ll just give it a label
and target our Android users for this one. And then we hit Send. And then back in
our Android app– KAT FANG: Do we want to
add advanced options? KIANA MCNELLIS: Oh, yes. And then we have some extra
notification stuff just to handle it inside of our app. So we’re going to add
some custom fields. The first is just some text
for our in-app notification. And then the location
we want to go, which is the progress screen. And then our special
intent handler for Android. Cool. Now we’ll go back
and send the app. And go over to our Android. And in the Notification
Center there, we should have an app pop up. Yeah, it stopped running. Sorry. Just send that again. Let’s just resend
that notification. KAT FANG: Sure. KIANA MCNELLIS:
And the cool thing is you can actually just
duplicate it and send it right again. KAT FANG: Still looks good? KIANA MCNELLIS: Yeah. Cool. And let’s go back to the app. KAT FANG: I can see it
right here on the podium. KIANA MCNELLIS: Cool. And we already clicked it and
it’s at the progress screen. Nice. So let’s switch
back to the slides and talk about Remote
Config real quick. So Firebase Remote
Config allows us to try out different
features inside of our app. It allows us to tweak our
experiences for different users and different user groups, and
change the UI based on things like a new feature flag. How does it work? Well, you have a hard coded
option in your app right now, and it gives the same
experience to everyone. But we want to change that. So with Firebase Remote Config,
we stick in a new variable and it fetches from the server
the dynamic value for that. And then it updates
your UI accordingly. So let’s try that out. So back in our pubspec
dot yaml, we’re just going to add the
Remote Config plugin, and again, packages dot get. Then in our content
screen, we’re going to import that
package once again, and create a new variable. And then we’ll go
ahead and initialize. So this time we’re going
to do an asynchronous call. And then using
the wait key word, we’re just going to wait for
that response back to say, yes, we have a
remote config set up. And if we do, we’ll go ahead
and do a configure settings, and this will make sure that
we set some default settings. In this case, we’re
in a debug mode. So we’re going to leave
the debug flag on. And then we’re going to set
some sensible defaults that we already have in our app. Next, we’re going to fetch
the new remote config from the server, and then
update the app accordingly. And we call set state
here because that’s how Dart knows to update the UI. Finally, we’re going to replace
the get config function just so our app knows to
check Remote Config first before we use our defaults. Cool. Let’s run that. And if we go over
to our find screen, we can see we currently
have two options. But we want to change
it to three or four, and make it a little bit
easier for our users. So let’s go into the
Remote Config dashboard. And we’re going to add
our first parameter here, which is going to be
find number options. And we’ll set it up to four. And then add the parameter. And finally, the last thing
is hit Publish to send it out to your users. Then in a couple seconds,
it’ll reach our app, and we’ll just restart
it to make sure it fetches those new variables. Since in this case,
we only wanted to start on startup because
otherwise the experience would change while our users
were using the app. And it just takes a
moment to load here. Cool. While this is loading, let’s
go and add another thing in our Remote Config. KAT FANG: Sure. KIANA MCNELLIS:
So the cool thing is we can actually add
parameters specifically for certain versions of
our user base and our app. So if we define a new
condition, say, is iOS, then we apply if they’re
using our iOS app, and we create the condition. Then we can add a
specific variable just for those iOS users, say, only
three because our iOS users are going to have a little
bit harder time finding those items, and then
we publish the changes. And then if we go
back to our app, let’s see what that
find screen looks like. Cool. And it got to four. Unfortunately, conference
Wi-Fi took a little bit of time to get there, but
it came through. And you’ll notice it didn’t
switch to three because it knows this isn’t that iOS app. And without any code
changes, we were able to update that
value dynamically. So those were all manual
tasks, but let’s switch back to the slide to learn
about some automatic ones. So the smarts–
predictions, A/B testing, and A/B testing for
Cloud Messaging– all allow us to add
some machine magic to automate those tasks
who we’re just doing. By using Firebase Predictions,
we take Google’s Cloud ML and actually integrate it
right into our analytics data. It helps predict actions
that our user base will take, like will they churn, or
will they spend money, or we can even have it predict
a custom analytics event, like are they ever going
to reach the third level. Then with A/B testing, we can
go ahead and automate our tests and interpret the
results automatically. So we can run tests with
just a sample of our users, or we can do it just with
a certain audience, or one of those prediction events. Then we can see if it made an
impact on the metrics we care about, and then roll it out to
a larger population if it works. So this is what it
might look like. So half of our user
base might get, can you beat our
latest challenge? And the other half get,
new levels just released. But it will do that all
for us, and we won’t have to choose which does which. So let’s go back and
do a demo of this. Cool. So this is our
predictions currently. And you’ll see we have
a pretty high churn number because our app, again,
wasn’t very good before. Now that our bugs
are fixed, hopefully that number will go up. But currently it’s at 37%
are predicted to churn, but that’s a high
risk tolerance. At a high risk
tolerance, we’re really saying anyone who
could possibly churn, we want to make
sure to target them. But if we switch it to
a lower risk tolerance, we can do, like, only the
users that we’re very sure are going to churn,
and maybe we’re going to try to ring them
for all the money we can get, or maybe we’ll just
help them do the app, use the app a little easier. We can also set up
down here a level three reached, which
is a custom analytics event that we then took and
asked Google to predict. And it would just
take a couple of days to go and do that prediction. Or we can even run
an A/B test on these and target just the users
who are predicted to churn. So next up, let’s
do an A/B test. So it takes a little while
to load on conference Wi-Fi, but we’ll create an
experiment for notifications. And let’s do something like
giving everyone I/O trophies. So we’ll do a short
message, and then we’ll target our iOS users. And let’s do, like, 100%,
because we want every one of our users to get this one. We just want to see
which one does better. So we’ll hit Next and
add three variants– finish a level for the
first, limited edition trophy for the next, and then
a special trophy for the third. And then Next. And our goal here
will be session start, because we want people to open
up our app and start using it. And that’s what we’re going
to try to optimize for. Then we hit Next. And go ahead and see
an overview of what our A/B test will look like. And then we start
the experiment. Now this will take a week
or so to run, or two weeks if we did the experiment
with Remote Config, but we actually started
an experiment a week ago that we can show you guys. This one was with Android. And it looks like a
Variant A won out. So that’s pretty cool. And if we look down we can
see what Variant A was, and we can see some
of the stats on it. We can see the conversion rate
was 22%, which is pretty good, and how many people
actually did that event. So nice. Let’s switch back to the slides. So what are some other ways I
can use all these cool features we just started working with? KAT FANG: That’s
a good question. One way is we can
use predictions to find the users that
will churn and give them booster packs. Target them. Maybe they’re having a hard
time with the different levels. So we can use booster
packs to help them through those harder levels. We can use this. We can use Firebase features
if we want to redesign our app. We can use A/B testing,
see if people actually enjoy the new redesign. And it will also tell us
if people are experiencing more crashes with the new
redesign, in which case, we’ll just roll it back. But if we do like it, we can
roll it all the way to 100%. We can also use Firebase
when producing new content. So I’m sure a lot of you have
had that experience where you just want your users
to download a new app update so that they can
get the new content. Well, we can roll
the new content into existing app uploads– app updates, but hide it behind
a Remote Config variable. Then on the day we want
to launch the new content, we don’t have to wait for
people to update their app. We’ll just flip a
Remote Config flag and send a push notification to
let everyone know that there’s new content waiting for them. So we’ve taken our two apps,
React Native and Flutter, and added Firebase
features to them. This allows us to
observe and analyze using Firebase Analytics,
Crashlytics, and Performance Monitoring to see what our users
are doing and discover issues before they reach everyone. We can make a
hypotheses as to how we can improve the experience
with them using predictions to segment users that might
be churning or spending more money, and we
can run experiments on them using A/B testing,
targeting Remote Config and Messaging. We’ll be able to analyze
the changes we have made, what users like, and repeat
the cycle all over again. Now that we’ve added
Firebase, when people all across the world
come to our app, they will have a smooth
and enjoyable experience. Firebase can actually
go beyond even this and help us develop
our next features using products such as
Firestore, which have real time synchronous capabilities,
allowing us to build things like team games so that
people can work together to build scavenger– to
finish scavenger hunts, or using Cloud
Storage so that we can make sure uploads
are successful, even across networks. But this is the last
talk here at I/O. So I encourage you
all to go to YouTube, check out the other talks that
have happened here these past three days, and explore the
deep dives on there as well. We want to hear from you. So please check out the website
and leave us some feedback. Again, thank you for
coming to our talk, and I hope you’ve enjoyed I/O. [APPLAUSE] [MUSIC PLAYING]

Only registered users can comment.

  1. #askfirebase we're integrated Firebase in one of our React Native app. We could not find the more details about how to integrate Firebase invite functionality in React Native.
    Use case : Once user click on received invitation link, App should automatically find the sender user details and mark them both as friend in Firebase database. We're stuck here and could not lunch the app on store as this is most important feature for this app.

  2. wait, how did the app connect to the correct firebase server? She didn't enter API keys or anything that tells the app to get and post data from the firebase server she set up

Leave a Reply

Your email address will not be published. Required fields are marked *