search

firebase / flutterfire

🔥 A collection of Firebase plugins for Flutter apps.
https://firebase.google.com/docs/flutter/setup
BSD 3-Clause "New" or "Revised" License
8.46k stars 3.91k forks source link

FlutterFire Roadmap #2582

Closed Salakar closed 2 years ago

Salakar commented 4 years ago

Hey all :wave:

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:

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:

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Looking at FlutterFire Roadmap #2582, it looks like the FlutterFire plugins are going towards much more stable and consistent design. There's one point I would like to add. As mentioned by @slightfoot, currently, it's very difficult to know what all kinds of exceptions might get thrown from a Firebase plugin on any given function (esp. Firestore (#1223) and Firebase Auth) and this leads to a poor UX feedback to the users. It's even difficult when writing tests or passing those errors as failures down the domain and UI layer. I tried finding a comprehensive doc of errors but could not get and concrete results.

I think that along with consolidating all the existing platform exceptions to a single place, if for the time being, we could get basic documentation with details of current implementation up and running[Related: #183] (esp. containing common ones such as Network/Timeout etc.), it could help take the pressure off as a workaround and can act as a base doc while working collaboratively on revamping the plugins. If there's already something in place on similar lines, please point to that too. Would love to contribute to this revamp process!

IchordeDionysos commented 4 years ago

For Auth, there is a well-documented list in the JS SDK reference [1]. I would appreciate if error documentation not just for Flutter, but across all Firebase products and platforms would be improved :)

[1] https://firebase.google.com/docs/reference/js/firebase.auth.Error

Ehesp commented 4 years ago

For Auth, there is a well-documented list in the JS SDK reference [1]. I would appreciate if error documentation not just for Flutter, but across all Firebase products and platforms would be improved :)

Yep something we're looking at. In cases where Firebase provides an actual error code we can handle. It's trickier when dealing with errors with no code since there's no real way to "check" the error and match it to a global one. In this case, we'll provide error messages which are as similar as possible.

SaadArdati commented 4 years ago

Any hope for a dart native firebase admin sdk?

Ehesp commented 4 years ago

@SwissCheese5 not on the roadmap right now, but maybe something longer term.

Levi-Lesches commented 4 years ago

I know it's not native, but here's something I used to keep my project mostly dart: firebase_admin_interop

SaadArdati commented 4 years ago

@Levi-Lesches That's web only unfortunately. The only available package is firebase_admin which only provides firebase auth and firebase storage support, no Firestore. firedart, on the other hand, is meant for dart native clients rather than admin

Levi-Lesches commented 4 years ago

That's web only unfortunately

It's not web, it's NodeJS, and doesn't run on clients, it runs on the server only.

The only available package is firebase_admin

It's a substitute for firebase_admin, but is being actively worked on and has many more features. My project uses it to do admin work on Firestore, Firebase Auth, and Firebase Messaging, so if you have any questions I'm happy to help.

SaadArdati commented 4 years ago

@Levi-Lesches So I can use it on a windows/Linux machine and it'll work? I legitimately thought it would crash because it depends on dart:html

Levi-Lesches commented 4 years ago

Yep! I have a Windows too. It takes some setting up, and you can't use dart:io (node_interop, node_io, and other packages by the same developer will come in handy as replacements for basic dart features), but once you get it running it works very well and supports most of Firebase's features.

raveesh-me commented 4 years ago

I would like to see "common semantic versioning". Firebase products could follow one form of versioning, but it will be super time-saving if we don't have to mix and match between plugins to get a set working.

It has been a problem for us in the past. Just hope that this remains a priority.

ingmferrer commented 4 years ago

Android newbie developers like me are starting new projects in flutter with kotlin support, so take into account that the documentation (i.e FMC) should refer to both java and kotlin version.

Also, there're a lot of FMC issues out there (crashing on start).

Good luck!

Ehesp commented 4 years ago

@raveesh-me That won't be happening sorry, for a couple of reasons:

  1. The plugins are already out-of-sync on versions, so we'd have to major jump some from 0 -> 6.
  2. Version-locking can slow down release cycles and shipping quick fixes.

