I am a linguist, not a programmer, sorry. I was asked and am adapting a keyboard for a minority language in Africa. I have spent a lot of time on this and am willing to learn more and to dig deeper.
I am using the latest Android Studio in Windows 10 and am working from a code sample from Google here:
https://android.googlesource.com/platform/development/+/master/samples/SoftKeyboard?autodive=0%2F
I managed to adapt this sample to our local language and compile and install in a several different phones from our team and all the new characters in the alphabet are working fine (ǝƎ ŋŊ ɖƉ ɔƆ ɛƐ ɩƖ ʊƱ). No problems here, this is just background for those who like that.
The unexpected behaviour is sadly with several existing keys, which I have not altered: apostrophe, quotation marks, hyphen, etc. Those are characters which to me "are too active"; possibly an escaping-problem or something the like.
When using my new keyboard in WhatsApp I can type any text just fine, until I need (for example) an apostrophe. Then the apostrophe will delete any alphabet-letter backwards until it hits a "resisting character" (those are space, full stop, comma and some others) and then it will show itself. Example sentence: "Three pigs' house."
I am typing this:
Three pigs
then I hit apostrophe and am expecting this:
Three pigs'
but instead I get this:
Three '
You can see how the apostrophe has deleted "pigs" and has been stopped by the space behind "Three". The same happens for - and for " and for a few other "bad keys".
I have this unwanted behaviour in several "powerful apps" like WhatsApp and Telegram but NOT in a simple text editor like this one:
https://play.google.com/store/apps/details?id=com.maxistar.textpad
I double-checked and compiled the original sample keyboard: It shows the same bad behaviour in WhatsApp, Telegram etc. but not in Simple Text Editor.
So the Google sample SoftKeyboard is having issues. I quote their doc:
Example of writing an input method for a soft keyboard. This code is
focused on simplicity over completeness, so it should in no way be considered
to be a complete soft keyboard implementation. Its purpose is to provide
a basic example for how you would get started writing an input method, to
be fleshed out as appropriate.
I would like help please:
Is this really a problem with the keyboard, or is the fault with WhatsApp etc. for "doing too much" with the characters being sent by the keyboard?
Or how can I find out where the deleting is happening? (Since this is only an input method, the Android Studio's debugging tools do not yet work for me.)
Is there a forum, where I can get help for that specific SoftKeyboard?
Any input to help me to change my self-made keyboard so that it behaves normally in any App which needs text-input, even WhatsApp, Telegram and the like.
Or is there another working template out there, which I could use to make a working soft keyboard for our language. Since I am not a pro, I am hoping for something that I can import into Android Studio for adapting.
Please do not yell at me. Any input and any help is welcome. I can upload my files, but the behaviour can be observed from the original SoftKeyboard files (see my first link at top). If you can type your own language, please be grateful. My people would also love to write their language in WhatsApp. Thank you.
First update:
I have looked over the main Keybaord.java file and have changed
mPredictionOn = true;
to
mPredictionOn = false;
for
case InputType.TYPE_CLASS_TEXT:
This has helped to calm the unexpected behaviour but has also lost some of the functionality. And the caps state is no longer auto-undoing like it is meant to be after user hits one capital letter.
Related
Precondition : Accessibility Talkback on.
Problem : While typing in characters from soft keyboard into the edit text, the characters are announced twice.
(I think once by the keyboard and once by the edit text).
Problem: Sighted users don't understand/empathize well with the types of information that blind users need. They just use a keyboard with TalkBack on, without actually closing their eyes and experiencing it the way a blind or partially sighted user would.
Solution: Close your eyes and actually use the keyboard the same way a TalkBack user would. You will discover that there are actually two relevant pieces of information here. The key that you're going to select and the key that you've actually selected.
Real Solution: Let Android do its thing unless you REALLY know what you're doing. More often than not, well intentioned, developers just muck things up when they start trying too hard. Provide content descriptions for your non-text controls, hook up some nice data associations when necessary and otherwise leave things alone.
This is an Android question.
Inside my <TextInput> (ReactNative (which renders an EditText in Android)) when the user types "#" and then they use Androids swipe mode to auto-complete a word, it adds a space between the "#" and the autocompleted word. So what I was doing was, onChange of the text, I replace the space between "#" and the word, however while the user is in swift mode, it is really messing things up. The space comes back and the swift autocomplete messes up to another word.
Is there a way in react-native to listen when the user accepts an autocompletion? I want to then check if the previous two chars are a # (hashtag and space) and if so, then replace it with just # (hashtag without space).
I was thinking the onCommitCompletion- https://developer.android.com/reference/android/widget/TextView.html#onCommitCompletion(android.view.inputmethod.CompletionInfo) - fires after a suggested word is accepted - is this true? If it is this would be perfect and I can submit a PR to react-native to accept this for Android.
Here is a video of what's happening: https://gfycat.com/AdmirableGrizzledIrishsetter
Low quality:
This is happening because you are typing a text via Swipe feature of your keyboard. The Swipe feature automatically adds an extra space before and after the String. There is no way to get rid of it, it's an integrated feature of(some) the keyboard. We have no control over it.
Don't worry, the end user is aware of it and all he has to do is type the whole text rather than using Swipe feature to input his text.
Try disabling AutoComplete inside your TextInput , perhaps like <TextInput autoCorrect={false}/>, I'm not sure.
Also, this isn't the problem with Android phones only, try installing GBoard in an Apple Device and you'll face the same problem.
I worked on a major keyboard for 2 years and I have no idea what you mean by "swift mode". But there is no such feature in the generic keyboard API. It may be a feature of some particular keyboard, but there'd be no way to programmatically turn it off.
What you're describing comes closest to sounding like autospacing. This is not a concept that Android has, it would be a concept of each individual keyboard. And since Android knows nothing about it, it can't turn it off (on many keyboards the user could, but that's it).
You might be able to override it (not turn it off, but force the spaces to disappear) if you were to do some work with either overridding the InputConnection or setting a text watcher in Java and altering the text to be inserted, but neither can be done at the react native level- you'd need to write a custom edit text and link that down to react native via a native component.
I think this would be onCommitCompletion - I'm not sure though I am not able to test yet. I think in this callback I would get the position, and see if there is a leading space, and if so then remove that leading space.
I have an app that I would like to submit to Google Play Store, just to be able to say I have an app that others would find useful. I thought it would be a freebie until I found a similar app-for-pay that mine has more features than. Mine also looks better. Whatever, my questions are about the keypad.
Here are screen shots of input screens, one with output filtering. Output pops up after the Show button is pressed. (The Help button clarifies the overly-terse "output filtering" portion.)
The only keys I need are the ten digits 0-9 and the backspace and Next keys.
Is there an input type that I haven't stumbled onto yet that would have just those 12 keys?
Or is there a way to hide the math symbol, ABC, and "Swype" keys? (Their presence isn't overly distracting, but it would be better without them.)
(I know I could try to design my own custom keypad, but it would be really hard to set up a dozen listeners for a dozen new buttons and have to handle my own text field editing. Meanwhile, the existing look and feel is standard and the app is FINISHED if I don't go this route! It wouldn't be wise to go this route would it? A lot more work not worth the effort?)
there is an android:inputType="number", Also it wont allow any other special characters too...
I'm currently developing an application targeted at android and desktop devices using apache cordova and HTML5.
In order to get the numeric keyboard to pop up I've used input type="number", which works fine.
However, the input field should also accept strings. The current functionality of type=number is that the ui seems to allow for strings to be entered, but the value property of the element is not changed if the input is invalid (e.g not numberic).
Is there a way of getting the numberic keyboard on mobile devices, while still being able to enter text?
My inital tries consisted of capturing the keydown event and manually setting the this.value property. I've tried this using jQuerys .val() and of course the more 'native' approach element.val += char. None of which work. UI is updated, but the change is not reflected in the model.
EDIT
For the next guy trying to achieve this.
1) The HTML solution.
As #LuudJacobs mentions in the comments below; There's currently no way to decide which keyboard is shown except for defining the type-attribute. Though some devices have a button to go back to alphabet keyboard, its not the case for every device. And can not be used reliably.
2) Writing a phonegap/cordova plugin.
It is possible to write a plugin to show and hide the keyboard at will. But, as far as I could find, there is currently no way of programmatically telling it to default to the symbols keyboard. Thus the functionality achieved is similar to using type=number and type=text in the HTML. Another problem with this approach is the diversity of keyboard for android devices, where even users themselves can install their custom keyboard. The functionality of the keyboard can are therefore unknown. What works on one device, may not work on the next.
3) JS/HTML/Canvas solution
Finally... A feasible solution. I suggest taking a look at this walkthrough as it shows an easy way to creating the keyboard using just html and js. Another option would be to use a canvas, and draw the keyboard yourself, but I would imagine that this is more error prone and harder to do.
As explained in the HTML5 spec you can not have anything but valid floats in a input type="number". So You can not. On a sidenote: how would users enter text when they'd only have a numeric keyboard?
I've been working on a .kcm file to give me my layout of choice on android. It's a rather obscure swedish dvorak version called se_sv_dvorak, http://tlundqvist.org/sv_dvorak/ .
I'm using a mac bluetooth keyboard like this: http://www.netonnet.se/ItemImages/dator/laptop/till-din-mac/mss-och-tangentbord/apple-wirelesskeyboard(160756)-Large.jpg
As you can see, this keyboard has more keys than an american keyboard, specifically the right of the ä-key, where US keyboards have apostrophe.
How can I implement this extra key?
Sincerely,
Love
I realised that when I hit the key in question it gave me the same character as the key to the left of Z (see picture). At first I thought this was a buggy reaction to being unbound but I soon figured out that they both were bound in the .kl file to the same keycode (D'uh)!
They were both bound to BACKSLASH for some reason. I bound one of them to HENKAN (something japanese maybe?) in the .kl file and bound HENKAN to ; and : in the .kcm file.
Everything seems to be working perfectly and I can finally start developing on my huge Xperia Z Ultra! :)
I'm sending my work to the original developer and maintainer of the layout. Maybe he will upload it to his drivers page. If someone comes here looking for this layout on android, head over to his site or send me a message!
Love and light