The Firebase Blog

Serving dynamic content with Cloud Functions on Firebase Hosting

2017-06-07T11:00:00.000-07:00

Michael Bleigh
Engineer, Firebase Hosting

Three years ago, we launched Firebase Hosting to make it easier for developers to deliver fast, engaging experiences on the web. Two months ago, we launched the beta of Cloud Functions for Firebase to let developers write custom backend logic without having to worry about servers or infrastructure. More recently at Google I/O, we brought Firebase Hosting and Cloud Functions together to provide a flexible set of tools to build Progressive Web Apps with world-class scale and performance.

You can connect an HTTPS Cloud Function to your Firebase Hosting app by adding a rewrite to the firebase.json configuration for your project:


{
  "hosting": {
    "rewrites": [
      {"source": "/function/**", "function":"myFunction"}
    ]
  }
}

Once connected, matching requests seamlessly proxy to your Cloud Function (in the example above, a function named myFunction). This one-line change enables exciting new capabilities for Firebase Hosting users including:

Server-Side Rendering. Until now, Firebase Hosting has only served static content. Now you can serve dynamic content using industry-standard libraries like Express, while still leveraging a lightning-fast global CDN cache.
Custom APIs. With Cloud Functions and Firebase Hosting, you can create custom API endpoints on your own domain, avoiding the overhead of cross-origin requests. Plus, with a few extra lines of code you can authorize your endpoints through Firebase Auth.
User-Generated Web Content. For the first time, Firebase Hosting can generate content compatible with AMP, Twitter Cards, and more without requiring a deploy. This means your Firebase Hosting apps can be more shareable and more searchable than ever before.

For Cloud Functions users, you can now run functions on an SSL-secured custom domain and get powerful caching to avoid unnecessary executions.

To get started using Cloud Functions on Firebase Hosting for your own Firebase project, take a look at our documentation. You can also learn more in our I/O session: Building Fast Web Experiences with Firebase Hosting.

Content Moderation with Cloud Functions for Firebase

2017-06-02T09:00:00.000-07:00

Nicolas Garnier
Developer Programs Engineer

In apps that allow users to post public content - for instance in forums, social networks and blogging platforms - there is always a risk that inappropriate content could get published. In this post, we'll look at ways you can automatically moderate offensive content in your Firebase app using Cloud Functions.

The most commonly used strategy to moderate content is "reactive moderation". Typically, you'll add a link allowing users to report inappropriate content so that you can manually review and take down the content that does comply with your house rules. You can better prevent offensive content from being publicly visible and complement your reactive moderation by adding automated moderation mechanisms. Let's see how you can easily add automatic checks for offensive content in text and photos published by users on your Firebase apps using Cloud Functions.

We'll perform two types of automatic content moderation:

Text moderation where we'll remove swearwords and all shouting (e.g. "SHOUTING!!!").

Image moderation where we'll blur images that contain either adult or violent content.

Automatic moderation, by nature, needs to be performed in a trusted environment (i.e. not on the client), so Cloud Functions for Firebase is a great, natural fit for this. Two functions will be needed to perform the two types of moderation.

Text Moderation

The text moderation will be performed by a Firebase Realtime Database triggered function named moderator. When a user adds a new comment or post to the Realtime Database, a function is triggered which uses the bad-words npm package to remove swear words.We'll then use the capitalize-sentencenpm package to fix the case of messages that contain too many uppercase letters (which typically meaning users are shouting). The final step will be to write back the moderated message to the Realtime Database.

To illustrate this we'll use a simple data structure that represents a list of messages that have been written by users of a chat room. These are made of an object with a text attribute that gets added to the /messages list:


/functions-project-12345
   /messages
       /key-123456
           text: "This is my first message!"
       /key-123457
           text: "IN THIS MESSAGE I AM SHOUTING!!!"

Once the function has run on the newly added messages, we'll add two attributes: sanitized which is true when message has been verified by our moderation function and moderated which is trueif it was detected that the message contained offensive content and was modified. For instance, after the function runs on the two sample messages above we should get:


/functions-project-12345
   /messages
       /key-123456
           text: "This is my first message!",
           sanitized: true,
           moderated: false
       /key-123457
           text: "In this message I am shouting."
           sanitized: true,
           moderated: true

Our moderator function will be triggered every time there is a write to one of the messages. We set this up by using the functions.database().path('/messages/{messageId}').onWrite(...)trigger rule. We'll moderate the message and write back the moderated message into the Realtime Database:


exports.moderator = functions.database.ref('/messages/{messageId}')
  .onWrite(event => {
      const message = event.data.val();

      if (message && !message.sanitized) {
        // Retrieved the message values.
        console.log('Retrieved message content: ', message);

        // Run moderation checks on on the message and moderate if needed.
        const moderatedMessage = moderateMessage(message.text);

        // Update the Firebase DB with checked message.
        console.log('Message has been moderated. Saving to DB: ', moderatedMessage);
        return event.data.adminRef.update({
          text: moderatedMessage,
          sanitized: true,
          moderated: message.text !== moderatedMessage
        });
      }
    });

In the moderateMessage function, we'll first check if the user is shouting and if so fix the case of the sentence and then remove all bad words using the bad-words package filter.


function moderateMessage(message) {
  // Re-capitalize if the user is Shouting.
  if (isShouting(message)) {
    console.log('User is shouting. Fixing sentence case...');
    message = stopShouting(message);
  }

  // Moderate if the user uses SwearWords.
  if (containsSwearwords(message)) {
    console.log('User is swearing. moderating...');
    message = moderateSwearwords(message);
  }

  return message;
}

// Returns true if the string contains swearwords.
function containsSwearwords(message) {
  return message !== badWordsFilter.clean(message);
}

// Hide all swearwords. e.g: Crap => ****.
function moderateSwearwords(message) {
  return badWordsFilter.clean(message);
}

// Detect if the current message is shouting. i.e. there are too many Uppercase
// characters or exclamation points.
function isShouting(message) {
  return message.replace(/[^A-Z]/g, '').length > message.length / 2 || message.replace(/[^!]/g, '').length >= 3;
}

// Correctly capitalize the string as a sentence (e.g. uppercase after dots)
// and remove exclamation points.
function stopShouting(message) {
  return capitalizeSentence(message.toLowerCase()).replace(/!+/g, '.');
}

Note: the bad-words package uses the badwords-list package's list of swear words which only contains around 400 of these. As you know the imagination of the user out there has no limit, so this is not an exhaustive list and you might want to extend the bad words dictionary.

Image Moderation

To moderate images we'll set up a blurOffensiveImages function that will be triggered every time a file is uploaded to Cloud Storage. We set this up by using the functions.cloud.storage().onChange(...) trigger rule. We'll check if the image contains violent or adult content using the Google Cloud Vision API. The Cloud Vision API has a feature that specifically allows to detect inappropriate content in images. Then if the image is inappropriate we'll blur the image:


exports.blurOffensiveImages = functions.storage.object().onChange(event => {
  const object = event.data;
  const file = gcs.bucket(object.bucket).file(object.name);

  // Exit if this is a move or deletion event.
  if (object.resourceState === 'not_exists') {
    return console.log('This is a deletion event.');
  }

  // Check the image content using the Cloud Vision API.
  return vision.detectSafeSearch(file).then(data => {
    const safeSearch = data[0];
    console.log('SafeSearch results on image', safeSearch);

    if (safeSearch.adult || safeSearch.violence) {
      return blurImage(object.name, object.bucket, object.metadata);
    }
  });
});

To blur the image stored in Cloud Storage, we'll first download it locally on the Cloud Functions instance, blur the image with ImageMagick, which is installed by default on all instances, then re-upload the image to Cloud Storage:


function blurImage(filePath, bucketName, metadata) {
 const filePathSplit = filePath.split('/');
 filePathSplit.pop();
 const fileDir = filePathSplit.join('/');
 const tempLocalDir = `${LOCAL_TMP_FOLDER}${fileDir}`;
 const tempLocalFile = `${LOCAL_TMP_FOLDER}${filePath}`;
 const bucket = gcs.bucket(bucketName);

 // Create the temp directory where the storage file will be downloaded.
 return mkdirp(tempLocalDir).then(() => {
   console.log('Temporary directory has been created', tempLocalDir);
   // Download file from bucket.
   return bucket.file(filePath).download({
     destination: tempLocalFile
   });
 }).then(() => {
   console.log('The file has been downloaded to', tempLocalFile);
   // Blur the image using ImageMagick.
   return exec(`convert ${tempLocalFile} -channel RGBA -blur 0x8 ${tempLocalFile}`);
 }).then(() => {
   console.log('Blurred image created at', tempLocalFile);
   // Uploading the Blurred image.
   return bucket.upload(tempLocalFile, {
     destination: filePath,
     metadata: {metadata: metadata} // Keeping custom metadata.
   });
 }).then(() => {
   console.log('Blurred image uploaded to Storage at', filePath);
 });
}

Cloud Functions for Firebase can be a great tool to reactively and automatically apply moderation rules. Feel free to have a look at our open source samples for text moderation and image moderation.

Introducing Firebase Performance Monitoring

2017-05-30T12:32:00.000-07:00

Ali Abdelhadi
Product Manager

Monitoring performance from the end user's point of view - both app code performance and network responsiveness/reliability - is a challenge for building great mobile apps. You have to be able to understand conditions that need improvement, in order to avoid user churn and negative reviews. Conversely, we have seen that 60% of 5-star reviews on Google Play mention speed, design or usability.

The biggest challenge in monitoring performance in native apps is understanding context. It's not enough to know that users experience delays or that your animations are not running smoothly; you need to understand where in your app that happens. It's also important to understand how those experiences differ for various countries, devices, OS levels, etc.

This is why we built Firebase Performance Monitoring for iOS and Android. It provides an SDK to capture and instrument performance metrics in production, and a console to gain insights about the data captured by the SDK.

Firebase Performance Monitoring provides two main features: traces and network activity monitoring. Let's talk about traces first. Traces allow you to instrument parts of your app to know the duration of an action, as well as attach custom metrics to that action using the "counter" API. As an example, you might set up a trace for the time from starting an image load until the image is fully rendered on the screen, and track how many times you hit or miss the cache while loading images using counters.
Just by installing the SDK, you get an automated trace for your app start so you can monitor how long it takes users to go through a cold app start.

The other feature Firebase Performance offers is monitoring network activity. HTTP/S requests made by your app will be automatically monitored from the time they are sent until the response is received. For each URL pattern, you will see the response time, payload size and success rate.

When failures happen, you will also see a breakdown of 400 and 500 response codes that caused them.

