FlutterFire Roadmap

[Salakar]

Hey all 👋

Today I’m excited to announce the upcoming changes and roadmap for the FlutterFire plugins.

The overall mission of FlutterFire is to provide a set of high quality set of plugins for developers to allow them to build Flutter apps using Firebase. As Flutter grows, we want to ensure that the FlutterFire plugins grow with it, including Web support and enabling the possibility to support other platforms such as Desktop.

We’ve recently started a triage of repository issues to understand the current state of the repository, and get a feel for the biggest pain points and challenges developers are facing. The triage has enabled us to focus our efforts on bringing the library to production ready quality along with overall quality of life updates to FlutterFire.

Our top priorities are to introduce a dedicated documentation website, review each plugin in importance order (based on usage & current state) and tackle critical issues (such as slow Cloud Firestore build times).

As we review each plugin by group, we’ll be focusing efforts on the following areas:

• Testing: covering the public API (as much as possible) with dedicated unit and integration tests is incredibly important to us, so we can be confident in adding new features, squashing bugs and opening up the repository to more external contributors.

• Supporting Federated Plugins: we want to ensure that all plugins can be integrated with the platforms Flutter supports. Right now only 4 plugins are Federated (Core, Cloud Firestore, Analytics & Cloud Functions). As we move forwards, each plugin will be converted into a Federated setup to allow other platforms to integrate with FlutterFire.

• Documentation: although the reference API is a great place to understand the plugins, the goal of FlutterFire is to allow developers of all backgrounds and experience to get up and running with as little friction as possible. We’ll be providing documentation on how to setup Firebase with your Flutter apps, get started with using each plugin within your app and guides on addressing how the plugins can integrate with the wider Flutter & Firebase ecosystems, helping to reduce the barrier to entry when working with the plugins.

As explained, we’ll be tackling the plugins in importance order. As it stands, the ordering is as follows:

1. 🟢 Core
   Status: complete, merged & stable release shipped.
2. 🟢 Cloud Firestore
   Status: complete, merged & stable release shipped.
3. 🟢 Authentication
   Status: complete, merged & stable release shipped.
4. 🟢 Crashlytics
   Status: complete, merged & stable release shipped.
5. 🟢 Cloud Storage
   Status: complete, merged & stable release shipped.
6. 🟢 Cloud Functions
   Status: complete, merged & stable release shipped.
7. 🟢 Cloud Messaging (FCM)
   Status: complete, merged & stable release shipped.

We’ve yet to decide on the order of the remaining plugins, we’ll update you as we progress. Also, the Google team are heavily engaged with the AdMob plugin and will continue to maintain that as a top priority in parallel with this work.

We want to ensure that all plugins are interoperable as we work through them, allowing developers to see the benefits from the on-going work as soon as they are available. Therefore we’ll be doing some immediate changes across the board which will allow the newly updated plugins to be “backwards compatible” with plugins that have not yet been updated as part of this process.

To achieve this, we’ll be updating all FlutterFire plugins with the following top level changes:

• Dependency on Core: The most significant change is to configure every plugin to have a hard dependency on firebase_core. This will both help reduce installation steps, improve API consistency and follow conventions of the Firebase SDKs.

• Fixed Firebase SDK versioning: all plugins will be set to a fixed version of the underlying Firebase SDK (however will be overridable if desired), allowing us to be confident developers will be using the same SDK versions we’ve tested against.

• Consistent public API: developers coming from other platforms should be familiar with the public API FlutterFire offers, so we’ll work on bringing the API in-line with the Firebase APIs (where possible). See the Dart design style guide to learn more.

• Reducing installation steps: installing and getting started with FlutterFire should be as painless as possible. We’re working towards reducing the amount of manual setup steps required to integrate the plugins.

• Adding missing features: the issue triage and API review has highlighted a number of missing features which will be implemented as part of the plugin updates. In general if the underlying platform Firebase SDK supports a feature cross-platform then so should FlutterFire.

These changes will introduce a number of breaking changes, though we’ll do our best to keep these to a minimum and ensure that the documentation provides full change logs & migration guides to help make the upgrade as painless as possible.

We’ll be updating this issue as we progress through the upgrade to the plugins so please check back regularly.

---

The following GitHub users will primarily be focusing on this work going forwards:

• @dackers86
• @Ehesp
• @helenaford
• @kirstywilliams
• @russellwheatley
• @Salakar

If you have any urgent issues / pull requests that you feel you would like us to look at sooner - feel free to tag us in using the @FirebaseExtended/invertase GitHub team and we'll try our best to look at them as soon as possible.

