I've been using TPKeyboardAvoidingTableView for a long time, and ever since I upgraded the Podfile to version 1.2.5 or to 1.2.6 it stopped working - the keyboard is hiding the lower part of my table.

When I downgraded the pod to version 1.2.4 it worked again, so for now I'm sticking with 1.2.4.

If you deallocate the parent view of any of the TPKeyboardAvoiding*View objects while it's scrolling, you will get a EXC_BAD_ACCESS crash. This is caused by the following code (which is copy-pasted to all the three implementations):

-(void)layoutSubviews 
// --snip--
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(TPKeyboardAvoiding_assignTextDelegateForViewsBeneathView:) object:self];
[self performSelector:@selector(TPKeyboardAvoiding_assignTextDelegateForViewsBeneathView:) withObject:self afterDelay:0.1];

performSelect increases the retain count of self in this case and since scrolling a view causes layoutSubviews to be called it gets queued to the run loop. The problem is apparent when you deallocate the parent view during this 0.1s time slot.

reverting to 1.2.1 solves the problem. I really don't know enough about the project to provide more details other than I tested this with a simple UIView containing a UIScrollView (set to TPKeyboardAvoidingScrollView) and a single UITextField at the bottom of the screen.

Did not set the delegate, so it's running off of the notifications.

Update: setting the delegate didn't help either.

Hi,

I ran into an issue that after the keyboard were closed, the whole view were shifted upwards aprox 85px (in my particular case...).

In closer inspection of the code, the TPKeyboardAvoiding_idealOffsetForView method would modify the contentOffset and it would never return to the previous (0,0) value after closing the keyboard.

I solved it in the code by adding a priorContentOffset property in the TPKeyboardAvoidingState class, and setting and resetting it in sync with the other "prior properties".

Being a total novice using git and not being sure that this IS a good solution in all cases, I've not committed this change. But I'd like someone with more knowledge to perhaps take a look at why this weren't done in the first place?

Great work on this!

Just one issue I've found. The Readme states:

"It also automatically hooks up 'Next' buttons on the keyboard to switch through the text fields."

I added this to a UIScrollView that has fields in it, and I haven't been able to get this part to work. The scrollView adjustments with the keyboard work fine, but hitting Next on the fields doesn't do anything.

Thanks!

This algorithm will to more accurately select the next text field. This works with all cases. Preferring the next text field that is to the right, then below the priorTextField.

This fixes cases such as this:

---------111111- ---------22222-- --333333333--

Previously, text field 3 would be chosen as the next text field in this case. This new algorithm selects text field 2.

After i've changed the textfield Height which added in TPKeyboardAvoidingScrollView, when the cursor ends editing, the text animates to the top and become awkward.please help me. Thanks. I applied to the demo project also, it becomes the same way.

On iOS 9.1 there is a bug with TPKeyboardAvoiding framework. Steps to reproduce:

1. Open screen with any keyboard avoiding view, for example TPKeyboardAvoidingScrollView and two UITextField. Here is test project https://github.com/anton-plebanovich/TP-framework-iOS-9.1-bug
2. Only working with empty field. Must be at least two fields on screen to reproduce. Press and type something in empty field.
3. Press on other field and text in first field will animate from top-left corner to his position. Can be reproduced only once. Reenter screen to test again. Bug description: TPKeyboardAvoiding is animating constraints changes with [self layoutIfNeeded] command in UIScrollView+TPKeyboardAvoidingAdditions.m in TPKeyboardAvoiding_keyboardWillShow: and TPKeyboardAvoiding_keyboardWillHide: methods. This also animate UITextField inner changes for written steps. Possible hotfixes: For me removing [self layoutIfNeeded]; or replacing it with [self layoutSubviews]; was a solution.

I disabled a few fields and I can not go to the next field by pressing return button. I solved the problem by editing the method : - (void)TPKeyboardAvoiding_findTextFieldAfterTextField:(UIView*)priorTextField beneathView:

I add this code : UITextField * textField = (UITextField *)childView; if (!textField.enabled) continue;

after this line : if ( childView.hidden ) continue;

Is it possible to add it to your repository , or have another solution to this problems ?

Updated to latest version

