News and views on the world of interactive media from the gskinner team
Category / Source Code
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.
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!
In the never-ending quest to reduce boilerplate and DRY up our code in Flutter, we have noticed that using the MediaQueryclass can be a bit cumbersome, and it’s also missing a couple of key pieces of information.
The issues we see are:
MediaQuery.of(context) is a bit verbose on its face
Checking for orientation especially is too long: bool isLandscape = MediaQuery.of(context).orientation == Orientation.landscape
There is no diagonal size parameter, so you can’t easily get the true screen size of the device, helpful for determining your form factor
There is no way to get the size in inches, which can be useful when thinking about breakpoints (for most people, 4.5″ is easier to picture, than 720 logical pixels)
To that end, we have small Screen helper class, that we use across all our new projects:
One of the most interesting aspects of Flutter, is the way it mixes declarative markup-style code, with imperativebusiness logic style code, all within the same Dart programming language and file. This creates a really nice coupling between interface and function. When compared to editing XAML for UWP apps, or XML for native Android, building interfaces in Flutter can be a very rapid workflow.
While this is really nice from a productivity standpoint, it also manifests as one of Flutters biggest issues…