Theory
Say it without stopping anyone
Booking saved. The user should KNOW: but last lesson's dialog would be rude: a modal interrogation for a mere FYI.
Android solved this years ago with the Toast: a small passing message that dismisses itself. Your syllabus asks for Flutter's version: and here waits an honesty checkpoint that separates students who memorise from students who know: Flutter has no built-in Toast widget at all. What it has is arguably better.
Theory
SnackBar: Flutter's native passing message
The Flutter idiom for toast-shaped news is the SnackBar: a strip that slides up from the bottom, waits, and leaves:
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text('Booking saved'),
duration: Duration(seconds: 2),
),
);
The ScaffoldMessenger is the dispatcher (which is one reason screens start with a Scaffold: the lesson that keeps paying). And a SnackBar carries one power a toast never had: an action: the famous UNDO.
Practical
Saved, said politely, with an exit
void onBookingSaved() {
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: const Text('Garba Night booked!'),
duration: const Duration(seconds: 3),
action: SnackBarAction( // the power a Toast never had
label: 'UNDO',
onPressed: () { /* release the seat */ },
),
),
);
}
// The reminders setting: Switch, the controlled law's 4th witness
bool reminders = true;
SwitchListTile(
title: const Text('Event reminders'),
value: reminders,
onChanged: (v) {
setState(() { reminders = v; }); // flips AND takes effect now
},
)
Theory
Switch: same machinery, different promise
Mechanically, Switch is Checkbox's twin: value: a bool, onChanged: + setState, null disables: the controlled-widget law testifying for the fourth time. SwitchListTile is the labelled-row form.
The difference is the PROMISE to the user:
- a switch flips a setting that acts immediately: reminders on, dark mode on: no Submit button follows
- a checkbox marks a choice a form will submit later: carry bag, terms accepted
Same bool underneath; different social contract on screen. Choosing by that contract is a design mark examiners genuinely award.
Quiz
Your syllabus says Toast. What is the honest, exam-safe statement about Toast in Flutter?
- Flutter ships a Toast widget: Toast.show(context, 'message')
- Flutter has no built-in Toast: SnackBar is the native equivalent, and Android-style toasts come from the fluttertoast package
- Toasts in Flutter are AlertDialogs with a short duration
- SnackBar and Toast are 2 names for the same built-in widget
Show the answer
Flutter has no built-in Toast: SnackBar is the native equivalent, and Android-style toasts come from the fluttertoast package
The honest map has 3 landmarks: no built-in Toast exists; SnackBar is the framework's own passing message (bottom strip, auto-dismiss, optional action); and the pub.dev PACKAGE fluttertoast supplies literal Android-style floating toasts for those who want them. Option A invents an API: the trap for students who assume every Android noun has a Flutter twin. Option C confuses passive FYI with modal interrogation: last lesson drew exactly that line. Option D merges 2 distinct things: one is a widget Flutter ships, the other a concept it deliberately did not.
Think first
Switch or checkbox? Rule on 4 rows
Four rows from FestConnect Flutter's screens: (a) Event reminders on/off in Settings, (b) I agree to the fest rules on the registration form, (c) Dark mode in Settings, (d) Add a carry bag on the booking form. Assign switch or checkbox by the PROMISE, then tap.
Show the answer
(a) and (c): switches: settings that take effect the moment they flip, no submission ceremony. (b) and (d): checkboxes: choices that mean nothing until the form's Book/Register button submits them. The test in one question: does flipping it act NOW, or is it part of something submitted LATER? Same bool, same setState: the widget choice is a message about timing, and mixing them (a switch on a form, a checkbox in settings) quietly confuses users on every platform.
Watch out
Passing-message slips
Stacking snackbars: firing several queues them for seconds each; showSnackBar after removing the current one (hideCurrentSnackBar) keeps news fresh.
Vital info in a SnackBar: it self-dismisses: anything the user MUST act on belongs in a dialog; anything they must merely know can pass by.
UNDO that cannot undo: offering the action obliges you to implement the release: an UNDO that shrugs is worse than none.
Theory
The interruption spectrum, complete
You now hold Flutter's full spectrum of speaking to the user: Tooltip whispers on request, SnackBar mentions in passing, AlertDialog stops and asks: escalate only as far as the news demands (the ErrorProvider-vs-MsgBox judgement from BCA404, cross-platform at last). One lesson remains in the entire subject: charts and the Form widget: FestConnect Flutter's registration, validated and finished.
Summary
Key takeaways
- Flutter ships no Toast: say so; SnackBar is the native passing message, fluttertoast the package route.
- ScaffoldMessenger.of(context).showSnackBar(SnackBar(content, duration, action)): bottom strip, auto-dismiss.
- SnackBarAction gives the one-tap UNDO a toast never had.
- Switch: value + onChanged + setState: the controlled law's fourth witness; SwitchListTile for rows.
- Switch = setting acting NOW; checkbox = choice submitted LATER: same bool, different promise.
- Escalate interruptions honestly: tooltip, snackbar, dialog.
- Memory hook: snackbars pass by, switches act now, no toast lives here.