---

Flutter blog post announcement: Flutter Package Ecosystem Update

New Flutter Favorites, Apple Sign In, and bringing prerelease Flutter plugins into production

---

If you're on Twitter, we'll be tweeting regular updates on the @FlutterFireDev account - feel free to follow along there also.

[slightfoot]

I have been working a lot recently with Flutter Web with Flutter Fire plugins and have found a few issues that I would like to raise concerns over. Just to impart the view-point/knowledge. I'll let you do what you will with the info.

1. Federated Plugin Interfaces
   I had a bug the other day because the confirmPasswordReset function of firebase_auth was not implemented on the web package. I found it weird that it even happened. Turns out that the base class for the Platform Interface implements all the functions and marks them to throw Unimplemented. I think this is unacceptable. It's the platform specific implementations job to mark a function as unimplemented and not the base class, or as functions are added to the interface we don't know which platform implementations have that feature. This is what happened with this simple use-case. I feel this design decision should be looked in to further.

2. Platform Interface Standards
   It should be clear/tested that the expectation of functionality of an platform interface is maintained. For example, I was working with cloud_firestore and in this situation the previous un-federated plugin allowed you to compare DocumentReference's. This was then federated and it broke the comparison operator. PR Here.
   Another example is google_sign_in (I know not in this repo). It's signIn function is documented and suppose to return null when the user cancels/closes the sign in popup. Currently with the web version it throws.

3. Poor Platform Interface Error Handling
   I worked very hard a long time across to standardise the reported Errors from firebase_auth I made sure that each method was correctly documented. The federated plugin has destroyed this. The web implementation is practically impossible for a developer to deal with specific errors such as "user not found". I would love to discuss this point and help on it where I can. But to me it seems practical to come up with a base exception class all FlutterFire plugins use from core and then for each plugin to extend it with specifics for each. For sure the plugin error class should be listed in the comments on every interface method with a list of code field responses so that the developer can deal with exceptional conditions and display the correct UX.

I know this might be a critical view-point, but hope the points are discussed internally.
I am happy to help where I can to further discussion over these and other issues.

[Ehesp]

Hey @slightfoot thanks for your comments, they're super useful.

1. Federated Plugin Interfaces

This library was created before Flutter Web was available, so at the time there were a lot of code decisions made which may not have considered the impact a Federated plugin setup would have when it was introduced. As it stands, FlutterFire web & native implementations are mis-aligned with each other feature wise. This is something we're working towards (starting with getting tests in place to catch these issues).

implements all the functions and marks them to throw Unimplemented. I think this is unacceptable.

The Platform Interfaces are like this by design to ensure that any platform specific code which wraps onto the plugin ensures that something happens if the underlying platform code (the delegates) don't provide functionality for the "call". If this happens, it should be a signal to flag an issue that something is indeed missing - this could also be a 3rd party platform implementation which is using the Platform Interface.

2. Platform Interface Standards

This boils down to the problem mentioned in the first section. Right now tests are lacking to help identify these sorts of problems but that's something we're working towards (as part of the "1.0" release cycle).

The plugins without a current web implementation will also be developed at some point in the future to work with the platform interfaces we'll create for each.

3. Poor Platform Interface Error Handling

We plan to provide a public FirebaseException class which all Firebase related errors should filter through for each platform. Right now, the firebase_core_web plugin wraps the firebase-dart library, which wraps the Firebase JS SDK. If an error is thrown on the web, the error message returned is JavaScript SDK related (not very handy for FlutterFire users). Luckily, Firebase errors return a code (e.g. core/no-app). If such an error is trapped on the JS side, we can throw a specific FirebaseException with the same message across all platforms. Once the Core rework PR lands, you can take a look in there - it's not ideal however it does help solve this problem.

[IchordeDionysos]

Thanks for bringing the development of Firebase for Flutter forward!

However, I am missing on the roadmap packages like Remote Config and Analytics!

Both are more popular than some other packages on the roadmap, however I do understand that the first 6 are for paid products.

Also, a proper Crashreporting for Flutter would be great, not tied to a Native implementation via Platform channels, but rather a first class Dart integration of Crashlytics, this would then work on all platforms out of the box!

[Boehrsi]

@Salakar and the team, thanks for taking over this important part of the Flutter ecosystem! I just wanted to ping you about an IMHO important issue and tried to link the mentioned GitHub team, but it seems the mentioned team is missing. A typo or something?