In previous posts (here and here), I have discussed my Google Sheets solution for interfacing with Firebase’s Realtime Database. I am working on an Android app that relies on some content managers, and the familiar spreadsheet interface of Google Sheets provides them with an easy way to edit content that will appear in our app, and the added structure of the spreadsheet along with a custom Google Apps Script gives me peace of mind that everything is being properly formatted in the database.
When Firestore was announced, I wanted to migrate to it ASAP (being able to use multiple “where” clauses in a query would be so nice!). However, in order to do so, I need to re-work my spreadsheet so that it writes to Firestore instead of the Firebase Realtime Database (which I’m going to call RDB from now on).
My spreadsheet relies on an unofficial Google Apps Script library for interfacing with the Firebase RDB. Since Firestore is so new, it appears that no such library exists for it yet. So I decided to start writing one.
In this post, I’m going to go over some details for authenticating a service account (so that my spreadsheet can be authorized to make edits) and writing to Firestore using the Firestore REST API in a Google Apps Script.Read more...
This is the second post in a series about using Firebase as a backend content management system that faces people who are not developers. The first post in this series is over here.
I have an app that uses Firebase for its backend. The app is a platform for lesson plans, and the lesson plan content is managed by a non-developer. In my last post, I discussed how I set up our Firebase server to be more consistently structured and more familiar by using Google Sheets as the primary entry point for content managers.
There’s another feature from Firebase that the app’s content managers use, though: Firebase Notifications. Firebase Notifications are a super easy way to send push notifications to your app, and we use them to send tips and updates on the lesson plans to the teachers who use the app.Read more...
In the months following Parse’s shutdown announcement, I was in school and was putting off the migration of my current Android app that utilized Parse. I didn’t want to have to host my own Parse server, but it was looking like that was my only option. However, in May, the solution arrived: Google’s Firebase service underwent a major upgrade.
Before even beginning with Parse, I had considered using Firebase as my backend-as-a-service provider. The problem was that my app requires file storage, which Firebase didn’t offer and Parse did. However, the new Firebase does have file storage, which allows me to easily download server-side data in my app.
Although server integration is essential to my app, the integration itself is not particularly complex or messy. That is, it wasn’t a problem to switch all the models and adapters to use Firebase instead of Parse. After a day of refactoring, I was completely out of Parse’s ecosystem and into Firebase’s.
Now, the key part about my app’s database is that the data is maintained by my client (an education group), not by me. The app is a platform for lesson plans, and my client manages the lesson files and information that gets uploaded to the server. As the content managers are not programmers, the familiar, spreadsheet-style Parse Dashboard was very useful for us. It was very intuitive to add new rows to the sheet to add a new lesson.Read more...