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?
Related
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.
I'm a relative newcomer to cocoa & programming for the ipad.
I've built an app that has a split view controller. In the detail view is a toolbar with a button on it. When the button is pressed, the split view controller is removed from the superview, and another view is put in its place. A toolbar button on this new view removes the view and puts the split view back. Works great... except when the ipad is rotated while the second view is visible. When the user returns to the split view, it's displayed as it was before the rotation.
The split view and all the sub views are set to autoresize=yes, and return yes when they receive the autorotatetointerfaceorientation message.
I'm guessing I need to tell the split view and its sub views to resize themselves when I add it as a subview to the window.
Thanks
Chris
Please see my question concerning this matter here:
Best way to switch between UISplitViewController and other view controllers?
If you use UISplitViewController as Apple intend you to, it's quite limited.
I ended up using a strategy exactly as you mention -- i.e. remove the UISplitViewController's view from UIWindow, and replace with another, and then later switch back. I found out that the orientation change WAS handled, even if I rotated while view B was presented (B being the non-split view), then switch back to A (the split view). However, I had to do a bit of fiddling with the frame size of the uisplitview to make it work. Will update with more info later when I find it.
There's also the option of writing your own split view controller, or using someone else's reimplementation, such as this one:
http://mattgemmell.com/2010/07/31/mgsplitviewcontroller-for-ipad
UPDATE
The fiddling I did with the frame size of UISplitView can be seen in the following method in my AppDelegate. These methods are for presenting the split view controller by replacing another top level view controller under UIWindow:
- (void)removeAllWindowSubviews {
for (UIView *childView in window.subviews) {
[childView removeFromSuperview];
}
}
- (void)presentSplitView:(UISplitViewController *)vc {
[self removeAllWindowSubviews];
UIView *viewForSplitVC = vc.view;
// fix for deficiency in adding a split view controller's view in landscape mode
// and it still having a frame for portrait mode.
// 2010-10-15 added -20.0f to fix problem with toolbar in LHS VC being 20 pix too low.
viewForSplitVC.frame = CGRectMake(viewForSplitVC.frame.origin.x, viewForSplitVC.frame.origin.y,
navigationController.view.bounds.size.width, navigationController.view.bounds.size.height - 20.0f);
[window addSubview:viewForSplitVC];
}
// for removing the split view and restoring the other main VC
- (void)restoreMenu {
if (isIPad()) {
[self removeAllWindowSubviews];
[window addSubview:navigationController.view];
}
}
As I said, it's a hack, but the correcting of the frame gave me the ability to present the split VC without its frame being sometimes incorrect. And as I noted earlier, by doing this stuff, we're going outside what Apple want us to do, hence the hackery involved.
Ok, I have an idea for what might work: Don't remove the UISplitViewController's view from the view hierarchy. Instead, either put a view on top of it, set the alpha property of its view to 0 or set the hidden property of its view to YES.
I have application with multiple UIViewControllers using navigation controller. UIViewController contains tableView, searchbar (that I can show/hide) and toolbar. All of this is added as subviews to its view. All this subviews are created after UIViewController is initialized and their content depend on UIVievController's content.
It works fine expect one problem. When I play with my app a little, move back and forth, open some modal views etc sometimes after navigating back to my root VC all it's subviews dissapear and all I get is white screen.
I double checked all my code and I can't find source of problem (I certainly don't remove them myself). I wasn't able to find exact patern how to reproduce this, it seems random. Any idea why iphone would remove my subviews from VC? I would post some code, but I don't want to put it all here and I am not sure which part is important, so if you wish to see some, let me know
Add your views in loadView or viewDidLoad: when viewDidUnload is called, the view is released, so they need to be created again when the view is shown again.
I am a working UINavigationController pushing two different UITableViews on and off the stack. All of my functionality is working correctly except scrolling. When either table is scrolled above the top row, or below the bottom row, it stays there exposing the margin above/below the table. I am looking for the table to "bounce" back so that only the table is visible and not the white space area beyond - just like any other iPhone app.
One of my UITableViews is being loaded by NIB and the other is being created programatically - both of which have the exact same result. I have tried all the bounce and scrolling settings in the Nib, but nothing seems to work.
Can someone tell me what I am doing wrong? Please let me know if I can be more specific in detailing my problem.
Thanks,
-Scott
I wanted to add a bit more information since I am still unable to figure out this problem. I should point out that the app I am trying to add this NavigationController to is NOT the main view. I have a SettingsViewController that uses a Nib to get loaded. Within that controller, I am wanting to create a new navigation based set of views. So From inside my SettingsViewController, if the user taps a button, I...
Within my button selector:
TextListViewController *controller = [[TextListViewController alloc] initWithStyle:UITableViewStylePlain];
controller.title = #"Test Table View";
navController = [[UINavigationController alloc] initWithRootViewController:controller];
navController.modalTransitionStyle = UIModalTransitionStyleCoverVertical;
[self presentModalViewController:navController animated:YES];
[controller release];
The above code works perfectly in every way except scrolling. I am able to process all the delegate methods and push new controllers onto the stack. The ONLY issue I am having is that the root controller (and every other controller pushed) will not scroll correctly.
In every case, it allows me to scroll past the top and bottom of the table and does not snap back like it should. It also does not have a free-wheel feel to it when you flick scroll. Instead, it stops as soon as you remove your finger no matter how fast you scrolled. Very odd.
I have tried creating another project using the Navigation template - and of course it works fine - but the template assumes the NavigationController's view is attached all the time - which is not my case. I am creating all of this on the fly within a standard ViewController.
Thanks for your help Kevin, but I am still looking for some help here.
Thanks,
Well, I fixed the issue and it had nothing to do with how I was adding the UITableView to the UINavigationController or in how I was instantiating the view. It turns out it was completely unrelated to any of that.
I am using a tight while loop to process my game loop. I needed a way to process OS messages in the loop to keep touches and other events from being blocked. Here is what I was using in the middle of my loop:
while(CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.002, TRUE) == kCFRunLoopRunHandledSource);
Up until this scrolling problem, I had no problems with this implementation at all. For whatever reason, this is breaking the scrolling functionality with UITableView.
I changed my game loop so the above code is not needed and everything started working.
Thanks...
Your UITableView is a UIScrollView, whose property bounces is the key. Here's the reference. By default it is YES, though. Did you check this one?
Your question and comments seem to suggest that you are attaching a UITableView to your UINavigationController in some way other than by pushing a UITableViewController. If you're not doing it that way, you really should.
In general, if you can push a child view controller onto a UINavigationController, then you can also use the child view controller by itself just to test it out. Try making your UITableViewController's view the root view of your window, and see if that does what you expect. That way you can isolate the problem to either the table view part or the navigation part.
I've been having the same issue as you which as you state above was related to the way you were calling the runloop:
while(CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.002, TRUE) == kCFRunLoopRunHandledSource);
Seems like DefaultMode is the wrong thing to be waiting on, I changed my code to wait on UITrackingRunLoopMode and the TableView worked correctly. In my case I used:
[[NSRunLoop currentRunLoop] runMode:UITrackingRunLoopMode beforeDate:[NSDate distantFuture]];
And everything worked correctly.
I'm trying to figure out from Apple's sketchy documentation which method is the best place to be initializing and adding my Views controls to the controller's view.
With winforms it's fairly straightforward, as they're always initialized inside InitializeDesigner, called in the constructor. I'm trying to match the reliability of this pattern if possible.
I'm working with UIViewControllers and UITableViewControllers inside a UINavigationController most of the time - if this effects it all.
Here's an example:
public MyController()
{
// Here?
AddViews();
}
public override ViewDidLoad()
{
base.ViewDidLoad();
// Or is should it be here?
AddViews();
}
public override ViewWillAppear(bool )
{
base.ViewWillAppear(animated);
// Here?
AddViews();
}
public override ViewDidAppear(bool animated)
{
base.ViewDidLoad(animated);
// Or maybe here?
AddViews();
}
void AddViews()
{
UILabel label = new UILabel();
label.Text = "Test";
label.Frame = new RectangleF(100,100,100,26);
View.AddSubView(label);
UIWebView webview = new UIWebView();
webview .Frame = new RectangleF(100,100,100,26);
View.AddSubView(webview);
}
I get mixed results with some UIControls when I add them to the view in different places. Visual lag sometimes, othertimes the webview is hidden somewhere.
Is there a general rule to keep to for adding them?
In general, this is what I do:
ViewDidLoad - Whenever I'm adding controls to a view that should appear together with the view, right away, I put it in the ViewDidLoad method. Basically this method is called whenever the view was loaded into memory. So for example, if my view is a form with 3 labels, I would add the labels here; the view will never exist without those forms.
ViewWillAppear: I use ViewWillAppear usually just to update the data on the form. So, for the example above, I would use this to actually load the data from my domain into the form. Creation of UIViews is fairly expensive, and you should avoid as much as possible doing that on the ViewWillAppear method, becuase when this gets called, it means that the iPhone is already ready to show the UIView to the user, and anything heavy you do here will impact performance in a very visible manner (like animations being delayed, etc).
ViewDidAppear: Finally, I use the ViewDidAppear to start off new threads to things that would take a long time to execute, like for example doing a webservice call to get extra data for the form above.The good thing is that because the view already exists and is being displayed to the user, you can show a nice "Waiting" message to the user while you get the data.
There are other tricks you can use, though. Lets say you want a UILabel to "fly" into the form after the form is loaded. In that case, I would add the label to the form in the ViewDidLoad but with a Frame outside of the view area, and then in the ViewDidAppear I would do the animation to fly it back into view.
Hope it helps.
Hmm, Apple's docs seem to be pretty clear, IMHO.
If you create your own root view (the root view of this particular controller's view hierarchy) programmatically, you should create it in -loadView without calling super and set the view property when done. If your view is loaded from a nib, you should not touch -loadView.
You add custom subviews to the view controller's view or otherwise modify it in -viewDidLoad. The recommended practice is to create your UILabel and UIWebView in -viewDidLoad and release them in -viewDidUnload, setting their references to nil if you need to keep them in ivars.
Note: -viewDidUnload is deprecated in iOS 6 and is just not called any more, because UIViewController no longer purges its view under memory pressure.
viewDidLoad relates to 'MEMORY', and viewWillAppear/viewDidAppear relates to 'APPEARANCE'. A view controller's view (which is a root-view of your view controller's views) can appear/disappear numerous times, even if the controller's view is already in memory.
(When referring to root-view, I also means its subviews, because the root-view has reference to its children (subviews), but from a view controller's perspective, it usually knows just the root-view. Reference to subviews can happens normally through view controller's outlets.)
The root-view itself MAY be removed from memory when there's a memory warning. The view controller will determine when is the best time to removed them from memory.
So, you would normally add subviews in viewDidLoad, because adding subviews means adding them to memory. BUT not if you create all of your views programmatically (not from a nib files). If that's the case then you should override loadView method, and create a root-view and add subviews there, so in this case you can omit viewDidLoad to add subviews.