Welcome back to Ask Flutter.
Hopefully some of that keynote content piqued your interest.
That was very exciting to see.
So, if you have a question for Ask Flutter,
ask a question in the live chat.
And to be honest, the keynote had so much content
that we are actually going to be having a slightly shorter Ask Flutter with you all,
but please do not delay in posting your questions
because we will be following up with you on Twitter.
So, for right now,
another round of questions means another guest.
I think a man who needs no introduction from the Firebase team.
Puff. Welcome. Thank you for joining us.
Thank you for having me.
Are you saying that I'm wearing a nametag that I didn't have to wear?
Yeah. Hopefully folks can see it.
But yeah, we have some questions here about Firebase.
- Can I first ask a question? - Yeah.
Can you please not kick me like you did with John?
I'm pretty sure you signed a waiver, didn't you?
I'm pretty sure I did.
I will not. I will not.
We will definitely keep our distance over here.
But first, why don't we get into some Firebase questions?
Because I know that there are many of them.
First off, when will we get full support for Firebase on desktop
and more specifically on Windows?
I ask you one difficult question and you reciprocate straightaway.
I can only follow with that.
That's awesome. No, it's a great question.
We get this one quite regularly.
Unfortunately it doesn't mean that I have a great answer
that people are going to be fully satisfied with, just so you know.
But to explain a bit about Firebase on Flutter with Window Support,
I want to give you some idea of where we come from
and where we are going.
Firebase was very early on
when Flutter wasn't even there, just starts,
we had a library from Dart that would talk to Firebase.
Back then it was just a real-time database for authentication
and a community member implemented it.
And what they did is guess what, right?
We're talking to the Native Wire Protocol, and those are not very easy.
So there was lots of code and I had lots of interactions
with the community member about how to do all the database operations.
Now, the reason I'm saying that is
the Firebase SDKs are not simple.
They are complex pieces of product functionality.
When we were ready to actually add many more Firebase products for Flutter,
we decided to take another approach.
So we decided to wrap the native SDKs that we already had
for Android, iOS and web in...
You know this better than I do.
What's the type of plugin that can...
- federated Plugin is the word Federated. - federated Plugins. Thank you, John.
Even I blank on words sometimes.
federated Plugins so that we load to the native SDK
and we call out from some thin layer of Dart code
so that we didn't have to replicate the functionality of those SDKs in Dart,
which allows us to get to functionality to Flutter developers quickly.
Now, the not so satisfying part, this worked great so far,
but then Flutter expanded
to a number of platforms that Firebase doesn't fully support yet.
That's where we are today.
We've been looking into this. We see lots of demand for people
saying that we should rewrite everything in Dart.
And while we would love to do that, it's a lot of time commitment.
Keep in mind, it brings us back to where we have to replicate
a lot of the native functionality.
So that's not the direction we're mostly looking at
in the shorter term.
What we are considering is for the Unity and C++ platforms
we support developer workflows on Windows in a beta
and we're considering if we can wrap those SDK
in the federated plugins that we already have.
That's something we're considering looking into.
No timelines yet.
Honestly, we're just trying to figure it out.
We're looking to get this into the hands of developers at some point.
But no idea when at the moment.
Yeah, we do know that
so many Flutter developers are using Firebase now in their apps
and many of them are on Windows.
Just the fact that we're starting to go down that rabbit hole
and figure out all the things that would be required is really great to hear.
Two of the questions I got earlier today were precisely this,
so I got a chance to practice this answer.
I hope this came across.
My favorite thing about working for Firebase Team
is we get first-class support from you guys
and we get a quick reply.
We always say
that Flutter and Firebase are like peanut butter and jelly,
or like Dash and Spark.
Yeah, like Dash and Sparky.
Shall we take another question?
I think so.
Whoever sent this my way,
I'll have to thank them.
Our next question is, is there a callback for knowing
when a list of items is loaded by a scroll view?
Scrolling is a particular favorite of mine in the framework.
Puff, do you want to take this one?
No, I don't! I've always said I don't know is a great answer to everything.
Then I guess I will.
If you are an experienced Flutter developer,
then you may have at some point used scroll notifications.
This is a widget that you wrap around a scroll view
pretty much anywhere in your subtree as long as it is above it.
That allows you to listen to your user
interacting with the scroll view as they're dragging it
and changing that position.
But for a long time it eluded us in this exact case.
How do I know when the scroll view has been initialized?
Because at that point the user isn't actually scrolling on it yet.
And so it was a little while back
that a contributor developed the scroll metrics notification,
and this was developed separately from the scroll notification
because there are many people already listening to them,
and this was more specific to listening
to the metrics, the content dimensions, how long it is.
That is the type of notification that you want to listen
to that will give you that initial response when the list has been loaded.
Yeah, a lot of features like that are added...
They're not added at first and then our developers give us feedback
and then people figure it out.
It's great to see that it's an open source framework,
things get added.
Further, there's this other additional class that more recently
was added as part of Material 3,
which I know we talked about a lot earlier.
The app bar, it needs to know about scrolling
so it can change colors when you scroll under it,
but that presented a problem in that
the app bar isn't above the scroll view.
It doesn't actually really know anything about the scroll view, and it shouldn't.
So we have this other widget that's called the Scroll Notification Observer,
which you can place anywhere in your subtree
and it will allow other widgets that wouldn't be in the right location
in your tree to listen to these notifications.
That provides both scrolling and these metric notifications.
Definitely great stuff to follow.
Deep framework knowledge from Kate. Thank you.
That's awesome.
We have another question here for you, Puff.
So why are the code samples in firebase.flutter.dev not updated?
It's a tricky question.
I love tricky questions. I love all questions.
Firebase has worked with Flutter for a long time, right?
And built the Flutterfly libaries as we call them.
People are always asking when will you officially support?
So we officially did that last I/O, right?
We switched...
Now, just so you know,
not a single byte in any of these libraries changed
when we went to official support.
We just said now it's sufficient.
The one thing that did change is that we moved all of the documentation
from Firebase to Flutter.dev to Firebase to Google.com.
And so when the I/O keynote was done
and this was announced we turned down firebase.flutter.dev.
And we found out that we hadn't ported everything over,
but there were certain pages that couldn't fit in
the Firebase side because honestly,
we wrote them specifically for Flutter.
So we quickly turned it back, put deprecation notices
on the top of every page, redirect you to where you need to be.
And we've been trying to keep them in sync since then.
Note to being trying.
We clearly haven't succeeded.
So we have a plan now.
We're analyzing where we still have gaps between the documentation
and we're moving it over in the coming months.
So keep flagging when you find an outdated snippet
and always look at the top of the page
on Firebase.photo.dev
because there's a direct link to the up to date documentation
in the Firebase website.
I'm glad we put you on the spot there with Alan,
like our users love to do.
Good documentation is so important, so thank you so much.
So this is a more general Flutter question,
but I think it has something to do with Firebase.
So the most important feature for my app is offline support.
Is Flutter a good option?
So I would say I don't know about you, Puff,
but I know the Firebase SDK is when you use them
on an iOS or Android device, it syncs offline automatically
and when you reconnect to the network,
it automatically updates your rights and reads to the database.
I think Firebase is a great option,
that's one of the killer features of Firebase that maybe we don't talk about enough.
Guess what?
It's one of the reasons why those SDKs are not as simple as you think.
Earlier I said they're much bigger than you think.
If you think of something like Firestore,
which is primarily an online database with amazing scalability.
And guess what?
It's completely reimplemented in the SDK also.
So it also has to do the same thing there, right?
We just actually made huge performance improvements there
so that the indexes that you have on your server
can now also be implemented in the Client SDK.
So that's we used to say that you should use Firestore
as primarily an online database that can handle
short to intermediate periods of offline. Not the case anymore.
You can now use it for offline for as long as you want.
Still probably like more logical to use a cloud-hosted database
when you want to sync to the cloud.
That's what our users really love about Firebase
is it's quick to get started,
but it's a scalable database that you can keep using
throughout the lifecycle of your app.
It's been great here today
at Flutter Forward to actually meet with a lot of developers
and seeing what they're building with these tools.
It's one of the highlights of being at an event like this
is hearing from developers about the cool use cases
and learning about the regional things.
I learned so much about payment processing in Africa
that is very different from Europe and the US,
which I know a lot more about,
and the apps that people are building for these markets.
It's been so fun to just talk to folks and see what they're building.
Everyone can just whip out their phone
and show you right away, and it's using Flutter
and Firebase and all that stuff.
- Yeah, I loved that. - That's really been great.
Yeah, so we're kind of out of questions for you, Puff,
but we can keep talking about Firebase.
Is there anything new in the Firebase SDK that we should know about?
Well, we did a workshop here today talking about
multifactor authentication when signing in, which is becoming more and more important.
But what I really liked actually doing also was in the same workshop
we were talking about account queries, because we often say that, well,
we're a bunch of Google engineers.
At Google, we actually often say that counting is hard.
Because counting at scale is actually really hard.
But when you come from a relational database background,
you do select start, count start, right?
And it's easy, except the database is working really hard to do that.
Then you come to a NoSQL database and counting isn't an option.
And now on Firestore, actually,
there is an integrated count feature and we were upgrading
a demo app that we built probably two years ago in Firestore
to use that new feature and then show
the impact on the cost that you have for that,
which is really cool to see
because it's about 1,000th of the cost that that it used to be.
You get that for free.
Yeah, exactly.
I just noticed that another question just popped into our feed here for Firebase.
So can you take another, Puff?
Let's see. We'll figure it out.
This one says, why are many calls in the Flutter SDK for Firebase asynchronous
even when the corresponding calls on iOS and Android are not?
That's a really good one. I liked that.
By the way, some of these questions,
I see a lot of these on a site like StackOverflow,
where I help a lot of developers.
So I've seen this one before.
There's two types of asynchronous calls that I noticed in the Flutter SDKs
for Firebase.
So the ones that actually I'm most familiar with
is the network calls, loading data from the server.
And that takes time.
That takes time in something between dozens or hundreds
of milliseconds.
And so there you typically want to use a future
or a stream builder to handle it,
the asynchronous nature, to show all the states
that it might go through to handle those.
Then there's things like initializing the app.
That call is async.
I was really surprised initially when I saw that
because it isn't async on Android and iOS
because actually it's just a call that we handle in the thread.
But on a... what's the word again?
Federated plugin.
When we go across a process boundary,
it turns out that all the calls are always asynchronous.
You're staying in the same application,
but you are actually calling across process boundaries,
but these take like nanoseconds to complete.
I see people putting something like initialize app
in their main UI and then doing a FutureBuilder,
which is totally okay if you want to.
It doesn't really matter that much.
You can also just put an await in your main function
and it will just work fine. That's what I recommend people doing.
Nothing bad happens when you put it in your UI with a FutureBuilder.
It's just simpler if you do it in your main method with await.
The takeaway there is to just add an await
on your initialize app call just to be safe, but it's probably fine if you don't.
But it makes sense to use async for the other stuff
because Dart is first class for futures and streams
as first class support for async code.
So it just would feel wrong if it wasn't async.
- It would just feel wrong. - No, yeah.
- I loved that. - Yeah.
It looks like we probably have time for one more question.
This one looks a little bit specific,
so I'm wondering if someone offstage has additional context.
Puff, I signed a user in,
why is the current user null when I restart the app?
I feel like somebody might have been looking at
the top questions on StackOverflow
because this is a very common one, really.
Remember, we were just talking about asynchronous behavior, right?
Firebase authentication automatically persists
the user credentials when you sign in in the local storage.
It restores them automatically when you restart the app.
But guess what?
Restoring credentials requires that we make a call to the server
to see if the user was suspended or something like that.
So yeah, that is going on while your app is already running
because we don't want to block the app while that call is happening.
But you can [read to property] current user and guess what?
If that call to the server hasn't come back yet,
current user's null.
So what you should do is actually use an off state listener
as shown in that documentation that we talked about earlier.
You can respond to when that state is restored.
It just becomes
a responsive UI like anywhere else where you use the stream builder.
Completely expected behavior,
but the first time you encountered it,
- it might be a bit like, huh? - Yeah, for sure.
It's great to have sample code
because you can see how that's written and then just copy, paste.
My standard answer, John, on this one is if you go to the documentation
on getting the current user and take the first snippet
and not the second one, you get exactly what you want.
- Do we have time for any more questions? - I don't think so.
I think that we have just about run out of time.
So I guess all we have left to do is to say thank you so much for joining us.
Thank you so much, Puff.
- Thanks for having me. - I hope you've enjoyed the day.
I hope that everyone has been enjoying the day.
I certainly am going to rewatch the keynote.
And there's additional content that's been released online,
so go check that out.
Should be dropping any minute, so be sure to check it out.
Thank you so much for joining us.
Enjoy the rest of Flutter Forward.
Enjoy. Bye.