Java refactoring

[alexcohn]

Если вам не лень залезть под кат, прокомментируйте пожалуйста мои эксперименты.

Comments

[iordane]

1)
Log.d(_TAG, "tryDisableEnable(): " + _wifiManager.getWifiState());
return _wifiManager.getWifiState() == WifiManager.WIFI_STATE_DISABLED;

нет гарантии, что результаты _wifiManager.getWifiState() будут одинаковы в первой и второй строчке

2)

for (int i = 0; i < 5; i++) {
Thread.sleep(500);
}
не обязательно займет не 2500ms.

[alexcohn]

спасибо!

1. Плевать: если вернули ОК, то мне плевать, что напечатано в логе... В конце концов Log.d() будет отключен вообще.

2. Тоже плевать: время явно оценивается очень приблизительно. Я знаю, что нет смысла ждать более полминуты. Если я получу таймаут через 20 секунд, или 40 секунд - ничего не изменится.

[anonymous]

busy-wait - зло. почему бы не зарегистрироваться на получение бродкаста WIFI_STATE_CHANGED_ACTION? (я не знаю, подходит ли это в данном случае, я только начинаю разбираться в андроиде).

[alexcohn]

Хороший вопрос. Потому что замучаешься разбивать линейную логику на десяток фрагментов и строить state machine чтобы выполнять по получнии события очередную порцию действий. Потому что мне нужно следить и за изменениями, которые вообще никакого бродкаста не генерируют. Потому что тогда совсем нет шансов понять, что время ожидания вышло, и пора прикрывать лавочку. И кому об этом сообщать.

А чем уж так уж бесконечно плох цикл с Thread.sleep() посередине?

[anonymous]

» следить и за изменениями, которые вообще никакого бродкаста не генерируют
вот это беда, да, а остальное не очень беда.
чем плохо? да ничем таким особенным не плохо. не масштабируется только.