Update: Both DebugView and StreamView are available to all Firebase developers, so you can get access to your data a whole lot faster! Happy Analytics viewing!
This is probably one of the most common questions we get around Firebase Analytics, and
we thought it was worth taking some time to delve into this topic a little
deeper. So buckle in, kids! We've got some learning ahead of us...
To understand latency with Firebase Analytics, there are two potential delays
you need to be aware of:
The time it takes for analytics data on the client to be sent over to the
Firebase Analytics servers.
The time it takes for Firebase Analytics data to be displayed to you in the
Firebase console once it's been received on the server.
Let's go over these one at a time.
Client-to-server latency
Firebase Analytics doesn't constantly stream down data from the client device.
That would be a serious battery drain, and we want to be respectful of your
users' battery life. Instead, analytics data is batched up and sent down when
the client library sees that there's any local data that's an hour old.
On iOS devices (and Android devices without Google Play Services), this one hour
timer is per app. But on Android devices with Play Services, this one hour timer
is across all apps using Firebase Analytics.
In addition, Firebase Analytics will send down all of its data from the client
if your user triggers a conversion event (like making an in-app purchase). And
on iOS devices, Firebase Analytics will also send down its data whenever your
app goes into the background.
"Hang on there -- once an hour? What about my users who churn out sooner
than that?"
Not to worry. On most Android devices, it's Google Play Services that manages
sending down this data. Which means that even if your user deletes your app
after an hour, that data will still get sent down because Google Play Services
still has it.
On iOS devices, Firebase will also send down data when your app moves into the
background. So if a user tries your app for 20 minutes and then uninstalls it,
that session data will still be received, because your app will have sent down
the data the moment the user moved your app to the background. The one corner
case where analytics data would actually get lost on iOS would be if your app
crashed and then your user immediately uninstalled it.
Server-to-console latency
Now, moving on to the second case, there's also the frequency at which Firebase
Analytics grabs the latest batch of data it's received from your client and uses
that data to update the reports and graphs you see in the Firebase Console. This
process typically runs every few hours. So that's the kind of delay you should
expect after your client data is sent down to the server.
If you're looking for your most recent data in these reports, keep in mind that
the default "Last 30 days" report doesn't include any data from the current day
-- this is because the data for the current day is incomplete, and it would be
misleading (not to mention a bummer) to see every graph end with a giant
downturn in usage. So if you want to see the current day's data, you'll want to
select "Today" from the drop down menu in the Firebase Console.
On the other hand, if you've set up your app to export all of its Firebase
analytics data to BigQuery, this data is available for you to look at
right away. There are no batch reports that need to be run, so you can
immediately view all of the day's data by looking at the app_events_intraday
table that's automatically created for you in BigQuery. For more about this
feature, be sure to check out our earlier
blog post.
But outside of BigQuery, it generally takes a few hours for you to see any data
you've recorded in Firebase Analytics.
"Anything that can be done to speed up this process?"
As you may have heard at our Firebase
Dev Summit, we've working on two enhancements to Firebase Analytics --
DebugView and StreamView -- which will give you more up-to-date insight into
your analytics data during both development and production.
Neither of these are yet available to the general public, but as your reward for
making it this far into the blog post, here's a link to
sign up for the DebugView closed beta. See? Reading has its advantages!
"So, what if I want a some kind of realtime dashboard? What should I
do?"
There are many developers out there who want to be notified as soon as they see
something unusual in their stats -- whether that's a sudden drop in in-app
purchases, people failing to make it through the tutorial, or what-have-you.
And while you can't quite accomplish this with the free Firebase Analytics
reports that you see in the console, you could accomplish this sort of thing by
combining BigQuery with another tool such as Google Data Studio, a third-party
visualization tool like Tableau, or even writing your own Google Apps Script
monitoring script. All of which allow you to run some pretty sophisticated
custom reports, but frankly, that's a whole other blog post.
Do keep in mind, however, that you're still subject to BigQuery usage charges
when you query your data though these tools if you go beyond the 1TB/month free
tier, so be mindful of how much (and how frequently) you decide to process your
data.
Hopefully, this gives you a better understanding of how long it takes for you to
see analytics data and what you can expect when you're developing your app. Now
go forth and start recording those events!
If your app is using Firebase Realtime
Database, you've probably gotten a lot of mileage out of its ability to
notify your app quickly as changes are made to the database. Your listeners are
triggering and receiving new data, users are delighted, and all is well with the
world.
However, sometimes listeners may not behave in exactly the way you'd
expect when combined with security and validation rules.
There are some important nuances to the way Firebase Realtime Database works,
and how those nuances affect the way your listeners are triggered. Let's go
over some of those situations, so you can expect the unexpected!
Security Rules with Value Event Listeners
Are you using security and
validation rules to protect access to your data? If not, please take a good
hard look at that! But if you are using these rules, you can run into
some behavior that may seem confusing at first, but is actually predictable,
once you understand how the Firebase Realtime Database client libraries work.
All the code samples here will be in Java, because Android is my main thing.
But the principles apply to each of the supported platforms, including iOS, web,
and JavaScript on the server side.
Imagine you have the following database rules set up:
{
"rules": {
".read": true,
".write": false
}
}
So, basically, everything is readable and nothing is writable. Your security
rules are likely going to be much more specialized, but the point is that some
writes will not be allowed at certain locations or under certain circumstances.
I'm keeping it simple here, in case you want to experiment with the code samples
here in a new project.
Now imagine you have the following tiny bit of data in your database:
ROOT
- data
- value: 99
You'd expect that a ValueEventListener
on the /data node would give you a snapshot containing a map of the key "value"
to the number 99. So, if you executed this code, you'd get a single log
statement showing these details:
private class MyValueEventListener implements ValueEventListener {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
Log.i("********** change", dataSnapshot.getKey() + ": " + dataSnapshot.getValue());
}
@Override
public void onCancelled(DatabaseError databaseError) {
// If we're not expecting an error, report it to your Firebase console
FirebaseCrash.report(databaseError.toException());
}
}
Pretty straightforward. But imagine you then attempt to change the value from
99 to 100:
HashMap map = new HashMap<>();
map.put("value", 100);
dataRef.setValue(map);
Since our security rules prohibit this, we expect to fail. And it does. But
one other thing happens that may not be expected. If MyValueEventListener is
still registered at the time setValue() is called, it will also be triggered
with the new value of 100. Not only that, but the listener will be
triggered again with the original value of 99. Your app log might look
something like this:
So we see here that the listener got the original value of 99, then the updated
value of 100, then an error, then back to the original 99.
Now, you might be thinking, "The security rules should have prevented that
change to 100! What gives!" This is a completely understandable perspective.
However, it's time to update your expectations with some knowledge about what's
really going on here!
The client SDK has no knowledge of the security rules for your project. They
live and are enforced on the Firebase server side. However, when the SDK
handles the call to setValue(), it goes ahead and assumes that the update will
actually work on the server. This is the usual case for code that's been
written for a database with a particular set of rules —
the intent is typically never to violate any rules. With this assumption in
play, the SDK goes ahead and acts early, as if the write to the
database location has actually succeeded. The result of this is the triggering
of all listeners currently added to the changed location within the same app
process.
OK, so, you might be wondering: if a write can fail, why does the client SDK act
early like this? The reasoning is that these immediate callbacks can help your
app feel snappy in the face of a poor network connection, and also allows your
app to be usable when completely offline. For example, if a user wants to make
a change to their profile, why not let them see that change immediately, rather
than having to wait for a full round trip to the server? After all, if your
code intends to honor the security rules, there should be no problem, right?
In the case where your code does violate a security rule like this, the server
notifies the app that the update actually failed at that location. The logical
thing to do, at this point, is trigger all listeners at that location with the
original data, so the UI of your app can regain consistency with known values
from the server.
Given all this context on how security rules works, let's look at another
scenario.
Security Rules with Child Event Listeners
Child
event listeners are different from the value event listeners described
above. A ValueEventListener
as shown above gives you the entire contents of a particular location, every
time any part of it changes, whereas a ChildEventListener
gives you callbacks for individual child nodes under a location whenever one of
those children is added, changed, moved, or removed.
For this example, let's use the same security rules as before, with everything
readable and nothing writable:
{
"rules": {
".read": true,
".write": false
}
}
Now, let's say you have a node in your database called /messages, where you want
users to be able to push new message content to be shared with others:
In this code, we have a ChildEventListener added on /messages, then we're trying
to add a new child object into a location determined by some generated push id.
Of course, we expect this to fail because of the security rules. But, let's
look at the log to see what actually happens if we execute this code:
I/**********: childAdded DataSnapshot { key = -KTfacNOAJt2fCUVtwtj, value = {key=value} }
W/RepoOperation: setValue at /messages/-KTfacNOAJt2fCUVtwtj failed: DatabaseError: Permission denied
I/**********: childRemoved DataSnapshot { key = -KTfacNOAJt2fCUVtwtj, value = {key=value} }
We see that the client library immediately triggers the onChildAdded method with
the new child object under /messages, then logs an error, then triggers the
onChildRemoved callback with the same object.
If you read through and understood the prior example, this one should be a
little less surprising. The Firebase client SDK is again acting early
in response to the call to setValue() and assuming that the write will success.
Then, after the write fails because of the security rules, it attempts to "undo"
the add that failed. This ensures that the app's UI can remain up-to-date with
the correct child values, assuming that it has implemented onChildRemoved
correctly.
The behavior of the Firebase client library in the face of violated security
rules should be more clear now, but you might still be wondering how you can
detect if a violation occurred. It may not be adequate for your app to simply
reverse the effect of the write. In fact, you may even want to know if and when
that actually happens, as it could be considered a programming error. This
brings me to the next point.
Detecting Write Errors
In the examples above, it can be very difficult to tell if your call to
setValue() failed at the server just by looking at the listener callbacks. If
you want to detect failure, you'll need a bit of extra code to respond to that
event. There are two ways to do this. First, there is CompletionListener
that you can pass to an overload of setValue
that gets notified of errors. Alternatively, you can also use the Play Services Task
API by using the Task
object returned by setValue. I'll prefer a Task here, because it has built-in
protections against Activity leaks (note the first argument to addOnCompleteListener
is an Activity instance):
Task task = messageRef.setValue(map);
task.addOnCompleteListener(MainActivity.this, new OnCompleteListener() {
@Override
public void onComplete(@NonNull Task task) {
Log.i("**********", "setValue complete");
if (!task.isSuccessful()) {
Log.i("**********", "BUT IT FAILED", task.getException());
FirebaseCrash.log("Error writing to " + ref.toString());
FirebaseCrash.report(task.getException());
}
}
});
When the write of the value completes, with either success or error, the OnCompleteListener
registered to the Task will be called. If it failed, I can check the Task to
see if it was successful and deal with it as needed. In the above code, I'm
choosing to report the error to Firebase Crash Reporting,
which can help me determine if and where I made a mistake in my code or security
rules. It's probably a good idea to always report your write failures like
this, unless you fully expect that a write could legitimately fail, under normal
circumstances, to a security rule.
When there is an update to a location that also has active listeners in the same
process, the flow of data through the process goes like this:
Immediately call all relevant listeners with the new value
Send the update to the Firebase server side
Check security rules for validity
If a security rule was violated, notify the client SDK
Roll back the change in the app by calling relevant listeners again to back
to the original state
Using this knowledge, it's possible you may have reset your expectations to
expect the unexpected for your listeners! Were your expectations changed? Let
me know in the comments below! And, if you have any programming questions about
Firebase Realtime Database, you can ask us on Stack Overflow with the firebase-database
tag. For more general questions, you can ask on Quora or use the firebase-talk
Google Group.
If you like, follow me on Twitter as CodingDoug, and don't forget to check
out our YouTube channel for Firebase
tutorials and other shows.
In September, we launched a
new way to search for content in apps on Android phones. With this update,
users were able to find personal content like messages, notes, music and more
across apps like OpenTable, Ticketmaster, Evernote, Glide, Asana, Gmail, and
Google Keep from a single search box. Today, we're inviting all Android
developers to enable this functionality for their apps.
Starting with version 10.0, the Firebase App Indexing API on Android lets apps
add their content to Google's on-device index in the background, and update it
in real-time as users make changes in the app. We've designed the API with three
principles in mind:
making it simple to integrate
keeping all personal data on the device
giving the developer full control over what goes into the index and
when
There are several predefined data types that make it easy to represent common
things such as messages, notes, and songs, or you can add custom types to
represent additional items. Plus, logging user actions like a user listening to
a specific song provides an important signal to help rank user content across
the Google app.
Example of adding or updating a user's shopping list in the on-device index.
Integrating with Firebase App Indexing helps increase user engagement with your
app, as users can get back to their personal content in an instant with Google
Search. Because that data is indexed directly on the device, this even works
when offline.
Version 10.0.0 of the Google Play services client libraries, as well as the
Firebase client libraries for Android, will be the last version of these
libraries that support Android API
level 9 (Android 2.3, Gingerbread). The next scheduled release of these
libraries, version 10.2.0, will increase the minimum supported API level from 9
to 14 (Android 4.0.1, Ice Cream Sandwich). This change will happen in early
2017.
Why are we discontinuing support for Gingerbread and Honeycomb in Google
Play services?
The Gingerbread platform is almost six years old. Many Android developers have
already discontinued support for Gingerbread in their apps. This helps them
build better apps that make use of the newer capabilities of the Android
platform. For us, the situation is the same. By making this change, we will be
able to provide a more robust collection of tools for Android developers with
greater speed.
What this means for your Android app that uses Google Play services or
Firebase:
You may use version 10.0.0 of Google Play services and Firebase as you are
currently. It will continue to work with Gingerbread devices as it has in the
past.
When you choose to upgrade to the future version 10.2.0, and if your app
minimally supports API level 14 or greater (typically specified as
"minSdkVersion" in your build.gradle), you will not encounter any versioning
problems. However, if your app supports lower than API level 14, you will
encounter a problem at build time with an error that looks like this:
Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 9 cannot be smaller than version 14 declared in library [com.google.android.gms:play-services:10.2.0]
Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage
Unfortunately, the stated suggestion will not help you successfully run your app
on older devices. In order to use Google Play services 10.2.0 and later, you
can choose one of the following options:
1. Target API level 14 as the minimum supported API level.
This is the recommended course of action. To discontinue support for API levels
that will no longer receive Google Play services updates, simply increase the
minSdkVersion value in your app's build.gradle to at least 14. If you update
your app in this way and publish it to the Play Store, users of devices with
less than that level of support will not be able to see or download the update.
However, they will still be able to download and use the most recently published
version of the app that does target their device.
If your app still has a significant number of users on older devices, you can
use multiple APK support in Google Play to deliver an APK that uses Google Play
services 10.0.0. This is described below.
2. Build multiple APKs to support devices with an API level less than
14.
Along with some configuration and code management, you can build
multiple APKs that support different minimum API levels, with different
versions of Google Play services. You can accomplish this with build
variants in Gradle. First, define build flavors for legacy and newer
versions of your app. For example, in your build.gradle, define two different
product flavors, with two different compile dependencies for the components of
Play Services you're using:
productFlavors {
legacy {
minSdkVersion 9
versionCode 901 // Min API level 9, v01
}
current {
minSdkVersion 14
versionCode 1401 // Min API level 14, v01
}
}
dependencies {
legacyCompile 'com.google.android.gms:play-services:10.0.0'
currentCompile 'com.google.android.gms:play-services:10.2.0'
}
In the above situation, there are two product flavors being built against two
different versions of the Google Play services client libraries. This will work
fine if only APIs are called that are available in the 10.0.0 library. If you
need to call newer APIs made available with 10.2.0, you will have to create a
compatibility library for the newer API calls so that they are only built into
the version of the application that can use them:
Declare a Java interface that exposes the higher-level functionality you
want to perform that is only available in current versions of Play services.
Build two Android libraries that implement that interface. The "current"
implementation should call the newer APIs as desired. The "legacy"
implementation should no-op or otherwise act as desired with older versions of
Play services. The interface should be added to both libraries.
Conditionally compile each library into the app using "legacyCompile" and
"currentCompile" dependencies.
In the app's code, call through to the compatibility library whenever newer
Play APIs are required.
After building a release APK for each flavor, you then publish them both to the
Play Store, and the device will update with the most appropriate version for
that device. Read more about multiple
APK support in the Play Store.
Developer feedback continues to be a critical medium for us to ensure Firebase
meets the needs of the community. Since we launched the expansion of Firebase at
Google I/O in May, we received a clear message that many of you would like to
try Firebase Test Lab
without having to enter a credit card number and upgrade to the paid Blaze plan.
We agree, and we're proud to introduce Firebase Test Lab for Android for the
Firebase Spark and Flame
plans. Here's how it works.
For Firebase projects on the Spark or Flame plan, you may run up to five
tests on physical devices and up to ten tests on virtual
devices on a daily basis. This means you have a total budget of
fifteen tests to use throughout the day. For each test run, you may target up
to four different devices, and you can mix physical and virtual devices as
needed. For example, you could execute five runs targeting three devices each
run, using your full budget of fifteen tests for the day. Or, each of your
fifteen tests could be executed on a single device in fifteen individual runs.
For projects on the Spark plan, there is no billing information required to make
use of your daily quota of tests.
For both plans, the daily quota of physical and virtual device tests refreshes
at 12am PST, so you can use that to schedule your daily allotment of tests. The
maximum duration for tests on virtual devices is one hour, and the maximum on
physical devices is thirty minutes. You can also split your allotment of tests
between Robo
tests, which will test your application automatically, and instrumentation
tests, which allow you to script your application with Espresso,
UI
Automator 2.0, and Robotium.
For projects on the Blaze plan, nothing changes. You continue to run tests for $5 per device-hour on physical devices. Virtual devices can be used at no cost till the end of December (12/31/2016) then at $1 per device-hour starting 2017.
Also available now is the ability to run tests against virtual devices with
Nougat MR1 at API level 25. The Firebase Test Lab team is committed to making
sure you have access to the latest versions of Android, so you can spot
incompatibilities early during your development.
Improving the quality of your applications is easier with Firebase. Please let
us know how you're using Firebase Test Lab for Android on our support channels, including the
firebase-talk
mailing list, and the #test-lab channel on the Firebase Slack.
Did you know that Firebase contains a whole bunch of features that makes it
easier for you as a developer to build awesome apps?
Yeah, okay. That's probably not news.
But you might have noticed that, for a while, we've been talking about "apps"
instead of "games". And that's because our mobile libraries work great... as
long as you're writing your apps in Swift, Java, or Objective-C.
The problem is that most game developers are either building their own game
engines in C++ or using popular 3rd party game platforms like Cocos2D or Unity
to power their mobile games. And while we've had a C++ version of the Firebase
library available in beta for a while now, our Unity developers have been left
with a rather out-of-date Firebase Database plugin...
...until now! Thanks to a lot of hard work from a lot of our engineers and your
continued feedback, there's a brand new, officially supported, Unity SDK that
includes a whole lot more of the Firebase platform.
So what does this offering mean for you as a Unity developer? It means you can
now take advantage of many of the new Firebase features that we announced back
in May. Including...
Firebase Analytics: A free and unlimited analytics package to
record events that happen within your game. Find out where in your game players
are getting stuck, how your audience is growing over time, or where players from
each different country are spending their premium currency. All of this is easy
to record with Firebase Analytics, and its integration with BigQuery allows you
to run some pretty sophisticated data mining along the way.
The Firebase Real-time Database: This is a database where your
app's data magically syncs across all devices, usually within a few hundred
milliseconds. It's great for near-real-time features like in-game chat, syncing
your user's saved game across devices, or potentially powering a turn-based
board, card, or strategy game. That said, you probably don't want to use it to
drive your multiplayer shooter or MOBA -- I know with game developers, we need
to a little more explicit about what 'real-time' actually means. ;)
Dynamic Links. These are mobile deep links that you can use to
point players to any element of your game (if they have it installed), or take
them to the Play Store / App Store (if they don't). I think the best use case
here for game developers would be to use Dynamic Links to help power in-app
sharing. You can use Dynamic Links to share a replay of a level, or a link to
your player's awesome new character / fortress / user-generated content. And if
you don't feel like building our your own interface to do all of this,
Firebase Invites can create one for you, by packaging up a
Dynamic Link inside a nicely formatted email or SMS message.
Authentication: "Boy, I really like spending all my time
building authentication systems instead of working on my game," said no game
developer ever. With Firebase Auth, we make it easier for you to sign in your
users in from third party providers like Facebook, Google, and Github, or to
create a custom username and password system.
Cloud Messaging: Firebase Cloud Messaging allows you to send
notifications to both iOS and Android devices through a single endpoint. It also
lets you send notifications through the Firebase Notifications panel, which
means non-technical members of your team can send notifications without your
having to worry about writing any custom server code or curl calls.
Remote Config: This feature lets you update your game's values
from the cloud. Honestly, this is the feature I'm most excited about for games.
Anybody who's designed a tower defense game knows that one overpowered stat in a
single unit can throw off the balance of your entire game. With Remote Config
you can tweak those values from the cloud, and then use Firebase Analytics to
see if they give you the results you expect. You can even use Remote Config to
deliver custom values to specific groups of people, like your expert players.
You can use this library with Android and iOS devices, but the team has nicely
added in stub methods for Windows, OSX, and Linux, so you don't need to worry
about adding a bunch of conditional code if your game is also targeting
desktops. As a side note, the Real-time Database part of the SDK works directly
within the Unity editor, which makes testing and debugging a bit nicer.
We encourage you to give the Firebase SDK for Unity a try! It's available right
here, and it contains
a whole bunch of features that makes it easier for you as a developer to build
some pretty awesome… games.
Nowadays, many users prefer using federated login, such as Google Sign-In,
Facebook, Twitter and others, over having to create a new account for every
service they use. Each user has their own favorite federated login provider, and
it would take a lot of effort to integrate and manage each federated login
provider for your app. This is where Firebase Authentication can help.
Firebase Authentication supports many popular federated login providers. You
just need to integrate with Firebase Authentication, and let Firebase
automatically manage multiple federated login providers under the hood for you.
However, depending on where your users are in the world, they may prefer a
federated login providers for which Firebase does not have built-in support yet.
For example, in Japan and many Asian countries, LINE Login is very
popular with hundreds of millions of users, so you may want to support it as
well. Fortunately, it is fairly simple to integrate LINE Login, as well as many
other federated login, with Firebase Authentication using Custom Auth.
In one of our previous blog
post, we have shown how to support federated login that was not available
out-of-the-box with Firebase Authentication on the web using our JavaScript SDK.
In this blog post, I will show you how to integrate with LINE Login on iOS and
Android.
Design Overview
Here is how the login flow looks like:
Step 1:
Use LINE Login SDK to
log user in, and acquire their LINE Access Token
Step 2:
Send their LINE Access
Token to your server and validate it with LINE authentication server. If the
token is valid, then create a Firebase Custom Auth token correspond to the user,
and send it back to user's device.
Step 3:
Use the Firebase Custom
Auth token to login to Firebase from the device.
Let's Build It!
Preparation
You will need to do some setup work to get your LINE business account and
Firebase project ready.
Follow the steps here to setup your
LINE business account, and integrate LINE SDK to your app
Next, make sure that you have added Firebase Authentication library to your
app (iOS / Android)
You may want to use our Firebase Server SDK to generate
Custom Auth token, but that is optional because any JSON Web Token library can
do the work as well.
Start the LINE Login flow
Refer to LINE Login document (iOS / Android)
to integrate LINE SDK to your app and implement LINE Login flow. Once user has
successfully logged in, you can get their LINE access token as below:
LineAuthManager authManager = LineSdkContextManager.getSdkContext().getAuthManager();
final String accessToken = authManager.getAccessToken().accessToken;
Then you can use your favorite networking library to send the access token to
your own server for validation. In this sample code, I use GTM HTTP Fetcher for iOS
and Volley for
Android.
HashMap validationObject = new HashMap<>();
validationObject.put("token", accessToken);
Response.Listener responseListener = new Response.Listener() {
@Override
public void onResponse(JSONObject response) {
// Extract Firebase Custom Auth token from response
// ・・・
}
};
JsonObjectRequest fbTokenRequest = new JsonObjectRequest(
Request.Method.POST,
"https:///verifyToken",
new JSONObject(validationObject),
responseListener, errorListener);
NetworkSingleton.getInstance(activity).addToRequestQueue(fbTokenRequest);
Exchange LINE Access Token for Firebase Custom Auth Token
You will need a server to validate LINE access token and generate a
corresponding Firebase Custom Auth token for that user. You can build a simple
one with Firebase Node.js Server SDK and Express web server.
Firstly, your server receives the LINE Access Token from user's device and
validates it using LINE Social Rest API. Don't forget to verify the
channelId value in API response to make sure that the access token is
actually issued for your app. This is to prevent spoof attack, of which
attackers reuse access token from other app/channel to attempt login to your
app.
Server (Node.js)
app.post('/verifyToken', (req, res) => {
if (!req.body.token) {
return res.status(400).send('Access Token not found');
}
const reqToken = req.body.token;
// Send request to LINE server for access token verification
const options = {
url: 'https://api.line.me/v1/oauth/verify',
headers: {
'Authorization': `Bearer ${reqToken}`
}
};
request(options, (error, response, body) => {
if (!error && response.statusCode === 200) {
const lineObj = JSON.parse(body);
// Don't forget to verify the token's channelId to prevent spoof attack
if ((typeof lineObj.mid !== 'undefined')
&& (lineObj.channelId === myLINEChannelId)) {
// Access Token Validation succeed with LINE server
// Generate Firebase token and return to device
const firebaseToken = generateFirebaseToken(lineObj.mid);
// Update Firebase user profile with LINE profile
updateUserProfile(reqToken, firebaseToken, lineObj.mid, () => {
const ret = {
firebase_token: firebaseToken
};
return res.status(200).send(ret);
});
}
}
const ret = {
error_message: 'Authentication error: Cannot verify access token.'
};
return res.status(403).send(ret);
});
}
});
After successfully validated LINE Access Token, use Firebase Server SDK to
generate Firebase Custom Auth token and return it to the user device. You can
reuse LINE's user ID for your Firebase user ID.
Server (Node.js)
function generateFirebaseToken(lineMid) {
var firebaseUid = 'line:' + lineMid;
var additionalClaims = {
provider: 'LINE'
};
return firebase.auth().createCustomToken(firebaseUid);
}
After receiving the Firebase Custom Auth token, just use it to sign the user in
Firebase:
iOS (Objective-C)
[[FIRAuth auth] signInWithCustomToken:firebaseToken
completion:^(FIRUser * _Nullable user, NSError * _Nullable error) {
// Process sign in result
// ・・・
}];
Android
FirebaseAuth.getInstance()
.signInWithCustomToken(firebaseToken)
.addOnCompleteListener(new OnCompleteListener() {
// Process sign in result
// ・・・
});
Earlier this year, we introduced
the expansion of Firebase: a unified app platform that provides developers a
variety of tools and a scalable infrastructure to build high quality apps and
grow successful businesses across Android, iOS and the Web. This blog post is
not about the 'what' but more about the 'how'. How do you implement Firebase
into your app quickly and easily?
Today we are launching a complete end-to-end video training course called
"Firebase in a Weekend". Whether you develop Android or iOS apps, the
training course helps you understand many of the core features of Firebase,
learned by building an app from the ground up.
Join some of our favorite Firebase instructors as they walk you through building
a functioning messaging app using:
Realtime database - Data is synchronized across all clients in realtime,
and remains available when your app goes offline.
Auth and FirebaseUI Auth Library - Get users logged into your app quickly
and protect their data.
Notifications - Lets you easily deliver notifications to your users without
writing a line of code.
Remote Config - Gives you a collection of variables that you can change
from the Firebase console in order to tune and customize your app on the fly to
deliver the best experience to your users.
Analytics - Set up analytics to gather data the moment you publish.
We partnered with Udacity, the online
learning platform, to give you a more personalized, in depth explanation of
Firebase and its features. You can learn how to do it on either Android or iOS by watching short videos
enhanced with code samples and assessments.
With Firebase, we've been working towards a world where developers don't have to
deal with managing servers and can instead build web and mobile apps with only
client-side code. However, there are times when you really do need to spin up
your own server. For example, you may want to integrate with a third-party API
(such as an email or SMS service), complete a computationally expensive task, or
have a need for a trusted actor. We want to make your experience on this part of
your stack as simple as it is on the front-end. Towards that aim, we announced
the Firebase Admin SDKs
for Node.js and Java at the Firebase Dev Summit in Berlin earlier this week.
What are the Admin SDKs?
The Firebase Admin SDKs provide developers with programmatic, second-party
access to Firebase services from server environments. Second-party here refers
to the fact that the SDKs are granted elevated permissions that allow them to do
more than a normal, untrusted client device can. The Admin SDKs get these
elevated permissions since they are authenticated with a service account, a
special Google account that can be used by applications to access Google
services programmatically. The Admin SDKs are meant to complement the existing
Firebase web and mobile clients which provide third-party, end-user access to
Firebase services on client devices.
Some of this may sound familiar for those of you who have used the existing
Firebase Node.js and Java SDKs. The difference is that we have now split the
second-party (aka "admin") and third-party (aka "end-user") access use cases
into separate SDKs instead of conflating them together. This should make it
easier for beginners and experts alike to know which SDK to use and which
documentation to follow. It also allows us to tailor the Admin SDKs towards
server-specific use cases. A great example of this is the new user management
auth API which we will go into in the next section.
What can the Admin SDKs do?
The Admin SDKs for Node.js and Java offer the following admin capabilities that
already existed in the prior server SDKs:
In addition, the Node.js SDK brings some exciting new functionality:
Admin API for managing
Firebase Auth users, including the ability to fetch user data, create new
users, update user properties, and delete users. You can do all of this without
a user's existing password and without worrying about rate limiting. This has
been a heavily requested feature from developers for years now and we are
excited to finally put it into your hands.
The best place to start is with our Admin SDKs setup guide.
The guide will walk you through how to download the SDK, generate a service
account key file, and use that key file to initialize the Admin SDK. Thanks to
our new Service
Accounts panel in your Firebase Console settings, generating
service account keys should be a breeze.
What's next for the Admin SDKs?
This is really just the beginning for the Admin SDKs. We plan to expand the
Admin SDKs across two dimensions. Firstly, we want to provide Admin SDKs in more
programming languages, allowing you to write code in the language you feel most
comfortable. Secondly, we plan to integrate with more Firebase services,
including adding support for services like Firebase Cloud Messaging and bringing
the new user management API to Java.
Would you like us to build an Admin SDK in a particular language? Do you want
the Admin SDKs to support a certain Firebase service or feature? Let us know in
the comments below or by sending us a note through our feature
request support channel.
We are excited to expand our first-class support for backend developers in the
Firebase ecosystem. Stay tuned for more to come in the future!
Our goal with Firebase is to help developers build better apps and grow them into successful businesses. Six months ago at Google I/O, we took our well-loved backend-as-a-service (BaaS) and expanded it to 15 features to make it Google’s unified app development platform, available across iOS, Android, and the web.
We launched many new features at Google I/O, but our work didn’t stop there. Since then, we’ve learned a lot from you (750,000+ projects created on Firebase to date!) about how you’re using our platform and how we can improve it. Thanks to your feedback, today we’re launching a number of enhancements to Crash Reporting, Analytics, support for game developers and more. For more information on our announcements, tune in to the livestream video from Firebase Dev Summit in Berlin. They’re also listed here:
Improve App Quality to Deliver Better User Experiences
Firebase Crash Reporting comes out of Beta and adds a new feature that helps you diagnose and reproduce app crashes.
Often the hardest part about fixing an issue is reproducing it, so we’ve added rich context to each crash to make the process simple. Firebase Crash Reporting now shows Firebase Analytics event data in the logs for each crash. This gives you clarity into the state of your app leading up to an error. Things like which screens of your app were visited are automatically logged with no instrumentation code required. Crash logs will also display any custom events and parameters you explicitly log using Firebase Analytics. Firebase Crash Reporting works for both iOS and Android apps.
Glide, a popular live video messaging app, relies on Firebase Crash Reporting to ensure user quality and release agility. “No matter how much effort you put into testing, it will never be as thorough as millions of active users in different locations, experiencing a variety of network conditions and real life situations. Firebase allows us to rapidly gain trust in our new version during phased release, as well as accelerate the process of identifying core issues and providing quick solutions.” - Roi Ginat, Founder, Glide.
Firebase Test Lab for Android supports more devices and introduces a free tier.
We want to help you deliver high-quality experiences, so testing your app before it goes into the wild is incredibly important. Firebase Test Lab allows you to easily test your app on many physical and virtual devices in the cloud, without writing a single line of test code. Beginning today, developers on the Spark service tier (which is free!) can run five tests per day on physical devices and ten tests per day on virtual devices—with no credit card setup required. We’ve also heard that you want more device options, so we’ve added 11 new popular Android device models to Test Lab, available today.
Illustration of Firebase Crash Reporting
Make Faster Data Driven Decisions with Firebase Analytics
Firebase Analytics now offers live conversion collection, a new integration with Google “Data Studio”, and real-time exporting to BigQuery.
We know that your data is most actionable when you can see and process it as quickly as possible. Therefore, we’re announcing a number of features to help you maximize the potential of your analytics events:
DebugView for validation of your analytics instrumentation is currently offered in limited availability and will be made more broadly available later this year
We were happy to give you a sneak preview at the Firebase Dev Summit of a new feature we are now building, StreamView, which will offer a live, dynamic view of your analytics data as it streams in.
To further enhance your targeting options, we’ve improved the connection between Firebase Analytics and other Firebase features, such as Dynamic Links and Remote Config. For example, you can now use Dynamic Links on your Facebook business page, and we can identify Facebook as a source in Firebase Analytics reporting. Also, you can now target Remote Config changes by User Properties, in addition to Audiences.
Build Better Games using Firebase
Firebase now has a Unity plugin!
Game developers are building great apps, and we want Firebase to work for you, too. We’ve built an entirely new plugin for Unity that supports Analytics, the Realtime Database, Authentication, Dynamic Links, Remote Config, Notifications and more. We've also expanded our C++ SDK with Realtime Database support.
Integrate Firebase Even Easier with Open-Sourced UI Library
FirebaseUI is a library that provides common UI elements when building apps, and it’s a quick way to integrate with Firebase. FirebaseUI 1.0 includes a drop-in UI flow for Firebase Authentication, with common identity providers such as Google, Facebook, and Twitter. FirebaseUI 1.0 also added features such as client-side joins and intersections for the Realtime Database, plus integrations with Glide and SDWebImage that make downloading and displaying images from Firebase Storage a cinch. Follow our progress or contribute to our Android, iOS, and Web components on Github.
Learn More via Udacity and Join the Firebase Community
We want to provide the best tool for developers, but it’s also important that we give resources and training to help you get more out of the platform. As such, we’ve created a new Udacity course: Firebase in a Weekend! It’s an instructor-led video course to help all developers get up and running with Firebase on iOS and Android, in two days.
Finally, to help wrap your head around all our announcements, we’ve created a new demo app. This is an easy way to see how Analytics, Crash Reporting, Test Lab, Notifications, and Remote Config work in a live environment, without having to write a line of code.
Helping developers build better apps and successful businesses is at the core of Firebase. We work hard on it every day. We love hearing your feedback and ideas for new features and improvements—and we hope you can see from the length of this post that we take them to heart! Follow us on Twitter, join our Slack channel, participate in our Google Group, and let us know what you think. We’re excited to see what you’ll build next!
In this post, we're going to talk about one of the biggest problems majority of
apps face: retention. The hard truth is that most people tend
to only use a few applications every week, abandoning a majority of them after
just a few tries. This might happen even if you did successfully activate a
user.
The goal, for any product, is to become a habit for their users. And, for a
person to pick up new habits, they need the help of triggers. The best products
carefully use external triggers — things like push notifications, E-mailers — at
appropriate times which help building habits.
The key capability added, thanks to this change, is something we call Firebase
Notifications. By simply adding the required dependency to your application,
you can now send push notifications to your users straight from the Firebase
console. But that's not all: you can target the notification to a required
segment. For example, you can inform those users who have shown an interest in a
particular product that you have a deal running in your E-commerce application.
While quite useful, particularly considering how little you need to do to add
them to your app, sending Push Notifications is a manual process and best
utilized for campaigns. To truly improve your product, you need to first
understand when you tend to lose your users, and build a system that helps you
retain them.
The first part can be solved using the cohorts from Firebase Analytics.
Cohorts help you visualise your retention by showing you what percentage of
users do you retain over a period of time, broken down by days or weeks. Most of
your users are typically lost in the first couple of days, which is usually an
issue with your activation strategy. However, this decline tends to flatten out.
While you should certainly work on your activation strategy to help improve your
cohort numbers on the first couple of days, you also want to look at some way to
improve the numbers a little later, such as around days 5-7. One fairly
straightforward solution is to build an automated system that sends push
notifications using Firebase Cloud Messaging to these users approximately a week
after they sign up. Using some kind of flag for "last used time", you could also
ensure this notification is only shown to those users who are at risk of being
dropped off.
You could utilize this strategy for things like extending trial periods for
users who haven't used your product enough, giving yourself an extended
opportunity to convert them into paying customers. Deals of any other form
(either for E-commerce products or for in-app products) are other ways.
A carefully crafted strategy could play a critical role in your overall
business. Do be mindful of avoiding a spammy notification system: you'll
probably annoy your users and increase your uninstall count.
There are additional possibilities as well. Firebase Analytics tracks
uninstalled users for you using the automated event "app_remove". As mentioned
in the second
post on acquisition, you can create an audience for users who have fired
this event and retarget them using Adwords.
Also, using Firebase App Indexing in your application would help highlight
content from your service in Google search results for your users. This is
particularly useful during the early phases of the user's time with you when
they haven't quite developed a habit of using your application directly.