Async Initialization In Unity with Firebase
Recently I was working on an app that utilizes Firebase’s Realtime database and encountered a simple async issue that I initially was over-thinking, but ultimately resolved with ease.
My hope is that you find this simple solution valuable whenever you need to wait on conditions to change, before handling your data during initialization.
My Problem
The app requires GPS location services coupled with real-time data, but the key is that when the data is processed, I need to know where the user is located in order to properly handle how the data is processed. If the data comes in before I get the coordinates, then I will have to create a redundant flow to re-process what arrived ( yuck ), if the coordinates are there before the data, then all is well.
I initially sought to use Tasks, or 3rd party plugins that handled async and await, but wasn’t happy with how overly complicated the implementation was to get going.
There must be a better way…
My Approach
As you can see below, its a basic Start method, but I changed it to be an async Start() and I awaited the Firebase dependency check, this ensured that whatever needed to happen with Firebase went through before I did anything else. Then, I ran a common coroutine after everything was in place.
My ultimate problem centered the fact that when the database is initially read, all ChildAdded listeners will fire off and bring in my data one at a time. During development testing I was seeing the coordinate data would validate before the data arrived so sometimes, it seemed as if there was no problem. Eventually, it ended up being about 80/20 that the data would come in before the coordinates.
So we have a proper setup that waits for things to happen before other things happen, but what about waiting on the GPS coordinates to validate?
Simple, we add in a while loop that monitors whatever condition you want to watch for, yielding every second to see if it changes.
A very simple solution to a common problem, I just never considered to use an IEnumerator in this way before. I found this approach preferable to writing a loop checker inside of Update, as I really needed things to be in order before I got to that point.
Summary
The trick that I knew I needed to figure out was someway of waiting on data to change before bringing in my data. I hated the idea of re-processing my data after I missed the window where the data comes in line by line — which by the way, was a beautifully clean way to handle my data as opposed to batch processing it all at once. The real goal here was to take care of all of my data during initialization, not after.
IEnumerators yield for something to happen before returning completed, and can easily WaitForSeconds(x), so simply tying together 2 coroutines gave me what I needed. One waits for a variable to change, and the other that waits on the first to complete before doing something else. Of course this could easily be handled in 1 coroutine, but this code went across 2 different classes and I felt this approach was cleaner.
What are your thoughts?