My app works as supposed on an iPhone running iOS 4.1 but not on iOS 4.2. I have an UIInputField set to first responder but the keyboard does not show up. The becomeFirstResponder is called in the viewDidLoad method. Is it a bug or has Apple made drastic changes? I'm using Xcode 3.2.5.
Does the input field have User Interaction Enabled? This is now required in iOS 4.2.
-viewDidLoad is called when your view is first initialized, not necessarily when it's displayed. Try calling -becomeFirstResponder inside -viewDidAppear: instead:
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[myField becomeFirstResponder];
}
Found a thread at the Apple Developer Forums (https://devforums.apple.com/message/325348#325348) where a solution was described. Set the UITextField property userInteractionEnabled to YES before a call to becomeFirstResponder is made, preferably in the viewDidLoad method.
Related
I am using the following control in a viewcontroller i want to show the keyboard when user opened the view so I tried to call this method from the viewcontroller
[self.inputToolbar.textView becomeFirstResponder];
But the keyboard does not show when opened the view. So i called the becomefirstresponder in the place where the textview is allocated you can see the allocation page here i called like this
[internalTextView becomeFirstResponder];
Now it works in iOS6 but in iOS7 it does not works
By using sample code
I write below code inUIInputToolbarViewController.m > loadView
[self.inputToolbar.textView.internalTextView becomeFirstResponder];
And it's working fine.
Code
In my application, I have sign in page but sometimes in textfield unable to type.
It happens rarely; I am creating textfield programmatically and already set property for userUnteractionEnabled.
I am not sure whether the issue in iOS 5 or xcode 4.2, i have faced same issue, if we use resignFirstResponder and becomeFirstResponder in same loop some time we would face this kind of issue, to fix this you may follow below code. this may help you
becomeFirstResponder
[textfield performSelector:#selector(becomeFirstResponder) withObject:nil afterDelay:0.0];
In one of my apps, when I try to edit (type some text) UITextField, UITextView or any other 'text-able' UIControl the cursor just blinks but no characters are typed in except BACKSPACE (possible only when I have some initial text in it), RETURN and switching character types. This goes to all controls across whole application.
Summary:
It happens only from iOS 6.0 (does not occur on iOS 5.x, 4.x neither Simulator or real device)
All delegate methods are fired (shouldBeginEditing: didBeginEditing:) except shouldChangeCharactersInRange:
isFirstResponder flag is behaving set correctly (shouldBeginEditing: logs NO, while didBeginEditing: logs YES correctly). It is also tested using logs that THE firstResponder IS the one already edited.
It repairs itself after any UIAlertView is presented to the user and dismissed. It doesn't matter if this alert is shown on the same screen (UIViewController view) or any other.
I have no idea how to even approach or debug this.
Where should I look for hints? Any experts of tracking responder chain related issues etc.?
How can I track down the UIAlertView's effect on the issue?
Depending on your implementation it's either the makeKeyAndVisible method of the UIWindow class that you forgot to call inside the - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions method of the application delegate or corresponding Visible at Launch flag in your main interface xib file.
Cheers... :)
in my case, there is a 'visible at launch' on the main window, it was unchecked, which works on iOS5 only, needs to check it to make it working on iOS6.
In my situation I had an activity indicator that would pop up over the main window during periods of background activity. In this case the activity indicator view had its own window that was set to UIWindowLevelAlert. I was inadvertently calling makeKeyAndVisible on this window. Later on I would call resignKeyWindow. This used to work on iOS 4 and 5 but no longer worked in iOS 6. I discovered that this was not technically necessary as simply using window.hidden = Y/N worked just as well.
In my case I moved becomeFirstResponder for my UITextField from ViewDidLoad to ViewDidAppear and this solved my problem.
while coding in iOS 4.3 before, I found while add a view controller's view to another view with [superview addSubView:controller.view], the controller instance will not receive the -viewWillAppear/viewDidAppear message, than I found same issue in some thread in stack overflow. After that, I manually call -viewWillAppear/-viewDidAppear as needed.
but, after upgrade to iOS 5.0, some frisky UIView behavior happened. Finally I found that in iOS 5, the [superview addSubView:controller.view] , will send a -viewWillAppear/-viewDidAppear message to the controller instance automatically, plus my manually calls, there are two duplicated message each time the controller action its behavior.
and I also found a similar issue: iOS 5 : -viewWillAppear is not called after dismissing the modal in iPad
Now, the problem is, after search apple's documents, I didn't find any explicitly doc for diff about these issues. I even wonder if this is a guaranteed view life cycle behavior in iOS 5.0 .
Does anyone fix similar issues or find some guidelines about these difference. cause I want to run my app both in 4.x & 5.x iOS.
In iOS 4 you had to manually call -viewWillAppear, -viewWillDisappear, etc. when adding or removing a view from your view hierarchy. These are called automatically in iOS 5 if the view is being added or removed from the window hierarchy. Fortunately, iOS 5 has a method in UIViewController that you can override to revert the behaviour back to how it worked with iOS 4. Just add this to your UIViewController:
-(BOOL)automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers {
return NO;
}
This is probably the easiest solution as long as you're supporting both iOS 4 and iOS 5. Once you drop support for iOS 4 you might consider modifying your code to use the newer approach when swapping views.
Edit 5 February 2012
Apparently this function requires the child view controller be added to the main view controller using the addChildViewController: method. This method doesn't exist in iOS4, so you need to do something like this:
if ([self respondsToSelector:#selector(addChildViewController:)] ) {
[self addChildViewController:childViewController];
}
Thanks to everyone who corrected me on this.
This may not be an answer what you want, but I had same kind of problem.
In my case, when I added a view controller's view to another view controller's view as a subview, the subview was received viewWillAppear only in iOS 5.0 not iOS 4.X.
So I added a nasty condition.
[self.view addSubview:self.viewController.view];
if ([[[UIDevice currentDevice] systemVersion] compare:#"5.0"] == NSOrderedAscending) {
[self.viewController viewWillAppear:animated];
}
From iOS 5.0, Apple provides a way to implement custom container view controllers like UINavigationController or UITabController. I think this change affects when viewWillAppear is called.
This problem may be solvable if we use -[UIViewController addChildViewController:].
The answers above a slightly incomplete.
Let's presume you have 2 view controllers, ControllerA, and ControllerB.
ControllerA.view is already added to the window(it is the parent), and you want to add ControllerB.view as a subview of ControllerA.
If you do not add ControllerB as a child of ControllerA first, the automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers will be ignored, and you will still be called by iOS5, meaning that you'll call your view controller callbacks twice.
Example in ControllerA:
- (BOOL)automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers {
return NO;
}
- (void)viewDidLoad
{
[super viewDidLoad];
self.controllerB = [[ControllerB alloc] initWithNibName:#"ControllerB" bundle:nil];
[self.view addSubview:self.controllerB.view];
}
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
[self.controllerB viewWillAppear:animated];
}
In ControllerB NSLogging in viewWillAppear:
- (void)viewWillAppear:(BOOL)animated
{
NSLog("#ControllerB will appear");
}
This will result in iOS5 only displaying that NSLog message twice. i.e. You're automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers has been ignored.
In order to fix this, you need to add controllerB as a child of controller a.
Back in ControllerA's class:
- (void)viewDidLoad
{
[super viewDidLoad];
self.controllerB = [[ControllerB alloc] initWithNibName:#"ControllerB" bundle:nil];
if ([self respondsToSelector:#selector(addChildViewController:)])
[self addChildViewController:self.controllerB];
[self.view addSubview:self.controllerB.view];
}
This will now work as expected in both iOS4 and iOS5 without resorting to the horrible hack of checking iOS version strings, but instead checking on if the function we're after is available.
Hope this helps.
It is iOS5 behavior:
viewWillAppear, viewDidAppear, ... are executed automatically after addSubView: for iOS5.
So for iOS5 no need to execute manually those methods as need for iOS<5.0.
The fix may be:
if ([[UIDevice currentDevice].systemVersion doubleValue] < 5.0) {
...execute viewWillAppear or other
}
By this method u know which os u use and put condition if is less then 5.0 or other one
[[UIDevice currentDevice] systemVersion]
view{Will,Did}Appear, view{Will,Did}Disappear are functions on View Controllers and not views. These functions are called by SDK provided view controllers that are supposed to manage other view controllers e.g. UITabBarController, UINavigationBarController.
If you are managing sub-view controllers yourself, you have to call these explicitly (and in proper order - though you should have a very good reason to do this). A modal view not getting these calls upon dismissal of a modal view is simply because there is no one there to call it. Encapsulate the root view controller in a UINavigationController (and hide the navigation bar if you like) and then open a modal view controller. Upon its dismissal, or pop, viewWillAppear will get called.
After reviewing all the evidence, I think the best thing to do is NOT use viewDidAppear etc for views that are affected by this ios 4 / ios 5 bug. Instead make a custom class (like viewDidAppearCustom) and call it yourself. this way you can guarantee that apple won't change the sdk again and mess you up. There is a great blog covering this issue here:
http://gamesfromwithin.com/view-controller-notification-changes-on-ios5
For the past few extremely frustrating days of my life, I've been trying to figure out what's wrong with me code. In a certain page, if I put UITextViews or UITextFields or a MFMailComposer or a MessageComposer or anything with fields that require editing, the fields just wouldn't respond to touches. I couldn't edit anything when I ran the app. I couldn't edit text views or email fields or anything. I tried everything, but nothing worked. It turns out that on the main page (MainVC) that leads to the page where fields don't respond (GiftVC), in the viewDidAppear method (in the MainVC), I say: [self becomeFirstResponder];.
Now I'm not really sure why I put that there, but it turns out that commenting that line out fixes everything and makes all the fields and textviews and email composers and everything work just fine again.
I also have this in the MainVC page:
-(BOOL)canBecomeFirstResponder {
return YES;
}
and commenting that out fixes the problem as well.
The weird part is that even with the [self becomeFirstResponder] line, everything worked just fine in the new iOS 5 (simulator and device), but in iOS 4 (simulator and device), it wouldn't work at all with that line. Now that I've removed it, it works fine in both cases.
If you have the following in your UIViewController subclass
- (BOOL)canBecomeFirstResponder
{
return YES;
}
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
if (self.view.window) {
[self becomeFirstResponder];
}
}
then you probably intended to allow that subclass to handle motion events (shaking) or something similar. So that's probably why it's there.
If you weren't able to edit UITextFields then this subclass was probably becoming the first responder and not forwarding the event to the actual UITextField. When a UIViewController subclass calls overrides canBecomeFirstResponder to return YES and makes them self the first responder (ie [self becomeFirstResponder], if you want don't want that custom class to handle the touch events for the UITextField, then you should override the nextResponder method.
An example from my own product -- Essentially I have a UIViewController subclass that does two things: 1) it handles shake events and 2) it displays another view modally when some button is tapped. On the modal view there are some UITextFields. To allow my UIViewController subclass to forward the touch events to my modal view, I added the following:
- (UIResponder *)nextResponder
{
if (!self.view.window) {
// If the modal view is being displayed, forward events to it.
return self.modalViewController;
} else {
// Allow the superclass to handle event.
return [super nextResponder];
}
}
This will work on iOS 4 and 5, with either sdk.
Now, in your case you obviously didn't remember adding the code to become first responder in the first place, so you don't need the above hooks. However, it's good to know for the future.
Back to your actual question -- once you updated your SDK to 5, why wouldn't things work on iOS 4, but they would work on iOS 5? iOS 5 is doing some of the event forwarding for you which is why it works there. It should have never worked on iOS 4 in the beginning. Apple fixed some bugs that allowed it to work on 4, which is why it no longer works on 4.
I know the question had already accepted an accepted answer; I just wanted to clear up any confusion out there.
Check if MainVC has a method called canResignFirstResponder that returns NO (at least sometimes). If so, then once it becomes first responder, it won't let anything else become first responder, until it returns YES from that method. (All the UITextViews, etc. have to become first responder to be edited.)
Actually just look everywhere in all your code for canResignFirstResponder, in case it's in a superclass or something.
Otherwise the only thing that would stop the text fields and views from being editable would probably be if they got set userInteractionEnabled = NO, but since it hinges on the becomeFirstResponder statement, it is more likely to do with canResignFirstResponder.
In iOS 4, a subclass must override canBecomeFirstResponder in order to be able to become first responder. Maybe this is different for iOS 5 or it's a bug.
Try this,
Make sure you have added the uiTextViewDelegate and
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView{
NSLog(#"textViewShouldBeginEditing:");
return YES;
}