Использование JobScheduler вместо BroadcastReceiver и Service

#android #service #broadcastreceiver #broadcast #android-jobscheduler

#Android #Обслуживание #broadcastreceiver #трансляция #android-jobscheduler

Вопрос:

Я работаю над приложением, которое будет последовательно загружать все записи моей базы данных на сервер в фоновом режиме, когда устройство подключено к Интернету.

Для этого я написал a BroadcastReceiver , который будет прослушивать сетевое подключение. Когда этот приемник запускается, я запускаю фоновую службу для загрузки записей.

Вот мой код.

 public class NetworkChangeReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(final Context context, final Intent intent) {
       AppUtils.checkInternetConnection(context));
        //If the device has the internet connection and if there are any pending records to upload to server then start the service for uploading the records.
        if (AppUtils.checkInternetConnection(context)) {
            if (Database.getInstance().getTotalRecordsCount() > 0) {
                context.startService(new Intent(context, SurveyUploadService.class));
            }
        } else {
            context.stopService(new Intent(context, SurveyUploadService.class));
        }
    }
}
  

Теперь я сомневаюсь

1. Могу ли я сделать то же самое с помощью JobScheduler?
2. Какой подход лучше (мой или тот, который использует JobScheduler) и почему?

Комментарии:

1. Вы пытались внедрить службу заданий?

Ответ №1:

Я не знаю, какое действие вы используете для BroadcastReceiver, но я предполагаю, что это действие CONNECTIVITY_CHANGE. Если вы используете его, прочитайте следующий текст сбоку об изменениях в поведении Android 7.0:

Чтобы устранить эти проблемы, Android 7.0 применяет следующие оптимизации:

  • Приложения, ориентированные на Android 7.0, не получают трансляции CONNECTIVITY_ACTION, даже если у них есть записи манифеста для запроса уведомления об этих событиях. Запущенные приложения все еще могут прослушивать CONNECTIVITY_CHANGE в своем основном потоке, если они запрашивают уведомление с помощью BroadcastReceiver.

  • Приложения не могут отправлять или получать трансляции ACTION_NEW_PICTURE или ACTION_NEW_VIDEO. Эта оптимизация затрагивает все приложения, а не только те, которые нацелены на Android 7.0.

Если ваше приложение использует какие-либо из этих намерений, вам следует как можно скорее удалить зависимости от них, чтобы вы могли правильно настроить таргетинг на устройства Android 7.0. Платформа Android предоставляет несколько решений для уменьшения необходимости в этих неявных трансляциях. Например, API JobScheduler предоставляет надежный механизм для планирования сетевых операций при выполнении заданных условий, таких как подключение к неустановленной сети. Вы даже можете использовать JobScheduler для реагирования на изменения поставщиков контента.

Поэтому лучше использовать API JobScheduler.

Вот пример JobScheduler.

Комментарии:

1. в чем разница между CONNECTIVITY_CHANGE и CONNECTIVITY_ACTION?

2. Если вы посмотрите здесь developer.android.com/reference/android/net /… вы увидите, что CONNECTIVITY_ACTION — это имя константы со значением «android.net.conn. CONNECTIVITY_CHANGE»‘.

3. Это здорово, спасибо

4. Означает ли это, что проверку CONNECTIVITY_CHANGE невозможно выполнить в фоновом режиме из target>= N?

5. Да, если вы используете в качестве неявного широковещательного приемника, т.Е. Как часть манифеста. Рекомендуется использовать планировщик заданий.