flutterfire
flutterfire copied to clipboard
firebase
[📚] The docs should return the manual setup since the CLI doesn't cover flavors
As shown in this issue the CLI doesn't support Android Flavors and Dimensions or iOS Schemes and Targets, so we can't use the CLI to setup our Firebase projects.
Until recently the setup docs included manual instructions and automated instructions, but now there's only the automated option through the CLI, leaving everyone with flavors/schemes incapable of adopting Firebase with Flutter, or updating the libraries to get the benefits, like better Crashlytics behavior with Flutter.
I believe the manual configuration option should return while the CLI doesn't cover this use cases.
@feinstein @darshankawar is this correct? If this is correct this influces whether flavors should be used at all imho. Is there any documentation about best practice about if flavors are "critical" or if environment switcher and specific crashlytics/analytics urls and filtering are sufficient?
@neiljaywarner there are situations where flavors are critical. Imagine a project that needs a Cloud Firestore data base for production and another for development, or as in my case, several whitelabel apps that share the same code, but only have different names and package ids, so we would need to configure FlutterFire to deal with all the 4 android apps that use that same project, and not only one Android app.
Unfortunately there aren't many official guidelines, although you can find lots of recommendations online, but here's one of the offcial docs
right, but the question is how many of those use cases would be taken care of by a quick change at runtime, yes that would have some disadvantages (eg crashes on launch) but maybe some simplicity especially if ther'es issues with dart-only initialization..
On Thu, Jun 30, 2022 at 8:29 PM Michel Feinstein @.***> wrote:
@neiljaywarner https://github.com/neiljaywarner there are situations where flavors are critical. Imagine a project that needs a Cloud Firestore data base for production and another for development, or as in my case, several whitelabel apps that share the same code, but only have different names and package ids, so we would need to configure FlutterFire to deal with all the 4 android apps that use that same project, and not only one Android app.
Unfortunately there aren't many official guidelines, although you can find lots of recommendations online, but here's one https://firebase.google.com/docs/projects/multiprojects of the offcial docs
— Reply to this email directly, view it on GitHub https://github.com/firebase/flutterfire/issues/8918#issuecomment-1171829240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXBGYLZ23EHGAZH4J23ZM3VRZCWDANCNFSM5Y4TA4NQ . You are receiving this because you were mentioned.Message ID: @.***>
Well, do you see how this would be possible for my use case?
I have 6 different white label apps (and growing), that I want to share the same Firebase, so I can have all the Crashlytics and remote configs at the same place.
Also, I want them to have a separate environment for development and production.
This works fine right now, and that's a functionality that Firebase supports, I am not inventing anything new, Firebase allows me to connect as many Android apps to one project as I want, so why the CLI shouldn't support something that Firebase already supports?
Also, there are many production apps like this, should we try to see how to change them all? How about data migrations for all of them?
I think it's simpler to just change the CLI, and while it doesn't get fixed, we rollback the manual configuration tutorials.
Yes, I agree. I'm just trying to evaluate
....sent from my phone
On Thu, Jun 30, 2022, 9:11 PM Michel Feinstein @.***> wrote:
Well, do you see how this would be possible for my use case?
I have 6 different white label apps (and growing), that I want to share the same Firebase, so I can have all the Crashlytics and remote configs at the same place.
Also, I want them to have a separate environment for development and production.
This works fine right now, and that's a functionality that Firebase supports, I am not inventing anything new, Firebase allows me to connect as many Android apps to one project as I want, so why the CLI shouldn't support something that Firebase already supports?
Also, there are many production apps like this, should we try to see how to change them all? How about data migrations for all of them?
I think it's simpler to just change the CLI, and while it doesn't get fixed, we rollback the manual configuration tutorials.
— Reply to this email directly, view it on GitHub https://github.com/firebase/flutterfire/issues/8918#issuecomment-1171849510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXBGYP6FNPNUTLJLCA5FVLVRZHTPANCNFSM5Y4TA4NQ . You are receiving this because you were mentioned.Message ID: @.***>
I am on that thread as well, I linked it in my first comment. I opened this issue so the docs could be updated in the meantime, and people have an alternative configuration.
I'm closing this out now, if you wish to see documentation for different build types + variants (flavors), please see the documentation on the FlutterFire CLI here: https://github.com/invertase/flutterfire_cli#documentation-for-v030-dev19