I'm developing a custom keyboard for the iOS operating system and I'm trying to add the auto-suggestion feature. For English dictionary there seems to be no difficulties, but for languages like french I came into a problem regarding accents. See this example: The user tries to write "Chaîne" (chain). the UITextChecker retrieves words until user reaches the "î", after that the it stops, the word list is empty.
The code to retrieve the word list is as follow:
// While user is typing the txt variable is modified...
range = NSMakeRange(0, txt.length);
words = [m_textChecker completionsForPartialWordRange:range inString:txt language:#"fr_FR"];
This problem happens also using Italian and other languages that use accented letters. You do not retrieve "città" (city) while typing "cit..." or "citt..."
Maybe it is my fault in understanding the completionsForPartialWordRange:inString:language method real meaning.
I tried to choose other solutions, for example including an SQLite database importing the Aspell dictionaries, but I'm not sure if it is legal and it will be accepted by Apple review team. Moreover database originating from Aspell are quite big. To solve the latter issue I though to use an optional download feature from the containing app, but I can't figure out how its keyboard extension could access the app's `Documents' folder, because they do not share the same bundle path for that folder.
Can any one help me in understanding the UITextChecker and accented words?
Thank you very much...
Related
I'm just learning and working through the Apple Xcode/Swift guide, and am currently working on the "Apple Pie" project (in case anyone is familiar). If you're not, it's a "hangman" style game, where you guess the letters in a word each round, and have a total number of guesses before you lose. The guide asks you to add your own list of words to an array, but that feels tedious and boring. I know this is just a guide to help me learn, but I think it'd be a lot more fun to pull a random word from a set of "all" English words (at least several thousand) to guess from.
How would I go about importing a set of words like this, to where I don't have to type them all hard coded? I found references to an "npm" that seems to contain what I'm looking for, but have no idea what an npm is or how to add it to my program as a searchable set.
The best thing you can do is to pull a request to a web were many english words are stored, for example: http://www.mieliestronk.com/corncob_caps.txt, create a file inside your app with all that words and then create an array in code where you can choose randomly from.
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 have a keyboard app designed for Serbian language. My keys have labels based in Serbian cyrillic alphabet. My xml strings that are used for those labels are enclosed in <xliff:g></xliff:g> tags, but a certain provider on a certain type of a phone still translates these into a different language. Just in case, I also have my strings in language specific folders, but it still happens. Does anyone know if there is a way I could disable translating of all my strings any other way?
There are providers who can handle technical files translations,i.e. know what to translate in technical files. Also, some are available for you to manage the translations. OneSky is one of these platform and we also provide translation service.
See GIF of how placeholder validation works in OneSky
Disclaimer: I work in OneSky
For example, say my App Store description is Titled: "Big Bobs Bowling". But due to space restrictions, the bundle display name (what is displayed under the icon when installed) has no spaces and is "BigBobsBowling".
I understand that the App Store description Title gets included in the App Store Search. But would it be a good practice to include "BigBobsBowling" as a keyword, in the event someone searches based on seeing the installed icon? Or does the search function somehow account for this? I am keeping in mind that I do not want to waste valuable keyword characters.
Based on my experience, you don't need to add the keyword BigBobsBowling in your App Store Keywords. If someone searches that term your app will be found.
For info, one of my app is titled Market Impulses but if I search the term MarketImpulses I found it (I didn't define that term as a keyword).
You can focus your remaining keywords characters to your ASO :-)
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.