When do you not need to declare an object?

Discussion in 'iOS Programming' started by thedon1, Jun 30, 2013.

  1. thedon1 macrumors 6502

    Jun 26, 2010
    This is probably a really newb question but the book i'm using (Learning iOS programming) doesn't really explain it well so i'm asking here.

    When i drag a UITextFieldn onto my view, I know I can ctrl click from it into my header file so that instance of a textfield (textField1 for example) has been declared and then later synthesised (.m file).

    This makes sense since I want to programmatically change the text, font etc so there needs to be a connection.

    Is this the only reason we declare an object in the header file?

    I ask because i've been watching videos on how to use Gesture Recognizers and nobody seems to declare those in the .h. Is it because they're minipulating those solely through the interface builder?

    I guess my question isn't if I have to decalre it in the .h file (as opposed the the .m) but why do I have to declare a gesture recognizer at all if i'll never use it outside the interface builder?

    Anything to add a bit of clarity would be great. Thanks
  2. ArtOfWarfare macrumors G3


    Nov 26, 2007
    I don't think I've ever read or heard this anywhere, but my understanding is that header files are for declaring things that you'd like to be visible outside of the corresponding .m file. Having learned Obj-C, and then C++ and Java, and then returned to Obj-C, I decided your .h file is basically full of everything that you would declare public in one of those other languages.
  3. subsonix macrumors 68040

    Feb 2, 2008
    It's the same in C++, as you mentioned, the header declares public interfaces, types and identifiers you want to use in more than one place.
  4. Sykte macrumors regular

    Aug 26, 2010
    No, Lets say you have a child object and of course the child object has a name property. You would want to declare the name property in your header file to make it public so a father or mother object can change set the child's name property.

    By declaring things in the header you are essentially declaring them as public. You can also declare things as private in your .m.

    Not always. The only time you should declare something in the header file is when you need access to it outside of the current object. Otherwise it should be declared as private.

    Gesture Recognizer is an object, it needs to be instantiated somewhere. Sadly, Interface Build obscures this.
  5. Duncan C macrumors 6502a

    Duncan C

    Jan 21, 2008
    Northern Virginia

    Some background.

    An object is a block of memory that stores instance variables, and a bunch of code (methods).

    The block of memory is allocated on the heap, when you create an object. The block of memory contains instance variables for the object.

    When you add a variable to the .h file for your project, you create an instance variable. You might add a variable as a property, and in that case newer versions of the compiler create an instance variable for you. (A property declaration also causes the compiler to generate getter and setter methods, but let's not worry about that right now.)

    It's also possible to add a new @interface statement inside your .m file that declares more instance variables and/or properties. That does exactly the same thing, except those properties/instance variables are only visible inside the .m file. That tells other code "Keep out, this is my private data." Other than that, instance variables declared inside a second @interface statement inside the .m file are identical to those declared inside the .h file.

    Instance variables are storage for state information for an object. You might have a car class, and subclasses for compact cars, sports cars, etc. You then create instances of cars. Each car object has instance variables for things like radio station setting, amount of gas in the tank, odometer reading, etc. Each instance of a car needs to save that information about itself.

    A subclass of an object has all the instance variables of it's parent class, and can also declare its own instance variables. It's block of memory becomes the combination of all the instance variables in it's ancestor classes, and its own instance variables.

    Methods and functions also have local variables. These are variables that don't exist until the method is called, and then disappear when the method returns. You can create objects and save them in local variables, and then under ARC, those objects get released when the method returns.

    Objects like view controllers have a long ancestry, with lots of parent, grandparent, and great-grandparent classes. Each of those ancestor classes has instance variables that it declares.

    In the case of a view controller, it has a view property that points to the content view that the view controller manages. If you create a subclass of UIViewController, it inherits that view property from the parent class.

    When you create view objects in interface builder and add them to your view controller, they are added as subviews of that main content view. (Under the covers, a view object has an array object called suviews that keeps track of, and owns, the objects that are inside a view.)

    The same goes for views that you create in code and add as subviews. They become the property of the content view.

    If you want to be able to get to those objects later, you might want to add an instance variable to your view controller and save a pointer to the view object there. That's what you do when you add an IBOutlet. It's an instance variable that points to one of your views, and the IBOutlet tag tells Interface Builder that that is a link it should know about.

Share This Page