Interacting with the User

// Copy the code up to and including the _buildAgeSwitch
// method from Listing 7-1 here.
 
Widget _buildResultArea() {
return Row(
children: <Widget>[
RaisedButton(
child: Text("Submit"),
onPressed: _updateResults,
),
SizedBox(
width: 15.0,
),
Text(_messageToUser, textAlign: TextAlign.center),
],
);
}
 
/// Actions
 
void _updateAgeSwitch(bool newValue) {
setState(() {
_ageSwitchValue = newValue;
});
}
 
void _updateResults() {
setState(() {
_messageToUser = ’You are’ +
(_ageSwitchValue ? " " : " NOT ") +
’compatible with \nDoris D. Developer.’;
});
}
}

Figure 7-4 shows a snapshot from a run of the code in Listing 7-2.

When it’s combined with some code from Listing 7-1, the app in Listing 7-2 has both onPressed and onChanged event handlers. In particular:

• The function _updateAgeSwitch handles onChanged events for the switch.

  When the user taps the switch, the appearance of the switch changes from off to on or from on to off.

• The function _updateResults handles onPressed events for the button.

  When the user presses the button, the app’s message catches up with the switch’s status. If the switch is on, the message becomes, “You are compatible.” If the switch is off, the message becomes “You are NOT compatible.”

Between the moment when the user flicks the switch and the time when the user presses the button, the message on the screen might be inconsistent with the switch’s state. In an online form with several questions, that’s not a problem. The user doesn’t expect to see a result until after the concluding button press. But in this chapter’s practice apps, each with only one question for the user, the lack of coordination between the user’s answer and the message that’s displayed is problematic. These practice apps don’t win any user experience awards.

Fortunately, Doris doesn’t publish her practice apps. Instead, she publishes an app that combines all the controls from her practice apps and more.

You can download and run Doris’s full-fledged dating app. It’s the file named App_endix.dart in the download from this book’s website. If you need immediate gratification and downloading code isn’t fast for you, just flip this book’s pages until you reach Appendix A.

So, what’s next? I know! How about a slider?

// This is not a complete program. (No way!)
 
class _MyHomePageState extends State<MyHomePage> {
double _loveFlutterSliderValue = 1.0;
 
Widget _buildLoveFlutterSlider() {
return // …
Text("On a scale of 1 to 10, "
"how much do you love developing Flutter apps?"),
Slider(
min: 1.0,
max: 10.0,
divisions: 9,
value: _loveFlutterSliderValue,
onChanged: _updateLoveFlutterSlider,
label: ’${_loveFlutterSliderValue.toInt()}’,
),
 
}
 
void _updateLoveFlutterSlider(double newValue) {
setState(() {
_loveFlutterSliderValue = newValue;
});
}
 
void _updateResults() {
setState(() {
_messageToUser = _youAre +
(_loveFlutterSliderValue >= 8 ? " " : " NOT ") +
_compatible;
});
}
}

Figure 7-5 shows a run of the slider app with the slider set all the way to 10. (How else do you expect me to set the “love Flutter” slider?)

The Slider constructor call in Listing 7-3 has these six parameters:

• min: The slider’s smallest value.

  The little gizmo that moves from left to right along a slider is called a thumb. The position of the thumb determines the slider’s value. So min is the value of the slider when the slider’s thumb is at the leftmost point. The min parameter has type double.

• max: The slider’s largest value.

  This is the value of the slider (again, a double) when the thumb is at the rightmost point.

  A slider’s values may increase going from left to right or from right to left. Before displaying a slider, Flutter checks a textDirection property. If the value is TextDirection.ltr, the slider’s minimum value is on the left. But if the textDirection property’s value is TextDirection.rtl, the slider’s minimum value is on the right. Apps written for speakers of Arabic, Farsi, Hebrew, Pashto, and Urdu use TextDirection.rtl. Other apps use TextDirection.ltr. In case you’re wondering, Flutter doesn’t support boustrophedon writing — an ancient style in which alternate lines flow from left to right and then from right to left.

• divisions: The number of spaces between points where the thumb can be placed. (See Figure 7-6.)

  

  The slider in Listing 7-3 can be placed at values 1.0, 2.0, 3.0, and so on, up to 10.0.

  If you omit the divisions parameter, or if you set that parameter to null, the thumb can be placed anywhere along the slider. For example, with the following constructor, the slider’s value can be 0.0, 0.20571428571428554, 0.917142857142857, 1.0, or almost any other number between 0 and 1.

  Slider(
min: 0.0,
max: 1.0,
value: _loveFlutterSliderValue,
onChanged: _updateLoveFlutterSlider,
)

• value: A number in the range from min to max.

  This parameter determines the thumb’s position.

• onChanged: The event handling function for changes to the slider.

  When the user moves the slider’s thumb, the Flutter framework calls this function.

• label: The widget that’s displayed on the slider’s value indicator.

  As the user moves the thumb, an additional shape appears. That shape is the slider’s value indicator. In Figure 7-5, the bubble with the number 10 on it is the slider’s value indicator.

  Despite its name, the value indicator doesn’t necessarily display a Text widget showing the slider’s value. In fact, the value indicator can display anything you want it to display. (Well, almost anything.)

  Luckily for us, the widget on the slider in Listing 7-3 displays _loveFlutterSliderValue — the slider’s very own value. But remember: If you don’t want numbers like 0.20571428571428554 to appear in the value indicator, you have to convert the slider’s double values into int values. That’s why, in Listing 7-3, the widget on the slider’s value indicator displays _loveFlutterSliderValue.toInt(), not plain old _loveFlutterSliderValue.

  If you don’t specify a label parameter, or if you specify a label but make it null, the value indicator never appears.