All metrics collected for traces and network can be broken down by country, device, app version and OS version. This helps you narrow down the cause of an issue and fix it more easily.

Firebase Performance Monitoring is available now in beta. To learn more, check out the documentation right here, or watch our I/O session for a deep dive.

Firebase Phone Auth

2017-05-25T10:20:00.000-07:00

Laurence Moroney
Developer Advocate

When Firebase was first released, it came with a number of authentication schemes:

You could build an app for email & password authentication (iOS, Android, Web), where the user provides you with basic details -- and Firebase would manage signing in using those as their identity. You could also build using federated identity where, instead of signing up for your app, users could simply sign in using credentials provided by third parties such as Google, Facebook, Twitteror GitHub, or anonymous authentication where you could apply security rules to people who haven't yet signed up.

One type of authentication that was requested by a number of developers was the ability to sign in using a phone number. With that in mind, we're delighted to announce that Firebase Auth now supports phone number authentication. If you're currently using the Digits SDK for phone number auth, check out the announcement herefor details on the migration to Firebase Auth.

Here's how Firebase Phone Auth works.

The Sign In Screen

Here's an example of an app that supports phone auth as well as federated identity via Google and Facebook, and basic email/password authentication.

It has been built using FirebaseUI, so many of the flows that you see in this article are automatically implemented for you when you integrate it.

As you can see at the bottom of the screen, there's a 'Sign in with Phone' option.

Let's take a look at what happens when the user taps that.

Sign In Flow

When the user first taps the Sign In with Phone button, they’ll enter the phone number for the device. When they press ‘Verify’, the number will be sent to Firebase, which will generate a 6-digit code that is sent via SMS to their device.

If the user enters the correct code, Firebase will validate them and add them as a recognized user. They’ll then stay signed in for future sessions.

You’ll see them as a verified user in the Firebase Console:

You can learn more about Firebase Authentication on the Firebase Developers Site.

Firebase UI is an Open Source library that lets you quickly get up and running with best-practice sign in and sign up flows. Phone Auth with Firebase UI is presently available oniOS and the Web, and coming soon to Android.

We're continuing to grow and build Firebase and Firebase Authentication, and we'd love to hear your feedback, so please reach out to us at firebase.google.com/support.

What's new with Analytics?

2017-05-23T12:03:00.001-07:00

Krista Seiden
Firebase Analytics

Here at Firebase, we know that the first step in making improvements in your app is knowing how your users are interacting with it: what parts they love, where they're having trouble, and what features are sadly underutilized. This is why we built Google Analytics for Firebase from the ground up to be a complete mobile analytics solution, with free and unlimited app analytics designed specifically for the way mobile apps are built.

Now, if you were paying close attention to the last paragraph, you may have noticed that the product formerly known as Firebase Analytics is now called "Google Analytics for Firebase." Don't worry; it's the same analytics product you know and love -- and we'll talk more about the name change in a bit.

Over the last year, we've made a number of improvements to Google Analytics for Firebase, including adding StreamView, which gives you an impression of how users are interacting with your app at this very moment, and DebugView, which allows you to see in precise detail what analytics events (and errors!) might be happening on a test device.

This year at Google I/O, we were thrilled to announcea number of new improvements and enhancements that make using analytics even better. In case you missed those presentations (which you can also watch on YouTube), let's give you a quick summary of what's new with Google Analytics for Firebase.

Custom Parameter Reporting

With Google Analytics for Firebase, you're allowed to submit up to 25 custom parameters alongside any events that you record in your app. For instance, if you were submitting a end_of_round event in a game, you could submit a user_score or premium_coins_earned parameter along with that event. By analyzing these different parameter values, you could then ensure that your game had the high score distribution or general payout rate that you were expecting.

But up until now, it's been impossible to see the results of most of these custom event parameters without first exporting your data to BigQuery and doing the analysis there. Being able to view summaries of these event parameters directly in the Firebase console has been our most common feature request since analytics first launched last year. So we're very pleased to announce that we've taken our first big steps in making these reports available to you.

To get started with custom event parameters in Firebase, you'll need to let Google Analytics for Firebase know what parameters you're interested in. You can do this by going to the specific event in the Firebase console and clicking the "Add event parameters" button in the interface. From there, you can specify a parameter, note whether it's a number or a string, and add units of measurement, if applicable.

Once you've done that, you'll start seeing these parameter summaries directly in the console. We'll show you sums and averages for numeric values, and a list of your most popular values for strings.

Like other analytics reports available in Google Analytics for Firebase, you can filter these reports by user properties or audiences to get a better sense of how different users are interacting with your app in different ways.

Currently, you can specify up to 50 different event parameters for which you'd like to generate summary reports.

Free Storage Tier in BigQuery

Of course, if you want to analyze a greater number of custom event parameters, or want to do more sophisticated analysis than what's available from the Firebase console, you can export your Google Analytics data directly into BigQuery, Google's data warehouse in the cloud. Analyzing your data in BigQuery is a very powerful way of running all sorts of ad hoc queries or custom analysis on your data, and we want to encourage all our developers to try it out.

To assist you on your journey, we've now added a free tier of storage in BigQuery -- 10 GB of data to be exact -- for every project using Google Analytics for Firebase. Combine this free storage tier with the 1 TB of free monthly query usage that you get from BigQuery, and you can do an awful lot of BigQuery analysis for a relatively little amount of money. And with the new analytics report templates in Data Studio, making stylish reports on custom parameters (or anything else you can measure in BigQuery) is a cinch.

Firebase and AdMob

We've made some major enhancements in the way Firebase and AdMob communicate with each other. Much like milk and cookies¹, mixing Firebase and AdMob together results in an exciting new flavor combination that complements the strengths of both products!

By linking your AdMob account to Firebase, your app will automatically record analytics events associated with AdMob (along with mediated ad units) just like any other analytics event. This gives Google Analytics for Firebase the ability to create reports on ad impressions, clicks, and exposure time, broken down by important characteristics such as screen, ad format or ad unit. This makes it easier than ever before to see which ads are most effective in your app, where you're earning the most ad dollars, or which ads your users spend the most time viewing.

Linking your AdMob and Firebase accounts together also gives you a more complete picture of where you're making money in your app. Both the APRU reports on the dashboard and the Lifetime Value metrics in the Attribution reports will now include revenue generated from AdMob advertising, as well as in-app purchases.

This can help you gain a much more complete understanding of how your app is doing from a revenue standpoint, and help you more accurately gauge which growth campaigns are bringing you users who are earning you the most revenue.

Automatic Screen Tracking

If, like me, you enjoy spending your free time reading the latest Firebase Release Notes, you might have noticed that a few months ago, Firebase started adding screen tracking support to the events that it was recording. This month, we're taking the first steps towards adding screen tracking reports in Google Analytics for Firebase, by showing you the top three screens your users are spending time on. You can find this information in the User Engagement section of the Firebase Dashboard.

Screen tracking reporting works behind the scenes by automatically logging a screen_view event whenever a screen transition occurs. These events are then combined on the server to paint a more complete picture of the user's journey throughout your app. And just like any other event, you can view them in StreamView or DebugView, or analyze them through BigQuery. If you would like to customize these events -- for instance, you're a game developer who has multiple "screens" all within the same ViewController -- you can do so with by setting these events manually on the client.

More Attribution Partners!

You can already use Google Analytics for Firebase for attribution tracking, which helps you learn not just which ad networks are sending you users, but which ones are sending you valuable users that you care about the most. And we're pleased to announce a new integration with DoubleClick Digital Marketing that will include attribution tracking for DoubleClick Campaign Manager and Bid Manager. Add this to the 50+ third-party advertising networks (and growing!) that we've integrated into our system, and Firebase can help you make better decisions around where to spend your advertising dollars with true cross-network attribution data.

New Name, Same Great Product

We're rebranding Firebase Analytics as Google Analytics for Firebase to make it clear that this is our recommended apps analytics solution for all mobile apps moving forward. But under the hood, you'll still be using the Firebase Analytics SDK with its event-driven model to generate all of your analytics data.

If you're using the old Google Analytics Services SDK in your existing apps, don't worry; it's not going anywhere. But we encourage you to start adding the Firebase SDK in future releases. Using the Firebase SDK will give you access to the latest reports in Google Analytics for Firebase and to new functionality as it becomes available. If you're a long-time Google Analytics fan, you can use Google Tag Manager to automatically send your events data to those reports as well. If you need more help on this topic, we wrote a blog post a few months back that covers a few strategies on how to get both these analytics libraries working together in your app. Give it a read sometime!

Try it Today!

We're thrilled to be bringing you these improvements to Google Analytics for Firebase -- they should be already available in the Give it a read sometime today (check out the demo project for an example!). If you haven't yet added analytics to your product, you can find all the documentation you need here to get started. Give it a try, and let us know what you think!

^{1. Or chili and mango, which Steve Ganem assures me is delicious, but sounds weird to me.↩}

Open sourcing the Firebase SDKs

2017-05-19T10:00:00.000-07:00

Salman Qadri
Firebase Product Manager

Originally posted on the Google Open Source Blog.

We are pleased to announce that we are taking our first steps towards open sourcing our client libraries. By making our SDKs open, we're aiming to show our commitment to greater transparency and to building a stronger developer community. To help further that goal, we'll be using GitHub as a core part of our own toolchain to enable all of you to contribute as well. As you find issues in our code, from inconsistent style to bugs, you can file issues through the standard GitHub issue tracker. You can also find our project in the Google Open Source directory. We're really looking forward to your pull requests!

What's open?

We're starting by open sourcing several products in our iOS, JavaScript, Java, Node.js and Python SDKs. We'll be looking at open sourcing our Android SDK as well. The SDKs are being licensed under Apache 2.0, the same flexible license as existing Firebase open source projects like FirebaseUI.

Let's take a look at each repo:

Firebase iOS SDK 4.0

https://github.com/firebase/firebase-ios-sdk

With the launch of the Firebase iOS 4.0 SDKs we have made several improvements to the developer experience, such as more idiomatic API names for our Swift users. By open sourcing our iOS SDKs we hope to provide an additional avenue for you to give us feedback on such features. For this first release we are open sourcing our Realtime Database, Auth, Cloud Storage and Cloud Messaging (FCM) SDKs, but going forward we intend to release more.

Because we aren't yet able to open source some of the Firebase components, the full product build process isn't available. While you can use this repo to build a FirebaseDev pod, our libraries distributed through CocoaPods will continue to be static frameworks for the time being. We are continually looking for ways to improve the developer experience for developers, however you integrate.

Our GitHub READMEprovides more details on how you build, test and contribute to our iOS SDKs.

