I am developing an iPhone app which has a shopping cart, and I'm using a UITableView to display the cart. There is a cell for each item, and the -tableFooterView is set to a custom view which gives the user a text field to verify their credit card's CVV and a button to complete the checkout process.
When the user taps in the CVV text field, I resize the table view so that the keyboard doesn't cover anything.
- (void)keyboardWillShow:(NSNotification *)n
{
// I'll update this to animate and scroll the view once everything works
self.theTableView.frameHeight = self.view.frameHeight - KEYBOARD_HEIGHT_PORTRAIT_IPHONE;
}
After entering their CVV, the user can tap the Done key to dismiss the keyboard:
- (BOOL)textFieldShouldReturn:(UITextField *)textField {
[textField resignFirstResponder];
return NO;
}
All of that works, however, while the keyboard is visible, my checkout button (a normal UIButton) does not respond to touch events. The table scrolls, but the button's touchUpInside event is never fired.
Once I tap Done and the keyboard is dismissed, the checkout button will recognize touchUpInside events.
From what I've seen, it appears that any button that was covered by the keyboard does not respond to my touches (even it scrolled out from behind the keyboard) until the keyboard is dismissed. Buttons in this same -tableFooterView that are not ever covered by the keyboard remain responsive to touch while the keyboard is visible.
Same behavior when running on iOS 5 and iOS 4.
Can anyone offer any suggestions of what may be going on? Or any helpful ideas for troubleshooting?
Thanks!
Edit - Update
In fact, the portion of the tableFooterView that is covered by the keyboard is not responding to touch events. In my custom UIView subclass, I implemented -touchesBegan:withEvent: and just log that a touch occurred.
Touching anywhere in the view gets a log statement before the keyboard is shown. However, after the tableview is resized, only touching the upper portion of the view generates a log statement.
Also I just realized, the portion of the tableFooterView that was covered by the keyboard turns to the color of the containing view's background color once I scroll that portion to be visible.
I had the same problem. I think it is a bug in iOS, but I've discovered a workaround for it:
- (void)keyboardWillShow:(NSNotification *)note {
NSDictionary* userInfo = [note userInfo];
// get the size of the keyboard
NSValue *boundsValue = [userInfo objectForKey:UIKeyboardFrameBeginUserInfoKey];
CGSize keyboardSize = [boundsValue CGRectValue].size; // screen size
CGFloat keyboardHeight;
if (self.interfaceOrientation == UIInterfaceOrientationPortrait ||
self.interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown) {
keyboardHeight = keyboardSize.height;
} else {
keyboardHeight = keyboardSize.width;
}
// resize the view with the keyboard
__block CGRect origFrame = self.view.frame;
__block CGRect viewFrame = origFrame;
viewFrame.size.height -= keyboardHeight - ((self.tabBarController != nil) ? self.tabBarController.tabBar.frame.size.height : 0);
// Set the height to zero solves the footer view touch events disabled bug
self.view.frame = CGRectMake(origFrame.origin.x, origFrame.origin.y,
viewFrame.size.width, 0);
// We immediately set the height back in the next cycle, before the animation starts
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
self.view.frame = origFrame; // The original height
// start the animation
[UIView animateWithDuration:0.4 animations:^{
[self.view setFrame:viewFrame];
}];
});
}
The trick is to set the height of the tableView to 0 and back to original in the next running cycle.
This works for me either iOS 4.3 and 5.1.
I think that resizing the UITableView causes it to send the UIButton (a subview) to the back of the view hierarchy. You may need to bring it to the front explicitly after resizing the frame.
[self.theTableView bringSubviewToFront:yourUIButton];
Following worked for me.
Had a table view footer with button, for that button action is linked via xib, apart from that added following code more -
#IBOutlet private weak var myButton: CustomUIButton!
override public func awakeFromNib() {
super.awakeFromNib()
let myButtonTapGesture = UITapGestureRecognizer(target: self, action: #selector(myButtonAction(_:)))
myButton.addGestureRecognizer(myButtonTapGesture)
}
#IBAction func myButtonAction(_ sender: AnyObject) {
// button action implementation
}
So I have to add a tap gesture on button.
Related
I have a scrollview with some subviews as tiles. The scrollview has its "Delays content touches" and "Cancellable Content Touches" set to YES.
I capture touches in each subview with touchesBegan, touchesEnded and touchesMoved.
When you tap a button and almost immediatly start to scroll, the button highlights and the scrollview do not scroll, without any code needed.
When I do exactly the same thing without changing anything, touching the view but outside the button, these touch methods are triggered, but the scrollview scrolls.
What may I do in those touch methods to cancel the scrolling when a touch is done outside the button to have the same behaviour that prevent the scrollview to scroll ?
I solved this adding this code in touchesBegan and touchesEnded when touch is catched by the subview.
UIView* superView = self.view.superview;
while (superView != nil) {
if ([superView isKindOfClass:[UIScrollView class]]) {
UIScrollView* superScroll = (UIScrollView*)superView;
superScroll.scrollEnabled = YES/NO; // put the right value depending on the touch method you are in
}
superView = superView.superview;
}
If you want to detect touches inside any of the subviews of the UIScrollView, you will have to subclass UIScrollView and override the touchesShouldBegin and touchesShouldCancelInContentView methods which are specifically created for this purpose.
Other than this, there is no way you can identify touches in the subviews as UIScrollView tends to handle all touches itself and doesn't pass them to its subviews.
Courtesy:-https://stackoverflow.com/a/392562/1865424
If you have any further issue regarding this.Happy to help you.
Depending on what you are trying to do, maybe you can add:
UILongPressGestureRecognizer *longPressDetect = [[UILongPressGestureRecognizer alloc] initWithTarget:self action:#selector(disableScrolling:)];
[subView addGestureRecognizer:longPressDetect];
and then add a method that disable and re-enable the scrollView from scrolling such as:
-(void)disableScrolling:(UILongPressGestureRecognizer*)longPress {
if (gesture.state == UIGestureRecognizerStateBegan) {
scrollView.scrollEnabled = NO;
}
if (gesture.state == UIGestureRecognizerStateEnded) {
scrollView.scrollEnabled = YES;
}
}
I got an gridview. Each cell within that grid is clickable. If a cell is clicked, another viewcontroller must be presented as a modal viewcontroller. The presentedviewcontroller must slide in fro the right to the left. After that, the modalviewcontroller can be dismissed with a slide. How do i achieve this? I got some images to show it :
Both views are separate viewcontrollers.
[Solution]
The answer from Matthew pointed me in the right direction. What i needed was a UIPanGestureRecognizer. Because UISwipeGestureRecognizer only registers one single swipe and i needed the view to follow the users finger. I did the following to accomplish it :
If i cell is tapped inside my UICollectionView, the extra view needs to pop up. So i implemented the following code first :
/* The next piece of code represents the action called when a touch event occours on
one of the UICollectionviewCells.
*/
-(void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
NSString* release_id = releases[indexPath.row][0];
// Next boolean makes sure that only one new view can be seen. In the past, a user can click multiple cells and it allocs multiple instances of ReleaseViewController.
if(releaseViewDismissed) {
// Alloc UIViewController and initWithReleaseID does a request to a server to initialize some data.
ReleaseViewController *releaseViewController = [[ReleaseViewController alloc] initWithReleaseID: release_id];
// Create a new UIView and assign the height and width of the grid
UIView *releaseViewHolder = [[UIView alloc] initWithFrame:CGRectMake(gridSize.width, 0, gridSize.width, gridSize.height)];
// Add the view of the releaseViewController as a subview of the newly created view.
[releaseViewHolder addSubview:releaseViewController.view];
// Then add the UIView with the view of the releaseViewController to the current UIViewController's view.
[self.view addSubview:releaseViewHolder];
// Place the x coordinate of the new view to the same as width of the screen. Then after that get the x to 0 with an animation.
[UIView animateWithDuration:0.3 animations:^{
releaseViewHolder.frame = CGRectMake(0, 0, releaseViewHolder.frame.size.width, releaseViewHolder.frame.size.height);
// This is important. alloc an UIPanGestureRecognizer and set the method that handles those events to handleSwipes.
_panGestureRecognizer = [[UIPanGestureRecognizer alloc] initWithTarget:self action:#selector(handleSwipes:)];
// Add the UIPanGestureRecognizer to the created view.
[releaseViewHolder addGestureRecognizer:_panGestureRecognizer];
releaseViewDismissed = NO;
}];
}
}
Then my handleSwipes is as follows:
-(void)handleSwipes:(UIPanGestureRecognizer *)sender {
CGPoint translatedPoint = [(UIPanGestureRecognizer*)sender translationInView:self.view];
CGPoint translation = [sender translationInView:sender.view];
CGRect newFrame = [sender view].frame;
[sender setTranslation:CGPointZero inView:sender.view];
if (sender.state == UIGestureRecognizerStateChanged)
{
newFrame.origin.x = newFrame.origin.x + translation.x;
// Makes sure it can't go beyond the left of the screen.
if(newFrame.origin.x > 0) {
[sender view].frame = newFrame;
}
}
if(sender.state == UIGestureRecognizerStateEnded){
CGRect newFrame = [sender view].frame;
CGFloat velocityX = (0.3*[(UIPanGestureRecognizer*)sender velocityInView:self.view].x);
// If the user swipes less then half of the screen, it has to bounce back.
if(newFrame.origin.x < ([sender view].bounds.size.width/2)) {
newFrame.origin.x = 0;
}
// If a user swipes fast, the velocity is added to the new x of the frame.
if(newFrame.origin.x + velocityX > ([sender view].bounds.size.width/2)) {
newFrame.origin.x = [sender view].bounds.size.width + velocityX;
releaseViewDismissed = YES;
}
// Do it all with a animation.
[UIView animateWithDuration:0.25
animations:^{
[sender view].frame = newFrame;
}
completion:^(BOOL finished){
if(releaseViewDismissed) {
// Finally remove the new view from the superView.
[[sender view] removeFromSuperview];
}
}];
}
}
If you want the presented view controller to slide in from the right to the left, it cannot be a modal view. #Juan suggested one way to achieve the right to left and swipe back, but it would result in the grid view being pushed out of the way by the new view. If you would like the new view to cover the grid view when it slides in, you will either need to accept the vertical slide of modal views or write your own code to slide the view in from the right -- the latter would not actually be all that difficult*.
As for the swipe to get back, the easiest way to do that from either a modally presented view or a view you animate in yourself is to use a UISwipeGestureRecognizer. You create the recognizer, tell it what direction of swipe to look for, and you tell it what method to call when the swipe occurs.
*The gist of this approach is to create a UIView, add it as a subview of the grid view, and give it the same frame as your grid view but an x-position equal to the width of the view, and then use the following code to make the view animate in from the right.
[UIView animateWithDuration:0.3 animations:^{
slidingView.frame = CGRectMake(0, 0, slidingView.frame.size.width, slidingView.frame.size.height);
}];
I believe what you need is the following:
Create another controller that is going to handle navigation between these two (ContentViewController for example). This controller should have a ScrollView with paging enabled.
Here is a simple tutorial if you don´t already know how to do this: click here
Once the cell is clicked you have to:
Create the new ViewController to be shown.
Enable paging and add this ViewController to the ContentViewController
Force paging to this newly created ViewController
Additionally you have to add some logic so that when the user swipes to change back to the first page, paging is disabled until a new cell is clicked to repeat the process.
I have a UITextField inside a UIScrollView (a few levels deep). I am watching UIKeyboardDidShowNotification, and also calling the same code when I manually change the first responder (I might change to a different text field without momentarily hiding the keyboard). In that code I use scrollRectToVisible:animated: to make sure the UITextField is visible.
I was having a huge headache debugging why that was acting funny, but I realized now that UIScrollView automatically ensures that the first responder is within its bounds. I am changing the frame of the UIScrollView so that none of it is hidden behind the keyboard.
However, my code can be slightly smarter than their code, because I want to show not only the UITextField, but some nearby related views as well. I try to show those views if they will fit; if not whatever, I try to show as much of them as I can but at least ensure that the UITextField is visible. So I want to keep my custom code.
The automatic behavior interferes with my code. What I see is the scroll view gently scroll up so that the bottom edge of my content is visible, then it snaps down to where my code told it to position.
Is there anyway to stop the UIScrollView from doing its default capability of scrolling the first responder into view?
More Info
On reviewing the documentation I read that they advise to change the scroll view's contentInset instead of frame. I changed that and eliminated some unpredictable behavior, but it didn't fix this particular problem.
I don't think posting all the code would necessarily be that useful. But here is the critical call and the values of important properties at that time. I will just write 4-tuples for CGRects; I mean (x, y, width, height).
[scrollView scrollRectToVisible:(116.2, 71.2, 60, 243) animated:YES];
scrollView.bounds == (0, 12, 320, 361)
scrollView.contentInset == UIEdgeInsetsMake(0, 0, 118, 0)
textField.frame == (112.2, 222.6, 24, 24)
converted to coordinates of the immediate subview of scrollView == (134.2, 244.6, 24, 24)
converted to coordinates of scrollView == (134.2, 244.6, 24, 24)
So the scroll view bottom edge is really at y == 243 because of the inset.
The requested rectangle extends to y == 314.2.
The text field extends to y == 268.6.
Both are out of bounds. scrollRectToVisible is trying to fix one of those problems. The standard UIScrollView / UITextField behavior is trying to fix the other. They don't come up with quite the same solution.
I didn't test this particular situation, but I've managed to prevent a scrollview from bouncing at the top and bottom by subclassing the scrollview and overriding setContentOffset: and setContentOffset:animated:. The scrollview calls this at every scroll movement, so I'm fairly certain they will be called when scrolling to the textfield.
You can use the delegate method textFieldDidBeginEditing: to determine when the scroll is allowed.
In code:
- (void)textFieldDidBeginEditing:(UITextField *)textField
{
self.blockingTextViewScroll = YES;
}
-(void)setContentOffset:(CGPoint)contentOffset
{
if(self.blockingTextViewScroll)
{
self.blockingTextViewScroll = NO;
}
else
{
[super setContentOffset:contentOffset];
}
}
-(void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated
{
if(self.blockingTextViewScroll)
{
self.blockingTextViewScroll = NO;
}
else
{
[super setContentOffset:contentOffset animated:animated];
}
}
If your current scroll behaviour works with a setContentOffset: override, just place it inside the else blocks (or preferably, in a method you call from the else blocks).
In my project I have succeeded to achieve this by performing my scroll only after some delay.
- (void)keyboardWillShow:(NSNotification *)note
{
NSDictionary *userInfo = note.userInfo;
CGRect keyboardFrame = [[userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];
UIEdgeInsets contentInsets = self.tableView.contentInset;
contentInsets.bottom += keyboardFrame.size.height;
[self.tableView setContentInset:contentInsets];
[self performSelector:#selector(scrollToEditableCell) withObject:nil afterDelay:0];
}
Also there is other possibility to make your view with additional views to be first responder and fool scroll view where to scroll. Haven't tested this yet.
This may turn out to be useless, but have you tried setting scrollView.userInteractionEnabled to NO before calling scrollrectToVisible: & then setting it back to YES? It may prevent the automatic scrolling behavior.
Try changing the view autoresizing to UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleRightMargin. The default is FlexibleTopMargin so maybe thats the reason. btw scrollRectToVisible: is using the scrollView.contentSize.
The other thing you can try to change the scrollView size first and then apply the scrollRectToVisible: change. First frame change, then content change. (Maybe observe the keyboard did appear event)
The automatic scrolling behavior seems to be especially buggy starting in iOS 14. I alleviated the problem by subclassing UIScrollView and overriding setContentOffset to do nothing. Here is the bases of my code.
class ManualScrollView: UIScrollView {
/// Use this function to set the content offset. This will forward the call to
/// super.setContentOffset(:animated:)
/// - Parameters:
/// - contentOffset: A point (expressed in points) that is offset from the content view’s origin.
/// - animated: true to animate the transition at a constant velocity to the new offset, false to make the transition immediate.
func forceContentOffset(_ contentOffset: CGPoint, animated: Bool) {
super.setContentOffset(contentOffset, animated: animated)
}
/// This function has be overriden to do nothing to block system calls from changing the
/// content offset at undesireable times.
///
/// Instead call forceContentOffset(:animated:)
override func setContentOffset(_ contentOffset: CGPoint, animated: Bool) {
}
}
This works but you have to deal with reimplementing many of the scroll views behaviors and methods that you normally get for free. Since scrollRectToView and scrollToView both use setContentOffset you also have to reimplement these if you want them to work.
I have many UIButtons within a UIScrollView. Those UIButtons have actions attached to them in Touch Down Repeat. My problem is my scroll view doesn't scroll when I touch a button then scroll, but it works fine if I touch outside of the button.
How can I allow my scroll view to scroll even though a button is pressed?
As long as you have the Cancellable Content Touches in Interface Builder set it should work. You can also set it in code:
scrollView.canCancelContentTouches = YES;
So view.canCancelContentTouches = YES works OK if you don't also have delaysContentTouches set to YES. If you do though, the buttons won't work at all. What you need to do is subclass the UIScrollView (or UICollectionView/UITableView) and implement the following:
Objective-C
- (BOOL)touchesShouldCancelInContentView:(UIView *)view {
if ([view isKindOfClass:UIButton.class]) {
return YES;
}
return [super touchesShouldCancelInContentView:view];
}
Swift 2
override func touchesShouldCancelInContentView(view: UIView) -> Bool {
if view is UIButton {
return true
}
return super.touchesShouldCancelInContentView(view)
}
Use a UITapGestureRecognizer with delaysTouchesBegan as a property set to true.
Is there a way to make a keyboard disappear without resignFirstResponder? I have a UITextField, and I'd like it to be able to accept new text and still have the insertion point (flashing cursor) visible without the keyboard being on screen.
When I perform a [textField resignFirstResponder] I can still insert text, by appending to the textField.text, but I can't see the insertion point anymore.
Is there a standard way to make the keyboard animate out, while having my textField remain first responder?
Thanks.
Found an answer to this question. It's not standard though, and like Dave says, may be taboo for the app reviewers. Using the code from this page as a starting point:
http://unsolicitedfeedback.com/2009/02/06/how-to-customize-uikeyboard-by-adding-subviews/
I added in an animation block. You can dismiss the keyboards view with a standard looking animation, but whatever is first responder will retain that status. Really, the keyboard is just hidden off screen.
- (void)hideKeyboard
{
for (UIWindow *keyboardWindow in [[UIApplication sharedApplication] windows]) {
// Now iterating over each subview of the available windows
for (UIView *keyboard in [keyboardWindow subviews]) {
// Check to see if the view we have referenced is UIKeyboard.
// If so then we found the keyboard view that we were looking for.
if([[keyboard description] hasPrefix:#"<UIKeyboard"] == YES) {
// animate the keyboard moving
CGContextRef context = UIGraphicsGetCurrentContext();
[UIView beginAnimations:nil context:context];
[UIView setAnimationCurve:UIViewAnimationCurveEaseInOut];
[UIView setAnimationDuration:0.4];
// remove the keyboard
CGRect frame = keyboard.frame;
// if (keyboard.frame.origin.x >= 0) {
if (keyboard.frame.origin.y < 480) {
// slide the keyboard onscreen
//frame.origin.x = (keyboard.frame.origin.x - 320);
// slide the keyboard onscreen
frame.origin.y = (keyboard.frame.origin.y + 264);
keyboard.frame = frame;
}
else {
// slide the keyboard off to the side
//frame.origin.x = (keyboard.frame.origin.x + 320);
// slide the keyboard off
frame.origin.y = (keyboard.frame.origin.y - 264);
keyboard.frame = frame;
}
[UIView commitAnimations];
}
}
}
}
I wrote in code to dismiss the keyboard to the left and to the bottom of the screen. I don't know what will happen when you eventually resignFirstResponder, but it might be an idea to reset the keyboard frame when you do that.
If there is, then it's not documented in the iPhone API. Also, what you're asking for does not make sense. You want to have the insertion point in a UITextField. OK, great. But you also want the keyboard to go away? Then what's the point of the textfield having the focus? How are you going to input data into the textfield? If you want to have a custom keyboard, then just display it on top of the keyboard. I can't think of a good reason why you'd want the cursor to be visible but not have some sort of data entry mechanism. That would break UI convention and might even get your app rejected.