One of my favorite classes in OSU’s online CS degree program was CS492 Mobile Development. I’ve always wanted to make my own iOS/Android app and CS492 gave me enough of a foundation to attempt it.
In this multi-part “journal” series, I’ll share all the major steps and decisions I made as I developed a Flutter app.
- Part 1 – Flutter installation and environment setup
- Part 2 – Structuring the app’s main screen UI
- Part 3 – Navigating between app screens with routes
- Part 4 – Refactors and improvements
- Part 5 – Hooking up Firebase to my Flutter project
- Part 6 – Developing the create, read, and update features
- Part 7 – A ton of feature work
- Part 8 – User accounts [someday]
In this post: some set-up hurdles I encountered on my MacBook. If you want to skip setup and go to the beginning of the code, go ahead to part 2.
Initial Flutter set up
For the most part, setting up Flutter was easy – I followed the official docs and it took me about 45 minutes to get the sample app running. (I’m on a new MacBook running macOS Catalina 10.15.3.)
I ran into a few hurdles, though, which I’ve documented here for other Mac users and for my future self (because I will inevitably go through this again someday).
Adding Flutter to the $PATH on a Mac
I followed the doc’s example of creating a “development” folder in my Users/mandi directory.
I wanted to follow the Flutter documentation example for adding Flutter to my path permanently, but I didn’t know how to find the PATH_TO_FLUTTER_GIT_DIRECTORY on my machine. I know I made a ‘development’ folder, but I don’t know what’s “before” it in its file path.
As it turns out, there’s a handy trick you can do using Finder and a Terminal window to get the full path to a directory or file.
Dragging the ‘development’ folder into Terminal reveals its full path.
That was what I needed to run:
export PATH="$PATH:/Users/mandi/development/flutter/bin"
source ~/.zshrcUnfortunately, this didn’t “stick” on my machine. It worked for the Terminal window I was in, but as soon as I opened a new Terminal window the “flutter” command was no longer found.
It’s still in there if I echo $PATH, so I’m not sure what’s wrong here. But I’m not the only person who ran into this issue, as evidenced by this Stack Overflow post. Kaushik Bharadwaj’s answer explains how to add it to the path file permanently.
In a Terminal window, enter:
sudo nano /etc/paths
Add the full path to the flutter/bin folder [this is what mine looks like, yours may vary] to this file and save it:
/Users/YOURNAMEHERE/development/flutter/bin
On my machine, the paths file looks like this:
Now the “flutter” command persists through Terminal window closures, reboots, etc.
IDE for Flutter
There are a bunch of choices but I’ve only used Android Studio for Flutter development so far. I’m happy with it and it’s pretty good at formatting Flutter’s copious amounts of nested code.
If you choose Android Studio, beware that the default project setting might be “Android”. You can change that by clicking the little Project dropdown in the upper left corner and selecting “Project” instead of “Android”.
That should give you a nice view of the project structure, like so:
This step is unnecessary but it’ll get rid of the weird “Java” folder that isn’t represented in the project structure if you view it in Terminal or Finder and it’ll make your environment look like the one I’ll be sharing in screenshots throughout this journal.
Emulators
There are a few to pick from. I’m on a MacBook and I find that the iOS Simulator runs way better than the Android simulator. In Android Studio, they appear here in the top bar:
On a Mac it “just works” with the built-in Simulator (which is iOS-specific). I’m not sure what’s involved in other dev environments but I’ll come back to this when I try to build for Android later.
Final checks with Flutter Doctor
In Terminal, using flutter doctor will show the status of your flutter setup. You don’t actually need a checkmark next to everything in this list to start coding, but when it’s time to push your app onto a device you’ll want to clear out the “!” and “x” marks where appropriate.
Here is my flutter doctor output at the time of this writing. I’ll come back to these later when it’s time to test on an actual device – this is good enough to get started.
With the project set up, it’s time to move on to Part 2 where I’ll show you how I built the main page’s UI.