I recently had a bug where my small EditText was ballooning up to fill whatever space wasn't consumed by the soft keyboard. But only in Landscape mode.
I posted this and got a quick response from a helpful StackOverflow member that I needed to add android:imeOptions="flagNoExtractUi", so I did and it worked!
But I still don't understand it. The documentation says that it's "Used to specify that the IME does not need to show its extracted text UI" OK, what's that? The "search developer docs" feature of http://developer.android.com shows the phrase "Extracted text UI" used 34 times in their documentation but I didn't notice a definition.
Could someone please explain what it is, and why it only affects Landscape mode? Thanks in advance.
In landscape mode, by default, the Input Method Editor (IME) gets control of the full screen when editing text. The idea is that there isn't enough room "vertically" on the landscape screen to show anything other than the EditText and the soft keyboard when editing something longer (e.g. an e-mail message).
The UI in question is here:
http://developer.android.com/reference/android/inputmethodservice/ExtractEditText.html
When you use that flag in a TextView in your app , it suppresses the creation of an ExtractedTextView at the top of the IME when it is in "full screen" mode. When in "full screen" mode, the keyboard (the IME) is allowed to fill the screen and cover the app's TextView which the user is trying to edit. If it asks for the full screen, it'll be given to it. This ExtractedTextView box shows the same hints appearing in the targeted TextView, and let's the user see their editing progress. That flag tells the IME not to generate the ExtractedTextView which might leave some room at the top of the keyboard to see your original TextView in the app.
The default implementation of an IME (keyboard) goes to full screen mode when in "landscape mode". It's regular size (about 1/3 of the screen height?) in "portrait mode". The ExtractedTextView is generated, by default, for "full screen" mode, unless you suppress it. I suspect that when you see your EditText "balloning", your actually looking at the ExtractedTextView of a "full screen" mode keyboard.
Related
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.
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.
Context:
I have a small EditText field in my Activity, and it needs to be small because there is a lot of another View's on this Activity. But the content most of times are very long, and the user have a bad experience typing long texts into a small field.
Question:
How i can always show the "Horizontal Keyboard" when the user click on the EditText, even if the user are at Vertical Orientation(portrait) ?
Example:
Here is a screenshot of the "Horizontal Keyboard" that i'm talking about:
Important:
Setting the orientation to horizontal, is not really necessary. If this same keyboard shown on the image above can be triggered even if you are using vertical orientation, it would be useful too.
Sorry, I don't have 50 reputation points for commenting. But this link is for a question where OP is trying to disable the full screen keyboard. Perhaps if it's possible to disable, probably you are able to force enable it.
Disabling the fullscreen editing view for soft keyboard input in landscape?
EDIT:
So, searching a little more, I came to the conclusion that you can't force the keyboard to enter in fullscreen mode. Unless you make a keyboard app of your own that works only in fullscreen. But still would need the user to activate it on the settings menu.
Anyway, I found this solution by a user: force fullscreen on edittext in android, the answer suggests creating an Activity just for writing (an Activity with only an EditText as it's layout). And calling this Activity with the startActivityForResult method. Thus returning the text entered by the user and placing it on the respective EditText (or whatever widget you are going to use for the text).
Again, hope it helps.
In the Google Maps app, there's a unique EditText that I'd like to reproduce. If you click "menu" then go to "directions", the "start point" field should begin with "My Location" as the text. The interesting part of this field is its behavior - you cannot edit "My Location" without completely deleting it first.
I have a few places where such behavior would be useful, but I can never quite fully reproduce this. There are three challenges involved with this behavior:
No matter what the user does, they cannot partially edit the field; it is always fully selected.
The keyboard directional keys, rather than moving around the EditText field, change focus.
When the user does choose to change the text, the behavior of #1 and #2 disappear and the field acts like a normal EditText.
Has anyone ever successfully reproduced this behavior?
Isn't it just a hint? Try setting
android:hint="My Location"
on the EditText in your layout resources.