App Crashes while clicking on the area just above the eye icon in sign in

[asaikarthikeya]

Click on the background just above the eye icon, On the area where background contains Munster name. Same can be observed in sign up. Click on area where background contains Munster text, App crashes.

https://user-images.githubusercontent.com/70392921/136885819-7c340276-6131-4376-8641-e5ded2a7b72b.mp4

[asaikarthikeya]

@SebaDro I just found out that this happens with the whole background. Clicking on background of sign in and sign up, app crash. Are u able to reproduce this sir?

[SebaDro]

Yes, I could reproduce the issue. We' take it up.

[cdhiraj40]

@SebaDro I just found out that this happens with the whole background. Clicking on the background of sign in and sign up app crash. Are u able to reproduce this sir?

If you click on editText first (I.e. if edit text has focus then only) and then click on the background, it doesn't crash. don't know the reason why :/

[SebaDro]

Very weird^^. Would you like to work on it?

[cdhiraj40]

Very weird^^. Would you like to work on it?

I would sure like to work but from past days I just can't build the files because of Cannot resolve symbol 'DaggerBaseApplicationComponent' I have rebuild, cleaned, invalidate & restart but nothing seems to work :/ will still give more tries and If i find anything I will sure make a PR

[SebaDro]

That's strange, since the last CI build succesfully finished, yesterday: https://github.com/enviroCar/enviroCar-app/actions/runs/1337266143

[cdhiraj40]

That's strange, since the last CI build successfully finished, yesterday: https://github.com/enviroCar/enviroCar-app/actions/runs/1337266143

I have talked with @asaikarthikeya about this too and it seems like it's a problem from my side only :/

[asaikarthikeya]

@SebaDro With the current implementation we have onclick for the background to close the keyboard

@OnClick(R.id.signin_background)
    protected void closeKeyboard(){
        InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
        imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
    }

This method gives Null pointer exception when the edit text is not in focus.

Possible solution - https://stackoverflow.com/questions/7940765/how-to-hide-the-soft-keyboard-inside-a-fragment

[asaikarthikeya]

That's strange, since the last CI build successfully finished, yesterday: https://github.com/enviroCar/enviroCar-app/actions/runs/1337266143

I have talked with @asaikarthikeya about this too and it seems like it's a problem from my side only :/

Ya..Kindly follow the steps that i have mentioned to you in the personal Mail. That might work. Thanks :)

[cdhiraj40]

@SebaDro With the current implementation we have onclick for the background to close the keyboard

@OnClick(R.id.signin_background)
    protected void closeKeyboard(){
        InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
        imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
    }

This method gives Null pointer exception when the edit text is not in focus.

Possible solution - https://stackoverflow.com/questions/7940765/how-to-hide-the-soft-keyboard-inside-a-fragment

we can use dispatch event directly in the parent activity which can take care of fragments too. I will soon share the code here as I'm unable to test myself

[SebaDro]

@SebaDro With the current implementation we have onclick for the background to close the keyboard

@OnClick(R.id.signin_background)
    protected void closeKeyboard(){
        InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
        imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
    }

This method gives Null pointer exception when the edit text is not in focus.

Possible solution - https://stackoverflow.com/questions/7940765/how-to-hide-the-soft-keyboard-inside-a-fragment

Your link provides an explanation for hiding the keyboard within an fragment, but in this case, we only have an activity. A simple solution would be to check, if any view is focussed, before closing the keyboard, such as:

View view = this.getCurrentFocus();
if (view != null) {
  // do hiding keyboard stuff
}

However, now I'm curious about the solution of @cdhiraj40 ;-)

[cdhiraj40]

@SebaDro With the current implementation we have onclick for the background to close the keyboard

@OnClick(R.id.signin_background)
    protected void closeKeyboard(){
        InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
        imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
    }

This method gives Null pointer exception when the edit text is not in focus. Possible solution - https://stackoverflow.com/questions/7940765/how-to-hide-the-soft-keyboard-inside-a-fragment

Your link provides an explanation for hiding the keyboard within an fragment, but in this case, we only have an activity. A simple solution would be to check, if any view is focussed, before closing the keyboard, such as:

View view = this.getCurrentFocus();
if (view != null) {
  // do hiding keyboard stuff
}

However, now I'm curious about the solution of @cdhiraj40 ;-)

