Flutter Firebase & DDD Course [27] - Firebase Updates

📗 Get the code 👇👇

📧 Get Flutter news 📰 and resources:

👨‍💻 Do you write good code? Find out now!

The Firebase packages for Flutter are getting more polished and pleasurable to use. Unfortunately, these updates inevitably break or deprecate parts of the code we've written in the previous parts of this series. Let's fix it all.

Go to my website for more information, code examples, and articles:

Follow me on social media:

[ahmed_alharthi]

After watching the whole series, a 23 minutes, feels like 2 minutes. I really enjoy your videos. I think it should be added to Netflix😂

[patrickkarlsson]

edit: @Wayne Werner did the research, enum is coming
Hi Reso! Regarding the change from PlatformException to FirebaseAuthException, It did catch the right exception but you ended up in the else branch. The error codes have changed also. 'ERROR_EMAIL_ALREADY_IN_USE' is now 'email-already-in-use'.

Great content as always, thanks!

[waynewerner]

Changing to FirebaseAuthException is a bit of a hassle... looks like they are transitioning to a statusCode enum (AuthExceptionStatusCode) for code completion (yay), which will have a getter for the for statusCode, with code still being the string value. They're working it though now in a couple of PRs, until then we must still work with the string code values. Anyhow, the code as you have it above will always return a server error, as the string code values have changed. The code below, not yet merged, is used to map the current string code values to the statusCode enum. The cases are the current values that can be returned in e.code, and must be used instead of the values that were returned from PlatformException in the past. I'm looking forward to using the statusCodes in the future.

AuthExceptionStatusCode get statusCode {
switch (super.code) {
case 'invalid-email':
return
case 'user-disabled':
return
case 'user-not-found':
return
case 'wrong-password':
return
case 'too-many-requests':
return
case 'operation-not-allowed':
return
case
return
case 'network-request-failed':
return
case 'email-already-in-use':
return
case 'weak-password':
return
case 'invalid-phone-number':
return
case 'invalid-verification-id':
return
case 'user-mismatch':
return
case 'no-such-provider':
return
case 'no-current-user':
return
default:
return
}
}
}

[Flutterdev]

Since last 6 month I didn't watch single episode on Netflix thanks Matt

[lowlydeveloper]

I was just thinking about this very thing!! I mean, updating the code to the new Firebase version release! You have read my mind 😀... Thank you, thank you, thank you for teaching us how to architect our code for maintainability and readability. Such courses are very rare, and so wonderful to learn from.

[albanr]

This series is completely awesome ! Thank you !

[mrchongnoi]

Another Great Video. What I have learned during this series, I am incorporating in my new APP.

[CodingUnited]

First?

Anyways, loving this series! I really needed this after my first app that I released was unmaintainable from the terrible code that I wrote👌

[pasindunirmal]

I really like to see a video on how to use the ValueFailure class after separated into feature wise classes.

Finally catched upto the series. Now waiting for the next.
I really like this DDD architecture than the TDD which was a pain to maintain

[gerooq]

Hey Matt, could you make a video about how you got where you are? Like from schooling to college to freelancing and the whole journey? It would help alot. Cheers

[waynewerner]

BTW, I haven't checked the FirebaseException error codes of 'PERMISSION_DENIED' and 'NOT_FOUND' used in the notes repository, but I would expect that they have changed as well. In any case, for the current code, in firebase_auth_facade.dart in the e.code checks replace:
'ERROR_EMAIL_ALREADY_IN_USE' with 'email-already-in-use'
'ERROR_WRONG_PASSWORD' with 'wrong-password'
'ERROR_USER_NOT_FOUND' with 'user-not-found'
The sign in logic will then perform as before without always falling through to returning an AuthFailure.serverError()

Follow up:
According to what I found in the test files for cloud_firestore the following changes should be made:
Instead of testing test e.code == 'permission-denied'
Instead of testing test e.code == 'not-found'
e.message is composed from the e.code value, so PERMISSION_DENIED and NOT_FOUND will never be contained in e.message. Hopefully, there will be an effort to create e.statusCode enum for all of the firebase exceptions at some time as well as for the firebase auth exceptions.

[urklegizmo]

was wondering if this was gonna be released 😆

[cooljibbin]

At the time this video was released the codes for Firebase errors were incorrect. If you pause at 21:23, the code parameter contained in FirebaseAuthException is "email-already-in-use". All the errors are resorting to their else scopes.

[lowlydeveloper]

Flutter is changing fast.


Also, autovalidate: state.showErrorMessages has been deprecated. I simply replaced it with:
*autovalidateMode: AutovalidateMode.always, *
However, this changes the meaning of the code. The value is no longer a simple boolean, but a static enum.... So I am not clear of the consequences.

Also, it seems that *maxLength: ClipCaption.maxLength*, is no longer limiting the user input into the field. The validation works, but the user can keep on typing characters without restrictions.

[lowlydeveloper]

Hey Reso, could you please update the code on github? Much appreciated!