Is there a way to find out the current keyboard layout?
I.e.: the typical layout is QWERTY but, e.g., Germany usually has QWERTZ, etc.
Also, I've seen some older Android phones without digits row on the main keyboard page.
Is it possible to find out if the current keyboard layout has also digits row? (Digits row without long touch) And potentially other "non standard" things?
Is there a way to find out current keyboard layout ?
Unless you mean "the keyboard that is visible to the user right this instant", there is no concept of a "current keyboard layout" in Android. A user may have 0-N input method editor implementations available to them, choosing among them as the user sees fit. Plus, depending on circumstances (e.g., inputType hints), an input method editor can display different input options.
Is it possible to find out if the current keyboard layout has there also digits row ?
No.
And potentially other "nonstandard" things ?
No.
Related
I'm having what seems to be an odd problem, and I'd greatly appreciate any suggestions which might help.
I'm trying to achieve due diligence by testing on a variety of screen form factors, but I'm having a problem when it comes to the default ( AKA Google ) keyboard on an emulated Nexus 4 using API level 19. AFAIK, according to the on-line specs the Nexus 4 was released with API 17, so it would seem to me that 19 ought to be able to handle any hardware in the Nexus 4.
I'm working with an app that displays a document and if the User wishes, allows notes about the document to be entered, at the same time the document is being viewed. By default most of the screen is taken by the view of the document. But when a Button is pressed to allow notes about the document to be entered, Views are re-arranged to allow for a soft keyboard to be displayed along with an EditText view to accept the notes and still allow for as much of the document to be viewed, as conveniently as possible, and scrolling is provided.
In the default "portrait" orientation I'm able to shoehorn in what I need with out too many problems; but oddly in "landscape" orientation, no matter how I try to constrain it, the on-screen keyboard itself occupies fully half the screen "height" and takes the other half with a separate input area it displays, several lines high; the "DONE" button is displayed separately about half way up the height of the input area near the right screen edge.
In order to keep the soft keyboard and any associated input area as small/simple as possible, I've supplied these attributes for the EditText:
android:inputType="text|textNoSuggestions|textShortMessage"
android:singleLine="true"
and this for the themes in my styles.xml file :
<item name="android:windowSoftInputMode">stateUnchanged</item>
I've even considered going as far as building a custom keyboard structure in XML, etc.. But my understanding is that Android won't allow a keyboard definition to be used "privately" for just one app; instead it requires a custom keyboard description to be approved by the User as the User's standard keyboard, or won't allow the custom keyboard to be used at all.
Have I've missed something? Am I not making the correct use of attributes for my purpose? Is there something else I need to do in order to get the desired effect? Does the actual Nexus 4 behave as I've described? Or is there a problem with the Emulation?
I'd be very grateful for any helpful thoughts.
Hopefully some images will help to illustrate the issue.
Default document viewing mode:
After the User presses the "MAKE NOTES" Button, note taking mode. This is before the User presses within the EditText view ( which is displaying the hint string "To enter notes, press here" ) :
When the "MAKE NOTES" button is pressed I rearrange things. It appears to me that the controls fit roughly in the upper left quadrant,
the document view is placed in the notably smaller scrollable area roughly in the upper right quadrant; I request that the keyboard be displayed, and it fits on the screen below those things. Since the keyboard does fit, I wouldn't have expected the "extract" view; especially since by the time I got these emulator screen snapshots, I had restricted the EditText view to one text line, so I would expect input to occur in place, within the
EditView, just as it does in "portrait" orientation...
Instead, when the User presses within the EditText view:
There is no way to change the height of the keyboard. The keyboard itself sets that, in the onComputeInsets of the InputMethodService class, combined with the height of the view returned in onCreateInputView.
You actually can create a keyboard just for your app, but your users will hate you. You aren't going to write Swype functionality, or good autocorrect, or anything else without spending the years on it the other companies have.
What you seem to be describing is a full-screen editing situation called extract view where the keyboard takes over the full screen in landscape mode. THat's the standard Android experience for phones because too little of the screen is left for apps to be usable. Is that what you're seeing, or is it something else? If it is extract mode, try adding android:imeOptions="flagNoExtractUi" to the textview.
When typing in an EditText control - some autocomplete/autosuggest words are made available at the top of the control.
Like below:
I have a situation where the user should only be entering words from a pre-known set of existing words. As such it would improve the user experience to control the autosuggest list, and have only words from this list appear.
All my searches on this subject have turned up is suggestions to use AutoCompleteTextView for this purpose, however this is not 100% ideal - below is a screenshot of AutoCompleteTextView in action:
The suggestions show as a popup list, and the top of the on screen keyboard now has unnecessary blank spaces.
So while this sort of 'works' - it isn't a 100% ideal user experience, it will feel 'hacky' to the user, and not as native/seamlessly integrated with the android experience as it should be.
So my main question(s)
1) Is there a way to either have the AutoCompleteTextView show its suggestions at the top of the on screen keyboard?
2) Or even better/alternatively, is there a way to hook into the autosuggest/spelling feature of the on screen keyboard for EditText itself instead?
Yes, you can. InputMethodManager.displayCompletions will give the keyboard a list of possible completions. Depending on the keyboard, it should display those but it may ignore them. That's how ACTV works behind the scenes.
In my project , I use an editext for entering names and I require only a keyboard without number rows on the top. I would like to avoid the appearance of the number
row on top line of the keyboard. How to do it?
The decision as to whether or not to show a row of numbers on a soft keyboard is up to the implementer of the soft keyboard, not you. Some soft keyboards will always have it. Some will never have it.
The android:inputType attribute is where you provide a hint of what you want, that some soft keyboards may elect to honor. However, there is no inputType option for "all possible characters except numeric digits" or even "only letters". And, more generally, there is no option for you to say "well, I want the user to be able to enter digits, but please do not put those digits on the main keyboard, but instead have the user switch to some alternate layout to get those digits".
I'm trying to devise an input type for a field which will accept credit card numbers.
I had been using inputType="number" - but that won't let people with hardware keyboards hit the space bar.. when they do it jumps to another field in the activity.
I'd like to allow users to use a space in their numbers if they want, or, at least, make it so that if users with a hardware keyboard hit the space when I'm only allowing numbers it won't leave the credit card number EditText.
Ideally I'd be able to implement some interface and have my own custom inputType, but I'm not sure that's possible.
Is it possible to allow numbers and spaces, while showing the numbers soft keyboard?
The best choise is InputType.TYPE_CLASS_DATETIME
How about android:inputType="phone" in your layout xml file?
I don't have a definitive answer for you but here are some resources I picked up:
I found this clue to "catch" hard key presses: "To intercept hard keys, override InputMethodService.onKeyDown()". Read from bottom heading "Intercepting hard key events".
If you can't find a way to intercept and deal with the "space" key, I would suggest using a normal TextView and manually opening the number keyboard rather than the qwerty one (Go here for more info on general Input Reference). You can then validate key pressed from the hard keyboard.
Sorry I couldn't give you a more solid answer!
I have an OpenGL application that needs to show the soft keyboard for devices without physical ones for user input such as username or numbers in a few cases. In the case of numeric input, is there any way to show the numeric keypad instead of the alphabetic keyboard? I'm not using any text edit fields or anything, just the InputMethodManager:
((InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE)).showSoftInput(glView, InputMethodManager.SHOW_FORCED);
The only method I've found that looks remotely helpful is InputMethodManager.setInputMethod but that takes an IBinder token and a String id, neither of which is explained very well in the documentation. I get the impression that it's not the right way to go, though.
If I were using an edit field, it would be simple and obvious, and I've found dozens of answers for that, but that's not what I'm doing, because it's an OpenGL game, so I have to just displaying the keyboard manually as above.
Probably not the answer you are looking for since it is more of a hack than a real solution, but a few things come to mind that might work (that is if you can't get a real solution).
An EditText with View.INVISIBLE set. Although, you might not be able to set focus here.
Put an EditText behind your GLSurfaceView and focus it. So it’s technically visible (from a code standpoint) but invisible to the user.