Custom keyboard words suggestion - android

Is there a way I can change the suggestions the keyboard shows for autocompletion of a word? I want to maintain a separate dictionary in the app and when the user types in the EditText he should be shown suggestions from that dictionary.

For changing the suggestions, you will have to implement your own keyboard. This is not what you want to do I believe.
The simplest option for you is to use AutoCompleteTextView for showing user the suggestions. Looks something like the following:

After reading several posts, I understood it can not be done without implementing my own keyboard. So, I ended up implementing a layout for displaying suggestions over the keyboard.(i.e. at the bottom of the activity view). When the keyboard shows up it automatically comes over the keyboard.
First, I turned off the default suggestions in the EditText using
edittext.setInputType(InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS);
Then for detecting if the keyboard is displaying or not:
myActivityView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
int heightDiff = myActivityView.getRootView().getHeight() - myActivityView.getHeight();
if (heightDiff > 180) {
// if more than 180 then its a keyboard
showSuggestions();
}else{
//keyboard gone...
// hide suggestion layout
}
}
});
I added a 100ms delay so that the keyboard hides its default suggestion layout, in case it is displaying.
private void showSuggestions(){
myActivityView.postDelayed(new Runnable() {
#Override
public void run() {
mySuggestionLayout.setVisibility(View.VISIBLE);
}
}, 100);
}

There is a tutorial on the Android Development website, which explains this. See the link here: http://developer.android.com/guide/topics/search/adding-custom-suggestions.html

Related

requestFocus() for EditText not working on devices running android P (API 28)

I am using EditText's to accept an OTP, where user has focus on next EditText once he enters a digit to a field and so. It works fine on all devices. But on devices running android OS P i.e. API 28, requestFocus() does not work, and user is not able to enter digits to consecutive EditTexts as focus doesn't move automatically.
Here is the code - by default all EditText's are disable to prevent from opening system keyboard. I am using my own CustomKeybaord to accept numbers. However it works except Android P.
mEtCode1.addTextChangedListener(new TextWatcher() {
#Override
public void beforeTextChanged(CharSequence charSequence, int i, int i1, int i2) {
Log.d("BEFORE_", charSequence.toString());
}
#Override
public void onTextChanged(CharSequence charSequence, int i, int i1, int i2) {
hideError(charSequence.toString());
if (!charSequence.toString().isEmpty()) {
mEtCode2.requestFocus();
mEtCode1.setBackground(getResources().getDrawable(R.drawable.verify_code_edit_text_background));
mEtCode2.setBackground(getResources().getDrawable(R.drawable.verify_code_edit_text_background));
mEtCode1.setEnabled(false);
}
}
#Override
public void afterTextChanged(Editable editable) {
}
});
Please help me with this
Thank you, in advance
I had the same issue with my OTP screen on devices with Android P sdk. The problem was that i set the height and width of the editText to 0dp, which is focus disabling in android P,
as described in Android Developer page in the Android P change log:
android-9.0-changes-28#ui-changes
Views with 0 area (either a width or a height is 0) are no longer focusable.
This is issue with Android P. And what worked for me is the following code block, So sharing here:
enterOtpTextFrame.postDelayed(Runnable {
enterOtpTextFrame.requestFocus()
}, 100
)
we require to call requestFocus with postDelayed with some small time amount. In my case it is 100 millisecond.
Here is the official documentation for requestFocus method. It states there that it only works if the desired view for which you want to have focus is enabled, has size, is visible, is focusable and is FocusableInTouchMode.
I had exact same issue. I was using databinding to set the enable state of my EditText. I realised that requestFocus was not working because databinding, due to some unknown reasons, was not enabling my textview in time.
Here is my code:
/*
setMyEditTextEnabled is my method to which my view is binded i.e.
android:enabled="#{vm.myEditTextEnabled, default=false}"
This worked for all version except Android P because it has
some timing issues with API 28 (not sure what)
*/
//binding.getVm().setMyEditTextEnabled(true);
/*
So to make it work, I am enabling my EditText directly and
it works for all versions.
*/
binding.myEditText.setEnabled(true);
binding.myEditText.requestFocus();
Also, as mentioned in following post: EditText requestFocus not working
Do set focusable and focusableInTouchMode to true as well.
In short, my point is to make sure that your edit text is fulfilling all requirements as mentioned in official doc in order to requestFocus to work.
Encountered a similar problem when popping an alert dialog. In my case, postDelayed'ing a focus request or forcing the soft keyboard to pop up didn't work. Even if I could manage to pop up the keyboard, the focus stayed on an EditText in the main activity; needless to say I have tried clearing its focus and even disabling it.
However, popping the alertDialog delayed did the trick:
final AlertDialog alertDialog = alertDialogBuilder.create(); //a builder of your own
final Runnable r = new Runnable() {
public void run() {
alertDialog.show();
}
};
editTextOnMainActivity.postDelayed(r, 100);

