Use Executor en lugar de handler para obtener más información Executor .
Para lograr el retraso posterior, use ScheduledExecutorService :

 ScheduledExecutorService worker = Executors.newSingleThreadScheduledExecutor(); Runnable runnable = () -> { public void run() { // Do something } }; worker.schedule(runnable, 2000, TimeUnit.MILLISECONDS);

Considere el uso de rutinas

 scope.launch { delay(3000L) // do stuff }

La función en desuso es ese constructor para Handler. Use Handler(Looper.myLooper()) .postDelayed(runnable, delay) en su lugar

Según el documento ( https://developer.android.com/reference/android/os/Handler#Handler() ):

La elección implícita de un Looper durante la construcción del controlador puede provocar errores en los que las operaciones se pierden silenciosamente (si el controlador no espera nuevas tareas y se cierra), bloqueos (si a veces se crea un controlador en un subproceso sin un Looper activo) o condiciones de carrera, donde el subproceso con el que está asociado un controlador no es lo que anticipó el autor. En su lugar, usa un Ejecutor o especifica el Looper explícitamente, usando Looper#getMainLooper, {link android.view.View#getHandler}, o similar. Si se requiere el comportamiento local del subproceso implícito para la compatibilidad, use el nuevo controlador (Looper.myLooper()) para dejarlo claro a los lectores.

Deberíamos dejar de usar el constructor sin un Looper y especificar un Looper en su lugar.

Si desea evitar el control nulo en Kotlin ( ? o !! ), puede usar Looper.getMainLooper() si su Handler está trabajando con algo relacionado con la interfaz de usuario, como este:

 Handler(Looper.getMainLooper()).postDelayed({ Toast.makeText(this@MainActivity, "LOOPER", Toast.LENGTH_SHORT).show() }, 3000)

Nota: use requireContext() en lugar de this@MainActivity si está usando fragment.

utilizar esta

 Looper.myLooper()?.let { Handler(it).postDelayed({ //Your Code },2500) }

El código handler() etc. lo genera Android Studio 4.0.1 cuando, por ejemplo, se crea desde cero una actividad de pantalla completa. Sé que se nos anima a usar Kotlin, lo cual hago, pero de vez en cuando uso proyectos de muestra para tener una idea. Parece extraño que AS nos castigue cuando AS realmente genera el código. Podría ser una actividad académica útil revisar los errores y corregirlos, pero tal vez AS podría generar un nuevo código limpio para nosotros, los entusiastas...

Solo el constructor sin parámetros está en desuso, ahora se prefiere que especifique el Looper en el constructor a través del método Looper.getMainLooper() .

Úsalo para Java

 new Handler(Looper.getMainLooper()).postDelayed(new Runnable() { @Override public void run() { // Your Code } }, 3000);

Úsalo para Kotlin

 Handler(Looper.getMainLooper()).postDelayed({ // Your Code }, 3000)

Proporcione un looper en el constructor de controladores

 Handler(Looper.getMainLooper())

Usar el alcance del ciclo de vida es más fácil. Actividad interior o fragmento.

 lifecycleScope.launch { delay(2000) // Do your stuff }

o usar el controlador

 Handler(Looper.myLooper()!!)

Respuesta Java

Escribí un método para usar fácilmente. Puede utilizar este método directamente en su proyecto. delayTimeMillis puede ser 2000, lo que significa que este código se ejecutará después de 2 segundos.

 private void runJobWithDelay(int delayTimeMillis){ new Handler(Looper.getMainLooper()).postDelayed(new Runnable() { @Override public void run() { //todo: you can call your method what you want. } }, delayTimeMillis); }

Yo suelo usar este

Código:

 Handler(Looper.myLooper() ?: return).postDelayed({ // Code what do you want }, 3000)

Captura de pantalla:

Corrutinas Kotlin

 private val SPLASH_SCREEN_TIME_OUT_CONST: Long = 3000 override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_splash) window.setFlags( WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN ) GlobalScope.launch { delay(SPLASH_SCREEN_TIME_OUT_CONST) goToIntro() } } private fun goToIntro(){ startActivity(Intent(this, IntroActivity::class.java)) finish() }

Si está utilizando Variable para Handler y Runnable, utilícelo así.

 private Handler handler; private Runnable runnable; handler = new Handler(Looper.getMainLooper()); handler.postDelayed(runnable = () -> { // Do delayed stuff here handler.postDelayed(runnable, 1000); }, delay);

También debe eliminar las devoluciones de llamada en onDestroy ()

 @Override public void onDestroy() { super.onDestroy(); if (handler != null) { handler.removeCallbacks(runnable); } }

Es buena idea usar esta estructura en Kotlin

 companion object Run { fun after(delay: Long, process: () -> Unit) { Handler(Looper.getMainLooper()).postDelayed({ process() }, delay) } }

Más tarde llamar como

 Run.after(SPLASH_TIME_OUT) { val action = SplashFragmentDirections.actionSplashFragmentToLogin() v.findNavController().navigate(action) }

Los constructores Handler() y Handler(Handler.Callback callback) están en desuso. Porque eso puede conducir a errores y fallas. Usa Executor o Looper explícitamente.

para Java

 Handler handler = new Handler(Looper.getMainLooper()); handler.postDelayed(new Runnable() { @Override public void run() { //do your work here } }, 1000);

Tengo 3 soluciones :

1. Especifique el Looper explícitamente:

    Handler(Looper.getMainLooper()).postDelay({ // code })

2. Especifique el comportamiento local del subproceso implícito:

    Handler(Looper.myLooper()!!).postDelay({ // code })

3. usando Thread :

    Thread({ try{ Thread.sleep(3000) } catch (e : Exception) { throw e } // code }).start() `

import android.os.Looper import android.os.Handler inline fun delay(delay: Long, crossinline completion: () -> Unit) { Handler(Looper.getMainLooper()).postDelayed({ completion() }, delay) }

Ejemplo:

 delay(1000) { view.refreshButton.visibility = View.GONE }