[MUSIC] >> A UI is composed of several different kind of categories of UI elements that are part of the way that the idea of the high level design concepts of the human interface guidelines become made concrete in an actual user interface. So, what I'd like to do is look at that user interface composition and try and get our head around the different ways in which we can construct a user interface. There's kind of four different categories of UI elements in the UI kit that are relevant for thinking about. They are bars, content views, controls and temporary views. You'd probably encounter them in several different places but maybe haven't though about them as being grouped together as sort of a similar UI element. So, starting with bars, for example. We can see bars in, for example, this to do app called Things. There's a bar located at the top, and this is something that would be called the Navigation Bar. What the Navigation Bar's supports is it supports a moving between different views and being able to get back to other views, and helping you to know which view you're in. So, in this case, the navigation bar says today, meaning this is a view showing the to-dos for today. And then, if you wanted to get back to the list, you can see, kind of hidden under the arrow there, there's a navigation back to previous display called lists. So, this is a navigation bar. It's a user interface element. Another kind of bar is located down at the bottom. And this is a tool bar. A tool bar is like a navigation bar, but it's not about moving between views. It's about applying interactivity to what's in the current view. And it's just a common interface metaphor that is supported through the UI kit. Generally speaking, bars have this role. They allow context relevant UI elements to be displayed. Those elements help to provide information. For example, where you are within an application that can move through several different views. Today, this week, a month, or a list, or a detail pane. They support app navigation, moving between those different scenes. And in the case of the tool bar, they initiate actions perhaps about moving between views, but also on the content that's currently being shown. A second category is content views. And content views are kind of the workhorse of an app. And you can recall that this reflects back to the high level design concept of letting the content shine through and making the user interface kind of fade to the background. So, there are a lot of different kinds of Content Views. One, for example, is the Map View. So, in this slide, what you see is an arrow pointing to a map view. It looks like I'm pointing to a specific location on the map. But actually, what I'm pointing to is that the entire rectangle that contains the map in it. That whole thing is the map view. And above it there's a little navigation bar, or a little search bar. And below it is a tool bar. But that main view consists of a content view which is specifically about displaying a map, manipulating the data there, zooming in, zooming out with gestures, like pinch in and pinch out. Scrolling around, highlighting different locations and points of interest on that map. That whole container is a map view for showing content related to maps. Another example of a content view is a collection view. Here we see a collection view that's been implemented as part of the Photos app. And in it we have a selection of different photographs from my photo album.. And the collection view contains that entire rectangular panel that's the same size as the map view. But from the top navigation bar where it says All Photos all the way down to the tool bar that has the shared Cloud icon in the bottom. That whole pane with the four by six of photos is the collection view container for content. In general, content view are app specific whether it's a map or it's a collection view or it's something else. There aren't just two. And they are responsible for managing data that you want to show in your app. They might support scrolling through the presentation of the data. In the map view, scrolling has a geographic metaphor. In the photos view, scrolling is more about going through, not a list, but a presentation of thumbnails. The content view might also allow you to add new data. For example, adding new photos or adding points to a map. Deleting photos, for example, deleting points or deleting photos. Editing them, perhaps moving their order or changing, adding a filter to a photo. Or manipulating data. Just changing the presentation of it. Making the thumbnails larger or smaller. There are all kinds of different ways, but that are app specific to the particular kind of data that you're looking at. And the particular way in which you manipulate that data. So, second category, Content Views. Third category are Controls. Controls are often embedded in the first two kinds of views. And, actually, the fourth view as well. You can think about a Control as being kind of a button, or a button in a specialized situation. So, one example of a Control is the Segmented Control. The Segmented Control here, shown in the music app, allows an analogous kind of control to what you might have seen in a tab bar where you select several different views of data by choosing a different segmented control. And in this case, my music has been selected and it filters out what's shown in the content below it. Another kind of control is a button. And in this case, those three dots represent a borderless button. As we saw on a previous lecture, Apple's promoting the idea of buttons without borders. These buttons support when you click on it, the metaphor three dots is to provide functionality, more functionality. Whatever that means in the context of what it's next to. And then, finally, we see a bunch of buttons that are embedded within the tool bar. And here we have buttons that enable some kinds of navigation, as well as buttons that enable you to identify things that you're interested in. For example, favoriting different songs if you're interested. A final category, a fourth category, is temporary views. Oh, in summary, so what control views do is they perform actions. You interact with a control, press a button, performs an action in response. And it also displays information. So, it may tell you where you are in the navigation, or might display the nature of the filter that's being applied to the data. So, you're not seeing all the data, you're seeing some data that's been filtered. And that control might show you what the filter that has been applied is. The fourth category are temporary views. And these are alerts, modal pop-ups that show up, that obscure the data or the content view behind it. And, generally, prevent you from moving on until you address the nature of the view. So, in this case is an example of an alert view. This is an alert view that comes up if you're in a web browser and you're trying to get to a particular website but you can't get on the data network. You'll get an alert view that says could not activate cellular data network. And this blocks your ability to do anything else until you hit OK and you clear it. So, it's used for sort of important information that the user has to acknowledge before being able to move on. Another alert is this one here. This is a redirect. So, opening a particular URL in a browser might cause you to invoke another app. In this case, this URL asks to open the News app. And you have to either agree to that or switch out of the current Safari app context and go to the News app context by hitting Open or hitting Cancel and just staying where you are in the current Safari application. Temporary views, as a general description of the category, appear briefly. They're interruptive. They interrupt. They display important information, or they should display important information. And they provide some additional functionality, usually some kind of response to that important information whether it's just acknowledgement that you've read it or action that you can take in response. All of these elements, each of those categories, are UI elements that in the code inherit from a UI view class. They are descendants of a UI view class. And UI View Classes, as a general property, have the ability to draw or render themselves on the screen. So, in one sense, there's this idea that a map view is this abstract collection of data. But at some point that abstract collection of data, whether it's a map or photos, a list of songs, at some point that data that's held in memory has to be converted in to something that can be seen on the screen. And that process of converting the data in to something that can be seen on the screen is drawing it or rendering it. So, things that are children of UI views can render themselves when asked to. And they are usually asked to render themselves within a particular size window. Particular size screen real estate. The other thing that UI views can do is they can receive events. If someone interacts with a UI view by touching on it or performing a gesture, or a force touch or a swipe, UI views have the ability to capture that event and respond to it in a way that either they inherit from their super class or they decide to implement specially for their particular application, whatever it is. So, they can both draw, sort of provide output, and they can receive events or receive input, output and input from a UI view. Almost always, and this isn't just in iOS, but almost in every UI programming framework whether it's Android or it's Java or it's iOS, they're almost always described in terms of a hierarchy. A hierarchy where there's one thing at the top, and that thing at the top is a parent, and the parent has children. And that abstract structure is a tree that proceeds from a top level element to bottom level elements. And in the case of the UI, we say that the parent elements are containers, or holders, for any of the children that are underneath them. So, a parent may be responsible for a particular region of the screen. The root element being responsible for the entire screen. And then, each of the children is assigned to a different sub-portion of the screen that is within the bounds of it's parent container. So, parent components have child elements. That's the language that we use. Or we can say that containers have UI elements. When we decide to, within the Operating System, when an event is received, the event generally is received by the parent. And if the parent doesn't want to handle that event, it will pass it down to the child that is in the correct region for that event. Most of the time that's handled automatically for you. But it does flow down this chain to produce a sequence of events through each of the elements in the hierarchy. Now, abstractly we might see this as a diagram like here on the left where the root element is the window, or the thing that has responsibility for the entire IOS screen. And maybe within that there's a Navigation Controller that's managing moving from one view to another. The Navigation Controller within its boundaries, within its container, has a view. And maybe that view has a Navigation bar at the top and a slider in the middle. So, we can think about it abstractly in terms of a tree structure like this. And what we'll see often when we work in Xcode is that this abstract hierarchy which I've displayed here as boxes and arrows gets represented in something that looks like a file chooser, or a file picker. Something that you can navigate through with accordion views that you can open and close. We'll see that when we start to implement some of these things in Xcode. Although we represent these as box and arrows here on the left, when you actually lay it out, it gets laid out according to the properties of the element itself. So, we might see that this structure on the left gets drawn something more like the structure on the right. Now, on the right one what I done is I've separated out the layers that get drawn, that would eventually get sort of all smooshed together according to the properties of each of the layers. Now, this layering, if you'll recall back, speaks to the high level design concept of layering that the human interface guidelines, the Apple human interface Interface guidelines, referred to. And it was through this layering that they suggested it was possible to do some interesting and exciting kind of animations that could delight the user. So, in this case we see that the window forms the background. It is the parent, and all the other elements are drawn within the boundaries of the window. The navigation controller also draws over the entire contents of the window. The view is gonna draw over the entire contents of the navigation controller in this abstract example. Then, the navigation bar might be drawn at the top of the view and the slider at the bottom of the view. When this is fully rendered, all those will be layered on top of each other like you might see if you've used Photoshop layers or you've used maybe layers in an HTML layout. Same sort of effect here. A tree structure rendered as layers that get flattened together. Now, when it gets rendered they all get put together in a screen. So, all of that whole tree on the left is gonna be composed into one screen interface. And the less abstract version on the right will be rendered into the same screen. So, in summary, iOS User Interfaces are composed of UI elements. Four of the categories are bars, content views, controls and temporary views. Each of those elements that descends from the UI view class can draw itself, and each of them can handle their own events. They're almost always composed in hierarchies. And that hierarchy becomes a way that we can manage the layout, the input and output. And we'll see that reflected in the Xcode tools that we'll use to build them. Thank you very much. [MUSIC]
