I am at a loss with what is potentially a simple fix.
I have a basic ViewController with a UINavigationController, and a UISearchBar embedded.
Basic view layout
When I PUSH a new UIViewController onto the Nav - I get a brief animation issue where a black background appears, and also the cancel button doesn't disappear.
Animation glitch
It's only brief, but annoying enough.
When I return back using the back button, the search bar reverts to white, and then switches to red.
Back display issue
I wondered if I had configured something wrong, so I created a fresh project and left everything with the defaults. Yet I get the same issue.
Stripped back and the same issue
I'm using xCode 9.3 - with swift 4.1
Any ideas?
Check the extendedLayout settings of your view controllers (these can be set in code or in the storyboard editor). They need to be the same for both view controllers or you'll get this animation glitch.
In your case the problem might be the embedded search bar. It seems to be present only for one of the view controllers. You've got navigation bars with two different heights because of that. The framework doesn't respond well to that...
Something going wrong badly due to Message Compose Screen.
I am working on a TabBar based application. In some screens I am showing ToolBar instead of tabBar by setting hidesBottomBarWhenPushed = YES; and its working fine everytime. But In 1 screen I am sending SMS by opening Message Compose Screen within the iphone App. So problem occurs if I open Message Compose Screen and i clicked Cancel button of Message Screen.
So, whenever going back to that module where I was showing ToolBar. So on click of button no ToolBar. Totally blank, no toolbar and no tabbar (tabbar is quite obvious i have already set hidesBottomBarWhenPushed).. But why toolbar now showing due to Compose screen ?
There is no link with compose screen to this screen. Far different implementation and different controllers.
I have check by debugging, Toolbar frame is also fine.
Please help
Issue fixed... had problem with adding it to keyframe window
I think it is because the MFMessageComposeViewController has got a navigation bar. Your application should be a navigation based application for that. Otherwise your toolbar's frame position will be affected. I had this kind of problem once. So i changed the application into navigation based but hid the navigation controller.
Hope this might help you,
Happy coding!
Anyone know why would I sometimes lose Navigation items when clicking to return to previous screen in UINavigationController app?
Background:
have a iPhone app using a UINavigationController and UITableViews
98% of the time things are fine, and if I'm on the detailed screen and click the "back" button things are find. The app takes you back to the main screen (pop's a view off the stack)
a small percentage of the time, and on the iPhone device itself, I click to go back, see some animation start, but I end up (a) on the same page, and (b) no navigation buttons or toolbar buttons appearing
from this state you can't do anything obviously and have to kill the app and re-start
Any ideas? How to fault find? (noting it's only occasionally when testing on an actual device I notice, and it may take hours/days before it does occur)
thanks
Add an alert in didReceiveMemoryWarning function of the viewController. The OS calls viewDidUnload on some memory warning (which don't usually happen in simulator).
I'm working on an iPhone app that has a UITabBar. Occasionally the tab bar ignores my "clicks" (or "taps", or whatever they're called in the iPhone world). It happens on both the simulator and the on the device. Clicking on a tab bar button won't result in any action, and I have to click it several times for the expected action to occur.
Can anybody shed any light on what might be causing this issue, or how I can go about debugging it?
I read somewhere that the UITabBar becomes unresponsive when it is not the immediate child of the window. It can be something like that or you might have a UIScrollView or some other view interfering with your UITabBar.
P.S
Click is correct for buttons, including tabs. For others, a widely used term is touch.
This might be happening bcoz the view is not getting loaded when you click on the tab.
Are you using any url request in the -(void)viewDidLoad method. If this is the case may be ur internet is workin slowly.
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.