Theory
One file, three doors
You have a working seat script and, from the last 2 lessons, TWO ways to run Dart already: DartPad in any browser, and the promise of the installed SDK.
The syllabus names three execution routes, and they are not rivals: they are stages of your week: experiment in the browser, verify at the command line, build in the IDE. This short lesson is about knowing which door to walk through, and what each door can and cannot open.
Theory
Door 1: the command line
With the SDK installed (bundled with Flutter, remember), any terminal runs Dart:
- save your code as
app.dart - run it:
dart run app.dart(the classic shorterdart app.dartalso works)
The Dart VM executes it via JIT, and here, unlike DartPad, the program has full machine powers: dart:io works, files open, the fest's registrations.txt is reachable: this is Node's world (BCA405-01 Unit 5), Dart edition.
Bonus door within the door: dart compile exe app.dart produces a standalone native executable: AOT on your desktop.
Practical
app.dart: same script, now with machine powers
// Run from a terminal: dart run app.dart
void main() {
var events = ['Garba Night', 'Coding Contest', 'Robo Race'];
int booked = 310;
int total = 350;
print('Seats left: ${total - booked}'); // 40
for (var e in events) {
print('Event: $e');
}
// Here (unlike DartPad) dart:io WOULD work:
// import 'dart:io'; ... File('log.txt').writeAsStringSync('saved');
}
At a glance
Three ways to execute Dart
| Route | Setup | Powers | Best for |
|---|---|---|---|
| DartPad | None: a browser | Core language only; no files, no packages | Snippets, practice, sharing |
| Command line | Dart/Flutter SDK | Everything: dart:io, packages, compile exe | Scripts; seeing what really happens |
| IDE (Android Studio / VS Code) | SDK + Dart & Flutter plugins | Completion, error underlines, DEBUGGING, projects | Real projects; all Flutter work ahead |
Theory
Door 3: the IDE, and why it wins for projects
Android Studio (your BCA305-02 home) or VS Code, each with the Dart and Flutter plugins installed once (File, Settings, Plugins, search Flutter: it pulls Dart along).
What the IDE adds over a terminal:
- completion and live error underlines: mistakes surface as you type, not at run
- debugging: breakpoints, pause, inspect variables, step line by line: the microscope simple print() cannot be
- project management: the many-file structure every Flutter app has from day 1
From Unit 3 onward, Flutter work effectively REQUIRES this door.
Quiz
Which execution route requires NO installation at all?
- The command line: dart run works on any fresh Windows machine
- DartPad: it runs entirely in the browser
- The IDE: Android Studio ships with Dart built in
- None: every route needs the Dart SDK first
Show the answer
DartPad: it runs entirely in the browser
DartPad's whole identity is zero-setup: editor, compiler and console live in the web page (compiled to JS behind the scenes, as last lesson revealed). The command line (option A) is the opposite: it IS the installed SDK talking. Option C is the plugin trap: Android Studio arrives knowing Java/Kotlin for Android; Dart and Flutter support is added via plugins, a step exams like asking about. The practical takeaway of the whole table: you can start learning Dart TODAY on any machine, and graduate to the SDK when files and projects demand it.
Think first
Assign the door to the day
Three moments from your actual week: (a) 5 spare minutes on a lab PC to test how Dart's switch behaves, (b) practising file writing for the registrations log, (c) starting Unit 3's first Flutter project. Pick the route for each, with the deciding constraint, then tap.
Show the answer
(a) DartPad: zero setup on a machine you do not own; a switch experiment needs no files. (b) Command line: dart:io is the constraint, and DartPad's sandbox forbids it: only a real SDK on a real disk writes registrations.txt. (c) IDE: Flutter projects are many-filed, device-connected and debug-hungry: Android Studio with the plugins is the only comfortable home. The pattern: the CONSTRAINT picks the door: setup available? files needed? project scale?
Watch out
Door-choosing slips
Practising file I/O in DartPad: import dart:io fails there by design: move to the command line for anything touching disk.
Forgetting the plugins: Android Studio without the Dart/Flutter plugins shows .dart files as plain text: install once, restart, done.
dart run vs dart compile exe: run executes NOW via the VM (JIT); compile exe produces a standalone native binary: know both spellings for the exam.
Theory
The tooling tour ends; the language begins
You now know why Dart exists, how it ships, and 3 ways to run it. Tooling knowledge is scaffolding: what remains of this unit is the language itself: the syntax mega-tour next (types, decisions, every loop Dart owns, with your Java reflexes as the guide), then functions with Dart's genuinely new tricks. DartPad open, Java eyes on: the fastest second language you will ever learn.
Summary
Key takeaways
- Command line: dart run app.dart executes via the JIT VM with full machine powers (dart:io works).
- dart compile exe produces a standalone native executable.
- DartPad: zero install, browser-based, sandboxed: snippets and practice.
- IDE (Android Studio / VS Code + Dart & Flutter plugins): completion, live errors, breakpoints, projects: Flutter's home.
- The constraint picks the route: setup, file access, or project scale.
- Android Studio needs the plugins added once: it does not ship Dart-aware.
- Memory hook: pad to play, terminal to touch the disk, IDE to build.