This question already has an answer here:
Handling non-ascii characters in textField:shouldChangeCharactersInRange:replacementString:
(1 answer)
Closed 7 years ago.
I have an app that gets the users name and email address. I want to prevent special UTB characters like ĂȘ and wondering how to prevent them? I don't care if the person wants it in their name as it is screwing up the backend.
I want to turn all ĂȘ into e. Also any similar. Is there a way to prevent the keyboard to offer those up? Though it doesn't prevent someone from copying a pasting.
Yes, the backend should handle these, but the deliver that did isn't around and I don't want to pay to fix it. Just need to prevent on the client app.
Is there a way to prevent the keyboard to offer those up? Though it doesn't prevent someone from copying a pasting
Implement the UITextFieldDelegate method textField:shouldChangeCharactersInRange:replacementString: to replace any non-ASCII characters with their ASCII equivalents. This will prevent pasting as well as keyboard text entry of non-ASCII characters.
Related
I am building a custom suggestion/autocorrection feature in an iOS app. It must detect accidental adjacent keypresses and compare this to a known word list to suggest the word it thinks the user intended to type.
For example, if the custom word list contains cat, dog, monkey, and the user types cst, the app can determine that the most likely word was cat (because s is adjacent to the a key)
This will work on a standard QWERTY keyboard, but what happens if the user is using an AZERTY keyboard?
For the autocorrect/suggest to work reliably, the app must be able to detect the keyboard layout in use.
In iOS, it is possible to obtain a UITextInputMode object from a UITextField. This object has a primaryLanguage (string) property, which will display the locale (e.g. en-GB), but this does not contain enough granularity to distinguish between English (Australia) QWERTY and English (Australia) AZERTY. In both cases, the primaryLanguage is en-AU.
Is it possible to detect the keyboard layout in iOS?
I have not been able to find a clean solution to this problem.
Maybe this would be worth a TSI ticket to discuss it with Apple employees.
I know that this will not be a satisfying answer, but I would still like to share my thoughts here for future readers:
Private API of UITextInputMode:
textField.textInputMode?.value(forKey: "identifierWithLayouts")
This will return a string like de_DE#sw=QWERTZ-German;hw=Automatic from which you can infer the keyboard layout.
UserDefaults
UserDefaults.standard.object(forKey: "AppleKeyboards")
This will return a list of all keyboards that the user has installed. In most cases, this will only be one language (besides the emoji keyboard).
For example:
Optional(<__NSCFArray 0x600003b8e6c0>(en_US#sw=QWERTY;hw=Automatic,emoji#sw=Emoji))
You could also iterate over UserDefaults.standard.dictionaryRepresentation() and search for QWERTZ/QWERTY/AZERTY within the values.
With much manual effort, you could maybe encode UITextInputModes to binary data in all ambiguous cases like en_AU. Something like
NSKeyedArchiver.archivedData(withRootObject:textField.textInputMode, requiringSecureCoding: false) can then be used to compare binary encodings of the user's textInputMode at runtime.
I have found this old question that may have a solution for you. No sure it's still working, but it shows in the question how to get the current instaled keyboards, and someone provided a "gray area" solution, as it seems that there is no direct way to achieve what you intend to do.
Hope this help.
AppleLanguages object at index 0 is common way to get input language. Instead of trying to determinate which language users are using and default layout, as far I worked with custom keyboard extension, I used one of recommended ways from Apple: use separate keyboard layout for each language. In other way I don't think you will have a stable and productive prediction, auto correct, by the way. As for auto correct I used SymSpell (https://github.com/AmitBhavsarIphone/SymSpell) and different dictionaries from https://github.com/wolfgarbe/SymSpell/tree/master/SymSpell.FrequencyDictionary to make my own RealmDb for each language. So far it was a little work to do, but finally my keyboard extension was publisehd in App Store. [Note: I am not related with SynSpell owners or coders] See images
I am working on an app that uses emojis on screen.
These emojis are displayed on buttons that can be pressed by the users.
To make this app compatible with "accessibility requirements", a.k.a. voice over, etc. I need to get all the emojis' description text, and when user is using "voice over", the emojis can be read to the user.
For example, when user is choosing an emoji is a "smiley face", voice over should read "smiley face" to the user. However, I cannot label manually for each of the emoji, because there are thousands of them.
I am wondering where should I get all the emoji description texts?
Thanks!!
As you've noticed already, the Accessibility subsystem already knows how to accessibly describe an emoji if given one as part of an accessibility-oriented text (like the accessibilityLabel for a control).
However, should you ever need emoji descriptions for other purposes (perhaps some kind of accessibility accommodation that doesn't go through the OS's Accessibility system), it might help to know how to find them yourself.
You can do this with Swift String.applyingTransform or ObjC NSString.stringByApplyingTransform:. (Both of these are wrappers for CoreFoundation's CFStringTransform API, which is better documented and featured in an old NSHipster post.) Use the toUnicodeName transform to get the names for emoji and other special characters â for example, as noted in the docs, that transforms âđ¶đźâ into â{DOG FACE}{COW FACE}â.
(As you might notice in the StringTransform docs and the aforelinked NSHipster article, there are lots of other fun things you can do with string transforms, too, like latinizing text from other scripts or producing the XML/HTML hex escape codes for unusual characters.)
Forgot to post my answer the other day.
Turns out that Apple has already handled this in the framework.
All that we need to do is just to set the *.accessibilityLabel = the emoji itself. Then it all reads out correctly, such as "smiley face" when voice over feature is turned on.
Awesome!
Here's the situation, I'm using a custom font to render some special characters (icons) for an iOS app. I have used many of the characters in that font and everything is just fine BUT when I use one character (it doesn't matter where) the app crashes.
This problem ONLY occurs with that single character in that font, if I use any other character nothing bad occurs.
Any ideas?
Please be specific WHICH special character you are talking about & WHERE you are using it. Based on your given limited information, all I can think of is try using ASCII of that problematic character.
All,
I ran into this problem where for a UITextField that has secureTextEntry=YES, I cannot get any UTF-8 keyboards(Japanese, Arabic, etc.) to show, only non UTF-8 ones do(English, French, etc..). I did alot of searching on Google, on this site, and on Apple dev forums and see others with the same problem, but short of implementing my own UITextField, nobody seems to have a reasonable solution or an answer as to whether this is a bug or intended behavior.
And if this is intended behavior, why? Is there a standard, a white paper, SOMETHING someplace that I can look at and then point to when I go to my Product Manager and say we cannot support UTF-8 passwords?
THanks,
I was unable to find anything in Apple's documentation to explain why this should be the case, but after creating a test project it does indeed appear to be so. At a guess, I imagine secure text entry is disallowed for any language using composite characters because it would make character input difficult.
For instance, for Japanese input, should each kana character be hidden after it is typed? Or just kanji characters? If the latter, the length of time characters remain onscreen is long enough make secure input almost moot. Similarly for other languages using composite input methods.
This post includes code for manually implementing your own secure input behaviour.
I don't know if my approach to this is fundamentally wrong, but I'm struggling to get my head around a (seemingly trivial?!) localisation issue.
I want to display the title of a 'System' UITabBarItem (More, Favorites, Featured, etc...) in a navigation bar. But where do I get the string from? The strings file of the MainWindow.nib doesn't contain the string (I didn't expect it to) and reading the title of the TabBarItem returns nil, which is what stumped me.
I've been told, there's no way to achieve it and I'll just have to add my own localised string for the terms in question. But I simply don't (want to) believe that!! That's maybe easy enough in some languages, but looking up, say, "More" in already presents me with more than one possible word in some languages. I'm not happy about simply sending these words for translation either, because it still depends on the translator knowing exactly which term Apple uses. So am I missing something simple here? What do other people do?
Obviously, setting the system language on my test device and simply looking to see what titles the Tab Items have is another 'obvious' possibility. But I really have a problem with half baked workarounds like that. That'll work for most languages, but I'm really gonna have fun when it comes to Russian or Japanese.
I'm convinced there must be a more reliable way to do this. Surely there must be a .strings file somewhere in the SDK that has these strings defined?
Thanks in advance...
Rich
The simple and unfortunate answer is that aside from a very few standard elements (e.g. a Back button), you need to localize all strings yourself. Yes, UIKit has its own Localization.strings file but obviously that's outside of your app sandbox so you don't have access to it.
I filed a bug with Apple years ago about providing OS-level localization for common button titles, tab item labels, etc. That bug is still open but obviously they haven't done it yet (sorry, I don't have the radar # handy).