#android #android-activity #broadcastreceiver
#Android #android-активность #broadcastreceiver
Вопрос:
Если намерение запускается с намерением определенного действия, получающего его, но действие выполняется в фоновом режиме, какова рекомендуемая наилучшая практика в этом сценарии?
Например, действие могло вызвать длительный запрос на вход на удаленный сервер, обрабатываемый IntentService. Во время длительного запроса на вход в систему действие отправляется в фоновом режиме. Поскольку BroadcastReceiver был зарегистрирован в Activity, он тоже находится в фоновом режиме. Процесс входа в систему завершается, но намерение сигнализировать об этом никогда не принимается BroadcastReceiver.
Должен ли я использовать ContentProvider для сохранения результата из IntentService и регистрации активности / пользовательского интерфейса для изменений? Если я использую этот подход, и действие выполняется в фоновом режиме, будет ли оно получать обновления ContentProvider?
Ответ №1:
Если в вашем приложении нет только одного действия, состояние аутентификации (никогда не входил в систему, авторизован, срок действия логина истек) должно находиться за пределами какого-либо одного действия. Находится ли это в статических элементах данных или в каком-либо постоянном хранилище, зависит от бизнес-правил.
Ваша активность будет просто запрашивать это состояние в onResume() (например, проверять элемент статических данных).
Комментарии:
1. Возможно, я могу более подробно изложить свой вопрос. Когда пользователь входит в систему, во время аутентификации отображается диалоговое окно о ходе выполнения. Диалоговое окно закрывается, когда широковещательный приемник обрабатывает намерение «войти успешно». Я понимаю, что ваш ответ по-прежнему заключается в том, что диалоговое окно прогресса может быть отклонено путем опроса состояния, хранящегося где-то в постоянном хранилище. Но это кажется распространенной проблемой. Вы хотите сказать, что для всех событий, которые должны приниматься на уровне пользовательского интерфейса, требуется какой-то механизм постоянного хранения? Если да, то зачем вообще использовать BroadcastReceivers в приложении?
2. @Jack: «Вы хотите сказать, что для всех событий, которые должны приниматься на уровне пользовательского интерфейса, требуется какой-то механизм постоянного хранения?» — если вы пытаетесь взаимодействовать с чем-либо, кроме активности на переднем плане, это действительно хорошая идея. «Если да, то зачем вообще использовать BroadcastReceivers в приложении?» — чтобы сообщить активности переднего плана о событии.
3. Но все действия на переднем плане потенциально могут выполняться в фоновом режиме (по определению), поэтому BroadcastReceivers редко являются хорошим выбором для передачи каких-либо других совершенно неважных событий, происходящих из самого приложения?
4. @Jack: Мы приветствуем ваше мнение. Сохранение
IntentServiceрезультатов (например, через статический элемент данных), а также отправка широковещательной рассылки (чтобы сообщить активности переднего плана, что что-то произошло, чего она иначе не осознает) — это одно из решений, но оно не единственное. Например, еслиIntentServiceрассматриваемое действие инициировано действием, вы могли бы передатьMessenger(привязанный кHandlerв действии) черезIntentextra с вашейstartService()командой и отправить результаты таким образом. Или попробуйтеResultReceiver.5. @Jack: Имейте в виду, что предлагаемое вами
ContentProviderрешение также требует «какого-то механизма постоянного хранения. Этот подход может сработать, хотя я скептически отношусь к тому, что он имеет смысл для сценария входа в систему (я бы назвал это «прихлопнуть муху Buick»).