Firebase JavaScript SDK 4.0

https://github.com/firebase/firebase-js-sdk

We are excited to announce that we are open sourcing our Realtime Database, Cloud Storage and Cloud Messaging (FCM) SDKs for JavaScript. We'll have a couple of improvements hot on the heels of this initial release, including open sourcing Firebase Authentication. We are also in the process of releasing the source maps for our components, which we expect would really improve the debuggability of your app.

Our GitHub repoincludes instructions on how you can build, test and contribute.

Firebase Admin SDKs

Node.js: https://github.com/firebase/firebase-admin-node

Java: https://github.com/firebase/firebase-admin-java

Python: https://github.com/firebase/firebase-admin-python

We are happy to announce that all three of our Admin SDKs for accessing Firebase on privileged environments are now fully open source, including our recently-launched Python SDK. While we continue to explore supporting more languages, we encourage you to use our source as inspiration to enable Firebase for your environment. (And if you do, we'd love to hear about it!)

We're really excited to see what you do with the updated SDKs - as always reach out to us with feedback or questions in the Firebase-TalkGoogle Group, on Stack Overflow, via the Firebase Support team, or now on GitHub for SDK issues and pull requests! And to read about the other improvements to Firebase that launched at Google I/O, head over to the Firebase blog.

What’s new from Firebase at Google I/O 2017

2017-05-17T14:12:00.000-07:00

Francis Ma
Group Product Manager

It's been an exciting year! Last May, we expanded Firebase into our unified app platform, building on the original backend-as-a-service and adding products to help developers grow their user base, as well as test and monetize their apps. Hearing from developers like Wattpad, who built an app using Firebase in only 3 weeks, makes all the hard work worthwhile.

We're thrilled by the initial response from the community, but we believe our journey is just getting started. Let's talk about some of the enhancements coming to Firebase today.

Integrating with Fabric

In January, we announced that we were welcoming the Fabric team to Firebase. Fabric initially grabbed our attention with their array of products, including the industry-leading crash reporting tool, Crashlytics. As we got to know the team better, we were even more impressed by how closely aligned our missions are: to help developers build better apps and grow successful businesses. Over the last several months, we've been working closely with the Fabric team to bring the best of our platforms together.
We plan to make Crashlytics the primary crash reporting product in Firebase. If you don't already use a crash reporting tool, we recommend you take a look at Crashlytics and see what it can do for you. You can get started by following the Fabric documentation.

Phone authentication comes to Firebase

Phone number authentication has been the biggest request for Firebase Authentication, so we're excited to announce that we've worked with the Fabric Digits team to bring phone auth to our platform. You can now let your users sign in with their phone numbers, in addition to traditional email/password or identity providers like Google or Facebook. This gives you a comprehensive authentication solution no matter who your users are or how they like to log in.
At the same time, the Fabric team will be retiring the Digits name and SDK. If you currently use Digits, over the next couple weeks we'll be rolling out the ability to link your existing Digits account with Firebase and swap in the Firebase SDK for the Digits SDK. Go to the Digits blog to learn more.

Introducing Firebase Performance Monitoring

We recognize that poor app performance and stability are the top reasons for users to leave bad ratings on your app and possibly churn altogether. As part of our effort to help you build better apps, we're pleased to announce the beta launch of Performance Monitoring.
Firebase Performance Monitoring is a new free tool that helps you understand when your user experience is being impacted by poorly performing code or challenging network conditions. You can learn more and get started with Performance Monitoring in the Firebase documentation.

More robust analytics

Analytics has been core to the Firebase platform since we launched last I/O. We know that understanding your users is the number one way to make your app successful, so we're continuing to invest in improving our analytics product.
First off, you may notice that you're starting to see the name "Google Analytics for Firebase" around our documentation. Our analytics solution was built in conjunction with the Google Analytics team, and the reports are available both in the Firebase console and the Google Analytics interface. So, we're renaming Firebase Analytics to Google Analytics for Firebase, to reflect that your app analytics data are shared across both.
For those of you who monetize your app with AdMob, we've started sharing data between the two platforms, helping you understand the true lifetime value (LTV) of your users, from both purchases and AdMob revenue. You'll see these new insights surfaced in the updated Analytics dashboard.
Many of you have also asked for analytics insights into custom events and parameters. Starting today, you can register up to 50 custom event parameters and see their details in your Analytics reports. Learn more about custom parameter reporting.

Firebase for all - iOS, games, and open source

Firebase's mission is to help all developers build better apps. In that spirit, today we're announcing expanded platform and vertical support for Firebase.
First of all, as Swift has become the preferred language for many iOS developers, we've updated our SDK to handle Swift language nuances, making Swift development a native experience on Firebase.
We've also improved Firebase Cloud Messaging by adding support for token-based authentication for APNs, and greatly simplifying the connection and registration logic in the client SDK.
Second, we've heard from our game developer community that one of the most important stats you monitor is frames per second (FPS). So, we've built Game Loop support & FPS monitoring into Test Lab for Android, allowing you to evaluate your game's frame rate before you deploy. Coupled with the addition of Unity plugins and a C++ SDK, which we announced at GDC this year, we think that Firebase is a great option for game developers. To see an example of a game built on top of Firebase, check out our Mecha Hamster app on Github.
Finally, we've taken a big first step towards open sourcing our SDKs. We believe in open source software, not only because transparency is an important goal, but also because we know that the greatest innovation happens when we all collaborate. You can view our new repos on our open sourceproject page and learn more about our decision in this blog post.

Dynamic Hosting with Cloud Functions for Firebase

In March, we launched Cloud Functions for Firebase, which lets you run custom backend code in response to events triggered by Firebase features and HTTP requests. This lets you do things like send a notification when a user signs up or automatically create thumbnails when an image is uploaded to Cloud Storage.
Today, in an effort to better serve our web developer community, we're expanding Firebase Hosting to integrate with Cloud Functions. This means that, in addition to serving static assets for your web app, you can now serve dynamic content, generated by Cloud Functions, through Firebase Hosting. For those of you building progressive web apps, Firebase Hosting + Cloud Functions allows you to go completely server-less. You can learn more by visiting our documentation.

Firebase Alpha program and what's next

Our goal is to build the best developer experience: easy-to-use products, great documentation, and intuitive APIs. And the best resource that we have for improving Firebase is you! Your questions and feedback continuously push us to make Firebase better.
In light of that, we're excited to announce a Firebase Alpha program, where you will have the opportunity to test the cutting edge of our products. Things might not be perfect (in fact, we can almost guarantee they won't be), but by participating in the alpha community, you'll help define the future of Firebase. If you want to get involved, please register your interest in the Firebase Alpha form.
Thank you for your support, enthusiasm, and, most importantly, feedback. The Firebase community is the reason that we've been able to grow and improve our platform at such an incredible pace over the last year. We're excited to continue working with you to build simple, intuitive products for developing apps and growing mobile businesses. To get started with Firebase today, visit our newly redesigned website. We're excited to see what you build!

Announcing the Firebase + Fabric party at WWDC17

2017-05-11T12:03:00.001-07:00

Megan Krilanovich
Program Manager

Heading to WWDC this year? Join us at the Firebase + Fabric party on June 5th as we celebrate with the top iOS developers from around the world.

We’re excited to throw our very first iOS developers party at this year’s conference - co-hosting with our teammates at Fabric who’re also deeply passionate about mobile development. If you’re going to be in town, join us for a night to mingle with other developers, meet engineers and PMs from the Firebase and Fabric team, showcase your latest app, or whatever strikes your mood.

We look forward to hearing about all the cool stuff you’ve been working on.

When: June 5th, 2017
Time: 8:00-11:00 p.m.
Where: Forager Tasting Room & Eatery
Price: Free (!)

Tickets are limited so request your invite today!

Seven MORE Sessions I Don't Want to Miss at Google I/O

2017-05-09T14:00:00.000-07:00

Frank van Puffelen
Engineer

Google I/O is rapidly sneaking up on us. I hope those of you attending have your bags packed by now, and those joining on the live stream have started marking the sessions you want to see. It's quite a lineup.

Personally, I'm looking forward to all the new great Firebase content that we're going to be sharing. I know Todd shared the five I/O sessions he was most looking forward to, but here's a list of some of the sessions that you'll find me at:

What's new in Firebase
I have been calling this our "Firebase keynote" internally. I've been following the rehearsals closely and it's shaping up to be a great overview of everything new that we're announcing for Firebase. It'll also be your essential starting point for all things Firebase at I/O; go to this talk and you'll have a good idea of what other sessions you might want to attend.

The future of Fabric: gaining momentum at Google
What is is like for a startup that joins Google? How do you maintain what made your startup unique, but also make optimal use of the resources available at Google? Will Google keep investing in Fabric and Firebase? And what on earth is Bring Your Pineapple To Work Day? Come to this talk and find out from the folks that started Fabric and Firebase, and the Googler who convinced them to join.

Rewarding for engagement
Building a great app is one thing. But convincing your users to keep using your app is another. Gus and Damien have great experience in this area, and together with some developers using Firebase in their app, they'll show you one approach that was very successful. Then they'll show you how to implement that very same approach yourself using Firebase.

Using Firebase to accelerate app growth
There are many ways to use Firebase to get more users on your app. Firebase's product managers Jumana and Jon are the perfect teachers for this topic. I'll be going to their great session to get a fresh overview of the Firebase features that help with growing your app's user base.

Using Pirate Metrics to grow your user base
Ahoy matey! Who can resist a session about Firebase that's centered around Pirates? I certainly can't. I expect buccaneers, swashbucklers and pirate ships! Or, at the very least, an analytics-focused discussion on how to best acquire and retain users through best practices. It might be less pirate-y, but it's easier to put into a business plan. AARRR….!

Single Codebase, Two Apps with Flutter and Firebase
Sure, maybe you've seen live-coding demos where we've built Android and iOS apps on top of Firebase before. But have you ever seen us do it with one codebase? Using Flutter makes it easy -- and maybe even fun -- to build cross-platform apps, and Emily and Emily will show you how in this session. I'm a sucker for live-coding talks and this is one that won't disappoint.

Great app performance with Firebase
Having a smoothly running, well performing app is critical to ensuring your app's success. With Firebase, this is easy to do, not only during development, but also in production. I've seen Nalin and Ali running around the hallways of the Googleplex all excited about the great things that they'll be sharing in this session. So not only will it be an exciting session, but it's done wonders for their metabolism!

And of course there's one more talk that I won't want to miss: Zero to App. Because missing your own I/O talk would be un-Googley. :-)

