problem with Android requestFocus()

The below is the piece of code that i have written for transferring the focus from one edit text to another, but the problem that i got with this implementation is, the focus moves to the particular edit text, and suddenly moves to the next edit text.So, i could not able to enter anything , since the focus is not at all staying that particular edit text ..

//some code comes here
// gun_pistolNotes and gun_pistolModel are two diff. editText
......
......
    gun_pistolNotes.setOnEditorActionListener(new OnEditorActionListener(){
  开发者_如何学Python  @Override
    public boolean onEditorAction(TextView view,int actionId, KeyEvent event){
    if(actionId == EditorInfo.IME_ACTION_UNSPECIFIED){
        gun_pistolModel.requestFocus(); // moves to this edittext and suddenly moves to another editext 
        return true;
    }
    return false;
    }
  });

......
......
//some code comes here

Any Help is Appreciated.

Thanks in advance.

I realise this is an old question, but I was facing a similar issue & after hours of frustration, I found the problem, so just thought I should post it here in case someone else needs it.

In my code I realised that for some reason specifying android:inputype on my edittext was causing this "jumping" behaviour. So if I have EditText1 with android:inputType="textCapSentences" in the XML, calling requestFocus() on EditText1 causes it to get highlighted briefly before moving focus onto the next view.

I am not sure if this is a bug within Android or if it is indeed something else that I am missing. I tried setting inputType programmatically & within various points in my code, with setInputType() but it did not work for me. So for now I have just removed the inputType attribute & requestFocus() works as it should.

I am facing exactly the same problem. I can confirm Kre8's statement that this behaviour only occurs if there's set a specific input type (in my case textNoSuggestion / singleLine). I'll explain later why this probably is the case.

I decided to analyse what's going on inside the View. After all i can say it is not a bug just an unhappy constellation maybe :). The EditText for which you requested focus, correctly receives it.

Your first maybe unrecognized problem is, that the EditorActionListener is called twice. Once for key up and once for down. I don't know the effect of your check of the actionId, so that maybe preservers your code from being executed twice.

So i called wrongly in my solution request focus on ACTION_DOWN key event. The EditText received focus correctly, BUT on the coming ACTION_UP event, which is somehow interpreted by the newly focused EditText, focus was sent immediatly back to the previously sending focus EditText because it is in the focus search the next receiving.

So i guess now the input type has an effect because, if the EditText is in a multiline mode, the enter key will not send focus further.

My final working solution looks like that:

passwordEditText.setOnEditorActionListener(new OnEditorActionListener() {

  @Override
  public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
    if (event != null && event.getKeyCode() == KeyEvent.KEYCODE_ENTER && v == passwordEditText) {
      if (event.getAction() == KeyEvent.ACTION_UP) {
        if (userEditText.length() > 0 && passwordEditText.length() > 0) {
          login();
        }
        if (userEditText.length() == 0) {
          userEditText.requestFocus();
        }
      }
      return true;
    }
    return false;
  }
});

Hope it works for you as well :)

Edit: I forgot to point out, that the input type of the EditText can be choosen as you want, because the onEditorAction method handles both, up and down.

I found this worked reliably:

        field1Text.setOnEditorActionListener(new TextView.OnEditorActionListener() {
        @Override
        public boolean onEditorAction(TextView textView, int i, KeyEvent keyEvent) {
            if ((i == EditorInfo.IME_ACTION_UNSPECIFIED) && (keyEvent != null) &&
                    (keyEvent.getKeyCode() == KeyEvent.KEYCODE_ENTER)) {
                if (keyEvent.getAction() == KeyEvent.ACTION_DOWN) {
                    return true;
                }
                i = EditorInfo.IME_ACTION_DONE;
            }
            if (i == EditorInfo.IME_ACTION_DONE) {
                field2Text.requestFocus();
                return true;
            }
            return false;
        }
    });

This handles both keyboard enter and clicking on the action button in the virtual keyboard. The odd fall through logic is because I do some other things the requestFocus branch, which I omitted here because they're not part of the issue.

Android has always had builtin support for coding an "up/down/right/left" hierarchy to views. This was done originally for trackball devices like the G1. I don't think you've found a bug - but we could verify by looking at some SDK source. For people facing a similar problem, you might try calling setNext**Focus(...) on the View that needs to be "blurred", and then generating an event to move to the "next field down". This can be done both in XML and during runtime. Have you guys tried this?

See View#focusSearch(int) and View#setNext**Focus(int). The SDK suggests that in your onEditorAction(...) you could write something like:

... if (userEditText.length() == 0) { hostGameBtn.setNextFocusDownId(R.id.myUserEditTextViewID); hostGameBtn.focusSearch(View.FOCUS_DOWN); } ...