2017-01-24 1 views
0

Я застрял на этом в течение удивительно долгого времени и потратил много времени на поиск ответа, но не повезло.Можете только загрузить ParseFiles с тем же приложением, которое их загрузило

Я могу получить штраф ParseFile с:

ParseFile imageFile = parseObj.getParseFile("image"); 

Наряду с числами и строками и вещами.

Однако, когда я пытаюсь загрузить содержимое файла с:

imageFile.getDataInBackground(...) 

просьбы всегда раз с кодом 100 ошибки:

com.parse.RarseRequest$ParseRequestException: i/o failure 

С причиной данной как:

"Connection refused" 

Удивительно, но содержимое файла может быть загружено, если файл был загружен с тем же ap п. Даже разные приложения, которым присваивается одинаковый идентификатор приложения, клиентский ключ и адрес сервера как друг друга, не могут загружать файлы друг друга, хотя они могут загружать свои собственные. Я тестировал это как с приложениями Android, так и с iOS.

Когда файлы изображений загружаются приложениями, эти изображения видны (и могут быть загружены) через Parse Dashboard, однако только приложение, загрузившее файл, может загрузить его снова, и никакие приложения не могут загружать файлы, которые были загружены самой панелью анализа ,

В моем приложении объект Анализировать инициализируется с:

Parse.initialize(new Parse.Configuration.Builder(this) 
    .applicationId("App ID") 
    .clientKey("Client Key") 
    .server("http://server.com:1400/service_subdir").build() 

и файл сервера 'config.js' содержит:

config.appID = 'App ID'; 
config.clientKey = 'Client Key'; 
config.jsKey = 'Javascript Key'; 

Где "App ID" и "Client Key" являются идентичны в обоих случаях.

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

"http://server.com:1400/service_subdir/" 

URL-адрес, возвращаемый ParseFile является:

"url": "http://localhost:1400/different_service_dir/files/App ID/..._file.png" 

И для жизни меня я не могу тренировки почему.

Я могу (вроде) понять, почему «http://server.com:1400» заменен на «http://localhost:1400», но почему «service_subdir» изменен на «different_service_dir», полностью меня озадачивает. Даже файлы, загруженные непосредственно из панели анализа, когда они были извлечены, все же перечисляют «different_service_dir» в URL-адресе ParseFile (и не будут загружаться). Даже файлы, загруженные одним и тем же приложением (которые загружаются), перечисляют их URL-адреса с этим «different_service_dir», и я полностью потерял мнение о том, почему.

Спасибо за любую помощь, которую вы можете предоставить, Slarti.

+0

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

ответ

0

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

+0

Когда вы закончите с этим проектом, в Норвегии вам понадобятся фьорды, которые вам понадобятся. – David

+0

Спасибо Дэйву, но я не хочу ничего хранить в локальном хранилище. Тот факт, что он отображается в файлах, хранится локально моим приложением, но скрывает тот факт, что он не получает файлы с сервера, и если что-то удобное для удобства. Я хочу хранить изображения на сервере Parse и загружать их с помощью своего приложения. Это очень распространенное использование для Parse, однако по некоторым причинам кажется, что хотя мое приложение может «видеть» файлы на сервере, он не может загрузить данные внутри них. Кажется, теперь тот факт, что он мог «загружать» файлы, которые он загружал, является лишь уловкой. – Slartibartfast

+0

И да, я не могу дождаться возвращения в Норвегию. Мне нравятся эти сверкающие биты;) – Slartibartfast

Смежные вопросы