¿Cómo manejar el cambio de orientación de la pantalla cuando el diálogo de progreso y el hilo de fondo están activos?

Mi programa realiza alguna actividad de red en un hilo de fondo. Antes de comenzar, aparece un cuadro de diálogo de progreso. El diálogo se descarta en el controlador. Todo esto funciona bien, excepto cuando la orientación de la pantalla cambia mientras el cuadro de diálogo está activo (y el hilo de fondo continúa). En este punto, la aplicación se bloquea o se interrumpe, o entra en una etapa extraña en la que la aplicación no funciona en absoluto hasta que se hayan eliminado todos los hilos.

¿Cómo puedo manejar el cambio de orientación de la pantalla con gracia?

El siguiente código de muestra coincide aproximadamente con lo que hace mi programa real:

public class MyAct extends Activity implements Runnable {
    public ProgressDialog mProgress;

    // UI has a button that when pressed calls send

    public void send() {
         mProgress = ProgressDialog.show(this, "Please wait", 
                      "Please wait", 
                      true, true);
        Thread thread = new Thread(this);
        thread.start();
    }

    public void run() {
        Thread.sleep(10000);
        Message msg = new Message();
        mHandler.sendMessage(msg);
    }

    private final Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            mProgress.dismiss();
        }
    };
}

Apilar:

E/WindowManager(  244): Activity MyAct has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@433b7150 that was originally added here
E/WindowManager(  244): android.view.WindowLeaked: Activity MyAct has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@433b7150 that was originally added here
E/WindowManager(  244):     at android.view.ViewRoot.<init>(ViewRoot.java:178)
E/WindowManager(  244):     at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:147)
E/WindowManager(  244):     at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:90)
E/WindowManager(  244):     at android.view.Window$LocalWindowManager.addView(Window.java:393)
E/WindowManager(  244):     at android.app.Dialog.show(Dialog.java:212)
E/WindowManager(  244):     at android.app.ProgressDialog.show(ProgressDialog.java:103)
E/WindowManager(  244):     at android.app.ProgressDialog.show(ProgressDialog.java:91)
E/WindowManager(  244):     at MyAct.send(MyAct.java:294)
E/WindowManager(  244):     at MyAct$4.onClick(MyAct.java:174)
E/WindowManager(  244):     at android.view.View.performClick(View.java:2129)
E/WindowManager(  244):     at android.view.View.onTouchEvent(View.java:3543)
E/WindowManager(  244):     at android.widget.TextView.onTouchEvent(TextView.java:4664)
E/WindowManager(  244):     at android.view.View.dispatchTouchEvent(View.java:3198)

Intenté descartar el cuadro de diálogo de progreso en onSaveInstanceState, pero eso solo evita un bloqueo inmediato. El subproceso de fondo aún continúa y la interfaz de usuario está en estado parcialmente dibujado. Necesita matar toda la aplicación antes de que comience a funcionar nuevamente.

Cuando cambie de orientación, Android creará una nueva vista. Probablemente te estés bloqueando porque tu hilo de fondo está tratando de cambiar el estado del anterior. (También puede estar teniendo problemas porque su hilo de fondo no está en el hilo de la interfaz de usuario)

Sugeriría hacer que mHandler sea volátil y actualizarlo cuando cambie la orientación.

Editar: los ingenieros de Google no recomiendan este enfoque, como lo describe Dianne Hackborn (también conocido como hackbod ) en esta publicación de StackOverflow . Mira esta publicación de blog para más información.

Debe agregar esto a la declaración de actividad en el manifiesto:

android:configChanges="orientation|screenSize"

entonces parece

<activity android:label="@string/app_name" 
        android:configChanges="orientation|screenSize|keyboardHidden" 
        android:name=".your.package">

El problema es que el sistema destruye la actividad cuando ocurre un cambio en la configuración. Ver cambios de configuración .

Poner eso en el archivo de configuración evita que el sistema destruya su actividad. En su lugar, invoca el onConfigurationChanged(Configuration)método.

Se me ocurrió una solución sólida para estos problemas que se ajusta a la 'forma Android' de las cosas. Tengo todas mis operaciones de larga duración utilizando el patrón IntentService.

Es decir, mis intentos actividades de difusión, el IntentService hace el trabajo, guarda los datos en la base de datos y luego difunde pegajosas intenciones. La parte adhesiva es importante, de modo que incluso si la Actividad se detuvo durante el tiempo después de que el usuario inició el trabajo y pierde la transmisión en tiempo real desde IntentService, aún podemos responder y recoger los datos de la Actividad que realiza la llamada. ProgressDialogs puede funcionar muy bien con este patrón onSaveInstanceState().

Básicamente, debe guardar un indicador de que tiene un cuadro de diálogo de progreso ejecutándose en el paquete de instancias guardadas. No guarde el objeto de diálogo de progreso porque esto filtrará toda la Actividad. Para tener un control persistente del diálogo de progreso, lo almaceno como una referencia débil en el objeto de la aplicación. En el cambio de orientación o cualquier otra cosa que haga que la Actividad se detenga (llamada telefónica, usuario llegue a casa, etc.) y luego se reanude, descarto el diálogo anterior y vuelvo a crear un diálogo nuevo en la Actividad recién creada.

Para diálogos de progreso indefinidos, esto es fácil. Para el estilo de barra de progreso, debe colocar el último progreso conocido en el paquete y cualquier información que esté utilizando localmente en la actividad para realizar un seguimiento del progreso. Al restaurar el progreso, utilizará esta información para volver a generar la barra de progreso en el mismo estado que antes y luego actualizar según el estado actual de las cosas.

Para resumir, colocar tareas de larga duración en un IntentService junto con un uso juicioso de le onSaveInstanceState()permite realizar un seguimiento eficiente de los diálogos y restaurarlos a lo largo de los eventos del ciclo de vida de la Actividad. Los bits relevantes del código de actividad están a continuación. También necesitará lógica en su BroadcastReceiver para manejar adecuadamente las intenciones de Sticky, pero eso está fuera del alcance de esto.

public void doSignIn(View view) {
    waiting=true;
    AppClass app=(AppClass) getApplication();
    String logingon=getString(R.string.signon);
    app.Dialog=new WeakReference<ProgressDialog>(ProgressDialog.show(AddAccount.this, "", logingon, true));
    ...
}

@Override
protected void onSaveInstanceState(Bundle saveState) {
    super.onSaveInstanceState(saveState);
    saveState.putBoolean("waiting",waiting);
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if(savedInstanceState!=null) {
        restoreProgress(savedInstanceState);    
    }
    ...
}

