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!
As the amount of data in the world increases, so does the need for designers to know how to visualize that data. Since at gskinner we have to work with quite a variety of data sets, I thought it was a good idea to brush up my data visualization skills.
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…