There are multiple fields on my screen which is designed in unity. While filling downwards input is blocking due to the keyboard.
Unity never supports the auto-scrolling screen just like the native Android/iOS.
Also, One more problem is the user has to input into a Keyboard input instead of an actual input box
Please check this screenshot for better understanding.
What would be the ideal way to overcome with this?
TouchScreenKeyboard
You have to detect when the keyboard is open and do some logic that scales, or re-anchors the text field.
Related
I've been playing around with JTGestureBasedTableView, but this library only deals with pulling and swiping gesture handling.
I am trying to figure out how the overlay text field input (with translucent background) is implemented in Clear iPhone app (screenshot below). This is the point when you pull down a new cell and it turns into a text field, and once you finish typing in, the content gets filled into the top-most cell, which is presumably hidden behind the textfield.
What is the simplest way to do this?
Here is an excellent tutorial on clear app by Colin Eberhardt .It explains well how the implementation is done
I’m creating an application which will be used by visually impaired users using voiceover (in built screen reader in iPhone).
Certain group of visually impaired persons use external keyboard.
1)Is there any way to Control the reading order of controls in iPhone using xCode?
I want a particular control to be read after another. Similar functionality can be achieved via tabIndex property in other programing languages. Is there any similar property available in xCode with which we can control the reading/navigation order of controls?
2)Is it possible to shift focus from one element to another on any event? I tried working with "nextResponder",but it is not working.
3)If a regular user is using iPhone with an external keyboard, it becomes difficult to understand where the current keyboard focus is and thus makes the application difficult to use. Is it possible to provide focus caret (black border around the control which is currently focused?) When Voiceover is ON, a black border is shown around the items which are focused
1) Do you mean: this
2) There is a way to switch focus from one element to another after something changed
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, yourElementOfFocus);
or if it is an layout change
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, yourElementOfFocus);
3) I don't quite understand your question... If voiceOver is turned on, doesn't it automatically shows a border around the element it is currently focussed on?
Is there any datepicker UI elements that I can use on my iphone application? Native one is found to be too big.
Maybe the right question is why is it too big? Apple has done a pretty good job of making a set of controls that apply for most circumstances, look stylish, and are usable by the user.
The default control is the size of the iPhone keyboard, and it was made this way for a very good reason: all elements are easily viewable and selectable by touch. If you have a lot of UI elements making life difficult, consider displaying the selected date/time in a label and edit it in a modal dialog.
I am having a terrible time trying to get an input box like the one in the SMS app.
Can anyone offer some guidance on how to build one of these and make it look good? I need an input box that is shaped nicely like the UITextfield but will stretch vertically when typing.
I assume that I need to calculate width of the text and stretch the overlay image frame vertically when the text word wraps. The closest I have come does stretch but the cursor bounces all around when nearing the boundaries.
UPDATE:
I have worked on this everyday for a week and I have about given up on the UITextView. I can get it to stretch properly but when backspacing, the Textview height shrinks too much when going up a line. As I continue backspacing it corrects itself. For example, it displays this behavior when I am on line 4 and backspace up to line 3. Then as I continue backspacing, it corrects until I get to the end of line 2. Then it corrects itself,.... etc.
I decided to try to subclass UITextField but I can't even get it to display in the Frame size that I specify. 150,150,150,150.
Try Chat Input Sample. It has the similar look and functionality of SMS app.
Three20 project has a control that should do this for you.
From the Three20 README:
TTTextEditor is a UITextView which can
grow in height automatically as you
type. I use this for entering messages
in Facebook Chat, and it behaves
similarly to the editor in Apple's SMS
app.
You get to do this yourself. Luckily, the UITextField can notify you whenever its text changes using UITextFieldTextDidChangeNotification, and luckily NSString has methods (under the UIKit Additions) that let you get the height of the string given a certain width using boundingRectWithSize:options:attributes:context:, and luckily you can resize a UITextField yourself using frame.
I know this is old but for the people that still look at this answer there is now a nice control from Slack that does that called SlackTextViewController.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!