[TEST PATTERN SIGNAL]
[THEME MUSIC]
ANDREW BROGDON: We mentioned this
in one of our earlier episodes.
We have Flutter samples, and I just
wanted to make sure everybody knew
that we have an index for it that
is a curated list of samples.
So we're working on a ton of samples right now.
I think I have two or three in the pipeline myself,
and other people are always making more on the team.
But there's also the community-- the Flutter community is also
cranking out samples, which is great.
And so I wanted to have an index in our samples repo
that had not just the stuff that the Flutter developer relations
team was working on, but also just good stuff
that the community has made that people should also
be looking at.
And so we put together this index.
It's in our samples repo--
you know, GitHub.com/Fluttersamples,
and then look for the index.
And you can see a bunch of things in here.
There's Flutter examples from Nashad,
there's another Flutter examples--
it's a collection of things from one of our GDEs.
And we have just a ton of stuff in here--
Brian Egan's architectural samples
that I've pointed a zillion people to.
So if you're looking for more sample code-- you know,
you're watching something like this,
you're probably interested in Flutter code--
and you're looking for more code that's
made by people who really know what they're doing,
check out this index, because you'll see a lot of stuff made
by a lot of good people.
OK.
EMILY FORTUNA: OK.
ANDREW BROGDON: We'll switch.
EMILY FORTUNA: Yeah.
You'll take a look at the questions, answer them,
and I will continue to investigate this bug.
ANDREW BROGDON: Yeah, there we go.
OK.
I'm going to take Dash.
There we go.
EMILY FORTUNA: Dash can assist with question answering.
ANDREW BROGDON: And this brings up an important question.
Where are-- over there, right in front of me.
So this open window is where the question--
OK.
EMILY FORTUNA: Set you up for success.
ANDREW BROGDON: Smart lady.
All right.
So we had a few come in.
We talked about the comment that was helping
me find the censors page and the Emulator settings-- thanks
again for that.
Let's see.
We had somebody ask about whether it's
possible to use the BLoC pattern with Angular Dart.
And yes, it is.
One of the things people like about BLoC,
and one of the things it was designed for, actually,
was code reuse between Dart for Web and Flutter.
So BLoC generally will be just business logic components--
it's taking an input on a stream and it's outputting
its output on another stream.
There's not widgets involved, generally, in a BLoC--
it's just pure Dart code.
And so one of the benefits of that
is that it can run on both platforms.
It can run both on mobile and web,
and that's part of what it's designed for.
So to answer your question, yes.
All right.
We had another question come in from someone
whose YouTube account has "locationservices"
as their name.
It's "locationservices."
Well, Mr. or Miss Services, thank you
for commenting, asking about importing
a file as a file versus importing a file as a package.
So if you-- do you mind flipping real quick just
to any file in Android Studio or something just so we can look?
So all the way at the top-- oh, sorry, Dart file.
Here we go.
So at the top here, we have "import package
Flutter/services.dart," which is being imported as a package--
that's how it's being recognized.
You can import things like in that same way,
even if they're in your own project.
So if you're working on an app and you have two files,
you know, one that's called main.dart and another one
called widgets.dart, you can import that one as a project,
even though it's a local file just sitting in your project,
or you can import it as a local file.
There's two ways to do it.
It doesn't really matter which way you do it--
the only important thing is that you pick one and stick to it.
And the reason is if you import a file as package,
you know, colon, your app name, slash, and then the file in one
place, and then import it as import--
EMILY FORTUNA: Direct path.
ANDREW BROGDON: --just direct path in another, Dart
actually considers those two separate name spaces.
And so it will create two sets of class definitions
and everything else, even though all the code
is in the same file.
It has to do with the way it handles the imports.
That's something they're looking at maybe changing further
down the line.
But for right now, that is the case.
It considers them two separate name spaces.
So if you have an object that you allocated
in one of those files and you're using it
in some code that was using the import that
was done in a different way, you can get a type conflict,
and it'll look really weird.
It'll be like, "type customer record
is not equal to type customer record,"
and you're like, what are you talking about?
You know, this came from--
I only have one customer record class declaration
in my whole project.
But because it's imported in two separate ways,
it counts as two.
Personally, I just do the package way for everything.
Everybody, you know--
EMILY FORTUNA: And I actually like to do the direct pathway.
ANDREW BROGDON: You do the exact opposite.
EMILY FORTUNA: But the reason I like
that is it helps for me to distinguish between the files
that I'm writing and other packages that I import.
But it comes down to personal preference, I suppose.
ANDREW BROGDON: Yeah.
Like I said, it's really pick one way--
EMILY FORTUNA: But be consistent.
ANDREW BROGDON: Yeah.
Pick one away and go with it.
It's like when you're chopping up vegetables to roast them,
you know?
You just pick a size and go with it.
So.
[THEME MUSIC]