These are seven (well, okay, eight) Firebase sessions that I will definitely be attending. If you're not at I/O or just missed them, you can find them on the Firebase YouTube channel at the end of each day!

See you at I/O!

Five Firebase I/O Sessions I'm Excited About

2017-05-03T12:07:00.000-07:00

Todd Kerpelman
Developer Advocate

Over the last few weeks, I've had many of you approach me with questions like, "Hey Todd! I'm super excited to be going to I/O this year! What sessions should I go to?" And my answer has always been the same: "Who are you, and how did you get into my apartment?"

But yeah, I can understand that picking sessions at I/O can feel overwhelming. Between the VR awesomeness and the new Android O stuff, Google I/O has a lot to offer. And while the Firebase VR Data Viewer is still a work-in-progress, there's still plenty of great Firebase content for you to check out this year.

Of course, asking me to pick my favorites among all the sessions is like asking me to pick my favorite child -- I love all of them equally¹. But with that said, here's a few Firebase sessions that I'm certainly looking forward to next month:

Supercharging Firebase Apps with Machine Learning and Cloud Functions -- This combines two of the most intriguing (for me, anyway) technologies happening in cloud-land. First, you've got Cloud Functions for Firebase, which essentially allows you to run server-side code based on events happening within your app, and then there's Machine Learning, which is still basically, "We're living in the future" kind of wizardry as far as I'm concerned. Combine them together, and you can pull off some really cool features to enhance your mobile app. Or, in this case, a giant crowdsourced game.

Firebase Analytics: Overview and Updates -- Apparently, launching StreamView wasn't enough for the Analytics team. They've got a whole bunch of other new features popping up, including what might be the most commonly-requested feature since they launched last year. (No, it's not changing all the fonts to Papyrus. That's just my most-requested feature.) What is it? You'll just have to swing by the session to find out.

Zero to App: Develop with Firebase -- This is one of our most popular sessions from last year, and it's been brought back for 2017! We're gonna bring up four Firebase engineers for a realtime cross-platform app development deathmatch! But… uhhh... without the "death" part. HR wouldn't allow it. I've been told this year, there will be some Cloud Functions involved and possibly some other new twists and turns to keep things interesting. Will they end up with a real app by the end of the session? Or will Mike be unable to compile his code because he forgot a semicolon? Only time will tell!

AdMob and Firebase Analytics: Better Together -- Remember those Reese's commercials from the 80's, when people apparently walked around with open jars of peanut butter all the time? Well, this talk is a little like that, but instead of resulting in a delicious candy, you end up with some solid ad-driven analytics-backed monetization strategies for your app. Which you can then use to go and buy your own peanut-butter cups.

Shipping Santa Tracker: Carefully Rolling Out a Feature to a Million Users -- What happens when you've essentially got one day to launch an app to millions of people around the world with a whole slew of features that you've never really tested before in front of a large audience? You would think "mass chaos and hysteria", but in Santa Tracker land, things were as smooth a baby elf's bottom. Come by and listen to Sam and Dan tell you how they were able to pull it off. I know it's an early session, but they promised me there'd be costumes. So that might be worth rolling out of bed for.

So there ya go! Five Firebase sessions you should definitely keep an eye on. Not able to make it to I/O in person? Don't worry! All of our presentations will be available either in the livestream that day, or in the Firebase YouTube channel a few days later.

Well, except you, Janice. Are you really going to use emacs over vim? You're breaking your mother's heart.

Understanding Attribution in Firebase Analytics

2017-04-27T14:53:00.001-07:00

Todd Kerpelman
Developer Advocate

Pop quiz, hot-shot! Let's say you've spent some money on two different ad campaigns to bring users into your app. After a few weeks, you discover:

Ad campaign #1 resulted in 500 clicks.
Ad campaign #2 resulted in 300 clicks.

So, which ad campaign performed better? Seems like a no-brainer, right? Should you double-down on ad campaign #1?

Well, hang on. What if you were to then discover...

Ad campaign #1 resulted in 500 clicks
- But only 80 users installed and opened your app
- ...and they spent an average of $1.20 each
Ad campaign #2 resulted in 300 clicks...

But 230 of those users installed and opened your app
...and they spent an average of $6 each
...and over 100 of them signed up for your newsletter?

Well, suddenly, that second ad campaign seems like a much better deal, doesn't it?

That's the idea behind attribution. It's a powerful form of app analytics that not only determines which campaigns are bringing you users, but also which campaigns are bringing you valuable users that you care most about.

While attribution is a complex topic that can be studied for many months by people with marketing degrees, let's give you a brief overview of how it works and what it can mean for your business.

Typically, when an app requests any kind of banner ad or video ad, the network that delivers this ad makes a note of the user's ID For Advertisers (on iOS devices), also known as the IDFA, or your Advertising ID (on Android devices). These are unique device IDs that serve as a way for an in-app advertiser to remember information about the individual user, while doing so in a way that respects the user's privacy. They're not tied to any personally identifiable information, and users have the ability to hide or reset these identifiers if they'd like.

If a user clicks on that advertisement, the network that was serving the ad makes a note on its servers that the user (as identified by this IDFA / Advertising ID) has clicked on it.

Then it sends your user to the appropriate app store so that they can check out your app. Assuming all goes well from here, this user will then install your app from the App Store or Play Store, and open it. Hooray!

Now, let's say you want to use Firebase Analytics to help track how successful this particular ad campaign is in bringing you valuable users. The way this would work is, on the Firebase Analytics "Attribution" panel, you select what ad networks you're working with -- right now there are about 50 networks that we partner with, and we're adding more every month.

By filling in some details about your ad campaign, you get back a Campaign URL, which you can then send on to the original advertiser.

The information shared about the ad network is generally broken up into three parts -- the source, the medium, and the campaign. Different networks like to record this information in slightly different ways, but you can think of them as generally hierarchical categories.

The source is typically the ad network itself. (Vungle, AdWords, etc.)
The medium generally records the type of ad that was shown. (In game banner, full-screen interstitial video, etc.)
The campaign usually identifies the specific ad campaign that was being run. (Elevator fight, Swimsuit model on a horse, etc.)

With this new URL, the advertising network can let Firebase know that the user clicked on one of their ads before redirecting them to the App / Play Store.

From that point on, when a user performs important events in the app that you have designated as Conversion Events -- things like opening the app for the first time, making a purchase, or sharing the app with their friends -- Firebase Analytics will also note what ad campaign was responsible for bringing you this user.

You'll then be able to filter those events within Firebase Analytics by any of these ad campaign parameters. For instance, you can see what ad network is responsible for giving you the most overall users, by looking at the attribution reports for your first_open event.

You can also see what particular ad campaign is responsible for giving you the most money in an in_app_purchase event, or which ad network gives you users who have clicked your "Yes, I'll review your app!" button. Whatever you can track in a Firebase Analytics event, you can designate as a conversion event.

Postbacks

In addition to receiving attribution information from these ad networks, Firebase Analytics can report back information to these ad networks, in a concept known to most marketing professionals as "completing the circle of life". Actually, nobody calls it that; I just made it up. (But it sounds good, right?) You can ask Firebase to tell these ad networks that a user has completed an important conversion event within your app, which is done via a call known as a Postback.

For instance, if your app were to report back to an ad network that a particular user (as identified by their IDFA / Advertising ID) has gone ahead and opened your app for the first time, that ad network could take advantage of this information to improve its own offerings in a couple of ways. For starters, it now knows that this user has installed your app, so it can stop showing them ads for an app they've already installed. It might also use this information to determine what kinds of apps this user might enjoy in the future.

Setting up a postback in Firebase Analytics is fairly easy. You'll use the Firebase console to determine which conversion events you want to post back to the network, and usually add a little information specific to that advertising network.

You'll also have the option of posting all of your conversion events back to this network, or just the ones that came from this original network. Posting back all conversion events means you'll be doing a better job of training all of your ad networks, and Firebase takes some time to anonymize the other ad networks involved before sending it over. So an ad network might find out that a particular user completed a conversion event in your app, but it won't know which competing ad network was responsible for it.

What about Dynamic Links?

So you might have noticed that when you use Firebase Dynamic Links, there's also a space for you to set up tracking parameters with a source, medium, and campaign name. Gosh, sounds awfully familiar, right?

Well, in the same way you can measure the effectiveness of ad campaigns with Firebase Analytics, you can also measure the effectiveness of Firebase Dynamic Links. By adding these tracking parameters to your Dynamic Links, Firebase Analytics can treat them like any other campaign it's measuring attribution reporting for, and you can view conversion events not just by the ad campaigns responsible for bringing in those users, but also by which Dynamic Links might have brought them in.

It's worth noting, however, that Firebase Dynamic Links works best when used in non-marketing contexts -- actions like user-to-user sharing, directing users to your app from your website, or linking to your app in social media posts. If you want to measure the effectiveness of an advertising campaign, you should stick with the traditional methods that these ad networks have already set up and use the Campaign URLs that Firebase provides for you.

Give it a try!

So that's the general overview of attribution information in Firebase Analytics. If you haven't yet tried it within your app, I encourage you to give it a try. You might learn something surprising about those ad networks you've been spending your money on.

Brand new course from Udacity and Google

2017-04-12T13:59:00.001-07:00

Jen Person
Course Developer

What separates apps that are good ideas from apps that are really great? Analytics! Successful app developers rely on analytics to determine how users are really interacting with their app. Analytics are at the core of Firebase, helping you make actionable decisions to build products that people love.

We partnered with Udacity to offer a free 2-day interactive course that will help you learn how to use Firebase Analytics to grow your userbase on iOS and Android. Specifically, you'll see how to set goals and how to log users' interactions with an app. You'll even analyze real data from an app that's live in the Google Play Store and in the App Store! And you'll learn from people who live and breathe Firebase: experts Steve Ganem and Todd Kerpelman from Google, as well as Android and iOS developers from Google and Udacity.

The new course will include a combination of short videos, quizzes, code snippets, and a robust online community to help you learn. Check out the course on Android or iOS for free, and see all of our courses at udacity.com/google.

Increasing the Realtime Database concurrency limits

2017-04-07T11:01:00.000-07:00

Tony Meng
Software Engineer

Alex Dufetel
Product Manager

We have some exciting news for Realtime Database developers on the Flame and Blaze plans: we're increasing your concurrent connections limit from 10,000 to 100,000!

Concurrent connections are the number of users simultaneously connected to your database. For context, it's useful to keep in mind that this number is generally one to three full orders of magnitude lower than your daily active users. To reach 100,000 concurrent users, you usually first need to accumulate tens of millions of daily actives.

Historically, we limited the concurrent connections to 10,000 per database. We requested that you reach out to us to raise this limit, which allowed us to do a quick verification of your app's health. We looked for things like unindexed queries or very heavy reads to make sure your app was ready to scale.

Recent improvements to our infrastructure have made it possible to increase that threshold to 100,000 concurrent connections (but you should still index your queries and never add listeners to the root path!). If you need to support even more concurrent connections, please contact us.

We're excited to bring this change to the Firebase Realtime Database. We've been working hard on improving scalability, and we hope this increase will make scaling more seamless for you. As usual, let us know if you have any questions or feedback. We're always excited to hear from you!

Easier configuration for Firebase on the web

2017-04-06T09:19:00.000-07:00

Michael Bleigh
Engineer, Firebase Hosting

Mature applications separate configuration from code. Doing so lets you easily switch between staging and production, deploy an open-source code sample, or spin up a new QA environment (see also "store config in the environment" from the 12 Factor App pattern).

Historically, this has been difficult for Firebase projects on the web, because you needed to keep track of the configuration options for firebase.initializeApp(). You might have had to write code that looked like this:

// DON'T DO THIS ANYMORE!
switch (location.hostname) {
  case 'myapp.com': firebase.initializeApp(prodConfig); break;
  case 'myapp-staging.com': firebase.initializeApp(stagingConfig); break;
  default: firebase.initializeApp(devConfig); break;
}

Not the best experience, plus it exposes your various staging environments in public-facing code. Today we're excited to announce some new features of Firebase Hosting and the Firebase CLI that makes configuring Firebase on your Web app and working with multiple environments much simpler.

On-Demand Firebase SDK Auto-configuration

We've introduced some new reserved URLs to Firebase Hosting that will let you load the Firebase SDK and automatically configure it for the current environment without having to write any custom code. All you have to do is include the right script tags:

  
<!doctype html>
<html>
  <body>

    ...

    <!-- Import and initialize the Firebase SDK -->
    <script src="/__/firebase/3.7.4/firebase-app.js"></script>
    <script src="/__/firebase/3.7.4/firebase-auth.js"></script>
    <script src="/__/firebase/init.js"></script>
    <script>
      // The Firebase SDK is ready to rock!
      firebase.auth().onAuthStateChange(function(user) { /* … */ });
    </script>
  </body>
</html>

This works on sites deployed to Firebase Hosting, and also works locally when using firebase serve! The new URLs available are:

/__/firebase/{VERSION}/firebase-{app,auth,database,messaging,storage}.js- modular SDK files (recommended)
/__/firebase/{VERSION}/firebase.js - the complete Firebase JS SDK
/__/firebase/init.js - script that auto-initializes the SDK when included. Must be loaded after any Firebase SDKs.
/__/firebase/init.json - JSON representation of the configuration for firebase.initializeApp(). You can use this to fetch config and initialize Firebase SDKs asynchronously.

When serving locally, init.js initializes the currently selected project for your project directory (see "Using Project Aliases" for more information). When deployed, it initializes for the deployed project. In addition, when deployed, the scripts are served over HTTP/2 and you can enjoy the benefits of loading the SDK from the same origin without having to manage your own dependencies.

Note: You will need at least version 3.6.0 of the Firebase CLI to use these features, and may need to reauthenticate. If you see a warning message when running firebase deploy, run firebase login --reauth to enable init.js.

Integrating into Existing Toolchains

What if you're not on Firebase Hosting or already bundle or otherwise build your JavaScript? You may want to have other ways to get the configuration for a given project. We've added the new firebase setup:web command to version 3.6.0 of the Firebase CLI. This can serve as a handy reference for copy and paste. The command prints out config information, but can also be integrated with your existing Node.js build process by using the Firebase CLI as a module.
To do so, first install firebase-tools as a dependency:

$ npm install --save firebase-tools@^3.6

Next, require it and call the command. For example:

const fbcli = require('firebase-tools');
const fs = require('fs');

// by default, uses the current project and logged in user
fbcli.setup.web().then(config => {
  fs.writeFileSync(
    'build/initFirebase.js',
    `firebase.initializeApp(${JSON.stringify(config)});`
  );
});

// alternatively, you can pass project or token information
fbcli.setup.web({
  project: 'my-custom-project',
  token: process.env.FIREBASE_TOKEN
});

We think these updates will make it much simpler to build mature, multi-environment web applications on Firebase, and we're excited to see the creative ways you use them. Let us know what you think!

Bringing Firebase Admin To Python

2017-04-05T09:00:00.000-07:00

Hiranya Jayathilaka
Software Engineer

After announcing the Firebase Admin SDKs for Node.js and Java at the Firebase Dev Summit in Berlin last year, we received many feature requests to bring the platform to Python developers as well. Now, we're pleased to announce that first release of the Firebase Admin Python SDK, focusing on Firebase Auth token minting and verification.

What are the Admin SDKs?

The Firebase Admin SDKs provide developers with programmatic, second-party auth access to Firebase services from trusted 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.

What is available in the Admin Python SDK?

As with the other Firebase Admin SDKs, the Python SDK can be initialized using a variety of built-in credential types. The following code shows how to authenticate the SDK using your own service account key file:

import firebase_admin
from firebase_admin import credentials

cred = credentials.Certificate("path/to/service.json")
firebase_admin.initialize_app(cred)

If you are running your code on Google infrastructure, such as Google App Engine or Google Compute Engine, the SDK can auto-discover the credential, allowing you to initialize the SDK with no arguments:

firebase_admin.initialize_app()

The Python Admin SDK contains Firebase Auth custom token minting and ID token verification. The custom token minting gives you complete control over authentication by allowing you to authenticate users or devices using your own authentication system.

uid = "some-uid"
additional_claims = {
  "premiumAccount": True
}

custom_token = auth.create_custom_token(uid, additional_claims)

ID token verification allows you to securely identify the currently signed-in user on your server.

decoded_token = auth.verify_id_token(id_token)
uid = decoded_token["uid"]

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.

What is coming next?

We plan to continue to build out the Admin Python SDK to include features already available in the other Admin SDKs, such as a user management API and an FCM API to send messages. We also plan to bring these token minting and verification features to even more languages. To see what APIs are available in each of the Admin SDKs, see our new feature matrix.

To all those Python developers out there, happy hacking!

Using Firebase Cloud Messaging with Android O

2017-03-29T14:00:00.000-07:00

Diego Giorgini
Software Engineer

Firebase Cloud Messaging (FCM) is a cross-platform messaging solution that lets you reliably deliver messages to your apps and sites. It provides two types of messages:

Notification Messages display a simple notification popup, with optional data payload.
Data Messages deliver a JSON payload to your application and let your code handle it.

Data Messages are a great way to build custom notifications, when the layout provided by notification messages is not enough, or to trigger background operations like a database sync or the download of additional content (image attachments, emails, etc.)

How should Data Messages trigger background operations?

The best way to trigger a background operation from a data message is by using Firebase Job Dispatcher to take advantage of the Android JobScheduler and Google Play services API.

By using Firebase Job Dispatcher you allow the operating system to schedule your operation when it's best for the user (like avoiding extra work when the battery is very low, or when the CPU is already heavily used by other foreground applications). Firebase Job Dispatcher also guarantees that your background task will be performed, and not killed by the system when foreground applications require more resources.

Background Process Optimizations in Android O

To get started, check out the Android O Developer Preview site where you will find instructions on downloading and installing the required SDKs. For Firebase Development, you'll also need to install the Firebase SDKs for Android. Be sure to use version 10.2.1 or later for Android O development.

Android O introduces new background processes optimizations, which make the use of JobScheduler (or wrapper libraries like Firebase Job Dispatcher) a requirement for long-running background operations. Due to these optimizations, the FCM (hence GCM as well) callbacks onMessageReceived()and onTokenRefresh() have a guaranteed life cycle limited to 10 seconds (same as a Broadcast Receiver).

After the guaranteed period of 10 seconds, Android considers your process eligible for termination, even if your code is still executing inside the callback.

To avoid your process being terminated before your callback is completed, be sure to perform only quick operations (like updating a local database, or displaying a custom notification) inside the callback, and use JobScheduler to schedule longer background processes (like downloading additional images or syncing the database with a remote source).

@Override
public void onMessageReceived(RemoteMessage remoteMessage) {
  if (/* Check if data needs to be processed by long running job */ true) {
    // For long-running tasks (10 seconds or more) use Firebase Job Dispatcher.
    scheduleJob();
  } else {
    // Handle message within 10 seconds
    handleNow();
  }
}
/**
 * Schedule a job using FirebaseJobDispatcher.
 */
private void scheduleJob() {
  FirebaseJobDispatcher dispatcher =
      new FirebaseJobDispatcher(new GooglePlayDriver(this));
  Job myJob = dispatcher.newJobBuilder()
      .setService(MyJobService.class)
      .setTag("my-job-tag")
      .build();
  dispatcher.mustSchedule(myJob);
}
/**
 * Perform and immediate, but quick, processing of the message.
 */
private void handleNow() {
   Log.d(TAG, "Short lived task is done.");
}

We hope this helps you understand how to use FCM to schedule long-running background operations. This solution greatly helps Android to preserve battery life and ensures that your application works fine on Android O. In case you have any questions don't hesitate to ask us on our support channels.

How to Schedule (Cron) Jobs with Cloud Functions for Firebase

2017-03-24T12:10:00.000-07:00

Abe Haskins
Developer Programs Engineer

Cloud Functions are a great solution for running backend code for your Firebase app. You can write a function which is triggered by many different actions like user sign-ups, writes to the Realtime Database, changes to a Cloud Storage bucket, or conversion events in Firebase Analytics. Cloud Functions can also be triggered by some external sources, for example you could tie a Cloud Function to an HTTPS endpoint or a Cloud Pub/Sub topic.

Reacting to these events is very powerful, but you may not always want to react to an event - sometimes you may want to run a function based on a time interval. For example, you could clean up extra data in your Realtime Database every night, or run analysis on your Analytics data every hour. If you have a task like this, you'll want to use App Engine Cron with Cloud Functions for Firebase to reliably trigger a function at a regular interval.

How to Schedule Functions

Cloud Functions for Firebase does not have any special support which allow us to utilize App Engine Cron to schedule events. In fact, the solution we'll implement is nearly identical to the solution we recommend for doing reliable task scheduling on Google Compute Engine.

The trick is to create a tiny App Engine shim that provides hooks for App Engine Cron. These hooks will then push to Cloud Pub/Sub topics for each scheduled job.

We will then configure our Cloud Function to handle incoming messages on that Pub/Sub topic.
Although this solution is the preferred option for scheduling functions, it isn't the only way you achieve this goal. If you're interested in seeing an alternative method, you should check out the functions-samplesrepository which explains how to achieve a similar result using an external scheduling service.

