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.
Continue reading →

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 →

A Dive Into the CAMP Site Assets

The site we made for the 2019 CAMP Festival for creatives recently won an Applied Arts award for Community Promotional Design! To celebrate, we looked back at some of the assets that went into the site experience.

The Site

The site took visitors on a mini-journey through a Canadian-inspired landscape. This is the breakdown of the assets for the site header rendered in Blender.
Continue reading →

Export Responsive Layouts for Flutter with Adobe XD

I’m very excited about the v1.0 release of the “XD to Flutter” plugin for Adobe XD. While the prerelease versions were interesting, and occasionally handy for grabbing a style or shape, the addition of responsive layout support in 1.0 makes it a genuinely useful tool for creating beautifully designed widgets and even simple views.

Now that the first production release is available, I thought I’d write up a short blog post that introduces the plugin, and helps you get started using it.

If you’d prefer not to read, you can check out this Adobe Creative Cloud video on LinkedIn that features Will Larche from Google describing what Flutter is, and me (@~17:00) talking about the XD to Flutter plugin.

Continue reading →

Blender Grease Pencil: Creating 3D Environment Illustrations

I saw some Blender Grease Pencil animations by Dedouze and got inspired by what the tool seemed to offer. The Grease Pencil tool is like a typical drawing tool made for Blender. It allows you to draw in 3D space as well as make and play animations in real-time. Pretty neat right? The closest thing I can compare it to is one of those 3D pens that lets you “draw” in a 3D space.

Continue reading →

I’m Lazy

Yes, I’m very lazy and proud of it. Most programmers out there will understand that. We’re among the laziest people you’ll ever meet. We’ll work hard and create a vast array of tools and scripts to aid us in tasks that we consider boring or repetitive, all so we don’t need to do extra work. Many of the repos at gskinner have a utils folder that’s full of scripts that serve one specific purpose. That’s a good thing. In daily programming, there are always repetitive tasks that crop up. Some are easy, some are just boring and time-consuming. Here are a few tips to help you also be lazy and save those precious seconds during your day.

When Should you Create Tools?

  • Is there a group of tasks that’s repetitive? Ex: everyday are you running the same X commands? Make a script to wrap them.
  • Is there a boring, but labor-intensive task that comes up every few weeks or months? Make a script for that. A good way to know when you should create a script for these tasks is, are you always having to remember those nit-picky details about how to do it? Or are there weird edge cases you know will be forgotten? A quick script will help isolate those dependencies for next time.
  • Is it a task that’s large and time-consuming? Examples could be data extraction or converting a folder full of files. Make a script for that. Sometimes if you know that one task will take you a few days (or more) to complete. Then, by all means, spend a few hours or even a day or 2 making that script that will save you time in the long run.
  • A “tool” doesn’t need to be a script. It could be a small, throwaway, RegExp expression. I don’t know how many times the “List” feature on https://regexr.com/ has saved me from hours of tedious data conversion tasks.

Focus on Functionality 

These tools don’t need to be perfect. They don’t need to be used by other projects or other people. Sure, if you make something that’s useful, then, by all means, consider making it more portable. But don’t waste time upfront with that extra work. It’s very tempting to over-architect your tool, but it may only be a script that’s only ever used in your project, or potentiality only runs once or twice. Your initial focus should be making it functional and don’t worry so much about error handling. Don’t worry about making the UI or cli interface perfect. Don’t worry about making the code clean. Do what’s fast, do what’s gonna get you to that point of running the script, so you can move past your boring task. You can always tweak or polish your script in the future. Or someone on your team will.

Organization 

Sometimes a tool turns into something more. Something that requires you to start adding command-line arguments or even UI. If you are in a JavaScript project, chances are you already have a package.json file.  And it’s super easy to add scripts to it. More on that here: https://docs.npmjs.com/cli/run-script. This helps centralize your tools, and makes them easy to discover, run, and self-document. For other projects just having a utils/ folder can be fine. Just remember to name your script something useful. runMe.sh is not useful. download-strings.sh gives some context to what will happen when you run this file. Don’t forget to add some docs. Use your repo’s README and add a one-liner to say what your script does, and any potential arguments or gotchas for running.

Stay Lazy!