pod 'TPKeyboardAvoiding'

Usage Details

• Language: Swift
• Platform: iPhone
• iOS Version: iOS 9 - 14

Expected Behavior

Xcode 12 build without warnings, proposal to move target to iOS 9

Actual Behavior

Xcode 12.x warning The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.0.99.

Steps to Reproduce the Problem

1. Use latest Xcode 12 or 12.0.1
2. Use TPKeyboardAvoiding in a Swift project with target iOS 11

When the keyboard frame changes, TPKeyboardAvoiding attempts to center the first responder view in the visible space above the keyboard. This results in a jarring change in scroll position (see the "before" video below) in certain circumstances (for example: an auto-growing text view). I believe that a better approach is to, instead of centering the first responder view, center the cursor (when possible).

This is slightly challenging because the cursor is not accurate for a UITextView first enters its editing state. Accordingly, you'll see in my change that I've delayed the initial contentOffset adjustment due to a changing keyboard frame until a future runloop. I'm not entirely happy with this approach because of the natural hand-wavy nature of delaying to future run-loops. In addition, I found that a simple dispatch_async() was not sufficient to ensure that the UITextView's actual cursor position is measured, so I was forced to resort to a dispatch_after(0.01 seconds), which is an even-less precise method of targeting a future run-loop in which the text view's cursor will be set. I'm hopeful the there exists a better method to deterministically target the correct run-loop that I haven't yet tried.

For reference, I've added a tab to the example project to demonstrate a non-scrolling UITextView whose height is much larger than the

Before my change: http://cl.ly/2Y3l0S3X001A/tall_text_view_demonstration_before.mov

After my change: http://cl.ly/0p343Y2E0R2k/tall_text_view_demonstration_after.mov

Warnings:

• I've only tested this on iOS 9.
• My testing, though thorough for my own limited use cases of the TPKeyboardAvoiding library, is by no means globally thorough.
• This hasn't yet been used in production code.
• I couldn't find a great way to integrate this into the sample project without creating another tab. And when I did so, I didn't have an icon for the tab that matched the existing icon set. Sorry!

I am getting crash issue on the layoutSubviews method of class TPKeyboardAvoidingCollectionView. The app getting crash on iOS 14.* devices only. In other iOS version, this is working fine. Exactly here I can see the crash point from Crashlytics.

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(TPKeyboardAvoiding_assignTextDelegateForViewsBeneathView:) object:self];

This can be observed using the provided sample application and making the following changes to TPKAScrollViewController

• Modify the returnKeyType and set the delegate for each UITextField

textField.returnKeyType = UIReturnKeyDone;
textField.delegate = self;

• Implement -(BOOL)textFieldShouldReturn:(UITextField *)textField to dismiss keyboard

-(BOOL)textFieldShouldReturn:(UITextField *)textField {
    [textField resignFirstResponder];
    return true;
}

Type in any field and click the Done button. The _UITextContentView frame jumps to the left briefly before returning to its original position.

This was introduced in build 1.2.4 by adding [self layoutIfNeeded] to -TPKeyboardAvoiding_keyboardWillShow: in commit f533c6c. I see that the issue this was intended to address was "Scrollview stuttering problem on content inset/offset change fixed." Removing this code fixes the text jumping when resigning first responder status, but what are the ramifications?

The IPHONEOS_DEPLOYMENT_TARGET was raised to iOS 12 in latest version 1.3.5 https://github.com/michaeltyson/TPKeyboardAvoiding/commit/ef7a25b3002f94667eedcf804dcc994109caf126 and anyone supporting pre iOS 12 cannot build the framework since Carthage only builds architectures available for the configured deployment target and above. Can this be lowered back to at least iOS 10? I saw it was iOS 8 before. In my opinion this should be in sync with the podspec platform which is iOS 9 currently (s.platform = :ios, '9.0'). In case it matters I am supporting iOS 10 and cannot build arhitectures for it like armv7.

I added TPKeyboardAvoidingTableView to my UITableView but when I click on my textfield it not scrolling. Please help me with this!

https://user-images.githubusercontent.com/26963737/106014970-05bcc780-60e4-11eb-9456-da69f8a624a8.mov