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: Simplify Platform & Screen Size Detection

In the never-ending quest to reduce boilerplate and DRY up our code in Flutter, we have noticed that using the MediaQuery class 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:

Continue reading →

Flutter: WidgetView – A Simple Separation of Layout and Logic

One of the most interesting aspects of Flutter, is the way it mixes declarative markup-style code, with imperative business 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…

Continue reading →

Flutter: Creating a Flippable Box with TweenAnimationBuilder

One of the great things about Flutter, is how you can use composition to combine multiple built-in Widgets, creating unique UI’s very quickly and easily.

Today, we’re going to create a FlippableBox, which is a double-sided card, that holds two pieces of content and automatically re-sizes to match its content, whenever it’s flipped over.

It will end up looking something like this:

Final State
Continue reading →

Google, Adobe, gskinner | Flutter Interact ’19

Flutter is a mobile UI toolkit that combines fast development, expressive and beautiful UIs, with native performance. To test-drive the platform, Grant Skinner & Mike Chambers recently built Redrix: a mobile companion app for Destiny 2.

Download Redrix on iOS or Android
Continue reading →

5 Times When You Absolutely Must Write Tests For Your Code

It’s my opinion that you should always write tests for your source code. Tests force you to code better. Tests allow you to write dependable code, create better architecture, and help you live longer*. They also help you spot fussy APIs, opportunities for reuse, and redundancies.

That said. You don’t always have the time (or budget) to test everything to death! Not everyone sees the value in all those little green checkmarks. Life isn’t pedantic and heavy-handed. Life is a pack wild horses and sometimes you need to be the cowboy.

So, when do you push back? When do you say NO! We must write tests!

1. When you have the time.

There is no reason to skip out on writing tests if you have the time to write them. Why would you opt out of better code? Taking the extra time to make your code testable will turn average code into dependable code. Code that you know actually works is almost always better than new code.

2. When you’re making a data structure.

You cannot make a data structure without writing tests for it. Why would anyone trust a data structure that cannot prove it works?

Data structures must be tested. I don’t even know how you’d code a data structure without setting up a test harness first. You don’t know how your code will be used, so knowing that every little piece works as expected is necessary.

With tests, you’ll see the logic in breaking code into small pieces. Tests will make it easier to spot problems in your architecture.

Writing data structures against a test suite is the only way to do it right.

3. When you want community contributions.

Tests are the backbone of any open source project. They make sure that community contributions do not break the codebase. This allows fixes, changes, and optimizations to be made with certainty.

Your test suite becomes the hurdle that any contributor must clear. It’s not too much to ask for contributions that prove they work.

4. When you’re designing an API.

Starting with a test suite is a great way to design an API.

This allows you to work backward from your code interface instead of coding to it. This will let you design an API from the user’s perspective first.

5. When it is a dependency

Point blank. If other code needs to use this code, you must write a test for it.

The testable code will become part of an ever-expanding toolbox. Dependable toy soldiers who can be summoned to fight for you. Go! Test the world!

Here are a few resources to help you start writing tests for your code.
Node.JS Assert
Writing good tests

*There is no scientific data that shows writing tests will help you live longer.