News and views on the world of interactive media from the gskinner team
Category / Flutter
As we begin pushing Flutter to more platforms such as Desktop and Web, it is becoming increasingly important to quickly and easily measure performance of your application. While the built-in performance monitor gets the job done, it leaves a lot to be desired in terms of readability and flexibility.
As the old school Flash devs we are, we remember the days when virtually every Flash application around would use the hi-res-stats package by mrdoob (yes, that mrdoob). It was extremely helpful to catch performance issues, and make sure your application was smooth (which in those days, was a solid 24fps!).
Currently nothing like that exists in the Flutter community. To help fill this gap, we’ve created StatsFl! Available now on pub.dev: https://pub.dev/packages/statsfl
There is a lot to like about Flutter, but one area I’m sure no one loves, is taming the Material Theme system! With over 65(!) properties, some of which, like TextTheme, break out into 10 more sub-properties is enough to make you go crazy pretty quick.
Last week we looked at how you can easily implement TextStyling, and this week we’re going to dive into Color Themes. We’ll take a look at a technique that we use to implement custom app-specific themes, while still providing Material ThemeData to the core Flutter components.
This works, but can end duplicated the same code all around your code base replicating the same transitions, violating the core tenant of DRY programming. Additionally if you’re using custom routes, then you’ll be forced to create additional widgets for each type, or worse, copy tons of boilerplate from view to view.
They are super cool to look at and appear to be highly performant. The only issue? The examples they’ve provided with the package are pretty hard to follow (coming in at close to 1500 lines!) and there’s no code snippets at all in the README.
But fear not! This package is actually extremely simple to use once you clear away the noise, and can see how it works.
The original thought was to add the methods to MediaQuery, which didn’t seem that appealing because it would still be quite verbose to access. Then we realized we could just use the build context directly, which turned out really nice! So nice, that we’ve gone ahead and created a package for it here: https://pub.dev/packages/sized_context.
It’s already been 2 months since our team finished the Flutter Vignette project and gave a talk at Flutter Interact ’19. Throughout the project, we were able to maintain a healthy designer-developer relationship, which was the key to the successful completion of the project. I want to share 5 things that helped us build an effective and efficient collaboration between designers and developers.
One of the big issues with Flutter for Web right now is it’s lack of support for dart.io. This means things like a simple Platform.isAndroid call will cause your web builds to crash on startup. In fact, just including the dart.io package _at all_ will break your app completely.
In cases like this, what is needed is some form of conditional compilation, so we can include the code on some platforms, and exclude it on others.
Some platforms like Unity, have built in platform defines, which let you easily partition sections of code for specific platforms. Unfortunately, this is not so easy to do with Flutter, but it is possible!