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.
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.
Just found myself trying to figure out this strange behavior in for EditText.
Information:
Bug seems to only happen in some devices! for now I've only seen it in Sony Xperia D2303.
App description:
I'm working on an app that has a main activity and navigation is done trough different fragments that are replaced as user moves from one section to another.
At one point I'm showing a DialogFragment with an edit text field, with background set to #null, with a hint text. (I have also tried with a normal edit text, taken from widget list and dragged to the layout and found the same behavior).
Problem:
When clicking on the EditText, software keyboard SHOWS UP but when typing there is no letter input in the EditText! I can long press, to visualize cursor position marker and also the magnifying glass shows up.
Things I've tried:
- I've tried requesting focus with xml, programmatically.
- Setting touchable(in touch mode also)
- Setting descendantFocusability attribute of parent to 'afterDescendants'
- Overriding onTouchListener and showing keyboard programmatically through the InputManager and using the edit text's token
… and maybe other things which I don't remember
There is but a workaround that I've found!!! sending the app to background, and bringing it to foreground again… so it seems something related to focus maybe?? but then why does keyboard show up, and cursor marker and magnifying glass work?
This solution does not work for me as it depends on the user taking action
Has anyone found this problem? any suggestions?
Thanks in advance!
in my app I disabled the keyboard (I use now my custom keyboard) using this code:
editText.setInputType(InputType.TYPE_NULL);
Now, my problem is that the text cursor does not appear anymore in the edit text. What should I do? Any suggestion would be very appreciated.
There is an Issue opened in bug tracker Issue opened in bug tracker for this.
One of the users suggests the approach which works on "most" devices.
Briefly, all you have to do is call:
editText.setRawInputType(InputType.TYPE_CLASS_TEXT);
for your EditText view (after you called editText.setInputType(InputType.TYPE_NULL);).
You should probably also set:
editText.setTextIsSelectable(true);
in order for text to be selectable (though in does not seem to work properly with Samsung Galaxy SIII). This method is only available starting from HONEYCOMB (api11) so keep that in mind when developing for older Android versions.
Also it is stated that your EditText should not be the first view to receive focus when activity starts (if it is - just requestFocus() from another view). Though I (personally) have not experienced any problems with this.
Rather than just using a custom view for your custom keyboard, why not implement a full-fledged IME? That will solve your cursor problem, and even make your keyboard available outside your app (if you want).
This answer has a couple useful links if you want to do that:
How to develop a soft keyboard for Android?
I really wouldn't suggest this. Writing a good full fledged IME is really hard. In addition, users come to expect functionality from their keyboard (auto-correct, Swyping, next word prediction, the ability to change languages) that you won't have unless you spend months on the keyboard itself. Any app that wouldn't allow me to use Swype would immediately be removed (bias note: I worked on Swype android).
But if you want to integrate fully with the OS as a keyboard, you're going to have to write an InputMethodService. Your keyboard would then be selectable by the user in the keyboard select menu, and usable for any app. That's the only way to get full OS integration, otherwise you'll need to really start from scratch- writing your own EditView. Have fun with that, getting one that looks nice is decidedly non-trivial.
Also, setting input type null won't disable most keyboards. It just puts them into dumb mode and turns off things like prediction.
I tried the below answer and it worked, but take care that
1) EditText must not be focused on initialization
2) when your orientation changes while the user's focus is on the editText, the stock keyboard pops up, which is another "solvable" problem.
This was mentioned in a previous answer but take care that you MUST make sure your editText element do not get focus on instantiation:
https://code.google.com/p/android/issues/detail?id=27609#c7
#7 nyphb...#gmail.com
I have finally found a (for me) working solution to this.
First part (in onCreate):
mText.setInputType(InputType.TYPE_NULL);
if (android.os.Build.VERSION.SDK_INT >= 11 /*android.os.Build.VERSION_CODES.HONEYCOMB*/) {
// this fakes the TextView (which actually handles cursor drawing)
// into drawing the cursor even though you've disabled soft input
// with TYPE_NULL
mText.setRawInputType(InputType.TYPE_CLASS_TEXT);
}
In addition, android:textIsSelectable needs to be set to true (or set in onCreate) and the EditText must not be focused on initialization. If your EditText is the first focusable View (which it was in my case), you can work around this by putting this just above it:
<LinearLayout
android:layout_width="0px"
android:layout_height="0px"
android:focusable="true"
android:focusableInTouchMode="true" >
<requestFocus />
</LinearLayout>
My app has an EditText that, when I click in it to enter text in the Emulator, brings up a soft keyboard. I don't want this confounded thing to begin with, but then, like the visiting loud-mouthed uncle in the plaid pants, doesn't want to go away, and it is blocking the button beneath it. How do I either (a) prorgrammatically prevent the soft keyboard from appearing or at least (b) evict it, albeit manually, when it pops up?
Provided that the user is not supposed to input text, but is able to click the EditText and then add text in some other way, you could change the EditText to a TextView and then apply the following three tags to it in the layout file:
style="#android:style/Widget.EditText"
android:editable="false"
android:focusableInTouchMode="false"
This will make it look like an EditText, but behave like a TextView.
Since you want the user to be able to write stuff in the EditText there are in my opinion two solutions:
Leave it be. To remove the keyboard, all you need is to hit the back button once and every Android user knows this. It's standard behaviour.
Wrap everything but the Button you say dissapears in a ScrollView. The ScrollView will then wrap its content to allow the Button to be shown in between the keyboard and the ScrollView.
Just set android:editable="false" for your EditText
The answer is to set the focus on an other View like a Button, TextView or similar:
// REQUEST FOCUS
viewName.setFocusableInTouchMode(true);
viewName.requestFocus();
I think what you really need is take a look at android:windowSoftInputMode attribute in Manifest.xml Look into this link.
You can specify the screen to pan/ resize to show the buttons that the input method might be blocking. Not allowing the keyboard to show will make the user unable to enter text at all!