Reputation: 71
I'm currently trying to provide a intuitive interface for my application.
I have an oncreate function to activate the keyboard on load which works fine.
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.add_popup);
reminder = (CheckBox)findViewById(R.id.reminder_option);
addTask();
taskField = (EditText)findViewById(R.id.task_name);
taskField.setHorizontallyScrolling(true);
taskField.setOnFocusChangeListener(new View.OnFocusChangeListener() {
@Override
public void onFocusChange(View v, boolean focus) {
if (focus) {
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_VISIBLE);
}
}
});
taskField.requestFocus();
When the checkbox is clicked, the keyboard is dismissed
if(checked){
imm.hideSoftInputFromWindow(taskField.getWindowToken(), 2);
dateTitle.setVisibility(View.VISIBLE);
dateSelector.setVisibility(View.VISIBLE);
timeTitle.setVisibility(View.VISIBLE);
timeSelector.setVisibility(View.VISIBLE);
datetimesperator.setVisibility(View.VISIBLE);
I am using 2 inner classes, a TimePickerFragment and a DatePickerFragment both implementing the onDate/TimesetListener.
Now the problem is that when a time or date is set from the popups, the keyboard is reactivated.
I attempted a solution from Stop EditText from gaining focus at Activity startup
Where the layout is set focusable to remove focus from the edittext, I added the following code to the if checked statement. RelativeLayout layout = (RelativeLayout)findViewById(R.id.add_container); layout.requestFocus();
However after setting either the date or time, in the respective dialogs, the keyboard is still activated despite the focus being moved away from the edittext element.
How can I prevent the keyboard from being activated when exiting the DatePickerDialog or the TimePickerDialog?
Upvotes: 1
Views: 4969
Reputation: 49817
Focus on EditText's is tricky. To my knowledge there is no real way to prevent an EditText from gaining focus automatically. Your approach of requesting focus to a RelativeLayout seems to be the best solution for this problem - even if it is not a nice solution, feels more like a workaround.
My advice would be: If possible try to avoid these kind of scenarios, try to accomplish what you need to do for example with ClickListeners, as with these you don't have to deal with Views automatically assuming focus. But if there is no other solution, you have to be aware that you have to request focus on the RelativeLayout every time a view who should not recieve focus could get focus. Your code does not show how you handle dialogs so I can't directly help you out, but here you will find all the Information you need regarding dialogs: http://developer.android.com/guide/topics/ui/dialogs.html
Upvotes: 2