void _updateStuff(String newValue) {
// When the user types a character, do something with
// the characters inside the text field (the newValue).
}

But what about the press of a button? Is there a nice way to find out what’s in a text field when the field’s characters aren’t changing? Yes, there is. It’s the TextEditingController — a stand-out feature in Figure 7-7.

In fact, Figure 7-7 has two TextEditingController objects — one for the Your Name field and another for the Your Income field. The next several paragraphs add details to the numbered callouts in Figure 7-7.

Callouts 1 and 2

In a Flutter program, constructor calls rule the roost. You get a Text widget with a constructor call like Text("Hello"). You get a Column and two Text widgets with code like Column(children: [Text(’a’), Text(’b’)]).

When you issue a constructor call, the call itself stands for an object. For example, the call Text("Hello") stands for a particular Text widget — an instance of the Text class. You can assign the call to a variable and use that variable elsewhere in your code:

@override
Widget build(BuildContext context) {
Text myTextInstance = Text("I’m reusable");
return Scaffold(
appBar: AppBar(
title: myTextInstance,
),
body: Column(
children: <Widget>[
myTextInstance,
],
),
);
}

In many cases, you can separate the variable declaration from the call:

Text myTextInstance;
 
// More code here, and elsewhere …
 
myTextInstance = Text("I'm reusable");

In Figure 7-7, the declaration of the two controller variables (_nameFieldController and _incomeFieldController) is separate from the corresponding TextEditingController constructor calls. I do this in order to introduce Flutter’s initState and dispose methods.

A State object is like anything else in the world — it comes into being and, eventually, it goes away. Flutter calls initState when a State instance comes into being, and calls dispose when the State instance goes away.

It may not be obvious, but the code in Figure 7-7 refers to two different initState methods. The declaration that begins with void initState() describes a method that belongs to the _MyHomePageState class. But the _MyHomePageState class extends Flutter’s own State class, and that State class has its own initState declaration. (See Figure 7-9.)

When you have two methods named initState, how do you distinguish one from another? Well, what if you meet a woman named Mary, whose child is also named Mary? Chances are, the child doesn’t call her mother “Mary.” Instead, the child calls her mother “Mom” or something like that. For her mother’s birthday, she buys a souvenir mug displaying the words Super Mom, and her mother smiles politely on receiving another useless gift.

The same kind of thing happens when two classes — a parent and its child — have methods named initState. The child class (_MyHomePageState) has to call the initState method belonging to its parent class (Flutter’s State class). To do so, the child class calls super.initState(). Unlike the Mary situation, the use of the keyword super isn’t meant to be flattering. It’s simply a reference to the initState method that’s defined in the parent class. (I can’t resist: The keyword super may not be flattering, but it’s certainly Fluttering.)

To stretch the mother/daughter metaphor a bit further, imagine that Super Mom Mary is a real estate agent. In that case, the child can’t buy a house without first consulting her mother. The child’s decideWhichHouse method must include a call to the mother’s decideWhichHouse method, like so:

// The child’s method declaration:
@override
void decideWhichHouse() {
super.decideWhichHouse();
// Etc.
}

That may be the situation when your code overrides Flutter’s initState method. In some versions of Flutter, if you don’t call super.initState(), your code won’t run.

// This listing is missing some parts. See App0705 in the files that
// you download from this book's website (www.allmycode.com/Flutter).
 
enum Relationship {
Friend,
OneDate,
Ongoing,
Committed,
Marriage,
}
 
Map<Relationship, String> show = {
Relationship.Friend: "Friend",
Relationship.OneDate: "One date",
Relationship.Ongoing: "Ongoing relationship",
Relationship.Committed: "Committed relationship",
Relationship.Marriage: "Marriage",
};

List<DropdownMenuItem<Relationship>> _relationshipsList = [
DropdownMenuItem(
value: Relationship.Friend,
child: Text(show[Relationship.Friend]),
),
DropdownMenuItem(
value: Relationship.OneDate,
child: Text(show[Relationship.OneDate]),
),
DropdownMenuItem(
value: Relationship.Ongoing,
child: Text(show[Relationship.Ongoing]),
),
DropdownMenuItem(
value: Relationship.Committed,
child: Text(show[Relationship.Committed]),
),
DropdownMenuItem(
value: Relationship.Marriage,
child: Text(show[Relationship.Marriage]),
),
];
 
class _MyHomePageState extends State<MyHomePage> {
Relationship _relationshipDropdownValue;
 
// And later in the program …
 
/// Build
 
Widget _buildDropdownButtonRow() {
return Row(
mainAxisAlignment: MainAxisAlignment.start,
children: <Widget>[
DropdownButton<Relationship>(
items: _relationshipsList,
onChanged: _updateRelationshipDropdown,
value: _relationshipDropdownValue,
hint: Text("Select One"),
),
if (_relationshipDropdownValue != null)
FlatButton(
child: Text(
"Reset",
style: TextStyle(color: Colors.blue),
),
onPressed: _reset,
),
],
);
}
 
Widget _buildResultsImage() {
if (_relationshipDropdownValue != null) {
return Image.asset((_relationshipDropdownValue.index >= 3)
? "Heart.png"
: "BrokenHeart.png");
} else {
return SizedBox();
}
}
 
/// Actions
 
void _reset() {
setState(() {
_relationshipDropdownValue = null;
});
}
 
void _updateRelationshipDropdown(Relationship newValue) {
setState(() {
_relationshipDropdownValue = newValue;
});
}
}