I am developing a special type of view controller for an iPhone component library.
I have got the who view controller working well, but I need to change it so that it works in one of two ways:
Either it is an abstract class which you must subclass and provider the implementation for a specific method which the controller will call whenever it needs its data.
Or it needs to be a useable class which has a property which is a selector... when you set the selector it specifies the method which should be called to collect the data.
I would like to know how I can implement either of these and which you would recommend
The standard way of doing this in Objective-C and the iPhone is through delegation.
Normally you provide a property in your view controller called delegate that is typed for a particular protocol you create. Then who ever is using your view controller will set the delegate property with their delegate for your view controller. You can then call the methods in your protocol on their delegate.
See the answer at this SO question for a full example.
Also read the Cocoa Fundamentals Guide for information on what delegates are and why they are used in Cocoa. There is also an example there of how to create delegates for your own custom classes.
Related
we wanted to present a custom SFSafariViewController to present the reCAPTCHA, it was given in the firebase docs to create a custom class that conforms to the FIRAuthUIDelegate protocol, and pass it to verifyPhoneNumber:UIDelegate:completion:.
I created a custom class that conforms to the protocol but the protocol needs us to pass a viewcontroller to it, but none of the details required to create that viewcontroller or any details or example as to how to use a custom viewcontroller is not given anywhere.
It's been a while since this was asked but I had to attempt to do this over the last few days and couldn't find the answer in the documentation either.
The view controller passed to the protocol functions is not one that you can create yourself as it's provided by the Firebase SDK and it's some implementation of SFSafariViewController.
As long as you have set the delegate object on the call itself than the SDK will trigger the delegate object methods directly providing the View Controller.
The delegate is expected to be able to manage the layout of the controller and its own views so it will need some reference to a parent UIViewController.
You are limited to the customisation available for this class and its own views. I assume you could start manipulating the view hierarchy in the controller itself but as this was provided to me by Firebase I settled for just adding this on a view container in the parent.
You can add and remove the controller and view as a child controller as normal.
I have a general working knowledge of object-oriented programming and I'm currently trying to create an interactive novel program in Objective C using Xcode 4.2 with storyboarding.
I have a storyController class that instantiates the page objects and a viewController class that needs to display the pages. My fundamental question is the best approach for my storyController to tell the viewController to update it's text to display that of the new page object. My instinct tells me that my storyController needs to call a method on the viewController and pass it a page object. However, I'm not sure how to reference the view controller since it seems to be automatically created and linked by the storyboard (I don't see the viewController instantiated in the appDelegate).
I've read this post: http://www.iphonedevsdk.com/forum/iphone-sdk-development/54859-sharing-data-between-view-controllers-other-objects.html and it seems to address the issue. I could make a shared object on my appDelegate and use KVN or NSNotification to tell the view controller to check it.
I've also been reading about delegates and protocols as possible solutions.
So considering these potentially different approaches, which would be best to tell my viewController to update itself and pass it an object that contains the updates?
I would suggest looking at the UIPageViewController class, which probably will do a lot of the heavy lifting work for you, depending on the specifics of your app. This class is essentially a controller class that contains multiple viewControllers. Each managed viewController becomes essentially a "page" in your book.
Here is a tutorial using UIPageViewController.
If this approach won't work for your app, I'd still suggest using a separate viewController instance for each "page" of your book and handle the transition between the pages with segues.
In my iPhone app, I have a custom UIViewController class setup which adds some UIImageViews and things.
How can I access this class via my main UIViewController and, for example, call a method from that outside class and have it add those UIImageViews to the view?
Make property and public methods, after that you can call them in target viewcontroller.
p.s. But I never used this approach because it breaks controller's logic. Instead of I usually use some managers which has all required methods. (DBManager, NetworkManager, etc)
In cocoa-touch development...
Use AppDelegate for delegate classes
Create separate delegate class and locate in new .h/.m for each class need to use delegate
Use view controller classes(whenever such exist) to do that job for all
classes managed by this controller
What would you recommend?
Well it depends. The entire concept for delegate protocols exist so that you can have a lot of flexibility. Sometimes you take the simply default route but sometimes you need to be able to have a lot of different delegate classes.
(1) App delegate -- the app delegate should only be used for UIApplicationDelegateProtocol methods or delegates for actual properties of the delegate instance itself. In other words, if the app delegate doesn't directly deal with an instance e.g. the application object, then the app delegate should serve as the instance's delegate. Piling up extranous methods in the app delegate will muddle the app and make it snarlingly interconnected and difficult to debug and maintain.
(2) Wholly separate delegate classes are usually used when you have (A) a large number of delegate protocols to implement or (B) you have the same protocol to implement for multiple instances but require a different behavior for each object's delegate. E.g. you have several UITextFields each of which behave differently. You create as separate delegate class for each so that each text field has it's own custom implementation of the delegate protocol's methods.
(3) Using the controller for delegates is the easiest, most logical and most modular way to go in the majority of cases. In many cases such as UI elements the delegate methods need an awareness of other UI elements which the controller can provide.
In sum, never do (1) as a general parking place for any random delegate methods and default to (3) in the majority of cases.
I have a view controller which gets an NSObject conforming to a protocol and then displays a view with the object's properties.
The question : How can my controller know that a property of this object has been modified and then refresh the view ?
Thanks a lot
Thierry
There are three ways of doing this:
Have the object call a method in the controller in response to an event e.g. a user clicking the button. This is usually done using an IBAction.
Set the controller to be the delegate of object e.g. a UIWebView sends a message to its delegate when it finishes loading a page.
Use a notification. The object generates the notification and then one or more objects (including the controller) registers to listen for the notification. This is usually not used with interface elements although it can be.
I can't tell you more without more detail about the specifics of your project.
Your viewcontroller should conform to your .
In your model, all your set methods should trigger appropriate functions you define in your modelchangedprotocol.
This OO design pattern is also known as "Observer" design pattern.