I’ll be using a datePicker several places in my app. I don’t want to “clutter” up each and every viewController with the delegation methods for the UIPickerViewDelegate and UIPickerDatasource, plus I would be doing the same delegation methods over and over again.
Every time the datePicker is in play it’s sole purpose is to slide halfway up the screen, let the user select a date and then disappear again.
I was contemplating a wrapper viewController (DatePickerViewController) that implemented the datePicker delegate methods, then did a NSNotification with the value which the user selected, which again was caught by the viewController instantiating the DatePickerViewController.
This would make me a decoupled datePicker and let the viewController instantiating the datePicker know nothing of a DatePickerDelegate, but just know that there would potentially come a notification containing an NSDate. Seems rational to me, like something I would do in other languages. But please correct me if Im digging myself a hole here:)
As I started breaking this down I ran into some difficulties, Im not very experienced in Objective C and Cocoa.
I can build a viewController that in it’s viewDidLoad presents a datePicker, running just this will result in a blank white screen with a datePicker in the bottom half of the screen. If I use “presentModalViewController” from the viewController that instantiates the (custom) DatePickerViewController, it of course slides up and covers the whole screen. I would like for the user to still have half the view visible. Much like setting the time in an event in the iCal app. (except they push a new viewController onto the stack). Ahh just realized that what I mean is exactly like the keyboard when it slides in and covers half the screen.
So I guess my main problem is: can you build a viewController that behaves like the keyboard when added to a view. But do all this in the ViewController that is added instead of in the controller instantiating the view.
Hope it makes sense:)
Thank you
(1) Put the picker in a model (edit: should be modal) view. This is how the keyboard is implemented.
(2) The picker controller/delegate should only control the model view and the picker.
(3) In the delegate create two properties such as:
id *target;
Selector theSelector;
and a method like:
-(void) sendPickerResultsTo:(id) theTarget forSelector:(SEl) theSelector;
(4) Before displaying the picker model view, set the target to the calling controller and the theSelector to a method in the calling controller. You can configure the selector method to pass an arbitrary amount of data. It would look something like:
-(void) pickerResults:(NSArray *) pickerResults; //could pass any value as long as it’s an object
[Note: this is kind of thing you define a protocol for if you use it a lot]
(5) When you have the picker value just have the picker delegate call:
[self.target performSelector:theSelector withObject:anArrayOfPickerResults];
(5) Add the appropriate method to any controller that needs to evoke the model picker view and set the controller as the target before you display the model picker view.
This will give you a self-contained model picker view that you can attach to any view and which can send its results to any arbitrary object that implements a method with the right signature i.e. implements the protocol.
This is basically a do it yourself version of UIControls addTarget:action:forControlEvents: