Eureka! 💡

One of the services that I use to make app making easier is Firebase🔥 . It’s backed by Google, and in a nutshell it lets you write software without having to deal with a lot of the complexities that would normally come with it. It handles your database, authentication, analytics, and a ton of other stuff that look like they’d be a pain to write. To give you an idea, last summer I spent a week trying to figure out how to use a local SQL database on Android. With Firebase, I set up a realtime database in the cloud, with local redundancy so the app would work without internet, within just a few hours.

That being said, sometimes there’s a tradeoff for all of this simplicity. The offline redundancy of the database only takes one line of code to set up, but erasing the cache is nearly impossible, and one of the most powerful features, the realtime part of the database, is not as simple as it seems. For the past few months I’ve been trying off and on to fix the same stubborn bug. I’d press a button in my app to add to a list of data, which would run methods to push it to Firebase (and theoretically detect a change in data and update the local list), then I’d run methods to update parts of the UI to reflect the new data.

//   sets the positive button
           .setPositiveButton(dataPointMethods.getAddDataButtonText(), new DialogInterface.OnClickListener() {
               public void onClick(DialogInterface dialog, int id) {
                   //                logs the data
                   dataPointMethods.logData();
                   DistanceManager.calculateActiveDistances();
                   ((MainActivity)getActivity()).updateCompassDisplay();
                   closeDialog();
               }
           })
//    logs data to Firebase
public void logData(){

    //        Creates new Water object
    int numberOfGlasses = 1;
    Water water  = new Water(numberOfGlasses);
    DBManager.dbRef.child(DB_DATA_ROOT).push().setValue(water);

}

All the data was stored properly, but the UI wouldn’t update how it was supposed to unless I added some data again. Turns out, I was overestimating the “realtime” part. Firebase has this really cool way to retrieve data using something called a ValueEventListener. It pulls what you want from the database, and then runs your code to put it wherever you decide. What’s cool about it is that it will do this every single time the data changes! So keeping this in mind, I figured I’d avoid doubling my code by just counting on my ValueEventListener to update my lists locally.

My ValueEventListener:

dbRef.child(WATER).addValueEventListener(new ValueEventListener(){
// some code that updates my local lists.
}

What these three snippets were actually doing:

Firebase saves you a lot of time by handling threading for you, and it handles it so well that you kind of forget it’s a thing you need to consider! It’s definitely worth using, especially since it lets you spend more time making the interesting parts of your project, but it has its quirks sometimes.

Alright, lets get back to coding! 😉

2 thoughts on “Eureka! 💡

  1. PantsStatusZero says:

    I don’t remember how promises (or await/sync/deferred) work in Java, but it’s a common issue with databases that you have to send or request something then wait until the db is done doing something before updating the UI. Note: promises are deep down the rabbit whole.

    • JCLaHoot says:

      In my case it was doing a pointless DB read when I should have just bypassed that locally. Now it’s working great though 😀 The instant feedback is really cool!

Leave a Reply