How are you feeling so far on this material? We haven't really gone over very much by way of mind bending material, but it can be a lot to take in at first. I'd like to move on now and talk about the .xib files you can see on the left side in Xcode. You have probably noticed that the names of any .xib files you see also correspond with the names of existing .h and .m files. If you can recall, I mentioned that the .h, and the .m files together make up a class. This might be a little confusing, but some classes are designed to be viewed on your screen, or in other words they have a visual component to them, and then some do not. The .xib file is the designated place for setting up the visual objects for the view of a particular class.
The concept behind using .xib files to handle the visual objects of your view is that it is easier to lay things out graphically then it is to do it in code. I completely agree with this. There are those that don't prefer the graphical method, but I am definitely one that is ready and willing to take advantage of all of the tools at my disposal. Interface Builder (the built-in program that allows you to do all the cool graphical editing stuff we're going to dive into) is a very powerful tool that we are going to take advantage of. It is very important to understand that Interface Builder is a tool that let's you connect graphical objects that you can easily interact with, to your code. That's the whole point. Setting up things graphically, and then linking them into the code so that they actually do things. This will make more sense as we go along.
If you have been following along with my previous posts, we have been playing around with a simple view-based application with a single blank view controller as the main view. If you go ahead and click on the only .xib file that there is on the left (in my case it's called ExampleViewController.xib), Xcode will load the file in Interface Builder. In previous versions of Xcode, Interface Builder, or IB as I will refer to it, was a separate program that ran along side Xcode. Ever since Xcode version 4.0+, IB has been integrated into Xcode, which is great.
You'll notice that a number of different things have just popped up. You are probably thinking, "I can't handle any more stuff!". Don't worry, you can. The image below will help make sense of all of the tools that IB provides:
Similar to how we've been doing, I'm just going to go through and talk about the points I have labeled:
A - Files owner is one of the more confusing components of IB, but it doesn't need to be. I mentioned earlier that the purpose of IB is to connect graphical objects to code so that they do things. A button doesn't do anybody any good unless it is hooked up to some code that does something, right? Files owner (right clicking on file'w owner more specifically) allows you to see in IB all of the objects from the .h file that are available to you in that particular class. This will all make sense as we go along, but make sure you understand that File's owner is basically a graphical representation of the .h file (which is where you declare all of your class variables! Right?).
B - This pane is a simple graphical representation of your view's hierarchy. This can be quite a useful tool, especially when you are nesting different view's inside of each other. Based on what you see going on in the middle of the screen, with all the buttons and stuff, what can you deduce from this pane? The container view is called View, and then (because of the fact that it is indented) we know that the Button, Label, etc, are objects that are nested in that View. We put those things in the view, and this pane represents that very well.
C - As mentioned before, this list of items are the things that are actually on the container view. So you might say this is a list of subviews.
D - The graphical representation of the view itself. IB does a great job of laying out a nice canvas to begin adding all the objects you need for your view. Just so you aren't confused, I went ahead and added a number of UI objects to illustrate how easy it is to set things up in the .xib file.
E - This row of icons is actually quite important when it comes to changing the attributes of different objects in IB. For our basic purposes, we won't need to change to a lot of them, but as we go along, know that that row is the Batman utility belt of IB.
F - In this sub-toolbar, it is important to remember that you are selecting that cube that is third from the left. This gives you access to the UI element library that you can pull things from.
G - To a large extent, this is where all the magic comes from. If you scroll through this pane, you'll see a large number of things that you can add to the view that we are building. Some of these you have seen in your use with an iOS device, others you haven't. Apple has done a great job of making it very easy to add and implement all of these tools. As we move along, you will become more familiar with this area.
Before we wrap up our little intro of IB and.xib files, let's get ready to so some nifty stuff with IB. Your view should be blank still (unlike mine), and so now I want you to add two things to your view. Where do you get items to add to the view? If you look up at the image, the item library is identified in F & G. Let's go ahead and grab a Label and drag it onto your view. You will notice that if you want to center it, IB will tell you where you need to line it up. Change the text of the Label by double-clicking on it, and change it to whatever you like.
Now go ahead and grab a Button fro the library and drag it beneath your Label. You can add some text to your button in the same way you did the Label. After you save the file, run your project and see what you've done!
Okay so adding a button to the screen that doesn't do anything isn't exactly a monumental achievement, but we are making progress! In our next post we are going to go over how to hook up the graphical side of things (in the .xib file) to the code side of things (in the .h/.m files).
No comments:
Post a Comment