private void restoreProgress(Bundle savedInstanceState) {
    waiting=savedInstanceState.getBoolean("waiting");
    if (waiting) {
        AppClass app=(AppClass) getApplication();
        ProgressDialog refresher=(ProgressDialog) app.Dialog.get();
        refresher.dismiss();
        String logingon=getString(R.string.signon);
        app.Dialog=new WeakReference<ProgressDialog>(ProgressDialog.show(AddAccount.this, "", logingon, true));
    }
}

Me encontré con el mismo problema. Mi actividad necesita analizar algunos datos de una URL y es lenta. Entonces creo un hilo para hacerlo, luego muestro un diálogo de progreso. Dejo que el hilo publique un mensaje en el hilo de la interfaz de usuario Handlercuando esté terminado. En Handler.handleMessage, obtengo el objeto de datos (listo ahora) del hilo y lo relleno en la interfaz de usuario. Entonces es muy similar a tu ejemplo.

Después de muchas pruebas y errores, parece que encontré una solución. Al menos ahora puedo rotar la pantalla en cualquier momento, antes o después de que el hilo esté terminado. En todas las pruebas, el cuadro de diálogo se cierra correctamente y todos los comportamientos son los esperados.

Lo que hice se muestra a continuación. El objetivo es llenar mi modelo de datos ( mDataObject) y luego completarlo en la interfaz de usuario. Debe permitir la rotación de la pantalla en cualquier momento sin sorpresa.

class MyActivity {

    private MyDataObject mDataObject = null;
    private static MyThread mParserThread = null; // static, or make it singleton

    OnCreate() {
        ...
        Object retained = this.getLastNonConfigurationInstance();
        if(retained != null) {
            // data is already completely obtained before config change
            // by my previous self.
            // no need to create thread or show dialog at all
            mDataObject = (MyDataObject) retained;
            populateUI();
        } else if(mParserThread != null && mParserThread.isAlive()){
            // note: mParserThread is a static member or singleton object.
            // config changed during parsing in previous instance. swap handler
            // then wait for it to finish.
            mParserThread.setHandler(new MyHandler());
        } else {
            // no data and no thread. likely initial run
            // create thread, show dialog
            mParserThread = new MyThread(..., new MyHandler());
            mParserThread.start();
            showDialog(DIALOG_PROGRESS);
        }
    }

    // http://android-developers.blogspot.com/2009/02/faster-screen-orientation-change.html
    public Object onRetainNonConfigurationInstance() {
        // my future self can get this without re-downloading
        // if it's already ready.
        return mDataObject;
    }

    // use Activity.showDialog instead of ProgressDialog.show
    // so the dialog can be automatically managed across config change
    @Override
    protected Dialog onCreateDialog(int id) {
        // show progress dialog here
    }

    // inner class of MyActivity
    private class MyHandler extends Handler {
        public void handleMessage(msg) {
            mDataObject = mParserThread.getDataObject();
            populateUI();
            dismissDialog(DIALOG_PROGRESS);
        }
    }
}

class MyThread extends Thread {
    Handler mHandler;
    MyDataObject mDataObject;

    // constructor with handler param
    public MyHandler(..., Handler h) {
        ...
        mHandler = h;
    }

    public void setHandler(Handler h) { mHandler = h; } // for handler swapping after config change
    public MyDataObject getDataObject() { return mDataObject; } // return data object (completed) to caller

    public void run() {
        mDataObject = new MyDataObject();
        // do the lengthy task to fill mDataObject with data
        lengthyTask(mDataObject);
        // done. notify activity
        mHandler.sendEmptyMessage(0); // tell activity: i'm ready. come pick up the data.
    }
}

Eso es lo que me funciona. No sé si este es el método "correcto" diseñado por Android: afirman que esta "actividad de destruir / recrear durante la rotación de la pantalla" en realidad hace las cosas más fáciles, así que supongo que no debería ser demasiado complicado.

Avíseme si ve un problema en mi código. Como se dijo anteriormente, realmente no sé si hay algún efecto secundario.

El problema original percibido era que el código no sobreviviría a un cambio de orientación de la pantalla. Aparentemente, esto se "resolvió" haciendo que el programa manejara el cambio de orientación de la pantalla, en lugar de dejar que el marco de la interfaz de usuario lo hiciera (llamando a onDestroy).

Diría que si el problema subyacente es que el programa no sobrevivirá en Destroy (), entonces la solución aceptada es solo una solución que deja al programa con otros problemas y vulnerabilidades graves. Recuerde que el marco de Android establece específicamente que su actividad está en riesgo de ser destruida casi en cualquier momento debido a circunstancias fuera de su control. Por lo tanto, su actividad debe poder sobrevivir en onDestroy () y en onCreate () posterior por cualquier motivo, no solo un cambio de orientación de la pantalla.

Si va a aceptar manejar los cambios de orientación de la pantalla usted mismo para resolver el problema del OP, debe verificar que otras causas de onDestroy () no generen el mismo error. ¿Eres capaz de hacer esto? Si no, me preguntaría si la respuesta "aceptada" es realmente muy buena.

Mi solución fue extender la ProgressDialogclase para obtener la mía MyProgressDialog.
Redefiní show()y dismiss()métodos para bloquear la orientación antes de mostrarla Dialogy desbloquearla nuevamente cuando Dialogse descarta. Entonces, cuando Dialogse muestra y cambia la orientación del dispositivo, la orientación de la pantalla permanece hasta que dismiss()se llama, luego la orientación de la pantalla cambia de acuerdo con los valores del sensor / orientación del dispositivo.

Aquí está mi código:

public class MyProgressDialog extends ProgressDialog {
private Context mContext;

public MyProgressDialog(Context context) {
    super(context);
    mContext = context;
}

public MyProgressDialog(Context context, int theme) {
    super(context, theme);
    mContext = context;
}

public void show() {
    if (mContext.getResources().getConfiguration().orientation == Configuration.ORIENTATION_PORTRAIT)
        ((Activity) mContext).setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
    else
        ((Activity) mContext).setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
    super.show();
}

public void dismiss() {
    super.dismiss();
    ((Activity) mContext).setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR);
}

}

Me enfrenté a este mismo problema y se me ocurrió una solución que no se invocaba con ProgressDialog y obtengo resultados más rápidos.

Lo que hice fue crear un diseño que tiene una barra de progreso.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<ProgressBar
    android:id="@+id/progressImage"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerInParent="true"
    />
</RelativeLayout>

Luego, en el método onCreate, haga lo siguiente

