NearbyConnection: payload.asFile (). AsJavaFile () имеет значение NULL при повторной попытке сохранить файл после того, как разрешения на хранилище изначально не предоставлены - PullRequest
Новая
       7

NearbyConnection: payload.asFile (). AsJavaFile () имеет значение NULL при повторной попытке сохранить файл после того, как разрешения на хранилище изначально не предоставлены

0 голосов
/ 24 марта 2019

Привет всем, я не уверен, откуда возникла эта проблема, будь то в реактивном родном обертке для Google Nearby Connections (https://github.com/butchmarshall/react-native-google-nearby-connection) или в самом Nearby Connection. У меня возникли проблемы при попытке сохранить полезную нагрузку файла при разрешенииизначально не предоставляются, поскольку библиотека заявляет, что payload.asFile().asJavaFile() является нулевым. Два сценария следующие:

Сценарий 1) Предоставляются разрешения на чтение / запись для хранения, пользователи обмениваются данными через соседнийСоединение, saveFile(serviceId,endpointId,payloadId) вызывается и файл сохраняется без проблем.
Сценарий 2) Пользователь не предоставил разрешения на хранение, и вызывается saveFile(serviceId,endpointId,payloadId), который возвращает отклоненное обещание, как и ожидалось.Параметры serviceId, endpointId, and payloadId хранятся в другом месте, поэтому пользователю может быть предложено предоставить разрешения и повторить попытку сохранения.При повторной попытке выполнение завершается неудачно, так как payload.asFile().asJavaFile() возвращает ноль.

Я выполнил adb logcat как во время успешного выполнения (изначально предоставленные разрешения), так и в случае сбоя (повторная попытка после предоставления разрешений), и я не вижуразница при регистрации полезной нагрузки.Ниже приведены журналы для случая сбоя: 

03-24 14:31:03.805 24644 26856 V NearbyConnection: saveFile from service com.google.myApp.v1 and endpoint hT4- and payload -6821529802993021226
03-24 14:31:03.805 24644 26856 V NearbyConnection: Payload com.google.android.gms.nearby.connection.Payload@16edba2
03-24 14:31:03.805 24644 26856 V NearbyConnection: payload.getType() 2
03-24 14:31:03.805 24644 26856 V NearbyConnection: payloadFileData  awesomePhoto.WEBP:{"description":"a flower"}
03-24 14:31:03.805 24644 26856 V NearbyConnection: payloadFilename awesomePhoto.WEBP
03-24 14:31:03.805 24644 26856 V NearbyConnection: payloadMetadata {"description":"a flower"}
03-24 14:31:03.806 24644 26856 V NearbyConnection: Cannot convert to file.

Cannot convert to File - это то, что возвращается здесь на Строка # 1501 https://github.com/butchmarshall/react-native-google-nearby-connection/blob/44f1699812c1f9cce37440294d7de1df438b75af/android/src/main/java/com/butchmarshall/reactnative/google/nearby/connection/NearbyConnectionModule.java#L1501 при payload.asFile().asJavaFile() == null.Что меня смущает, так это то, что кажется, что сама полезная нагрузка существует из того, что я вошел в систему adb logcat, так как payload.getType() работал нормально, возвращая 2.

Вопрос 1 : Ошибка первоначальных разрешенийпривести к тому, что содержимое файла полезной нагрузки каким-то образом будет уничтожено в кэше NearbyConnection, чтобы нечего было вызывать payload.asFile().asJavaFile()?Мне кажется странным, что вызов payload.getType() работает, но asFile() не удается.

Вопрос 2 : Можно ли хранить файлы полезных данных NearbyConnection во внутреннем приложении, выполняющем запрос, устраняя необходимость запрашивать / предоставлять разрешения для внешнего хранилища? 

When a file is received, it is saved in the Downloads folder (DIRECTORY_DOWNLOADS) on the recipient's device with a generic name and no extension.

src: https://developers.google.com/nearby/connections/android/exchange-data#file

Допущение / Гипотеза: После доставки окончательной полезной нагрузки, Nearby Connections пытается записать файл, который, если разрешения не предоставлены, завершается неудачей.Следовательно, независимо от того, будут ли предоставлены разрешения после этого, эта конечная полезная нагрузка все равно не будет иметь связанный с ней файл и, как таковая, никогда не будет работать.Если это правильно, то нет другого варианта, кроме как переслать файл, который я предполагаю?

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

Любые мысли здесь будут с благодарностью.

Выпуск Github : https://github.com/butchmarshall/react-native-google-nearby-connection/issues/4

1 Ответ

0 голосов
/ 25 марта 2019

Файл сохранен, несмотря на то, что ваше приложение не имеет READ / WRITE_EXTERNAL_STORAGE.Это связано с тем, что API Play Services запускаются в привилегированном процессе, отдельно от вашего приложения.Даже если у вашего приложения нет разрешений, Play Services может записывать файлы.К сожалению, выполнение в отдельном процессе не позволяет соседним соединениям записывать данные в хранилище вашего частного приложения.И это также означает, что, даже если вы не можете прочитать файл, вы по-прежнему отвечаете за его очистку или он останется на диске неопределенно долго.

Чтобы объяснить больше о проблеме, из-заотсутствие разрешений, вы не можете прочитать файл.Этот сбой кэшируется в тот момент, когда вы получаете onPayloadReceived.Я сообщу об ошибке, чтобы избежать кеширования ошибки, но потребуется много времени, чтобы исправить и отправить новый SDK.Обходные пути: ...

  • Запросите разрешение раньше, чем файл будет отправлен на ваше устройство.
  • Просмотрите файл вручную через ~ / Downloads / Nearby / {payloadId}.Обратите внимание, что это не рекомендуется, поскольку путь к файлу может измениться в любое время (хотя это маловероятно).Это похоже на использование отражения.
...