I'm quite new to Android native development, and I'm trying to figure out how to customize the IME action buttons. I've looked at the Google documentation, but I can find very few information about the expected behaviour.
From the offical guide I understand that the keyboard action button can be configured using the attributes:
android:imeOptions can set the text/id of the button displayed near the space key to some pre-defined values (E.g. actionGo set the key label to Go and the id to 2)
android:imeActionLabel set the label of the button displayed inside the input area when the keyboard is fullscreen, usually in landscape mode. Can be set to any string value.
android:imeActionId same as previous but set the numeric Id passed to the callback method
But after some empiric attempts I've found different behaviour between API level 15 and next API levels.
I've set up a simple EditText element with the following attributes:
<EditText
...
android:imeOptions="actionGo"
android:imeActionLabel="Custom"
android:imeActionId="666"
android:inputType="text"/>
and I've checked the effect with the different API levels both in portrait and landscape mode. Here is the outcome.
API level 15 - 4.0.3
In portrait mode the key label is Go and the action id passed to the callback method is 2, accordingly to the imeOptions setting.
In landscape mode the key label/id is Go/2 as the portrait mode, while the button displayed in the input area is Custom/666, accordingly to the imeActionLabel and imeActionId attributes.
API level 16, 17 and 18 - 4.1.2, 4.2.2 and 4.3
Both in portrait and landscape mode the key and the button are displayed with Custom label and are bound to 666 id, ignoring imeOptions attribute.
This mismatch in the behaviour is quite annoying because:
with API level >= 16 you can't distinguish between key button and input area button
with API level = 15 you can't set any custom text for key button.
Do you know how to obtain this both in API 15 and 16+?
Or if there is a way to obtain a consistent behaviour across all (or at least a part of) the API versions?
Maybe I am missing something in the IME settings that can justify the different behaviour...
Thank you very much!
It's actually up to the input method app, not the Android framework itself, to decide what to do with the values you set.
The Android framework just passes the values you set through to the input method, which can then choose what buttons to show on the keyboard or an "extracted" EditText in full-screen view. The Android framework influences the EditorInfo in two ways:-
It passes it through EditorInfo.makeCompatible to ensure the values therein are compatible between the keyboard's and the app's targetApiVersions. At the moment this only affects some InputType values, not the editor action, but this could change if new editor actions (or completely new settings) are introduced.
It sets the default behaviour for the input method, including the behaviour around full-screen editors. If the input method chooses not to override this default behaviour, then it could end up with behaviour that's different between Android versions. Many keyboards do choose to set their own behaviour, in a way that's consistent between Android versions.
For that reason, it's not so simple to say that a certain EditorInfo field has a certain effect on any given version, and there's no way to ensure a consistent behaviour, even on one Android version. All you're doing is providing hints to the input method, which chooses how to present them to the user.
Just call .setImeActionLabel() programtically in java codes to set actionID (again) to your desired one.
editText.setImeActionLabel(getString(R.string.xxx), EditorInfo.IME_ACTION_GO);
When you start a new Android project, it provides a good hint to your question. There is an Activity called LoginActivity which you can create as a default login screen. This Activity will produce an EditText as so:
<EditText
android:id="#+id/password"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="#string/prompt_password"
android:imeActionId="#+id/login"
android:imeActionLabel="#string/action_sign_in_short"
android:imeOptions="actionUnspecified"
android:inputType="textPassword"
android:maxLines="1"
android:singleLine="true"/>
Now if you read the documentation, you would know that the imeOptions attribute allows you to specify additional actions for a text field. For example, the keyboard that pops up has an action on the bottom right corner like "Next". Using imeOptions you can select another action from a predefined list provided by Android. You can specify something like "actionSend" or "actionSearch".
Once you do that, in order you Activity, you can listen for that action using the setOnEditorActionListener event handler:
mPasswordView = (EditText) findViewById(R.id.password);
mPasswordView.setOnEditorActionListener(new TextView.OnEditorActionListener() {
#Override
public boolean onEditorAction(TextView textView, int id, KeyEvent keyEvent) {
if (id == R.id.login || id == EditorInfo.IME_NULL) {
attemptLogin();
return true;
}
return false;
}
});
Notice how we target the imeActionId here. It is another method to target that EditText in your Activity, while also having the flexibility to change the action on the keyboard input.
If someone is designing a custom keyboard for Android and has a problem with the label of the Enter key, you should do the following. In the sample of Android custom keyboard we have the following method in SoftKeyboard.java:
#Override
public void onStartInput(EditorInfo attribute, boolean restarting)
{
super.onStartInput(attribute, restarting);
.
. // the implementation
.
mCurKeyboard.setImeOptions(getResources(), attribute.imeOptions);
}
Change the last line to the following line:
mCurKeyboard.setImeOptions(getResources(), attribute);
Now in LatinKeyboard.java change setImeOptions method like bellow:
void setImeOptions(Resources res, EditorInfo ei)
{
if (mEnterKey == null)
{
return;
}
switch (ei.imeOptions & (EditorInfo.IME_MASK_ACTION | EditorInfo.IME_FLAG_NO_ENTER_ACTION))
{
case EditorInfo.IME_ACTION_SEND:
mEnterKey.iconPreview = null;
mEnterKey.icon = null;
mEnterKey.label = res.getText(R.string.label_send_key);
break;
case EditorInfo.IME_ACTION_GO:
mEnterKey.iconPreview = null;
mEnterKey.icon = null;
mEnterKey.label = res.getText(R.string.label_go_key);
break;
case EditorInfo.IME_ACTION_NEXT:
mEnterKey.iconPreview = null;
mEnterKey.icon = null;
mEnterKey.label = res.getText(R.string.label_next_key);
break;
case EditorInfo.IME_ACTION_SEARCH:
mEnterKey.icon = res.getDrawable(R.drawable.sym_keyboard_search);
mEnterKey.label = null;
break;
default:
mEnterKey.iconPreview = null;
mEnterKey.label = res.getText(R.string.label_enter_key);
mEnterKey.icon = null;
break;
}
if (ei.actionLabel != null)
{
mEnterKey.iconPreview = null;
mEnterKey.icon = null;
mEnterKey.label = ei.actionLabel;
}
}
Now your custom keyboard shows proper label based on what is defined in xml file for imeActionLabel.
Related
In a current fullscreen opengl based project I work on, I have some GL based graphical elements, notably a text entry field. For the use to enter text when this element has the focus, I display the soft keyboard (which appears fine).
On android version before 5.0, the Google Keyboard was working fine, sending key events like for hardware keyboards. On android Lollipop, some other keyboards like Swiftkey or the free Hacker's keyboard are still working, but the Google Keyboard isn't anymore.
When pressing a key on the Google Keyboard on Lollipop, no visual feedback appears on the keyboard itself and my application receives the touch events as if the keyboard was not shown (but it is). The 'hardware' back key works fine though.
The view used in the app is a SurfaceView (and it's not a TextView). I've overridden onCheckIsTextEditor and I return a specific InputConnection from onCreateInputConnection where I've set the inputType to be TYPE_NULL.
Note that onCreateInputConnection doesn't seem to be called.
This app is compiled with android level 15 compatibility.
Any idea what would prevent the keyboard to accept touch events?
What should I do to debug the touch events flow?
I finally found a workaround to my problem, even though I don't really understand exactly why it works. This solution is partially based on what Cocos2d-x does for input on Android.
I created an android EditText (actually a class than inherits EditText in which I overrode onKeyUp and onKeyDown, this is to track focus and the back key).
Instead of having the SurfaceView the sole element of the activity, I created a layout that has the fake edit text in the background (but not fullscreen), and the SurfaceView on top:
private FrameLayout setupView(View androidView)
{
ViewGroup.LayoutParams framelayout_params = new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT);
frameLayout = new FrameLayout(this);
getFrameLayout().setLayoutParams(framelayout_params);
ViewGroup.LayoutParams edittext_layout_params = new ViewGroup.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT);
edittext = new FakeEditText(this);
edittext.setLayoutParams(edittext_layout_params);
// make sure this edit text is not fullscreen
edittext.setImeOptions(EditorInfo.IME_FLAG_NO_FULLSCREEN | EditorInfo.IME_FLAG_NO_EXTRACT_UI);
// ...add to FrameLayout
frameLayout.addView(edittext);
frameLayout.addView(androidView);
return frameLayout;
}
I also added a TextWatcher linked to the fake edit text, this is mainly to capture the text entered by the user and send it back to the GL based edit text I have on the SurfaceView (in my case, when the afterTextChanged method is called, I transform the received characters to internal keydown/keyup events that are routed to my GL control).
When the virtual keyboard needs to be shown (for example when the GL text field has focus), I set the fake edit text content from the GL text field content, and attach this TextWatcher to the fake edit text, and attach the virtual keyboard to the android fake edit text.
// Control is the base class of my GL controls
private void uiShowVirtualKeyboard(Control control)
{
if (fakeEdit.requestFocus()) {
// textWrapper is our TextWatcher
fakeEdit.removeTextChangedListener(textWrapper);
fakeEdit.setText("");
// get the text from the GL Text entry
final String text = control.getTextContent();
// and make sure it's in the android EditText at start
fakeEdit.append(text);
// listen to user changes
fakeEdit.addTextChangedListener(textWrapper);
// show the virtual keyboard
InputMethodManager imm = (InputMethodManager) fAndroidActivity.getSystemService(Context.INPUT_METHOD_SERVICE);
imm.showSoftInput(fakeEdit, InputMethodManager.SHOW_FORCED);
}
}
I had exactly the same problem. Google keyboard did no show up correctly and passed touch input through it's buttons.
As it turned out Google keyboard was not happy with the default settings of EditorInfo class passed into onCreateInputConnection for a view. If you fill in at least imeOptions field and leave the rest to their default values it will work, even if you return null from the function.
In order to fix it i've added these lines to my SurfaceView subclass:
#Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
outAttrs.inputType = InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS | InputType.TYPE_TEXT_VARIATION_SHORT_MESSAGE | InputType.TYPE_CLASS_TEXT;
outAttrs.imeOptions = EditorInfo.IME_FLAG_NO_EXTRACT_UI | EditorInfo.IME_FLAG_NO_FULLSCREEN;
return super.onCreateInputConnection(outAttrs);
}
I have a EditText component, and, of course, if you click on it, the Android keypad is shown, allowing the user to input text. As far as I know, all Android software keyboards have (at least) a letter mode (ABC) and a symbols mode (?123). Their default view is the letter mode.
Now when the keypad is shown when the EditText component is clicked, I want the symbols mode to be shown by default. The user will still be able to switch to the letter mode.
Is there a way to achieve that? If yes, how?
I'm posting this because I don't think any of the answers actually address the question. The screenshot in the question does not correspond to a particular InputType's default state. So, switching InputTypes will not give you the layout from the screenshot.
(based on my research...)
Support for symbol input is not governed by any contract. One can very well leave symbols out when creating their own InputMethod. OR, they can add pagination support to provide access to 100s of symbols. Can this be bound by a contract? May be. But, it isn't at present.
Input method framework does not allow direct communication between the client and the IME. All communication happens either through the InputMethodManager or through InputConnection — a one-way channel. Switching to symbols using ?123 is, however, an internal event — not a defined state/action. Client applications cannot switch to it. There's no public (or hidden) API to make this happen.
InputType indicates something entirely different to an IME. Not sure why everyone is recommending its use. You may of course find that a particular InputType provides most of the required keys. But that isn't the same as show[ing] Android keyboard with symbols mode by default.
Possible workaround:
We'll create a custom EditText. We don't have to. It'll just keep everything in one place, and save us from copy-paste nightmare.
public class CusEditText extends EditText {
private final int mDefinedActionId;
public CusEditText(Context context, AttributeSet attrs) {
super(context, attrs);
// Corresponds to 'android:imeActionId' value
mDefinedActionId = getResources().getInteger(R.integer.definedActionId);
setOnEditorActionListener(new OnEditorActionListener() {
#Override
public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
Log.i("CusEditText", "onEditorAction, actionId = " + actionId);
// Only bother if (...)
if (actionId == mDefinedActionId) {
// Check if current InputType is NUMBER
if ((getInputType() & InputType.TYPE_CLASS_NUMBER) != 0) {
// Toggle
setImeActionLabel("NUM", mDefinedActionId);
setInputType(InputType.TYPE_CLASS_TEXT);
} else {
// Current InputType is TEXT // Toggle
setImeActionLabel("ABC", mDefinedActionId);
setInputType(InputType.TYPE_CLASS_NUMBER);
}
// We've handled this
return true;
}
// Let someone else worry about this
return false;
}
});
}
}
Next, we need to define definedActionId. Open or create res/values/integers.xml and add:
<integer name="definedActionId">-100</integer>
-100 is an arbitrary value. I checked EditorInfo and the actionIds (IME_ACTION_XXXX) were >= 0. -100 seems like a good candidate.
In xml, your layout will look like:
<com.your.packagename.CusEditText
android:layout_width="blah"
android:layout_height="blah"
android:inputType="number"
android:imeActionId="#integer/definedActionId"
android:imeActionLabel="ABC"/>
<!-- Probably use #string resource in place of ABC -->
There's not much to explain. IME will launch in NUMBER mode. Instead of a checkmark icon, it'll display ABC. On click, we intercept the actionId and toggle between NUMBER and TEXT input. We're using setInputType(...) because it not only updates the InputType, it also restarts the IME with changes. setRawInputType(...) only updates the InputType.
Issues:
As you can tell, this isn't really a solution. If the user closes the keyboard(using the back button) in TEXT mode, the keyboard will remain in the TEXT mode when they open it again. To go to the NUMBER mode, user will have to click NUM. Also, in TEXT mode, user will see NUM as the action, along with ?123 option. This doesn't break anything, but does take away from the UX.
We can't do anything about ?123 showing in TEXT mode for reasons listed above. But, we can try to make sure that the keyboard always opens in the NUMBER mode. I'll provide a rough sketch of how we'll do that. Its not straight-forward since we (developers) are not privy to events such as keyboard closing or opening. Updated CusEditText:
public class CusEditText extends EditText {
private final int mDefinedActionId;
private long mLastEditorActionTime = 0L;
public CusEditText(Context context, AttributeSet attrs) {
super(context, attrs);
// Corresponds to 'android:imeActionId' value
mDefinedActionId = getResources().getInteger(R.integer.definedActionId);
setOnEditorActionListener(new OnEditorActionListener() {
#Override
public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
Log.i("CusEditText", "onEditorAction, actionId = " + actionId);
// Only bother if (...)
if (actionId == mDefinedActionId) {
// setInputType(...) will restart the IME
// and call finishComposingText()
// see below
mLastEditorActionTime = SystemClock.elapsedRealtime();
// Check if current InputType is NUMBER
if ((getInputType() & InputType.TYPE_CLASS_NUMBER) != 0) {
// Toggle
setImeActionLabel("NUM", mDefinedActionId);
setInputType(InputType.TYPE_CLASS_TEXT);
} else {
// Current InputType is TEXT // Toggle
setImeActionLabel("ABC", mDefinedActionId);
setInputType(InputType.TYPE_CLASS_NUMBER);
}
// We've handled this
return true;
}
// Let someone else worry about this
return false;
}
});
}
#Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
InputConnection inputConnection = super.onCreateInputConnection(outAttrs);
return new CusInputConnectionWrapper(inputConnection, false);
}
private class CusInputConnectionWrapper extends InputConnectionWrapper {
private CusInputConnectionWrapper(InputConnection target, boolean mutable) {
super(target, mutable);
}
#Override
public boolean finishComposingText() {
Log.i("CICW", "finishComposingText");
// Ignore finishComposingText for 1 second (1000L)
if (SystemClock.elapsedRealtime() - mLastEditorActionTime > 1000L) {
if ((getInputType() & InputType.TYPE_CLASS_NUMBER) == 0) {
// InputConnection is no longer valid.
// Switch back to NUMBER iff required
setImeActionLabel("ABC", mDefinedActionId);
setInputType(InputType.TYPE_CLASS_NUMBER);
}
}
return super.finishComposingText();
}
}
}
Again, code is self-explanatory. We create a InputConnectionWrapper and listen for the finishComposingText() callback. If we're manually switching between TEXT and NUMBER, we use a flag since finishComposingText() will automatically be called. Else, we check if input type is set to TEXT and change it to NUMBER. I am not sure if finishComposingText() is the right method for interpreting keyboard closing/opening. Testing on API 21, vanilla android, this seems to work. More tests will be required.
I really hope someone can come up with a better, more robust solution than this - or modify my workaround so that it doesn't look like one.
Summary
Task at hand is to provide functionality of switching between NUMBER & TEXT input modes around existing Input Method Engines (IMEs). The first approach was to use imeActionLabel & imeActionId in the switching mechanism. This approach worked well with Google's keyboard (this is the imeActionLabel), but failed with Samsung's - imeActionLabel failed to show up in portrait (without extract). Possible workaround is to include the toggle button in the app's own UI.
Even with Google's keyboard, the letters (text) fail to show up when the mode switches back to NUMBER after inputting letters. This problem was fixed (at least on tested devices) by using flag flagNoExtractUi which prevents the IME from entering fullscreen mode in landscape orientation.
Final solution (pending implementation & testing)
The IME starts in the NUMBER input mode (95% use-cases involve number input)
A button is added to app's UI (next to the EditText) for switching between NUMBER & TEXT mode
User can switch from NUMBER to TEXT without any restrictions. Switching back from TEXT to NUMBER requires that no alphabets have been added.
InputType is preserved between keyboard closing & reopening. Example: If the user switches to TEXT mode and closes the keyboard, it will open in the TEXT mode. The InputType is not reset.
For more information about the approaches tried, refer to this discussion thread.
Screenshots
Default (NUMBER):
Switched to TEXT:
Recorded video link
I agree it is an InputType. If you want to show only numbers to your user then you would add the following to you xml document for your edit text:
android:inputType="number"
However if you set it as number then the user has to enter a number. But you can add additional types as well like numbers and email addresses such as:
android:inputType="number|textEmailAddress"
Check out http://developer.android.com/reference/android/text/InputType.html for more options. You can also check out what eclipse or android studio shows you under "inputType"
I believe you are looking to set the InputType of your edit text.
http://developer.android.com/reference/android/text/InputType.html
I'm not sure which you would use though you may have to play around a bit.
The only way to do this is by setting the inputType of your EditText.
If you want to set this property in the onCreate() (or inside a custom View's constructor) you can use the method setRawInputType():
mEditText.setRawInputType(InputType.TYPE_CLASS_NUMBER | InputType.TYPE_NUMBER_FLAG_DECIMAL);
Otherwise, if you need to set this property after the onCreate() (or after a custom View's constructor), you can use the method setInputType():
mEditText.setInputType(InputType.TYPE_CLASS_NUMBER | InputType.TYPE_NUMBER_FLAG_DECIMAL);
Obviously you can also specify the property at XML level:
android:inputType="number|numberDecimal"
You can play around with different flags to find the best composed filter.
Programmatically it is possible with little bit of tweak to the usual flow. First you have to set editText as:
editText.setInputType(InputType.TYPE_CLASS_NUMBER);
Then you have to listen for keyevent. On pressing of pound set the InputType again to InputType.TYPE_CLASS_TEXT. This should work as it works for me.
editText.setOnKeyListener(new View.OnKeyListener()
{
#Override
public boolean onKey(View v, int keyCode, KeyEvent event) {
// TODO Auto-generated method stub
Log.d("KeyBoard", "Keyboard Test Key Hit");
switch (keyCode) {
KeyEvent.KEYCODE_POUND:
if(editText.setInputType(InputType.TYPE_CLASS_TEXT);
{
editText.setInputType(InputType.TYPE_CLASS_TEXT);
return true;
}
Same thing I've answered i: EditText with number keypad by default, but allowing alphabetic characters
Hi I'm making custom dialer so I create my own input pad.
The problem is how do I disable the EditText but still allow cut/copy/paste? The stock dialer can do this.
I have tried android:focusable="false" but it disables cut/copy (can still paste though).
I also tried to disable the inputType programatically which disables all three commands:
myEditText.setInputType(InputType.TYPE_NULL); //Can't cut/copy/paste
Disabling it from manifest also doesn't work:
android:configChanges="orientation|keyboardHidden" //Keyboard still popped up
Any solution? Thanks
After hours and hours of research, I finally found a solution that works for all API versions. Hope this saves someone's time.
If you are developing for API >= 11, the solution is simple, either:
1) Add the two properties below in the xml file of EditText
android:inputType="none"
android:textIsSelectable="true"
or
2) Programatically do the below
myEditText.setInputType(InputType.TYPE_NULL);
myEditText.setTextIsSelectable(true);
And you're done.
If you want to cater for API < 11 as well, I found that there is no way to disable to keyboard from popping out if you wanted to select the text for copy paste purpose. Setting focusable to false will disable the keyboard but it doesn't help because it disables your ability to select text too. Any other solutions I found in stackoverflow all either doesn't work or disables text selection at the same time too.
One ugly way to solve this is as such..
First, add this property in the xml file of EditText
android:editable="false"
Yes this is deprecated, but necessary for making the EditText not editable in API version < 11.
Next, we will need to hide the keyboard as soon as it shows up, so that we can continue selecting text without the keyboard blocking the way.
Use this code below to detect keyboard showing up (solution obtained from https://stackoverflow.com/a/9108219/1241783), and hide it immediately.
if (android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.HONEYCOMB)
{
final View activityRootView = findViewById(R.id.activityRoot);
activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
Rect r = new Rect();
//r will be populated with the coordinates of your view that area still visible.
activityRootView.getWindowVisibleDisplayFrame(r);
int heightDiff = activityRootView.getRootView().getHeight() - (r.bottom - r.top);
if (heightDiff > 100) { // if more than 100 pixels, its probably a keyboard...
//Hide the keyboard instantly!
if (getCurrentFocus() != null)
{
InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
}
}
}
});
}
It works for my case. Though you can see the keyboard showing up in a split second (which is the ugly part) but I can't think of any other way to get this to work at the time of writing. If you have a better solution, please leave a comment!
Let me know too if this saves someone's time :)
To disable the soft keyboard showing, keeping the copy/paste and cursor functionality, just add this line in your activity:
getWindow().setFlags(WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM,
WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM);
Since the current top answer uses a deprecated method and didn't have the paste method for me, here's another way that doesn't use old methods. But, it does try to use a hidden method via reflection with a fallback. =)
I've subclassed EditText into a new widget called KeyboardlessEditText that still retains all the cool editing features without the keyboard showing. Just drop the file in and go.
The full code is a little long for this post, but as long as GitHub doesn't go down, then this will work: https://github.com/danialgoodwin/android-widget-keyboardless-edittext/blob/master/KeyboardlessEditText2.java
To disable system keyboard automatic pop up for EditText or TextView do the following:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
editTextView.setShowSoftInputOnFocus(false);
} else {
editTextView.setTextIsSelectable(true);
//N.B. Accepting the case when non editable text will be selectable
}
I had the same problem but later I also wanted allow typing after double tap.. after hours and hours of searching I found working solution (at least for me). Use this in your onCreate method:
editText.setCursorVisible(false);
editText.setTextIsSelectable(true);
editText.setShowSoftInputOnFocus(false);
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN); // This just hide keyboard when activity starts
These lines should definitely do the trick.. and if you want to revert that use this:
editText.setCursorVisible(true);
editText.setShowSoftInputOnFocus(true);
To show keyboard again use:
private void showSoftKeyboard(View view) {
InputMethodManager inputMethodManager = (InputMethodManager) getSystemService(INPUT_METHOD_SERVICE);
view.requestFocus();
inputMethodManager.showSoftInput(view, 0);
}
To allow copy/paste next time just use these three lines:
editText.setCursorVisible(false);
editText.setTextIsSelectable(true);
editText.setShowSoftInputOnFocus(false);
For further keyboard hide use:
private void hideSoftKeyboard() {
if(getCurrentFocus() != null) {
InputMethodManager inputMethodManager = (InputMethodManager) getSystemService(INPUT_METHOD_SERVICE);
inputMethodManager.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
}
}
This code is working on API >= 21
try this
EditText et = ... // your EditText
et.setKeyListener(null) //makes the EditText non-editable so, it acts like a TextView.
No need to subclass. The main difference between this and making your EditText non-focusable, is that the EditText still has its own cursor - you can select text, etc. All it does is suppress the IME from popping up its own soft keyboard.
Had a similar need due to my custom inline "fake" input which was still visible as the os soft keypad was appearing after focus moved to an edit text.
Solution was to make the edit text hide soft input until the previous custom input widget had finished its edit lifecycle.
Used #Bruce's answer for inspiration, also saw a few related posts which I'll attach at end.
Solution I found worked was:
fun setInputType(inputType: Int) {
getEditText().setRawInputType(inputType)
if (inputType == InputType.TYPE_NULL) {
getEditText().setTextIsSelectable(true)
getEditText().isCursorVisible = true
}
}
had to use setRawInputType() instead as multiline text input was not respected when setting from InputType.TYPE_NULL back to InputType.TYPE_TEXT_FLAG_MULTI_LINE.
Seems there are users reporting issues relating to calling setInputType(InputType.TYPE_NULL). see:
https://issuetracker.google.com/issues/36907992
other useful related posts:
How to make EditText not editable through XML in Android?
EditText non editable
Well, here's the deal:
I'm creating an app which contains some device-specific settings (in this case sweep2wake), but i need it only to appear if the value in the build.prop ro.product.device is saga, pyramid or endeavoru.
I already have a layout file with more buttons in it. (just 3 plain buttons with intents)
When the button appears it is supposed to be an intent to a new activity onclick. (but i can handle that.)
How does one do that?
if (System.getProperty("ro.product.device", "bollocks").equals("saga") ||
System.getProperty("ro.product.device", "bollocks").equals("pyramid") ||
System.getProperty("ro.product.device", "bollocks").equals("endeavoru")) {
myDopeButton.setVisiblity(View.VISIBLE);
}
I have a game that uses a callback to Java from C++ to force open the soft keyboard when the user touches the screen. The Java code is simply this:
this._inputMethodManager.toggleSoftInput(InputMethodManager.SHOW_FORCED, 0);
This has worked fine for a while but recently we've been receiving complaints from some Motorola Droid users that the soft keyboard fails to open for them. Since we've only recently started to get these complaints and it's a number of users I'm thinking it was some kind of update to those devices.
Is there a better way I can force the keyboard to open? All the links I find online talk about using textbox controls and such but my app is primarily C++ and doesn't use the standard controls at all.
I don't know if this is related to your problem, but I was running into some issues using only InputMethodManager.toggleSoftInput() when devices would sometimes get "out of sync" and hide when I wanted to show and vice versa.
I've had some success by taking advantage of the fact that while IMM.showSoftInput() won't show a keyboard, IMM.hideSoftInputFromWindow() will reliably close one, so when I want to show a keyboard I now call IMM.hideSoftInputFromWindow() followed by IMM.toggleSoftInput(), and use IMM.hideSoftInputFromWindow() by itself to hide one.
[A day later...]
Writing the above yesterday made me rethink how I was dealing with the soft keyboard (I mean, showSoftinput() does work, just not the way we expected it to) and so here is a better way to do it:
First, you need to set up your view so that Android knows it can have a soft keyboard - described in the docs for InputMethodManager. In my case I have a single view derived from GLSurfaceView and so I added:
setFocusable(true);
setFocusableInTouchMode(true);
to the constructor and then the following 2 overrides:
#Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs)
{
outAttrs.actionLabel = "";
outAttrs.hintText = "";
outAttrs.initialCapsMode = 0;
outAttrs.initialSelEnd = outAttrs.initialSelStart = -1;
outAttrs.label = "";
outAttrs.imeOptions = EditorInfo.IME_ACTION_DONE | EditorInfo.IME_FLAG_NO_EXTRACT_UI;
outAttrs.inputType = InputType.TYPE_NULL;
return new BaseInputConnection(this, false);
}
#Override
public boolean onCheckIsTextEditor ()
{
return true;
}
Now I can show the keyboard with:
InputMethodManager mgr = (InputMethodManager)mActivity.getSystemService(Context.INPUT_METHOD_SERVICE);
mgr.showSoftInput(mView, 0);
and the keypresses get reported via the view's onKeyUp() and onKeyDown() methods.
Hiding it is still done using hideSoftInputFromWindow()