I've been rewriting the Kids In Touch app to use Firebase as my backend. As I've plodded along, I've come across a few ideas that I think would make good features to add to Firebase.
Today, I made a feature request to Firebase for an API to store information only locally. The support rep asked for an explanation of why I would need such a feature. Basically, it would allow you to write to local storage only using the Firebase client. That way you don't need to roll your own Local Storage or integrate a third party library.
Here it is. If you think it would be useful, please let Firebase know.
Local Storage Only Option
For my app, a single "account" can have multiple users. Those users can share a single device or each user their own device. The account for all these family members is the "uid". To store specific information about a particular device, I COULD have a Firebase reference like this:
account id (uid)
- device-guid-1
- Device details
- device-guid-2
- device details
All of that works great. However, to access those records, the client must know it's own device guid. If an app is opened, I can generate the device-guid, write to Firebase, and query that specific guid at will between pages. If the app is backgrounded and then re-opened, I can still query that device-guid record in Firebase because the device-guid is still in memory. However, if the app is completely closed and later reopened, the previous device-guid will not be available. Now, I can't query Firebase for the previous settings. To work around this, I can store the device-guid locally in Local Storage. Then, I can query it in Firebase. This works well. However, it means I need two storage mechanisms. If Firebase had a "local only" option, the device guid could be stored "permanently".
"Permanently" : Local storage is of course not permanent as you mentioned. However, it's surprisingly durable. Many hybrid apps use local storage exclusively. Firebase uses local storage on the device and the browser. My current app uses Local Storage exclusively. I've never had my local storage flushed by the device in almost a year.
So, my idea would just make it easier for developers to use a single Firebase API for all their storage needs instead of having to juggle two. I can even see this as a way to offer Firebase for free and then upsell developers.
Example : The Firebase client software is VERY easy to use. It's much easier to use than many Local Storage options or rolling your own. So, offer the client with the ability to do local storage only. You might entire a lot of developers to use Firebase just for that need. However, once the start using it, they'll see the possibilities of the real Firebase service. Then, it's an easy path to charging for a real Firebase collection.
Code Sample :
var ref = new Firebase('my-firebase-url-here/deviceGuid');
var devSync = $firebase(ref);
devSync.$setLocal('219e7b96-6f7a-473b-aba5-6ee78821f13f');
...
var deviceGuid = devSync.$getLocal();
// Perhaps it could even have local syncing like the real firebase.
devSync.onLocal('value', function() {
// Something here
});
Code Sample with localOnly option passed on initialization so the methods stay the same:
var ref= new Firebase('deviceGuid', { localOnly : true });
var devSync = $firebase(ref);
devSync.$set('219e7b96-6f7a-473b-aba5-6ee78821f13f');
...
devSync.on('value', function() {
// Something here
});