Expect everything to change...

Intro

In addition to being responsible for drawing and handling user events, a view instance can act as a container, enclosing other view instances. Those views are linked together creating a view hierarchy. Unlike a class hierarchy, which defines the lineage of a class, the view hierarchy defines the layout of views relative to other views.

The window instance maintains a reference to a single top-level view instance, call the content view. The content view acts as the root of the visible view hierarchy in a window. The view instances enclosed within a view are called subviews. The parent view that encloses a view is referred to as its superview. While a view instance can have multiple subviews, it can have only one superview. In order for a view and its subviews to be visible to the user, the view must be inserted into a window's view hierarchy.

This window's view hierarchy has these parts.

• The window is represented by an NSWindow(aWindow) instance.
• The content view serves as the root of the window's view hierarchy.
• The content View contains a single subview, an instance of a custom class.
• The custom view instance that, in turn has two subviews, an NSButton(viewB) instance, and an NSTextField(viewC) instance.
• The superview for both the button and text field is the NSBox(viewA) object. The custom view container actually encloses the button and text field views.

Relationships among objects in a hierarchy

my thanks to:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/WorkingWithAViewHierarchy.html

Preamble
1) This tutorial assumes you have some basic C knowledge, including C data types, what a function is, what a return value is, knowledge of pointers and basic memory management in C. If you haven't gotten this far, I highly suggest you pick up K and R's book, The C Programming Language. This is the book on C written by the writers of C.
2) Objective-C, being a C derivative, inherits all of C's features. There are a few exceptions but they don't really deviate from what C offers as a language.
3) nil: In C/C++ you're probably used to NULL. In Objective-C it is nil. The difference is you can pass messages to nil (such as [nil message];) and this is perfectly legal. You cannot however do this with NULL.
4) BOOL: C doesn't have an official boolean type, and in reality neither does Objective-C. It's however built into the Foundation classes (Namely from importing NSObject.h). nil is also included in this header file. BOOL in Objective-C has two modes, YES and NO rather than TRUE and FALSE.
5) #import vs #include: As you will notice in the hello world example, #import was used. #import is supported by the gcc compiler, however it is deprecated in favor of #include. #import is basically the same thing as #ifndef #define #endif at the top and bottom of every .h file you make. I find this to be retarded, as many other programmers will most likely agree. For all purposes, just use #import. It's less hassle, and if gcc ever does remove it chances are enough Objective-C developers exist to either keep it from getting removed or getting added back in. As an aside, Apple officially uses #import in all their code so if this ever did happen, you can be certain that Apple would conviently ship a forked version of gcc to add this back in.
6) The word method and message are used interchangably in Objective-C, although messages have special properties. A message can be dynamically forwarded to another object. Calling a message on an object in Objective-C doesn't mean that the object implements that message, just that it knows how to respond to it somehow via directly implementing it or forwarding the message to an object that does know how to.

Creating classes
Fraction.h
1) Instance variables go between @interface Class: Parent { .... }
2) No access is set (protected, public, private). Default is protected. Setting the access will be shown later
3) Instance methods follow after the member variables. The format is: scope (returnType) methodName: (parameter1Type) parameter1Name; ie. -(IBAction) _uiLoginBtnTouch: (id)sender
4) scope refers to class or instance. instance methods begin with - class level methods begin with +


Instance variables go between @interface Class: Parent { .... }
No access is set (protected, public, private). Default is protected. Setting the access will be shown later

Piecing it together
main.m
1) Fraction *frac = [[Fraction alloc] init];
There are several important things in this one line.
The way methods in Objective-C are called is [object method], which is similar to object->method() in C++
Objective-C doesn't have value types, so there is nothing similar to C++'s: Fraction frac; frac.print();. You always deal with objects as pointers in Objective-C.
What this line is really doing is two things: [Fraction alloc] is calling the alloc method on the Fraction class. This is similar to mallocing memory, because that is all that is done in this operation.
[object init] is the constructor call, which initializes any variables in the object. This method is called on the instance returned from [Fraction alloc]. This operation is so common it's usually just done in one line as Object *var = [[Object alloc] init];

2) [frac setNumerator: 1] is quite simple. It's calling the setNumerator method on frac, and passing it the parameter 1.
3) Like every c variant, there's a construct for freeing memory. This is done via release, which is inherited from NSObject. This method will be explainted in greater detail later.


Interface Builder
Actions: things user do/events like push a button
Outlets: things program gonna do like display text

-- Memory Leaks
-----------------------
Try Apple's Instruments utility, found in /Developer/Applications/.
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html















my thanks to:
http://www.otierney.net/objective-c.html#creatingclasses