oh, thanks for saying that :) so I have many solutions for this and (I don't know why my master branch code is working even with the error and I just copied the code of signInActivity and yes it was crashing so I tried it and all are working fine :) ) so here are some solutions: 1) I like to use dispatch event as once override in activity it can handle the fragments too but one disadvantage the keyboard keeps on opening whenever we click on editText

    @Override
    public boolean dispatchTouchEvent(MotionEvent ev) {
        if (getCurrentFocus() != null) {
            InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
            imm.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
        }
        return super.dispatchTouchEvent(ev);
    }

2) now this is where the good stuff comes as the 2nd one is a little complex took me a lot of time to understand (my maths is a little weak) how it was working. The only Disadvantage it has is the focus from editText doesn't go (yes I have solution for that too)

@Override
    public boolean dispatchTouchEvent(MotionEvent event) {
        View view = getCurrentFocus();
        boolean ret = super.dispatchTouchEvent(event);

        if (view instanceof EditText) {
            View w = getCurrentFocus();
            int screenCoords[] = new int[2];
            w.getLocationOnScreen(screenCoords);
            float x = event.getRawX() + w.getLeft() - screenCoords[0];
            float y = event.getRawY() + w.getTop() - screenCoords[1];

            if (event.getAction() == MotionEvent.ACTION_UP
                    && (x < w.getLeft() || x >= w.getRight()
                    || y < w.getTop() || y > w.getBottom()) ) {
                InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
                imm.hideSoftInputFromWindow(getWindow().getCurrentFocus().getWindowToken(), 0);
            }
        }
        return ret;
    } 

I just got fond of this feature after seeing it in enviroCar app so I saw many people's code on stack overflow and understood :) And yeah I have tested both code and its working (but under master branch if any of you can just test under develop branch, pretty sure there wont be any differences I would like to make PR for this :)

https://user-images.githubusercontent.com/75211982/137298344-af6a5e4e-abd0-4377-b20d-ceb9e87bce2d.mp4

[SebaDro]

Ok, I understand that the dispatchEvent approach has advantages when it comes to handle different fragments in one activity. However, we have a working and stable solution in those fragments that needs to hide the keyboard when clicking outside the editText field. In addition, your second code sample seems very overelaborated for implementing such a simple action.

Therefore, I'd prefer the existing approach because it is more straightforward. So I'd suggest to only add a null check for the view you want to hide the keyboard from.

[cdhiraj40]

Ok, I understand that the dispatchEvent approach has advantages when it comes to handle different fragments in one activity. However, we have a working and stable solution in those fragments that needs to hide the keyboard when clicking outside the editText field. In addition, your second code sample seems very overelaborated for implementing such a simple action.

Therefore, I'd prefer the existing approach because it is more straightforward. So I'd suggest to only add a null check for the view you want to hide the keyboard from.

yeah, you are correct, and checking null works perfectly fine :) I just checked it. if you would like I can make PR and get the error resolved.

[SebaDro]

Yeah, do it 😃

[cdhiraj40]

@asaikarthikeya @SebaDro as I'm unable to run the latest app can you confirm if signUp activity is not crashing as there is the same hide keyboard condition

[SebaDro]

Yes, I can confirm

[cdhiraj40]

Yes, I can confirm

so should I still add it? I guess it's better to have a check, as you say :)

[SebaDro]

Your PR is ok as it is

[SebaDro]

@asaikarthikeya @SebaDro as I'm unable to run the latest app can you confirm if signUp activity is not crashing as there is the same hide keyboard condition

I'm sorry, you meant the SignUpActivity instead of SignInActivity. Yes, the SignUpActivity also needs a fix.

[SebaDro]

Fixed by #846

[cdhiraj40]

@SebaDro @asaikarthikeya can we create an issue for just discussion about adding new features or simply for comments on the app? I wanted to propose --> issue template, PR template, and many more :)

[asaikarthikeya]

@cdhiraj40 Hello Dhiraj, Things such as PR template,issue template are handled by the internal org members. Not open to external contributors at this moment. We would definetly like to here your new ideas, so donot hesistate to create an issue if you have a new feature/ bug in your mind. Work only after it is approved by any mentor ;)

[SebaDro]

Hi @cdhiraj40. We introduced our new contributing guidelines in the develop branch: https://github.com/enviroCar/enviroCar-app/blob/develop/CONTRIBUTING.md

Have a look on it, there are also some basic guidelines for reporting issues and creating pull requests. In the future, maybe, we will also allow discussions about new ideas using GitHub Discussions. But up to now, however, we did not activate it, yet.

[asaikarthikeya]

Merged into the master branch!