Show HN: iOS Table View that automatically adjusts with keyboard show/hide
github.com
github.com
Instead of adjusting the frame of the Table View simply work with the contentInset property. This is how UITableViewController does its job.
Short Code Review if you don't mind: (I only want to help - not to be a jerk)
Line 35: Please remove your -init override. You are doing nothing there and if you want to have custom initialization use initWithCoder: and initWithFrame: instead of init
Line 61: id (star)appDelegate = [[UIApplication sharedApplication] delegate];
Please remove the "(star)"
Line 64: CGRect windowRect = appDelegate.window.bounds;
You are trying to get the window bounds. Why are you not using: CGRect windowRect = self.window.bounds;
Line 73: viewRectAbsolute = FixOriginRotation(viewRectAbsolute, orientation, windowRect.size.width, windowRect.size.height);
Are you aware of: CGRectGetHeight(…) and CGRectGetWidth(…)? I am not saying you should use these functions instead but you could consider using them. I like them very much:
viewRectAbsolute = FixOriginRotation(viewRectAbsolute, orientation, CGRectGetWidth(windowRect), CGRectGetHeight(windowRect));
Line 79: int remainder = (viewRectAbsolute.origin.y + viewRectAbsolute.size.height + keyboardFrame.size.height) - windowRect.size.height;
Again: Consider the functions mentioned above. More importantly replace "int" with "NSInteger" - or even better with CGFloat.
Line 80: if (remainder > 0 && !(remainder > frame.size.height + 50)) {
When using CGFloat you want to make sure to use 0.0 and 50.0.
Line 82: float duration = [[userInfo objectForKey:UIKeyboardAnimationDurationUserInfoKey] doubleValue];
Why are you assigning the result of -doubleValue to a float?
Actually, on iOS, CGFloat is 32 bits, so you should use '0.0f' and '50.0f'.
On the Mac, in, 64-bit, it's a 64-bit value, so your advice would be correct there.
It is slightly annoying there's no easy way to write a CGFloat literal in a cross-platform way apart from the overly verbose '((CGFloat)50.0)'.
Convert the keyboard frame to the superview's coordinate system using `-convertRect:fromView:`, e.g. :
keyboardFrame = [tableView.superview convertRect:keyboardFrame
fromView:tableView.window];
The bottom inset is then simply the difference between the TableView's height and the keyboard's Y coordinate.You would also set those properties and scroll to the selected row in the same animation block.
Would that method have any significant advantages? Less code? Would it avoid all the crazy frame calculations depending on the rotation?
Cool. I'll give that a whirl. Those rotation bits were a biatch. Thanks for the pointers.
Also it would be quite a bit of overkill and extra communication and code to back every table with a full blown view controller.
The reasoning here was that search results aren't going to come up that often, so we wanted the results out of the way most of the time to make a cleaner interface.