public void onCreate(Bundle icicle) {
    super.onCreate(icicle);
    setContentView(R.layout.progress);
}

Luego haga la tarea larga en un hilo, y cuando termine, haga que Runnable configure la vista de contenido en el diseño real que desea usar para esta actividad.

Por ejemplo:

mHandler.post(new Runnable(){

public void run() {
        setContentView(R.layout.my_layout);
    } 
});

Esto es lo que hice, y descubrí que se ejecuta más rápido que mostrar el ProgressDialog y es menos intrusivo y tiene una mejor apariencia en mi opinión.

Sin embargo, si desea utilizar ProgressDialog, esta respuesta no es para usted.

Descubrí una solución a esto que aún no he visto en ningún otro lado. Puede usar un objeto de aplicación personalizado que sepa si tiene tareas en segundo plano en lugar de intentar hacer esto en la actividad que se destruye y se recrea en el cambio de orientación. Blogueé sobre esto aquí .

Voy a aportar mi enfoque para manejar este problema de rotación. Esto puede no ser relevante para OP ya que no lo está usando AsyncTask, pero tal vez otros lo encuentren útil. Es bastante simple pero parece hacer el trabajo por mí:

Tengo una actividad de inicio de sesión con una AsyncTaskclase anidada llamada BackgroundLoginTask.

En mi caso BackgroundLoginTask, no hago nada fuera de lo común, excepto agregar un cheque nulo al ProgressDialogdescartar la llamada :

@Override
protected void onPostExecute(Boolean result)
{    
if (pleaseWaitDialog != null)
            pleaseWaitDialog.dismiss();
[...]
}

Esto es para manejar el caso donde la tarea en segundo plano finaliza mientras Activityno está visible y, por lo tanto, el diálogo de progreso ya ha sido descartado por el onPause()método.

A continuación, en mi Activityclase principal , creo identificadores estáticos globales para mi AsyncTaskclase y mi ProgressDialog(el AsyncTask, anidado, puede acceder a estas variables):

private static BackgroundLoginTask backgroundLoginTask;
private static ProgressDialog pleaseWaitDialog;

Esto tiene dos propósitos: en primer lugar, me permite Activityacceder siempre al AsyncTaskobjeto, incluso desde una nueva actividad posterior a la rotación. En segundo lugar, me permite BackgroundLoginTaskacceder y descartar ProgressDialogincluso después de una rotación.

A continuación, agrego esto a onPause(), haciendo que el cuadro de diálogo de progreso desaparezca cuando nuestro Activityabandona el primer plano (evitando ese feo bloqueo de "cierre forzado"):

    if (pleaseWaitDialog != null)
    pleaseWaitDialog.dismiss();

Finalmente, tengo lo siguiente en mi onResume()método:

if ((backgroundLoginTask != null) && (backgroundLoginTask.getStatus() == Status.RUNNING))
        {
           if (pleaseWaitDialog != null)
             pleaseWaitDialog.show();
        }

Esto permite Dialogque reaparezca después de que se vuelve a Activitycrear.

Aquí está toda la clase:

public class NSFkioskLoginActivity extends NSFkioskBaseActivity {
    private static BackgroundLoginTask backgroundLoginTask;
    private static ProgressDialog pleaseWaitDialog;
    private Controller cont;

    // This is the app entry point.
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        if (CredentialsAvailableAndValidated())
        {
        //Go to main menu and don't run rest of onCreate method.
            gotoMainMenu();
            return;
        }
        setContentView(R.layout.login);
        populateStoredCredentials();   
    }

    //Save current progress to options when app is leaving foreground
    @Override
    public void onPause()
    {
        super.onPause();
        saveCredentialsToPreferences(false);
        //Get rid of progress dialog in the event of a screen rotation. Prevents a crash.
        if (pleaseWaitDialog != null)
        pleaseWaitDialog.dismiss();
    }

    @Override
    public void onResume()
    {
        super.onResume();
        if ((backgroundLoginTask != null) && (backgroundLoginTask.getStatus() == Status.RUNNING))
        {
           if (pleaseWaitDialog != null)
             pleaseWaitDialog.show();
        }
    }

    /**
     * Go to main menu, finishing this activity
     */
    private void gotoMainMenu()
    {
        startActivity(new Intent(getApplicationContext(), NSFkioskMainMenuActivity.class));
        finish();
    }

    /**
     * 
     * @param setValidatedBooleanTrue If set true, method will set CREDS_HAVE_BEEN_VALIDATED to true in addition to saving username/password.
     */
    private void saveCredentialsToPreferences(boolean setValidatedBooleanTrue)
    {
        SharedPreferences settings = getSharedPreferences(APP_PREFERENCES, MODE_PRIVATE);
        SharedPreferences.Editor prefEditor = settings.edit();
        EditText usernameText = (EditText) findViewById(R.id.editTextUsername);
        EditText pswText = (EditText) findViewById(R.id.editTextPassword);
        prefEditor.putString(USERNAME, usernameText.getText().toString());
        prefEditor.putString(PASSWORD, pswText.getText().toString());
        if (setValidatedBooleanTrue)
        prefEditor.putBoolean(CREDS_HAVE_BEEN_VALIDATED, true);
        prefEditor.commit();
    }

    /**
     * Checks if user is already signed in
     */
    private boolean CredentialsAvailableAndValidated() {
        SharedPreferences settings = getSharedPreferences(APP_PREFERENCES,
                MODE_PRIVATE);
        if (settings.contains(USERNAME) && settings.contains(PASSWORD) && settings.getBoolean(CREDS_HAVE_BEEN_VALIDATED, false) == true)
         return true;   
        else
        return false;
    }

    //Populate stored credentials, if any available
    private void populateStoredCredentials()
    {
        SharedPreferences settings = getSharedPreferences(APP_PREFERENCES,
            MODE_PRIVATE);
        settings.getString(USERNAME, "");
       EditText usernameText = (EditText) findViewById(R.id.editTextUsername);
       usernameText.setText(settings.getString(USERNAME, ""));
       EditText pswText = (EditText) findViewById(R.id.editTextPassword);
       pswText.setText(settings.getString(PASSWORD, ""));
    }

    /**
     * Validate credentials in a seperate thread, displaying a progress circle in the meantime
     * If successful, save credentials in preferences and proceed to main menu activity
     * If not, display an error message
     */
    public void loginButtonClick(View view)
    {
        if (phoneIsOnline())
        {
        EditText usernameText = (EditText) findViewById(R.id.editTextUsername);
        EditText pswText = (EditText) findViewById(R.id.editTextPassword);
           //Call background task worker with username and password params
           backgroundLoginTask = new BackgroundLoginTask();
           backgroundLoginTask.execute(usernameText.getText().toString(), pswText.getText().toString());
        }
        else
        {
        //Display toast informing of no internet access
        String notOnlineMessage = getResources().getString(R.string.noNetworkAccessAvailable);
        Toast toast = Toast.makeText(getApplicationContext(), notOnlineMessage, Toast.LENGTH_SHORT);
        toast.show();
        }
    }

    /**
     * 
     * Takes two params: username and password
     *
     */
    public class BackgroundLoginTask extends AsyncTask<Object, String, Boolean>
    {       
       private Exception e = null;

       @Override
       protected void onPreExecute()
       {
           cont = Controller.getInstance();
           //Show progress dialog
           String pleaseWait = getResources().getString(R.string.pleaseWait);
           String commWithServer = getResources().getString(R.string.communicatingWithServer);
            if (pleaseWaitDialog == null)
              pleaseWaitDialog= ProgressDialog.show(NSFkioskLoginActivity.this, pleaseWait, commWithServer, true);

       }

        @Override
        protected Boolean doInBackground(Object... params)
        {
        try {
            //Returns true if credentials were valid. False if not. Exception if server could not be reached.
            return cont.validateCredentials((String)params[0], (String)params[1]);
        } catch (Exception e) {
            this.e=e;
            return false;
        }
        }

        /**
         * result is passed from doInBackground. Indicates whether credentials were validated.
         */
        @Override
        protected void onPostExecute(Boolean result)
        {
        //Hide progress dialog and handle exceptions
        //Progress dialog may be null if rotation has been switched
        if (pleaseWaitDialog != null)
             {
            pleaseWaitDialog.dismiss();
                pleaseWaitDialog = null;
             }

        if (e != null)
        {
         //Show toast with exception text
                String networkError = getResources().getString(R.string.serverErrorException);
                Toast toast = Toast.makeText(getApplicationContext(), networkError, Toast.LENGTH_SHORT);
            toast.show();
        }
        else
        {
            if (result == true)
            {
            saveCredentialsToPreferences(true);
            gotoMainMenu();
            }
            else
            {
            String toastText = getResources().getString(R.string.invalidCredentialsEntered);
                Toast toast = Toast.makeText(getApplicationContext(), toastText, Toast.LENGTH_SHORT);
            toast.show();
            } 
        }
        }

    }
}

