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 a new environment
Adding and switching between environments with the Firebase CLI is as simple as one command: 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 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.
Switching environments
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
For a single command, you can also specify the environment using the -P flag:
$ firebase deploy -P staging # deploy to staging alias
That’s it!
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!
With Firebase Dynamic Links, we made it easier for you to share deep links into your app by providing a single link that works across iOS and Android. It can even survive through the app installation process from the App Store and on Google Play. These Dynamic Links have many uses in email or social media campaigns, but one powerful use case is to enable your users to share elements of your app with their friends. A game, for instance, can take advantage of Firebase Dynamic Links to share replays of a level, so players can challenge their friends to beat their score.
And while this kind of user-to-user sharing can be quite effective -- word of mouth is still one of the most powerful drivers of app discovery -- the process of generating a Dynamic Link and making it easy for the user to send it to their friends through an SMS or email message is a sizeable chunk of work. Work that most developers would rather be spending on other tasks like building their app.
So that's the idea behind Firebase Invites: We wanted to take that process of sharing a Dynamic Link over SMS or email, and streamline it for developers. And now that we've seen some instances of Firebase Invites out in the real world, we wanted to share a couple of tips for you on how to better take advantage of Firebase Invites to make them more compelling.
Share something specific
Because Firebase Invites is built on top of Dynamic Links, your users can share specific deep link information with their friends. This means that invite recipients can immediately start up your app with an experience that's relevant to the invitation they clicked on, rather than just a standard home screen.
You should take advantage of this to ensure that you're sharing specific information about your app; not just building a generic "Share this app with my friends" feature. If you have an exercise app, make sure your users can share their latest workout or their jogging route with their friends. Or if you have a ride-sharing app with a referral code, make sure your users can share that code with their friends.
Along those lines, you should make sure that whatever interface you use to start the sharing process is close to the content your users will want to share. If you simply place a generic sharing option somewhere in your settings menu, you're probably not going to see a huge lift in usage or installs. On the other hand, if you place a "Share this!" button close to that jogging route or referral code your users want to share, it becomes a lot more compelling.
Customize your emails
When you send an email invitation from Firebase Invites, the library can automatically populate the email with images and text taken directly from your app's Play Store or App Store listing. This is certainly nice from a convenience standpoint -- you can craft a nicely-formatted email full of content with just a few lines of code.
And if you were using Firebase Invites for a generic app sharing feature, this might be fine. But if you're using Firebase Invites to share a specific piece of content like we recommend, you can customize this outgoing email by taking advantage of the setEmailHtmlContent method on Android. This gives your client the ability to supply any html you want as the content of your outgoing email message, so you can display an email message that's more relevant to the content that your users are looking to share.
For example, Yummly used Firebase Invites to power a feature where users could share specific recipes with their friends. By customizing the outgoing email on the client, Yummly provided detailed descriptions and images of each recipe for every recipient. Presenting more relevant information up front is a more interesting experience for recipients, which can lead to more engagement than the standard Firebase Invite email content.
And hey, while you're at it, why not use Firebase Remote Config in conjunction with App Invites to rapidly iterate over different versions of your email content? If you wire up your app to grab its outgoing email text from Remote Config rather than hard-coding it into your app, you can try out new emails without having to update your app. With a little bit of experimentation, you can figure out what kinds of email content are the most persuasive.
Properly support iOS users
One important limitation to understand with Firebase Invites is that, while your Android users can send and receive invitations at any time, and your iOS users can receive invitations freely, if you want to send an invite on iOS, your user must be signed in with Google.
For many developers, this isn't a problem; they encourage users to sign in, and Google is one of their preferred providers. But other apps might not have sign-in at all, or don't support Google sign-in, which makes Firebase Invites a little less appealing on iOS. Many developers at this point are tempted to think, "Well, that's fine. I'll just support Firebase Invites on my Android app."
The problem with this approach is that if a developer supports sending invites from an Android device, their users will still send invites to all their friends -- both iOS and Android users! And if the Firebase Invites library isn't available on the iOS side to read in this invitation, the corresponding deep link data (and all the Firebase Invite magic) gets lost.
Therefore, we recommend that even if you decide to not support the sending of invites on iOS, you should at least support the ability to receive invites on iOS. That way, your iOS users can still make sure they retrieve all the appropriate deep link information when they accept an invite, to get the full sharing experience.
Sharing is caring!
It seems like nearly every app has some kind of content -- whether it's a cool replay in a game, a funny picture, or a referral code -- that would benefit from sharing. And I'm guessing that somewhere on your app's to-do list, you have a "Let users share (designated content) with friends" item that you're still planning on implementing just as soon as you have a bunch of spare cycles to figure it out.
With Firebase Invites, we can take a lot of the work out of the process and move these features from the "figure it out one day" category into the "low-hanging fruit" category. Or, at least, fruit you can reach with a short stepladder. (Produce-based metaphors were never my strong suit.) So give it a try -- be sure to peruse our documentation, and check out some of our best practices for more invitation goodness.
UPDATE: We updated this tutorial for the Firebase 3.1.0 SDK which now supports the Firebase Realtime Database and Firebase Authentication.
Here at Firebase, we’rebigReact fans. Firebase synchronizes application state, and React re-renders the application UI based on state changes. It’s a perfect fit.
And with React Native, app development became a lot easier for JavaScript developers. Using React Native you can build real native apps with just JavaScript. And that’s just awesome-sauce. We live in the future. Let’s get started.
Getting started with React Native is fairly easy, but there are some gotchas you should be aware of. If you already have React Native set up, you can skip this section.
Then finally, you can begin your project with the CLI command:
react-native init GroceryApp # or whatever you want
Open the main folder in your favorite editor.
atom GroceryApp # if you’re into Atom
Build and run
To build a React Native project, run the following command:
react-native run-ios
This should launch the Simulator, and you should see the boilerplate screen.
React Native comes with hot-reloading, which means you can make an edit to the code, index.ios.js, and then hit Cmd+R and see your changes instantly update. And if you’re an iOS developer, or really any kind of developer, you know how cool that is.
With the build setup done, let’s get Firebase up and running.
Firebase Setup
React Native manages dependencies through npm. To install Firebase, run the following command at the root of the project.
npm install firebase --save
Open index.ios.js and add the following line to the top:
import * as firebase from 'firebase';
Then right above the component, initialize Firebase with your config values:
What’s a const? A const is a read-only reference to a value, which makes sense here, because you don’t want to ever override the value of Firebase. You can use this keyword since you’re using Node 4.0 or higher. If your editor yells at you, it’s telling you a lie.
One ES2015 feature isn’t enough. Rather than use React.createClass() to define components, let’s use classes.
ES2015 (ES6) Components
React is component-based. Which means an app is just a tree of components, starting with a root component. As of React 0.14, you can use ES2015 classes to define React components.
In index.ios.js, let’s change the component to use a class rather than React.createClass().
The shell of the app is complete. Let’s make it look good, or at least halfway decent.
Styling in React Native
React Native uses JavaScript rather than CSS for styling. This may sound like an extreme divergence, but it’s really not all that different. To declare a set of styles, you create a StyleSheet.
StatusBar (purple): displays the title of the view
ListView (green): displays the list of grocery items
ListItem (black): displays an individual item from the list
ActionButton (blue): adds an item to the list
Create a folder named components. Each one of these components is stored in the components folder. The exception is GroceryApp, since it is contained in index.ios.js.
Add each one of these components below to the components folder:
The component has a special property called state, which manages the entire data flow of the application. We’ll dive deeper in the next section.
The app’s state is a ListView.DataSource, which is a class that provides efficient data processing to a ListView component. The next step is to display this data.
Each component has a lifecycle, where certain functions are called at important events. When the component has first been rendered, componentDidMount() is called. This is where we want set any initial state of the app.
Build and run the app, and you should see the following static app.
Each one of these components just simply displays data, or sets a callback function for a touch.
The key thing to understand is that these components are not state-ful. They have properties that are set by their root component, GroceryApp. To begin to understand React, you have to learn how to manage state.
State
State is simply data that can change. This data is called state, because it represents the "state" of your application. If this data changes, your application will likely look different, hence being in a different "state". State is usually things like a list of todos, or an enabled/disabled button.
The root component will serve as the holder of state. State changes start at the root component, which is then responsible for updating the properties of its child components.
Component properties are immutable, meaning they can’t be modified. So, if you can’t modify the properties, how do they ever change? You re-render, the application by calling setState(), like seen in componentDidMount().
The setState() function is special because every time it is called, it will attempt to re-render the entire app. This means that if a child property is different from the last state, it will be re-rendered with the new value.
This is where React fits perfectly with Firebase. Because the Firebase database synchronizes application state across multiple devices, and React efficiently re-renders application state changes.
Realtime Database listener
Create Realtime Database reference as a property in the constructor:
this.itemsRef = firebaseApp.database().ref();
Then, add the following function to the GroceryApp component:
listenForItems(itemsRef) {
itemsRef.on('value', (snap) => {
// get children as an array
var items = [];
snap.forEach((child) => {
items.push({
title: child.val().title,
_key: child.key
});
});
this.setState({
dataSource: this.state.dataSource.cloneWithRows(items)
});
});
}
This function creates a value listener for all grocery items. Whenever an item is added, changed, or removed, you’ll get the entire result set back as a DataSnapshot, from the Firebase SDK. Using the DataSnapshot, you call forEach(child), which iterates through all of the children and adds them to an array as a grocery list item. Notice in the .forEach function, a _key property is created from the DataSnapshot's .key() value. This makes life much easier when doing data operations later down the line.
Once the array is populated, you’ll update the dataSource property on state using dataSource.cloneWithRows(items). The cloneWithRows() function is just a convenience method for creating a new ListView.DataSource based on the same DataSource previously defined.
Next, you write the listen up to componentDidMount():
Build and run the app. You should see an empty page, but try adding a few items using the Firebase App Dashboard or the super awesome data viewer Vulcan, and you’ll see it update in realtime!
This is awesome, but you’d rather have the "Add" button working. Let’s tackle that in the next section.
Add Item
When the ActionButton is tapped, an alert should pop up prompting the user to enter an item. The AlertIOS API is what you’ll use to create this alert box.
Add the following function to the GroceryApp component:
The AlertIOS API is quite extensible when it comes to building alerts. The first two parameters are simple, they're just the title of the alert box and an optional message. The third parameter is the meat of the API. Here you create an array that specifies the buttons available to the user. Each button can have a text, style, and an onPress callback function. The last parameter is type the of input, whether plain-text or secure-text.
To add an item, create an object in the buttons array. This object can add items in the onPress callback. The callback returns the text the user has entered. Use this text to .push() a new child onto the /items location.
Next, you'll need to update render() to assign the onPress property of the ActionButton:
To "complete" an item, you'll need to delete it from the Firebase database. Using .child(key), you can drill down into a specific item in the list. The onPress callback is a closure, therefore it has access to the outer environment which contains the item parameter. This is where the _key property comes in hand.
When the "Complete" option is tapped, you can find the specific child by using the _key property on item. Then you can call .remove() to delete the item in the Firebase database.
Build and run, yet again. Tap any ListItem , tap "Complete", and you should see it removed from the list.
Get the code, give a star
Check out the completed app on Github. And, if you’re feeling generous, we would love a star. Feel free to fork the repo, and even send in a PR if you want.
Still having trouble?
If you’re running into issues, open up a question on Stackoverflow, we monitor the Firebase tag closely, or drop a line in our community Slack Team.
Engineer
In this series of posts we cover the features of Firebase. This time we'll talk about the most classic of Firebase features: the Realtime Database.
History
The Realtime Database was the first feature we launched for Firebase, over four years ago. Cloud-hosted JSON databases were still somewhat new at the time, so it immediately stood out. What made the Firebase database truly unique was its ability to synchronize data between the different clients instantly, with a single, simple to use API.
The Realtime database hides the complexity of building applications behind one consistent programming interface. This made it easy to build realtime, collaborative applications.
What is it?
The Realtime Database is really just one big JSON object that you manage in realtime. This means it’s really just a tree of values.
This allows for simple, flexible data modeling. The database is schemaless, which means you don't have to commit to a fixed structure early on. But, if you’re worried about data validation, the Realtime Database comes with a server enforced rules language that allows you to validate the data structure of each write to the database.
The truly unique aspect of the Firebase database is in its realtime synchronization. Most traditional databases make you work with a request/response model. You write a query, then ask the database to give you the results for that query. If you need the results again, or want to check for updates to the results, you execute the query again.
Our database is different. Our database tells you when changes occur. You say to our database: if something changes at this location in the tree, notify me. This makes it simple to monitor changes and to keep these changes in sync across all users.
Realtime Events
With a single API, the Firebase database provides your app with both the current value of the data and any updates to that data.
iOS
refHandle = postRef.observeEventType(FIRDataEventType.Value, withBlock: { (snapshot) in
let postDict = snapshot.value as! [String : AnyObject]
// …
})
Web
firebase.database().ref('posts/' + postId).on('value', function(snapshot) {
var post = snapshot.val();
// …
});
Android
mPostReference.addValueEventListener(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
// Get Post object and use the values to update the UI
Post post = dataSnapshot.getValue(Post.class);
// …
}
@Override
public void onCancelled(DatabaseError databaseError) {
// Getting Post failed, log a message
Log.w(TAG, "loadPost:onCancelled", databaseError.toException());
// …
}
});
Your app then displays the data in its user interface and allows the user to manipulate it. It's that easy.
What happens when you're offline
Ever used an app that became unresponsive the very moment you lost network connection? Most developers want their app to work despite the network condition. That's why the Firebase database keeps an internal cache of all data that is being shown in the app. When the network connection temporarily drops, the app keeps working from the cache. And while the connection is lost, the Firebase data client keeps a queue of local write operations. Your app continues to work and remains responsive, all without having to write any extra code.
The power of the Firebase platform is in the integration of all our features. We're adding more integrations, but these are a few example of the integrations that you can already use. Allow your users to sign in to your app, then secure access to their data based on their identity. Store the user's files in Firebase Storage, then use the realtime database to synchronize the status and availability to all other users of the app. Track what files are most popular with Firebase Analytics and invite other users to collaborate on those files. The possibilities are almost endless and it's never been easier to build an app than with Firebase.
Developer Advocate
You asked for it, and it’s finally here: file storage for Firebase developers!
Firebase Storage is a stand-alone solution for uploading user generated content like images and videos from an iOS and Android device, as well as the Web. In typical Firebase fashion, there's no server required.
Firebase Storage is designed specifically for scale, security, and network resiliency.
Scale: Every file uploaded is backed by Google Cloud Storage, which scales to petabytes.
Security: Files can be secured to specific users or sets of users using Storage Security Rules.
Network Resiliency: Uploads and downloads are automatically retried in the case of poor network connections, so you don’t have to keep track of them yourself.
In this blog post, we’ll cover five tips to help you go far with Firebase Storage. But enough with the chatter, let’s see some code!
1. References point to files
Even if you’re not familiar with the Realtime Database, you’ll feel right at home storing data with Firebase Storage. Firebase Storage uses a simple folder/file system to structure data. Each file is accessed through a reference:
Web
var storageRef = firebase.storage.ref("folderName/file.jpg");
Swift
let storageRef = FIRStorage.reference().child("folderName/file.jpg")
References give you control over files at that location in your storage bucket. With this storage reference you can easily download an existing file, or upload a new one.
2. Upload files with one method
Once you have a reference, you can upload a file with one method:
Web
var storageRef = firebase.storage.ref("folderName/file.jpg");
var fileUpload = document.getElementById("fileUpload");
fileUpload.on(‘change’, function(evt) {
var firstFile = evt.target.file[0]; // get the first file uploaded
var uploadTask = storageRef.put(firstFile);
});
iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
let localFile: NSURL = // get a file;
// Upload the file to the path "folderName/file.jpg"
let uploadTask = storageRef.putFile(localFile, metadata: nil)
For the web, the binary file comes from the File object received from the <input type="file" /> element. iOS users can upload a file from memory or from a local file. On Android you can even upload using a stream.
3. Monitor progress with Tasks
Need to create a progress indicator for your app? Firebase Storage makes it easy. When you upload or download a file, Firebase Storage creates UploadTask or DownloadTasks, which allows you to monitor the progress of the file upload or download.
Web
var storageRef = firebase.storage.ref("folderName/file.jpg");
var fileUpload = document.getElementById("fileUpload");
fileUpload.on(‘change’, function(evt) {
var firstFile = evt.target.file[0]; // get the first file uploaded
var uploadTask = storageRef.put(firstFile);
uploadTask.on(‘state_changed’, function progress(snapshot) {
console.log(snapshot.totalBytesTransferred); // progress of upload
});
});
iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
let localFile: NSURL = // get a file;
// Upload the file to the path "folderName/file.jpg"
let uploadTask = storageRef.putFile(localFile, metadata: nil)
let observer = uploadTask.observeStatus(.Progress) { snapshot in
print(snapshot.progress) // NSProgress object
}
The progress listeners return a snapshot of the upload and the file is uploaded to the server. This snapshot gives you useful information, such as the total size of the file in bytes and how many bytes have been uploaded so far. Using this information, you can calculate the percentage uploaded and use it to update any UI control in your app.
4. Download files with one method
There are two ways to download files with Firebase Storage, using references in the SDK or a download URL. iOS and Android users can download files into memory, disk, or from a download URL. The web SDK can download files just from a download URL.
Web
var storageRef = firebase.storage.ref("folderName/file.jpg");
storageRef.getDownloadURL().then(function(url) {
console.log(url);
});
iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
storageRef.downloadURLWithCompletion { (URL, error) -> Void in
if (error != nil) {
// Handle any errors
} else {
// Get the download URL for 'images/stars.jpg'
}
}
Android
StorageReference storageRef = FirebaseStorage.getInstance().reference().child("folderName/file.jpg");
storageRef.getDownloadUrl().addOnSuccessListener(new OnSuccessListener() {
@Override
public void onSuccess(Uri uri) {
// Got the download URL for 'users/me/profile.png'
}
}).addOnFailureListener(new OnFailureListener() {
@Override
public void onFailure(@NonNull Exception exception) {
// Handle any errors
}
});
iOS and Android apps can either store the file in memory or on disk, or use URLs to work with popular image caching libraries. Where web apps prefer having the URL due to the modern browsers powerful caching systems.
5. User based security with Storage Security Rules
Similar to the Realtime Database, Firebase Storage provides you with a set of rules that allow you to specify constraints to the size and type of files uploaded and who has access to what files. Firebase Storage integrates with Firebase Authentication, which allows you to secure files against users in your application.
This is great for situations where you only want to let users upload their own profile photos, but allow anyone else to view it.
// Only a user can upload their profile picture, but anyone can view it
service firebase.storage {
match /b/<bucket>/o {
match /users/{userId}/profilePicture.png {
allow read;
allow write: if request.auth.uid == userId;
}
}
}
What do you think?
We’re extremely proud of everything we’ve done with Firebase Storage so far, but it’s just the beginning and we want your feedback! What are some of your useful Firebase Storage tips? What are you using Firebase Storage for? What features would help you and your apps? Leave a comment or hit us up in our Slack Team.
Software Engineer
Thanks to your continued feedback, Firebase now has broader support for React Native with version 3.1.0 of the JavaScript SDK. And, that’s not all! This version also adds unauthenticated access from the Node.js SDK, which means you can initialize an app without a service account. What does this all mean? Let’s break it down.
React Native Support
When the Firebase 3.x SDK was released at Google I/O, the authentication part of the SDK was no longer compatible with React Native. The 3.1.0 release replaces the use of browser-specific APIs that allows Firebase to once again work with React Native. In addition, it fixes longstanding issues with using Firebase in React Native, including persisting authentication state across app restarts. This means all you have to do is initialize your Firebase project just as you would in any other JavaScript app:
import ReactNative from "react-native";
import * as firebase from 'firebase';
// Initialize Firebase
const firebaseConfig = {
apiKey: "<YOUR-API-KEY>",
authDomain: "<YOUR-AUTH-DOMAIN>",
databaseURL: "<YOUR-DATABASE-URL>",
storageBucket: "<YOUR-STORAGE-BUCKET>"
};
firebase.initializeApp(firebaseConfig);
With the updates in the 3.1.0 SDK, almost all of the JavaScript SDK’s functionality should now work smoothly in React Native. But there are a couple caveats:
"Headful" auth methods such as signInWithPopup(), signInWithRedirect(), linkWithPopup(), and linkWithRedirect() do not work in React Native (or Cordova, for that matter). You can still sign in or link with a federated provider by using signInWithCredential() with an OAuth token from your provider of choice.
React Native does not support the File and Blob types, so Firebase Storage uploads will not work in this environment. File downloads do work however.
Unauthenticated Access
Another feature of the 3.1.0 release is support for unauthenticated access with the Node.js SDK. Previously a service account was required to use the Node.js SDK. This required you to create a service account key in the Firebase Console, download it to your server, and authenticate by referencing the file in your code.
A service account is still required to create and verify tokens, but it isn’t necessary for all Node.js use cases. With the latest SDK, we’ve relaxed this requirement, so you can initialize your app with just your database URL.
import * as firebase from 'firebase';
firebase.initializeApp({
databaseURL: "<YOUR-DATABASE-URL>",
});
Without a service account, access to the Realtime Database will be restricted just like any other unauthenticated client.
Let us know what you think
Thanks to everyone for their patience and voicing their opinions in our Slack Team, on our Google Group, and across our other support channels. If you run into any issues with the new SDK, please reach out. Are you excited about React Native and Firebase? Let us know in the comments.