This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Implementing a method taking a block to use as callback
I couldn't find any clear explanation about how to implement a method that executes a completion block.
I know that NSOperation can be subclasses and used with calling setCompletionBlock: . Anyone knows if this is possible just by implementing in the m. file?
You may not believe it, but there is a Code Samurai Article which covers the exact ground of your question! About a third of the way down, they subclass NSOperation with an example completion block.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Do code blocks completely replace delegates?
I just encountered the following declaration from a forum:
"Delegates is the past. Blocks are the future."
1) Are blocks the preferred way to do 'delegation' duties over delegates?
2) Is there any particular benefit of using a delegate vs a block?
I think there's a slight misunderstanding in what delegates do and what blocks do.
In Objective-C, there are three ways to handle callbacks:
Delegation -> where you make one object the delegate of another object and you have to specify which kinds of events generated by the "parent" object the delegate object will respond to.
Target-Action -> typical in UI interactions, where a UI subview (button, slider, etc) generates an event based on some user input (for example a touch/tap) that is handled by a predefined event handler (typically some Objective-C method that the developer specifies).
Notification -> where an object registers itself with an instance of NSNotificationCenter to "listen" for events of any type and responds to one or more of those events.
A block is not by itself a way to handle delegation, or any other callback.
They are self-contained pieces of code that have access to the local variables and parameters of the calling method. They can be used to define behavior in a bunch of different contexts. The main benefit of a block (as I see it) is that it can simplify code by eliminating extraneous overly-specific methods that would clutter your codebase. Blocks help to localize code to where it makes the most sense: right there within the callback mechanism.
Basically, using them enhances readability and makes code more maintainable.
Whether these benefits make blocks the 'preferred' method of handling callbacks is definitely a matter of personal opinion and experience. ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm new with Objective C and am not an uber programmer anyway but one thing I find odd is that it won't throw errors sometimes when objects are declared not initialized.
I just ran into this again - I had some setup stuff to be done in so I put it in an init function - but the class is a UIViewController that is wired up in the storyboard. So init was never called - and that's my error - (lots of NSObject derived classes in the project and I rushing and just tossed that in to test some things).
But my methods that were making calls to the instance that was supposed to have been set up in int didn't throw errors - it just that the values I was expecting were nil.
Isn't that sort of odd that that sort of stuff would fail silently?
You've got two separate issues here, both quite common for beginners.
Your init was never called because it's the wrong method entirely. It's not the designated initializer for a view controller, and in any case a view controller from a nib or storyboard gets initWithCoder:. So it's up to you to have a sense of what method will be called and when.
Messages to nil return nil with no error. This is a deeply entrenched feature of Objective-C and isn't going to change. There is often quasi-religious debate about it, and there are some clever ways around it, but that's neither here nor there really. Basically it's up to you to use lots of NSLog and lots of nil-checking (NSAssert is a great thing to use for this), especially during early stages.
Not odd at all. That's how Objective-C has always worked. Messages to nil simply do nothing.
It is strange, but that's how Obj-C was designed. Actually, from Obj-C perspective, the code did not fail (silently). Everything was correct.
In Obj-C you can alwyas send messages to ("call methods on") nil.
init is just another message ("method"), not a constructor. It's not needed to create and use an object. You can understand Obj-C only as a thin layer over C language. C language won't report if you haven't called a function on a struct, either.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
alloc, init, and new in Objective-C
There is +alloc/-init... and +new. Their role are almost same in documentation except +new is designed for instance pooling. (according to my understanding :)
However the pooling is possible with +alloc/-init. Why the separated method is required? Or is there any reason for the method?
And I couldn't find any example utilizes the method. When should I use this method? Can I get some use-case of the method +new?
In the original Objective-C implementation from Stepstone, +new was what we used to create instances. It was a holdover from Smalltalk. NeXT separated +new into +alloc/-init since most classes don't have to do anything different to allocate the memory their instances use, and it didn't make sense to duplicate that code all over the place.
This question already has answers here:
#synthesize vs #dynamic, what are the differences?
(8 answers)
Closed 8 years ago.
Objective-C has a feature called #dynamic.
Google only lists results about dynamic typing.
I rarely see this in code and I don't understand what it is used for. Can anyone explain me this? Thanks.
#dynamic means “my class will figure out how to respond to this at runtime.” Uses a runtime mechanism for an object to intercept messages it normally wouldn’t respond to. In the case where a Core Data db is used to store persistent data, NSManagedObject turns these into calls to -valueForKey: and -setValueForKey:.
Take a look at Lecture 12 (Fall 2010) of Stanford's iPhone development course.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Delegates, can't get my head around them
Hi friends,
What is mean by delegate in objective C? Why we need it? When should we use it? Is there any types in it? How to use it?
Please friends, use simple words and examples to explain. I saw so many articles, forums.. But still i can not catch the exact explanation of it..
Thank you
A delegate is a way to modify the behavior of a class without requiring the class to be subclassed. Often you don't want to dramatically change behavior, but tweak it a bit; subclassing would be overkill, so that's where delegates come in to play.
Look at it this way: a teenager represents a class, and her parent the delegate. The teenager's friend calls her to come hang out at the mall, but the teenager has to ask her parents if it's okay first. The parent -- the delegate -- can say yes or no. That's how delegates work in Cocoa.
Is there any types in it?
Delegates can generally be of any type. In 10.6, many delegates implement protocols with optional methods, so you'll see types like id <BlahClassDelegate>, but that wasn't common before 10.6.