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
Related
I want to have to focus of my textfield always at the beginning of the textfield even if the user is writing, I want that the user always see the first word he typed.
Is it possible?
For this kind of thing I usually use two textfields, the "real one" which is behind the one the user sees and the one the user sees which is in front, has user interaction turned off, and is covered by another view with a tap gesture recognizer (or just a clear button).
When the user taps on the empty view or button, you tell the real textfield to become first responder. As the user types in the textfield you implement the delegate methods and forward whatever filtered or formatted input you want to the visible textfield in front.
I have a view with a textfield at the top, a textview under it and two buttons below the textview.
The keyboard is configured with a "Done" button. Once the user has typed in their info, they click the save button, which is below the textview. First they click Done to hide the keyboard (and reveal the save button) then click the save button.
I need to allow carriage returns in the textview but "Return" is already taken up by Done.
How is it usually handled when you need a Return key and ability to also hide the keyboard?
Drag a button into your view, delete the text, and resize it to take up the entire view. In the document outline, select the new button and drag it to the top of the list of elements. This puts it in the background so it is not hiding the elements of your view.
Add this code to your ViewController:
#IBAction func hideKeyboard(sender: AnyObject) {
self.textField.resignFirstResponder()
}
Link the button to this action and you're all set.
If you're using a UINavigationBar or have other buttons or fields, activating any of those UIControls could be detected and used to dismiss the keyboard via resignFirstResponder(). In fact Save/Cancel/Done are UIBarButtonItems and are a standard mechanism for completing things and changing state, and create a framework for accomplishing what you want. If you don't take that approach then you have to get creative with how you do it, and also make it clear to the user what needs to be done.
In Interface Builder you can change the type of your main view from UIView to UIControl and then use addTarget() to detect touch events as a 'touch outside' area and use those actions to resign first responder as well. But you might want to consider a UINavigationBar or some other button bar or tab interface to make state transitions.
Also review iOS Human Interface Guidelines document. It's a great document for understanding how iOS is designed to handle common situations like what you are dealing with, and it can get you out of design ruts. It's well written and worth re-visiting periodically.
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'd like to create a UITextView that you can tap anywhere within it and start typing at that location. The default behavior of the control is that typing starts where the last character ended. So, if I had a UITextView with no text in it and tap in the middle of the control, I'd like typing to start there--not in the upper left.
What is the best way to implement this behavior? I've considered making the default text value of the view to be 3000 space characters or something similar, but this seems like not an elegant solution. Suggestions?
I suggest deriving from UITextView to create a custom view that handles taps. You'll want to override the following methods, probably:
touchesBegan:withEvent
touchesMoved:withEvent
touchesEnded:withEvent
touchesCancelled:withEvent
Make sure the userInteractionEnabled property has a default value of YES. Override hitTest:withEvent and pointInside:withEvent to figure out where in your view the user tapped.
Be sure and read the Responding to Events section in the View Programming Guide for iOS, and also see the Event Handling Guide for iOS for more details.
Anyway, once you figure out where the user touched, you can modify the text or reposition the karat as appropriate.
I'm about to start a new iPhone app that requires a certain functionality but I'm not sure if it's doable. I'm willing to research but first I just wanted to know if I should at least consider it or not.
I haven't seen this in an app before (which is my main concern, even though I haven't seen too many apps since I don't own an iPhone), but an example would be the iPhone shortcuts panels: you can hold on an app, and then drag it to another panel, sweeping while still dragging it. But this is the core app, is it possible to reproduce something similar within a normal app?
I only need to be sure it can be done before I start digging, I don't need code examples or anything, but if you have some exact resources that you consider helpful, that would be appreciated.
Thanks!
Yes. If you have your custom UIView subclass instance inside a UIScrollView, your view controller just needs to set the UIScrollView to delay content touches and not allow it to cancel touch events.
[scrollView setCanCancelContentTouches:NO];
[scrollView setDelaysContentTouches:YES];
When the user taps and holds in the custom view, the event goes to that custom view, which can process the touch events to drag an item around, but if the user quickly swipes, it scrolls the view.
The "panel" view that you're referring to appears to be a UIPageControl view — although, perhaps, the specific incarnation of this view that Apple uses for the iPhone's home page may be customized.
Instances of generic UIView views that you might touch-and-drag will receive touch events. By overriding methods in the view, these events can be processed and passed to the page control, in order to tell it to "sweep" between pages.
If I wanted to do what you're asking about, that's how I might approach it. It seems doable to me, in any case.
Start with this: Swip from one view to the next view
Try using a UIButton that tracks the time since the state of the button changed to "highlighted". You may need to do this in order to track the dragging and move the button around:
Observing pinch multi-touch gestures in a UITableView
Check to see if the button starts overlapping one side of the screen while being dragged. If s certain amount of time elapses since the button first started overlapping the edge and then manipulate the UIScrollView so that it switches to the next page on the corresponding side of the screen
You may need to use NSTimer to keep track of how long the button is held down, etc.
In any case there's no reason why this couldn't work.
If UIButton doesn't work then perhaps try a custom subclass of UIControl (which tracks the same touch down actions etc.). If that doesn't work then use the window event intercept thing to track everything.