Is it possible to get a double picker to appear from the bottom of a screen when a certain button is selected? And is it possible to remove a value from a picker if it was already selected?
Of course it's possible. I did that for an app just this summer. But you'll have to code the component yourself.
My suggestion is to create a class which has a UIPickerView member; this class, when instantiated and sent a message (like -showInView:), will make the view slide up. You'll need to have a delegate protocol for the class; it will probably make sense to have its delegate also implement UIPickerViewDelegate and UIPickerViewDataSource.
Related
This is maybe a simple question, but I don't have a clue the keyword i had to search for this...
I want to create a simple selector (I called it spinner in Android). This is what i want to achieve
Or it will take a whole screen if it's in ipod touch / iphone.
So, I have 3 button that represent filter (category, country, sort) for a ListView... and if I press one of the button, a popover / dialog should be appear to select the filter for each button.
thanks...
Please let me know if I need to add some information to make the question clear.
Its not so much typical that is it appearing.
Create a new UIViewController class with xib and adjust view size you want to display for combo box or popviewControoler. Then put navigation controller over and tableviewController.
And customize your UIViewController using its controller class. Controller class will be reponsible for displaying and selecting data.
Now in your MainViewController From where you want to show ComboBox or popviewcontroller.
declare popViewController instance variable,synthesize it.
implement a userdefined method here alloc your popviewcontroller class and assign it to popviewController instance variable of your class.
Then called it didSelectRowAtIndexPath.
When popover dismiss you set popViewController result in instance variable of this class so it can easily access in MainViewController class.
You can achieve combo box like functionality by adding a UItableView in a UIView and implement all the delegates of UITableView in that custom view.
Now you can add object of that custom UIView where ever you want that combo. Just you have to workout with some Frame setting.
I have following codition for my app as shown in image.
On left View : The different User selection will be done in table view.
And the selected users information will be needed on right view while pressing the button.
How can I do this ?
Use of Protocol is very simple to solve your problem.
When you tap on row on left side, then you just need to pass the object as userinfo and make a call to its delegate method which will be implemented in rightview.
This is very simple task if you know how to implement protocols for the viewController.
Hope this helps you.
Use a delegate pattern.
When a row is selected from the table view in the left view, call the delegate to notify the selection. Afterward your delegate (which suppose to be the right view's controller) can display the corresponding user info.
I'm a newbie doing Objective-C, coming from Flex/Actionscript development.
I have an iPhone app with an UIApplicationDelegate conforming delegate called MyAppDelegate - it has a UIWindow.
Instead of adding buttons, labels and whatnot directly to the window, I guess I'm supposed to make a child class of UIViewController for every screen I wanna make. When that screen should be displayed, I add the respective controller's view to the window as a subview. When another screen should be displayed, I should pop off any other view from the window and add the new view. Hope I got everything correct so far...
My intent is to make each view controller only know about its own things, so let's say I wanna call view A from view B, in ActionScript I'd add a button in A firing off an event which would be caught in view A's owning object (could be the application), which could take proper action (remove view A, instantiate view B and display it).
How do I do this in Objective-C?
A UIControl, such as UIButton, can have any number of event listeners registered with:
- (void)addTarget:(id)target action:(SEL)action forControlEvents:(UIControlEvents)controlEvents;
The target would be the view controller you want to receive the method, and the action is the method you want called. For a button, events is usually just UIControlEventTouchUpInside. If the target is nil, the event will pass up the responder chain until a responder implements the action. If you pass #selector(buttonClicked:) then the target should have this method:
-(IBAction) buttonClicked:(id)sender;
The sender will be the button that was clicked. IBAction is equivalent to a void return type. You can bind the action in Interface Builder if you prefer that to doing it programmatically.
When another screen should be
displayed, I should pop off any other
view from the window and add the new
view.
This is basically correct, but usually you use a meta view controller like UINavigationController to manage view controllers. Even if you do not use the UI that a meta controller might present, it is convenient to have view switching managed for you.
If you're coming from Actionscript you may be interested in looking at the PureMVC framwork for objective C. Using PureMVC you'll create a combination of Mediators, Commands, and Models for application interaction.
With PureMVC you register notification with the facade, and you define listeners in your mediators to respond to these. This is pretty close to the event model you're used to in Actionscript. (At my last job we added some categories to the UIResponder to remove some of the cruft in doing this). If you're creating a considerably sized application, then I would recommend you give it a look; it certainly helped us keep everything manageable.
If you don't want to pull in a third party library then you should define your view manipulation code in your MyAppDelegate and use the [UIApplication sharedApplication] class method to access the globally shared instance.
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:
I have a view which I built in Interface builder with a tableview and associated outlets etc, to display a list of items. Clicking on an item brings up the detail of that item.
I now want to build a very similar view with a list of the same kinds of items and some additional controls and different behavior on cell selection. In this case, if the user clicks on the item, they will effectively be using that item as a template to create a new item. Or, they can click on a button to create a new item. Aside from this, there is a lot of logic I want to reuse from the original view - for example the items are location dependent, and there is a background thread that updates the location information.
It seems like the natural thing to do would be to subclass the original viewcontroller, and build a second view layout using IB. However, before I embark on this I'm wondering if this is possible/recommended practice? Will IB recognise the IBOutlets in the superclass and let me wire them up?
IB will recognise the IBOutlets defined in the superclass.
You do it all the time: The outlet for the view in UIViewController is defined in a superclass you subclass for each of your View Controllers.
pgb is correct. IB will recognise outlets in the superclass
As for whether subclassing the controller is a good or bad idea, I'm not sure. Apple suggests subclassing NSArrayController in order to change sorting/filtering behaviour. A view controller is different to an array controller, but I dare say that subclassing the view controller is probably the correct thing to do.