Deploying the App Engine App

It just so happens that we've already written the App Engine app you'll need to set up scheduled functions. It's available in the firebase/functions-cronrepo on Github.

By default this sample triggers hourly, daily, and weekly Cloud Pub/Sub ticks. If you want to customize this schedule for your app then you can modify the cron.yaml.

For details on configuring this, please see the cron.yaml Reference in the App Engine documentation.

Let's get started!

1. Prerequisites

Install (or check that you have previously installed) the following tools.

2. Clone this repository

To clone the GitHub repository to your computer, run the following command:

git clone https://github.com/firebase/functions-cron

Change directories to the functions-cron directory. The exact path depends on where you placed the directory when you cloned the sample files from GitHub.

cd functions-cron

3. Deploy to App Engine

Configure the gcloud command-line tool to use your Firebase project.

gcloud config set project

Change directory to appengine/

cd appengine/

Install the Python dependencies

gcloud app deploy app.yaml \ cron.yaml

Open Google Cloud Logging and in the right dropdown select "GAE Application". If you don't see this option, it may mean that App Engine is still in the process of deploying.

Look for a log entry calling /_ah/start. If this entry isn't an error, then you're done deploying the App Engine app.

4. Deploy to Google Cloud Functions for Firebase

Ensure you're back the root of the repository (cd .. if you're coming from Step 2)

5. Verify your Cron Jobs

We can verify that our function is wired up correctly by opening the Task Queue tab in App Engine and clicking on Cron Jobs. Each of these jobs has a Run Now button next to it.

The sample functions we deployed only has one function: hourly_job. To trigger this job, let's hit the Run Now button for the /publish/hourly-tick job.

Then, go to your terminal and run...

firebase functions:log --project

You should see a successful console.log from your hourly_job.

You're Done!

Your cron jobs will now "tick" along forever. As we mentioned above, you're not limited to the hourly-tick, daily-tick and weekly-tick that are included in the App Engine app.

You can add more scheduled functions by modifying the cron.yamlfile and re-deploying the app.

BigQuery Tip: The UNNEST Function

2017-03-22T14:00:00.000-07:00

Todd Kerpelman
Developer Advocate

By now, you probably already know that you can export your Firebase Analytics data to BigQuery, which lets you run all sorts of sophisticated ad hoc queries against your analytics data.

At first, the data set in BigQuery might seem confusing to work with. If you've worked with any of our public BigQuery data sets in the past (like the Hacker News post data, or the recent San Francisco public data that our Developer Advocate Reto Meier had fun with), it probably looked a lot like a big ol' SQL table. Something like this:

The truth of the matter is that BigQuery can get much more sophisticated than that. The rows of a BigQuery table don't just have to be straightforward key-value pairs. They can look more like rows of JSON objects, containing some simple data (like strings, integers, and floats), but also more complex data like arrays, structs, or even arrays of structs. Something a little more like this:

Firebase Analytics takes advantage of this format to bundle all of your users' user properties together in the same row. Rather than have you perform some kind of join against a separate user_properties table, all of your user properties are included in the same BigQuery row as an array of structs.

A slightly simplified version of the user_properties struct in your BigQuery data

The same thing holds true for your events. Your event parameters are included inside your events as an array of structs. And it turns out these events themselves are stored inside of an array. One single row of data in BigQuery will often contain 2 or 3 Firebase Analytics events all bundled together.

This means a single row in your BigQuery table can contain an array of user properties, as well as an array of events, which in turn also have their own arrays of event parameters. I know combining all of that information into a data structure like this seems confusing at first, but in the long run, it actually makes your life easier because there aren't any JOINs with other tables for you to worry about.

Important note: For all of these examples, I'm going to be using standard SQL, which is what all the cool kids are doing this days¹. If you want to follow along, turn off Legacy SQL in your BigQuery options. Also, you'll need to follow this link to access the sample Firebase Analytics data we'll be using.

For example, I can see all of my event data at once just by calling

#standardSQL
SELECT event_dim 
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607` 
LIMIT 50

and I'll get back all of my event data, along with all of the event parameters, in one nice little table

And then if we want to get a list of all of my "Round completed" events, I can just write some SQL like this…

#standardSQL
SELECT event_dim 
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607` 
WHERE event_dim.name = "round_completed"

...which gives me a nice result of...

Error: Cannot access field name on a value with type ARRAY<STRUCT<date STRING, name STRING, params ARRAY<STRUCT<key STRING, value STRUCT<string_value STRING, int_value INT64, float_value FLOAT64, ...>>>, ...>> at [2:17]

Oh. Oh dear.

Okay, so this won't win any awards for "Best Error Message of 2017"² , but if you think about it, the reason it's barfing makes sense. You're trying to compare a string value to "an element of a struct that's buried inside of an array". Sure, that element ends up being a string, but they're fairly different objects.

So to fix this, you can use the UNNEST function. The UNNEST function will take an array and break it out into each of its individual elements. Let's start with a simple example.

Calling:

#standardSQL
WITH data AS (
  SELECT "primes under 15" AS description,
  [1,2,3,5,7,11,13] AS primes_array)
SELECT * 
FROM data

will give you back a single row consisting of a string, and that array of data.

Instead, try something like this:

#standardSQL
WITH data AS (
  SELECT "primes under 15" AS description,
  [1,2,3,5,7,11,13] AS primes_array)
SELECT description, prime 
FROM data CROSS JOIN UNNEST (primes_array) as prime

What you're basically saying is, "Hey, BigQuery, please break up that primes_array into its individual members. Then join each of these members with a clone of the original row." So you end up with a data structure that looks more like this:

The results are similar as before, but now each prime is in its own row:

You'll notice that the original primes_array is still included in the data structure. In some cases (as you'll see below), this can be useful. In this particular case, I found it was a little confusing, which is why I only asked for the individual fields of description and prime instead of SELECT *.³

It's also common convention to replace that CROSS JOIN syntax with a comma, so you get a query that looks like this.

#standardSQL
WITH data AS (
  SELECT "primes under 15" AS description,
  [1,2,3,5,7,11,13] AS primes_array)
SELECT description, prime 
FROM data, UNNEST (primes_array) as prime

It's the exact same query as the previous one; it's just a little more readable. Plus, I can now stand by my original statement that this data format means you don't have perform any JOINs. :)

And the nice thing here is that I now have one piece of "prime" data per column that I can interact with. So I can start to do comparisons like this:

#standardSQL
WITH data AS (
  SELECT "primes under 15" AS description,
  [1,2,3,5,7,11,13] AS primes_array)
SELECT description, prime 
FROM data, UNNEST (primes_array) as prime
WHERE prime > 8

To get just that list of prime numbers between 8 and 15.

So going back to our Firebase Analytics data, I can now use the UNNEST function to look for events that have a specific name.

#standardSQL
SELECT event.name, event.timestamp_micros
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, 
  UNNEST(event_dim) as event
WHERE event.name = "round_completed"

As you'll recall, events have their own paramsarray, which contains all of the event parameters. If I were to UNNEST those as well, I'd be able to query for specific events that contain specific event parameter values:

#standardSQL
SELECT event, event.name, event.timestamp_micros
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, 
  UNNEST(event_dim) as event,
  UNNEST(event.params) as event_param
WHERE event.name = "round_completed"
AND event_param.key = "score"
AND event_param.value.int_value > 10000

Note that in this case, I am selecting "event" as one of the fields in my query, which gives me the original array of all my event parameters nicely grouped together in my table results.
Querying against user properties works in a similar manner. Let's say I'm curious as to what language my users prefer using for my app, something our app is tracking in a "language" user property. First, I'll use the UNNEST query to get just a list of each user and their preferred language.

#standardSQL
SELECT
 user_dim.app_info.app_instance_id as unique_id,
  MAX(user_prop.key) as keyname,
  MAX(user_prop.value.value.string_value) as keyvalue
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`,
  UNNEST(user_dim.user_properties) AS user_prop
WHERE user_prop.key = "language"
GROUP BY unique_id

And then I can use that as my inner selection to grab the total number of users⁴ that fits into that group.

#standardSQL
SELECT keyvalue, count(*) as count
FROM (
  SELECT
   user_dim.app_info.app_instance_id as unique_id,
    MAX(user_prop.key) as keyname,
    MAX(user_prop.value.value.string_value) as keyvalue
  FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`,
    UNNEST(user_dim.user_properties) AS user_prop
  WHERE user_prop.key = "language"
  GROUP BY unique_id
) 
GROUP BY keyvalue
ORDER BY count DESC

I can also UNNEST both my event parameters and my user properties if I want to create one great big query (no pun intended) where I want to look at events of a specific name where an event parameter matches a particular criteria, while also filtering by users who meet a certain criteria:

#standardSQL
SELECT user_dim, event, event.name, event.timestamp_micros
FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`,
  UNNEST(event_dim) as event,
  UNNEST(event.params) as event_param,
  UNNEST(user_dim.user_properties) as user_prop
WHERE event.name = "round_completed"
  AND event_param.key = "squares_daubed"
  AND event_param.value.int_value > 20
  AND user_prop.key = "elite_powers"
  AND (CAST(user_prop.value.value.string_value as int64)) > 1

Once you start playing around with the UNNESTfunction, you'll find that it's really powerful and it can make working with Firebase Analytics data a lot more fun. If you want to find out more, you can check out the Working with Arrays section of BigQuery's standard SQL documentation.

And don't forget, you get 1 terabyte of usage data for free every month with BigQuery, so don't be afraid to play around with it. Go crazy, you array expander, you!

1 ^↩ The BigQuery team has asked me to inform you that this is really because standard SQL is the preferred SQL dialect for querying data stored in BigQuery. But I'm pretty sure they're just saying that so they get invited to all the good parties.

2 ^↩ Yet another year the Messies have slipped from our grasp!

3 ^↩ I could have also done this by saying "SELECT * EXCEPT (primes_array)", which can be pretty convenient sometimes.

4 ^↩ Okay, technically, each "App Instance" -- a user interacting with my app from multiple devices would get counted multiple times here.

Take Control of Your Firebase Init on Android

2017-03-18T10:00:00.000-07:00

Doug Stevenson
Developer Advocate

A while back, we discussed how Firebase initializes on Android. There was a lot of great discussion around that, and it sounded like some of you experimented with the same technique for getting your own Android libraries initialized. Many of you also noted that there were a few situations when you couldn't use the normal automatic init procedure.

What if you have a customized build system?

Normally, Android apps using Firebase are built with Gradle and the Google Services Gradle Plugin. This plugin pulls your Firebase project data out of google-services.json, and adds it to your app's resources. Once the resources are added to your project, there is a component called FirebaseInitProvider that automatically picks up those values and initializes Firebase with them.
However, if you have a different build system, such as Bazel, or you're otherwise unable to use the Gradle plugin, you need to find another way to get those resources into your app. The solution could be as simple as creating your own resource XML file and adding the correct values to it. The documentation for the plugin gives the details of how to get those values out of your google-services.json file and into your resources.

What if you need to select your app's Firebase project at runtime?

It's very rare, but sometimes an app must be able to select its Firebase project at runtime. This means your app can't use the automatic init provided by the FirebaseInitProvider that's merged into your app. In that case, the solution has two tasks.

1. Disabling FirebaseInitProvider

FirebaseInitProvider is normally automatically merged into your app build by the Android build tools when doing a build with Gradle. If you're doing your own init, however, you'll to make sure it doesn't get merged at all. The way to do that is to use your own app's manifest to override that behavior. In your manifest, add an entry for FirebaseInitProvider, and make sure to use a node marker to set its tools:node attribute to the value "remove". This tells the Android build tools not to include this component in your app:

<provider
    android:name="com.google.firebase.provider.FirebaseInitProvider"
    android:authorities="${applicationId}.firebaseinitprovider"
    tools:node="remove"
    />

If you don't have the "tools" namespace added to your manifest root tag, you'll have to add that as well:

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="your.package"
    >

2. Calling FirebaseApp.initializeApp() to initialize

Because you removed FirebaseInitProvider, you'll need to perform the same init somewhere in your app (in your own ContentProvider during its onCreate, to ensure Analytics can measure your app correctly). The method you'll need to call is FirebaseApp.initializeApp(Context, FirebaseOptions). If you click through to the javadoc, you'll see a few varieties of that method. The one you want takes both a Context and FirebaseOptionsto initialize the default FirebaseApp instance. You can create a FirebaseOptions object using its Builder:

FirebaseOptions.Builder builder = new FirebaseOptions.Builder()
    .setApplicationId("1:0123456789012:android:0123456789abcdef")
    .setApiKey("your_api_key")
    .setDatabaseUrl("https://your-app.firebaseio.com")
    .setStorageBucket("your-app.appspot.com");
FirebaseApp.initializeApp(this, builder.build());

The documentation for the plugin will help you locate the correct strings for your project in your google-services.json file.

With these changes in place, you no longer need the Google services plugin and its JSON config file in your project.

Again, if you're happy with the way your Android app builds, you shouldn't need to implement any of the changes here. Otherwise, if your situation requires it, the information here should be all you need to do to take control of your Firebase init.

Profiling your Realtime Database Performance

2017-03-14T12:00:00.000-07:00

Tyler Rockwood
Software Engineer

The Firebase Realtime Database has traditionally been a black box that doesn't really give you a lot of insight into its performance. We're changing that. Today, you'll be able to get insights into how your database instance is performing by using the profiler built into the Firebase CLI. You can now easily monitor your database writes and reads at the path level, collecting granular data on bandwidth usage and speed.

To start, make sure you have the latest version of the Firebase CLI installed and initialized. Start profiling using the database:profile command.

firebase database:profile

This will start streaming operations from your Realtime Database. When you press enter, the CLI aggregates the collected data into a summary table broken down into three main categories: speed, bandwidth and unindexed queries. Speed and bandwidth reports are further broken down by the operation type (write or read) and the path in your Realtime Database. If you have a location with more than 25 children (for example, if you're using .push in the SDKs), the summary table collapses those paths into a single entry and replaces the push ids with $wildcard.

Speed*

Unindexed Queries

This shows 3 things: the path, the index rule that should be added to your rules, and the number of times the location has been queried. Warnings for these queries also show up in the SDK logs.

What if this isn't enough?

You can also collect the raw operations from your server by using the --raw flag (you'll probably also want to specify an output file with --output), to get more detailed information like ip addresses and user agent strings for connected applications. See the profiler reference page for a complete list of possible operations you can collect information about and what they show.

* Speeds are reported at millisecond resolution and refers to the time it takes for the database to process an operation. However, you may see vastly different latencies depending on network conditions and numerous other factors.

** Bandwidth is an estimate based on the data payload and is not a valid measure of the billable amount. Values here could be over or under your actual billed bandwidth, and the stats sent by the profiler also count towards your bandwidth bill.

Multiplying the Power of Firebase Storage

2017-03-10T09:12:00.001-08:00

Mike McDonald
Product Manager

Since the initial release of Firebase Storage at Google I/O 2016, we've been happy to see mobile app developers make use of its scalable, secure, and robust file storage to power their apps. Hundreds of thousands of developers have created buckets, and we serve hundreds of millions of requests for photos, videos, audio, and other rich media every day.

But we're not done yet: we have a few more features lined up that will make it faster and easier to store and share your app's content.

Use multiple buckets in your projects

After our launch at I/O '16, Firebase projects were limited to a single bucket, located in the United States. With our announcement at Google Cloud Next '17, any Firebase project on the Blaze payment plan can now create buckets in any of the regions and storage classes supported by Google Cloud Storage. This enables some powerful use cases:

Logically separate different types of data (e.g. user data from developer data).
Store data in a locationcloser to users, either to optimize performance or support regulatory compliance.
Reduce cost by storing infrequently accessed data (e.g. backups) in a different storage class.

Creating new buckets in the Firebase Console is easy: just select the location and storage class and give it an easy-to-remember name!

Link existing buckets to your projects

Because every Firebase project is also a Google Cloud Platform project, you can easily use any existing Cloud Storage buckets directly with Firebase SDKs for Cloud Storage. This means your mobile and web apps can access data in your buckets without having to do an expensive data migration. This is a useful feature for existing apps looking to modernize by integrating Firebase.

Linking your existing bucket to Firebase is easier than creating a new one: just select the bucket you want to import, configure your security rules to allow access, and start using the bucket directly from your app.

At Google Cloud Next '17 we also announced Cloud Functions for Firebase, which enables developers to write code that responds to events in Cloud or Firebase features. Cloud Storage for Firebase integrates well with that, allowing you to trigger code when a file is uploaded, changed, or deleted from a storage bucket. This powerful mechanism enables developers to build new functionality on top of their project storage, such as automatically converting images, generating thumbnails, moderating images with the Google Cloud Vision API, and extracting metadata. Previously, these tasks would have required maintenance of a custom backend, but now, Cloud Functions makes it easy to automate by deploying code with a single command line.

Same feature, new name

With these new features and integrations with Cloud Storage, we're proud to announce Firebase Storage is now Cloud Storage for Firebase. We want to highlight the fact that Firebase Storage is Google Cloud Storage, and that using Firebase means that you're getting the ease of use of an SDK tailored for mobile and web developers, plus the full scale and performance of Google's infrastructure.

You can continue to use the existing Firebase SDKs for Cloud Storage on iOS, Android, JavaScript, C++, and Unity, knowing that your data is stored on the same infrastructure that powers Snapchat, Spotify, and Google Photos. And if you want to access data from Cloud Functions or your own server, you can always use the Cloud Storage server SDKs.

We think you're going to love the expanded Cloud Storage for Firebase. When you're building your next app with us, reach out on Twitter, Facebook, Slack, or our Google Group and let us know how it's going. We can't wait to see what you build!

Introducing Cloud Functions for Firebase

2017-03-09T10:26:00.000-08:00

Brendan Lim
Product Manager

Firebase started with the belief that apps could be built with mostly client code since it was, in many instances, easier and faster. However, there are still some cases where server code is needed, such as executing trusted code, authenticating to a third party API, or running battery intensive operations. In these instances, you had to stand up your own server — until now.

Today we are excited to announce the beta launch of Cloud Functions for Firebase. It lets you write small pieces of JavaScript, deploy them to Google's Cloud infrastructure, and execute them in response to events from throughout the Firebase ecosystem. This has been the most requested feature since Firebase launched. The ability to extend and connect Firebase features using Cloud Functions makes Firebase more powerful, allowing you to do even more with your app without having to think about servers.

Cloud Functions is a versatile tool for building your mobile app. Here are a just a few of the many tasks you can perform with the integrations available at launch:

Firebase Analytics integration lets you trigger a function when a specific conversion event is fired. You can create functions to automate growth and retention workflows for your mobile apps, all without ever needing to update your client code.

Send a notification with a coupon code to users who have just completed a purchase
Send a survey request to users after they upgrade their app

Firebase Authentication integration lets you trigger a function when a new user is created or deleted.

Send an email to welcome new users immediately after they sign up
Clean up user associated data from your Realtime Database when a user account is deleted

Firebase Realtime Database integration lets you trigger a function when data is created, updated, or deleted at a specific path in the database.

Send a notification using FCM when data is written to the database
Moderate and remove abusive language from data written to the database

Cloud Storage integration lets you trigger a function when an object is written, updated, or deleted within a particular storage bucket.

Resize and convert images when a new image has been uploaded to your Cloud Storage bucket
Moderate abusive images uploaded to Cloud Storage using the Cloud Vision API

HTTP endpoint integration gives your Cloud Function a URL that can be used as a webhook. These functions are triggered when a request is made to their own unique, secure URLs.

Post new GitHub commits to a Slack channel
Process in-app payments using Stripe

We'll continue to add more integrations in the future.

"We were early testers of Cloud Functions for Firebase and were excited to see how easy it was to extend the Realtime Database to export data and integrate with other services."
- Erling Mårtensson, Master Architect, Sony

Firebase SDK and tooling

Cloud Functions for Firebase provides a first-class experience for Firebase developers, built on top of Google Cloud Functions. Cloud Functions are single-purpose JavaScript functions that are executed in a secure, managed Node.js environment. The Firebase SDK for Cloud Functions gives you an API that allows you to choose an event source (such as writes to Firebase Realtime Database at a specific data location) and implement a function that triggers on every matching event. Our SDK also works with TypeScript to support code completion and help you catch syntax errors early.

The SDK works in tandem with the Firebase CLI to provide a seamless experience when deploying your functions. This tight integration allows you to deploy all of your functions using only a single command.

Pricing

Cloud Functions is available on all Firebase pricing plans, including our free tier. The free tier allows you to quickly experiment and try out integration with other Firebase products. For our Blaze plan, you only pay for what you use. Blaze customers also receive a monthly allotment of free usage for Cloud Functions.

"Thanks to Cloud Functions for Firebase, I built a company with no permanent employees but myself (so far), with no serious scaling concerns, and no major costs maintaining or upgrading the backend as the app grows. It's something of a miracle."

- Paul Budnitz, Founder/CEO, Wuu

Create and deploy your first Cloud Function today

Getting started is easy! Walk through our step-by-step codelab, which takes you through setting up your first Cloud Function. You can refer to our full documentation for all the details.

We can't wait to see what you build!

Working Closer with Google Cloud Platform

2017-03-09T10:25:00.000-08:00

James Tamplin
Product Manager

Since expanding Firebase to become Google's mobile application development platform at Google I/O last year, our amazing community of developers has created over 1 million Firebase projects.

We're thrilled so many of you use and trust us. While Firebase is a full suite of products for building and growing apps, we know that some apps need more than we offer out-of-the-box. That's why we're bringing Firebase much closer to Google Cloud Platform (GCP) to serve even the most demanding applications, whether you're a new startup or a large enterprise.

Product Integrations

Firebase already shares the same account and billing system as GCP, so you can attach Firebase services to your GCP project and vice-versa. This makes for powerful combinations, such as exporting raw event data from Firebase Analytics into BigQuery for ad-hoc analysis. Starting today, we're beginning to share products too.

First, Firebase developers have been asking for ways to extend their app's functionality without spinning up a server, and Cloud Functions for Firebaselets you do just that. Cloud Functions is our new event-driven serverless compute offering that enters public beta today. The infrastructure is shared between Cloud and Firebase, allowing you to invoke a function or access resources from throughout the Cloud/Firebase ecosystem. For more information, read the announcement on the Firebase blog and Cloud blog.

Next, we're bringing Firebase Storage closer to Cloud Storage. Firebase Storage launched 10 months ago, and lets you easily upload and download files from your device directly to Cloud Storage. Previously we gave you a single bucket for your files. Now we're fully aligning the two products and letting you use any Cloud Storage bucket, from any global region and from any storage class, all straight from the Firebase SDK. To reflect this alignment we're renaming the productCloud Storage for Firebase. Read more in our blog post.

Stay tuned for more product integrations in the future as Firebase continues to provide direct client-side access to GCP infrastructure through our iOS, Web, and Android SDKs.

Streamlined Terms of Service

We love lawyers almost as much as developers, so we're extending GCP's Terms of Service to cover several Firebase products. This makes Firebase and Cloud simpler to evaluate and use together. Products to be covered include: Authentication, Hosting, Storage, Functions, and Test Lab. Our streamlined Terms of Service will take effect soon.

The Big Picture

Firebase brings together the best of Google on mobile -- whether that's Google's flagship advertising solutions like AdMob and AdWords, or Google's analytics expertise in the form of Firebase Analytics.

Google Cloud Platform lets you to benefit from the institutional knowledge Google has developed from almost two decades of running global-scale computing infrastructure.

By bringing together the ease-of-use of Firebase with the full-range of GCP infrastructure offerings, we're better able to serve you up and down the stack. If you're a startup using Firebase to quickly get to market, you can now easily scale into a full public cloud. If you're an existing business running on GCP who wants to ship a mobile app, we've got you covered too.

We can't wait to see what you build with Firebase and Google Cloud Platform!

Updates to Firebase Notifications: Reach your users with greater focus

2017-03-01T14:04:00.000-08:00

Laurence Moroney
Developer Advocate

Firebase Notifications is a free service that enables targeted user notifications for mobile app developers. It is based on Firebase Cloud Messaging (FCM), and provides an option if you need a flexible notification platform that requires minimal effort to get started. It includes a graphical console for sending messages, so no programming is needed when picking your target segment and creating the message they’ll receive.

We’ve now expanded the way that you can target your notifications. With the first release of Firebase Notifications, we provided the facility for you to target users in a particular app, optionally filtering on Firebase Analytics Audience membership, language, or specific app version. . Today we’re releasing a new set of enhancements to the Firebase Notifications console that will allow you to select a much more granular audience to receive your notification -- and as you know, accurately targeted notifications give a far greater chance of user engagement.

First of all, the user audience filter has more granular control. Now, if you choose to filter on User Audience, you’ll see a set of tools that let you flexibly target users by their membership in multiple different audiences.

This allows you to target or exclude users who are members of a particular set of audiences. . Using a combination of several targeting criteria, as well as user-defined audiences, you have great control over which users will receive your notification.

Also new is the facility to filter your desired target segment based on user property. Firebase User Properties are attributes that allow you to define segments of your user base, beyond the typical app level properties. So, for example, if you’re building a fitness app, and you want to track how many people have met their fitness goals, you could define a user property for that, and then send notifications to them accordingly.

Now, you can target a notification by selecting a user property to compare against a desired value. So, if the user property contains a string, you can check if it contains, does not contain, is in, or is not in a range of values, or you can target users with user properties that match a Regex using RE2 syntax.

And of course if the user property contains a numeric value, there are several operators that you can use to compare it to a value -- such as equals, greater than, less than and more.

With these tools you’re equipped to more accurately target your notifications, to improve response rates while avoiding notification spam. We’re continuing to improve all of Firebase, including Firebase Notifications, and would love to hear your feedback on this or any other features.

To learn more, check out the Firebase Notifications documentation site.

Realtime Analytics For Everyone

2017-03-01T10:00:00.000-08:00

Steve Ganem

Product Manager

When it comes to analytics, the sooner you can see your data, the quicker you can react to it, and the more valuable it can be. This has been at the front of our mind since launching Firebase Analytics, and we've been working hard to get you closer to that goal.

Back in November we launched real-time conversions. This meant that your most important events were delivered immediately from end-user devices. Around the same time, we also launched real-time export to BigQuery, so that your client events could be analyzed within BigQuery as soon as they were sent to our servers.

But for those of you not using BigQuery, you'd often have to wait several hours before you could start to see any meaningful results from Firebase Analytics. And when it comes to tasks like debugging analytics within your app, or just getting a quick snapshot of how your community is reacting to your latest changes, those hours can feel realllly long.

To address those needs, we are pleased to announce that StreamView and DebugView from Firebase Analytics are being rolled out to the general public.

StreamView visualizes events as they flow into Firebase Analytics, and gives you a general sense of how your users are interacting with your app. With StreamView you can find out if a brand new feature is as well-received as you were hoping, watch the roll-out of the latest version of your app, or gauge the response to your latest re-engagement efforts - all in real-time as events are received by Firebase Analytics.

StreamView can give you a sense of where in the world people are using your app, right down to the city level…

...or what user properties are most common among your users….

You can also get an overview of what kind of events are being triggered in your app, and for any of those events, you can see a breakdown of all the custom event parameters you've been recording...

...and you can use all of these values as report filters to see where in the world certain events are occurring or certain products are popular, and you can see what user properties or events are common among users in certain countries or cities.

One unique feature available in StreamView is the User Snapshot. This will give you a live stream of the events from a random user. You can use the view to gain insight into the individual user journeys within your app.

Within the User Snapshot view you can see the set user properties, the user's device and location, and drill into the parameters of the events they're sending. You can filter the users included by their location and app version.

While you may still need to use BigQuery to get full and complete reports, or cross-reference certain sets data against others, there's a surprising amount you can learn about your app just by following the events as they happen in StreamView. The Santa Tracker team was an early customer of StreamView and they've assured me that it's (and this is a direct quote), "Pretty bad-ass."

You can can check out StreamView right away in our Demo Project!

While StreamView is a great real-time picture of your app once it's gone out to the general public, event delivery from device is still batched. This is great for users and battery optimization, but difficult when you're developing your app and need to check right away if your analytics setup is correct!

With DebugView, you can immediately see which events are being reported to Firebase Analytics. This will be activated for any device for which you've turned on Analytics Debugging, and is great for making sure you're logging the right events with the right parameters while you're building your app.

DebugView shows you events, parameters and user properties for any individual development device. It can also highlight any events that contain invalid parameters, so that you can get those fixed before you publish your app.

To get started yourself, take a look at our documentation on DebugView, or just look for these features in your own project console in the coming days and try them out!

The Firebase Blog

Serving dynamic content with Cloud Functions on Firebase Hosting

Content Moderation with Cloud Functions for Firebase

Text Moderation

Image Moderation

Introducing Firebase Performance Monitoring

Firebase Phone Auth

The Sign In Screen

Sign In Flow

What's new with Analytics?

Custom Parameter Reporting

Free Storage Tier in BigQuery

Firebase and AdMob

Automatic Screen Tracking

More Attribution Partners!

New Name, Same Great Product

Try it Today!

Open sourcing the Firebase SDKs

What's open?

Firebase iOS SDK 4.0

Firebase JavaScript SDK 4.0

Firebase Admin SDKs

What’s new from Firebase at Google I/O 2017

Integrating with Fabric

Phone authentication comes to Firebase

Introducing Firebase Performance Monitoring

More robust analytics

Firebase for all - iOS, games, and open source

Dynamic Hosting with Cloud Functions for Firebase

Firebase Alpha program and what's next

Announcing the Firebase + Fabric party at WWDC17

Seven MORE Sessions I Don't Want to Miss at Google I/O

Five Firebase I/O Sessions I'm Excited About

Understanding Attribution in Firebase Analytics

Postbacks

What about Dynamic Links?

Give it a try!

Brand new course from Udacity and Google

Increasing the Realtime Database concurrency limits

Easier configuration for Firebase on the web

On-Demand Firebase SDK Auto-configuration

Integrating into Existing Toolchains

Bringing Firebase Admin To Python

What are the Admin SDKs?

What is available in the Admin Python SDK?

What is coming next?

Using Firebase Cloud Messaging with Android O

How should Data Messages trigger background operations?

Background Process Optimizations in Android O

How to Schedule (Cron) Jobs with Cloud Functions for Firebase

How to Schedule Functions

Deploying the App Engine App

1. Prerequisites

2. Clone this repository

3. Deploy to App Engine

4. Deploy to Google Cloud Functions for Firebase

5. Verify your Cron Jobs

You're Done!

BigQuery Tip: The UNNEST Function

Take Control of Your Firebase Init on Android

What if you have a customized build system?

What if you need to select your app's Firebase project at runtime?

1. Disabling FirebaseInitProvider

2. Calling FirebaseApp.initializeApp() to initialize

Profiling your Realtime Database Performance

Multiplying the Power of Firebase Storage

Use multiple buckets in your projects

Link existing buckets to your projects

Integrate with Google Cloud Functions

Same feature, new name

Introducing Cloud Functions for Firebase

Firebase SDK and tooling

Pricing

Create and deploy your first Cloud Function today

Working Closer with Google Cloud Platform

Updates to Firebase Notifications: Reach your users with greater focus

Realtime Analytics For Everyone