OnTimeSet también se llama al descartar TimePickerDialog
Hoy estaba tratando de usar el TimePickerDialog
pero me di cuenta de un par de defectos.
- OnTimeSet se llama también cuando el diálogo se descarta (haciendo clic fuera, por ejemplo)
- OnTimeSet se llama dos veces cuando el usuario pulsa el botón "Listo"
La API que estoy usando es 18.
- ¿Cómo se utilizan los skins personalizados de Datepicker y Timepicker?
- Android TimePickerDialog set max time
- Android: Establecer el tiempo en el selector de tiempo con el tiempo mostrado en la vista de texto
- ¿Cómo agregar timePicker usando fragmento?
- ¿Cómo configurar el TimePickerDialog a 24 horas?
¿Alguien más ha experimentado estos problemas? Como los resolviste?
- Android: ¿cómo tener este tipo de selección de tiempo?
- Cómo establecer un intervalo de minutos personalizado en TimePickerDialog en Android
- ¿Cambiar el título en un TimePicker?
- ¿Cómo implementar android Minutos-Segundos selector?
- Android: TimePicker setIs24HourView no funciona
- ¿Cómo implementar el cordova-plugin-datepicker para Android?
- Obtener el valor del selector de fecha y hora a partir de un solo fragmento de diálogo y establecerlo en EditText
- Android - ¿Cómo puedo cambiar el textColor en un TimePicker?
Frente a la misma cuestión hoy. No podía entender por qué sucedía esto, pero encontró una solución simple:
El método onTimeSet () se llama una vez cuando se descarta el diálogo y se llama dos veces cuando se hace clic en el botón Listo. De cualquier manera, hay una llamada no deseada a onTimeSet (). Así que decidí ignorar siempre la primera llamada.
Aquí está el código:
Calendar mcurrentTime = Calendar.getInstance(); int hour = mcurrentTime.get(Calendar.HOUR_OF_DAY); int minute = mcurrentTime.get(Calendar.MINUTE); TimePickerDialog mTimePicker; mTimePicker = new TimePickerDialog(MainActivity.this, new TimePickerDialog.OnTimeSetListener() { int callCount = 0; //To track number of calls to onTimeSet() @Override public void onTimeSet(TimePicker timePicker, int selectedHour, int selectedMinute) { if(callCount == 1) // On second call { timeString = selectedHour + ":" + selectedMinute + ":00"; Log.d("TEST", "Chosen time : "+ timeString); } callCount++; // Incrementing call count. } }, hour, minute, true); mTimePicker.setTitle("Pick Time"); mTimePicker.show();
Debería usar el método ya dado de la clase View:
new TimePickerDialog.OnTimeSetListener() { @Override public void onTimeSet(TimePicker view, int hour, int minute) { if (view.isShown()) { // This method will return true only once... } } };
Para reiterar: Este es un error confirmado en Android para varios tipos de diálogo. Ya se han sugerido dos soluciones, guardando el estado en una variable (de instancia) o preguntando al isShown()
diálogo si isShown()
. Pero isShown()
parece ser poco fiable en Android 4.0.4 y guardar el estado obtiene desordenado si desea volver a mostrar el diálogo.
Una mejor solución es guardar el estado dentro del propio Dialog, porque es la misma instancia que llama al método:
public void onDateSet(DatePicker picker, int year, int monthOfYear, int dayOfMonth) { if (picker.getTag() == null) { picker.setTag("TAGGED"); // Only gets called once per Dialog } }
Es limpio y eficaz.
Usar el recuento para evitarlo. Cuando se seleccionó TimePickDialog más de dos veces, también debería funcionar bien.
TimePickerDialog tpd = new TimePickerDialog(this, new TimePickerDialog.OnTimeSetListener() { int count = 0; @Override public void onTimeSet(TimePicker view, int setHour, int setMinute) { if(count % 2 == 0) { //set time here } count++; } }, hour, minute, true);
Gracias a Tony por publicar una solución. Esto funciona para la mayor parte del tiempo, pero no siempre. Habíamos liberado nuestra aplicación con esta solución (junto con controles de versiones); Sin embargo esta solución falló en Samsung Galaxy Note GT-8000 (Android 4.4.2). Default 4.4.2 los dispositivos tienen este error y la solución funciona sin embargo Samsung parece haber arreglado este problema en la versión 4.4.2 por lo que onTimeSet () se llama sólo una vez que ignoramos y segunda llamada nunca sucedió.
Estamos publicando una solución que aplicamos hoy. Aunque no estoy satisfecho con la solución, ya que es otro hack / solución, pero puede ayudar en situaciones en las que la comprobación de versión no ayuda y OEMs fusionar soluciones selectivas.
Nuestra implementación anterior
if((android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) && (android.os.Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP)){ if(ccount == 1){ // Do Your Processing count = 0; }else{ // Ignore event. Bug in Android API count++; } }else{ // Do Your Processing }
Nuestra nueva implementación es
if((android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) && (android.os.Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP)){ StackTraceElement[] stacktrace = Thread.currentThread().getStackTrace(); StackTraceElement e = stacktrace[4]; String methodName = e.getMethodName(); if(methodName.equals("onClick")){ // Do Your Processing }else{ // Ignore event. Bug in Android API } }else{ // Do Your Processing }
Espero que pueda ayudar a otros.
- ¿Qué adaptador debo usar para usar HashMap en un ListView
- ¿Cuándo se utiliza realmente el paquete savedInstanceState?