Today we released new versions of our Android (2.4.0), iOS (2.4.0), and JavaScript (2.3.0) clients. You can read the individual changelogs for details (Android, iOS, web), but we wanted to expand on three highly requested features shipping with this release: atomic multi-location writes, ordering queries by deep paths, and iOS 9 bitcode support. Let's jump in!
Firebase has always supported updating multiple children of a node atomically. For example, let's assume the /user path in our Firebase database contains the following data:
/user
{ "user": { "name": "Samantha", "age": 25 } }
Using the pre-existing atomic update support, we can change the user's age and add a city without updating their name:
age
city
name
var ref = new Firebase("https://.firebaseio.com"); var userRef = ref.child("user"); var newUserData = { "age": 30, "city": "Provo, UT" }; ref.child("user").update(newUserData);
Firebase ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com"); Firebase userRef = ref.child("user"); Map newUserData = new HashMap(); newUserData.put("age", 30); newUserData.put("city", "Provo, UT"); userRef.updateChildren(newUserData);
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://<YOUR-FIREBASE-APP>.firebaseio.com"]; Firebase *userRef = [ref childByAppendingPath: @"user"]; NSDictionary *newUserData = @{ @"age": 30, @"city": "Provo, UT" }; [userRef updateChildValues: newUserData];
let ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com") let userRef = ref.childByAppendingPath("user") let newUserData = ["age": 30, "city": "Provo, UT"] userRef.updateChildValues(newUserData)
var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); // Generate a new push ID for the new post var newPostRef = ref.child("posts").push(); var newPostKey = newPostRef.key(); // Create the data we want to update var updatedUserData = {}; updatedUserData["user/posts/" + newPostKey] = true; updatedUserData["posts/" + newPostKey] = { title: "New Post", content: "Here is my new post!" }; // Do a deep-path update ref.update(updatedUserData, function(error) { if (error) { console.log("Error updating data:", error); } });
Firebase ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); // Generate a new push ID for the new post Firebase newPostRef = ref.child("posts").push(); String newPostKey = newPostRef.getKey(); // Create the data we want to update Map newPost = new HashMap(); newPost.put("title", "New Post"); newPost.put("content", "Here is my new post!"); Map updatedUserData = new HashMap(); updatedUserData.put("users/posts/" + newPostKey, true); updatedUserData.put("posts/" + newPostKey, newPost); // Do a deep-path update ref.updateChildren(updatedUserData, new Firebase.CompletionListener() { @Override public void onComplete(FirebaseError firebaseError, Firebase firebase) { if (firebaseError != null) { System.out.println("Error updating data: " + firebaseError.getMessage()); } } });
Firebase *ref = [[Firebase alloc] initWithUrl: @"https://<YOUR-FIREBASE-APP>.firebaseio.com"]; // Generate a new push ID for the new post Firebase *newPostRef = [[ref childByAppendingPath:@"posts"] childByAutoId]; NSString *newPostKey = newPostRef.key; NSString *updateUserPath = [NSString stringWithFormat:@"users/posts/%@", newPostKey]; NSString *updatePostPath = [NSString stringWithFormat:@"posts/%@", newPostKey]; // Create the data we want to update NSMutableDictionary *updatedUserData = [[NSMutableDictionary alloc] init]; [updatedUserData setValue:[NSNumber numberWithBool:YES] forKey:updateUserPath]; [updatedUserData setValue:@{@"title": @"New Post", @"content": @"Here is my new post!"} forKey:updatePostPath]; // Do a deep-path update [ref updateChildValues:updatedUserData withCompletionBlock:^(NSError *error, Firebase *ref) { if (error) { NSLog(@"Error updating data: %@", error.debugDescription); } }];
let ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com") // Generate a new push ID for the new post let newPostRef = ref.childByAppendingPath("posts").childByAutoId() let newPostKey = newPostRef.key // Create the data we want to update let updatedUserData = ["users/posts/\(newPostKey)": true, "posts/\(newPostKey)": ["title": "New Post", "content": "Here is my new post!"]] // Do a deep-path update ref.updateChildValues(updatedUserData, withCompletionBlock: { (error, ref) -> Void in if (error) { print("Error updating data: \(error.description)") } })
Deep path updates let you write cleaner code and easily denormalize data across multiple nodes in your Firebase database.
Up until now, we have been able to order queries by direct children. Here's a snippet of the dinosaur data stored in our database of dinosaur facts:
{ "lambeosaurus": { "height" : 2.1, "length" : 12.5, "weight": 5000 }, "stegosaurus": { "height" : 4, "length" : 9, "weight" : 2500 } }
To read all dinosaurs ordered by height, we can order nodes by a common child key:
var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); ref.orderByChild("height").on("child_added", function(snapshot) { var dinoName = snapshot.key(); var dinoData = snapshot.val(); console.log(dinoName + " was " + dinoData.height + " meters tall"); });
Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); Query queryRef = ref.orderByChild("height"); queryRef.addChildEventListener(new ChildEventListener() { @Override public void onChildAdded(DataSnapshot snapshot, String previousChild) { DinosaurFacts facts = snapshot.getValue(DinosaurFacts.class); System.out.println(snapshot.getKey() + " was " + facts.getHeight() + " meters tall"); } // .... });
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"]; [[ref queryOrderedByChild:@"height"] observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) { NSLog(@"%@ was %@ meters tall", snapshot.key, snapshot.value[@"height"]); }];
let ref = Firebase(url:"https://dinosaur-facts.firebaseio.com/dinosaurs") ref.queryOrderedByChild("height").observeEventType(.ChildAdded, withBlock: { snapshot in if let height = snapshot.value["height"] as? Double { println("\(snapshot.key) was \(height) meters tall") } })
This works great, but sometimes we want to order by descendants further down in our data tree. Let's say our dinosaur data actually looked like this:
{ "lambeosaurus": { "dimensions": { "height" : 2.1, "length" : 12.5, "weight": 5000 } }, "stegosaurus": { "dimensions": { "height" : 4, "length" : 9, "weight" : 2500 } } }
Previously there was no way to sort these dinosaurs based on any of their dimensions since they are stored too many levels deep. Now we can use a deep path query!
var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); ref.orderByChild("dimensions/height").on("child_added", function(snapshot) { var dinoName = snapshot.key(); var dinoData = snapshot.val(); console.log(dinoName + " was " + dinoData.dimensions.height + " meters tall"); });
Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); Query queryRef = ref.orderByChild("dimensions/height"); queryRef.addChildEventListener(new ChildEventListener() { @Override public void onChildAdded(DataSnapshot snapshot, String previousChild) { DinosaurFacts facts = snapshot.getValue(DinosaurFacts.class); System.out.println(snapshot.getKey() + " was " + facts.getHeight() + " meters tall"); } // .... });
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"]; [[ref queryOrderedByChild:@"dimensions/height"] observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) { NSLog(@"%@ was %@ meters tall", snapshot.key, snapshot.value[@"dimensions"][@"height"]); }];
let ref = Firebase(url:"https://dinosaur-facts.firebaseio.com/dinosaurs") ref.queryOrderedByChild("dimensions/height").observeEventType(.ChildAdded, withBlock: { snapshot in if let height = snapshot.childSnapshotForPath("dimensions/height").value as? Double { println("\(snapshot.key) was \(height) meters tall") } })
The ability to order by deep paths gives you much more freedom in structuring your data.
The Firebase iOS client is now compiled with bitcode support, a new iOS 9 feature. Bitcode is an "intermediate" language that Apple uses to represent your iOS and watchOS apps. According to Apple, “including bitcode will allow [us] to re-optimize your app binary in the future without the need to submit a new version of your app to the store.” This enables you to ship smaller apps through app thinning, as well as design for future products, decreasing development time and increasing the number of platforms upon which your app runs.
On top of the new features mentioned above, we have also fixed a handful of bugs across each of the clients. Memory leaks, cache inconsistencies, and crashes have been tracked down and fixed in today's releases.
All of these new features and bug fixes are now available in version 2.4.0 of the mobile clients and version 2.3.0 of the JavaScript client. See the installation and setup guides for each platform (Android, iOS, web) to learn how to get started with the latest clients.
We'd love to hear what you think of this release. Post any feedback or submit bug reports in our Google Group. Lastly, if you've built anything, don't be shy! Share your apps with us on Twitter @Firebase. We're excited to see what you build.
Designed to help native mobile developers quickly and easily develop Firebase apps, FirebaseUI eliminates bloat in your application code by providing native bindings to common UI controls.
FirebaseUI adds support to quickly hook a Firebase database reference or query to a ListView, GridView, RecyclerView on Android or a UITableView or UICollectionView iOS.
ListView
GridView
RecyclerView
UITableView
UICollectionView
Start by creating an Android Firebase project or iOS Firebase project then follow our Android or iOS quickstarts below.
On Android, add the latest version of FirebaseUI to your build.gradle:
build.gradle
compile 'com.firebase:firebase-ui:0.2.0'
Resync your project and you're ready to continue.
More information, including a more in-depth installation walkthrough, can be found on the FirebaseUI-Android README.
Once we've installed FirebaseUI, create a FirebaseListAdapter which binds a Firebase database reference or query to a ListAdapter and provides developers an easy way to populate ListView views with developer specified model objects (more information on using Java Objects is available in the docs).
FirebaseListAdapter
ListAdapter
Firebase.setAndroidContext(this); Firebase ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); mAdapter = new FirebaseListAdapter<ChatMessage>(this, ChatMessage.class, android.R.layout.two_line_list_item, ref) { @Override protected void populateView(View view, ChatMessage object) { /* Populate view with contents of the model object */ } }; mListView.setListAdapter(mAdapter);
If you want more examples, check out the Android README, or see our Android chat app example. The Javadoc is available here.
On iOS, add the latest version of FirebaseUI to your podfile:
podfile
pod 'FirebaseUI', '~> 0.2.0'
If you're using Swift, make sure to add:
platform :ios, '8.0' use_frameworks!
pod install, then open the generated .xcworkspace.
pod install
.xcworkspace
More information, including a more in-depth installation walkthrough, can be found on the FirebaseUI-iOS README.
Once we've installed FirebaseUI, create a FirebaseTableViewDataSource. This datasource will provide cells and the associated FDataSnapshots (or a custom model object, a feature in beta) to populate UITableViewCells, a custom subclass, or even a custom XIB.
FirebaseTableViewDataSource
FDataSnapshots
UITableViewCells
XIB
Firebase *ref = [Firebase alloc] initWithUrl:@"https://<YOUR-FIREBASE-APP>.firebaseio.com/chat"]; self.dataSource = [[FirebaseTableViewDataSource alloc] initWithRef:ref modelClass:[FDataSnapshot class] cellClass:[UITableViewCell class] cellReuseIdentifier:@"" view:self.tableView]; [self.dataSource populateCellWithBlock:^void(UITableViewCell *__nonnull cell, FDataSnapshot *__nonnull snap) { /* Populate cell with contents of the snapshot */ } }]; self.tableView.dataSource = self.dataSource;
let ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio-demo.com") self.dataSource = FirebaseTableViewDataSource(ref: ref, modelClass: FDataSnapshot.self, cellClass: UITableViewCell.self, cellReuseIdentifier: "", view: self.tableView) self.dataSource.populateCellWithBlock { (cell: UITableViewCell, obj: NSObject) -> Void in let snap = obj as! FDataSnapshot // Force cast to an FDataSnapshot /* Populate cell with contents of the snapshot */ } self.tableView.dataSource = self.dataSource
FirebaseUI can also be used to back a UICollectionView using the FirebaseCollectionViewDataSource.
FirebaseCollectionViewDataSource
If you want more examples, check out the iOS README, or see our iOS chat app example. The Appledoc is available here.
We're working on making mobile development as effortless as possible, so we're always looking for ways to improve development speed and reduce complexity. One major area that we hear a lot of developers struggle is around mobile authentication, which typically requires installation of third party SDKs and understanding lots of additional docs.
While we have login demo apps on Android and iOS that explain these processes, FirebaseUI 0.3 will incorporate a set of login helper classes and standard views to make adding authentication to your mobile apps simple.
Our long term strategy involves adding support for pagination, infinite scroll, and client side filtering. We'd also love to hear feature requests from you.
Do you want to see those features added faster? Are you excited about making Firebase apps easier to develop? Is writing quality code your passion?
We'd love to have your help building and maintaining these libraries. Please submit issues for bugs and feature requests on Android and iOS, and pull requests are always welcome.
Lastly, if you've built anything, don't be shy! Share your apps with us on Twitter @Firebase or in our Google Group--we're excited to see what you build.
Firebase is growing faster every day, and since joining Google last year, we've gained access to world-class infrastructure and scale. Today, we're announcing across-the-board price drops to lower the barrier to entry for Firebase, so developers everywhere can create extraordinary experiences for their users.
Here are the changes we've made:
We've heard from you that concurrents are confusing. So today, we're eliminating the need to worry about them… they're now unlimited for our Candle plan and above!
To prevent abuse, we're limiting simultaneous connections to a single Firebase to 10,000 by default, which is generally enough for applications with at least 100,000 daily active users. We can scale far beyond that limit, and users can contact us to permanently raise the cap with 24 hours notice.
Firebase is about giving people the tools to build extraordinary apps. Experimentation is core to what we stand for, and we believe people should be able to build non-trivial apps on Firebase for free.
Therefore, we are widening our free tier to:
In addition, you can now add a custom domain to your free app for only $5/month, with our new Spark plan. No more need to upgrade to the Candle plan just to get a custom domain!
Finally, we're increasing the resource limits on all our paid plans. The Candle, Bonfire, Blaze, and Inferno plans are all seeing big increases in database bandwidth and storage, up to 3x. We've also lowered overage fees to increase flexibility as your app scales.
Here's a full summary of the changes, and you can check out our new pricing page here:
It has been a pleasure building Firebase, and it's humbling to see the great things you build with us. We've got some great new features coming soon, and are more excited than ever for the future.
Happy Coding!
Today's EmberFire release includes new features that will make it even easier for Ember developers to connect their apps to Firebase. The EmberFire 1.5.0 release brings Ember Data 1.13.0 compatibility, integration with Firebase Authentication, and some updates for embedded records.
EmberFire is an adapter for using Firebase with Ember Data. It is packaged as an Ember CLI addon, which makes it incredibly easy to add Firebase as the backend for your Ember app. Using EmberFire, all of your models stored in Ember Data will be automatically synchronized with our remote Firebase database. Simply calling save() on a record will save it to the store and persist that data in your Firebase database.
save()
Ember Data has made it out of beta, which means we can count on a stable API. This is great news for EmberFire. In addition to 1.13.0 compatibility, we're working on staying up to date with the latest releases, and our tests are also passing for 2.0 canary!
You can now authenticate users in your EmberFire app with Facebook, Twitter, GitHub, and Google using our Torii adapter. Get started by enabling the authentication provider you’d like to use in your Firebase Dashboard, installing the Torii addon, and following the authentication section in our guide. Once you've set it up, you can authenticate a user inside your route or controller with the following snippet:
this.get("session").open("firebase", { provider: "twitter"}) .then(function(data) { console.log(data.currentUser); });
This snippet of code will authenticate a user with Twitter and log the returned user object to the console.
Many thanks to Matt Sumner for his work on this.
This release also changes the way embedded records are declared. If you have an embedded hasMany / belongsTo relationship in your EmberFire app, you should now follow the Ember Data conventions by configuring embedded record settings in a serializer. Visit the relationships section of our guide for details. Just be sure to use Ember Data 1.13.6+ for embedded records compatibility.
hasMany
belongsTo
If you're new to EmberFire, using it with your Ember CLI app is as simple as installing our addon:
ember install emberfire
Then, update your Firebase URL in config/environment.js and you're ready to persist your Ember Data records in your Firebase database. Check out our guide for a detailed walkthrough on all things EmberFire.
config/environment.js
We'd love to hear what you think of the latest release. Post any feedback in our Ember Google Group, or open an issue on GitHub. Contributions to EmberFire are always welcome, so feel free to submit a pull request if there's something you'd like to see added.
We're excited to see what you build with Firebase and Ember!
React and Firebase were made for each other. And with the introduction of ReactFire back in May 2014, we provided a simpler way to build apps using both technologies. Today we're announcing ReactFire 0.5.0 - the biggest update since that initial release. The update brings improved performance, a handful of bug fixes, and some extra features to simplify development.
For those who aren't familiar, ReactFire is a React mixin. The ReactFireMixin makes it dead simple to bind data stored in Firebase to a component's state. It handles both array-like and object-like data via the bindAsArray() and bindAsObject() methods, respectively.
ReactFireMixin
bindAsArray()
bindAsObject()
For example, say you have a list of messages stored in your Firebase database that looks like this:
{ "messages": { "-JqpIO567aKezufthrn8": { "uid": "barney", "text": "Welcome to Bedrock City!" }, "-JqpIP5tIy-gMbdTmIg7": { "uid": "fred", "text": "Yabba dabba doo!" } } }
You can bind the message data to your component's state by calling bindToArray() in your componentWillMount() method:
bindToArray()
componentWillMount()
var ExampleComponent = React.createClass({ mixins: [ReactFireMixin], getInitialState: function() { return { messages: [] }; }, componentWillMount: function() { var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com/messages"); this.bindAsArray(ref, "messages"); }, render: function() { // ... } });
The message data is now bound to this.state.messages. Whenever messages are added, removed, updated, or moved in Firebase, those changes are reflected automatically in this.state.messages
this.state.messages
this.setState()
render()
render: function() { var messages = this.state.messages.map(function(message) { return ( <li key={ message['.key'] }>{ message.uid } says { message.text } </li> ); }); return <ul>{ messages }</ul> ; }
The 0.5.0 release is the first major upgrade to the ReactFireMixin since its initial release. The API is still just as minimal, but a lot has changed under the hood.
The initial implementation of bindAsArray() was quite simplistic. It had poor performance and did not properly handle complex Firebase queries. The new implementation provides improved performance (especially on large data sets) and works well with all Firebase queries. Best of all, no changes to your code are required to enable these improvements.
Another major change with 0.5.0 is the addition of the .key attribute. ReactFire now adds the .key attribute to every record it creates via the bindAsArray() and bindAsObject() methods. In previous versions, it was impossible to retrieve key names for bound items. The 0.5.0 release fixes this by including the key name by adding a .key attribute to each bound item.
.key
As an example, let's look again at the messages array from above. The resulting bound array stored in this.state.messages will be:
[ { ".key": "-JqpIO567aKezufthrn8", // New in version 0.5.0! "uid": "barney", "text": "Welcome to Bedrock City!" }, { ".key": "-JqpIP5tIy-gMbdTmIg7", // New in version 0.5.0! "uid": "fred", "text": "Yabba dabba doo!" } ]
The inclusion of .key makes it possible to easily write data back to Firebase to update, remove, or move a record in the array. All objects synced via bindAsObject() now include the .key attribute as well.
Finally, version 0.5.0 changes how primitive values (strings, numbers, booleans) are handled. As an example, say you have the following data in your Firebase database:
{ "foo": "bar" }
If you call bindAsObject() on the /foo/ path, previous versions bound the value as a string "bar". As of today's 0.5.0 release, the bound object now looks like this:
/foo/
"bar"
{ ".key": "foo", ".value": "bar" }
You have access to the key that was bound to (.key) as well as the bound value (.value). Primitive values bound via bindAsArray() behave in the same way with the primitive value being stored in .value. Non-primitive values (that is, regular JavaScript objects) have not changed and behave in the same in all versions, except for the addition of .key.
.value
There is a lot of excitement in the React community about ES6+, Relay, GraphQL, and ReactNative. Discussions about these topics are even ongoing in the ReactFire GitHub repo. We are following the new announcements and technologies closely. Since we use React in production at Firebase, we want the two technologies to work as well as possible together.
We've found that using the vanilla React and Firebase libraries together works great and somewhat replaces the need for an application architecture like Flux. Things like ReactFire simplify development further by providing a shorthand for a lot of common use cases. And community contributions like the recently released re-base library show how well Firebase can fit into new technologies like Relay. The future of a React + Firebase application tech stack is exciting and promising. The two technologies make it that much easier to build scalable apps in a fraction of the time they traditionally have taken. You can expect ReactFire to evolve alongside React over the course of the comings months.
re-base
The best place to get started with ReactFire is by heading over to the docs. We have a five minute quickstart, a guide which walks you through making an example app, and a full API reference with more examples of binding data via bindAsArray() and bindAsObject().
If you run across any bugs or have feature suggestions, please file them on GitHub. If you have questions about the API or how to build apps with ReactFire, post them on the Firebase Google Group.
We are excited to see what you create!
