I have a situation where i have to reload all subViews of my current view....I am adding all objects(like buttons, images ...etc) from interface builder.....
And i want to reset these subviews when user click on a button...
i tried [self.view setNeedsDisplay]; but it doesn't works.
Is there any simple way to do this...
Any suggestion?
I am not sure that what happening in your code but i guess
You should add all subview programatically and refresh on button click event,
or write code in viewDidAppear method.
Reloading them sounds like the wrong thing to do. You can easily reset them to their default state programmatically by setting the various properties to your defaults. Once you do that I would probably just create the whole view and subviews programmatically without using IB. I do everything programmatically now and find it easier to maintain my code.
You could come up with a NIB based solution by putting all affected subviews within a parent UIView and load just that parent view from a NIB and then replace the parent UIView only but I don't recommend it. You need to able to set subview properties programmatically in viewDidLoad anyway in case the view controller needs to unload/reload the view based on memory warnings.
May be this is helpful to you.
One way is create on UI method that set default or required value for required controllers. And call it on button event.
Related
In UIViewControllers I have several methods such as viewDidLoad, viewWillAppear, viewDidAppear, etc.
The question is: "what is the best place to, for example, set the background color of my view, instantiate, and set the background color of a UILabel, or instantiate an object that I set as #property in my class and things like that? "
Thanks!
So many questions at once!
The first time the view is loaded, in viewDidLoad you will already have access to all the readily initialized UI elements, so it is a great place to configure the view and to set your class properties.
If you come back to the view if it is already loaded (say, by popping a view from a navigation controller, or dismissing a modal view controller), viewDidLoad will not be called. Thus, if you want to change something (background, add a label, change the background of a label, etc.) based on something that might have happened since the view controller was initialized, you have to use viewWillAppear.
You would use viewDidAppear if you want to animate a change so the user can see it after the view has already become visible.
Edit: this is pertinent for if you use IB or storyboard. See CitronEvanescent's answer for the case that you create your view in code.
The feasible method would be viewDidLoad or -(id)init,-(id)initWithNibName constructors of the class.
viewWillAppear and viewDidAppear should be avoided,since you would not like to instantiate your variables again and again since they get called every time the view appears(from pop or tabSwitch).These two methods can be useful in case you want to change some variable values on reappearance
If you are creating your view programaticaly, you can set your properties on - (void) loadView this method will be call once before anything is displayed.
Generally i prefer instantiating the UI elements in the -(id) init and update their UI in loadView.
For further details : View construction reference
Basically i wanted to implement a popup UIView so i followed what was posted here
POP-UP UIView "IMDB App" style
This works very well. However i have one query. My main view is a tableView. so when a view is popped up i disable scrolling in the table. Now when the popup subView is removed, i need to re-enable scrolling. How do i achieve that? i can't use willRemoveFromSuperview because the popup view is loading a different NIB altogether.
Should i use Notifications?
hope i was clear with explaining the scenario.
Thanks in advance!
Feloneous Cat has the correct answer. This is the perfect use a #protocol in your popup view along with a registered delegate. Something is triggering that popup view to close. Whatever that trigger is, call the protocol and the delegate can handle the situation as needed.
Furthermore, when protocols are used correctly, your code becomes very reusable within a project as well as in other projects.
What you could do is subclass UIView and override removeFromSuperview to send a notification. I don't think there's ever a case where a view gets removed without using the removeFromSuperview method.
I have a main view with a UINavigationController and a subview (both added through interface builder). I have a UIBarButtonItem in the navigation toolbar. When that button is clicked, I want a popover view to come up (with a table format) with options for different subviews to choose from. When a user chooses one of the subviews (by clicking a cell), the popover should fade away and the subview should change to the user's chosen view.
Those view options should be loaded from separate xib files.
I know it's a relatively complicated question, but what is the best way to do this?
I don't necessarily need code, but that would be helpful. Thanks guys!
Check this tutorial about the popOvers:
http://mobiforge.com/designing/story/using-popoverview-ipad-app-development
Are you looking for something similar to this?
Checkout the – loadNibNamed:owner:options: of NSBundle(UINibLoadingAdditions). Your view will be the first index object of the returned array commonly.
I've been working for a while now on switching UIViews, and am trying a basic UIView switch, without using UINavigationController. I've looked into UINavigationControllers, but I have been wrestling with the below for so long that I want to explore it fully.
My project organisation is:
MainViewController.h/.m -> viewDidLoad: This method runs a NSTimer to update self.view with a few bits and bobs.
ConfigView.h/.m: -> viewDidLoad: nothing - just an idle view.
MainViewController.xib -> Main window NIB
ConfigView.xib -> ConfigView NIB
I have the following method in MainViewController.m execute on a UIButton press event:
- (IBAction)switchToConfigView:(id)sender {
if(self.configViewController == nil) {
ConfigView *cv = [[ConfigView alloc] initWithNibName:#"ConfigView" bundle:nil];
self.configViewController = cv;
[cv release];
}
[self.view addSubview:configViewController.view];
}
Now, when I switch to the ConfigView, the view is indeed displayed, but it appears that viewDidLoad: from MainViewController still executes, causing both views to effectively be merged. From the code, I can see that this is obviously the case, as the actual view switch itself is performed within the MainViewController context, and as you can see, simply a subview.
My question is, how do I neatly tuck away/pause all goings-on within MainViewController when switching the view by just adding another subview to it? My guess is that it's not possible, or rather it's a lot of leg work where some other methodology would be better applied. I suspect I need to implement the actual switch from the ConfigView.h/.m but I could be wrong.
Any light you can shed on the above would be grand.
thanks
swisscheese.
My suggestion is:
1) have a base, empty view;
2) add a subview to it; this would be your actual first view;
3) when you want to switch, remove the first subview from the base view and add the second one as a subview;
4) when you want to switch back, remove the second one and add the first one as a subview to the base view;
you can easily handle as many view as you like. it works.
alternatively, you can hide the view instead of removing it.
Believe me adding a whole new sub-view on another view is really a massive task and later on when the project becomes big it becomes a painful task to switch views.
This is my own personal experience as I did this big mistake in one of my previous project.
In all cases navigation control is the best choice for switching views rather than adding sub-views.
Please tell me that what difficulties are you facing in Navigation control and I can help about this.
Thanks,
If the NSTimer you've set up in MainViewController's viewDidLoad method is adding subview's to mainViewController's view with the addSubview method, those views will be placed on top of all other subviews, i.e. on top of the config view. So, you might try either invalidating the timer when presenting the config view.
You should really just use a UINavigationController, or present the config view controller with presentModalViewControllerAnimated. Why don't you want to?
I want to add a shadow (using the layer property of the view) to my view controller's view. Should I do this in load view after creating the view myself.
Or should I do this in ViewDidLoad.
EDIT: Currently I haven't implemented loadView.
The short answer is, if you're using loadView, it doesn't really matter whether you configure the shadow there or in viewDidLoad. viewDidLoad will be called right after loadView, in every case.
The longer version is that if in the future you decided to move your view creation into a XIB file, you would want to remove your implementation of loadView. In that case, you would need to customize the layer shadow in viewDidLoad. So theoretically you could save your future self some copy and paste work by putting it in viewDidLoad.
the loadView method is intended for view controller's view creation. So if you want to add shadow to it, then this would be the best place. And if you want to customize it's subviews, then it's better to do that in viewDidLoad