Storing and iterating arrays comprises a good portion of the Firebase questions on StackOverflow. This article will explain Firebase's array support, the ins-and-outs of arrays in distributed data, and some common techniques for dealing with array-like data.
First, let's get a handle on the current array support.
Firebase has no native support for arrays. If you store an array, it really gets stored as an "object" with integers as the key names.
// we send this ['hello', 'world'] // Firebase stores this {0: 'hello', 1: 'world'}
However, to help people that are storing arrays in Firebase, when you call .val() or use the REST api to read data, if the data looks like an array, Firebase will render it as an array.
.val()
In particular, if all of the keys are integers, and more than half of the keys between 0 and the maximum key in the object have non-empty values, then Firebase will render it as an array. This latter part is important to keep in mind.
// we send this ['a', 'b', 'c', 'd', 'e'] // Firebase stores this {0: 'a', 1: 'b', 2: 'c', 3: 'd', 4: 'e'} // since the keys are numeric and sequential, // if we query the data, we get this ['a', 'b', 'c', 'd', 'e'] // however, if we then delete a, b, and d, // they are no longer mostly sequential, so // we do not get back an array {2: 'c', 4: 'e'}
You can't currently change or prevent this behavior. Hopefully understanding it will make it easier to see what one can and can't do when storing array-like data.
So why not just store arrays instead of objects?
I bet that got your attention. Actually, arrays are quite handy. But for distributed data, they aren't reliable because they lack a unique, permanent way to access each record.
Consider the case where three clients attempt to modify an array on a remote service like Firebase:
[ {name: 'foo', counter: 1}, {name: 'bar', counter: 1}, {name: 'baz', counter: 1} ]
data[1].counter++
The end result is that record 'foo' is deleted, and the counter for record 'baz' is incremented, while the now incorrect 'bar' sits at position 0. None of the operations worked quite as intended.
If the data were instead stored as an object, keyed by unique ids, the scenario would look more like this:
{foo: {counter: 1}, bar: {counter: 1}, baz: {counter: 1}};
Now the operations resolve in a sensible manner, despite concurrent updates from multiple clients. This isn't possible with an array, where the indices used to reference each record are fluid and change over time.
However, we couldn't just pick up the bar record and move it to the front of the list. What we need is a convenient way to create unique ids, such as a hash or object's keys, while still having a defined ordering for the records.
bar
In Firebase, this is done with push ids and priorities.
Firebase's solution to the problem of unique identification is the push method (note that this is named childByAutoId in iOS).
Like JavaScript's push method, this appends new records to the end of our collection. It does this by assigning a permanent, unique id based on the current timestamp (offset to match server time). This means that each record is naturally sorted at the end and that they maintain a chronological order.
var ref = new Firebase(URL_TO_DATA); // this new, empty ref only exists locally var newChildRef = ref.push(); // we can get its id using key() console.log('my new shiny id is '+newChildRef.key()); // now it is appended at the end of data at the server newChildRef.set({foo: 'bar'});
Firebase provides a set of tools for ordering data at the server level. By using setPriority or setWithPriority, it's possible to specify the order in which records are stored and retrieved. A classic example of this is a leaderboard, where results are stacked by highest score.
var scoresRef = new Firebase(URL_TO_SCORES); var score = 10000000000; // enough to put me in the #1 position! // we sort the scores in descending order, so use a negative score for the priority ordering scoresRef.child('kato').setWithPriority( score, -score ); // retrieve the top 10 scores scoresRef.limitToLast(10).once('value', function(snap) { var i = 0; snap.forEach(function(userSnap) { console.log('user %s is in position %d with %d points', snap.key(), i++, snap.val()); }); });
But what about client-side sorting, such as by table heading, and other ops that really just don't work with objects? There are times when nothing but an array will do.
If all of the following are true, it's okay to store the array in Firebase:
// initial data: [ {name: 'foo', counter: 1}, {name: 'bar', counter: 1}, {name: 'baz', counter: 1} ]; var ref = new Firebase(URL_TO_LIST); // sync down from server var list = []; ref.on('value', function(snap) { list = snap.val(); }); // time to remove 'bar'! // this is the correct way to change an array list.splice(1, 1); ref.set(list); // DO NOT DO THIS! It will eventually turn the array into an object // and may result in null values for deleted indices // ref.child('1').remove();
In Java, if we know that the data is array-like, it can be cast as a List:
Firebase julieRef = new Firebase("https://SampleChat.firebaseIO-demo.com/users/julie/"); julieRef.addValueEventListener(new ValueEventListener() { @Override public void onDataChange(DataSnapshot snapshot) { GenericTypeIndicator<List<String>> t = new GenericTypeIndicator?<List<String>>() {}; List messages = snapshot.getValue(t); if( messages === null ) { System.out.println('No messages'); } else { System.out.println("The first message is: " + messages.get(0) ); } } // onCancelled... });
In Objective-C, array-like data is easy enough to iterate. However, some use cases, such as Table View, require the use of NSArray. It can be obtained with a simple type cast:
Firebase *julieRef = [[Firebase alloc] initWithUrl:@"https://SampleChat.firebaseIO-demo.com/users/julie"]; [julieRef observeEventType:FEventTypeValue withBlock:^(FDataSnapshot *snapshot) { if(snapshot.value == [NSNull null]) { NSLog(@"No messages"); } else { NSArray *messages = [snapshot.value]; NSString *firstMessage = [messages objectAtIndex:0]; NSLog(@"First message is: %@", firstMessage); } }];
What if we want shiny arrays, and still want to have all the power of real-time collaboration? Well Firebase is about building amazing real-time apps so surely we can have both!Check out Synchronized Arrays in Firebase to learn more about this advanced technique.
Find this article useful or have additional questions? Leave a comment below or post a message on the mailing list!