De ninguna manera soy un desarrollador experimentado de Android, así que siéntase libre de comentar.

Mueva la tarea larga a una clase separada. Impleméntelo como un patrón sujeto-observador. Cada vez que se crea la actividad, regístrese y, al cerrar, anule el registro con la clase de tarea. La clase de tarea puede usar AsyncTask.

El truco consiste en mostrar / descartar el diálogo dentro de AsyncTask durante onPreExecute / onPostExecute como de costumbre, aunque en caso de cambio de orientación cree / muestre una nueva instancia del diálogo en la actividad y pase su referencia a la tarea.

public class MainActivity extends Activity {
    private Button mButton;
    private MyTask mTask = null;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        MyTask task = (MyTask) getLastNonConfigurationInstance();
        if(task != null){
            mTask = task;
            mTask.mContext = this;
            mTask.mDialog = ProgressDialog.show(this, "", "", true);        
        }

        mButton = (Button) findViewById(R.id.button1);
        mButton.setOnClickListener(new View.OnClickListener(){
            public void onClick(View v){
                mTask = new MyTask(MainActivity.this);
                mTask.execute();
            }
        });
    }


    @Override
    public Object onRetainNonConfigurationInstance() {
        String str = "null";
        if(mTask != null){
            str = mTask.toString();
            mTask.mDialog.dismiss();
        }
        Toast.makeText(this, str, Toast.LENGTH_SHORT).show();
        return mTask;
    }



    private class MyTask extends AsyncTask<Void, Void, Void>{
        private ProgressDialog mDialog;
        private MainActivity mContext;


        public MyTask(MainActivity context){
            super();
            mContext = context;
        }


        protected void onPreExecute() {
            mDialog = ProgressDialog.show(MainActivity.this, "", "", true);
        }

        protected void onPostExecute(Void result) {
            mContext.mTask = null;
            mDialog.dismiss();
        }


        @Override
        protected Void doInBackground(Void... params) {
            SystemClock.sleep(5000);
            return null;
        }       
    }
}

