If you’ve visited the Firebase console’s Analytics section recently, you might have noticed something new… an updated Analytics dashboard, a new Realtime view and a few other UI enhancements.
These new changes are part of our effort to improve the Google Analytics experience in Firebase, by providing access to some of the newest Google Analytics 4 innovations directly in the Firebase console.
New Google Analytics 4 features available in the console
The Dashboard
Firebase now shows a curated collection of Analytics cards that provide the same information as the previous dashboard, but presented more intuitively to get to key insights faster. This matches the ‘App Developer - Firebase’ collection in Google Analytics 4 - meaning you no longer need to switch to the Google Analytics interface to see this data. The cards are now organized by surfacing overview metrics first, followed by user engagement and retention cards, then monetization and user demographics.
The dashboard now also contains a lot of explorer cards that allow you to more easily drill-down into specifics for data represented by that card for more details - like the new App Versions card which provides a quick view into the number of users you have per app version, and a jumpoff link to see more data like engagement rates, revenue and conversions per app version as well.
The Publisher card is another example of providing a more natural flow to learn more about how different ad units are performing as well as the revenue they are generating.
Before adding this card to the dashboard, accessing this information would require digging into specific event reports, like the ad_impression event report to get out the ad unit performance or revenue data. Well, no need to go digging through various event reports anymore with this updated flow that should make accessing this information more convenient and intuitive.
One feature that’s been around in Google Analytics 4 for a while but only just making an appearance in the Firebase console is the Comparisons tool, which replaces what was previously ‘Filters’. Similar to the Filters tool, with the Comparisons tool you can create comparison groups based on any custom or pre-defined Analytics dimensions or audiences. The advantage of the Comparisons tool is that you can create up to five comparison groups at once, and view and compare the Analytics data for each of these groups across all cards on the Analytics dashboard. For example, if you recently ran a promotional campaign offering 10% off in-app purchases to your top purchasers using Remote Config, you can check to see the impact of that at a glance on metrics like user engagement and app revenue by comparing the top purchasers audience, your most engaged users audience, and all users by applying Comparisons in the dashboard.
Note to compare events or conversions as you would have done using Filters in the past, you can navigate to the Events or Conversions card from the dashboard to reveal a detailed report that you can then apply comparisons on.
Check out this article or this video that covers how to use the Comparison tool in more detail.
The Realtime view
The Realtime dashboard now shows the same views as in Google Analytics 4 and is great for, well, seeing events come in real-time from around the world. This can be really useful after just releasing a new feature, and seeing new events come in for the first time as it rolls out to your users. The updated dashboard contains new cards and new card capabilities, like the User Acquisition card that can be filtered by source, campaign, medium and platform, as well as the Users card that can now be filtered by audience.
One of the biggest benefits of this new change is the ability to use the Comparisons tool in the Realtime dashboard, too, so you can create and compare different groups over real-time app analytics data.
Google Analytics settings page
As part of this change, the Google Analytics settings page now links out to the Google Analytics console where you can modify any Analytics settings as you would previously in the Firebase > Project Settings > Integration > Google Analytics page. The Analytics Linking card however is still available and can be edited from within the Firebase console.
We invite you to take the updated Analytics dashboard in the Firebase console for a spin, and as always, let us know if you have any feedback or questions.
Developer Advocate
Firebase Analytics provides a lot of nice reports for you out of the box --
things like retention, active users, and some demographic information about the
people using your app. And for specific events, you can see useful stats like
the number of events fired over time or the average number of events per
session. But one thing that you currently can't do (outside of BigQuery) is see
values associated with any custom parameters that you send down in a Firebase Analytics event.
While the team is looking into ways they can make this experience better, there
is one feature you can use right now to get some of the answers you're looking
for. Every event you record in Firebase Analytics can accept a "value" parameter
-- this can be a floating point number or integer -- and Firebase Analytics will
give you back the average of this value over time.
For instance, let's say your fitness app is recording an end-of-workout event
that looks a little like this[1]:
Within the Firebase Analytics reports, you'll be able to see the total number of
workouts completed over time, the average number of workouts completed in a session, and the general age and gender breakdown of people completing
workouts. But you can't, for instance, track the average amount of time people
spent working out.
On the other hand, if you were to provide that same workout time
information in a value parameter like so…
...you'd be able to see this workout time over the lifetime of your app by
looking at the "Value" graphs for the
workout_complete event. In the example screenshot
below, we can see that in the last 30 days, my users have completed about 1400
workouts (the "Event count" graph), and have spent a total of about 1.5 million
seconds (the "Value" graph) doing so. That works out to about 17 minutes per
workout.
Of course, the value parameter won't always give you all the information you
need. If you were interested in comparing the average workout time for your
interval workouts to the average workout time for your yoga workouts, you'd
still need to use
BigQuery to get that kind of data analysis. But I think you'll find you can
get a surprising amount done just with the value parameter.
This value parameter can track completely different values for completely
different events. So you could track average workout length in your
workout_complete event, number of friends invited
in an invite_friends event, or number of calories
consumed in an eat_meal event.
I encourage you take a look at the events you're recording in your app and see
if there's any useful information you might want to see that could be uncoveblack
using these value parameters. You can check out our
docs for more info, and find us on StackOverflow with the Firebase tag.
Happy tracking!
[1] I'm cheating a bit here. Swift 3 requires that I cast all of these values as
NSObjects, but that tends to hide the point of this sample behind a lot of extra
code, so just pretend I'm casting values appropriately. :)
Developer Advocate
Firebase Auth is a secure authentication system that allows users to sign up and
sign in for your application. It allows you to use federated identity through
providers, such as Facebook, Twitter, and of course - Google. When doing this,
your users will demand a rich user experience, and the burden of implementing
this will fall on you as a developer. In addition, creating apps that allow for
sign in involves a lot more than just signing in -- there are many other user
flows, such as choosing from multiple accounts, signing up for new accounts,
resetting passwords and more. This can be a lot of work!
Luckily, the open-source
FirebaseUI libraries make all of this really easy. In this post, you'll take
a look at building a simple web site that allows for sign in and sign up. You'll
use two providers: The built-in Email/Password on Firebase, and federated
identity using Google Sign-In.
Getting Started
To use FirebaseUI, you need a Firebase app or site, and you created these on the
Firebase Console. From here,
select 'Authentication' on the left (1).
When you select 'Sign-In Method' at the top, you'll be given a list of Sign-in
providers. Choose 'Email/Password' and 'Google' (2). Make sure they're enabled.
Additionally, if you are going to host these pages on your own domain, make sure
the domain is added to the list of OAuth redirect domains at the bottom of the
screen. (3).
Now, back on the Overview screen for your project, click 'Add Firebase to your
Web app', and you'll see a popup like this:
This contains all the code you need to initialize Firebase on your web site.
Let's take a look at a simple 2-page web site next: one page for signing in, and
one page for after you've signed in.
A simple site with Sign In
I've built and hosted a simple site using FirebaseUI Auth here. The first page you see when
you go to this site looks like this:
As you can see, it's pretty straightforward, with two sign-in options -- Google
and Email, matching what we configured in the Firebase console.
Clicking Sign-In with Google can have multiple effects based on the context:
If you've signed in previously on this browser, you'll be taken straight
back into the site
If you have multiple Google accounts, you'll be given the account chooser, with
the choice to pick a different account, or create a new one, like this:
If you haven't signed in on this browser, and don't have a Google account,
you'll be given the option to enter one, or create a new one, like this:
Clicking on the Create account link will take you through the standard user flow
for creating an account, which will return you to your site to sign in when
you're done.
Similarly when using Email/Password auth, you'll get the full user flow.
If you've signed in with an Email/Password combination before, and you're the
only user, you'll go straight into the site.
If you've signed in with an Email/Password combination before, but aren't the
only user, you'll get a list of accounts to choose from, like this:
This also gives you the facility to add a new account, and doing so creates a
new account on firebase that you can use to sign in in future. There are many
scenarios, with a very complex flow. To see a detailed flowchart of these, click
here.
So let's look at the code needed to implement this!
Coding the Log In Page
Here's the full source code for the Log In page you've seen in this post. You'll
see that there are two highlighted blocks. The first is the initialization code
that you got from the Firebase console earlier. The second uses the FirebaseUI open source
code to create the user interface widgets.
The things to note in the second block are the signInSuccessUrl parameter, which
is the address of the page to redirect to once the sign in is successful. Also,
note the signInOptions setting where Google Sign-In and Email Sign-In are
configured.
<!DOCTYPE html>
< html lang="en">
< head>
< title>EasyAuth</title>
<meta charset="UTF-8">
</head>
<!-- Below is the initialization snippet for my Firebase project. It will vary for each project -->
<script src="https://www.gstatic.com/firebasejs/3.6.4/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: "AIzaSyAPtNmUso5tA8d83vaJlgDHA_4C7HEgYNY",
authDomain: "authui-6818f.firebaseapp.com",
databaseURL: "https://authui-6818f.firebaseio.com",
storageBucket: "authui-6818f.appspot.com",
messagingSenderId: "596916061379"
};
firebase.initializeApp(config);
</script>
<!-- The code below initializes the sign-in widget from FirebaseUI web. -->
<script src="https://cdn.firebase.com/libs/firebaseui/1.0.0/firebaseui.js"></script>
<link type="text/css" rel="stylesheet" href="https://cdn.firebase.com/libs/firebaseui/1.0.0/firebaseui.css" />
<script type="text/javascript">
var uiConfig = {
signInSuccessUrl: 'loggedIn.html',
signInOptions: [
// Specify providers you want to offer your users.
firebase.auth.GoogleAuthProvider.PROVIDER_ID,
firebase.auth.EmailAuthProvider.PROVIDER_ID
],
// Terms of service url can be specified and will show up in the widget.
tosUrl: '<your-tos-url>'
};
// Initialize the FirebaseUI Widget using Firebase.
var ui = new firebaseui.auth.AuthUI(firebase.auth());
// The start method will wait until the DOM is loaded.
ui.start('#firebaseui-auth-container', uiConfig);
</script>
<!-- Include a simple background image & and title -->
<div></div>
<body>
<h1 align="center" style="color:white;">Firebase Auth Quickstart Demo</h1>
<div id="firebaseui-auth-container"></div>
</body>
</html>
Note that this is all the code you need to implement to get the user flows
mentioned earlier. Everything is encapsulated in the open source library.
The Signed-In page will need the first block of code in order to ensure that it
uses Firebase, and then, when the firebase.auth().onAuthStateChanged event
fires, you know the user is signed in, and you can query their exposed metadata.
Here's the code:
<!DOCTYPE html>
<html lang="en">
<head>
<title>EasyAuth</title>
<meta charset="UTF-8">
</head>
<!-- Below is the initialization snippet for my Firebase project. It will vary for each project -->
<script src="https://www.gstatic.com/firebasejs/3.6.4/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: "AIzaSyAPtNmUso5tA8d83vaJlgDHA_4C7HEgYNY",
authDomain: "authui-6818f.firebaseapp.com",
databaseURL: "https://authui-6818f.firebaseio.com",
storageBucket: "authui-6818f.appspot.com",
messagingSenderId: "596916061379"
};
firebase.initializeApp(config);
</script>
<body>
<!-- A simple example script to add text to the page that displays the user's Display Name and Email -->
<script>
// Track the UID of the current user.
var currentUid = null;
firebase.auth().onAuthStateChanged(function(user) {
// onAuthStateChanged listener triggers every time the user ID token changes.
// This could happen when a new user signs in or signs out.
// It could also happen when the current user ID token expires and is refreshed.
if (user && user.uid != currentUid) {
// Update the UI when a new user signs in.
// Otherwise ignore if this is a token refresh.
// Update the current user UID.
currentUid = user.uid;
document.body.innerHTML = '<h1> Congrats ' + user.displayName + ', you are done! </h1> <h2> Now get back to what you love building. </h2> <h2> Need to verify your email address or reset your password? Firebase can handle all of that for you using the email you provided: ' + user.email + '. <h/2>';
} else {
// Sign out operation. Reset the current user UID.
currentUid = null;
console.log("no user signed in");
}
});
</script>
<h1>Congrats you're done! Now get back to what you love building.</h1>
</html>
And that's it! Hopefully this primer will help you understand the power that you
get with the FirebaseUI Auth libraries, and how they make it much easier for you
to build web apps that sign in!
Software Engineer
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. Towards that aim, we announced
the Firebase Admin
SDKs this past November.
Today, I'm excited to share two new Admin SDK features:
The Node.js SDK now contains an Admin API for sending messages via Firebase
Cloud Messaging (FCM).
The Java SDK can now be initialized from a set of built-in credentials,
making it easier to use, especially on Google infrastructure.
Admin Node.js FCM API
The new Admin
Node.js FCM API simplifies the process of sending messages via FCM. There is
no extra setup required to use this new API as the existing credential used to
authenticate the Node.js SDK handles everything on your behalf. The new API
contains methods for sending messages to individual devices, device groups,
topics, and conditions.
As an example, let's assume you are building an app for the upcoming Super Bowl
and you want to send a notification to anyone subscribed to either the Atlanta
Falcons' topic (/topics/falcons) or the New England Patriots'
topic (/topics/patriots):
var admin = require("firebase-admin");
// Fetch the service account key JSON file contents
var serviceAccount = require("path/to/serviceAccountKey.json");
// Initialize the app with a service account, granting admin privileges
admin.initializeApp({
credential: admin.credential.cert(serviceAccount),
databaseURL: "https://<DATABASE_NAME>.firebaseio.com"
});
// Define who to send the message to
var condition = "'falcons' in topics || 'patriots' in topics";
// Define the message payload
var payload = {
notification: {
title: "Super Bowl LI: Falcons vs. Patriots",
body: "Your team is Super Bowl bound! Get the inside scoop on the big game."
}
};
// Send a message to the condition with the provided payload
admin.messaging.sendToCondition(condition, payload)
.then(function(response) {
console.log("Successfully sent message! Server response:", response);
})
.catch(function(error) {
console.log("Error sending message:", error);
});
You can optionally provide a third option to any of the FCM methods to provide
options for the message. For example, since the game is a little under a week
away, let's send the message with high priority and give it a time to live of
one week:
// condition and payload are the same as above
var options = {
priority: "high",
timeToLive: 60 * 60 * 24 * 7
};
admin.messaging.sendToCondition(condition, payload, options)
.then(function(response) {
console.log("Successfully sent message! Server response:", response);
})
.catch(function(error) {
console.log("Error sending message:", error);
});
This is just a taste of what the new Admin Node.js FCM API allows you to do. See
Send
Messages for more code samples and detailed documentation.
Admin Java Credential Interface
Since the launch of the Admin SDKs last November, the Node.js SDK has supported
several initialization methods while the Java SDK has only allowed
initialization via a service account certificate file. As of the latest Admin
Java SDK release, both SDKs now provide a full credential interface with some
helpful default implementations.
Upgrading to the new API is straightforward. The previous way of initializing
the SDK is via the setServiceAccount() method:
FileInputStream serviceAccount = new FileInputStream("path/to/serviceAccountCredentials.json");
FirebaseOptions options = new FirebaseOptions.Builder()
.setServiceAccount(serviceAccount)
.setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
.build();
FirebaseApp.initializeApp(options);
The updated way of initializing the SDK is via the
setCredential() method.
FileInputStream serviceAccount = new FileInputStream("path/to/serviceAccountCredentials.json");
FirebaseOptions options = new FirebaseOptions.Builder()
.setCredential(FirebaseCredentials.fromCertificate(serviceAccount))
.setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
.build();
FirebaseApp.initializeApp(options);
The Admin Java SDK now includes a credential implementation based on Google
Application Default Credentials. This allows for auto-discovery of service
account credentials on Google infrastructure like Google App Engine and Google
Compute Engine. This means you don't need to manage service account credentials
yourself. Instead, you can make use of Google Application Default Credentials to
run the same exact code on your local, staging, and production environments, no
configuration required.
FirebaseOptions options = new FirebaseOptions.Builder()
.setCredential(FirebaseCredentials.applicationDefault())
.setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
.build();
FirebaseApp.initializeApp(options);
See Initialize
the SDK for more code samples and detailed documentation.
What's next for the Admin SDKs?
We are continually striving to expand our first-class support for backend
developers in the Firebase ecosystem. Stay tuned for more features to be added
to the Firebase Admin SDKs in the future! If you'd like to see a specific
feature, let us know by sending us a note through our feature
request support channel.
Developer Advocate
Debugging Firebase Cloud Messaging is one of the most common Firebase-on-iOS questions I see on StackOverflow. And
so in an effort to garner as many StackOverflow points as I can (oh, yeah, and to educate the developer community),
I thought it might be helpful to write up a full debugging guide on what to do when you can't seem to get Firebase
Cloud Messaging (FCM) working on your iOS device.
First off, I'd recommend taking a moment to watch our Understanding
FCM on iOS video. It'll give you a better idea of what's going on underneath the hood, which is always useful
when you're trying to debug things. Go ahead! I'll wait.
Okay, back? So you probably noticed in the video that we have several systems all talking to each other:
Your app server (or Firebase Notifications) talks to Firebase Cloud Messaging
Firebase Cloud Messaging then talks to APNs
APNs talks to your user's target device
On your user's target device, iOS communicates with your app.
These four paths of communication means there are four opportunities for things to go wrong. And when they do, they
very often manifest as a frustrating "It says my notification was sent, but nothing showed up on my device" kind of
bug, which requires some real detective work. So here are the steps I recommend you go through to start tracking
down these errors.
1. Temporarily disable any connectToFCM() calls
If you'll recall from the video, your app can explicitly connect to Firebase Cloud Messaging by calling connectToFCM()
when it's in the foreground, which allows it to receive data-only messages that don't have a
content-available flag directly through FCM.
And while this can be useful in certain circumstances, I recommend disabling this while you're debugging. Simply
because it's one extra factor that you want to eliminate. I've seen a few, "My app receives notifications in the
foreground, but not in the background" problems out there that probably occurred because the developer was only
receiving messages through the FCM channel, and their APNs setup was never actually working properly
.
If things break at this point: If you suddenly go from "Hey, I was receiving foreground notifications" to "I'm not
receiving any notifications at all", then this is a sign your app was never properly set up to receive notifications
from APNs in the first place. So your app might be a little more broken than before, but at least now it's
consistently broken. (Hooray!) Keep reading to debug your APNs implementation!
For the next several steps, we're going to go backwards through that "Notifications to FCM to APNs to iOS to your
app" chain. Let's start by making sure that iOS can actually speak to your app...
2. Add some good ol' fashioned print() debugging
Thanks to some clever method swizzling, Firebase Cloud Messaging makes it totally unnecessary for you to implement either application(_:didRegisterForRemoteNotificationsWithDeviceToken:) or application(_:didFailToRegisterForRemoteNotificationsWithError:) in your app delegate.
However, for debugging purposes, I like to add in these methods and print out some debug information to see if there
are any errors happening that I should be aware of. Start by adding some debug output to your failure method.
Something like this:
func application(_ application: UIApplication,
didFailToRegisterForRemoteNotificationsWithError error: Error) {
print("Oh no! Failed to register for remote notifications with error \(error)")
}
In theory, any error message printed out here will also probably be printed out by the FCM client library, but I
like having my own messages because I can search for specific strings (like "Oh no!" in the above example) among all
the Xcode output. This also gives me a handy line of code where I can add a breakpoint.
While you're at it, in your didRegister... method, go ahead and print out a human-readable version of your device
token:
func application(_ application: UIApplication,
didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
var readableToken: String = ""
for i in 0..<deviceToken.count {
readableToken += String(format: "%02.2hhx", deviceToken[i] as CVarArg)
}
print("Received an APNs device token: \(readableToken)")
}
You don't need to disable method swizzling or anything to add these debug methods. Firebase will go ahead and call
them just as soon as it's done calling its own set of methods.
If you're seeing an error message at this point: If you either receive an error message or don't get back a
device token, check the error message for a good hint as to what went wrong. Most mistakes at this point fall under
the, "I'm embarrassed to tell anybody why it wasn't working" category. Things like:
Testing on the iOS simulator and not the device.
Forgetting to enable Push Notifications in your Xcode project settings.
Not calling application.registerForRemoteNotifications() when your app starts up.
Sure, these are simple mistakes, but without the benefit of printing out messages to the Xcode console, it's easy
for them to go unnoticed.
3. Confirm that you can send user-visible notifications
As with any iOS app, you need to explicitly get the user's permission to show any kind of notification alert or
sound. If you're in a situation where your app doesn't appear to be receiving notification messages in the
background, your app simply might not have permission from iOS to do so.
You can check this in iOS >= 10 by adding the following code somewhere in your app.
UNUserNotificationCenter.current().getNotificationSettings { (settings) in
print("Alert setting is \(settings.alertSetting ==
UNNotificationSetting.enabled ? "enabled" : "disabled")")
print("Sound setting is \(settings.soundSetting ==
UNNotificationSetting.enabled ? "enabled" : "disabled")")
}
If you're seeing "disabled" messages at this point: Either you accidentally denied granting your app
permission to send you notifications, or you never asked for permission in the first place.
If you accidentally clicked on the "Don't allow" button when the app asked you for permission to send notifications,
you can fix this by going to Settings, finding your app, clicking on Notifications, then clicking the
Allow Notifications switch.
On the other hand, if you never asked for permission to show user-visible permissions, then it means you need to add
code like this (for iOS >= 10) within your app somewhere:
let authOptions : UNAuthorizationOptions = [.alert, .badge, .sound]
UNUserNotificationCenter.current().requestAuthorization(options: authOptions)
{ (granted, error) in
if (error != nil) {
print("I received the following error: \(error)")
} else if (granted) {
print ("Authorization was granted!")
} else {
print ("Authorization was not granted. :(")
}
}
But if everything looks good at this point, you can move on to debugging the APNs connection!
4. Make a call directly through APNs
Remember; just because you're using FCM to handle your notifications doesn't mean you can't also use APNs directly.
There are a few ways you can try this; one option is to use an open-source tool like
NWPusher to send test notifications. But personally, I prefer
sending APNs requests directly through a curl call.
Making an APNs curl request is easier these days now that APNs supports HTTP/2. But it does mean you'll need to make
sure your copy of curl is up-to-date. To find out, run curl --version. You'll probably see something like this:
If you want to talk to APNs, you'll need a version of curl that's greater than 7.43, and you'll need to see HTTP2
among the features. If your version of curl doesn't meet these requirements, you'll need to update it. This blog post by Simone Carletti gives
you some pretty nice instructions on how to do that.
Next, you'll need to convert the .p12 file you downloaded from the Apple Developer Portal to a .pem file. You can do
that with this command:
You'll also need the APNs device token for your target device. If you added the debug text listed earlier in your
application(_:didRegisterForRemoteNotificationsWithDeviceToken:) method, you'll be able to grab this from your Xcode
console. It should look something like
ab8293ad24537c838539ba23457183bfed334193518edf258385266422013ac0d
Now you can make a curl call that looks something like this:
That --cert argument should link to the .pem file you created in the previous step.
For the apns-topic, include the bundle ID of your app. And yes, the concept of apns-topics are completely different than Firebase Cloud Messaging topics.
Make sure your device ID is included at the end of that URL there. Don't just copy-and-paste the one that I have. It won't work.
If all has gone well, you'll see a push notification on the device, and you can move on to the next step. If not, here's a few things to look for:
Are you getting back any error message from APNs? That's a pretty good sign something has gone wrong. Common messages include:
"Bad device token" -- This is what it sounds like. Your device token is incorrect. Double-check that you've copied it correctly from your app
"Device token not for topic" -- This might mean that your topic isn't properly set to your app's bundle ID.
But it also might mean that you're not using the correct certificate here -- I've gotten this message when
I've used the wrong .pem file.
Is your app in the background? Remember that iOS will not automatically show notification alerts or sounds if your app is in the foreground.
However, in iOS 10, they've made it significantly easier to have iOS show these alerts even if your app is
in the foreground. You just need to call completionHandler([.alert]) at the end of
userNotificationCenter(_:willPresent:withCompletionHandler:)
Are you sending valid APNs requests? There are a few types of requests that, while syntactically correct, may
still get rejected. At the time of this writing, these include sending silent notifications that don't include
the content-available flag, or sending silent notifications high priority.
In addition, iOS may throttle silent notifications if your app neglects to call its completionHandler in a
reasonable amount of time upon receiving them or uses too much power to process these notifications. Refer
to Apple's
documentation for more information.
But if things seem to be working correctly here, it's time to move on to the next step...
5. Make a curl call directly through FCM
Once you've confirmed your APNs call seems to be working properly, the next step is to confirm the FCM part of the
process is working. For that, I also like to make another curl call. For this to work, you're going to need two
things: The server key and the FCM device token of your target device.
To get the server key, you'll need to go to the Cloud Messaging settings of
your project in the Firebase Console. Your server key should be listed there as a giant 175-character string.
Getting your FCM device token is slightly more work. When your app first receives an APNs token, it will send that
off to the FCM servers in exchange for an FCM device token. When it gets this FCM token back, the FCM library will
trigger an "Instance ID Token Refresh" notification. 1
So listening to this firInstanceIDTokenRefresh NSNotification will let you know what your FCM device token is, but
this notification only gets triggered when your device token changes. This happens infrequently -- like when you
switch from a debug to production build, or when you run your app for the first time. Otherwise, this notification
will not be called.
However, you can retrieve your cached FCM device token simply through the InstanceID library, which will give you
any stored device token if it's available. So to get your latest-and-greatest FCM token, you'll want to write some
code like this:
func application(_ application: UIApplication, didFinishLaunchingWithOptions
// ...
printFCMToken() // This will be nil the first time, but it will give you a value on most subsequent runs
NotificationCenter.default.addObserver(self,
selector: #selector(tokenRefreshNotification),
name: NSNotification.Name.firInstanceIDTokenRefresh,
object: nil)
application.registerForRemoteNotifications()
//...
}
func printFCMToken() {
if let token = FIRInstanceID.instanceID().token() {
print("Your FCM token is \(token)")
} else {
print("You don't yet have an FCM token.")
}
}
func tokenRefreshNotification(_ notification: NSNotification?) {
if let updatedToken = FIRInstanceID.instanceID().token() {
printFCMToken()
// Do other work here like sending the FCM token to your server
} else {
print("We don't have an FCM token yet")
}
}
The very first time your app runs, you'll see a message that you don't have an FCM token, followed by a message a short
time later with your actual token. In subsequent runs, you should see your cached token right away. It's a 153-character
random string that looks a lot like your server key, so don't get 'em confused.
So, now that you have both pieces of information, you can make a curl call. Try calling something like this:
> curl --header "Content-Type: application/json" \
--header "Authorization: key=AU...the rest of your server key...s38txvmxME-W1N4" \
https://fcm.googleapis.com/fcm/send \
-d '{"notification": {"body": "Hello from curl via FCM!", "sound": "default"},
"priority": "high",
"to": "gJHcrfzW2Y:APA91...the rest of your FCM token...-JgS70Jm"}'
If all has gone well, you'll see a notification on your device, as well as receive a "Success" response from
FCM.
Don't get too excited by this success response. That just means FCM has successfully received your message; it
doesn't mean that it has successfully delivered it to APNs. You really want to look for the notification on your
device.
If your notification doesn't seem to be getting received, here's a few things to look out for:
Are you seeing an error message in your response? Don't ignore those. They're usually pretty big hints as to
what's going on.
InvalidRegistration means you don't have the correct FCM device token. (Remember, it's actually called a
"registration token")
A 401 error with the message "The request's Authentification (Server-) Key contained an invalid or malformed
FCM-Token" means the server key is probably incorrect. Make sure you've copied the whole thing correctly
from the Firebase console.
Is your priority set to high? Android and iOS devices have different interpretations of medium and high priority
values.
On Android, medium priority basically means, "Send the message, but be respectful of your user's device if it's
in doze mode". This is generally why FCM uses "medium" as its default priority if you don't specify one.
On iOS, medium (or 5) priority can best be summarized as, "Maybe we'll send it at some point. But in this
crazy world of ours, who can say for sure?!? ¯\_(ã)_/¯".
This is why APNs defaults to a priority value of 10 (or "high") when no priority value is specified and they
really only ask you to send messages medium priority when you're sending a data-only content-available
message.
Ideally, you should send most user-visible messages with medium priority to Android devices and high
priority to iOS devices. If you're using the Firebase Notifications panel, you can do this pretty easily.
Are you using APNs syntax instead of FCM syntax? While FCM will properly translate FCM-speak to APNs, it will
get confused if you send it APNs syntax in the first place. So double-check that you're sending messages
properly formatted for FCM. In particular, confirm that you're setting "priority" to "high" and not "10".
If you're sending a content available message, make sure you're specifying "content_available": true with an
underscore and not "content-available":2
I also recommend trying to send a Notification through the Firebase Notifications panel at this point. If
you can make a call through Notifications but not through a curl call, it might be a sign that your message
isn't properly formatted.
Have you uploaded your APNs certificate to the Firebase console? And has it expired? Remember, FCM needs that
certificate in order to communicate with APNs.
6. Make a call through the Notifications panel and/or your server
So if you've gotten to this point, we've basically established that the path from FCM to APNs to iOS to your app is
working correctly. So I would be very surprised if the Notifications panel wasn't working at this point. If it is,
the best thing to do is check status.firebase.google.com and see
if there are any issues with the Cloud Messaging service. (This also includes the Notifications panel)
If the problem is with your server code, well… that's up to you and your server. But now that you've figured out exactly
what data you need to generate to make a proper FCM call, I'm hoping you can tackle this part on your own with
confidence. Or, at least, the appearance of confidence, which is enough to fool most people.
Whew! Well, I know that was a lot to go through, and hopefully you were able to stop at, like, step 2 because it
turns out you forgot to flip some switch in your Xcode project. If that's the case, you're probably not even reading
this conclusion. Come to think of it, if you made it this far, it's probably because you're still having problems
with your implementation, in which case… uh… go check out our support
channels. Or ask @lmoroney, because I'm basically out of suggestions at this point.
Thanks for reading!
[1] That's an NSNotification, not an APNs notification.
Hooray for overloaded terms!
[2] One interesting error I ran into was a developer who
couldn't understand why his content-available messages were only being received when his app was in the foreground.
It turns out he had explicitly connected to FCM (like in step 1) and was using the (invalid) "content-available" key
in his message. Since FCM didn't translate this into a valid APNs content-available message, it interpreted it as a
data-only message that should only be sent over FCM, which is why it only worked when his app was in the foreground.
Developer Advocate at ProgressSWGuest blogger Jen Looper
The powerful combination of NativeScript, Firebase, and Angular 2 can kickstart
your app building into high gear, especially during the holidays when you find
yourself confronted with the need to speed up your app development AND meet your
family's gift-giving needs! Just in time, I am happy to present
to you (see what I did there ð) a demo of how to leverage Firebase in your Angular 2-powered NativeScript apps
using several elements of Eddy Verbruggen's famous
NativeScript-Firebase plugin.
In this tutorial, I'm going to show you how to use four popular Firebase
elements in your NativeScript app: Authentication with a login
and registration routine; Database for data storage and
real-time updates; Remote Config to make changes to an app
remotely; and Storage for saving photos. To do this, I decided
to rewrite my Giftler
app, originally written in Ionic.
Before we get started, I encourage you to read through the
documentation before starting in on your project, and make sure that a few
prerequisites are in place:
Ensure that
NativeScript is installed on your local machine and that the CLI works as
expected
Configure your preferred IDE for NativeScript and Angular development.
You're going to need TypeScript, so ensure that your transpiling process
is working. There are excellent NativeScript plugins available for
Visual Studio, Visual
Studio Code, and
Jetbrains-compatible IDEs, among others. Visual Studio Code in particular
has handy
snippets that speed up development
Log in to your Firebase account and find your console
Create a new project in the Firebase console. I named mine 'Giftler'. Also
create an iOS and Android app in the Firebase console. As part of this process
you'll download both a GoogleServices-Info.plist and google-services.json file.
Make sure you note where you place those files, and you'll need them in a
minute.
Install the dependencies
I've built Giftler as an example of an authenticated NativeScript app where
users can list the gifts that they would like to receive for the holidays,
including photos and text descriptions. For the time being, this app does the
following on iOS and Android:
allows login and logout, registration, and a 'forgot password' routine
lets users enter gift items into a list
lets users delete items from a list
lets users edit items in the list individually by adding descriptions and
photos
provides messaging from the Remote Config service in Firebase that can be
quickly changed in the backend
Now, fork the Giftler source
code, which is a complete and functional app. Once your app is cloned,
replace the app's current Firebase-oriented files that you downloaded when you
created your app:
In the /app/App_Resources/Android folder, put the google.services.json file
that you downloaded from Firebase.
Likewise, in /app/App_Resources/iOS folder, put the GoogleService-Info.plist
file also downloaded from Firebase.
These files are necessary to initialize Firebase in your app and connect it to
the relevant external services.
Now, let's take a look at the package.json at the root of this app. It contains
the plugins that you'll use in this app. I want to draw your attention to the
NativeScript-oriented plugins:
The NativeScript-Angular plugin is NativeScript's integration of Angular. The
Camera plugin makes managing the camera a bit easier. IQKeyboardManager is an
iOS-specific plugin that handles the finicky keyboard on iOS. The Theme plugin
is a great way to add default styles to your app without having to skin the app
entirely yourself. And finally, the most important plugin in this app is the
Firebase plugin.
With the dependencies in place and the plugins ready to install, you can build
your app to create your platforms folder with iOS and Android-specific code and
initialize the Firebase plugin along with the rest of the npm-based plugins.
Using the NativeScript CLI, navigate to the root of your cloned app and type tns
run ios or tns run android. This will start the plugin building routines and,
in particular, you'll see the various parts of the Firebase plugin start to
install. The install script that runs will prompt you to install several
elements to integrate to the various Firebase services. We're going to select
everything except Messaging and social authentication for the moment. A great
feature is that a firebase.nativescript.json file is installed at the root of
the app, so if you need to install a new part of the plugin later, you can edit
that file and reinstall the plugin.
At this point, if you run tns livesync ios --watch or tns livesync android
--watch to see the app running on an emulator and watching for changes, you
would see a the app running and ready to accept your new login. Before you
initialize a login, however, ensure that Firebase handles Email/Password type
logins by enabling this feature in the Firebase console in the Authentication
tab:
Let's take a look under the covers a bit to see what's happening behind the
scenes. Before you can log in to Firebase, you need to initialize the Firebase
services that you installed. In app/main.ts, there are a few interesting bits.
// this import should be first in order to load some required settings (like
globals and reflect-metadata)
import { platformNativeScriptDynamic } from "nativescript-angular/platform";
import { AppModule } from "./app.module";
import { BackendService } from "./services/backend.service";
import firebase = require("nativescript-plugin-firebase");
firebase.init({
//persist should be set to false as otherwise numbers aren't returned during
livesync
persist: false,
storageBucket: 'gs://giftler-f48c4.appspot.com',
onAuthStateChanged: (data: any) => {
console.log(JSON.stringify(data))
if (data.loggedIn) {
BackendService.token = data.user.uid;
}
else {
BackendService.token = "";
}
}
}).then(
function (instance) {
console.log("firebase.init done");
},
function (error) {
console.log("firebase.init error: " + error);
}
);
platformNativeScriptDynamic().bootstrapModule(AppModule);
First, we import firebase from the plugin, and then we call .init(). Edit the
storageBucket property to reflect the value in the Storage tab of your Firebase
console:
Now your app is customized to your own Firebase account and you should be able
to register a new user and login in the app. You can edit the user.email and
password variables in app/login/login.component.ts file to change the default
login credentials from user@nativescript.org to your own login and password if
you like.
The iOS and Android login screens
Note: you should be able to emulate your app right away on iOS, using the
Xcode simulator. On Android, make sure that you select an Android SDK emulator image that supports Google Services, such as "Google APIs Intel x86 Atom System Image." It can be hard to get the versions lined up perfectly, so pay close attention to the Firebase dependencies and version info.
Code Structure and Authentication
Angular 2 design patterns require that you modularize your code, so we will
oblige by using the following code structure:
—login
login.component.ts
login.html
login.module.ts
login.routes.ts
—list …
—list-detail …
—models
gift.model.ts
user.model.ts
index.ts
—services
backend.service.ts
firebase.service.ts
utils.service.ts
index.ts
app.component.ts
app.css
app.module.ts
app.routes.ts
auth-guard.service.ts
main.ts
I want to draw your attention to the way Firebase authentication works with the
Angular 2 auth-guard.service. When Firebase is initialized in your app in
app/main.ts as we saw above, the onAuthStateChanged function is called:
When the app starts, check the console for the stringified data being returned
by Firebase. If this user is flagged as being loggedIn, we will simply set a
token which is the userId sent back by Firebase. We'll use the NativeScript
application settings module, which functions like localStorage, to keep this
userId available and associate it to the data that we create. This token and the
authentication tests that use it, managed in the app/services/backend.service.ts
file, are made available to the app/auth-guard.service.ts file. The auth-guard
file offers a neat way to manage logged-in and logged-out app state.
The AuthGuard class implements the CanActivate interface from the Angular Router
module.
Essentially, if the token is set during the above login routine, and the
BackendService.isLoggedIn function returns true, then the app is allowed to
navigate to the default route which is our wish list; otherwise, the user is
sent back to login:
Now that you have initialized your Firebase-powered NativeScript app, let's
learn how to populate it with data and use Firebase's amazing realtime power to
watch for the database to be updated.
Making your list, checking it twice
Starting in app/list/list.html, which is the basis of the wish list, you'll see
a textfield and a blank list. Go ahead, tell Santa what you want! The items are
sent to the database and added to your list in realtime. Let's see how this is
done.
First, note that in app/list/list.component.ts, we set up an observable to hold
the list of gifts:
public gifts$: Observable;
then, we populate that list from the database when the component is initialized:
It's in the firebaseService file that things get interesting. Note the way that
this function adds a listener and returns an rxjs observable, checking for
changes on the Gifts collection in the Firebase database:
getMyWishList(): Observable {
return new Observable((observer: any) => {
let path = 'Gifts';
let onValueEvent = (snapshot: any) => {
this.ngZone.run(() => {
let results = this.handleSnapshot(snapshot.value);
console.log(JSON.stringify(results))
observer.next(results);
});
};
firebase.addValueEventListener(onValueEvent, `/${path}`);
}).share();
}
The results of this query are handled in a handleSnapshot function below, which
filters the data by user, populating an _allItems array:
handleSnapshot(data: any) {
//empty array, then refill and filter
this._allItems = [];
if (data) {
for (let id in data) {
let result = (Object).assign({id: id}, data[id]);
if(BackendService.token === result.UID){
this._allItems.push(result);
}
}
this.publishUpdates();
}
return this._allItems;
}
And finally, publishUpdates is called, which sorts the data by date so that
newer items are shown first:
publishUpdates() {
// here, we sort must emit a *new* value (immutability!)
this._allItems.sort(function(a, b){
if(a.date < b.date) return -1;
if(a.date > b.date) return 1;
return 0;
})
this.items.next([...this._allItems]);
}
Once the data has populated your $gifts observable, you can edit and delete
elements of it and it will be handled by the listener and the front end updated
accordingly. Note that the onValueEvent function of getMyWishList method
includes the use of
ngZone which ensures that, although data updates occur asynchronously, the
UI is updated accordingly. A good overview of ngZone in NativeScript apps can be
found
here.
Remotely Configured Messages from Beyond
Another cool piece of Firebase's service includes "Remote Config", a way to
provide app updates from the Firebase backend. You can use Remote Config to
toggle features on and off in your app, make UI changes, or send messages from
Santa, which is what we're going to do!
In app/list/list.html, you'll find a message box:
<Label class="gold card" textWrap="true" [text]="message$ | async"></Label>
The message$ observable is built in much the same way as the data list; changes
are picked up in this case each time the app is freshly initialized:
And the magic occurs in the service layer (app/services/firebase.service.ts ):
getMyMessage(): Observable{
return new Observable((observer:any) => {
firebase.getRemoteConfig({
developerMode: false,
cacheExpirationSeconds: 300,
properties: [{
key: "message",
default: "Happy Holidays!"
}]
}).then(
function (result) {
console.log("Fetched at " + result.lastFetch + (result.throttled ? "
(throttled)" : ""));
for (let entry in result.properties)
{
observer.next(result.properties[entry]);
}
}
);
}).share();
}
Publish new messages as often as you like!
Note: tinkering repeatedly with Remote Config may cause throttling of your
Firebase instance, so develop with care
Take a picture!
One of the more interesting parts of this project, I think, is the ability to
take a picture of your present of choice and store it in Firebase Storage. I
leveraged the Camera plugin, as mentioned above, which makes managing the
hardware a little easier. To start, ensure that your app has access to the
device camera by getting permissions set in the ngOnInit() method in
app/list-detail/list-detail.component.ts:
ngOnInit() {
camera.requestPermissions();
...
}
A chain of events begins when the user clicks the 'Photo' button in the detail
screen. First,
takePhoto() {
let options = {
width: 300,
height: 300,
keepAspectRatio: true,
saveToGallery: true
};
camera.takePicture(options)
.then(imageAsset => {
imageSource.fromAsset(imageAsset).then(res => {
this.image = res;
//save the source image to a file, then send that file path to
firebase
this.saveToFile(this.image);
})
}).catch(function (err) {
console.log("Error -> " + err.message);
});
}
The camera takes a picture, and then that photo is stored as an imageAsset and
displayed on the screen. The image is then named with a date stamp and saved to
a file locally. That path is reserved for future use.
Once the 'Save' button is pressed, this image, via its local path, is sent to
Firebase and saved in the storage module. Its full path in Firebase is returned
to the app and stored in the /Gifts database collection:
editGift(id: string){
if(this.image){
//upload the file, then save all
this.firebaseService.uploadFile(this.imagePath).then((uploadedFile: any) =>
{
this.uploadedImageName = uploadedFile.name;
//get downloadURL and store it as a full path;
this.firebaseService.getDownloadUrl(this.uploadedImageName).then((downloadUrl:
string) => {
this.firebaseService.editGift(id,this.description,downloadUrl).then((result:any)
=> {
alert(result)
}, (error: any) => {
alert(error);
});
})
}, (error: any) => {
alert('File upload error: ' + error);
});
}
else {
//just edit the description
this.firebaseService.editDescription(id,this.description).then((result:any)
=> {
alert(result)
}, (error: any) => {
alert(error);
});
}
}
This chain of events seems complicated, but it boils down to a few lines in the
Firebase service file:
The end result is a nice way to capture both photos and descriptions of the
gifts for your wish list. No more excuses that Santa didn't know exactly WHICH
Kylie Eyeliner to buy. By combining the power of NativeScript and Angular, you
can create a native iOS and Android app in a matter of minutes. By adding
Firebase you have a powerful way of storing your app's users, images and data,
and a way of updating that data in real-time across devices. Cool, huh? It looks
like this:
We are well on our way to create a solid wishlist management app! It remains to
figure out the best way to inform Santa of our wishes - a Mailgun email
integration or using push notifications would be the obvious next route. In the
meantime, best wishes for a wonderful holiday season, and I hope you have a
great time creating awesome NativeScript apps using Firebase!
Want to learn more about NativeScript? Visit http://www.nativescript.org. If you need
help, join the NativeScript Slack channel here.
The Santa
Tracker app for Android is a Google holiday tradition. Every year, millions
of people around the world use the app to play games with elves and reindeer
and, of course, track Santa, as he flies around the world on December 24th.
While the app is live for a few months each year, about 90% of our usage occurs
in the last two weeks of December. In order to turn around improvements to
Santa Tracker quickly over this time, it's critical that we can monitor and
adjust the Santa Tracker app remotely. This year, we decided to go all-in with
Firebase as our monitoring solution. In this blog post, I'll talk about how we
use a combination Analytics, Crash Reporting, and Remote Config to
maintain a high level of quality, without ever having to republish the app.
Firebase Analytics
As users navigate through the app we use Firebase Analytics events to record
their behavior. Most of the mini-games in the app live in their own Activity
classes, so we can use Firebase Analytics' automatic screen tracking feature to
record these events without writing any code.
For events within games we use custom
events to record important user actions. For example after the user finishes
playing the "Penguin Swim" game, we record the event
swimming_game_end with custom parameters score and
num_stars. In the first week of December we noticed that 85% of
users were getting zero stars when playing the Penguin Swim game. Clearly, the
game is too hard, we were hoping that only 60-70% of users would get a score
this low! We were able to correct this using Remote Config, which I'll talk
about later.
The other feature of Analytics that we put to use is user
properties. At the start of each Santa Tracker session, we use user
properties to record some information about the user's device. These properties
are then attached to every analytics event. Since Santa Tracker is used all over
the world, we get a lot of diversity in the devices people use. These user
properties help us to make sense of our analytics data. Some examples are:
API_LEVEL
The API level of the user's device, like 23 for Marshmallow or 21 for
Lollipop.
DEVICE_BRAND
The brand of the user's device, such as Samsung for the Galaxy S7 or
Google for the Pixel XL.
DEVICE_BOARD
The processor or specific SoC name for the user's device.
The combination of our custom events and user properties with Firebase
Analytics' automatically tracked events enables us to get a good understanding
of what our users are doing in the app by looking at the Firebase console.
Firebase Crash Reporting
Despite our best efforts, the Santa Tracker app is not perfect. With millions
of users on hundreds of device types in dozens of countries we are constantly
discovering new bugs in the wild. Firebase Crash Reporting lets us see all of
the fatal errors in our app within a minute of their occurrence. Since Firebase
Analytics events show up in Firebase Crash Reporting logs we can see the
progression of events before the crash which was very helpful in diagnosing some
issues.
For example there's an OutOfMemoryError crash which seems to happen
during the "Penguin Swim" game on some low-RAM devices. We did not see this
error during our testing, but the Firebase Analytics data in Crash Reporting
tells us that this occurs when playing the game repeatedly.
This integration is invaluable in helping us to reproduce issues that our normal
QA setup does not find. We can get the exact device model and then use the
analytics log to recreate the crash conditions.
Firebase Remote Config
Once we have analyzed the data from Analytics and Crash Reporting, we need to
make changes in the app to improve the user experience. Due to the short active
life span of this app there's no time to go through the full development
lifecycle of the app to publish changes, and we don't get a second chance at
Santa's big day!
Santa Tracker uses Firebase Remote Config to gate access to various features,
and to provide remote fine-tuning for experiences in the mini game. For
example, in the "Penguin Swim" game, there are two key variables we store in
Remote Config:
SwimmingObstacleDensity
Control the density of ice cubes and other obstacles in the game, a lower
density makes the game easier.
DisableSwimmingGame
A kill-switch to completely hide the game from the app.
As mentioned earlier, users were having a hard time getting a score higher than
zero stars in the game. In order to make the game more fun, we changed
SwimmingObstacleDensity from 1.5 to 1.1, which made it much easier
for users to dodge obstacles. By making the game easier in this way, the
percentage of users getting 0 stars went down from about 85% to 70%. This
change took place instantly over the air, with no need to publish a new version
of the app!
Right now the OutOfMemoryError in the swimming game happens for DisableSwimmingGame flag to immediately hide the game from affected
users whilst we resolve the issue. By taking advantage of the fact that
Analytics user properties can be referenced in Remote Config, we can even
disable the game only for certain device types! For example, let's say the
Penguin Swim stopped working on all KitKat devices (API level 19).
First, we add a condition based on user properties:
Next, we disable the game only for users who match the condition:
Now the game will only appear for users who will have a stable experience, which
will lead to fewer crashes for our users and more positive app ratings for us.
Final Thoughts
Adding deep Firebase integration to Santa Tracker gives us the ability to
monitor and fine-tune the app over time without releasing app updates. As
developers, it's invaluable to have a clear picture of what our users are really
doing and how we can improve the app. Throughout December we knew we could rely
on Firebase to give Santa Tracker users a magical holiday experience.