I am looking for good example code for using delegate and events in objective c?
i am familiar with delegate and events in C#.
so if someone can help me with few lines of code it will be very helpful.
Selectors (equivalent of C# delegates)
Beware, C# has a term called "delegate" and Objective-C has a term called "delegate", but the two have hardly anything in common.
The C# "delegate" is essentially a type-safe function pointer. The equivalent of a function pointer in Objective-C is called a "selector".
To declare a parameter, member variable or local variable to be a selector, declare the type as SEL. For instance in the header file for the NSTimer class you can find this method:
- (id)initWithFireDate:(NSDate *)date
interval:(NSTimeInterval)seconds
target:(id)target
selector:(SEL)aSelector
userInfo:(id)userInfo
repeats:(BOOL)repeats;
This means you're meant to pass a selector as the fourth argument when using this method. You can call it like this:
[[NSTimer alloc] initWithFireDate: someDate
interval: someInterval
target: self
selector: #selector(myTimerCallback:)
userInfo: nil
repeats: NO];
As you can see, by writing #selector(some-name-here), I can construct a new selector (similar to how I can construct a new string by writing #"some text here"). Objective-C methods have "holes" in them where arguments are inserted, and these holes are preceded by colons. When writing a selector as above, you keep the colons but you remove all else. For instance you can write something like #selector(firstPart:secondPart:thirdPart:).
The documentation of the method that accepts a selector should usually state what sort of signature it is allowed to have. The compiler will NOT enforce this for you (this is very different from C# delegates).
Notice also that the method above asks for a "target" parameter. This is typically the object the selector will be called on. Notice that the target is the completely untyped id. The compiler does not try to enforce that the object you pass in as target actually will respond to the method indicated by the selector. If it doesn't respond, then that is a runtime error. This is part of the dynamic nature of Objective-C.
(The Objective-C "delegate" concept is really just the delegate pattern (look it up), which is very prevalent in Objective-C, often used where other langauges would use inheritance.)
Events and Actions
Regarding events, there is an NSEvent class, but I have not yet had any experience with it. It seems to be for fairly low-level handling of GUI events. The C# use for events is probably more akin to "actions" in Objective-C.
Typically, a GUI component such a button has an "action" and a "target" associated with it. You can set these either in code or in Interface Builder. The target is as explained above -- an object on which a method will be called. And the "action" is in fact just a selector.
Please read the section "The Target-Action Mechanism" of this Cocoa Fundamentals article in the Apple docs. In fact that whole page is relevant to both parts of your question, so I recommend it highly.
The above answer is certainly correct. However, if you are looking for a way to implement the publisher/subscriber pattern then you should check out the NSNotificationCenter. This post has a good example.
Related
I was reading Apple's documentation, The Objective-C Programming Language (PDF link). On pg. 18, under The Receiver’s Instance Variables, I saw this.
A method has automatic access to the receiving object’s instance
variables. You don’t need to pass them to the method as parameters.
For example, the primaryColor method illustrated above takes no
parameters, yet it can find the primary color for otherRect and return
it. Every method assumes the receiver and its instance variables,
without having to declare them as parameters.
This convention simplifies Objective-C source code. It also supports
the way object-oriented programmers think about objects and messages.
Messages are sent to receivers much as letters are delivered to your
home. Message parameters bring information from the outside to the
receiver; they don’t need to bring the receiver to itself.
I am trying to better understand what they are describing; is this like Python's self parameter, or style?
Objective-C is a strict superset of C.
So Objective-C methods are "just" function pointers, and instances are "just" C structs.
A method has two hidden parameters. The first one is self(the current instance), the second _cmd (the method's selector).
But what the documentation is describing in page 18 is the access to the class instance variables from a method.
It just says a method of a class can access the instance variables of that class.
It's pretty basic from an object-oriented perspective, but not from a C perspective.
It also say that you can't access instance variables from another class instance, unless they are public.
While I would not say that it is a "slam" against Python, it is most certainly referring to the Python style of Object Orientation (which, in honesty, is derived from the "pseudo-object orientation" available in C (whether it is truly OO or not is a debate for another forum)).
It is good to remember that Python has a very different concept of scope from the rest of the world — each method more or less exists in its own little reality. This is contrasted with more "self-aware" languages which either have a "this" variable or an implicit instance construct of some form.
I want to programmatically associate code with selectors. I am not clear on how to do that in Objective C. In Ruby, I might override method_missing. In Common Lisp, I might define a macro. In Objective C, I can get part of the way there with #dynamic properties, but I'm unclear on how to actually implement them.
Here's a concrete example: I want to use an NSMutableDictionary to persistently store parts of my object. My class has two methods that handle the basic functionality, and a bunch of dynamic properties (matching #propertys exist in #interface):
#dynamic name;
#dynamic age;
#dynamic favoriteColor;
- (id)accessor:(NSString*)name {
return [[self dict] objectForKey:name];
}
- (void)mutator:(NSString*)name value:(id)value{
[[self dict] setObject:value forKey:name];
[[self dict] writeToFile:[self filename] atomically:YES];
}
Now I am looking for a way to translate a call like
[myInstance setName:#"iter"];
into
[self mutator:#"name" value#"iter"];
I wonder if there is an idiomatic way to do that in ObjC.
This isn't really an idiomatic thing to do in Objective-C, and there's certainly nothing like a Lisp macro available. NSObject and the runtime do, however, provide three possible points for you to intercept and handle messages referring to methods that don't otherwise exist. In the order they are used by the runtime: resolveInstanceMethod:, forwardInvocation: and doesNotRespondToSelector:. The documentation for each of them explains their use and gives some examples.
The first requires you to actually write out and add a method to the class, which doesn't seem like it will achieve the dynamic state of affairs you desire. The last by default raises an exception and doesn't provide for any return value. Almost certainly, forwardInvocation is what you want to look into. It allows your object to ask another object to handle a method call, including the passed arguments; it should be possible for you to make your object handle the call itself in a way that at least gets you close to what you're going for.
Also, the "Message Forwarding" chapter of the Runtime Programming Guide gives some examples of tasks similar to your requirement.
If an object does not have the method that you have called on it you can override forwardInvocation to delegate the method call to another object.
You can use the Objective-C runtime functions along with resolveInstanceMethod:. There's a short example in the resolveInstanceMethod: docs.
What the difference between a method, a selector and a message in Objective-C?
This is a great question.
Selector - a Selector is the name of a method. You're very familiar with these selectors: alloc, init, release, dictionaryWithObjectsAndKeys:, setObject:forKey:, etc. Note that the colon is part of the selector; it's how we identify that this method requires parameters. Also (though it's extremely rare), you can have selectors like this: doFoo:::. This is a method that takes three parameters, and you'd invoke it like [someObject doFoo:arg1 :arg2 :arg3]. There's no requirement that there be letters before each part of the selector components. As I said, this is extremely rare, and you will not find it used in the Cocoa frameworks. You can work with selectors directly in Cocoa. They have the type SEL: SEL aSelector = #selector(doSomething:) or SEL aSelector = NSSelectorFromString(#"doSomething:");
Message - a message is a selector and the arguments you are sending with it. If I say [dictionary setObject:obj forKey:key], then the "message" is the selector setObject:forKey: plus the arguments obj and key. Messages can be encapsulated in an NSInvocation object for later invocation. Messages are sent to a receiver. (ie, the object that "receives" the message).
Method - a method is a combination of a selector and an implementation (and accompanying metadata). The "implementation" is the actual block of code; it's a function pointer (an IMP). An actual method can be retrieved internally using a Method struct (retrievable from the runtime).
Some other related things that you didn't ask for:
Method Signature - a method signature represents the data types returned by and accepted by a method. They can be represented at runtime via an NSMethodSignature and (in some cases) a raw char*.
Implementation - the actual executable code of a method. Its type at runtime is an IMP, and it's really just a function pointer. iOS 4.3 includes a new ability to turn a block into an IMP. This is really cool.
One of the fun things to realize is that the name of a method (the selector) is distinct from the implementation of the method (the IMP). This means that you can swap them around, if you're feeling daring. You can also add and remove methods at runtime, because all you're doing is editing an entry in a hash table: the key is the selector, and the value is the IMP of the method. This allows you to do some really crazy and trippy stuff. It's not for the faint of heart. :)
A method is the implementation which is run when an object or class is asked to perform some action. It is in the scope of its containing class and is therefore different when referenced through some other class. A selector is an identifier which represents the name of a method. It is not related to any specific class or method, and can be used to describe a method of any class, whether it is a class or instance method.
Simply, a selector is like a key in a dictionary. It can tell you what method someone is talking about, but only if you also have the dictionary itself (the class or object). The method is what you get when you ask for the value from the dictionary using the selector as a key.
This site has a good overview of all the terminology in question: http://www.otierney.net/objective-c.html
Check out the link, but I'll give a quick summary:
A method is essentially like a method of function that you are used to in your favourite programming language.
A message (from the article) "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."
Selectors can mean two things. It can refer to the name of a method, or "refers to the unique identifier that replaces the name when the source code is compiled. Compiled selectors are of type SEL." (from: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocSelectors.html)
In most languages I have dealt with, one something is called a convenience method, it means that the method does some small task that gets done very frequently, and therefore it is more convenient to use said method.
In Objective-C does this definition hold true? Or is it generally only used to describe class methods that return a prebuilt object? ex. [NSString stringWithContentsOfFile:...]
Is this just a preference thing, or are there some hard and fast definition for these terms?
Cheers,
Stefan
What you are talking about is actually more specifically a "convenience constructor" in Objective C. (Note that it's not really a constructor in the C++/Java/C# sense, it's actually an object initializer/factory method, but it seems to be the convention to call the "convenience constructors"). "Convenience constructors" in Obj C are a convention or pattern for creating a constructor/initializer/factory method for a class which takes specific parameters. This pattern also has some special conventions that you should follow (such as autoreleasing the new object within the constructor), so that your custom classes fit in well with the built-in types.
See this page (a little way down) for more info: http://macdevcenter.com/pub/a/mac/2001/07/27/cocoa.html?page=3
As for "convenience method," this specific term doesn't have any special meaning in Objective C. You can create any type of convenience method in Obj C, and there is no expectation about what it should or should not do. It's only "convenience constructor" that has a special meaning.
So far as I know, "convenience method" means basically what you defined it to mean here: a single method or function which replaces a more complicated series of invocations because of its frequency of use.
In Objective-C, the "ordinary" way to create a new instance is something along the lines of NSSomething * mySomething = [[[NSSomething alloc] initWithParam:... andParam:...] autorelease]. Many classes provide convenience constructors which simplify these three steps (in fact, in most cases, they probably literally do exactly the same thing, but wrapped behind a class method call).
While reading the documentation, I wonder if objc_msgSend() is actually the "core technology" in delivering the functionality for making Objective-C "object oriented". Maybe someone can explain in more detail which other pieces come into place to enable the object oriented paradigm of Objective-C?
Not entirely.
Objective-C is object oriented solely because it encapsulates data and functionality into a single container; a class.
That is pretty much all there is to "object oriented programming".
Now, there are many different kinds of object oriented programming and one critical aspect is whether or not a language uses dynamic or static dispatch.
In a statically dispatched language -- C++ is the best example (yes, I know it has virtual methods that give a form of dynamic dispatch) -- a method call is wired up at compile time and cannot change at runtime. That is, the implementation of the method that will be used to fulfill the method call is fixed during compilation and cannot change at runtime.
With a dynamically dispatched language like Objective-C, the implementation of the method that will be used to fulfill a method call is determined each time the method call happens. Thus, through the use of categories or the runtime's API, it is possible to change a method's implementation while an application is running (this is actually how Key Value Observation works, for example).
objc_msgSend() is the hook that does the dynamic dispatch. It takes a reference to an object or a class & a method name -- a selector or SEL, as it is called -- and looks up the implementation on the object or class that goes by that method name. Once the implementation is found, it is called.
If no implementation is found, objc_msgSend() will then take a series of steps to see if the class or instance wants to handle the unrecognized method call somehow, allowing one object to stand in for another (proxying) or similar functionality.
There is a lot more to it than that. I would suggest you read Apple's documentation for more information.
There's quite a bit more to it.