iPhone Multiview Application Part III

This part of tutorial will be primarily focused of some theoretical concepts of Objective C programming and Object Oriented Programming. We will also modify code from previous part at the end of tutorial, so keep on.

Ola everybody,

let`s continue where we have stopped last time. I would like to point some basic concepts of Object-C programming, so if some of you guys already know this topic, skip this, and move straight to the end of this part, there will be some coding. Rest of you, let`s dive. Objective C is object orientated language we use for iPhone programming. Let`s define several concepts here, which will be (and were) used frequently:

class – defines grouping of data and code, represents the blueprint for instance

instance – one piece of the class

instance variable – piece of data belonging to an object

method – function that an object knows how to perform

Regarding Object C, everything begins with NSObject. This is the superclass which every other object inherits.  UIControl inherits NSObject, and UIButton inherits UIControl.  So, we said that UIButton is subclass (Inheritance).

Class defines state (instance variables) and behavior (methods). Instance variables are usually hidden, so we have to define getters and setters in order to access their values or set their values (encapsulation).

We can manually write our getters and setters but, since Objective C 2.0, this process can be automated by defining properties. Every class in Objective C consist of .h and .m files. .h file is header file, interface, where we define our properties and methods. On the other side, .m file represents the implementation of interface, so this is the place we implement getters and setters and all methods we have defined in header file. So when we write:

NSString *message; – we have defined instance variable (.h file)

@property (nonatomic, retain) NSString  *message;  -this line of code tells compiler that we are going to have getters and setters for message variable. In the .m file, all we have to do is to synthesize this property:

@synthesize message; – and this tells compiler to generate getters and setters for this property. Simple as that. Also, we can define just getter or just setter:

@property (readonly) BOOL someBoolValue; this way we define property which have just getter.

Accessing properties:

int number = [Person age]; is the same as: int number = person.age;

If we have class named Person with age property, we can access this property calling the property getter. You can use one or another syntax, whatever you like.

Creating object in Object-C is two step process, first we allocate memory to store an object and then we initialize it`s state.

Memory management is very important when we talking about iPhone programming since there is no garbage collector here (it exists if we programming for iMac). So it is essential to handle the memory properly. And there is only one rule here, if we create object, we are responsible to release memory it takes when we don`t need it any more. Every time we allocate an object it retain count will increase by 1. Every time we release it, it retain count will decrease by 1. As long as retain count is larger then zero, object remains, if retain count become zero memory will be deallocated. So:

alloc and copy will create object with retain count to 1

retain will increment retain count by 1

release will decrement retain count by 1

When retain count becomes 0, dealloc will be called automatically (we never call dealloc directly, instead, we release the object thus telling that it won`t be used any more, so memory it takes can be released).

If object is not explicitly allocated (ex. NSString *tmp = @”someText”;), it will be autoreleased, so don`t have to take care of it.

We also mentioned IBOutlet in previous part. Every time we drop some component in Interface Builder View, we have to define IBOutlet (of course if we want to do anything with it) on program side, and connect it to that component. iPhone uses MVC (Model View Controller), meaning that we have on one side our code (Model), on the other side visual part (View) and we have mediator in between. Model and View will never talk to each other directly, but instead, they will always use Controller. So IBOutlet will enable Model to talk to View, and   IBAction on the other side will pass messages from View to Model. We have already seen IBOutlet in action. In next part, we will define one IBAction too.

One more thing. When we have created SecondViewController (better say, when we instantiate it) in RootViewController method didSelectRowAtIndexPath, we have used pushViewController method. What does this means? Well, stack is program LIFO data structure. LIFO stands for Last In First Out. Best analogy I know is automatic rifle magazine. When we put the bullet (dummy) into the magazine (push) it will be at the top. So if we fire it (pop), it will goes out. Now, if we put one bullet (push), then another (push), second will move first beneath it and will place itself as first. Now, when we start firing, second pushed will pop out first. I hope you get the idea:

Same thing happens with view controllers.  When application is started, Root view controller is loaded (pushed at the top of the stack). When we create second view controller, and push it on the stack, it will move Root View Controller to second place, and place itself as first. Since we always see what is at the top of the stack, our second View Controller will become visible. When we pop it from the stack, our root View Controller will be moved to the top, thus becoming visible to the user.

Ok, enough talking, let`s do one little change to our code before ending this part. Last time, we put label to the Second View Controller, but every time we pick row it loads it, but label text is already set. Let`s try to set it programmatically. Fire up xCode, and double click at SecondViewController.xib to open Interface Builder. Expand the label (make it bigger) and delete text inside it (double click on label and hit DELETE  to remove text). Open Inspector (CTRL+CMD+I) and select tab Label Connections, Delete Connection between the secondScreenLabel and File`s Owner (Click on x):

Save changes and swap to xCode. Open SecondViewController.h file and add new NSString object, and create property for it:

Open SecondViewController.m file and synthesize label text (create getter and setter for it):

Save file and switch to RootViewController.m and it`s method didSelectRowAtIndexPath. Before we push second view on the stack, we will set label value:

See how we access the property labelText? Using dot notation,  after instance name, we simply called it`s property (setter method called) and pass some text. Now, we need to tell the label that this text will be showed. Switch now to the SecondViewController.m file, uncomment viewDidLoad method and put the following:

One more thing to do before test this.  Double click to SecondViewController.xib to open Interface builder. remember that we have broken connection between our IBOutlet and Label. Select File`s Owner, and then select Connections TAB on Inspector. Click and drag from circle right to SecondScreenLabel to the label. When you`re over label, move the finger from left mouse button. Connection is created:

Save everything and build and run. If you click on the some row, our app will slide to Second View Controller setting label text, just as we want:

That`s all for this part. I hope I didn`t bother you with theory, however, I only touch tip of the iceberg . I strongly encourage you to continue reading Objective-C and OOP theory, because you`ll need all of this in order to learn to programming. Until next time, all the best.    

return to part II: http://computersight.com/programming/iphone-multiview-application-part-ii/

proceed to part IV: http://computersight.com/software/iphone-multiview-application-part-iv/

comments powered by Disqus
Loading