In my previous post, we looked at the construction of a small Flutter app. It was dense, but provided a very strong idea of how Flutter apps are constructed:
- An overall stateless widget that is the app frame and code root.
- The contents, which feels like building a responsive app with JSON and a CSS framework like Bootstrap.
- Relatively simple events, listeners and state changes.
To round things off, I must approach this from a full developer perspective and actually build with it, as was our aim when comparing with Tauri. So it’s time to get started.
I’m developing with a Mac, but not targeting iOS — just MacOS. There is a bit of extra work involved when targeting mobiles, which I won’t cover here. Looking at my options:
In the multitarget world, configurations need to be handled carefully — recommending iOS because I’m on a Mac is a stray signal, even if it is something many are interested in.
Asking for 36GB space as a prerequisite is another cue that this is not a simple project, but an entire workflow. Cocoapods is also required, depending on your target. As expected, Visual Studio Code (or VS Code for short) is supported and recommended (as well as IntelliJ).
Over the past year, I’ve felt the world tilt heavily toward VS Code. So I’ll start with VS Code, which needs to be version 1.77 or newer. Then, install the Flutter extension.
Remember, Flutter is written in Dart code. I can create a new project via the command palette, as we have done a few times before:
Slightly confusingly, it will then ask you to download the Flutter SDK or locate it. Doing this behind an IDE window isn’t ideal, as it could fail. As it is cloning, you’ll also need Git. So it might well be better to do this separately. I had issues from the “Flutter doctor” but they were mainly with versions and putting binaries on paths. It’s very easy to miss query windows within VS Code, however.
I ran the “Flutter Doctor” within a VS Code shell after restarting to confirm if the issues had been fixed.
flutter doctor -v
When you are ready, with the New Project, choose Application and name it something appropriate. I mistakenly called my project namer_app, thinking I was building something else. The template app is much simpler than the Sunflower example explained in my last post, but has the same structure.
I hit build (F5 within Mac).
Eventually it ran the example app — which is a simple window, with a button and fully responsive.
It’s a MacOS app — it has an icon and the standard Mac window frame, but is running in debug mode.
I already went over a much more complex example last week, so I’ll just summarize how the Dart code is organized.
Structurally, the app is represented by a stateless widget. The stateful part, the MyHomePage class, holds the state — which we’ll need to deal with the button and events.
import 'package:flutter/material.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
...
}
class MyHomePage extends StatefulWidget {
...
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
...
}
The MyApp class sets the color theme, creates the title, and creates the MyHomePage class with page title in purple.
class MyApp extends StatelessWidget {
const MyApp({super.key}); // This widget is the root of your application.
@override Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(
seedColor: Colors.deepPurple),
useMaterial3: true, ),
home: const MyHomePage(title: 'Flutter Demo Home Page'),
);
}
}
The _MyHomePageState class has the responsibility to create the screen and increment the button:
class _MyHomePageState extends State<MyHomePage> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
backgroundColor: Theme.of(context).colorScheme.inversePrimary,
title: Text(widget.title),
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
const Text( 'You have pushed the button this many times:',
),
Text(
'$_counter',
style: Theme.of(context).textTheme.headlineMedium,
),
],
),
),
floatingActionButton: FloatingActionButton(
onPressed: _incrementCounter,
tooltip: 'Increment',
child: const Icon(Icons.add),
),
);
}
}
So the build method of the widget creates a Scaffold object, which holds the AppBar, a central Column with the Text and counter objects, and the button. The button clearly sets up the event listener _incrementCounter method, which moves the counter up one and announces a state change — forcing an update. If I hover over the button, it does indeed show the text “Increment” as a tooltip.
The debug app has been fully packaged, and the build result here can be run within the Application folder of my Mac:
To complete the picture, I need to build the app beyond debug mode. The launch configuration file launch.json appears to already have three configurations:
{
"version": "0.2.0",
"configurations": [
{
"name": "namer_app",
"request": "launch",
"type": "dart"
},
{
"name": "namer_app (profile mode)",
"request": "launch",
"type": "dart",
"flutterMode": "profile"
},
{
"name": "namer_app (release mode)",
"request": "launch",
"type": "dart",
"flutterMode": "release"
}
]
}
Now, I realize that we need a task file, and one may exist, but VS Code tends to create one when you need it:
And indeed, if we use the recommended keyboard shortcut (Shift+Command+B), we do get a “release” build:
We now have a Release directory as a sister to the Debug directory. While running this app, we do indeed have a correctly packaged 46MB app that isn’t in debug mode:
Conclusion
There is quite a lot more within the different flavors of launch configuration and deployment; these can, for example, control what assets are included by Flutter within VS Code. You can also work on getting your app into the various app stores if that’s the road you need to take.
Yet again, VS Code, while not astoundingly transparent in its actions, is able to offer a build and deployment scenario — allowing Flutter (in this case) to focus on making good-looking apps. We’ll see more of this combination more in the future.
The post Building With Flutter Using Visual Studio Code: A Dev Guide appeared first on The New Stack.
For Flutter developers, VS Code is able to offer a build and deployment scenario — allowing Flutter to focus on making good-looking apps.