BluetoothChat синхронизирован onResume Метод жизненного цикла активности, почему? - PullRequest
Новая
       27

BluetoothChat синхронизирован onResume Метод жизненного цикла активности, почему?

5 голосов
/ 06 января 2012

Я сейчас изучаю Bluetooth API для Android и столкнулся с примером BluetoothChat. http://developer.android.com/resources/samples/BluetoothChat/index.html

Он содержит много ошибок, прежде всего тот простой факт, что он использует API 11, но манифест не заставляет этот минимальный API.

Другая интересная вещь - это использование синхронизированного ключевого слова в методах жизненного цикла Activity, как в 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();
        }
    }
}

Почему это ключевое слово используется там? Есть ли разумное объяснение, или просто тот, кто написал код, не знал, что onResume будет вызываться всегда одним и тем же потоком? Или я что-то пропустил?

Заранее спасибо!

1 Ответ

1 голос
/ 24 мая 2012

Это кажется довольно старым вопросом, но я думаю, что вот что происходит:

Я предполагаю, что он хочет быть осторожным, когда возвращаются "диалоги".В примере BluetoothChat используются диалоговые окна (а также действия, подобные наложенным диалоговым окнам), для включения Bluetooth, включения обнаружения и инициирования сопряжения / подключений.

Я точно не знаю, но подозреваю, что произошла ошибкагде разные потоки возвращались к основному действию и вызывали путаницу в отношении того, как обрабатывать onResume.

Что они, вероятно, должны были сделать, это synchronize блок объекта и использование флагов для определения состояния.Таким образом, намерение, состояние и функциональность более понятны - и приложение знает, что оно должно делать в onResume;

, что-то вроде этого может быть: 

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

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

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

Однако из-заБудучи примером приложения, они, возможно, решили пойти с чем-то более простым.Примеры приложений не всегда следуют соглашению, потому что идея состоит в том, чтобы продемонстрировать конкретный код, необходимый для примера.Иногда следующее соглашение может добавить много «отвлекающего» кода.Согласны ли вы с этим, зависит только от вас.

...