Question about Two Different initializeSecondaryApp Functions and Firebase Auto-Initialization in React Native

[aman32767]

Description:
I have been reviewing the source code for the ReactNativeFirebaseApp class in the Firebase library for React Native, and I've come across an interesting design choice involving the initializeSecondaryApp functions. There are two versions of this function with slightly different signatures, and I'm seeking clarification on the reasoning behind this design.

In the provided source code, there are the following two initializeSecondaryApp functions:

1. initializeSecondaryApp(String name):

   • Takes one argument, the name of the secondary Firebase app.
   • Relies on the applicationContext that was previously set using the setApplicationContext method.
   • Uses FirebaseOptions.fromResource(applicationContext) to obtain configuration options for the secondary app.

2. initializeSecondaryApp(String name, Context applicationContext):

   • Takes two arguments: the name of the secondary app and a specific applicationContext.
   • Allows for the specification of a custom applicationContext if needed.
   • Also uses FirebaseOptions.fromResource(applicationContext) to obtain configuration options for the secondary app.

My questions are as follows:

• Why are there two different functions for initializing secondary Firebase apps with these slightly different signatures?
• Is there an equivalent function for initializing the primary Firebase app (initializePrimaryApp)?
• Does Firebase automatically initialize itself in a React Native app, and if so, where in the source code does this automatic initialization occur?

I believe that understanding the purpose of these two initializeSecondaryApp functions and the automatic initialization process, if it exists, would be valuable for developers working with Firebase in a React Native environment. It can help ensure proper configuration and usage of Firebase within our apps.

[mikehardy]

As background information, react-native-firebase is a wrapper to the native firebase-android-sdk and firebase-ios-sdk, and as a wrapper it is as thin as possible. The primary goal is to expose those native SDKs to the react-native ecosystem, with an API as close as possible to the firebase-js-sdk (since react-native is javascript...) but while also exposing the extra native capabilities having truly native SDKs (versus just javascript).

So that's the goal of the package.

That also brings constraints (since the native SDKs do have some constraints)

First constraint: the native SDKs require the primary firebase app ([DEFAULT]) to be configured natively. In Android that is with a google-services.json file that the android play services plugin carries into a special resources/XML file and on iOS that is with a GoogleServices-Info.plist file that is carried at build time into the right place.

At application startup in the native code (before the react-native javascript layer even exists) the Firebase system starts, reads that configuration information, creates the default app and starts doing useful things like 1) monitoring for crashes with crashlytics, 2) instrumenting for performance, 3) measuring for analytics, 4) listening for initial startup notifications and messages and links - these are all native activities that you get with the native SDKs that the JS SDK does not provide.

Okay, so javascript context does not exist yet but we already have our primary / default app configured and Firebase is running.

Now react-native finishes booting up and initializing and you finally get the chance to start running your react-native javascript project code. What can you do?

Well, if you like, since we do have the power of the native SDKs, you may have some other firebase project configured via XML and you may load that as a secondary app. Those are the APIs you mention.

Your questions:

1. why are there two different functions? Honestly, I'm not really sure. This code hasn't changed in years and years and the reasons are lost to time. They appear to be very similar, and not many people use secondary apps at all much less configure them natively, so they are both probably used by 5 people out of the tens of thousands using firebase, and which API those 5 people chose is probably whichever they got to work first. It likely doesn't matter much to them, and compared to how most people use firebase it almost doesn't matter at all

2. No. Based on the background information above, hopefully there is enough context to explain why. The primary app is configured from native config files (json or plist for android or iOS) because that configuration must happen prior to any javascript context being available. If you must initialize your primary app from javascript, you must use firebase-js-sdk and you will not be able to use react-native-firebase

3. It does, again, hopefully with enough background information above as to why. Where does it happen? In iOS it happens when you add that configure API call in your AppDelegate file. In Android it happens via the Android "provider" functionality that instantiates at app startup, defined here https://github.com/firebase/firebase-android-sdk/blob/879c84bb4ae02b9b6923d3ae0620c97c63bae10d/firebase-common/src/main/AndroidManifest.xml#L22-L27 - after iOS and Android are configured using native mechanisms via those pathways, Firebase is running with a primary app, and the rest of react-native-firebase is initialized in a fairly standard way via react-native's auto-linking mechanism which discovers and connects modules at install/build time and loads them at app startup

Hope this helps

[aman32767]

Thank you very much, Mike, for this. It has been incredibly insightful, and I now have a clear understanding of how things work.