Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

FlutterFire Roadmap #2582

Closed
Salakar opened this issue May 18, 2020 · 84 comments
Closed

FlutterFire Roadmap #2582

Salakar opened this issue May 18, 2020 · 84 comments
Assignees

Comments

@Salakar
Copy link
Member

Salakar commented May 18, 2020

Hey all 馃憢

Today I鈥檓 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鈥檝e 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鈥檒l 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鈥檒l 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鈥檒l 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鈥檝e yet to decide on the order of the remaining plugins, we鈥檒l 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鈥檒l be doing some immediate changes across the board which will allow the newly updated plugins to be 鈥渂ackwards compatible鈥 with plugins that have not yet been updated as part of this process.

To achieve this, we鈥檒l 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鈥檝e tested against.

  • Consistent public API: developers coming from other platforms should be familiar with the public API FlutterFire offers, so we鈥檒l 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鈥檙e 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鈥檒l 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鈥檒l 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:

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.

@Salakar Salakar closed this as completed May 18, 2020
@Salakar Salakar changed the title Ignore me FlutterFire Roadmap May 20, 2020
@Salakar Salakar pinned this issue May 20, 2020
@Salakar Salakar reopened this May 20, 2020
@slightfoot
Copy link
Contributor

slightfoot commented May 20, 2020

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
Copy link
Member

Ehesp commented May 20, 2020

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.

  1. 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.

  1. 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
Copy link
Contributor

IchordeDionysos commented May 20, 2020

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
Copy link

Boehrsi commented May 20, 2020

@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?

@workerbee22
Copy link

workerbee22 commented May 21, 2020

I think an argument can be made that this PR to implement the New Crashlytics SDK:

[firebase_crashlytics]Migrate to new Crashlytics SDK #2288

is perhaps even more urgent than some of the others. Because most/'all' flutter production apps need a crash and error reporting solution. Where as Cloud Storage or Cloud Functions ... perhaps not so much.

@mayurdhurpate

This comment has been minimized.

@IchordeDionysos

This comment has been minimized.

@Ehesp

This comment has been minimized.

@SwissCheese5

This comment has been minimized.

@Ehesp

This comment has been minimized.

@Levi-Lesches

This comment has been minimized.

@SwissCheese5

This comment has been minimized.

@Levi-Lesches

This comment has been minimized.

@SwissCheese5

This comment has been minimized.

@Levi-Lesches

This comment has been minimized.

@Ehesp
Copy link
Member

Ehesp commented Sep 2, 2020

Hey all,

The Crashlytics rework has been shipped as a dev release 馃コ This upgrade introduces loads of new features, fixes and SDK updates.

Please help test if possible!

@Salakar
Copy link
Member Author

Salakar commented Nov 4, 2020

Hey everyone 馃憢 it's been a while since the last update but we have lots to update you on.

Since the the last update:

Reworks completed and shipped to stable channel:

  1. 馃煝 Crashlytics - [Changelog]
  2. 馃煝 Cloud Storage - [Changelog]
  3. 馃煝 Cloud Functions - [Changelog]

Reworks completed and shipped to dev channel:

  1. 馃煛 Messaging - [Changelog]
    • Notable changes:
      • Removed all manual native code changes that were originally required for integration - FlutterFire messaging now works out of the box once configured.
      • Support for MacOS. 馃捇
      • iOS background handler support 馃コ
      • Android background handler debugging and logging support.
      • Reworked API for message handling (Streams + explicit handlers).
      • Fully typed Message & Notification classes (vs raw Maps).
      • New Apple notification permissions & support.
      • Lots of new documentation.
    • We'd love for as many people as possible to test out this rework version of the Firebase Messaging plugin. For feedback and discussions on the update please see this discussion thread: Firebase Messaging - v8.0.0 dev channel feedback.聽#4023

What's next?

Our focus has now shifted slightly, and we're looping back to the first 7 plugins to focus on web and ensure it is a) supported on these plugins and b) is up to the same standard and feature set as the native reworks we've been doing.

We want these plugins to be the best they can be on Android, iOS, macOS & Web by the end of the year.

Web progress:

  1. 馃煝 Core Web
    Status: complete, pending additional testing & merging.
  2. 馃煝 Cloud Firestore Web
    Status: complete, pending additional testing & merging.
  3. 馃煝 Authentication Web
    Status: complete, pending additional testing & merging.
  4. Crashlytics Web
    Status: not supported by Firebase Web SDK.
  5. 馃煛 Cloud Storage Web
    Status: complete, pending review & additional testing. (feat(firebase_storage_web): web support聽#3917)
  6. Cloud Functions Web
    Status: not started.
  7. 馃敶 Cloud Messaging (FCM) Web
    Status: in progress.

What about the other plugins?

They've not been forgotten, for now they are lower in priority and most likely won't be reworked until the new year. We'll do our best to keep critical bug fixes/blockers shipping still on these plugins in the meantime.

@firebase firebase unlocked this conversation Nov 4, 2020
@firebase firebase locked and limited conversation to collaborators Nov 4, 2020
@Salakar
Copy link
Member Author

Salakar commented Nov 26, 2020

Hey all, update time;

Web progress:

  1. 馃煝 Core Web
    Status: complete, shipped 馃殺 .
  2. 馃煝 Cloud Firestore Web
    Status: complete, shipped 馃殺 .
    • This added in the follow new feature changes;
      • FirebaseFirestore.enablePersistence now accepts PersistenceSettings
      • support for PersistenceSettings
      • support for FirebaseFirestore.clearPersistence
      • support for FirebaseFirestore.terminate
      • support for FirebaseFirestore.waitForPendingWrites
      • support for SetOptions.mergeFields
      • GetOptions support for querying against server/cache
      • support for Query.limitToLast
      • support for FirebaseFirestore.snapshotsInSync
  3. 馃煝 Authentication Web
    Status: complete, shipped 馃殺 .
    • This added in the follow new feature changes;
      • support for EmailAuthProvider.credentialWithLink
      • support for FirebaseAuth.setSettings
      • support for User.tenantId
      • FirebaseAuthException now supports email & credential properties
      • ActionCodeInfo now supports previousEmail field
  4. 馃煝 Cloud Storage Web
    Status: complete, shipped 馃殺 .
    • Cloud Storage did not support Web previously, so this is a new platform being supported.
  5. 馃煝 Cloud Functions Web
    Status: complete, shipped 馃殺 .
  6. 馃煝 Cloud Messaging (FCM) Web
    Status: complete, shipped 馃殺 .

What's next?

Null safety support for all the above packages. More on this soon.

@mehmetf

This comment has been minimized.

@Ehesp

This comment has been minimized.

@Ehesp
Copy link
Member

Ehesp commented Apr 16, 2021

Hi All,

For those interested, all plugins have now been migrated to Null Safety, you can find more information here: #4182 (reply in thread)

Note; this does not mean they've been reworked yet, that work will be carried out in due course.

@Salakar
Copy link
Member Author

Salakar commented Sep 9, 2021

Hey all, please take a look at #6979 - the remaining plugins are now in progress along with something new 馃憖 - continuing this issue over there.

@Salakar Salakar closed this as completed Sep 9, 2021
@Salakar Salakar unpinned this issue Sep 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests