I have this weird problem where the buttons on the simulator or my iPhone are not showing when the class of the view's set to TPKeyboardAvoidingScrollView.
Here's a screenshot:
When the view's class is set to UIView (default) it works properly.
See this post for instructions.
For non-UITableViewControllers, use it as-is by dropping the TPKeyboardAvoidingScrollView source files into your project, popping a UIScrollView into your view controller’s xib, setting the class to TPKeyboardAvoidingScrollView, and putting all your controls within that scroll view.
To use it with UITableViewController, pop the TPKeyboardAvoidingTableView source files in, and just make your UITableView a TPKeyboardAvoidingTableView in the xib — everything should be taken care of.
Are you using it with or without a UITableViewController? Make sure you've embedded the button in your UIScrollView. The site linked above also has a sample project you could reference for more help.
This is most def something very simple, but it is driving me crazy, cant figure it out.
It was very simple, see solution below
My app does not auto rotate. It is just stuck in portrait.
My AppDelegate creates a viewController witch has shouldAutorotate uncommented an simply returns yes.
My viewController sets up a scrollview(x) as it's view and adds a subclassed custom scrollview(y) as its subview.
Than scrollview(y) adds UIView as it's subview. This UIView acts as a content view and has 1 or multiple other UIViews as subview.
So: AppDelegate -> scrollView(x) -> scrollView(y) -> UIView -> 1 or more UIView's
I have a line displayed when shouldAutorotate is called. This happens 2x when the application has finished loading. When I rotate the simulator, nothing happens, shouldAutorotate is not called apparently because I don't see a line displayed in my log.
Is there a property on the UIScrollview which prevents it from rotating?
Update: I've just changed my plist.info to start the app in landscape. Now the app is stuck in landscape and does not rotate to portrait.
FYI: I'm not using interface builder, all done in code.
Solution: Turns out I was a bit to memory conservative. In my app delegate I would create an instance of a viewController, add it to the window, and than called release on it, figuring it was added to the window so I wouldn't need it anymore. Bad idea.
The shouldAutorotate messages is therefore sent to an object that does not exist anymore. I did get a message in my console about a message being sent to a released object, but only multiple seconds (20 or so) after I rotated the simulator.
I've learned that you should always keep a reference to your "main/root viewController" as an instance variable in appDelegate
I created a app with the iOS 4.1 SDK.
In this app I did the following: I add two UIView's as subview to the Window of the Application. One view is a navigationcontrollerview and the other is a view that displays advertisement. The user can then navigate trough the app will the ads are displayed uninterrupted.
Now comes the problem: I wanted to add the option to rotate the device from portrait to landscape and back. The problem is only the first view (in my case the navigationcontrollerview) is rotated without problem. The second view is never rotated. Documentation from Apple confirms that this is the default behavior.
So, how do I get my second view rotated? Do I need to restructure my application? And why is the second view never rotated? That doesn't make any sense to me.
Are you just adding the second view (the one that doesn't rotate) as a plain UIView? If so, try adding it after containing it within a UIViewController class. I had the same issue in my app not so long ago. instead of [window addSubview:sampleView], I did [window addSubview:[sampleViewController view]]; where sampleViewController subclasses UIViewController.
In general, always use corresponding view controllers and contain views in them and then add subviews to avoid these issues.
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'm doing an iPad tech demo and I'm running into a serious technical problem.
I have an app concept that leverages UISplitViewController, but NOT as the primary controller for the entire app.
The app flow could be described roughly as this:
Home screen (UIViewController)
List->Detail "Catalog" (UISplitViewController)
Super Detail Screen (UIViewController but could conceivable also be a child of SplitView).
The problem is in the flow between Home and Catalog. Once a UISplitViewController view is added to the UIWindow, it starts to throw hissy fits.
The problem can be summarized at this:
When a UISplitView generates a popover view, it appears to then be latched to its parent view. Upon removing the UISplitView from the UIWindow subviews, you will get a CoreGraphics exception and the view will fail to be removed.
When adding other views (presumably in this case, the home screen to which you are returning), they do not autorotate, instead, the UISplitView, which has failed to be removed due to a CG exception, continues to respond to the rotation instead, causing horrible rendering bugs that can't be just "dealt with". At this point, adding any views, even re-adding the SplitView, causes a cascade of render bugs.
I then tried simply to leave the SplitView ever present as the "bottom" view, and keeping adding and removing the Home Screen from on top of it, but this fails as SplitView dominates the Orientation change calls, and Home Screen will not rotate, even if you call [homeScreen becomeFirstResponder]
You can't put SplitView into a hierarchy like UINavigationController, you will get an outright runtime error, so that option is off the table. Modals just look bad and are discourages anyway.
My presumption at this moment is that the only proper way to deal with this problem is so somehow "disarm" UISplitViewController so that it can be removed from its parent view without throwing an unhandled exception, but I have no idea how.
If you want to see an app that does exactly what I need to do, check out GILT Groupe in the iPad app store. They pulled it off, but they seem to have programmed an entire custom view transition set.
Help would be greatly appreciated.
Apple states:
The split view controller’s view
should always be installed as the root
view of your application window. You
should never present a split view
inside of a navigation or tab bar
interface.
This does mean it should be root view and not subview of another view. Even though they add:
You should never present a split view inside of a navigation or tab bar interface
That does not mean you can add it as a subview of any other controller either. (sorry)
I have a feeling that what you are experiencing is the byproduct of trying to do so. I am actually surprised that GILT Groupe's app did not get rejected. Apple has a tendency to enforce these HIG guidelines rather strictly lately. They (as you found out already) cause a rather nasty runtime error when you attempt to add them to a NavigationController.
I've solved this for myself... actually worked around... by presenting all other possible full screen views as modals of the SplitView...
This is an unsavory way of doing things in my book, but Apple leaves you little choice if you want to leverage a SplitView only "sometimes" within an app.
I had some success by creating a second UIWindow. I associate the UISplitViewController with that, and switch it out with the main window when I want to show the splitview. It seems to work they way I wanted, except for a slight delay in rotations and a log message about "wait_fences".
Unless your developing for jail-broken devices then bending apples rules/wishes isn't a good idea. Like Jann and Jasconius state above this means keeping a splitView controller view root, not over-using modals (vague) and not using multiple windows.
Also, the Gilt app is only available in the US
I'v been trying to find a solution too and have ended up programatically removing views from the window like Tuannd talks about but the landscape rendering bug is unforgivable.
#Jasconius, What is the max number of modals are you are presenting at any time?
I am struggling with this same issue. I've been trying various things poking at the UISplitViewController as a black box and see how it reacts.
I seem to have come up with a solution to my case which seems to be working satisfactorily.
The key appears to be that the first view added to the UIWindow is the only view properly initialized. All the problems I've had tend to stem from incorrect notification of the orientation of the device. The first view added, apparently has this correctly configured.
In my case I didn't want the UISplitView as the first view. The following is working for me.
The app delegate application:didFinishLaunching method is special. Adding the view to the UIWindow must occur here. If it is done elsewhere it does not get configured properly.
Essentially the magic sauce, is have the split view be the first view added to the window. Its then ok to remove it as long as you retain the UISplitViewController. From then on you can swap other views in and out, including the UISplitView and most things seem to be ok.
I've still run into a few issues. Popovers on views other than the split view are confused on the views frames and location of toolbar buttons and will display in the wrong location. I place then in a specific location and that seems to handle that case.
If a popover on the split view is still displayed, and you try to view another view, the orientation of the second view is confused and shows up sideways. If that view is accessed before the popup is displayed, all is well. I've fixed this my manually dismissing the popover before switching to any other view.
Here's the code if it helps. All the controllers are instance variables of appDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// This also seems to work as good magic. Seems to set orientation and size properties that persist.
[window addSubview:splitViewController.view];
[splitViewController.view removeFromSuperview];
[self switchToNewViewController:firstController];
[window makeKeyAndVisible];
return TRUE;
}
- (void)switchToNewViewController:(UIViewController *)newViewController {
[popoverController dismissPopoverAnimated:FALSE];
if (newViewController != currentViewController) {
[currentViewController removeFromSuperview];
currentViewController = newViewController;
[window addSubView:newViewController.view];
}
}
Just wanted to say that I was running into these same issues, found this forum topic, and followed the advice from g051051 above. This is working perfectly for me. I am not seeing any glitch, and no messages about wait_fences in the console of the device.
I simply used IB to create two UIWindow objects in the main XIB, created as normal the UISplitViewController and then also an instance of my other controller derived from UIViewController (which I am using for full screen display). I have simply hooked them up by attaching the rootViewController for each UIWindow to its appropriate controller.
In application:didLaunch...: method I can decide which window to send the makeKeyAndVisible method and which to set to hidden. When the user want to switch back and forth I simply have to send makeKeyAndVisible to one and set the hidden property on the other, that's all there is to it.
As indicated all of the rotation related messages are sent to each controller appropriately, regardless of which one is associated with the currently visible window.
Anyway, works great for me, and actually quite easy to set up.