Laying Things Out

child: buildColumn(context),
 
// … And elsewhere, …
 
Column(
// … Blah, blah, …
children: <Widget>[
buildTitleText(),
SizedBox(height: 20.0),
buildRoundedBox(
// … Etc.

Each method call takes the place of a longer piece of code — one that describes a particular widget in detail. I create these methods because doing so makes the code easier to read and digest. With a glance at Listing 6-2, you can tell that the Column consists of title text, a sized box, and a rounded box. You don’t know any of the details until you look at the buildTitleText and buildRoundedBox method declarations in Listing 6-1, but that’s okay. With the code divided into methods this way, you don’t lose sight of the app’s overall outline.

In the design of good software, planning is essential. But sometimes your plans change. Imagine this scenario: You start writing some code that you believe will be fairly simple. After several minutes (or, sometimes, several hours), you realize that the code has become large and unwieldy. So you decide to divide the code into methods. To do this, you can take advantage of one of Android Studio’s handy refactoring features. Here’s how it works:

1. Start with a constructor call that you want to replace with your own method call.

   For example, you want to replace the Text constructor call in the following code snippet:

   children: <Widget>[
Text(
"My Pet Shop",
textScaleFactor: 3.0,
textAlign: TextAlign.center,
),
SizedBox(height: 20.0),

2. Place the mouse cursor on the constructor call’s name.

   For the snippet in Step 1, click on the word Text.

3. On Android Studio’s main menu, select Refactor ⇒   Extract ⇒   Method.

   As a result, Android Studio displays the Extract Method dialog box.

4. In the Extract Method dialog box, type a name for your new method.

   For a constructor named Text, Android Studio suggests the method name buildText. But, to create Listings 6-1 and 6-2, I made up the name buildTitleText.

5. In the Extract Method dialog box, press Refactor.

   As if by magic, Android Studio adds a new method declaration to your code and replaces the original widget constructor with a call to the method.

   The new method’s return type is whatever kind of widget your code is trying to construct. For example, starting with the code in Step 1, the method’s first two lines might look like this:

   Text buildTitleText() {
return Text(

6. Do yourself a favor and change the type in the method’s header to Widget.

   Widget buildTitleText() {
return Text(

   Every instance of the Text class is an instance of the Widget class, so this change doesn’t do any harm. In addition, the change adds a tiny bit of flexibility that may eventually save you some mental energy. Maybe later, you decide to surround the method’s Text widget with a Center widget.

   // Baby, you’re no good . . .
Text buildTitleText() {
return Center(
child: Text(

   After you make this change, your code is messed up because the header’s return type is inaccurate. Yes, every instance of the Text class is an instance of the Widget class. But, no, an instance of the Center class isn’t an instance of the Text class. Your method returns an instance of Center, but the method’s header expects the method to return an instance of Text. Don’t you wish you had changed the first word in the header to Widget? Do it sooner rather than later. That way, you won’t be distracted when you’re concentrating on making changes in the method’s body.

Widget buildRoundedBox(
String label, {
double height = 88.0,
})

The method has two parameters: label and height.

• The label parameter is a positional parameter.

  It’s a positional parameter because it’s not surrounded by curly braces. In a header, all the positional parameters must come before any of the named parameters.

• The height parameter is a named parameter.

  It’s a named parameter because it’s surrounded by curly braces.

  In a call to this method, you can omit the height parameter. When you do, the parameter’s default value is 88.0.

With these facts in mind, the following calls to buildRoundedBox are both valid:

https://api.flutter.dev/flutter/dart-ui/Color-class.html

Padding(
padding: const EdgeInsets.symmetric(
horizontal: 20.0,
),
child: buildColumn(context),

surrounds the buildColumn call with 20.0 units of empty space on the left and the right. (Refer to Figure 6-1.) With no padding, the column would touch the left and right edges of the user’s screen, and so would the white Sale Today box inside the column. That wouldn’t look nice.

In Flutter, a line such as horizontal: 20.0 stands for 20.0 density-independent pixels. A density-independent pixel (dp) has no fixed size. Instead, the size of a density-independent pixel depends on the user’s hardware. In particular, every inch of the user’s screen is roughly 96 dp long. That makes every centimeter approximately 38 pixels long. According to Flutter’s official documentation, the rule about having 96 dp per inch “may be inaccurate, sometimes by a significant margin.” Run this section’s app on your own phone, and you’ll see what they mean.

In Flutter, you describe padding of any kind by constructing an EdgeInsets object. The EdgeInsets.symmetric constructor in Listing 6-1 has one parameter — a horizontal parameter. In addition to the horizontal parameter, an EdgeInsets.symmetric constructor can have a vertical parameter, like so:

Column(
mainAxisAlignment: MainAxisAlignment.center,
crossAxisAlignment: CrossAxisAlignment.stretch,
// … And so on.

The mainAxisAlignment property comes up in Chapter 3. It describes the way children are positioned from the top to the bottom of the column. With MainAxisAlignment.center, children gather about halfway down from the top of the screen. (Refer to Figure 6-1.) In contrast, the crossAxisAlignment describes how children are situated from side to side within the column. (See Figure 6-2.)

A column’s crossAxisAlignment can make a big difference in the way the column’s children appear on the screen. For example, if you comment out the crossAxisAlignment line in Listing 6-2, you see the screen shown in Figure 6-3.

In Listing 6-2, the CrossAxisAlignment.stretch value tells the column that its children should fill the entire cross axis. This means that, regardless of the children’s explicit width values, children shrink or widen so that they run across the entire column. If you don’t believe me, try the following experiment:

1. Run the code in Listing 6-1.

   Use the iPhone simulator, the Android emulator, or a real physical phone. Start with the device in portrait mode, as in Figure 6-1.

2. Turn the device sideways so that the device is in landscape mode.

   If you’re running a virtual device, press Command-right arrow (on a Mac) or Ctrl+right arrow (on Windows). If you’re running a physical device, turn the darn thing sideways.

3. Observe the change in the size of the Sale Today box.

   No matter how wide the screen is, the Sale Today box stretches almost all the way across. The width: 88.0 setting in Listing 6-1 has no effect.

You can read more about axis alignments in the sections that follow.

When you turn a device sideways, the device might not switch between portrait and landscape modes. This is true for both physical devices (real phones and tablets) and virtual devices (emulators and simulators). If your device’s orientation refuses to change, try this:

• On an Android device, in Settings ⇒   Display, turn on Auto Rotate Screen.
• On an iPhone or iPad, swipe up from the bottom of the screen, and press the button that displays a lock and a circular arrow.

With an emulator or a simulator, you can try turning the computer monitor sideways, but that probably won’t work.