How to detect the keyboard on the android window - Titanium Appcelerator

I need something to verify the existence of the keyboard in the window of an android app ... The problem is I can not test the focus / blur the input, and need that check for keyboard ... I see the official documentation Appcelerator and this functionality is only for iOS ... does anyone have a solution?
KeyboardVisible property for iOS:
http://docs.appcelerator.com/platform/latest/#!/api/Titanium.App-property-keyboardVisible
As you can see in the official docs there is no native way to detect if the keyboard is visible; if you need to show the keyboard when the user open the window, add a listener to 'open' and 'resume' (this one is from the activity, not the window, and is triggered also when your app go from the background to the foreground) for a function that focus your field, if you need to know when the keyboard is open to change the layout, android already try to fit it for you (in this case, place everything inside of a scrollview).
On iOS you can listen to the keyboardframechanged event. For Android, you might be able to use one of these modules.
There is no any direct way to do this. but some trick may be work. try this.
final View activityRootView = findViewById(R.id.activityRoot);
activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
int heightDiff = activityRootView.getRootView().getHeight() - activityRootView.getHeight();
if (heightDiff > 100) { // if more than 100 pixels, its probably a keyboard...
... do something here
}
}
});

How does Facebook app handle layout changes when keyboard appears?

Facebook app is just amazingly handling UI changes at login screen. Check it out.
No keyboard
With keyboard (notice how need help? and English Change views disappear)
Yes, I do know about the adjustPan and adjustResize settings, but how does Facebook set exactly which views will be visible when keyboard is present?
Seems like they are showing/hiding specific text (such as need help or English in example above), when Soft keyboard becomes visible.
Now, in Android, there is No direct way to detect if soft keyboard is visible or not.
Why?
Below is the Answer from Android framework Engineer.
The IME being shown has little meaning, since exactly how the IME
behaves is up to it -- it may be a transparent overlay and not impact
the application, a small strip, or all other kinds of things.
Due to this, the main way you interact with the IME is by setting your
softInputMode to be resizeable so when the IME says it wants to
occlude part of the screen your app's UI will get resized to take that
into account if needed.
But, there are different ways/methods/workarounds by using which Apps (like Facebook) could potentially detect if Soft keyboard is visible or not and based on the outcome, app could show/hide texts/widgets in it's UI.
Method 1:
InputMethodManager imm = (InputMethodManager) getActivity()
.getSystemService(Context.INPUT_METHOD_SERVICE);
if (imm.isAcceptingText()) {
//soft keyboard is shown, so hide "need help" text, for example
} else {
//Software Keyboard was not shown;
}
Method 2:
final View activityRootView = findViewById(R.id.activityRoot);
activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(
new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
int heightView = activityRootView.getHeight();
int widthView = activityRootView.getWidth();
if (1.0 * widthView / heightView > 3) {
//Make changes for Keyboard not visible
} else {
//Make changes for keyboard visible
}
}
});
Now both Above mentioned methods does not necessarily works 100% in every situations (as one can expect from non-supported operation way out of SDK)
Facebook may be using any of the above method or who knows, they may have implemented it in different way!
editText.setOnFocusChangeListener(new OnFocusChangeListener() {
#Override
public void onFocusChange(View v, boolean hasFocus) {
// view/hide whatever you want depending on the hasFocus value
// hasFocus == true -> keyboard shown
}
});
edittext.post(new Runnable() {
public void run() {
edittext.requestFocusFromTouch();
InputMethodManager lManager = (InputMethodManager) activity
.getSystemService(Context.INPUT_METHOD_SERVICE);
lManager.showSoftInput(edittext, 0);
}
});

Disable soft-keyboard from EditText but still allow copy/paste?

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

Android - Detect visible keyboard?

Is it possible to detect whether a keyboard is visible on the screen or not?
Thanks
I think this thread should answer your question. To summarize, you can give your activity's root view an id, such as "#+id/activityRoot", and then hook a GlobalLayoutListener into the ViewTreeObserver for that view. In the listener is where you check the visibility of the keyboard, like so:
final View activityRootView = findViewById(R.id.activityRoot);
activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
if (getResources().getConfiguration().keyboardHidden == Configuration.KEYBOARDHIDDEN_NO) { // Check if keyboard is not hidden
// ... do something here
}
}
});
This is a combination of #Reuben_Scratton and #Yogesh's answers in the above thread.
UPDATE:
Note that the documentation for keyboardHidden says it will ALWAYS return Configuration.KEYBOARDHIDDEN_YES if there is a hard keyboard available on the device(i.e. like a Motorola Droid 1 & 2)
try this or this workaround since its not possible within "simple" sdk method invocation
You might try something along the lines of this:
InputMethodManager imm =
(InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
boolean showingKeyboard = imm.isActive();
Hope this helps!
EDIT:
The other option is simply to force the keyboard open or closed, depending on what you want the user to see :) This would lead to more predictable use behavior and likely improve the user experience.

Categories

Resources