Lo he hecho así:

    package com.palewar;
    import android.app.Activity;
    import android.app.ProgressDialog;
    import android.os.Bundle;
    import android.os.Handler;
    import android.os.Message;

    public class ThreadActivity extends Activity {


        static ProgressDialog dialog;
        private Thread downloadThread;
        final static Handler handler = new Handler() {

            @Override
            public void handleMessage(Message msg) {

                super.handleMessage(msg);

                dialog.dismiss();

            }

        };

        protected void onDestroy() {
    super.onDestroy();
            if (dialog != null && dialog.isShowing()) {
                dialog.dismiss();
                dialog = null;
            }

        }

        /** Called when the activity is first created. */
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.main);

            downloadThread = (Thread) getLastNonConfigurationInstance();
            if (downloadThread != null && downloadThread.isAlive()) {
                dialog = ProgressDialog.show(ThreadActivity.this, "",
                        "Signing in...", false);
            }

            dialog = ProgressDialog.show(ThreadActivity.this, "",
                    "Signing in ...", false);

            downloadThread = new MyThread();
            downloadThread.start();
            // processThread();
        }

        // Save the thread
        @Override
        public Object onRetainNonConfigurationInstance() {
            return downloadThread;
        }


        static public class MyThread extends Thread {
            @Override
            public void run() {

                try {
                    // Simulate a slow network
                    try {
                        new Thread().sleep(5000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    handler.sendEmptyMessage(0);

                } finally {

                }
            }
        }

    }

También puedes intentar y hacerme saber que funciona para ti o no

Si crea un fondo Serviceque hace todo el trabajo pesado (solicitudes / respuestas de tcp, desorganización), el Viewy Activitypuede ser destruido y recreado sin filtrar la ventana o perder datos. Esto permite el comportamiento recomendado de Android, que es destruir una Actividad en cada cambio de configuración (por ejemplo, para cada cambio de orientación).

Es un poco más complejo, pero es la mejor manera de invocar la solicitud del servidor, el procesamiento previo / posterior de datos, etc.

Incluso puede usar su Servicepara poner en cola cada solicitud a un servidor, por lo que es fácil y eficiente manejar esas cosas.

La guía de desarrollo tiene un capítuloServices completo sobre .

Tengo una implementación que permite que la actividad se destruya en un cambio de orientación de la pantalla, pero aún así destruye el diálogo en la actividad recreada con éxito. Utilizo ...NonConfigurationInstancepara adjuntar la tarea en segundo plano a la actividad recreada. El marco normal de Android maneja la recreación del diálogo en sí, no se cambia nada allí.

Subclase AsyncTask agregando un campo para la actividad 'propietaria' y un método para actualizar este propietario.

class MyBackgroundTask extends AsyncTask<...> {
  MyBackgroundTask (Activity a, ...) {
    super();
    this.ownerActivity = a;
  }

  public void attach(Activity a) {
    ownerActivity = a;
  }

  protected void onPostExecute(Integer result) {
    super.onPostExecute(result);
    ownerActivity.dismissDialog(DIALOG_PROGRESS);
  }

  ...
}

En mi clase de actividad, agregué un campo que hace backgroundTaskreferencia a la tarea de fondo "propiedad" y actualizo este campo con onRetainNonConfigurationInstancey getLastNonConfigurationInstance.

class MyActivity extends Activity {
  public void onCreate(Bundle savedInstanceState) {
    ...
    if (getLastNonConfigurationInstance() != null) {
      backgroundTask = (MyBackgroundTask) getLastNonConfigurationInstance();
      backgroundTask.attach(this);
    }
  }

  void startBackgroundTask() {
    backgroundTask = new MyBackgroundTask(this, ...);
    showDialog(DIALOG_PROGRESS);
    backgroundTask.execute(...);
  }

  public Object onRetainNonConfigurationInstance() {
    if (backgroundTask != null && backgroundTask.getStatus() != Status.FINISHED)
      return backgroundTask;
    return null;
  }
  ...
}

Sugerencias para seguir mejorando:

• Borre la backgroundTaskreferencia en la actividad después de que la tarea haya finalizado para liberar cualquier memoria u otros recursos asociados con ella.
• Borre la ownerActivityreferencia en la tarea de fondo antes de que la actividad se destruya en caso de que no se vuelva a crear de inmediato.
• Cree una BackgroundTaskinterfaz y / o colección para permitir que se ejecuten diferentes tipos de tareas desde la misma actividad propietaria.

Si mantiene dos diseños, todos los subprocesos de la interfaz de usuario deben terminarse.

Si usa AsynTask, puede llamar fácilmente al .cancel()método dentro del onDestroy()método de la actividad actual.

@Override
protected void onDestroy (){
    removeDialog(DIALOG_LOGIN_ID); // remove loading dialog
    if (loginTask != null){
        if (loginTask.getStatus() != AsyncTask.Status.FINISHED)
            loginTask.cancel(true); //cancel AsyncTask
    }
    super.onDestroy();
}

Para AsyncTask, lea más en la sección "Cancelar una tarea" aquí .

Actualización: condición agregada para verificar el estado, ya que solo se puede cancelar si está en estado de ejecución. También tenga en cuenta que AsyncTask solo se puede ejecutar una vez.

Intenté implementar la solución de jfelectron porque es una " solución sólida para estos problemas que se ajusta a la" forma de Android "de las cosas ", pero llevó un tiempo buscar y reunir todos los elementos mencionados. Terminé con esta solución ligeramente diferente, y creo que más elegante, publicada aquí en su totalidad.

Utiliza un IntentService disparado desde una actividad para realizar la tarea de ejecución larga en un hilo separado. El servicio devuelve Intenciones de difusión fijas a la actividad que actualiza el diálogo. La Actividad usa showDialog (), onCreateDialog () y onPrepareDialog () para eliminar la necesidad de que se pasen datos persistentes en el objeto de la aplicación o el paquete savedInstanceState. Esto debería funcionar sin importar cómo se interrumpa su aplicación.

Clase de actividad:

public class TesterActivity extends Activity {
private ProgressDialog mProgressDialog;
private static final int PROGRESS_DIALOG = 0;

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    Button b = (Button) this.findViewById(R.id.test_button);
    b.setOnClickListener(new OnClickListener() {
        public void onClick(View v) {
            buttonClick();
        }
    });
}

private void buttonClick(){
    clearPriorBroadcast();
    showDialog(PROGRESS_DIALOG);
    Intent svc = new Intent(this, MyService.class);
    startService(svc);
}

protected Dialog onCreateDialog(int id) {
    switch(id) {
    case PROGRESS_DIALOG:
        mProgressDialog = new ProgressDialog(TesterActivity.this);
        mProgressDialog.setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
        mProgressDialog.setMax(MyService.MAX_COUNTER);
        mProgressDialog.setMessage("Processing...");
        return mProgressDialog;
    default:
        return null;
    }
}

@Override
protected void onPrepareDialog(int id, Dialog dialog) {
    switch(id) {
    case PROGRESS_DIALOG:
        // setup a broadcast receiver to receive update events from the long running process
        IntentFilter filter = new IntentFilter();
        filter.addAction(MyService.BG_PROCESS_INTENT);
        registerReceiver(new MyBroadcastReceiver(), filter);
        break;
    }
}

public class MyBroadcastReceiver extends BroadcastReceiver{
    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.hasExtra(MyService.KEY_COUNTER)){
            int count = intent.getIntExtra(MyService.KEY_COUNTER, 0);
            mProgressDialog.setProgress(count);
            if (count >= MyService.MAX_COUNTER){
                dismissDialog(PROGRESS_DIALOG);
            }
        }
    }
}

/*
 * Sticky broadcasts persist and any prior broadcast will trigger in the 
 * broadcast receiver as soon as it is registered.
 * To clear any prior broadcast this code sends a blank broadcast to clear 
 * the last sticky broadcast.
 * This broadcast has no extras it will be ignored in the broadcast receiver 
 * setup in onPrepareDialog()
 */
private void clearPriorBroadcast(){
    Intent broadcastIntent = new Intent();
    broadcastIntent.setAction(MyService.BG_PROCESS_INTENT);
    sendStickyBroadcast(broadcastIntent);
}}

Clase IntentService:

public class MyService extends IntentService {

public static final String BG_PROCESS_INTENT = "com.mindspiker.Tester.MyService.TEST";
public static final String KEY_COUNTER = "counter";
public static final int MAX_COUNTER = 100;

public MyService() {
  super("");
}

@Override
protected void onHandleIntent(Intent intent) {
    for (int i = 0; i <= MAX_COUNTER; i++) {
        Log.e("Service Example", " " + i);
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        Intent broadcastIntent = new Intent();
        broadcastIntent.setAction(BG_PROCESS_INTENT);
        broadcastIntent.putExtra(KEY_COUNTER, i);
        sendStickyBroadcast(broadcastIntent);
    }
}}

