Блог

Главная - Вопросы по программированию - Совместное использование Android между приложениями с помощью contentUri

Совместное использование Android между приложениями с помощью contentUri

#android #uri #android-contentprovider #android-sharing

#Android #uri #android-contentprovider #общий доступ Android

Вопрос:

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

Например:

  1. Я открываю Google Apps и предоставляю общий доступ к документу в своем приложении A.
  2. Приложение Google сгенерировало намерение и отправляет URI содержимого. Насколько я понимаю, uri содержимого содержит информацию о файле (имя файла, размер файла, тип mimetype) и возможность извлечения содержимого, которое находится в кэше приложения Google на устройстве.
  3. Когда приложение A открывается, оно считывает URI содержимого. В идеале, он должен иметь возможность извлекать информацию из uri содержимого, а затем отображать изображение. Это означает, что приложение A отобразит совместно используемое изображение. В этом примере приложение Google предоставляет общий доступ к документу, а приложение A хочет открыть и отобразить документ в своем собственном приложении.

Запутанная часть

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

Обходной путь:

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

Вопрос:

  1. Обходной путь не кажется идеальным, потому что технически вы снова сохраняете файл на устройстве. Есть два хранилища с одинаковым контентом (хранилище приложений Google и хранилище приложения A). Вам также необходимо указать, когда удалять созданный вами файл приложения A. На самом деле это не кажется идеальным, и мне было интересно, каким был бы наилучший подход? Или это ожидаемый поток?

  2. Также я не знаю, идеально ли передавать байты обратно или просто указывать путь к файлу.

Обновить

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

Приветствуются любые советы, D

Комментарии:

1. Пожалуйста, объясните более подробно, что означает «передать этот путь для получения рендеринга или передать байты обратно» и что означает «передать байты обратно». Что именно приложение A должно делать с контентом, представленным Uri ?

2. Обновлено: допустим, в моем случае использования это документ Google, которым приложение Google пытается поделиться с приложением A. URI содержимого генерируется приложением Google, поэтому я не могу контролировать, как это кодируется, но могу только предположить, что оно знает, как получить доступ к документу. Я могу прочитать байты документа, но не получить доступ к тому, где он хранится. Предполагается, что приложение A считывает файл и отображает его. В этом случае прочитайте документ общего доступа и отобразите его.

Ответ №1:

Несмотря на то, что я не могу извлечь путь к файлу из contentUri, я могу прочитать байты того, на что указывает contentUri.

Правильно. Это не сильно отличается от того, как вы используете URL-адрес HTTPS, где у вас также нет прямого доступа к файловой системе к контенту (в этом случае, резидентному на другом сервере).

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

Или просто используйте байты. Опять же, проводя аналогию с URL-адресом HTTPS, нет необходимости сохранять эти байты на диск, чтобы использовать их.

Обходной путь не кажется идеальным, потому что технически вы снова сохраняете файл на устройстве. Есть два хранилища с одинаковым контентом (хранилище приложений Google и хранилище приложения A). Вам также необходимо указать, когда удалять созданный вами файл приложения A.

Затем не сохраняйте файл снова на устройстве, а просто используйте поток байтов. Опять же, это не сильно отличается от использования URL-адреса HTTPS.

На самом деле это не кажется идеальным, и мне было интересно, каким был бы наилучший подход?

Не записывайте байты на диск. Просто используйте их.

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

Ваш выбор:

  • Улучшите код веб-приложения таким образом, чтобы путь к локальному файлу был одним из возможных источников данных, или

  • Возникают проблемы с созданием копий этих данных

В конце концов, имейте в виду, что Uri вам предоставляется через ACTION_SEND , не обязательно должно быть content Uri . Это очень легко может быть http или https Uri .