Понимание проблемы на Android
По иронии судьбы, из-за интенсивной песочницы в iOS есть простой способ сделать это там (группы приложений), при условии, что приложения, которым необходимо обмениваться данными, созданы одним и тем же разработчиком. Вероятно, из-за того, что Android более гибок в плане безопасности, это на самом деле становится более сложной проблемой. Команда Android до сих пор не сочла нужным предоставить удобный и безопасный способ специально делиться такими данными, потому что существует обходной путь с низкой безопасностью.
Тем не менее, существует множество способов обмена данными между приложениями без использования облака.
Общие настройки
В исходном вопросе говорится, что SharedPreferences устарели. Насколько я могу судить, это неправда, однако контексты MODE_WORLD_READABLE и MODE_WORLD_WRITABLE устарели, что делает этот подход неработоспособным в будущем. Однако этот режим уже давно устарел — начиная с Android 4.2 (2012 г.). В текущих документах по Android нет никаких угроз, чтобы предположить, что они фактически отказываются от него (иногда устаревание просто означает «это не очень хорошая идея», а не «это будет удалено»). Я подозреваю, что отсутствие более безопасной прямой альтернативы на уровне ОС для обмена данными приложения на уровне настроек, вероятно, является причиной того, что он оставался в состоянии устаревания в течение последних 5 лет.
Доступ к файлам
Самый простой и наиболее распространенный известный мне способ реализации обмена данными между приложениями на Android — это просто запросить доступ к файлу на устройстве и создать общее расположение на внешнем хранилище для этих данных. (Не путайте с обозначением «внешнее хранилище» — именно так Android относится к общим данным. Это не обязательно относится к SD-карте.) Вы даете файлу уникальное имя и сохраняете его где-нибудь, чтобы ваши приложения знают, где его искать. Лучший способ получить этот путь: Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS)
Очевидная проблема с этим - безопасность. Несмотря на то, что ОС не объявляет его устаревшим, он создает ту же проблему, которая указана в документах Android как причину отказа от MODE_WORLD_* — он по своей сути небезопасен и открывает потенциальные уязвимости в вашем приложении.
- Вы размещаете свою информацию там, где все имеет к ней свободный доступ.
- Вы запрашиваете разрешения, которые в противном случае могут не понадобиться вашему приложению.
- Вы читаете файлы, происхождение которых не можете проверить.
Если ваше приложение не обрабатывает какие-либо конфиденциальные данные, возможно, это не имеет значения для вас (возможно, для ваших пользователей). Если вы планируете считывать данные из этих файлов, вы должны обеспечить максимальную проверку этих данных перед синтаксическим анализом. Проверьте размер файла, проверьте форматирование и т. д.
Создание собственной службы
Вы всегда можете создать Service или IntentService. (Между ними есть тонкие различия, но IntentService — это подкласс Service, который работает в рабочем потоке, в то время как Service прерывает основной поток. IntentService также реализует поддержку Intent, которая обеспечивает наиболее прямое взаимодействие между приложениями на Android).
У этой службы есть собственное частное хранилище, для которого она имеет полный доступ на чтение/запись, но больше ничего. Затем эта служба предоставляет интерфейс для получения намерений от других приложений и для возврата результатов (в виде намерений) этим приложениям. Это чрезвычайно удобный способ реализации данных между приложениями, при этом максимально повышая конфиденциальность и безопасность этих данных. Если удаленным приложениям в основном нужно запрашивать очень простую информацию из центрального приложения, это вариант начального уровня.
Реализация BroadcastReceiver
В том же духе находится класс BroadcastReceiver. В зависимости от того, какие данные вы собираетесь передавать между приложениями, и насколько эти приложения могут быть знакомы с вашим конкретным подходом, это еще одна возможность. Опять же, вы будете управлять общими данными в частном хранилище одного приложения. Связь осуществляется с помощью намерений, поэтому она похожа на IntentService, за исключением того, что приложения могут взаимодействовать с BroadcastReceiver, выдавая общесистемные события (то есть им не нужно явно взаимодействовать с вашим приложением или службой — они выкрикивают world для части информации, и ожидая ответа.)
Создание ContentProvider
Исходное сообщение, похоже, неправильно понимает, что такое ContentProvider и как он работает. Вы должны думать об этом типе элемента, как об облачном решении, даже если оно является локальным для вашего устройства. Каждому приложению не нужен ContentProvider — все они должны взаимодействовать с ContentProvider, и этот ContentProvider поддерживает, обновляет и возвращает данные.
Это, вероятно, наиболее подходящее для Android решение для данного конкретного случая использования, которое предлагает наибольшую расширяемость. Вы реализуете независимый процесс, который обрабатывает хранение данных и отвечает другим приложениям. Это, однако, более развитое решение и, как таковое, может быть более сложной задачей. Если вам нужна настоящая служба базы данных, а не довольно простая служба типа запрос/ответ, ContentProvider кажется лучшим выбором.
person
EddieOffermann
schedule
26.02.2017
