Это действительно зависит от того, чего вы пытаетесь достичь.В случае, когда, как вы просите, взаимодействия должны быть асинхронными, нет причин, по которым вы не можете использовать Intents.Этот способ имеет два преимущества:
- Если это «общий» запрос (что-то вроде «выбрать фотографию» или что-то подобное ...), то он дает пользователю (и операционной системе) возможностьвыберите наиболее подходящее приложение.Вполне возможно, что приложение № 2, как вы его назвали, на самом деле не существует на устройстве целевого пользователя (если только приложение № 1 конкретно не зависит от него).
- Приложение № 2 действительно может занять свое время, независимо от того, что оноты спросил.Если это задача, ориентированная на пользователя, то, возможно, она захочет запустить Activity и получить пользовательский ввод, или что-то подобное.
Если вы ищете дополнительные технические преимущества для этого метода: вы неприходится беспокоиться о приложении №1 в зависимости от сгенерированного кода класса каждый раз, когда вы меняете интерфейс.Когда вы пишете интерфейс, используя AIDL (именно так вы реализуете модель сервиса, которую вы назвали «1»), ADT уйдет и сгенерирует для вас группу классов, которые вы используете для предоставления своей удаленной службы.Проблемы возникают, когда приложение # 1 имеет другую версию этих сгенерированных классов для приложения # 2.(И поверьте мне, сообщения об ошибках, связанных с этими проблемами, являются менее информативными.)
С другой стороны, это не означает, что вам следует избегать модели удаленного обслуживания;у него много полезных приложений.Вот где мое объяснение становится немного «волнистым», но, надеюсь, вы поймете суть того, что я говорю.Интерфейсы AIDL дают вам гораздо больше прямого контроля над услугами, которые вы вызываете.Вместо того, чтобы запускать намерение, связывать в кучу данных и отправлять их в надежде, что оно достигнет правильного Сервиса (или действия, или другого обработчика), затем обрабатывается правильным образом, и в итоге результат вернетсядля вас вы напрямую вызываете методы внутри класса Remote.Методы, которые вы вызываете в этом удаленном классе, являются теми, которые определены интерфейсом AIDL, написанным в Приложении № 2 (который функционирует как сервер), - но вы быстро начнете думать о таких вещах, как потоки.Вы непосредственно вызываете код, который живет в другом процессе - это означает, что потоку, принадлежащему к Приложению № 1, предоставляется доступ к объектам и методам в Приложении № 2.
Как вы справляетесь с тем фактом, что Приложение #1 вызов кода в приложении № 2 в значительной степени зависит от вас, но способ, которым я пользуюсь (и я считаю, что рекомендуемый способ, хотя, если кто-то знает другое, я надеюсь, что они исправят меня здесь), заключается в использовании обработчика в приложении № 2,Когда приложение № 1 вызывает интерфейс AIDL, код, который он вызывает, отправляет сообщение обработчику, живущему в приложении № 2, который затем вызывается потоком, принадлежащим приложению № 2, то есть вы знаете, какая часть вашего приложения имеет доступ к каким членами т. д.
У этого потока управления есть очевидные преимущества, и мне кажется, что он больше похож на API-интерфейс, но это не значит, что он будет соответствовать целям каждого.Мой опыт также показывает, что программирование через интерфейс AIDL намного более чревато ошибками и хрупко.Хотя технически он всегда просто делает то, что вы сказали, но довольно легко сказать, что он делает что-то не так, или, что еще хуже, неправильно понимает то, что вы сказали.Я бы сказал: исчерпайте другие маршруты, прежде чем думать о написании службы AIDL.
На заметку об асинхронных вызовах:
- Если вы просто вызываете код в приложении № 2 напрямую, это полностьюсинхронный.
- Если вы используете интерфейс обработки сообщений, все немного по-другому.Затем вы можете предоставить второй интерфейс AIDL, находящийся внутри приложения № 1, который позволит приложению № 2 выдавать обратные вызовы (это то, что происходит в примере в официальной документации AIDL для Android).
Итак, у вас есть два очень гибких интерфейса для взаимодействия между двумя процессами.Оба хороши для разных целей.