Every time you create a new Flutter project, you’re greeted with the proverbial ‘counter app’ with its Scaffold widget. It’s a common widget used with the Material interface design and often uses another common widget, the AppBar. The AppBar is seen as a fixed band (or bar) placed along the top of the screen. It serves as a navigational tool listing along its length a number of pre-defined icons and or text. The user is to tap on these listed items so to generate and present a different screen.
In this article, we’re going to review the AppBar widget’s parameters one by one using a little app I whipped up for this exercise. It’s available to you for download on Github called, appbar_example. You can then ‘look under the hood’ at the code and see how to use AppBar widget’s many parameters.
I Like Screenshots. Click For Gists.
As always, I prefer using screenshots in my articles over gists to show concepts rather than just show code. I find them easier to work with frankly. However, you can click or tap on these screenshots to see the code in a gist or in Github. Further, it’s better to read this article about mobile development on your computer than on your phone. Besides, we program mostly on our computers — not on our phones. Not yet anyway.
No Moving Pictures, No Social Media
There will be gif files in this article demonstrating aspects of the topic at hand. However, it’s said viewing such gif files is not possible when reading this article on platforms like Instagram, Facebook, etc. They may come out as static pictures or simply blank placeholder boxes. Please, be aware of this and maybe read this article on medium.com
We’ll work our way down the AppBar’s named parameters and illustrate how each affects the appearance of the app bar and the general ‘look and feel’ of the app overall. This widget is, in fact, a StatefulWidget. That means it has a corresponding State object (_AppBarState) that retains some values for the duration of the app. Below is a screenshot of the AppBar widget.
Implements A Preferred Size
Further note, the widget implements another class called, PreferredSizeWidget. Unlike Java with its explicit Interface types, Dart has implicit Interfaces. In Dart, as you see in the screenshot above, you can assign any class as ‘an interface’ to any other class by simply specifying it with the keyword, implements. That means, however, you’ve now some further work to do. All the functions from that class will need to be re-implemented in your own class (unless yours is an abstract class). Further, any instance fields from that class will need to be re-assigned values — otherwise, they’re null.
In the case of the AppBar class implementing the class, PreferredSizeWidget, it is the instance field, preferredSize, that now has to be assigned a value. You see, it’s seen as the height in which the AppBar widget would prefer to be if it were unconstrained. In most cases, that height is the sum of [toolbarHeight] and the [bottom] widget’s preferred height forming a band (a bar) along the top of the screen.
Play With Your AppBar
Again, the sample app on Github, will allow you to try out to some degree each and every parameter offered by the AppBar widget. Note, its parent widget, in this case, is the Scaffold widget and is also using a Drawer widget in this app. It this drawer that you’ll use to adjust the AppBar’s parameter values:
Let’s Take The Lead
Ok, let’s start with the named parameter, leading. It usually takes in an Icon widget or an IconButton widget and begins what can be a number of widgets that will appear along the length of the app bar.
However, since the example app we’re using utilizes a Drawer widget to change the app bar’s parameter values, you’re going to get a menu icon presented in what would be the ‘leading’ location on the app bar (the user taps on the icon to open the drawer). If there was no Drawer, and the named parameter, leading, was set to false, there would be nothing displayed at the location at all — since this is the home screen of the app. However, if this was a secondary screen in the app, there would then be a ‘back arrow’ to get back to the home screen. Clear as mud, right?
To illustrate it does have some functionality even in this app with its Drawer widget, setting the parameter, leading, to true will change the ‘menu’ icon to the ‘pizza’ icon. Of course, turning off the ‘leading’ switch will return the drawer’s standard menu icon.
It’s Implying A Lead
Ok, not very interesting so far, but let’s see what else these parameters can do for you. Notice the next parameter is named, automaticallyImplyLeading. By default, it’s always set to true. This is so a ‘back arrow’, for example, is made available for a secondary screen. If you set it to false in this app (while leading is also false), you’re going to find even the Drawer menu icon disappears!
Oops. Now, how are we going to continue without the Drawer?? Well, by incrementing the counter, you’ll get the menu icon back. Opening the drawer, you’ll see the switch for the parameter, automaticallyImplyLeading, is back on again giving you now an idea of how those first two work together.
What’s Your Title?
The next parameter is pretty straight forward. If you don’t supply a title to the AppBar, there isn’t one.
It’s Not All True Or False
By the way,not all of AppBar’s parameters are boolean values. In fact, most are not boolean values — they’re Widgets of one form or another or numeric values. Using this sample app, however, it’s much easier for demonstration purposes to tap a switch and impose some pre-defined value onto the AppBar. When I turned off the title, for example, I merely supplied that parameter by the same name with null. In most instances that parameter is supplied a Text widget. Below is a screenshot listing the data types of all the AppBar parameters we’re walking through, today.
Where’s The Action?
The next parameter is literally a list of Widgets you can supply to the app bar. I picked two icons usually used in the ‘actions’ section of the app bar. One invokes a search routine, in many cases; the other may open a popup menu.
The next parameter is a widget called, flexibleSpace, and is situated actually behind the app bar and stretches with the height of the app bar. In my simple app, I merely place a Text widget stating, ‘This is behind the Title.’
Your Bottom Bar
There’s a further bottom bar (highlighted orange in the sample app) that’s available to you. Traditionally, it takes in a TabBar widget displaying a horizontal row of tabs.
Elevate the Bar
This controls the size of the shadow cast below the app bar. If not specified, the app turns to the ThemeData.appBarTheme. If that is also null, the default value is 4. You have a slider in the sample app, to vary that value up to 16.
Elevate the shadow and pass a Color object to the parameter, shadowColor, and see what happens. A hue of color will be assigned to that very shadow.
The Shape Of Things
Supply a ShapeBorder object to the parameter, shape, and you can change the shape of that what is usually a simple band across the top of the screen.
Pretty straightforward, supply a Color object to the parameter, backgroundColor, and as you see below, you have a new color.
Note, how the phone’s toolbar indicators are changed from white to black.
Explitly define the color, opacity, and size for the app bar icons.
You can separately define ‘the theme’ of the list of widgets provided by the parameter, actions.
Explitly define the color, opacity, and size for the app bar icons.
Primary is a boolean value, and by default, is set to true. When true, the app bar’s height is its preferred height plus the height of the phone’s system status bar listed above. Setting this to false does not include the system bar’s height.
In the AppBar’s State object, _AppBarState, you literally see what a boolean value of true in the primary parameter results in wrapping the whole AppBar object in a SafeArea widget which then provides sufficient padding (equal to the height of the status bar) to avoid the status bar at the top of the screen.
I’ll let you try that switch for yourself.
Sets the spacing around the title on the horizontal axis.
It is the opacity of the app bar’s contents. Decrease its value will increase the title’s transparency.
It the opacity of the bottom portion of the app bar.
You can explicitly set the height of the app bar.
Defines the actual width of the leading widget. The default is 56 logical pixels.
That’s A Wrap
Again, the sample app, appbar_example, is available to you for download on Github. If anything, you can take a look and see the Drawer widget’s role in changing the App bar’s settings anyway.