views:

444

answers:

1

Hi 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  A: 

(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:

TechZen
Hi TechZenThank you very much:)There are a few things I don't understand; what is a "model view"?I would like to end up with CustomDatePicker.m and .h, instantiating this and adding it to the current view will slide up a datePicker and selecting a date will call an eventHandler on the viewController adding the datePickerView. This would mean I only had to implement the handler method and wait for the notification, not conform to any protocols?Maybe your way is better, but a bit new to me, can you point to an example out there. Thanks again.
RickiG
I think he means modal view -- a view which while up takes all input. Other views don't get user interaction events.A dialog box (error/warning) that won't let you click on anything else until you confirm it is an example of a modal view.
Epsilon Prime
Thanks Epsilon:)I went on a searching spree for "Model View" thinking there was a magical UIView type I had not seen yet.(got a few billion 'Model-View-Controller' results on that one) I want the user to be able to tap elsewhere, like the keyboard, nothing prevents you from doing that. I tried incorporating a Picker in an ActionSheet to get the 'slide in' animation etc. but that truly locks up the screen.Maybe I should try building the view and do my own animation.
RickiG
Sorry for the typo.
TechZen