Tutorials
Using FutureBuilder in Flutter
In this quick video tutorial, Johannes Milke does a nice job of explaining the use of FutureBuilder in Flutter.
Although there are many ways to handle data coming in from an asynchronous API call, this should prove helpful as another "how to" example if you're working on this.
Create a Nested Navigation Flow
If you're developing anything other than a very basic app, you'll eventually run into supporting complex navigation schemes. Having a navigation scheme that makes sense is important, and if you're just getting a project started, you might as well give some thought to navigation up-front to save development effort later.
This Flutter Cookbook article gives a nice overview of creating a nested navigation scheme, and is worth looking at if you're struggling at all with setting this up in your own apps.
Tips & Tricks
Architecture
Why is Flutter Fast?
"So, why do you use Flutter?"
If you're like me and get this question from other developers, you may benefit from the deep dive Cagatay Ulusoy has done here in explaining Flutter's performance advantages.
If you've been developing in Flutter for a while you already know some of the basics which Cagatay covers here, but sometimes it's helpful to be reminded of gems like this:
Flutter takes a different approach than other cross-platform technologies. The UI is displayed on the screen using its own libraries instead of the platform UI libraries which eliminates one level of abstraction.
Instead of native UI components, Flutter apps use natively-looking UI components included in the Flutter SDK. Thanks to this approach, the quality and flexibility of the widgets used in Flutter apps are independent of the built-in solutions provided by the underlying platforms.
Of course, Cagatay covers much more depth in this series, with the three major topics including:
- The Widget, Element, and Render trees
- Flutter's layered architecture
- The rendering pipeline
If you'd like a better understanding of Flutter's fundamentals so that you're better prepared to answer the "Why Flutter?" question, I'd encourage you check this out.
Development Process
The Tasks You Don't See Can Sink a Software Project
Please don't hate me here, but I've spent much of my career in software engineering management, and as such I've also spent a lot of time gathering estimates from engineers about what they were working on. This was all part of an effort to help keep projects on track and to prioritize the features we would implement in the next product revision.
Although these "estimates" were somewhat useful, there was a huge variability in the accuracy of those estimates -- even when the estimates were coming from very skilled and experienced developers. In fact, if I had to guess, I'd say they were incorrect more often than not, and usually incorrect in the "wrong" way, where the tasks took a lot longer to implement than the developer had originally expected.
To this day, I've still felt like there must be a better way to estimate and manage the scope of individual programming tasks. This statement from Basecamp's Ryan Singer in his guide to the Shape Up development process really hit home:
Say you have two tasks, both estimated to take four hours. If one task is something the team has done ten times in the past, you can be confident in the estimate. Suppose the other task is something the team has never done before, or it has unclear interdependencies. It could take the four hours if all goes perfectly, but due to the unknowns in it, it could stretch out to two to three days. It’s not meaningful to write “4 hours, or maybe 3 days” as the estimate.
If these sorts of things interest you, I'd encourage you to check out Ryan's thoughts, as well as the rather simple tool they finally settled on at Basecamp to help give better visibility into how much effort is remaining for current programming tasks.
I've often felt that estimating the work left to be done was sort of a necessary evil, but using something like this to not only keep track of the amount of work left to do, but also the kind of work left to do, may actually prove useful.
Flutter Jobs
Flutter Job Openings at Very Good Ventures
I mentioned last week that I'd be devoting one section of the newsletter each week to Flutter job openings, and this week I wanted to highlight these available positions at Very Good Ventures.
Openings at VGV this week run the gamut, from individual developer roles to engineering management to product management. If you're looking for a new opportunity, I'd highly recommend checking these out.
And as always, if you're aware of Flutter-related jobs where you work and want to have them listed here, please drop me a note. (Mentions here are free for now :-)
)}
Expectations vs Reality When Starting Work at Your First Big Tech Company
If you've been there, you know :-)
// From Mark
Managing the Risk of External Dependencies
If you're an Atlassian/Jira customer, you could be feeling some pain this week as their systems went down and Atlassian is still working toward full recovery ten days later.
Although this specific outage seems more "extended" than what you might normally run into, it does beg the question: What are the critical outside dependencies your own organization relies on, and are you prepared in the event that any of these services go offline?
Depending on the services you both provide and depend on, I think the granularity of the solutions here could run the gamut, from large-scope measures such as offsite system backups, down to reasonable error handling in your Flutter code in the event that backend systems go offline unexpectedly.
Even though I'm using Atlassian as an example here, being in the tech industry ourselves, I don't think we'd wish this sort of outage on anyone. But each of us can take to heart the question: Am I prepared?
Please enjoy this week's issue. I'm off to backup that server REST API code...
Mark Winters