Shawn has worked as programmer and product designer for over 20 years, shipping several games on Steam and Playstation and dozens of apps on mobile. He has extensive programming experience with Dart, C#, ActionScript, SQL, PHP and Javascript and a deep proficiency with motion graphics and UX design. Shawn is currently the Technical Director for gskinner.


Flutter: Introducing `RoutedWidgetSwitcher`

We’ve recently released a new package for use with all “Nav 2” implementations, called routed_widget_switcher:

It allows you to declaratively switch child widgets based on the current Router location:

class SideBar extends StatelessWidget {
    Widget build(_){
     return RoutedWidgetSwitcher(
        builders: [
            PathBuilder('*', builder: (_) => const MainMenu()),
            PathBuilder('/dashboard', builder: (_) => const DashboardMenu()),
            PathBuilder('/settings', builder: (_) => const SettingsMenu()),

RoutedWidgetSwitcher is intended as a complimentary package for any Router (aka Nav2) implementation, including popular routing solutions like GoRouter, RouteMaster or VRouter etc. It is read-only, and simply binds to the current Router location and renders the matching widget.

Switching widgets based on location is useful for two primary use cases:

  • when you have scaffolding around your Navigator, like a SideBar or a TitleBar and you would like it to react to location changes
  • when multiple paths resolve to the same Page and you want to move subsequent routing further down the tree

It is based on Flutters AnimatedSwitcher widget, so it has support for a custom transition and duration. For path matching it uses the popular PathToRegExp package which is also used by many of the implementations including GoRouter and VRouter.

Using RoutedWidgetSwitcher provides a few benefits to your code:

  • no need to add pattern matching logic to your outer scaffolding and inner sub-tree. Instead express the location bindings in a simple declarative format which is more flutter-like
  • Decouple your ui from any particular routing package, making it easier to change packages later or migrate code across projects

You can see an example of it being used with some different router implementations here:

If you have any questions or comments let us know below!

Flutter: Adding (scalable) state management to the new `skeleton` template

Recently we took a deep dive into the new skeleton template included in the Flutter SDK. As noted in the article, one of the big missing pieces in the template is a scalable state management solution with dependency injection and data-binding.

Given that, we thought it would be informative to convert it to use a couple of popular state management libraries, specifically riverpod and GetItMixin.

Continue reading →

Flutter: A Skeleton App w/ GetIt + GetItMixin

Recently we compared and contrasted some common state management packages. And while app architecture was not the focus of the article, we received some feedback that the examples were too simple to give a good picture of how the approaches would scale. In this post we’ll attempt to address that concern by building a simple yet scalable skeleton app using GetIt and GetItMixin!

Get What?

If you’re not familiar with GetIt, it is a robust implementation of the classic service locator pattern, which allows you to register objects by their type and then look them up from anywhere in the app. Recently it gained a sibling package named GetItMixin which provides reactive widget binding hooks. Combined these two packages make up one of the simplest and cleanest methods of managing state within a Flutter application. Let’s take a look!

NOTE: To follow along, the full demo is posted here:

Continue reading →

Flutter: Deep dive into the new `skeleton` app template

For many years Flutter has provided the basic “Counter App” each time you created a new project. While that example provides a nice introduction to the foundational concepts of StatefulWidget and basic font/asset management, it does not really resemble the structure of a “complete app”. This has left developers without guidance for anything beyond a basic single page app.

Continue reading →

Flutter: Hit-test outside parent bounds with `DeferPointer`

One thing that has always felt a little limiting in Flutter for us has been its inability to perform hit-testing for a button or gesture detector that is outside the parents bounds. This has been a popular issue in the Flutter bug-base over the years, getting something around 150+ upvotes if you add up all incarnations of the issue.

Continue reading →