As far as I can tell by default the react native text input component has some inconsistencies on iOS from the normal text input when using it in a controlled way. The examples I've found so far:
the "period shortcut" (pressing two spaces to get a period in text) does not work.
typing a special character and then space does not switch the keyboard back to its normal mode
spelling errors do not have a red underline
often text replacement shortcuts don't work
I'm trying to get around this in the short term and so far the only thing I've found that works is using a multiline input. At this point I'm trying to "hack" the multiline input to work like a singleline, but figured it was also worth reaching out to see if anyone else has a better solution.
Related
I am not using a button for this particular part of the code, only an input field (and any button I added isn't working) but I would like a calculator icon next to the word "Calculate" in the "value" field.
So far I have this:
value=" Calculate"
But this is failing to reproduce the calculator icon (the code does turn blue as though it has been accepted but the icon fails to load).
f1ec is the unicode of the icon at Fontawesome. I can not seem to get a value that works and displays. Is there another way around this or have I done the unicode incorrectly?
Thanks for the help.
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
I'm trying to implement the transfer of a one-time code from SMS to the field above the keyboard, as in the image.
But for some reason the field above the keyboard is not displayed.
Code:self.valueTextField.textContentType = UITextContentTypeOneTimeCode;
UI hierarchy:
+UIView
CustomContentView
UIImageView
UITextField - valueTextField
UITextFieldContentView
I have read these materials:soQuestion and apple docs , and I saw a warning:
If you use a custom input view for a security code input text field, iOS cannot display the necessary AutoFill UI.
... but I do not understand what is meant by custom input view.
Also I have category for UITextField. Can it affect the work?
I will be glad to any ideas, thanks!
Okay. This is what I could find out. Regarding the code, it is enough that I described above. Additional settings on the client is not required. But you need to pay attention to the text of the SMS message. As an example, I attached two messages.
In the first message, our code is defined by the system as a phone number. We can even call it if we click on it. But why do we need to call a one-time code? :)
In the second image, the code is defined as one-time, just what we need. If we click on it, the system will offer to copy it to the clipboard.
What is the difference? Unfortunately, it is not completely clear by what rule the text is parsed in SMS. But we can check your text in the following way:
If you set a property textContentType to your text field and nothing works for you, the first thing you need to check is whether the operating system determines the code correctly. To do this, simply go to the message application and check the code:
blue font color with underscore - the system did not recognize
one-time code.
black font color (as default) with a gray underscore - it's okay!
At the end, in the first case, you should check the text of the message for the contents of incorrect characters.
PS Just a couple of examples of correct and incorrect SMS:
SMS-code: 12345 £ correct
SMS-code: 12345 $ correct
SMS-code: 12345 № correct
SMS-code №1: 12345 incorrect
I got caught out by the fact "Autofill PAsswords" was turned off on the phone.
It seems that it needs to be on for this functionaility to work.
I have a TextInput that should only accept numeric values. I can more or less force this by using keyboardType "number-pad" on iOS, but Android only has "numeric", which provides keys for characters like - or ,. Even then, an attached hardware keyboard (like the iOS Simulator / Android Emulator have by default) still allows entry of non-numeric characters.
Everything I can find online is filtering the entered value in onChangeText, storing the filtered value in the state and use the state as the TextInputs value – while this does work, it causes the entered value to briefly appear before the JavaScript is able to filter it. Since I can't force the Android keyboard to only show numbers, I really want to avoid this visual behavior.
Android has android:digits for this, but I don't think this is available in React Native.
Is there any way to filter the TextInputs value before it is displayed?
I think solution for now is to accepts extra characters on Android and when you are submitting the form just transform that text field's input before sending to server :)
I'm creating my own Text Editor in iOS using Core Text. Pretty much everything works great with one exception: Stuff really starts to slow down when the text document is "large". I've discovered that iOS is requesting the entire document text on every change, including selection changes (at least, when I notify the UITextInputDelegate of selection changes). Part of the problem is that I've already optimized my Core Text code by splitting up the document into paragraphs and rendering only the paragraphs that change. But doing this also split up the document string (which is a NSAttributedString) into the separate 'paragraph objects'. So when iOS requests the entire text document, I have to combine all those strings into one string, which takes time and memory.
My solution is to give iOS incorrect UITextPosition's for the beginningOfDocument and endOfDocument methods, limiting those positions to the paragraph(s) intersecting the current selection. This is actually working very well. iOS is now only requesting the current paragraph(s) of the change, which has completely eliminated the slow-down.
So far, so good, but I'm a little worried that this might break something. I've tested this a bit and nothing is broken, but Text Editors can be hard to test (who knows if it'll break in some edge condition).
I have 2 question:
Should iOS be requesting the entire document text on each change? If not, then perhaps some other method in my UITextInput protocol methods that are returning the wrong value, somehow causing iOS to request the entire document.
Does anyone know if this will actually break anything?
Alright, I've been testing this for quite a while now and I've finally found a place where using this technique will break functionality. UITextInput uses beginningOfDocument and endOfDocument to determine whether it has room to "move" when you press the arrow keys on a bluetooth keyboard. Returning only the beginning and end of the currently selected paragraph(s) cause it to ignore the 'arrow' buttons when it is at the beginning or end of that paragraph and those arrows indicate an attempt to move outside what it thinks is the beginning/end of the document. It's easy enough to fix. If the currently selection begins at the beginning/end of a paragraph, I now also return the previous/next paragraph as part of the document, respectively.