I have a problem, I have a view with 3 text fields, 2 of them are covered by the keyboard when I want to write something.
I found a code that moves the entire view up when the keyboard is shown but I only want to move the two text fields when they are pressed, while the rest of the view stays in place, is it possible?
The code I used - http://www.ioscreator.com/tutorials/move-view-behind-keyboard-ios8-swift
make use of the notification event, then you can make adjustments to your view. The Notification also includes information about the size of the keyboard.
UIKeyboardDidShowNotification
Related
I have a UIScrollView with 2 views, side by side, each of which covers the entire screen.
They are moved to visible bounds on user's action, only one covering the screen at a time. Both of these views have multiple UITextFields. Working with the simulator, I fill in a textField in the first view and when I press the Tab key, the firstResponder is assigned to a textField in the other view. I understand that on using the device, the user will not be able to do that. But what if the user uses a bluetooth keyboard, or similar accessory? I do not want a textField, that is currently not visible to become firstResponder. Can this be done?
EDIT: I just remembered the canBecomeFirstResponder method. But how do I determine which textField is about to becomeFirstResponder?
It sounds like the problem isn't that they shouldn't be able to tab between the two text fields, but instead that they shouldn't be able to edit a text field that isn't visible, and they should be able to tab between them if they are both visible at the same time.
Instead of restricting tab, I would implement the UITextField delegate method -textFieldShouldBeginEditing:, which allows you to return a boolean whether or not that text field should become the first responder.
Something such as:
- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField
{
// Only edit if the text field is visible
return !textField.isHidden;
}
You may need to adjust this code to fit your 'is visible' status of the text field.
I've been searching, but haven't quite found a complete answer, and the Apple docs aren't much help.
I have an application with a UIView that has a lot of text fields on it, ranging from the top of the view to the bottom. When the user clicks the first UITextField the keyboard pops up. The keyboard has three buttons above it, previous, next, and done on a toolbar InputAccessoryView.
Basically, let's say there are 6 UITextField boxes that space from the top of the view to the bottom. When the user gets past the third text field, the keyboard blocks the bottom three. How do I have the view adjust up when putting text in the bottom three text fields?
You need to place your textfields into a UIScrollView, and either translate the view above the keyboard when it is active and away when it is down, or another solution such as always having the keyboard up on that page, which'll save you the setFrame calls on your UIView/UIScrollView depending on what the keyboard is doing.
This will further help:
How to adjust the view position when the keyboard opens in iPhone?
I have a "new message" view controller in my app (just like the system sms app) where there are two textfields, one for receivers and one for the message content. The problem is when I switch between the two textfields, the keyboard may resize (depending on the input method), and I don't get any keyboard notifications. This is rather embarrassing since the keyboard may cover the textfield, which is not what i want. How can I fix this?
thanks in advance.
You can set your controller as the delegate of your text fields and when textFieldShouldBeginEditing: or textFieldDidBeginEditing: is called, perform any necessary manipulations to your view to make sure the textField is visible.
I have a somewhat complex iOS view hierarchy. One piece of text is an editable UITextField. When the user touches it, it becomes first responder, and is editable.
Here's the rub, though: Best practice should be that a touch anywhere outside the edit control causes it to resign first responder and end editing. What's the best way of accomplishing this?
Techniques I've tried:
Use the exclusiveTouch property, which stops the user from interacting with other controls, but doesn't cause editing to end. Also disallows user from interacting with my toolbar "Done" button.
Put a see-through UIView under the text field control and on top of everything else (except the toolbar), and use touches there to end editing. This works, but I end up reparenting the text field onto this other random view which sits above my whole hierarchy, which means I have to take care of the text field's layout in multiple places, since it no longer lives in the place where it lived originally, and I have to delegate all its behavior back and forth from its "shield" view to its native home container, which has all the related logic.
Is there an elegant solution to this problem that I'm missing? I figure it must be a common design issue.
Thanks.
Tile 4 "see-thru" views around the textview to capture/ignore touches. Doesn't require modifying or "lifting" the textview, and can be added to the parent view in a fairly modular way.
You can't mask a region without knowing what that mask will cover and what the mask will not cover. So any solution will require enough reach to gather both of those bounds. Either pass the text rect up, or the view rect/region to be disabled down, or both to something in-between. The controller for the stuff to be covered seems as good a place as any to consolidate both rects or regions, if not the controller for the text view.
The nub of the issue is what constitutes "best practice". The fact that the keyboard remains unless the user dismisses it is deliberate. For example, many apps need the user to be able to tap a button while still working in a text field.
The keyboard has a Return button. "Best practice" is to respond to the user tapping that button by resigning first responder. Otherwise, you should leave the keyboard there, since that's what the user expects.
However, if you insist on doing it your way, there's a simple solution: put a UITapGestureRecognizer on the background view. Its handler will be triggered if the user taps on the background or on any button or similar in the interface. So, presuming you have kept a record of what the first responder is, you can send resignFirstResponder to the first responder in the tap gesture recognizer's handler.
If you change your base view to a UIControl you can add an IBAction to that layer that resigns your text field as first responder.
Also, if you have multiple touch events, make sure they each becomeFirstResponder when touched.
I'd love to have some more details to qualify my explanations xD
I want to add a text box and a button beside it. They will be at the bottom of the window. Then, when I touch the textbox (to type something), keyboard will appear and the whole row (with textbox and button) scrolls up and the keyboard will be right below them. Could you please let me know how can I do that?
Is there any sample program?
Thanks.
Matt Gallagher posted this on his blog:
Sliding UITextFields around to avoid the keyboard
It is a step by step example of exactly what you want.
In the XCode documentation iPhone Application Programming Guide there is a section on "Moving Content That Is Located Under the Keyboard" that talks about receiving keyboard notifications when a keyboard is about to show. There's code there to show you how to get the keyboard size (which varies depending on the orientation). I won't repeat it here.
You can use the same technique to get the UIKeyboardWillShowNotification notification and get the height of where the keyboard will end up. That gives you the bottom edge of where your view needs to go, effectively putting it above the keyboard. So just put your textbox and button inside a view. When you get the notification tell your view where it needs to go (keyboard height + height of the container view) and you're done. You'll also want to catch UIKeyboardWillHideNotification to move the view back to where it was, so keep track of the original container view position.
It's pretty straightforward and it'll look nice, especially if you use a nice UIView animation effect and set the timing just right.