iOS Development

Course No. 10-152-139

Chapter 21 — Object Instance Variables and Properties

Object Variable Types

  1. Object-type attributes
    • A pointer to a simple object like an NSString for first name.
  2. To-one relationships
    • A pointer to a single complex object like an Employee object.
  3. To-many relationships
    • A pointer to a collection like an NSArray or NSMutableArray of Employee objects.

Many Pointers

  • One really crucial concept in Object-Orientation and Objective-C is that it’s common for an object to have more than one pointer variable pointing to it.
  • Let’s look at this with primitive C types first.
  • In this example both pointer1 and pointer2 have the same address and are pointing to the same variable. As we can see in the output, dereferencing the pointers gives us the same value.

  • If we use one of the pointers and change the value it points to the other pointer will see the new value.
  • Now let’s switch to Classes and objects.

The Parent and Child Classes

  • Here’s a simple example using Parent and Child classes.
    • Parent class Parent.h file.
    • Parent class Parent.m file
    • Child class Child.h file.
    • Child class Child.m class

Class Details

  • The Parent class is very simple and there’s nothing new there.
  • The Child class has some new stuff we’re going to look at in more detail. Let’s start with the Child.m file.
  • This line imports the Parent.h file so we can use it in the Child class.
  • Let’s look at the Child.h file now.
  • This line is the new piece of Objective-C syntax. The @class directive is like a light version of #import. It tells the compiler that there is a class named Parent and to compile this file as if it already knew all about it. The compiler is easily fooled!
  • Next, we have a simple object variable that’s a pointer to an NSString.
  • Finally we have a pointer to our Parent.

Using Parent and Child

  • Here’s the main function when we use the new classes.
  • Here are the details.
    • We have to import the classes so we can use them.
    • Create our Parents and Child objects and set their properties.
    • Finally, we assign the one Parent object as the parent of both of the child objects.
    • Each of the Child objects has a pointer to the same Parent. Two pointers, one Parent.

Object ownership and ARC

  • Here’s the setup. For probably a long time, iOS devices will have substantially less RAM than our desktop or laptop computers. We need to manage our app’s use of RAM to be as efficient as possible. If you use too much RAM iOS will just shut your app off. Boom! It’s gone.
  • If you have a pointer, you own it!

  • Remember malloc and free? We used to have to do all of our own memory management.
  • It’s a lot simpler now.

If no one owns an object it will be destroyed.

  • And

If an object is owned by another then it won’t be destroyed.

The description method

  • The description method is inherited from the NSObject class. We should override it almost always.
  • This method will be called automatically when we want to display a string that describes an object. It is like the toString() method in Java and the ToString method in VB and C#.
  • Here’s an example from our Parent class.
  • Here’s the Child class.
  • We can create any string we want and return it to the calling method.

The dealloc method

  • When an object is destroyed by Objective-C, its dealloc method will be called. We don’t normally implement this method in Modern Objective-C. We will in this example to see when our objects get destroyed.
  • Here’s the one for the Parent class.
    • When self is used like this it calls the description method.
  • Here’s the method for the Child class.
    • It’s just the same as in Parent!

Watching objects come and go

  • Here’s a full example from the main function.
  • Here’s the output from the code without the NSLog timestamp.
  • We looked at the first half previously so we’ll start with the nils.
  • We can nil out the parent pointer because our Child objects have pointers. The Parent isn’t going anywhere with the kids pointing to it.
  • Now we display the kids. The description method for the Child class also shows the Parent.
  • Next, we nil out the pointer to the first kid. This removes that address from the pointer and Objective-C knows that nothing is pointing to that Child object now. Since nothing is pointing to it the object is destroyed.
    • And that’s all the output we get. That object’s dealloc method was called and it gave us that output. The other kid object still has a pointer to the Parent so it still exists.
  • Now we nil out the second kid. This time we get more results!
    • Notice that the highlighted lines occur together. This happens even though the NSLog statement about “all kids gone” is right after the secondKid is set to nil.
  • When the secondKid is set to nil the Parent is immediately destroyed because there were no more pointers to it.
  • This is how Objective-C works to reduce memory use. We just have to make sure we are not owning any objects and they get removed from RAM. No problems right?
  • Anyone see any issues with this? I knew it was too easy.