That being said, we're working on a "check" which prevents incompatible versions being installed.

@ingmferrer Yep any native changes will be in both Kotlin/Java + Swift/Objc on the docs. We're actually going to be reducing a good number of native steps anyway.

sondresorbye commented 4 years ago

When will storage be available for flutter web?

ro0t commented 3 years ago

Finally the slow builds will be looked at :)

ReniDelonzek commented 3 years ago

Since there is no sdk available for the desktop (windows, linux), wouldn't building a native dart be an evaluable option?

orestesgaolin commented 3 years ago

There has been some unofficial work on Firebase SDK in Dart. Firebase Auth and Firestore is already ported but it's done by single person https://github.com/fluttercommunity/firebase_dart_sdk/tree/develop

Ehesp commented 3 years ago

There's no plans yet, although it has been talked about. Building a new SDK is a whole different story than building on-top of existing ones.

ctrysbita commented 3 years ago

@Ehesp That means we have to build more than one SDK if we want to support other platforms like windows and linux. Maybe implement everything using Dart will be easier? Or use Dart to wrap a single cross-platform native library through FFI?

Ehesp commented 3 years ago

@ctrysbita yep but you'll be waiting for a long time. I wouldn't say it's not going to happen, but it's not on the roadmap.

Salakar commented 3 years ago

Hey everyone 👋 quick progress update;

zmeggyesi commented 3 years ago

@Ehesp where does Remote Config lie on this roadmap? What about the AdMob plugin?

IchordeDionysos commented 3 years ago

@zmeggyesi it's maintained by Google as explained in the first message:

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

And Remote Config is not in the list, so it will be done sometime after "Cloud Messaging (FCM)". They don't know which package they use next.

zmeggyesi commented 3 years ago

@IchordeDionysos I'm aware of that being the initial plan, I was more looking for an update on those two packages, and whether priorities have changed (mostly in response to feedback here highlighting the need for other packages to be tackled).

Salakar commented 3 years ago

Hey all, again 🙈 another week, another update:

workerbee22 commented 3 years ago

@Salakar What is the estimated time between 'prereleases shipped' and the released version appearing on pub.dev ? I noticed core merging is blocked due to some checks failing.

ryaanwells commented 3 years ago

Just want to note that the visibility of the roadmap is awesome 🎉 Really keen to see these changes land, thanks for your hard work here!

larssn commented 3 years ago

So no release today after all?

Salakar commented 3 years ago

So no release today after all?

https://github.com/FirebaseExtended/flutterfire/releases

IchordeDionysos commented 3 years ago

@Salakar Just tried to install cloud_firestore-v0.14.0-dev.1 while also trying to install firebase_storage. Did not work... Will other Firebase libraries in their current form be compatible with the new Firebase core?

Would it require that each package will get a v1 rework? Or can I use the Firestore v1 library, and the firebaase_ml_vision or firebase_in_app_messaging pre-v1 version together?

Ehesp commented 3 years ago

@IchordeDionysos yep we're working on that. The plan is to bump the versions of all other modules (without reworking them), but get them to work with the updates. You can see Functions is WIP.

Salakar commented 3 years ago

Hey everyone, quick update;

Pre-releases of the reworked Core & Firestore FlutterFire plugins are now available on Pub (as some of you have already been quick to notice 😅). Early adopters & feedback would be hugely appreciated. [View Releases]

Note: as discussed above by @IchordeDionysos & @Ehesp, there may be some incompatibilities with the currently published versions of Auth, Functions & Storage when using the new Firebase Core - we're in the process of publishing pre-releases for these too (only minor internals changes for compatibility, not the rework versions) so please bear with us.

EDIT: functions prereleases have now been published from #2951

oranmana commented 3 years ago

image

IchordeDionysos commented 3 years ago

@oranmana I've asked that earlier :) https://github.com/FirebaseExtended/flutterfire/issues/2582#issuecomment-657786968 https://github.com/FirebaseExtended/flutterfire/issues/2582#issuecomment-658011068 https://github.com/FirebaseExtended/flutterfire/issues/2582#issuecomment-658152748

