There are many ways to architect an app in Flutter, and just about as many state management frameworks out there to do it for you! With this in mind, we thought it might be nice to talk about how we build scale-able apps without a framework, using only the Provider package, and some simple application tiers.
Continue reading →Author / shawn.blais
Flutter Tricks: Widget Size & Position
Occasionally in Flutter, you will need to get the size and/or position of a widget. Some common use cases for this are:
- You need to measure something and make some decision based on that. For example, you might switch from an expanded column, to a scrolling column, at a certain height threshold.
- You may want enable or disable a scrollbar based on the height of some content
- The parent needs to know your position. For example if when you tap a menu button, the parent wants to animate a dot to that position, we need the button to be able to report its position somehow.
Flutter: Extending State‹T›
Recently we’ve been exploring the ability to extend the base State<T> class, to add additional capabilities to our views, or writing our own custom Mixins to do the same.
Most Developers are familiar with using the various framework Mixins, like TickerProviderStateMixin but what is not commonly known, is how easy it is to create your own flavors of these. Additionally, many developers extend State<T> constantly, and write very repetitive boilerplate code, without realizing how easy it is to create their own BaseState<T> instead.
In this example, we’ll make a “base state” that provides 3 AnimatorControllers to any widget that needs to animate something. We could then apply this to any Widget in our application, and it automatically get 3 animators to play with. No setup, or teardown required.
Continue reading →Introducing: Flokk – A Desktop App built with Flutter!
After several months of hard work, we’re excited to announce our latest collaboration with Google, Canonical, and the Flutter Team, it’s a cross-platform app called Flokk!
Flutter: Introducing StatsFl, an FPS monitor for 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
Continue reading →Flutter: Create Custom App Themes
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.
Continue reading →Flutter: Tame those TextStyles!
One of the most verbose parts of Flutter is handling of various font styles, sizes, and families. In this post, we’ll show a couple of the tricks we’re using in production to ease this pain point.
Continue reading →Flutter: Simplify your PageRoutes
One of the more verbose parts of Flutter is pushing new pages into the Navigator Stack, especially if you want to use something other than the standard Material or Cupertino Routes.
The standard recommendation from Flutter Docs, is to just build your PageRoutes inside your button handlers, and then pass them directly into Navigator from your views. Something like:
Navigator.of(context).push(MaterialPageRoute(builder: (c)=> MyPage()))
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.
Continue reading →