Привязать к службе из нового контекста для изменений конфигурации или привязать из контекста приложения?

Итак, покопавшись, я думаю, что нашел (пока) непроверенное решение.

Во-первых, на основе предложения Дианы здесь: https://groups.google.com/forum/#!topic/android-developers/Nb58dOQ8Xfw Я должен быть привязан к контексту приложения, поэтому моя проблема с потерей контекста исчезла. Я могу поддерживать свое ServiceConnection при изменении конфигурации с помощью фрагмента, отличного от пользовательского интерфейса. отличный. Затем, когда я закончу, я могу использовать контекст приложения, чтобы вернуть соединение со службой и отменить привязку. Я не должен получать никаких предупреждений об утечке сервисного соединения. (Возможно, я должен указать, что это стандарт и рекомендуется способ поддерживать экземпляры при изменении конфигурации)

Последней проблемой этой проблемы было то, что я не был уверен, смогу ли я привязываться несколько раз из одного и того же контекста - документация по привязкам подразумевает, что существует некоторая зависимость между привязкой и жизненным циклом контекста, и поэтому я беспокоился, что мне придется делать свои собственные форма подсчета ссылок. Я просмотрел исходный код и оказался здесь: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/app/LoadedApk.java#LoadedApk.forgetServiceDispatcher%28android.content.Context%2Candroid.content.ServiceConnection%29

Главное, эти строки:

sd = map.get(c);
    if (sd != null) {
        map.remove(c);
        sd.doForget();
        if (map.size() == 0) {
            mServices.remove(context);
        }

Выясните, что map используется для подсчета ссылок, о котором я беспокоился.

Так что взять домой это:

• Связанная служба будет нормально работать с контекстом приложения, и мы ДОЛЖНЫ сделать это, чтобы предотвратить утечку соединения службы из одного действия в другое во время изменения конфигурации.
• Я могу безопасно сохранить подключение службы к фрагменту, отличному от пользовательского интерфейса, и использовать его для отмены привязки, когда закончу.

Я постараюсь вскоре опубликовать проверенный код.

ОБНОВЛЕНИЕ и протестированное решение: я сделал код для проверки и опубликовал его здесь: https://github.com/samskiter/BoundServiceTest

Кажется, это работает довольно хорошо, и фрагмент, не относящийся к пользовательскому интерфейсу (фрагмент данных), действует как хороший прокси-слушатель во время ротационных изменений, чтобы перехватывать результаты службы (намерение слушателей состоит в том, чтобы тесно привязать запросы к пользовательскому интерфейсу, чтобы гарантировать он остается отзывчивым.Очевидно, что любые изменения модели могут быть переданы в пользовательский интерфейс через наблюдателей.)

Изменить: я думал, что должен явно ответить на вопросы в ОП...

• следует ли использовать первый метод (действия с временными контекстами)? Или второй (просто привязать сервис к контексту приложения)? Второй

• Правильно ли я понимаю, что контекст приложения может связываться со службой несколько раз, а затем столько же раз от нее отвязываться? (Т.е. что у вас может быть несколько действительных привязок для PER контекста)? Да

• Может ли использование моего собственного контекста (new Context()) в первом решении вызвать какие-либо проблемы? Это даже невозможно

Окончательное резюме:

Этот шаблон должен быть довольно мощным — я могу расставить приоритеты сетевого ввода-вывода (или других задач), поступающих из различных источников в моем приложении. У меня могла бы быть активность переднего плана, делающая небольшой ввод-вывод, о котором просил пользователь, одновременно я мог бы запустить службу переднего плана для синхронизации всех данных моих пользователей. И служба переднего плана, и действие могут быть привязаны к одной и той же сетевой службе для выполнения своих запросов.

Все это при условии, что сервис живет ровно столько, сколько ему нужно, то есть он прекрасно работает с Android.

Я очень рад получить это в приложении в ближайшее время.

ОБНОВЛЕНИЕ: я попытался написать это и дать некоторый контекст более широкой проблеме фоновой работы в записи блога здесь: http://blog.airsource.co.uk/2014/09/10/android-bound-services/

Можете ли вы не просто выбрать конфигурации, которые вы хотели бы обрабатывать с помощью атрибута configChanges в вашем манифесте, и вручную изменить ориентацию в пользовательском интерфейсе? В этом случае вам нужно только привязаться к сервису в onCreate, а затем отменить привязку в onDestroy.

или, может быть, попробуйте что-то вроде этого (я не сделал должной проверки ошибок):

  

    class MyServiceConnection implements ServiceConnection,Parcelable {
                public static final Parcelable.Creator CREATOR
                = new Parcelable.Creator() {
                    public MyServiceConnection createFromParcel(Parcel in) {
                        return new MyServiceConnection(in);
                    }

                    public MyServiceConnection[] newArray(int size) {
                        return new MyServiceConnection[size];
                    }
                };

                @Override
                public int describeContents() {
                    return 0;
                }

                @Override
                public void writeToParcel(Parcel dest, int flags) {

                }

                @Override
                public void onServiceConnected(ComponentName name, IBinder service) {

                }

                @Override
                public void onServiceDisconnected(ComponentName name) {

                }
            }
            MyServiceConnection myServiceConnection;
            boolean configChange = false;

            protected void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.activity_main);
                if (savedInstanceState != null) {
                    myServiceConnection = savedInstanceState.getParcelable("serviceConnection");
                } else {
                    myServiceConnection = new MyServiceConnection();
                }

            }
            @Override
            protected void onSaveInstanceState(Bundle outState) {
                super.onSaveInstanceState(outState);
                if (myServiceConnection != null) {
                    outState.putParcelable("serviceConnection",myServiceConnection);
                    configChange = true;
                }
            }
            @Override
            protected void onDestroy() {
                super.onDestroy();
                if (!configChange && myServiceConnection != null){
                    unbindService(myServiceConnection);
                }
            }
        }

