Сетевой сервис должен вернуть обратный вызов

Question

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

Я размышлял, использовать ли интерфейс IBinder с локальной ссылкойв класс и решил не делать, на данный момент.

У меня есть следующие проблемы:

1. , если служба умирает, и я знаю, что это возможно во время обработки запроса, это проблемадля меня, во-первых, я видел это, процесс не умрет, пока не вернется чистый запрос (затем поток умирает), если в процессе не используется kill -9 ... потом я не уверен, что android делает ссоединения.Я не уверен, какой подход я должен использовать здесь (это будет верно, хотя, даже если это был локальный поток, а не служба ...)
2. , если я хочу, чтобы служба прослушивала обратный вызови вызовите его, как только закончится сетевая обработка, я нахожусь в проблеме, никакие экземпляры не могут быть переданы с использованием Intents.Поэтому мне нужны некоторые другие решения, и все они мне кажутся плохими: A. используйте IBinder, чтобы получить экземпляр класса сетевого обслуживания, затем я могу вызвать один из его методов и передать экземпляр, это будет работать, так как все онизапустить в том же процессе, НО требует от меня использовать Async способ получить экземпляр сети, который не очень подходит для меня.B. Используйте статический член в Сервисе, к которому я могу получить доступ, тогда для чего мне нужен сервис?C. использовать намерение для отправки параметров только службе, служба будет составлять из нее запрос и помещать его в очередь, а затем по завершении отправит ответ, используя намерение, которое будет инкапсулировать ответ (который может быть длинным!) Итакже будет содержать имя вызывающего класса в виде строки, поэтому все получатели будут знать, если это для них или нет - БОЛЬШИЕ издержки инкапсуляции данных в Intent и поиск во всех получателях правильного, чтобы получить ответ.

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

У кого-нибудь есть хорошие идеи о том, как подойтиэта вещь?

Answer 1

В конце концов я отказался от службы. Причина, по которой сервис не используется. Но чтобы расширить объект Application и сохранить сетевой класс в качестве члена этого объекта Application, он запускается при создании приложения, до создания какого-либо действия, и закрывается до того, как приложение рисует его. последний вздох. Я знаю, что приложение onTerminate может не вызываться постоянно, но если кто-то вызовет kill -9 или его эквивалент в моем Приложении, и процесс умрет, убив приложение с ним, я все готов, так как моя Служба все равно будет уничтожена. Причины, по которым я отказался от услуги:

1. У меня есть способ поддерживать рабочий поток во время жизненного цикла приложения .
2. Поскольку у меня есть и для будущего планирования будет только одно приложение, оно все равно будет работать в будущем.
3. Поскольку оно не связано и не начинается с какой-либо конкретной деятельности, оно не будет затронуто их смертью или созданием.
4. он имеет контекст, который будет действовать в течение жизненного цикла приложения, поэтому я МОГУ использовать его для трансляции событий с использованием намерений.
5. когда приложение умирает, моя служба умирает вместе с ним. если только не kill -9, а затем система убьет все потоки, связанные с приложением, включая мое, так что я все еще в порядке.
6. Каждое действие может использовать getApplication () и приводить к моему объекту Application и получать сервис.

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