I have created a simple UIViewController, and set a UIWebView as a default view.
When I inserted it into a NavigationController, it did not show input method anymore if I click in some text field in page.
Any ideas?
input method = soft keypad,
ps: i set the simple UIViewController as rootViewController of MainWindow, also take no effect. can not show soft keypad too.
I just encountered this. For me, the keyboard is apparently sitting behind my web view. I happened to rotate the device (in the simulator) and noticed, during the screen rotation drawing process, that I could see parts of the keyboard behind my webview. [Quoted] [1]
Interestingly, I can't seem to reproduce this problem in a freshly created sample application - yet I can't see what the problem can be with my view hierarchy. [Quoted] [2]
[1][2]: Reference
Is your web view in a modal view controller?
Pls check if the userInteraction is enabled for the web view. If not you can set it by
yourWebview.userInteractionEnabled = YES;
Related
I'm aware some of you may not be familiar with Monotouch, but this could certainly be a general iOS issue rather than a specific Monotouch issue.
I'm recreating an app with similar functionality to the default mail app:
This is a simple recreation of our app. It's a UIView which contains a UITableView and a UIToolbar. It's loaded from a XIB file (which contains accompanying view controller code). This view is a UITabController view (though I'm sure this shouldnt affect things?).
This has been pushed from a navigation Controller using
controller.PushViewController(inboxItem.Controller, true);
(where inboxItem is a custom object I've made, the Controller property being the inboxItem's view controller).
Pressing the right hand button on the toolbar presents a new modal view (compose new message) - which does its thing and no matter which way its dismissed, upon dismissal, the UIToolbar disappears. However, if I am to click on another tab then click back onto this tab, the Toolbar reappears. Is this a redraw issue?
Am I doing something wrong with the way I'm structuring my app? Or have I happened to stumble across some bizarre iOS/Monotouch bug? (I'm hoping it's for the former - so I can improve my iOS development).
I solved the problem. Basically, what was happening was when the ModalView was being presented and then dismissed, the toolBar was being moved down by 44 pixels each time.
In my example, the toolBar is placed above a UITabBar, so when the modal view was dismissed the toolbar was being moved out of view. I'm not sure why this is happening but I'll be sure to file appropriate bug reports.
One quick and (very) dirty way around this is to move the toolBar up 44 pixels when displaying the modalview, so that when it is dismissed, it will move it back down to the appropriate position.
I have a very simple screen with an UITextField with the default configuration, nothing special.
When I touch the UITextField, the keyboard doesn't pops up.
I haven't any custom control, behavior or anything else, just that, but it doesnt'work.
I've done this in previous apps iPhone/iPad apps already on the AppStore but i can't figure out what's going wrong here.
The UITextField is created in Interface Builder, in the nib file.
I've been doing some research and i added an IBAction in the UIViewController for UItextField TouchDown event and the IBOutlet for the UITexField.
In the first line of the code i added:
[textFild becomeFirstResponder];
That's the default behavior of the UITextField, when you touch it, it becomes the first responder asking the system to show the keyboard.
I debugged it and it runs that line, but the keyboard still doesn't shows up.
Thanks in advance.
Many times your code is right, it's just about the settings of your Xcode or the Simulator.
Try Toggling Keyboard Software in the Simulator
Simulator --> Hardware --> Keyboard --> Toggle Software Keyboard
OR just simply hit Command + K it would do the same thing
One thing you should check is to make sure the containing view (the UIView that contains all the controls), which is the View icon in Interface Builder nib viewer, has User Interaction Enabled checked. If the parent container doesn't have this checked, even if the individual controls do, you will see this behavior.
I already figured out by myself!
I had tha UITextField in a UIViewController that gets presented from another view controller
who responds to motion events, and that previous View Controller was allways the First Responder.
All I had to do was everytime i leave the controller's view in viewWillDisappear:(BOOL)animated, i called [self resignFirstResponder]; and that was all.
I took me a while to find this silly oversight, but make sure that both properties of UITextView: selectable and editable are set to true.
Its a pretty basic thing but make sure your USER INTERACTION and ENABLED are checked in the storyboard editor.
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.
First of all, my code isn't complex - in fact it's just two sample programs from "Beginning iPhone Development: Exploring the iPhone SDK", combined into one program. I took the ViewSwitcher application, which switches between a blue view and a yellow view, and replaced the YellowViewController with the CameraViewController from the camera application.
I have three ViewControllers total. SwitchViewController just switches between BlueViewController and CameraViewController.
Inside CameraViewController, I'm trying to use a UIImagePickerController to choose an image. The picker is presented with presentModalViewController. The catch is that I want to do this in landscape orientation.
Everything works fine under 2.2.1, and everything works fine in 3.0 in portrait mode.
In 3.0 under landscape orientation, however, things break. If I set SwitchViewController to landscape orientation, my screen goes white when I try to present the picker. If I rotate the iPhone a few times, I can see a corner of the picker, which apparently was displayed off screen.
If I set CameraViewController to landscape orientation, the picker doesn't come up at all.
I think this page may have a clue when it says "The most prominent change [in 3.0] I can see is that the modal view controller will always use the application frame instead of the parent view controller's frame." I don't understand exactly what that means, though.
Any help is greatly appreciated. Thanks!
I believe what that means is this: Modal views always use the full screen, even if the parent view controller that invokes them controls a view that is only part of the screen. This makes sense for standard modal views like the camera picker, but I can see why someone who creates a custom modal view might want it to be smaller.
Not sure if that really helps solve your problem though.
Question -- what happens if you bring up the modal view and THEN rotate the phone?
You must have used addSubview in your parent view controller, try using presentModalViewController:.
My application is pretty simple: it starts up with a view controller that holds a table view (in grouped view layout) with a few options. When the user taps on one of the options, I push another view controller onto my navigation controller.
This second view controller simply displays a UIImageView, and the user can change the screen orientation on this view controller between portrait/landscape modes. This works just fine, and all is happy.
However, if the user taps on the "Back" button on my navigation bar while on the landscape mode, the first controller's layout is all messed up. See below for before/after screenshots:
(source: pessoal.org)
(source: pessoal.org)
Any clues on how to force the first view controller (second screenshot in this post) to stay within the portrait screen orientation?
There does not appear to be a way to do this using the documented methods.
I have filed a bug for this: rdar://6399924
"There is no way to always restrict a UIViewController to one orientation"
You can see it on open radar (along with a link to sample code to reproduce the problem) here: http://openradar.appspot.com/radar?id=697
Like someone on the open radar suggested, a workaround is to disable "back" button while in non-portrait:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation{
// don't let user press "back" button in landscape - otherwise previous view and the rest of the application
// will also be in landscape which we did not feel like testing yet
self.navigationController.navigationBarHidden = (UIInterfaceOrientationPortrait != self.interfaceOrientation);
}
There is a solution to do that : it's to use a view controller and adding its view to the window. then in that controller you force landscape in the shouldAutorotate... methode. It works fine, but be sure it's necessary for your project to use that, because it's not very smart to force the user to turn his iPhone. By the way, here is an example code if you need it.
http://www.geckogeek.fr/iphone-forcer-le-mode-landscape-ou-portrait-en-cours-dexecution.html
I wasn't able to get this to work the way I wanted. You ought to be able to set a particular orientation for a ViewController, but the NavigationController doesn't seem to always do the right thing.
I ennded up re-designing my screens so that they all work in either orientation. That might be extra work, but it "feels" more natural, anyway.