As a GDE, I have been part of early access to the new Firebase, which was publicly announced today at Google I/O. I saw a big potential in these tools and since we needed a redesign anyway, I decided to rewrite Settle Up for Android, iOS and Windows from scratch. We have already been working with the new Firebase for several months now and I would like to share our experience with it.
Firebase Realtime Database
I wrote the current version of Settle Up’s backend on AppEngine. It works well and it’s quite efficient. But there are some quirks. Synchronization during an unstable connection is a difficult problem. In rare cases expenses might not synchronize which then might result in the loss of users’ trust. And debugging the synchronization takes a lot of time.
Realtime Database solves this problem — synchronization is completely managed by the service and it’s battle-tested. The bonus is a nice realtime UI. As long as a user is inside the app, the changes coming from other devices are instant. Goodbye manual syncing!
Realtime Database removes the need for another huge part of our former codebase — offline support. Firebase SDK automatically caches data on the disk, including new entries. The UI layer handles both offline and online data the same. This greatly simplifies the code. On the other hand, it wouldn’t hurt to know which data are offline so we could show that to the user.
We have been testing the performance of Firebase with thousands of expenses in one group. We did not find any performance issues and offline/disconnecting behavior works as expected. You can try that yourself by installing our prototype. We have been iterating a lot over the structure of our data in Firebase. Here is our structure for your inspiration.
Moreover, Realtime Database also provides REST API by default. Ultimately, Firebase removed the need for a backend developer in our team.
Firebase Dynamic Links
We plan to simplify inviting users to Settle Up groups. Goodbye e-mails, hello links! Users can flexibly share the link via any app they prefer. And they don’t need to know their friends’ emails or phone numbers.
And Dynamic Links are made just for that. We have tested it and it works as expected — you can generate the link offline and it works both for Android & iOS. On the other hand, the link is quite long and cannot be easily shortened. On the web it sends the user to our web app, on the phone it goes either directly to the app or to the Store. Right after the installation, the new group member is taken straight to the group. A magical experience!
We will use Storage for saving users’ receipts. It’s pretty similar to Google Cloud Storage, but with nicer pricing. It works well, and we have found no surprises or obstacles.
We will support Google, Facebook and e-mail/password login in the new Settle Up. The integration was mostly painless, and I really like the e-mail/password support. Finally, somebody has written this boilerplate that almost every app needs.
Other Firebase features
Firebase Cloud Messaging is pretty similar to Google Cloud Messaging, no surprises in the integration. It comes with a nice console which we can use later for engaging users via notifications.
Crash Reporting works nicely without any change to the code at all. The reports are a little less detailed than Crashlytics, but we will probably switch to it just to have everything in one dashboard.
Same with Analytics — we will switch from Google Analytics to have everything in one dashboard.
We already use Hosting for hosting static HTML file of our new web app. No surprises here, Firebase has supported this for a long time. I really like its user-friendly command line tool for deployments.
We will probably use Remote Config for A/B testing, but we haven’t played with that yet.
We have already used Test Lab for testing our last Android update. It works well, we have only tried monkey tests though. I guess it will be even more useful when we have some UI tests. It will remove the need to buy many physical devices for our company.
We have a solid architecture for the whole code. We have chosen MVP for structuring the code. Realtime Database is accessible to the rest of the code via RxJava. It would be nice if the SDK provided Rx bindings, but it’s not hard to write that one class. Yeah and everything is written in Kotlin, because we love it! I will go deeper into this topic during my talk at mDevCamp conference in June.
I’m excited about the new Firebase. It solves a lot of pain points and common tasks for many apps. The developer experience is on a different level than previously separate Google tools. I’m confident that we will be able to migrate our apps to this new platform. And about that redesign, here is the first concept of our new Android UI: