We launched the Google URL Shortener back in 2009 as a way to help people more easily share links and measure traffic online. Since then, many popular URL shortening services have emerged and the ways people find content on the Internet have also changed dramatically, from primarily desktop webpages to apps, mobile devices, home assistants, and more.
To refocus our efforts, we're turning down support for goo.gl over the coming weeks and replacing it with Firebase Dynamic Links (FDL). FDLs are smart URLs that allow you to send existing and potential users to any location within an iOS, Android or web app. We're excited to grow and improve the product going forward. While most features of goo.gl will eventually sunset, all existing links will continue to redirect to the intended destination.
Starting April 13, 2018, anonymous users and users who have never created short links before today will not be able to create new short links via the goo.gl console. If you are looking to create new short links, we recommend you use Firebase Dynamic Links or check out popular services like Bitly and Ow.ly as an alternative.
If you have existing goo.gl short links, you can continue to use all features of goo.gl console for a period of one year, until March 30, 2019, when we will discontinue the console. You can manage all your short links and their analytics through the goo.gl console during this period.
After March 30, 2019, all links will continue to redirect to the intended destination. Your existing short links will not be migrated to the Firebase console, however, you will be able to export your link information from the goo.gl console.
Starting May 30, 2018, only projects that have accessed URL Shortener APIs before today can create short links. To create new short links, we recommend FDL APIs. FDL short links will automatically detect the user's platform and send the user to either the web or your app, as appropriate.
If you are already calling URL Shortener APIs to manage goo.gl short links, you can continue to use them for a period of one year, until March 30, 2019, when we will discontinue the APIs.
As it is for consumers, all links will continue to redirect to the intended destination after March 30, 2019. However, existing short links will not be migrated to the Firebase console/API.
URL Shortener has been a great tool that we're proud to have built. As we look towards the future, we're excited about the possibilities of Firebase Dynamic Links, particularly when it comes to dynamic platform detection and links that survive the app installation process. We hope you are too!
All too often I become frustrated when building an authentication component. The asynchronous flow is hard to manage and it makes my template a mess of ngIfs and Elvis operators:
{{ (user | async)?.uid }}
The problem is always same. I'm mixing too many concerns in one place. Organizing the right code in the right place is what makes a happy codebase.
The solution: Store route specific code in Angular's Route Guards.
The AngularFireAuth service is a great match for routing code. It contains information about a current user, whether they are coming from a redirect, and all sorts of other things.
AngularFireAuth
Take a simple signInWithRedirect example:
signInWithRedirect
import { Component, OnInit } from '@angular/core'; import { AngularFireAuth } from 'angularfire2/auth'; import { Router } from '@angular/router'; import * as firebase from 'firebase/app'; @Component({ selector: 'app-login', template: ` <button class="btn" (click)="auth()"> Login </button> `, styleUrls: ['./login.scss'] }) export class LoginComponent implements OnInit { constructor( private afAuth: AngularFireAuth, private router: Router ) { } ngOnInit() { this.afAuth.getRedirectResult().then(result => { if(result) { this.router.navigateByUrl('profile'); } }); } auth() { const provider = new firebase.auth.GoogleAuthProvider(); this.afAuth.auth.signInWithRedirect(provider); } }
Here's what's going in this example:
auth()
signInWithRedirect()
getRedirectResult()
ngOnInit()
navigateByUrl()
This isn't a problem with one component. However, imagine having to manage redirects in multiple components.
The code in ngOnInit belongs in a Route Guard. This will clean up the component of routing logic and remove the Router dependency entirely.
ngOnInit
Router
A Route Guard is used for all sorts of useful things. In this case a guard can handle the redirect code.
@Injectable() export class RedirectGuard implements CanActivate { constructor( private authService: AngularFireAuth, private router: Router ) {} canActivate() { this.authService.auth.getRedirectResult().then(result => { if(result.user != null) { this.router.navigateByUrl('profile'); return false; } return true; }); } }
The canActivate method determined if the user has access to the route. Here's what happens:
canActivate
'profile'
This code is now reusable. The Angular Router lets you specify which routes you want to listen for a redirect.
import { Routes, RouterModule } from '@angular/router'; import { LoginComponent } from './login/login.component'; import { RedirectGuard } from './redirect.guard'; const ROUTES: Routes = [ { path: '', component: LoginComponent, canActivate: [RedirectGuard] }, { path: 'profile', loadChildren: 'app/profile/profile.module#ProfileModule' } ]; const AppRoutes = RouterModule.forRoot(ROUTES); export { AppRoutes }
Now the LoginComponent is free of routing code:
LoginComponent
@Component({ selector: 'app-login', template: ` <button class="btn" (click)="auth()"> Login </button> `, styleUrls: ['./login.scss'] }) export class LoginComponent { constructor(private afAuth: AngularFireAuth) { } auth() { const provider = new firebase.auth.GoogleAuthProvider(); this.afAuth.auth.signInWithRedirect(provider); } }
No more async flow mess. The right code is organized in the right place. You can add the RedirectGuard to more routes as the app grows, which keeps the complexity out of your components.
RedirectGuard
Dashboards are great, but what if you're not checking them? Wouldn't it be great to know when you have a huge spike in traffic, or if you're about to hit your concurrent connections limit for a single database? Don't worry, Google Stackdriver Alerts have you covered!
Back in December, we announced that the Firebase Realtime Database has integrated with Google Stackdriver to let you create dashboards and graphs of powerful new metrics. We also have more in-depth descriptions of these metrics available in our documentation, as well as other monitoring and debugging tips for your databases. Now we've made all this data actionable through Google Stackdriver Alerts!
You can set alerts that will trigger actions whenever particular conditions are met. For example, if the metric io/database_load goes over 90% for more than one minute, an email will go out to your engineering team. It's also possible to include documentation in your alert, which can help if you haven't yet had your morning coffee. To learn more about conditions that can trigger alerts, see the Condition details documentation.
io/database_load
In addition to the plethora of available conditions, Google Stackdriver also lets you choose how to be alerted. On the basic tier, you can be notified via email or the Google Cloud Console Mobile App. On the premium tier, you're able to create an incident via PagerDuty or have a message posted to your Slack Channel. One of my personal favorite premium notifications is the Webhook option, which you can even use to trigger a Cloud Function to help you diagnose the issue. For the load example, when your database is nearing 100% load, you could start a Cloud Function, have it profile your database, then report the findings to your Slack Channel.
Setting up a custom alert in Stackdriver is a straightforward process. Start by heading over to the Stackdriver Monitoring Console. Once you've signed up for an account, navigate to Alerting > Create a Policy. You should see a panel like this:
For this alerting policy, I've specified that when my database utilization is over 90% for more than a minute, I'll receive an email at alerts@you.com with the name of the policy, plus the documentation I specified. Now all I need to do is hit the Save Policy button, and my alert is live!
Firebase is returning to the Game Developers Conference this year in San Francisco! We've been hard at work making Firebase more valuable for all you game developers out there, and would love to spend time talking with you about how we can make it even better.
While we'll be available to chat at booth 823 for the rest of the conference, we also dropped by the Google Developer Day on Monday to share a few exciting announcements with everybody. In case you missed it, here's the quick summary:
Firebase Auth already lets your players log in safely and securely through a variety of ways -- everything from using their Facebook or Google account to a custom email and password -- but we've now added support for players to sign in using Google Play Games Services (GPGS).
If you're currently using GPGS in your game, you can use the credentials you already have to authenticate your users' accounts with the Firebase service. And if you haven't used GPGS in your Android games yet, you really should because it's an easy -- and often frictionless -- way to get your players signed in. Either way, this means your game can start using Firebase to store user-specific data in Realtime Database or Cloud Storage as soon as your players are signed in through GPGS.
While many of you are developing games for mobile devices, we know that it's often much more convenient to build and test your game on a desktop machine. With that in mind, we've added desktop support so that Firebase will work right from your development environment (Unity player on a Windows machine, for example). This support includes products like:
So if your game relies on one of these products, you can continue to use the same development process you always have, without the hassle of deploying your game on a device every time you want to test it.
Note that desktop support is intended to make development and testing easier, but it's not for publishing Firebase-enabled games to end users on desktop machines.
We debuted Firebase Predictions and A/B Testing at the Firebase Developer Summit in Amsterdam a few months ago, but we think both of these features are so useful to game developers that we want to mention them again. :)
Firebase Predictions brings the power of machine learning to Firebase. By analyzing your players' behavior, we can predict which ones will be most likely to churn out, spend money, or perform any other conversion event that you've defined in Analytics. This allows you to customize your app's behavior (using Remote Config or Notifications) specifically to that group of users. Want to engage players who are likely to stop playing your game? Give them extra lives, or send them a free gift they can redeem inside your game! Want to target players who are likely to spend money on in-app purchases? Notify them about a big sale, or change the layout of your in-app store!
In fact, Rockbite Studios did just that. They used Remote Config to feature certain items at the top of their in-app store for players who were predicted to spend money in their game, while also adding new ad-viewing options for players who were predicted to not spend money. As a result, they boosted revenue by 25% for their spenders, and 24% for their non-spenders!
Firebase A/B testing is great way to improve your game by making data-driven decisions based on experiments that you can run inside your app. Want to know if increasing the difficulty of your game will increase or decrease player engagement? Curious to learn if increasing the amount of premium currency your players start off with will increase or decrease your overall revenue? You can run experiments to uncover answers to all of these questions (and much much more) through Firebase A/B testing.
Firebase A/B testing is easy to get started with, as it runs on top of Remote Config and Analytics, which you might already be using. Experiments can be set up entirely through the Firebase console, which means your game designers or analysts can build, publish, and analyze experiments on their own without needing too much time from your engineering team. And it's all available at no cost to you, which is always nice.
If you want to learn more about how Firebase can make it easier for you to build successful games, come talk to us! We'll be available at booth 823 all during the expo, and we're giving a special presentation on what's new with Firebase and the Google Cloud Platform on Wednesday, March 21st, at 3:30 in the South Hall.
And of course, you can always find out more at https://firebase.google.com/games/
Game on!
Firebase Remote Config is a simple way for you to change elements of your app on the fly, just by using the Firebase console. As developers used Remote Config, many of you requested the ability to change these values without having to go through the Firebase console at all. We're happy to announce that you can now update your Remote Config values directly through the new Remote Config REST API.
The API itself consists of two calls: one to retrieve the current set of Remote Config values from the console, and another to set them. And to be clear, these are designed only for the purpose of setting remote config values without going through the Firebase console. If you want your clients to retrieve these values, they should do so through the native mobile client SDKs.
With this new API, you have the ability to make Remote Config more useful for your team, by creating in-house tools that incorporate specific logic that would be impossible to do from the Firebase console alone. Some examples include:
...and you've probably got a great idea or two we haven't even thought of yet.
The REST API is available starting today for anybody who wants to use it with their project, so give it a try! As always, if you have any questions about the REST API, or just want to show off some fun new tool you've built, please contact us in the Firebase Talk group, or on Stack Overflow.
At Firebase, it's our mission to help developers like you build better apps and grow your businesses. That means Firebase needs to work for you from your first user up to your millionth, with pricing plans that scale as you do.
Today, we're excited to announce that we're changing our Blaze (pay-as-you-go) plan to align with the free usage that we offer on our Spark (free) plan. To view more detail about these free usage limits, including a pricing calculator, you can check out our pricing page or scroll to the end of this blog post.
If you're on the Blaze plan and stay within these free usage limits, you will not be charged for the month and you will not receive a bill. You'll be charged for any usage above these limits at the same rates as before. The Spark and Flame (subscription) plans remain unchanged.
We've also heard your concerns about exceeding specific limits on the Blaze plan. Now, you can set up alerts, so you get notified when you're reaching usage thresholds, and set budgets in the billing section of the Firebase Console. You can choose project or billing level budgets and specific alerting thresholds.
This update will also make it easier for you to use Google Cloud Platform (GCP) services. The credit card you use for the Blaze plan is also a payment method for GCP. We know that previously, it was tough to justify adding a payment method when you would lose your free tier on Firebase. With this change, you can safely upgrade to the Blaze plan to use a GCP service without it affecting your Firebase costs.
There are a few minor differences between the Spark plan and the free usage within the Blaze plan.
As always, if you have any questions, please don't hesitate to contact us. We hope these pricing changes simplify your life and let you focus on what matters: building a great app. Happy coding!
*July 11 Edit: An earlier version of this blog post said that Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully. To clarify, that means that Firebase Crash Reporting will be accessible on September 8, 2018 and will no longer be accessible on September 9, 2018.*
Back in October, we were thrilled to launch a beta version of Firebase Crashlytics. As the top ranked mobile app crash reporter for over 3 years running, Crashlytics helps you track, prioritize, and fix stability issues in realtime. It's been exciting to see all the positive reactions, as thousands of you have upgraded to Crashlytics in Firebase!
Today, we're graduating Firebase Crashlytics out of beta. As the default crash reporter for Firebase going forward, Crashlytics is the next evolution of the crash reporting capabilities of our platform. It empowers you to achieve everything you want to with Firebase Crash Reporting, plus much more.
This release include several major new features in addition to our stamp of approval when it comes to service reliability. Here's what's new.
We heard from many of you that you love Firebase Crash Reporting's "breadcrumbs" feature. (Breadcrumbs are the automatically created Analytics events that help you retrace user actions preceding a crash.) Starting today, you can see these breadcrumbs within the Crashlytics section of the Firebase console, helping you to triage issues more easily.
To use breadcrumbs on Crashlytics, install the latest SDK and enable Google Analytics for Firebase. If you already have Analytics enabled, the feature will automatically start working.
By broadly analyzing aggregated crash data for common trends, Crashlytics automatically highlights potential root causes and gives you additional context on the underlying problems. For example, it can reveal how widespread incorrect UIKit rendering was in your app so you would know to address that issue first. Crash insights allows you to make more informed decisions on what actions to take, save time on triaging issues, and maximize the impact of your debugging efforts.
From our community:
"In the few weeks that we've been working with Crashlytics' crash insights, it's been quite helpful on a few particularly pesky issues. The description and quality of the linked resources makes it easy to immediately start debugging." - Marc Bernstein, Software Development Team Lead, Hudl
- Marc Bernstein, Software Development Team Lead, Hudl
Generally, you have a few builds you care most about, while others aren't as important at the moment. With this new release of Crashlytics, you can now "pin" your most important builds which will appear at the top of the console. Your pinned builds will also appear on your teammates' consoles so it's easier to collaborate with them. This can be especially helpful when you have a large team with hundreds of builds and millions of users.
To show you stability issues, Crashlytics automatically uploads your dSYM files in the background to symbolicate your crashes. However, some complex situations can arise (i.e. Bitcode compiled apps) and prevent your dSYMs from being uploaded properly. That's why today we're also releasing a new dSYM uploader tool within your Crashlytics console. Now, you can manually upload your dSYM for cases where it cannot be automatically uploaded.
With today's GA release of Firebase Crashlytics, we've decided to sunset Firebase Crash Reporting, so we can best serve you by focusing our efforts on one crash reporter. Starting today, you'll notice the console has changed to only list Crashlytics in the navigation. If you need to access your existing crash data in Firebase Crash Reporting, you can use the app picker to switch from Crashlytics to Crash Reporting.
Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully.
Upgrading to Crashlytics is easy: just visit your project's console, choose Crashlytics in the left navigation and click "Set up Crashlytics":
If you're currently using both Firebase and Fabric, you can now link the two to see your existing crash data within the Firebase console. To get started, click "Link app in Fabric" within the console and go through the flow on fabric.io:
If you are only using Fabric right now, you don't need to take any action. We'll be building out a new flow in the coming months to help you seamlessly link your existing app(s) from Fabric to Firebase. In the meantime, we encourage you to try other Firebase products.
We are excited to bring you the best-in class crash reporter in the Firebase console. As always, let us know your thoughts and we look forward to continuing to improve Crashlytics. Happy debugging!
