One of Firebase Analytics' most powerful features is the ability for you to view and analyze your Analytics data directly in BigQuery. By linking your Firebase apps with BigQuery, all of your raw, unsampled, app data is exported into BigQuery on a daily basis. This gives you the ability to run powerful ad-hoc queries on your data, combine your Firebase Analytics data with that from other analytics libraries, or run your own custom reporting tools directly on top of your data.
And while this feature is quite popular with developers, it comes with one occasionally-frustrating limitation: You typically have to wait about 24 hours for your daily analytics data to be collected and exported into a BigQuery table. This was often inconvenient from a development-and-testing standpoint. But it also meant that app developers were a little less nimble than they could have been. After all, if your latest A/B test was causing people to abandon your app, wouldn't it be nice to find that out in 20 minutes, rather than 24 hours?
So starting this week, we're happy to announce that you will now be able to see your Firebase Analytics data in BigQuery in near real-time!
Here's how it works: If you've gone ahead and linked up BigQuery with your Firebase project, then Firebase Analytics will, by default, send all of its data to BigQuery as soon as it receives it. In addition to your usual appevents_ tables, there's now a special appevents_intraday_ table that will collect all of your incoming data for that day.
appevents_
appevents_intraday_
You're welcome to analyze and run queries against this intraday table to your heart's content. It looks just like your other BigQuery analytics tables; the only data you won't find there is lifetime value data and campaign information (the traffic_source record). At the end of the day [1], this data will be moved into its permanent appevents_ home, and the old intraday table will be automatically cleaned up for you.
intraday
traffic_source
Of course, BigQuery usage and storage charges still apply. Which does mean that you'll need to upgrade your Firebase project to the Blaze plan in order to receive these benefits. But considering that BigQuery exporting is a feature analytics customers typically had to pay quite a bit of money for in the past, I still think it's a pretty good deal.
If you're new to BigQuery, you can find out more here and start playing around with it. It's fun! Or, as fun as running fast queries against large sets of data gets, I suppose.
[1] This is determined by looking at the developer's time zone.
We know that it's important for you to make sure your apps can run on the latest and greatest technology out there. And in the world of iOS development, there's this little release on the horizon called iOS 10 that many of you are excited about supporting with your apps.
Well, we here on the Firebase team also want to make sure your apps are up and running on iOS 10 as soon as it's made available to the general public. So we're going to go over some of the changes that we've included in the latest version (3.5.1) of the Firebase Cocoapod, and let you know about upcoming changes that will affect you as we move into the exciting new world of iOS 10 development.
Dynamic Links, Invites, App Indexing
With the latest version of the Firebase library, we've added support for handling deep links on iOS 10. If your app uses a feature that relies on deep links -- specifically, Dynamic Links, Firebase Invites, and App Indexing -- go ahead and update to the latest version of the library. Rebuild your app (no code changes needed!), and these features should all work properly.
Firebase Analytics
The latest version of the Firebase SDK includes some changes to more accurately track app installs resulting from AdWords search and display ads. If this sounds familiar, it’s because this feature was also included in version 3.3.0 of Firebase, but now we've added support for this on iOS 10 as well. Like the new deep link support, this should work automatically if you rebuild your code with the new library.
Firebase Cloud Messaging
iOS 10 made a lot of exciting changes around notifications, along with new ways for you as a developer to handle incoming user notifications. Specifically, notifications are now handled by methods belonging to the UNUserNotificationCenterDelegate protocol, while the old UIApplicationDelegate methods like application:didReceiveRemoteNotification are now deprecated.
UNUserNotificationCenterDelegate
UIApplicationDelegate
application:didReceiveRemoteNotification
That said, you might notice that the most recent release of the Firebase SDK is still calling the older appDelegate methods. We hope to have support for these new UNUserNotificationCenterDelegate protocol methods soon, so do keep an eye out for any future announcements as we update our libraries.
A Quick Note About Firebase Auth and Xcode 8
We've noticed what seems to be an issue with the latest iOS 10 simulators (up to beta 6 at the time of this writing) that causes Firebase Auth to throw an error due it to not being able to write values to the keychain. This issue does not affect real devices.
We have filed a radar with Apple and are hoping to get this issue resolved shortly, but you may encounter errors when testing Firebase Auth in the simulator. As a workaround, we recommend testing Auth on a physical device running iOS 10. If you do not have access to a real device, you also can try enabling Keychain Sharing in the Capabilities section of your app, as described in this StackOverflow post.
What about Swift 3?
You might have noticed that the code samples in our documentation still reflect Swift 2.3. With all the changes that are still happening in Swift 3, we've decided to wait until version 3.0 has been officially released before switching over the code samples in our documentation.
Of course, if you're interested in trying out our samples in Swift 3, you can always download our latest sample code and let Xcode's Swift conversion tool convert the samples for you. It does a remarkably good job. And, in the next few days, we'll be creating a specific Swift 3 branch of our sample apps, so you can check out those branches from GitHub and see the source code without having to go through the conversion process.
Send us Feedback!
Obviously, releasing a library to support an operating system that's still in beta is a tricky proposition. Issues may still arise here and there as new versions of iOS 10 are made available, and if they do, we'll try to address them as quickly as we can. So if you encounter an error that seems to be specific to iOS 10, please let us know! Our Google Group is a good place to start.
sendNotificationToUser("puf", "Hi there puf!");
public static void sendNotificationToUser(String user, final String message) { Firebase ref = new Firebase(FIREBASE_URL); final Firebase notifications = ref.child("notificationRequests"); Map notification = new HashMap<>(); notification.put("username", user); notification.put("message", message); notifications.push().setValue(notification); }
notificationRequests $pushid message: "Hello there" username: "puf"
var firebase = require('firebase-admin'); var request = require('request'); var API_KEY = "..."; // Your Firebase Cloud Messaging Server API key // Fetch the service account key JSON file contents var serviceAccount = require("path/to/serviceAccountKey.json"); // Initialize the app with a service account, granting admin privileges firebase.initializeApp({ credential: firebase.credential.cert(serviceAccount), databaseURL: "https://<your database>.firebaseio.com/" }); ref = firebase.database().ref(); function listenForNotificationRequests() { var requests = ref.child('notificationRequests'); requests.on('child_added', function(requestSnapshot) { var request = requestSnapshot.val(); sendNotificationToUser( request.username, request.message, function() { requestSnapshot.ref.remove(); } ); }, function(error) { console.error(error); }); }; function sendNotificationToUser(username, message, onSuccess) { request({ url: 'https://fcm.googleapis.com/fcm/send', method: 'POST', headers: { 'Content-Type' :' application/json', 'Authorization': 'key='+API_KEY }, body: JSON.stringify({ notification: { title: message }, to : '/topics/user_'+username }) }, function(error, response, body) { if (error) { console.error(error); } else if (response.statusCode >= 400) { console.error('HTTP Error: '+response.statusCode+' - '+response.statusMessage); } else { onSuccess(); } }); } // start listening listenForNotificationRequests();
String username = "puf"; FirebaseMessaging.getInstance().subscribeToTopic("user_"+username);
The transformation of Firebase into a unified mobile platform brought with it new Gradle artifacts and CocoaPods that mobile developers can use to import the Mobile Ads SDK. With these additions, there are now several alternatives for each platform. Thanks to your feedback, we wanted to share a little more information about which ones we recommend and what libraries they include, so here's a quick run-down.
This is the best way to get the Mobile Ads SDK into your project. With the firebase-ads artifact, you get everything you need to load and display ads from AdMob, DFP, or AdX, plus Firebase Analytics built in. You'll also be ready to add the client components for any other Firebase services you want to use, like firebase-crash or firebase-config. Unless you have a specific need to use the SDK without Firebase, this is your jam.
firebase-ads
firebase-crash
firebase-config
If you'd like to see a screencast of how to get up and running with AdMob using firebase-ads, check out this episode of the Firecasts series:
For those not using Firebase, this Gradle artifact contains the Mobile Ads SDK on its own. You'll get the client code for AdMob, DFP, and AdX, but no Firebase services.
This is the full Google Play services client, also without Firebase. This gives you not only the Mobile Ads SDK, but all the other Google Play services SDKs as well: Maps, Drive, Fit, and so on. Since you're probably not using every API that Play services offers, it's better to import them individually. If you need mobile ads and Play games, for example, just include play-services-ads and play-services-games.
play-services-ads
play-services-games
The SDK team developed this new Gradle artifact for a very specific use-case. It contains a slimmed-down version of the Mobile Ads SDK designed to work only on devices that have Google Play services installed. If reducing app size is extremely important for you, this can help lessen the impact of the Mobile Ads SDK, but it won't be able to load and display ads on devices that don't have Play services. Make sure you're intimately familiar with your app's install base before considering this tradeoff, and see the Lite SDK guide for more details.
This is the Firebase CocoaPod for AdMob and the Mobile Ads SDK. While it's labelled as "AdMob," this pod gives you the iOS client code for DFP and AdX as well. You'll get everything you need to load and display ads from all three sources, plus Firebase Analytics built in. This CocoaPod is also easy to combine with any other Firebase pods your app needs, like Firebase/Crash and Firebase/Database. For most developers, this is the one you want.
Firebase/Crash
Firebase/Database
The Firecasts series has an episode that shows how to import AdMob and Firebase into an app using Firebase/AdMob, so check that out for a detailed screencast:
Firebase/AdMob
For developers not yet using Firebase, this pod contains just Mobile Ads SDK. You get everything necessary to show ads from AdMob, DFP, and AdX, but no Firebase services.
This is an older, alternate CocoaPod for the Mobile Ads SDK that should no longer be used. Google-Mobile-Ads-SDK is the better choice if you aren't using Firebase.
Google-Mobile-Ads-SDK
If you've got questions about Firebase and the best ways to get started, the Firebase support page also has a bunch of options that can help. If you've got technical questions about the Mobile Ads SDK itself, you're welcome to stop by the SDK support forum.
Deploying to production is always a little nerve-wracking. What happens if the new version of the site has bugs you didn’t catch? One-click rollbacks in Firebase Hosting allow you to safely go back the last working version, but how can we ensure that the problem doesn’t happen in the first place?
The answer is simple. Test your site in a mirrored production environment. Fortunately for us, the Firebase CLI makes it simple to setup and deploy to multiple environments.
Adding and switching between environments with the Firebase CLI is as simple as one command: firebase use.
firebase use
When you first initialize your Firebase Hosting project with firebase init you specify what project you want to deploy your app to. This is your default project. The use command allows you to add another project.
firebase init
use
$ firebase use --add
This command prompts you to choose from one of your existing projects:
$ firebase use --add $ ? Which project do you want to add? (Use arrow keys) my-production-project > my-staging-project my-dev-project
Select the project you want to use for a different environment, and then give it an alias. The alias can really be whatever you want, but it’s common to use aliases like “development”, “staging”, or “production”.
$ firebase use --add $ ? Which project do you want to add? (Use arrow keys) my-production-project > my-staging-project my-dev-project ? What alias do you want to use for this project? (e.g. staging) staging Created alias staging my-staging-project. Now using alias staging (my-staging-project)
Once you’ve created a new alias, it will be set as the current environment for deployment. Running firebase deploy will deploy your app to that environment.
If you want to switch to another environment, just provide the alias in the use command.
$ firebase use default # sets environment to the default alias $ firebase use staging # sets environment to the staging alias
-P
$ firebase deploy -P staging # deploy to staging alias
That’s all there is to switching environments with Firebase Hosting. If you want a guided tour on getting setup, then check out our screencast. Let us know what you think in the comments!