They are working on pre-release versions for other packages like firebase_auth which supports the new core.

alejandroaap commented 3 years ago

I have updated the cloud firestore version to the version ^0.14.0-dev.1 and firebase core to the version ^0.5.0-dev.2 and I have encountered problems executing this code that I have extracted from the documentation ->

// Initialize first await FirebaseCore.instance.initializeApp ();

// Set the host as soon as possible await FirebaseFirestore.instance .settings (Settings (host: "localhost: 8080", sslEnabled: false));

When initializing FirebaseCore it does not exist, however, Firebase.initializeApp () does exist.

Also, when making the settings, the error it gives is the following: 'The expression doesn't evaluate to a function, so it can't be invoked.' The example should look like this FirebaseFirestore.instance.settings = Settings (host: 'localhost: 8080', sslEnabled: false, persistenceEnabled: false); Also await is not necessary since it is not a Future.

greghesp commented 3 years ago

@alejandroaap - Thanks for highlighting the error in the docs, we'll update it soon. The correct code should be:

// Initialize first
await Firebase.initializeApp();

// Set the host as soon as possible
FirebaseFirestore.instance.settings = Settings(host: "10.0.2.2", sslEnabled: false);

With that in mind, please be aware that at the time of writing, cloud_firestore >=0.14.0-dev.1 depends on firebase_core ^0.5.0-dev.1, and firebase_auth 0.16.1 depends on firebase_core ^0.4.4 as per this issue

alejandroaap commented 3 years ago

Hello @greghesp , today I have found new versions available. I am specifically using

firebase_core: ^ 0.5.0-dev.2 firebase_database: ^ 4.0.0-dev.1 cloud_firestore: ^ 0.14.0-dev.1 firebase_storage: ^ 4.0.0-dev.1 firebase_auth: ^ 0.17.0-dev.1

With these versions, the problem you are talking about no longer exists or at least I have not had it.

On the other hand, I have seen how FirebaseDatabase cannot be initialized with the firebase database emulator url. I have tried to initialize an instance with the url of the database emulator but nothing more than trying to get data, from that instance, the application closes and no error is displayed in the log. I understand that this error is still normal because the firebase database library has not been checked. Is that so?

Ehesp commented 3 years ago

@alejandroaap We've not touched Database yet, so nothing has changed other than upgrading internal dependencies. I'd suggest raising a new issue for this, so we don't clutter this issue. Thanks.

Salakar commented 3 years ago

Hey everyone; another quick update;

The following pre-release versions are now live - these have all been updated to work with new Core:

Lots of work has gone into each of these plugins to improve testing & CI stability, these are now all using the latest Firebase SDKs and are also using the shared Firebase SDK versioning setup meaning all these plugins now depend on the same version of the Firebase SDKs - no longer mixing & matching versions.

If you can; please give these a try - overview pages for each of these are now showing on the docs site including a quick installation guide which shows what the latest pre-release version for each is, e.g. Analytics: https://firebase.flutter.dev/docs/analytics/overview.

image

Remote Config, Links, In App Messaging and Messaging pre-releases that use the new Core will be available soon.

workerbee22 commented 3 years ago

@Salakar Great work ... but you neglected to mention Crashlytics ?

Salakar commented 3 years ago

@Salakar Great work ... but you neglected to mention Crashlytics ?

For Crashlytics see https://github.com/FirebaseExtended/flutterfire/pull/2288#issuecomment-663170672

Salakar commented 3 years ago

Remote Config with new firebase_core (pre-rework) pre-release is up, also added in MacOS support whilst I was at it. 🙃

https://firebase.flutter.dev/docs/remote-config/overview

Bilonik commented 3 years ago

Amazing work!!!, just waiting for Messaging to Upgrade 😁

Salakar commented 3 years ago

@Bilonik Amazing work!!!, just waiting for Messaging to Upgrade 😁

Just for you 😅 a Messaging pre-release has just been published that uses new Core 🙃

https://firebase.flutter.dev/docs/messaging/overview

alejandroaap commented 3 years ago

@Salakar As part of that cloud messaging rewrite, do you plan to implement the option to handle notifications with data once the application ends?