I am trying to use the UITableView.keyboardDismissMode = UIScrollViewKeyboardDismissMode.Interactive, to be able to drag my keyboard up and down. However I can't find any way to track the keyboard frame to update my tableView frame and messaging view. I am simply trying to replicate the standard iMessage behaviour. Given the name, I would have thought that UIKeyboardWillChangeFrameNotification would have been perfect for tracking the keyboard frame changes, but it only notifies when the gesture ends and the keyboard animates up or down.
I'm not sure if this will work but you could try to track the drag progress via the panGesture property on UIScrollView in your tableView. It wouldn't be a direct tracking of the keyboard frame, but if you know the keyboard's height and the progress/offset of the pan, you might be able to math your way around the problem.
The best approach for interactive dismissal is to use the "UIKeyboardDidShowNotification" and "UIKeyboardWillHideNotification" system notifications. When the selector is called you update the table's bottom inset. NOT the constraints. Updating the inset will give you a beautiful smooth keyboard dismissal experience.
Related
I can get the keyboard's dimension after its displayed from the notification, BUT I would like to position my textFields so that I don't have to scroll them when the keyboard appears. To achieve this I should know the keyboard's dimension BEFORE it's even displayed.
Is this possible on iOS?
You can use a class where this all things are handled by default. Just you have to use scroll view for this.
TPKeyboardAvoidingScrollView
See if it's useful and fulfill your requirement.
Think of a UIScrollView with embedded (subview) UIViews, arranged in a column. In iOS6 and previously, the scroll view could be configured so that when you flick it with your finger, the embedded views do not receive touch events even if the initial touch is on one of the subviews; but if you touch a subview without flicking, the scroll view decides this is not a scroll action and forwards the touch events to the embedded views. This was very convenient behavior if you wanted to be able to drag/drop the embedded UIViews within the UIScrollView.
In iOS 7 the documentation indicates that setting the UIScrollView property delaysContentTouches will cause touch-down events to be delayed until the UIScrollView decides whether it's being scrolled. But in fact, this simply does not appear to work. The subview immediately receives touch events and responds to them if the scrolling touch-down event is on one of the subviews. Thus if the subview is programmed for drag/drop it starts dragging while the scroll view also scrolls.
It appears that the model for this behavior has been changed, since iOS 5/6 both did suppress touch events while deciding whether this is a scroll action. Some new methods are now available to cancel the touch-down events after the UIScrollView decides it is scrolling. But obviously this is not useful if the drag/drop code has also started moving the subview.
My question: Is there any way to prevent iOS 7 UIScrollViews from invoking low-level touch-down events on its subviews, when you initiate a scrolling action by stroking a subview?
When I say "low-level", I mean actual touch events as opposed to using gesture recognizers. I am convinced that simply setting the delaysContentTouches property to YES does not work.
This problem has totally busted some quite complex code that worked smoothly and beautifully in iOS 5 and 6; and, so far I have discovered no way to tell the UIScrollView to suppress events to its subviews until it determines whether or not it is being scrolled. The events go through, then a cancellation touch event is triggered later, after the scroll view determines it is scrolling. It looks like the underlying model has been redefined for the worse, or this is a bug. Any insights will be greatly appreciated.
Are you sure it was working on iOS5/6? Based on my experience and posts like UIScrollview delaysContentTouches issue it doesn't work.
Maybe a sample code which shows it working on iOS5/6 but not on iOS7 will help to answer your question.
This works for me:
[scrollView setCanCancelContentTouches:YES];
[scrollView setDelaysContentTouches:YES];
When a control becomes the First Responder, normally the keyboard slides in from the bottom. How can I change that behavior and make it slide in from the left or the right instead? It makes much more sense for the particular UI that I'm working on.
Thanks
You could try to move the keyboard frame intercepting the UIKeyboardWillShowNotification event.
For retrieving the keyboard frame refer to this answer or this other one.
You could create your own view which functions as a keyboard.
I made a custom keyboard view and linked it to the inputView property of a UITextField.
Is there a way to change the height of a custom inputView when orientation changes and have the frame change animated smoothly just like the system keyboard?
My keyboard size is 768x272 and when the device goes landscape the size becomes 1024x272, but I want to make it bigger like 1024x372. If I change the frame with the code below when I get UIDeviceOrientationDidChangeNotification, the change animation is not smooth.
textField.inputView.frame = CGRectMake(0,0,1024,372);
Per Apple documentation for UIResponder.inputView:
"If UIKit encounters an input view with a UIViewAutoresizingFlexibleHeight value in its autoresizing mask, it changes the height to match the keyboard."
So if you want customized height, you shouldn't specify UIVieAutoresizingFlexibleHeight mask.
After many experiments, I found the best answer to my own question. A short answer is change frame when you get UIKeyboardDidHideNotification.
Custom inputView is embedded in another view controlled by the system called UIPeripheralHostView.
So changing the custom inputView at wrong time is not reflected immediately or shows an ugly layout at best.
When the device rotates, the system briefly hides the keyboard, then performs a rotation animation of the keyboard from old orientation to new orientation. I think the animation block is inserted somewhere between two notifications UIKeyboardDidHideNotification and UIKeyboardWillShowNotification. These notifications are coupled with UIKeyboardWillChangeFrameNotification. The "frame" in this notification actually means the frame of UIPeripheralHostView.
So changing the frame of my input view when I get UIKeyboardDidHideNotification gives the system a chance to adjust the frame of UIPeripheralHostView before the animation starts, resulting in smooth transition from short keyboard to tall keyboard during orientation change.
This works in iOS 5. But Apple may change the practice in the future.
I have noticed a slight delay on the highlighted state of a UIButton when touched down if it is inside a UIScrollView (or a table view). Otherwise, the highlighted state is pretty much instantaneous.
I surmise this must be by-design to provide a chance for user to scroll. But it just seems like the button is unresponsive to me. Is there a way to fix this?
Indeed, it's a design choice. It needs this small time to differentiate a scroll (panGesture) from a tap. If you eliminate this delay, then the user won't be able to scroll if he places the finger on top of the button, which is not good user experience.
Because a scroll view has no scroll bars, it must know whether a touch signals an intent to scroll versus an intent to track a subview in the content. To make this determination, it temporarily intercepts a touch-down event by starting a timer and, before the timer fires, seeing if the touching finger makes any movement. If the timer fires without a significant change in position, the scroll view sends tracking events to the touched subview of the content view.
from the UIScrollView Documentation
I wouldn't recommend disabling the delay, but if you insist, you can set it in interface builder (select the Scroll View, and on the right panel, right under "Bounces Zoom"), or using this code:
scrollView.delaysContentTouches = false