Reputation: 6675
Just a simple question today. Is there a downside to calling FirebaseApp.initializeApp twice?
We use the urban airship sdk which handles the init but we noticed some crashes coming in from background services because FirebaseApp.initializeApp was not called.
My solution is to put FirebaseApp.initializeApp in our application class. Just want to make sure this won't cause any issues with an SDK making the same call.
Thanks in advance!
Upvotes: 1
Views: 609
Reputation: 317322
You can see what FirebaseApp.initializeApp does by command- or control-clicking into its implementation in Android Studio:
public static FirebaseApp initializeApp(Context context) {
Object var1 = LOCK;
synchronized(LOCK) {
if (INSTANCES.containsKey("[DEFAULT]")) {
return getInstance();
} else {
FirebaseOptions firebaseOptions = FirebaseOptions.fromResource(context);
if (firebaseOptions == null) {
Log.d("FirebaseApp", "Default FirebaseApp failed to initialize because no default options were found. This usually means that com.google.gms:google-services was not applied to your gradle project.");
return null;
} else {
return initializeApp(context, firebaseOptions);
}
}
}
}
As you can see, if the default app was previously initialized, its instance is returned, and nothing else happens. So, if there is a downside, it's that you've just done unnecessary work.
But you shouldn't ever have to call it manually if you performed the standard integration, as it will be invoked automatically a startup via a ContentProvider that will initialize before any other Activity or Service. You can read more about that in this blog.
Upvotes: 3