Entradas de archivo de manifiesto:

Antes de la sección de aplicación:

uses-permission android:name="com.mindspiker.Tester.MyService.TEST"
uses-permission android:name="android.permission.BROADCAST_STICKY"

sección de aplicación interior

service android:name=".MyService"

Esta es mi solución propuesta:

• Mueva AsyncTask o Thread a un Fragmento retenido, como se explica aquí . Creo que es una buena práctica mover todas las llamadas de red a fragmentos. Si ya está utilizando fragmentos, uno de ellos podría hacerse responsable de las llamadas. De lo contrario, puede crear un fragmento solo para realizar la solicitud, como propone el artículo vinculado.
• El fragmento utilizará una interfaz de escucha para indicar la finalización / falla de la tarea. No tiene que preocuparse por los cambios de orientación allí. El fragmento siempre tendrá el enlace correcto a la actividad actual y el diálogo de progreso se puede reanudar de forma segura.
• Convierta su diálogo de progreso en un miembro de su clase. De hecho, debe hacer eso para todos los cuadros de diálogo. En el método onPause, debe descartarlos; de lo contrario, filtrará una ventana sobre el cambio de configuración. El estado ocupado debe mantenerse por el fragmento. Cuando el fragmento se adjunta a la actividad, puede volver a abrir el cuadro de diálogo de progreso, si la llamada aún se está ejecutando. Se void showProgressDialog()puede agregar un método a la interfaz de escucha de actividad de fragmentos para este propósito.

Me enfrenté a la misma situación. Lo que hice fue obtener solo una instancia para mi diálogo de progreso en toda la aplicación.

Primero, creé una clase DialogSingleton para obtener solo una instancia (patrón Singleton)

public class DialogSingleton
{
    private static Dialog dialog;

    private static final Object mLock = new Object();
    private static DialogSingleton instance;

    private DialogSingleton()
    {

    }

    public static DialogSingleton GetInstance()
    {
        synchronized (mLock)
        {
            if(instance == null)
            {
                instance = new DialogSingleton();
            }

            return instance;
        }
    }

    public void DialogShow(Context context, String title)
    {
        if(!((Activity)context).isFinishing())
        {
            dialog = new ProgressDialog(context, 2);

            dialog.setCanceledOnTouchOutside(false);

            dialog.setTitle(title);

            dialog.show();
        }
    }

    public void DialogDismiss(Context context)
    {
        if(!((Activity)context).isFinishing() && dialog.isShowing())
        {
            dialog.dismiss();
        }
    }
}

Como muestro en esta clase, tengo el diálogo de progreso como atributo. Cada vez que necesito mostrar un diálogo de progreso, obtengo una instancia única y creo un nuevo ProgressDialog.

DialogSingleton.GetInstance().DialogShow(this, "My title here!");

Cuando termino con la tarea en segundo plano, vuelvo a llamar a la instancia única y descarto su diálogo.

DialogSingleton.GetInstance().DialogDismiss(this);

Guardo el estado de la tarea en segundo plano en mis preferencias compartidas. Cuando giro la pantalla, pregunto si tengo una tarea ejecutándose para esta actividad: (onCreate)

if(Boolean.parseBoolean(preference.GetValue(IS_TASK_NAME_EXECUTED_KEY, "boolean").toString()))
{
    DialogSingleton.GetInstance().DialogShow(this, "Checking credentials!");
} // preference object gets the info from shared preferences (my own implementation to get and put data to shared preferences) and IS_TASK_NAME_EXECUTED_KEY is the key to save this flag (flag to know if this activity has a background task already running).

Cuando empiezo a ejecutar una tarea en segundo plano:

preference.AddValue(IS_TASK_NAME_EXECUTED_KEY, true, "boolean");

DialogSingleton.GetInstance().DialogShow(this, "My title here!");

Cuando termino de ejecutar una tarea en segundo plano:

preference.AddValue(IS_TASK_NAME_EXECUTED_KEY, false, "boolean");

DialogSingleton.GetInstance().DialogDismiss(ActivityName.this);

Espero que ayude.

Esta es una pregunta muy antigua que apareció en la barra lateral por alguna razón.

Si la tarea en segundo plano solo necesita sobrevivir mientras la actividad está en primer plano, la "nueva" solución es alojar el subproceso en segundo plano (o, preferiblemente, AsyncTask) en un fragmento retenido , como se describe en esta guía del desarrollador y numerosas preguntas y respuestas .

Un fragmento retenido sobrevive si la actividad se destruye por un cambio de configuración, pero no cuando la actividad se destruye en segundo plano o en la pila. Por lo tanto, la tarea en segundo plano aún debe interrumpirse si isChangingConfigurations()es falsa onPause().

Estoy más fresco en Android e intenté esto y funcionó.

public class loadTotalMemberByBranch extends AsyncTask<Void, Void,Void> {
        ProgressDialog progressDialog = new ProgressDialog(Login.this);
        int ranSucess=0;
        @Override
        protected void onPreExecute() {
            // TODO Auto-generated method stub
            super.onPreExecute();
            progressDialog.setTitle("");    
            progressDialog.isIndeterminate();
            progressDialog.setCancelable(false);
            progressDialog.show();
            setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_NOSENSOR);

        }
        @Override
        protected Void doInBackground(Void... params) {
            // TODO Auto-generated method stub

            return null;
        }
        @Override
        protected void onPostExecute(Void result) {
            // TODO Auto-generated method stub
            super.onPostExecute(result);
            progressDialog.dismiss();
            setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_NOSENSOR);
        }
}

Lo he intentado TODO. Pasé días experimentando. No quería bloquear la rotación de la actividad. Mi escenario fue:

1. Un diálogo de progreso que muestra información dinámica al usuario. Por ejemplo: "Conectando al servidor ...", "Descargando datos ...", etc.
2. Un hilo haciendo cosas pesadas y actualizando el diálogo
3. Actualización de la interfaz de usuario con los resultados al final.

El problema era que, al girar la pantalla, todas las soluciones del libro fallaban. Incluso con la clase AsyncTask, que es la forma correcta de Android de lidiar con estas situaciones. Al girar la pantalla, el contexto actual con el que está trabajando el hilo inicial desaparece y eso se confunde con el diálogo que se muestra. El problema siempre fue el Diálogo, sin importar cuántos trucos agregué al código (pasar nuevos contextos a hilos en ejecución, retener estados de hilo a través de rotaciones, etc.). La complejidad del código al final siempre fue enorme y siempre había algo que podía salir mal.

La única solución que funcionó para mí fue el truco Actividad / Diálogo. Es simple y genial y es a prueba de rotación:

1. En lugar de crear un cuadro de diálogo y pedir que se muestre, cree una actividad que se haya establecido en el manifiesto con android: theme = "@ android: style / Theme.Dialog". Entonces, solo parece un diálogo.

2. Reemplace showDialog (DIALOG_ID) con startActivityForResult (yourActivityDialog, yourCode);

3. Use onActivityResult en la Actividad de llamada para obtener los resultados del subproceso en ejecución (incluso los errores) y actualizar la IU.

4. En su 'ActivityDialog', use hilos o AsyncTask para ejecutar tareas largas y onRetainNonConfigurationInstance para guardar el estado del "diálogo" al girar la pantalla.

Esto es rápido y funciona bien. Todavía uso diálogos para otras tareas y AsyncTask para algo que no requiere un diálogo constante en la pantalla. Pero con este escenario, siempre voy por el patrón Actividad / Diálogo.

Y no lo intenté, pero incluso es posible bloquear la rotación de esa Actividad / Diálogo, cuando el hilo se está ejecutando, acelerando las cosas, mientras que permite que la Actividad de llamada gire.

En estos días hay una forma mucho más clara de manejar este tipo de problemas. El enfoque típico es:

1. Asegúrese de que sus datos estén separados adecuadamente de la interfaz de usuario:

Todo lo que sea un proceso en segundo plano debe estar retenido Fragment(configúrelo con Fragment.setRetainInstance(). Esto se convierte en su 'almacenamiento de datos persistente' donde se guarda todo lo basado en datos que le gustaría retener. Después del evento de cambio de orientación, Fragmentaún será accesible en su original estado a través de una FragmentManager.findFragmentByTag()llamada (cuando lo cree, debe darle una etiqueta, no una ID, ya que no está adjunto a a View).

Consulte la guía desarrollada Manejo de cambios en tiempo de ejecución para obtener información sobre cómo hacer esto correctamente y por qué es la mejor opción.

2. Asegúrese de interactuar de manera correcta y segura entre los procesos en segundo plano y su IU:

Debe revertir su proceso de vinculación. En este momento, su proceso en segundo plano se une a un View- en su lugar, Viewdebería estar adjuntándose al proceso en segundo plano. Tiene más sentido ¿verdad? La Viewacción de 's depende del proceso en segundo plano, mientras que el proceso en segundo plano no depende del View. Esto significa cambiar el enlace a una Listenerinterfaz estándar . Digamos que su proceso (sea cual sea la clase que es - si se trata de una AsyncTask, Runnableo lo que sea) define una OnProcessFinishedListener, cuando el proceso se realiza debe llamar a ese oyente si existe.

Esta respuesta es una buena descripción concisa de cómo hacer oyentes personalizados.

3. Enlace su interfaz de usuario al proceso de datos cada vez que se crea la interfaz de usuario (incluidos los cambios de orientación):

Ahora debe preocuparse por interactuar la tarea en segundo plano con cualquiera que sea su Viewestructura actual . Si está manejando sus cambios de orientación correctamente (no es el configChangestruco que la gente siempre recomienda), Dialogel sistema recreará su sistema. Esto es importante, significa que en el cambio de orientación, todos los Dialogmétodos de ciclo de vida se recuperan. Entonces, en cualquiera de estos métodos ( onCreateDialoggeneralmente es un buen lugar), puede hacer una llamada como la siguiente:

DataFragment f = getActivity().getFragmentManager().findFragmentByTag("BACKGROUND_TAG");
if (f != null) {
    f.mBackgroundProcess.setOnProcessFinishedListener(new OnProcessFinishedListener() {
        public void onProcessFinished() {
            dismiss();
        }
    });
 }

Vea el ciclo de vida de Fragment para decidir dónde configurar mejor el oyente en su implementación individual.

Este es un enfoque general para proporcionar una solución sólida y completa al problema genérico formulado en esta pregunta. Probablemente falten algunas piezas menores en esta respuesta dependiendo de su escenario individual, pero este es generalmente el enfoque más correcto para manejar adecuadamente los eventos de cambio de orientación.

He encontrado una solución más fácil para manejar hilos cuando cambia la orientación. Puede mantener una referencia estática a su actividad / fragmento y verificar si es nulo antes de actuar en la interfaz de usuario. Sugiero usar un try catch también:

 public class DashListFragment extends Fragment {
     private static DashListFragment ACTIVE_INSTANCE;

     @Override
     public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        ACTIVE_INSTANCE = this;

        new Handler().postDelayed(new Runnable() {
            public void run() {
                try {
                        if (ACTIVE_INSTANCE != null) {
                            setAdapter(); // this method do something on ui or use context
                        }
                }
                catch (Exception e) {}


            }
        }, 1500l);

    }

    @Override
    public void onDestroy() {
        super.onDestroy();

        ACTIVE_INSTANCE = null;
    }


}

Si tiene problemas para detectar los eventos de cambio de orientación de un diálogo INDEPENDIENTE DE UNA REFERENCIA DE ACTIVIDAD , este método funciona de manera emocionante. Lo uso porque tengo mi propia clase de diálogo que se puede mostrar en varias actividades diferentes, por lo que no siempre sé en qué actividad se muestra. Con este método no es necesario cambiar el manifiesto de Android, preocuparse por las referencias de actividad, y no necesitas un diálogo personalizado (como yo tengo). Sin embargo, necesita una vista de contenido personalizada para poder detectar los cambios de orientación utilizando esa vista en particular. Aquí está mi ejemplo:

Preparar

public class MyContentView extends View{
    public MyContentView(Context context){
        super(context);
    }

    @Override
    public void onConfigurationChanged(Configuration newConfig){
        super.onConfigurationChanged(newConfig);

        //DO SOMETHING HERE!! :D
    }
}

Implementación 1 - Diálogo

Dialog dialog = new Dialog(context);
//set up dialog
dialog.setContentView(new MyContentView(context));
dialog.show();

Implementación 2 - AlertDialog.Builder

AlertDialog.Builder builder = new AlertDialog.Builder(context);
//set up dialog builder
builder.setView(new MyContentView(context));        //Can use this method
builder.setCustomTitle(new MycontentView(context)); // or this method
builder.build().show();

Implementación 3 - ProgressDialog / AlertDialog

ProgressDialog progress = new ProgressDialog(context);
//set up progress dialog
progress.setView(new MyContentView(context));        //Can use this method
progress.setCustomTitle(new MyContentView(context)); // or this method
progress.show();

Esta es mi solución cuando lo enfrenté: ProgressDialogno es un Fragmentniño, por lo que mi clase personalizada " ProgressDialogFragment" puede extenderse DialogFragmenten su lugar para mantener el cuadro de diálogo que se muestra para los cambios de configuración.

import androidx.annotation.NonNull;
import android.app.Dialog;
import android.app.ProgressDialog;
import android.os.Bundle; 
import androidx.fragment.app.DialogFragment;
import androidx.fragment.app.FragmentManager;

 /**
 * Usage:
 * To display the dialog:
 *     >>> ProgressDialogFragment.showProgressDialogFragment(
 *              getSupportFragmentManager(), 
 *              "fragment_tag", 
 *              "my dialog title", 
 *              "my dialog message");
 *              
 * To hide the dialog
 *     >>> ProgressDialogFragment.hideProgressDialogFragment();
 */ 


public class ProgressDialogFragment extends DialogFragment {

    private static String sTitle, sMessage;
    private static ProgressDialogFragment sProgressDialogFragment;

    public ProgressDialogFragment() {
    }

    private ProgressDialogFragment(String title, String message) {
        sTitle = title;
        sMessage = message;
    }


    @NonNull
    @Override
    public Dialog onCreateDialog(Bundle savedInstanceState) {
        return ProgressDialog.show(getActivity(), sTitle, sMessage);
    }

    public static void showProgressDialogFragment(FragmentManager fragmentManager, String fragmentTag, String title, String message) {
        if (sProgressDialogFragment == null) {
            sProgressDialogFragment = new ProgressDialogFragment(title, message);
            sProgressDialogFragment.show(fragmentManager, fragmentTag);

        } else { // case of config change (device rotation)
            sProgressDialogFragment = (ProgressDialogFragment) fragmentManager.findFragmentByTag(fragmentTag); // sProgressDialogFragment will try to survive its state on configuration as much as it can, but when calling .dismiss() it returns NPE, so we have to reset it on each config change
            sTitle = title;
            sMessage = message;
        }

    }

    public static void hideProgressDialogFragment() {
        if (sProgressDialogFragment != null) {
            sProgressDialogFragment.dismiss();
        }
    }
}

El desafío consistía en retener el título y el mensaje del diálogo durante la rotación de la pantalla mientras se restablecían a la cadena vacía predeterminada, aunque el diálogo aún se mostraba

Hay 2 enfoques para resolver esto:

Primer enfoque: realice la actividad que utiliza el diálogo para retener el estado durante el cambio de configuración en el archivo de manifiesto:

android:configChanges="orientation|screenSize|keyboardHidden"

Google no prefiere este enfoque.

Segundo enfoque: en el onCreate()método de la actividad , debe conservarlo DialogFragmentreconstruyendo ProgressDialogFragmentnuevamente con el título y el mensaje de la siguiente manera si savedInstanceStateno es nulo:

@Override
protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.activity_deal);

 if (savedInstanceState != null) {
      ProgressDialogFragment saveProgressDialog = (ProgressDialogFragment) getSupportFragmentManager()
              .findFragmentByTag("fragment_tag");
      if (saveProgressDialog != null) {
          showProgressDialogFragment(getSupportFragmentManager(), "fragment_tag", "my dialog title", "my dialog message");
      }
  }
}

Parece demasiado 'rápido y sucio' para ser verdad, así que por favor señale los defectos, pero lo que encontré funcionó fue ...

Dentro del método onPostExecute de mi AsyncTask, simplemente envolví el '.dismiss' para el diálogo de progreso en un bloque try / catch (con un catch vacío) y luego simplemente ignoré la excepción que se generó. Parece incorrecto pero parece que no hay efectos nocivos (al menos para lo que estoy haciendo posteriormente, que es comenzar otra actividad pasando el resultado de mi consulta de larga duración como Extra)

La solución más simple y flexible es utilizar una AsyncTask con una referencia estática a ProgressBar . Esto proporciona una solución encapsulada y, por lo tanto, reutilizable para los problemas de cambio de orientación. Esta solución me ha sido útil para diversas tareas asíncronas, incluidas las descargas de Internet, la comunicación con los Servicios y los análisis del sistema de archivos. La solución ha sido probada en múltiples versiones de Android y modelos de teléfonos. Puede encontrar una demostración completa aquí con interés específico en DownloadFile.java

Presento lo siguiente como un ejemplo conceptual

public class SimpleAsync extends AsyncTask<String, Integer, String> {
    private static ProgressDialog mProgressDialog = null;
    private final Context mContext;

    public SimpleAsync(Context context) {
        mContext = context;
        if ( mProgressDialog != null ) {
            onPreExecute();
        }
    }

    @Override
    protected void onPreExecute() {
        mProgressDialog = new ProgressDialog( mContext );
        mProgressDialog.show();
    }

    @Override
    protected void onPostExecute(String result) {
        if ( mProgressDialog != null ) {
            mProgressDialog.dismiss();
            mProgressDialog = null;
        }
    }

    @Override
    protected void onProgressUpdate(Integer... progress) {
        mProgressDialog.setProgress( progress[0] );
    }

    @Override
    protected String doInBackground(String... sUrl) {
        // Do some work here
        publishProgress(1);
        return null;
    }

    public void dismiss() {
        if ( mProgressDialog != null ) {
            mProgressDialog.dismiss();
        }
    }
}

El uso en una actividad de Android es simple

public class MainActivity extends Activity {
    DemoServiceClient mClient = null;
    DownloadFile mDownloadFile = null;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate( savedInstanceState );
        setContentView( R.layout.main );
        mDownloadFile = new DownloadFile( this );

        Button downloadButton = (Button) findViewById( R.id.download_file_button );
        downloadButton.setOnClickListener( new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                mDownloadFile.execute( "http://www.textfiles.com/food/bakebred.txt");
            }
        });
    }

    @Override
    public void onPause() {
        super.onPause();
        mDownloadFile.dismiss();
    }
}

Cuando cambia las orientaciones, Android elimina esa actividad y crea una nueva actividad. Sugiero usar retrofit con Rx java. cuyo mango se bloquea automáticamente.

Utilice este método cuando reequipa la llamada.

.subscribeOn (Schedulers.io ()) .observeOn (AndroidSchedulers.mainThread ())