Существует гораздо более простой способ справиться с этой ситуацией, называемый IntentService, о котором вы можете узнать подробнее здесь. С сайта андроида:

«Класс IntentService предоставляет простую структуру для запуска операции в одном фоновом потоке. Это позволяет ему обрабатывать длительные операции, не влияя на скорость отклика вашего пользовательского интерфейса. Кроме того, IntentService не зависит от большинства событий жизненного цикла пользовательского интерфейса, поэтому он продолжает работать в обстоятельствах, которые могут закрыть AsyncTask"

Вместо того, чтобы привязывать свою службу к своей активности, вы можете запускать длительные действия в фоновом потоке, просто используя намерение, которое запускает ваш IntentService

public class RSSPullService extends IntentService {

    @Override
    protected void onHandleIntent(Intent workIntent) {
    // Gets data from the incoming Intent
    String dataString = workIntent.getDataString();
    ...
    // Do work here, based on the contents of dataString
    ...
    }
}

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

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

По завершении службы вы можете сообщить о статусе работы. используя локальную трансляцию - либо отправляя результаты непосредственно обратно в активность (через широковещательный приемник), либо, возможно, даже через onNewIntent() (хотя заставить это работать немного более неуклюже.

Изменить – ответить на вопросы в комментариях

IntentService — относительно небольшой класс. Это упрощает модификацию. Стандартный код для IntentService вызывает stopSelf() и умирает, когда у него заканчивается работа. Это можно легко исправить. Изучив исходный код IntentService (см. предыдущую ссылку), вы можете увидеть, что он в значительной степени уже работает с очередью, получая сообщения в onStart() и затем выполняя их в порядке получения, как описано в комментарии. Переопределение onStart() позволит вам реализовать новую структуру очереди в соответствии с вашими потребностями. Используйте пример кода для обработки входящего сообщения и получения Intent, а затем просто создайте свою собственную структуру данных для обработки приоритета. Вы должны иметь возможность запускать/останавливать свои веб-запросы в IntentService так же, как и в Service. Таким образом, переопределяя onStart() и onHandleIntent(), вы сможете делать то, что хотите.

У меня была аналогичная проблема, когда у меня была связанная служба, используемая в действии. Внутри действия я определяю ServiceConnection, mConnection, а внутри onServiceConnected я устанавливаю поле класса, syncService которое является ссылкой на Сервис:

private SynchronizerService<Entity> syncService;

(...)

/** Defines callbacks for service binding, passed to bindService() */
private ServiceConnection mConnection = new ServiceConnection() {

    @Override
    public void onServiceConnected(ComponentName className, IBinder service) {
        // We've bound to LocalService, cast the IBinder and get
        // LocalService instance
        Log.d(debugTag, "on Service Connected");
        LocalBinder binder = (LocalBinder) service;
        //HERE
        syncService = binder.getService();
        //HERE
        mBound = true;
        onPostConnect();
    }

    @Override
    public void onServiceDisconnected(ComponentName arg0) {
        Log.d(debugTag, "on Service Disconnected");
        syncService = null;
        mBound = false;
    }
};

Используя этот метод, всякий раз, когда менялась ориентация, я получал NullPointerException при ссылке на переменную syncService, несмотря на то, что служба работала, и я пробовал несколько методов, которые никогда не работали.

Я собирался реализовать решение, предложенное Сэмом, используя сохраненный фрагмент для сохранения переменной, но сначала вспомнил о простой вещи: установить для переменной syncService значение static.. и ссылка на соединение сохраняется при изменении ориентации !

Итак, теперь у меня есть

private static SynchronizerService<Entity> syncService = null;

...

/** Defines callbacks for service binding, passed to bindService() */
private ServiceConnection mConnection = new ServiceConnection() {

    @Override
    public void onServiceConnected(ComponentName className, IBinder service) {
        // We've bound to LocalService, cast the IBinder and get
        // LocalService instance
        Log.d(debugTag, "on Service Connected");
        LocalBinder binder = (LocalBinder) service;
        //HERE
        if(syncService == null) {
            Log.d(debugTag, "Initializing service connection");
            syncService = binder.getService();
        }
        //HERE
        mBound = true;
        onPostConnect();
    }

    @Override
    public void onServiceDisconnected(ComponentName arg0) {
        Log.d(debugTag, "on Service Disconnected");
        syncService = null;
        mBound = false;
    }
};