i have an app that uses a navbar. What i want to acomplish is make it transparent when i push in the last view from the nav sequence, and make it opaque when i click the back button on the nav
i tried with on dealoc, but it doesn't work. My view is an UIScrollView not an UiView, but i guess that makes no difference.
As i see it, eighter i have to control the events on the nav bar, and see the type of the view with a loop or trigger some event on the "unloading" of my current view
when i push in the view i do a
self.navigationController.navigationBar.barStyle = UIBarStyleBlackTranslucent;
and when it pops out i need the
self.navigationController.navigationBar.barStyle = UIBarStyleBlackOpaque;
Pushing and popping a view with UINavigationController or UITabController will call the view
{Will,Did}{Appear,Disappear} methods so I think you need to hook into the child view's ViewWillDisappear.
I'd architect it so that top level navigation controller sets itself as the childs delegate, and the child calls its delgate with an "I'm unloading" type function where you change the navbar style.
Actually the best way for this is to use UINavigationControllerDelegate. I extended UINAvigationController and set the delegate to self and used one of the methods of the UINavigationControllerDelegate protocol.
You can't really depend on dealloc to ever get called, much less when you want it. That should only be used to release retained objects.
I think you should be able to add the barStyle changes in the viewDidAppear and viewDidUDisappear methods of your view controller.
Related
My UIViewController calls a function on my rootViewController which then called popToRootViewControllerAnimated to return the view to the rootController. This all works - great!
Unfortunately the UINavigationItem (toolbar at the top) seems to display a mashup of both the rootViewController and the UIViewController that has just been removed.
What do I need to do? What have I done wrong?
The navigation bar doesn't remember changes that were made to it, so when you push a new controller, the navigation bar is altered to give the title of the new view controller, but it doesn't store what was there for the previous view controller.
You will need to recreate the items in the toolbar each time you come back to the view controller that has custom items.
You might be able to do this on viewWillAppear instead of viewDidLoad. I can't recall exactly, but you should recreate custom controls on navigation toolbar because it does not get preserved when a new view controller is pushed.
It seems that calling popToRootViewController from the rootViewController messes things up. TO rectify this I called the following from within the calling UIViewController
[self.navigationController popViewControllerAnimated:YES];
I have a problem. I am working on an app which is tab bar based app. In this app, we call [self.view addSubview:newVC.view] when we want to navigate to a new view. newVC is the view controller of the new view that we want to display. Also we use [self.view removeFromSuperview] when we want to go back to previous view.
So in other words, there is no navigation controller. Now problem is that I want to update the previous view. Since we are using [self.view removeFromSuperview], viewDidAppear of the previous view is not get called and so we have no way of refreshing that view.
I know the approach that we used has flaw but since its a large scale app and changing it to implement navigation controller with take lot of time so I need you to please help me find the solution of this problem. How can I call the viewDidLoad or viewDidAppear or the previous view on calling [self.view removeFromSuperview] from its subview?
Yes, as Sarah said you should hold a reference to previous controller in "stack".
And when "poping" controller from stack, call appropriate method on previous controller.
Certainly you should not call viewDidLoad (it is not called when you pop controller from navigation stack of real UINavigationController).
You can call viewWillAppear or viewDidAppear, but better use your own method, like viewRevealed (you can also call it from viewWillAppear or viewDidAppear). It is useful to make
base class where implement all this functionality and derive all you controller from the base class. It may look like:
- (void) pushViewController:(BaseViewController *)baseController{
[self.view addSubview:baseController.view];
baseController.parentController = self;
}
- (void) pop{
[self.view removeFromSuperview];
[self.parentController viewRevealed];
}
viewDidLoad method call only when when you jump into a controller through pushViewController method. If you call removeFromSupreView, it will call viewWillAppear method. Here if you want to navigate from one view to another view over tabbar you must use UINavigationController in Mainwindow.xib and connect its viewController with App delegate.
Let's say I have a viewcontroller "ViewBViewController". In that viewcontroller I create an instance of the "ViewAViewController" and use the addSubView: method to display this ViewAViewController. It then processes a bunch of information, and is now done. I want it to automatically get removed as a subview when it's done.
I was looking at the removeFromSuperview method, but can't seem to call that from within the viewcontroller whose view I'm trying to remove (my first instinct was [self.view removeFromSuperview], but that gets rid of the entire view, not just the subview I'm after).
The only way I can think of is setting up a delegate protocol, and have View B take care of the unloading of View A on behalf of View A as its delegate. However this approach seems a bit overkill. Am I missing an easier solution?
Thanks in advance!
UIViewController does not respond to removeFromSuperview, because a UIViewController is not a UIView but a UIViewController. No surprises there. You can call removeSuperview on any view, such as the view associated to a view controller (here self):
[self.view removeFromSuperview];
or if you just want to remove one subview:
[mySubview removeFromSuperview];
or if your subview is a member of self (i.e. declared in the interface say):
[self.mySubview removeFromSuperview];
Have you tried: setHidden: YES ?
There are two basically correct solutions here:
Use a navigation controller. You can hide the navigation bar if you don't want it to be part of your interface. Then you can dispose of the top view controller and its view from either view controller by calling
// argument can be YES or NO, as you like
[self.navigationController popViewControllerAnimated:YES];
Use a delegate call that tells the parent view controller to do something like
-(void)removeViewA {
// remove the view from the view hierarchy
[self.viewAController.view removeFromSuperview];
// dispose of the view controller so it doesn't leak.
self.viewAController = nil;
}
It's important to make sure that you don't leak the child view controller and its view.
Either of these approaches works, but using a navigation controller seems more idiomatic to me.
I've made a custom view to which I add a custom button. This custom view goes as a subview to yet another view (Kal calendar for iphone) that I push into a navigation controller. Now the button in my custom view is connected to an IBAction in which I am not able to call upon the self.navigationController to pop the current view from.
I've tried the [[sender superview] navigationController] for a hierarchy of superview calls but it doesn't work that way either.
Any ideas please?
Thanks
A view typically has no knowledge of its view controller (and consequently, to its or its superview's view controller's navigation controller) because this would introduce a tight coupling between view and view controller that is usually unwanted and unnecessary.
The easiest way to solve your problem would be to have the view controller instead of the view handle the button's action. If that doesn't work for your design, consider designing a delegate protocol for your custom view and make your view controller the custom view's delegate. The view would then call the delegate method in the button's action method. This latter method is used a lot throughout Cocoa, e.g. by UIScrollView (UIScrollViewDelegate) and UITableView (UITableViewDelegate).
I am sure this is an easy question, but one that has escaped me for some time now.
Say I have a UIViewController, either defined as a root in an XIB or on a stack. At some point in my code I want to replace it with another view controller. Just flat out replace it. How would I do that?
I have tried defining the controller and assigning, but not sure what actually makes it push on the screen with the absence of a navigation controller.
I think when you say that you want to replace the view controller, what you actually mean is that you want to replace the view. Bear in mind that view controllers aren't visible, but every view controller maps to a view, which can become visible by getting added as a subview of a visible view.
Your solution of replacing self.view with the new view controller's view may work in your particular case, but it's probably not the "correct" answer to your question. There are going to be cases where this solution won't work for you.
Let's say you have a simple view based application with no navigation controller and no tab bar controller. In your app delegate you construct an instance of YourFirstViewController, and you call [window addSubview:yourFirstController];. Your view hierarchy now consists of a UIWindow with a single subview -- the view for YourFirstViewController.
Now let's say the user presses a button on that view, which is handled by an IBAction defined in YourFirstViewController. You want to respond by "replacing" YourFirstViewController's view with a view associated with YourSecondViewController. I put "replacing" in quotes because we more commonly present a view by pushing its view controller onto a navigation stack, or calling presentModalViewController:animated: to present the view modally, but let's assume that you've rejected those options for some reason, and you actually do want to manually replace YourFirstViewController's view with YourSecondViewController's view.
This is a simple matter of manipulating the view hierarchy. You want to remove YourFirstViewController's view from its superview (the UIWindow in this case), and you want to add YourSecondViewController's view as a subview to replace it. Your action would therefore look something like this:
- (IBAction)replaceButtonClicked {
UIView *mySuperview = self.view.superview;
YourSecondViewController *secondController = [[YourSecondViewController alloc] init];
[mySuperview addSubview:secondController.view];
[self.view removeFromSuperview];
[secondController release];
}
When we use a methods like -pushViewController:animated: or -presentModalViewController, the receiving controller manipulates the view hierarchy for us. This may make it seem like we're looking at view controllers on the screen, but we're not. We're just looking at a big hierarchy of nested views going all the way up to a UIWindow at the top.
You can present a new view controller modally:
[self presentModalViewController:aViewController animated:YES];
This won't outright replace the current VC, but it will display a new view over the current view.