When I want to try out something small in Flutter, I mostly have two options. Either use DartPad or create a small sandbox project locally.

DartPad vs local project

I don't always like to use DartPad because it doesn't allow me to use the setup I'm used to on my machine. Code completion isn't that great, there's no option to easily click through the framework's source code and we cannot add certain libraries.

Having a sandbox project locally is nicer to work with but it requires some tedious setup. Go to a directory, create a new project, remove all the verbose comments in main.dart and, if you want to run on a real iOS device, set up signing in Xcode. Quite a hassle, so I took some steps to make it easier.

Create a clean project

First of all, I created a new Flutter project and set it up just as how I wanted it to have as a starting point. I made sure it was able to run on a real iOS device and simplified the main.dart file:

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Sandbox',
      home: HomeScreen(),
    );
  }
}

class HomeScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text("Sandbox"),
      ),
    );
  }
}

For me, this is what I mostly would like to have as a starting point for trying something out.

Once this was all set up, I simply created a local Git repository and commit this on the master branch.

git init
git add .
git commit -m "Initial commit"

Now, to start with a clean slate, I just open this project and run git reset --hard to go back to this starting point. But if you've created other files that aren't tracked by Git, you need to run git clean -f -d as well to remove those. This was all a bit too cumbersome for me.

Script it

I simply created a script that resets this project and opens it in VS Code. It's basically just a few lines, but I wanted to add something extra to it.

If I don't have any connected devices, I want to be able to run my code on an iOS simulator or Android emulator. So I added two options to the script: -i for starting the simulator, -a for starting the emulator or -ia to start both, of course.

Here's the script:

#!/bin/bash

# Absolute path of the Flutter sandbox project
sandbox_path="/Users/fre.dumazy/Developer/Playground/flutter_sandbox"
# Name of Android emulator to open.
# Check with `emulator -list-avds`
avd_name="Pixel_4_API_30"

main() {
    processOptions "$@"
    resetSandbox
    openVsCode
}

openVsCode () {
    # Open the project in VS Code at the main.dart file
    code "$sandbox_path" "$sandbox_path/lib/main.dart"
}

usage () {
    echo "Usage: $0 [-i] [-a]"
}

processOptions () {
    while getopts ":ia" flag; do
        case "${flag}" in
            i) 
                startSimulator
                ;;
            a) 
                startEmulator
                ;;
            *)
                usage
                ;;
        esac
    done
}

startSimulator () {
    open -a Simulator
}

startEmulator () {
    # Start emulator in a background process and ignore logs in terminal
    emulator -avd "$avd_name" > /dev/null 2>&1 &
}

resetSandbox () {
    (cd "$sandbox_path" \
     && git reset --hard > /dev/null 2>&1 \
     && git clean -f -d > /dev/null 2>&1)
}

main "$@"

Some values need to be configured at the top, but once that's set up, I can use it over and over again.

Alias it

Once this script was made, I added it as an alias in my bash.profile so I could call this from any directory in the terminal.

alias fsandbox='~/scripts/flutter_sandbox.sh'

Now I can just type fsandbox when ever I want to fiddle with Flutter.

It's nothing special, but enables me to quickly have a sandbox project set up and avoids me from trying out stuff in existing projects, or losing time with DartPad.
I'll probably add more features to the script in the future. One of the things I'd like is that previous changes are first committed to a separate branch with the last modification date and time as branch name, so I don't accidentally lose useful code snippets.

If you haven't set up anything like this, try it out, it might help you. If you do have another way that enables you to quickly try something out, let me know, I'd love to hear it :-)