Доступ к облачному хранилищу с Android ⇐ Android
-
Гость
Доступ к облачному хранилищу с Android
Мне не удалось найти конкретную документацию по использованию Cloud Storage из приложения Android.
Я наткнулся на эту клиентскую библиотеку из Google Cloud SDK, однако столкнулся с множеством проблем, и мне до сих пор не удалось заставить ее работать.
Я добавил следующий код, как рекомендовано в ссылке выше:
build.gradle:
группа компиляции: «com.google.cloud», имя: «google-cloud-storage», версия: «0.9.3-beta» Затем я добавил простой код, хотя это не имеет особого отношения к данному вопросу, поскольку мне еще не удалось запустить свое приложение с добавленной выше зависимостью:
В действии:
Хранилище хранилища = StorageOptions.getDefaultInstance().getService(); Ведра Page = Storage.list(); Iterator BucketIterator = Buckets.iterateAll(); в то время как (bucketIterator.hasNext()) { Ведро Ведро = BucketIterator.next(); Log.d(TAG, "Имя сегмента: " + Bucket.getName()); } После решения множества проблем с зависимостями (конфликты с Joda, Netty, DuplateFileException из gradle и т. д.) мне удалось собрать проект, хотя и со следующими ошибками:
>
Внимание: ПРЕДУПРЕЖДЕНИЕ: Зависимость org.apache.httpcomComponents:httpclient:4.0.1 игнорируется при отладке, поскольку она может конфликтовать с внутренней версией, предоставляемой Android. Внимание: ПРЕДУПРЕЖДЕНИЕ: Зависимость org.json:json:20151123 игнорируется при отладке, поскольку она может конфликтовать с внутренней версией, предоставляемой Android.
Затем я могу попробовать запуститься, но это завершится неудачно с несколькими сотнями ошибок, большинство из которых выглядят примерно так:
Ошибка: предупреждение: игнорирование атрибута InnerClasses для анонимного внутреннего класса Ошибка: (com.google.inject.internal.cglib.reflect.$FastClassEmitter$3), которая не поставляется с Ошибка: связанный атрибут EnclosingMethod. Вероятно, этот класс был создан Ошибка: компилятор, не ориентированный на современный формат файлов .class. Рекомендуемый Ошибка: решение — перекомпилировать класс из исходного кода, используя обновленный компилятор. Ошибка: и без указания каких-либо опций типа «-target». Последствия игнорирования Ошибка: это предупреждение заключается в том, что рефлексивные операции над этим классом будут выполняться неправильно. Ошибка: укажите, что это *не* внутренний класс. После многих из них с разными именами классов в конце ошибки появляется следующее:
проблема с обработкой "javax/transaction/HeuristicCommitException.class":
Ошибочное или ошибочное использование основного класса (java.* или javax.*), когда не создавать основную библиотеку.
Часто это происходит из-за случайного включения файла основной библиотеки в проект вашего приложения при использовании IDE (например, Eclipse). Если вы уверены, что не определяете основной класс намеренно, тогда это это наиболее вероятное объяснение происходящего.
Однако на самом деле вы можете попытаться определить класс в ядре пространство имен, источник которого вы могли взять, например, из проект виртуальной машины, отличной от Android. Это наверняка не будет работа. Как минимум, это ставит под угрозу совместимость вашего приложения с будущие версии платформы. Это также часто вызывает сомнения законность.
Если вы действительно намерены создать базовую библиотеку, а это всего лишь подходит как часть создания полного дистрибутива виртуальной машины, в отличие от компиляции приложения - тогда используйте Опция «--core-library» для подавления этого сообщения об ошибке.
Если вы используете «--core-library», но на самом деле создаете приложение, то имейте в виду, что ваше приложение по-прежнему не будет работать построить или запустить в какой-то момент. Пожалуйста, будьте готовы к разгневанным клиентам которые обнаруживают, например, что ваше приложение однажды перестает работать они обновляют свою операционную систему. Ты будешь виноват в этом проблема.
Если вы законно используете код, который находится в ядре пакет, то самая простая и безопасная альтернатива — переупаковать этот код. То есть переместите рассматриваемые классы в свой собственный пакет. пространство имен. Это означает, что они никогда не будут конфликтовать с ядром системные классы. JarJar — это инструмент, который может помочь вам в этом начинании. Если вы обнаружите, что не можете этого сделать, то это признак того, что путь, по которому вы идете, в конечном итоге приведет к боли, страданию, горю, и плач.
Несколько вопросов:
[*]Является ли эта клиентская библиотека правильным способом доступа к моему облачному хранилищу Google из моего приложения Android? [*]Есть ли причина, по которой мне не следует пытаться получить доступ к Cloud Storage из мобильного приложения? Например, было бы лучшей архитектурой сделать вызов REST API к моему приложению App Engine (с использованием Cloud Enpoints) и передать ему медиа-объекты, затем получить доступ к приложению App Engine и сохранить мультимедиа в облачном хранилище, прежде чем окончательно вернуть результат. в мобильное приложение? [*]Если я правильно получаю доступ к облачному хранилищу, используя указанную клиентскую библиотеку, что означают эти ошибки и как их можно исправить?
Мне не удалось найти конкретную документацию по использованию Cloud Storage из приложения Android.
Я наткнулся на эту клиентскую библиотеку из Google Cloud SDK, однако столкнулся с множеством проблем, и мне до сих пор не удалось заставить ее работать.
Я добавил следующий код, как рекомендовано в ссылке выше:
build.gradle:
группа компиляции: «com.google.cloud», имя: «google-cloud-storage», версия: «0.9.3-beta» Затем я добавил простой код, хотя это не имеет особого отношения к данному вопросу, поскольку мне еще не удалось запустить свое приложение с добавленной выше зависимостью:
В действии:
Хранилище хранилища = StorageOptions.getDefaultInstance().getService(); Ведра Page = Storage.list(); Iterator BucketIterator = Buckets.iterateAll(); в то время как (bucketIterator.hasNext()) { Ведро Ведро = BucketIterator.next(); Log.d(TAG, "Имя сегмента: " + Bucket.getName()); } После решения множества проблем с зависимостями (конфликты с Joda, Netty, DuplateFileException из gradle и т. д.) мне удалось собрать проект, хотя и со следующими ошибками:
>
Внимание: ПРЕДУПРЕЖДЕНИЕ: Зависимость org.apache.httpcomComponents:httpclient:4.0.1 игнорируется при отладке, поскольку она может конфликтовать с внутренней версией, предоставляемой Android. Внимание: ПРЕДУПРЕЖДЕНИЕ: Зависимость org.json:json:20151123 игнорируется при отладке, поскольку она может конфликтовать с внутренней версией, предоставляемой Android.
Затем я могу попробовать запуститься, но это завершится неудачно с несколькими сотнями ошибок, большинство из которых выглядят примерно так:
Ошибка: предупреждение: игнорирование атрибута InnerClasses для анонимного внутреннего класса Ошибка: (com.google.inject.internal.cglib.reflect.$FastClassEmitter$3), которая не поставляется с Ошибка: связанный атрибут EnclosingMethod. Вероятно, этот класс был создан Ошибка: компилятор, не ориентированный на современный формат файлов .class. Рекомендуемый Ошибка: решение — перекомпилировать класс из исходного кода, используя обновленный компилятор. Ошибка: и без указания каких-либо опций типа «-target». Последствия игнорирования Ошибка: это предупреждение заключается в том, что рефлексивные операции над этим классом будут выполняться неправильно. Ошибка: укажите, что это *не* внутренний класс. После многих из них с разными именами классов в конце ошибки появляется следующее:
проблема с обработкой "javax/transaction/HeuristicCommitException.class":
Ошибочное или ошибочное использование основного класса (java.* или javax.*), когда не создавать основную библиотеку.
Часто это происходит из-за случайного включения файла основной библиотеки в проект вашего приложения при использовании IDE (например, Eclipse). Если вы уверены, что не определяете основной класс намеренно, тогда это это наиболее вероятное объяснение происходящего.
Однако на самом деле вы можете попытаться определить класс в ядре пространство имен, источник которого вы могли взять, например, из проект виртуальной машины, отличной от Android. Это наверняка не будет работа. Как минимум, это ставит под угрозу совместимость вашего приложения с будущие версии платформы. Это также часто вызывает сомнения законность.
Если вы действительно намерены создать базовую библиотеку, а это всего лишь подходит как часть создания полного дистрибутива виртуальной машины, в отличие от компиляции приложения - тогда используйте Опция «--core-library» для подавления этого сообщения об ошибке.
Если вы используете «--core-library», но на самом деле создаете приложение, то имейте в виду, что ваше приложение по-прежнему не будет работать построить или запустить в какой-то момент. Пожалуйста, будьте готовы к разгневанным клиентам которые обнаруживают, например, что ваше приложение однажды перестает работать они обновляют свою операционную систему. Ты будешь виноват в этом проблема.
Если вы законно используете код, который находится в ядре пакет, то самая простая и безопасная альтернатива — переупаковать этот код. То есть переместите рассматриваемые классы в свой собственный пакет. пространство имен. Это означает, что они никогда не будут конфликтовать с ядром системные классы. JarJar — это инструмент, который может помочь вам в этом начинании. Если вы обнаружите, что не можете этого сделать, то это признак того, что путь, по которому вы идете, в конечном итоге приведет к боли, страданию, горю, и плач.
Несколько вопросов:
[*]Является ли эта клиентская библиотека правильным способом доступа к моему облачному хранилищу Google из моего приложения Android? [*]Есть ли причина, по которой мне не следует пытаться получить доступ к Cloud Storage из мобильного приложения? Например, было бы лучшей архитектурой сделать вызов REST API к моему приложению App Engine (с использованием Cloud Enpoints) и передать ему медиа-объекты, затем получить доступ к приложению App Engine и сохранить мультимедиа в облачном хранилище, прежде чем окончательно вернуть результат. в мобильное приложение? [*]Если я правильно получаю доступ к облачному хранилищу, используя указанную клиентскую библиотеку, что означают эти ошибки и как их можно исправить?
Мобильная версия