Okay, now I get the point of using log outputs.

You can find a video of this at the bottom of the page and a link to the source code here.

I added a Value Event Listener to the Database Reference object myRef. I ran into some issues with the Log.d() debug method, but I found another way to confirm changes using updates to the app UI.

Picking up where I left off, I invoked the addEventListener() method on myRef. Like before, I copied code from the Firebase website. That’s when I hit a wall with a statement involving the Log class.

According to Android Studio, the TAG argument in the Log.d() debug method has private access in the FragmentActivity class. (click below)

I returned to the Firebase website to see if I missed anything. After opening the MainActivity example class on the page, I found the TAG argument was in fact a private Static String variable used for searching the debug logs after running my app.

The TAG variable contains a String corresponding with the beginning of the output in the debug log. In this case, it read MainActivity (click below)

After updating my code, it worked as expected. I played around with this app and also included code which would update the default Hello World TextView in the MainActivity with the value read from the database. (click below)

I learned two things today. First of all, the debug log is useful for locating areas of code which might not work as expected. Second, updating the UI is not the only way to confirm changes to my code. Different tasks require different tools, but both seemed effective for the task at hand.

Next I will look into reading the database into a ListView. It shouldn’t be too different from what I’ve seen today. There’s probably a method which gets all the data from the database instead of a snapshot of a single value. We’ll just have to see for ourselves!

Join the mailing list to see updates like this every week!
Coding Fanatic