Profile cover photo
Profile photo
Seth Ladd
Dart and Flutter @ Google
Dart and Flutter @ Google


Post has shared content
I took it up a notch and created another video to show how to create a navigation drawer in a flutter app. But this time I use the DrawerHeader and DrawerItem with a material design icon and then when you press on it, go to a new activity using a route to a stateless widget.

Find out how to create a simple Stateless widget and use it as an activity. And then use the Navigator to navigate to it from the drawer item ontap or onpress event.

Post has shared content
Check out our new tutorial for static layouts with Flutter (a new reactive framework and mobile SDK for building apps for iOS and Android)!

Comments most welcome. Please enjoy!
In Flutter, "Everything is a widget!" A new tutorial, Building Layouts in Flutter, shows you how to create a layout using Flutter's rich library of widgets.

Post has shared content
"I've been using [Flutter's hot reload feature] to write code for a few days now and it is astounding what a difference it makes"
The big thing we're testing in Flutter land right now is Hot Reload. This is a feature from the Dart team that's going to make Flutter development massively easier. Instead of having to restart your app each time you make a change, you just have your IDE signal your device that the source code has changed, and we load the new code straight into the actively running VM without losing any of your state! Your app could be in the middle of an animation, and boom, half-way through we upload the new code and the animation continues running but with the new settings, without interrupting the animation or anything.

I've been using this feature to write code for a few days now and it is astounding what a difference it makes. You can try it today if you're using the master branch, just use "flutter run --hot". It's still a bit buggy (we don't yet support loading assets in this mode, for example, which is obviously a bit limiting) but that should get shaken out in a few days and then we'll land it on the alpha branch.

Conveniently, our framework really fits the hot reload model well. When you trigger a hot reload, we just mark every widget as needing to be rebuilt, and the whole app gets the new code applied, without losing state. This means you can tweak build functions, theme settings, and so on, and when you reload, the code takes effect. It would have been much harder to do this if our framework used a more retained-mode model like traditional UI frameworks, where once you've described the UI it stays in memory.

In other news, we now have a real logo! We've started deploying it, you can see it on our Web site and our G+ page and so on. I've been writing a widget that renders the logo, so that you can fly our colours if you want to. The logo is a heavily stylised blue wing in the shape of a sideways F. By the way, using hot reload makes writing canvas code, like this logo drawing code, so much easier. You just edit the coordinates, hit a key to save your changes, look at the device, and repeat.

The past few weeks I've been making sure our licensing story is nice and straight, including adding an AboutDialog widget and corresponding license screen. (Nothing drives home quite how many shoulders Flutter is standing on than paging through all the licenses of third-party packages Flutter uses. It really is a testament to the power of open source development.) Anyway, that's why I'm writing a FlutterLogo widget: my plan is, by default, to include it at the top of the license screen.

Post has attachment
"A scrollable Contacts View containing widgets representing each contact will be implemented along the article writing just 74 lines of [Flutter] code"

Post has shared content
"code completion heaven"

Nice work, +Jana Moudrá!

Amazingly thorough work by +Jana Moudrá. Every bloody callback wrapped as native Dart Future or Stream (await / async heaven), every single JS object transformed to Dart object (code completion heaven) and also - it works :-)

Post has shared content
The last week or so we've been working on polish issues so that our Flutter Gallery demo app looks and feels so good that anyone trying it is left with no doubt that Flutter is a serious option for writing mobile apps. This means looking at things like performance during page transitions, removing demos that aren't complete, and fixing silly trivial bugs that we've ignored for too long. In the latter category, for example, we have the bug I've been looking at today: getting the scroll friction in flings in lists to feel natural. This basically means figuring out what the magic number should be by tweaking it slowly bit by bit until it matches the platform! You can see my crazy setup in the photo below. I put two devices side by side and then do a fling gesture on both and see how close it gets.

Turns out iOS is very slippery, 0.125. Android is high friction, 0.002 if I remember correctly.

Post has shared content
The Flutter with Firebase codelab is really fun. Looking forward to seeing developers try our tech-preview of Flutter for the first time :)
Fired up for Google I/O 2016! Try a tech-preview of Flutter with Firebase at the codelab kiosks, and build a cross-platform mobile app.

Stop by the kiosks and say Hi!

Post has shared content
Lots going on in the Flutterverse!
Over the past few weeks the Flutter team has been mostly focused on performance and testing.


For performance, the first step of course is measurement. To this end, Yegor has started doing continuous automated testing on actual devices, so that we have a clear baseline against which to measure our progress. Of course to make that useful we have to have performance tests, so Viktor wrote a test with some complicated layouts. This immediately uncovered that my MixedViewport class was terrible, so Adam rewrote that as LazyBlock. And on it goes.

LazyBlock is pretty neat. Instead of just giving it a list of children, you give it a delegate that produces children on demand, and LazyBlock only asks it for the children that it needs. As you scroll, it throws away the earlier children, and asks for the next ones. If you go back up, it does the same thing backwards. Eventually we'll even make it guess the right child number if you jump scroll, so that you can jump around a huge list of children without ever having to pay the cost of drawing any children other than the ones on the screen.

One widget we don't yet have is a LazyTable. That's something I plan to add soon. I did implement DataTable recently, you can see the demo in our gallery app which exactly matches the sample in the Material Design specification. The next step though is a paginated version and a scrolling version, reusing the same delegate approach that Adam used for LazyBlock. (Tables are tricky because you have to figure out what size to make the columns; for DataTable, it actually measures every cell before laying out any rows, which is quite expensive. For LazyTable, we'll have to use either fixed width columns or flex-style sizing.)

Lots of other work on performance has been going on too. Eric and Devon hooked things up so that from the Atom editor you can now with one checkbox turn on and off our PerformanceOverlay widget and our "repaint rainbow" feature, live while your app is running. Hans has been working on improving the performance of our gallery app. Seth has been running lots of our demo apps tracking down any where we miss frames and filing bugs on them. We even had the help of a nine year old yesterday, who found a bunch of bugs for us!

You can see a screenshot of the checkbox on the PR:


The other big push recently has been on testing. As we like to say, "write test find bug". The problem is that writing tests for Flutter has been a bit difficult so far, because you can't see what you're testing.

Yegor has been working on a way to test on-device, using "flutter drive", and as part of that he redesigned our API for testing in a way that makes a lot more sense. (Flutter drive is what he used to do the continuous performance testing I mentioned earlier.) I've now picked that up and I'm taking it to its logical conclusion: make it so that even for our unit tests, you can actually see what's going on if you run them on a device. The hope is that this will really simplify writing tests for Flutter, which will mean we write more tests (and hopefully will mean people writing apps for Flutter can write more tests, since we use the same testing strategy for people writing Flutter apps as we do on Flutter itself), which will mean finding more bugs!

Post has shared content
Why yes, that's a Flutter app talking to a Dart server. So cool to see devs try +Flutter.

Post has shared content
Lots of nice updates to the Dart Language Tour!
Check out the updated Dart Language Tour.

This version adds details about superclass constructors, initializer lists, cascades, runes, mixins, callable objects, and more. Information on implementing libraries is gone, replaced by a link to the recently added page

For details on how the tour changed, see
Wait while more posts are being loaded