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

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

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

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

Размер сообщения составляет около 1 кбайт. Издатель может легко хранить несколько сотен активных сообщений в любой момент времени.

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

Теперь мне интересно, каким будет хороший транспортный механизм:

Вариант 1. Широковещательные намерения

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

Существует проблема с большими фидами, так как брокер запросов Android поддерживает максимум 1 МБ для всех одновременных транзакций (поэтому максимальный объем данных в фиде может быть даже меньше, если что-то занято). В настоящее время я работаю над этим, разбивая каналы на куски по 100 сообщений или меньше.

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

Вариант 2. Поставщики содержимого

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

Вопросы:

• Есть ли способ реализовать описанную выше модель с несколькими издателями и несколькими подписчиками с поставщиками контента и без необходимости предоставления центрального компонента, еще не предоставленного ОС?
• В частности, может ли один поставщик контента иметь несколько серверных частей? В качестве альтернативы, могут ли несколько функционально идентичных поставщиков контента рекламировать себя как группу?
• Как бы я реализовал вышеизложенное с помощью поставщиков контента?
• Каковы преимущества и недостатки широковещательных намерений или поставщиков контента, которые я мог упустить?