Re: new to Cocoa/Objective-c: many points of confusion
Re: new to Cocoa/Objective-c: many points of confusion
- Subject: Re: new to Cocoa/Objective-c: many points of confusion
- From: Dave Keck <email@hidden>
- Date: Sun, 03 Feb 2013 04:34:58 -1000
> *delegates: my understanding is that these take the place of subclasses (though why this is useful is beyond me), overriding methods they are designed to handle rather than letting the base class take those methods. However, I not only don't see why this is so great, but I don't understand the syntax used to declare them or attach them to other classes so the delegates' methods get called when any of those methods are called on the object to which the delegate is attached. Every example I have found seems to indicate they are used only for GUIs, but Apples docs say that they are a much more general-purpose system?
> *Speaking of delegates, I don't follow the syntax used to set them up. Every example seems to love to use views or other UI examples, which would be fine if I could follow that, but I'm not that advanced yet. A more basic, even if not-so-useful-in-reality, example would be very much appreciated.
Delegates are indeed a general-purpose pattern -- there are many
instances of non-GUI classes that use the delegate pattern in the
Foundation framework (note that the Foundation framework doesn't
include any GUI functionality, that's all in the AppKit and UIKit
frameworks.) For example, NSFileManager, NSCache, NSPort, and
NSURLConnection all expose delegate interfaces.
The delegate pattern is simply a callout mechanism, allowing one class
to notify another class of some event. The delegate pattern is
inherently limited in that only one delegate can typically be assigned
to a class, but often that limitation isn't an issue. In contrast to
this limitation, notifications (via NSNotificationCenter) are an
alternative callout mechanism that are useful in cases where a class
might expect more than one client to be interested in an event.
A delegate is always an object, and with modern Objective-C, classes
typically declare a delegate protocol with required and optional
methods for the delegate object to implement. For example,
NSFileManager declares the NSFileManagerDelegate protocol. Now say I
have a class called MyFileDelegate; in the interface for
MyFileDelegate, I declare that it conforms to the
NSFileManagerDelegate protocol:
@interface MyFileDelegate <NSFileManagerDelegate>
@end
Now say I assign an instance of MyFileDelegate to be the delegate of
an instance of NSFileManager, via NSFileManager's -setDelegate:
method. Once that's set up, any time I, for example, move a filesystem
object using that NSFileManager instance, that same MyFileDelegate
instance is notified via the -fileManager:shouldMoveItemAtPath:toPath:
method, which MyFileDelegate implements.
> *Outlets: I have a basic idea that these are a way of sending messages from object to object, a bit like listeners. However, I don't really understand the syntax used to make them. Moreover, I always see them used in GUIs, but Xcode's Interface Builder won't let Voiceover users make connections, so I can't proceed with Apple's tutorials on this topic. Somehow, these connections are outlets, or are related to outlets, or some connections are outlets, or something... Anyway, as I can't make the connections to get an idea of how they work, I'm trying to follow others' examples which I don't get as they use code I didn't write and that makes no sense to my newbie brain. So, what exactly is an outlet and how and why would I set one up? Again, a very basic code example would really help here.
I think you've somewhat misunderstood outlets: outlets are references
to objects created in IB. (These objects are typically UI-related,
such as views and buttons.) Outlets can be either an instance variable
or a property.
Now let's say we have a view controller with an outlet (in the form of
an instance variable) to a button that exists inside the view. The
view controller's interface might look like:
@interface MyViewController : UIViewController
{
IBOutlet UIButton *myButton;
}
@end
If I hook up the outlet correctly in IB, every time I instantiate
MyViewController, its 'myButton' instance variable references the
button that exists in its view.
> *Every so often I'll see a class between less- and greater-than signs when an example talks about a delegate, but I don't know what this is for. What does it mean to put these symbols around a class (or maybe they are around an object?)?
There are two different scenarios in which you'll encounter these
less-than/greater-than signs in Objective-C, and both concern the
protocols feature of Objective-C. The first situation is in class
interfaces, where they're used to declare that whatever class you're
creating conforms to the protocol between the less-than/greater-than
signs. Let's continue with NSFileManager to illustrate: NSFileManager
declares the NSFileManagerDelegate protocol. So let's declare a class
called AppController that conforms to NSFileManagerDelegate; the
syntax looks like:
@interface AppController <NSFileManagerDelegate>
@end
The second situation that you'll encounter less-than/greater-than
signs is when used in the types of variables. To illustrate, let's say
we're implementing NSFileManager and so we need a method to set its
delegate. This method would look like:
- (void)setDelegate: (id <NSFileManagerDelegate>)newDelegate;
In this case, the "NSFileManagerDelegate" between the
less-than/greater-than signs acts as a type modifier -- it specifies
that the argument to -setDelegate: must conform to the
NSFileManagerDelegate protocol.
>
> *I've seen sample code that seems to go against everything I know about method calls:
> -(IBAction) someObject:(id)inSender;
> Huh? Is the (IBAction) casting, or a method call, or what (I understand what IBAction is, but not why it is where it is and in parentheses)? I know why the "id" is there, so this action will work with any UI element, but why the colon? What is inSender doing there, hanging out at the end of the line? How does the method (in the m file) have any idea what inSender is as it appears to not be an argument? Why does it need inSender if it already has the id argument?
The IBAction bit is just some preprocessor voodoo that allows IB to
parse the file. (It's also nice for code-readability, so that you know
that the method is invoked from the UI.) From the compiler standpoint
though, IBAction is equivalent to "void", so let's just assume the
method in question reads like the following, and we'll break it down:
-(void)someMethod: (id)inSender;
1. The beginning hyphen indicates that this is an instance method
instead of a class method. (Class methods are declared with a plus
sign.)
2. "void": this is the return type of the method. As in plain C,
"void" means there's no return value.
3. someMethod: this is the name of the method
4. Colon: a colon indicates that an argument follows. In the above
case, "inSender" is the only argument. If a method took two arguments,
it might look like:
-(void)someMethodArgOne: (id)argOne andArgTwo: (id)argTwo;
> *What is a property? I see these used a lot, but I'm not clear on what they are compared to, say, class-level variables or methods. The statement I'm talking about is the "@property" statement.
Here's Apple's page on declared properties that explains them better
than I could:
http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/DeclaredProperty.html
> *I know that using the @synthesize statement auto-generates getters and setters, but no one ever talks about how to use them once they are set up. That is, what is the syntax for these generated methods? I assume it is "get" and "set", cammel-cased with the variable being synthesized (and with a single parameter matching the variable type in the case of the setter) but I want to be sure.
See page given above; if you declare a property like this:
@property(copy) NSString *title;
Then its getter is simply -title and its setter is -setTitle:.
Hope that helps Alex!
David
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden