BluetoothChat synchronized onResume Método del ciclo de vida de la actividad, ¿por qué?

Question

Estoy estudiando ahora la API de Android bluetooth, y me encontré con el ejemplo de BluetoothChat. http://developer.android.com/resources/samples/BluetoothChat/index.html

Contiene muchos errores, en primer lugar, el simple hecho de que utiliza API 11 pero el manifiesto no fuerza esta API mínima.

Otra cosa interesante es el uso de la palabra clave sincronizada en los métodos del ciclo de vida de actividad, al igual que en onResume:

@Override 
public synchronized void onResume() { 
    super.onResume(); 
    if(D) Log.e(TAG, "+ ON RESUME +"); 

    // Performing this check in onResume() covers the case in which BT was 
    // not enabled during onStart(), so we were paused to enable it... 
    // onResume() will be called when ACTION_REQUEST_ENABLE activity returns. 
    if (mChatService != null) { 
     // Only if the state is STATE_NONE, do we know that we haven't started already 
     if (mChatService.getState() == BluetoothChatService.STATE_NONE) { 
      // Start the Bluetooth chat services 
      mChatService.start(); 
     } 
    } 
} 

Por qué se usa esta palabra clave allí? ¿Hay alguna explicación razonable, o simplemente el que escribió el código no sabía que onResume se llamará siempre por el mismo hilo? ¿O extraño algo?

¡Gracias de antemano!

Answer 1

Ésta parece ser una pregunta bastante viejo, pero esto es lo que creo que puede estar pasando:

Mi conjetura es que quiere tener cuidado cuando el retorno "diálogos". El ejemplo de BluetoothChat utiliza cuadros de diálogo (así como una actividad similar a un diálogo de superposición) para habilitar Bluetooth, habilitar el descubrimiento e iniciar el emparejamiento/las conexiones.

No lo sé con certeza, pero sospecho que hubo un error en el que diferentes hilos volvían a la actividad principal y causaban confusión en cuanto a cómo manejar onResume.

Lo que probablemente debieron haber hecho es synchronize un bloque en un objeto y banderas usadas para determinar el estado. De esta forma, la intención, el estado y la funcionalidad son más claros, y la aplicación sabe lo que debe hacer en onResume;

tal vez algo como esto:

//class fields  
private Object myLockObj = new Object(); 
private boolean isPausedForPairing = false; 

public void onResume() 
{ 
    super.onResume(); 

    synchronized (myLockObj) 
    { 
     if (isPausedForPairing) 
     { 
      //handle a "pairing" onResume 
     } 
    } 
} 

Sin embargo, debido a que es una aplicación ejemplo, puede haber decidido ir con algo más simple. Las aplicaciones de ejemplo no siempre siguen la convención porque la idea es demostrar el código particular necesario para el ejemplo. A veces, seguir la convención podría agregar un montón de código de "distracción". Si usted está de acuerdo o no con eso depende de usted.