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.
Related
In ios, where's the best place in a view controller to move your custom subviews around to handle rotations? (of course this is only for those where the autoresizingflags don't help).
Here's the following places i've tried, and the issues each has:
willAnimateRotationToInterfaceOrientation:duration
This works, and any subview frame changes you make are animated nicely as the device is rotated landscape<->portrait. However, if you're in a tab controller, this doesn't get called when another VC is visible. And so if you rotate, and switch back to this tab, it'll have the wrong layout.
viewWillAppear
Doesn't really help, because this gets called before the rotation takes effect, so when accessing self.view.frame you get the pre-rotation sizing, so you can't know whether we're going for landscape or portrait
viewDidAppear
This is better than viewWillAppear, however because it gets called after the view goes on screen, you see a flash of content in the wrong layout before it flicks across.
I just want to know where the proper place is to put my code that lays out my view controller's subviews nicely to handle both layouts, animated nicely. THanks all
I usually have my own layoutViewsForOrientation:(UIInterfaceOrientation) method which I call both from willAnimateRotationToInterfaceOrientation:duration (to get the nice animations you mention), and from my viewWillAppear: (with self.interfaceOrientation) to set up my view before it appears.
So the answer is that the proper place to layout your view is whenever something changes and you're not sure that it's in the proper orientation, and you can use a layout function to keep your code clean.
The problem here, from my experience, is that if the UIViewController is not visible, it won't rotate. You can have 3 tabs each one with a distinct UIViewController (A,B and C). If you are in A and you rotate, B and C won't. I resolved this, by having a UIViewController (Lets call it D) to hold the UITabBarController, then in this UIViewController I have a reference to each UIViewController (A,B and C) so i just call the willAnimateRotationToInterfaceOrientation:duration method for each UIViewController when D rotates. Works very well for me. :)
The best i've come up with personally is to grab every event, seems to work, but its worrying me that there should be a better way to do this, and that i'm doing something wrong.
- (void)doMyResizing {
self.somesubview.frame = ...
}
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
[super willAnimateRotationToInterfaceOrientation:toInterfaceOrientation duration:duration];
[self doMyResizing];
}
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[self doMyResizing]; // This is for the case when the person uses this tab in portrait, changes to another tab, rotates to landscape, and switches back to this tab
}
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self doMyResizing]; // This is for the case when the person uses this tab in portrait, changes to another tab, rotates to landscape, and switches back to this tab
}
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 have an application with 8 UIViewControllers presented by navigating from left/right/up/down. They are created on start of the app and kept in an NSArray. Only 1 of them is added to the view tree (addSubview:) at any time - the rest just sit in the cache until they are needed.
Now the problem I am having is when rotating to Landscape. Only the currently visible view changes the bounds.size to Landscape. When navigating to the next view, that view still thinks it is in Portrait (but the containing views will all look in Landscape).
By the way, the view hierarchy of the app is the following: UIWindow -> Main UIViewController -> 1 of the 8 cached UIViewControllers.
For example:
* Change orientation:
- Main UIViewController.view.bounds.size = 480x300 (OK)
- One of the cached UIViewControllers view.bounds.size = 480x300 (OK)
* Go to next view:
- Main UIViewController.view.bounds.size = 480x300 (OK),
- Another of the cached UIViewControllers view.bounds.size = 320x460 (??)
Not sure whats going on. Do I have to tell the cached UIViewControllers somehow that the orientation/size changed or something else?
Thanks a lot
Yes you can. Optimally you should purge the view that each view controller manages when it goes off screen.
Simply assign nil to the view property of the view controller that is being replaced. This will free all resourced used by the view that is not visible anyway. As an added bonus the view is then recreated with proper frame whenever you decide to brin a particular viw controller in front again.
I am also assuming that what you are implementing is a subclass of UIViewController that acts as a container for other view controllers. Like a sibling to UITabController named CWGridController or similar. Noe that it is the responsibility of the the parent view controller (your subclass) to size the frame of it's child view controllers views as needed.
Creating a container view controller is not a small task, and the support for doing it is not complete from Apple. There are a few things you must do including but not limited to:
Forward all orientation change calls to all child view controllers.
Properly call all appear/disappear on child view controller as needed.
The last part to make it work is to break some rules. View controllers works very badly unless they know about their parent view controller, layout will be wrong and modal view controller behaves strange. Unfortunately the parentViewController is readonly, or so you would think. Setting it anyway using KVC will solve most problems, and Apple does not seem to object when you submit to App Store:
[childViewController setValue:self forKey:#"parentViewController"];
In viewWillAppear you will have to check the interface orientation and set the frames accordingly.
My app has a welcome screen that can only be shown in portrait mode. After the user has tapped through the welcome screen I'd like to show another screen that can be used in both portrait mode and landscape.
I have set up a view controller that implements shouldAutorotateToInterfaceOrientation: returning YES only for UIInterfaceOrientationPortrait, and I add the view to the window with [window addSubView:view]. I tag this view with the tag 1.
When the user taps through the welcome view and the app moves on to the new view I do:
[[window viewWithTag:1] removeFromSuperView];
[window addSubView:myViewController.view];
Where myViewController is an instance of the 2nd view's view controller (that handles the shouldAutorotateToInterfceOrientation method properly).
Now when I rotate, it still calls shouldAutorotateToInterfceOrientation on the original view's view controller, and does not call it on the new view's view controller.
This note from Apple says that only one view controller will get rotation notifications; however, I have removed the other view controller.
What am I doing wrong?
actually that note doesn't say that "only one view controller will get the notifications" but instead it says that "Only the first view controller added to UIWindow will rotate.".
So this might be the problem.
To resolve it, i would say to always have a view added to your window (call it permanent), and add your welcome screen and the next views to this permanent view.
Hope this helps.
as the note you link to state:
Only the first view controller added
to UIWindow will rotate.
So put a flag that makes sure that shouldAutorotateToInterfceOrientation returns NO until the user have dismissed the screen - and then returns YES afterwards. This is a simple and working solution - however, from a code readability point it might be confusing that a "dismissed" view actually controll the rotation.
Personally; my experience is that it's not really worthwhile having some views rotating and some don't - and users tend to don't like it.
happy coding
I wrote up a quick test that shows what you are trying to do should work. Here are the basics I did:
Create two view controllers. App starts with the first view controller being set in the AppDelegate into an instance variable viewController through NIB files. It is then added to the window as you have written.
I then setup an action that when called (could be a Timer, button on first view controller, etc.) that performed the following:
Remove view using [self.viewController removeFromSuperview]. This is different than the way you have done with the tag.
Created second view controller and assigned it to self.viewController.
Added to window like you have specified.
Not sure what is incorrect with your code. I would guess that perhaps the first view wasn't really being removed.
I am putting an iPad application together that allows a user to work their way through a virtual tour. They are able to move forward through screens on which some will have buttons to other material such as a video or more info.
If Keynote supported Hyperlinks then it would be well suited but as it doesn't I am trying to recreate the tour within Xcode.
I am a newbie but have spent time researching and have code to display the 'slides' and the capability to move forward and back through them. The slides are no more that an image view with a full screen graphic and buttons for the various options, some slides are simple and have nothing other than back and forward but others will have additional links
However doing it in this simplistic way means I am ending up with a huge number of view controllers and XIB files, currently at 75 which I know must be more than any app should have. However it does work although on occasions when running it on the device and not in the simulator it will bomb out.
My questions are is there a limit to the number of view controllers in one app and will having a large number cause the instability? I'm aware of other ways to handle the views such as having them in arrays and pushing them out a single view controller but this won't give me the flexibility to tailor slides for different content.
I'd welcome any help or advice and I hope have gone about posting this question in the right way (its my first)
Many Thanks
Kieron
The code I am using to manipulate the view is
-(IBAction)goBack {
[self dismissModalViewControllerAnimated:NO];
}
-(IBAction)goForward {
Slide5ViewController *screen = [[Slide5ViewController alloc] initWithNibName:nil bundle:nil];
screen.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
[self presentModalViewController:screen animated:YES];
[screen release];
}
Kieron,
Why not have one "slide" view controller and a different image only? Use some sort of data structure to keep information about the buttons, images, and pathways for each slide, and then just keep re-using the same view controller for each slide?
The view controller can then dynamically load each image as it transitions between the currently visible view and the next instantiation of itself... It should be possible using only 1 view controller.
If you're comfortable with using Interface Builder, keep using the XIB files to lay everything out. However, instead of setting each "File's Owner" to a different view controller, set them all to the same one. Then, inside your IBAction methods (when the user pressed a button), use some logic to say "I am on this view right now, and the user pressed this button, so which one should I go to next?"
Then, call a method like loadNewSlide: that might look like this:
- (void) loadNewSlide:(NSInteger)slideNumber
{
// Make a string with the new XIB name
NSString* xibName = [NSString stringWithFormat:#"slide-%d",slideNumber];
// Create the next slide view controller (it doesn't matter if you create a slide view
// controller from within another slide view controller, remember, they are all just
// objects)
SlideViewController *newSlideViewController = [[SlideViewController alloc] initWithNibName:xibName bundle:nil];
// Change the view
UIWindow *theWindow = [self.view superview];
[self.view removeFromSuperview];
[theWindow addSubview:newSlideViewController.view];
// Release, the view stack now should be retaining the view controller instead
[newSlideViewController release];
}
This will work MUCH better than running "modally" with 75 view controllers (as you had previously suggested) because this will only keep 1 slide in memory at a time - whatever you are currently looking at - and then will load the next slide just in time to move to it.
Fist of all, what error is in the log?
Did you properly implemented viewDidUnload method of view controllers? View controllers should be able to unload loaded xib. Also, release data in didReceiveMemoryWarning.
Second, it could be better to use UINavigationController to handle view controllers stack instead of modal view controllers stack. You can hide navigation bar or customize it.