Android support repository android studio

Как вручную установить вспомогательные библиотеки Android, необходимые для пакетов Xamarin.Android.Support?

Примеры шагов для Xamarin.Android.Support.v4

Загрузите нужный пакет NuGet для Xamarin.Android.Support (например, установите его с помощью диспетчера пакетов NuGet).

используйте ildasm , чтобы проверить, какая версия ildasm требуется для пакета NuGet.

Выходные данные примера:

Скачайте android_m2repository.zip из Google, используя URL-адрес, возвращенный программой Ildasm. Кроме того, вы можете проверить версию репозитория поддержки Android, установленного в настоящее время, в диспетчере SDK Android:

Если версия совпадает с версией, необходимой для пакета NuGet, вам не нужно загружать ничего нового. Вместо этого можно повторно заархивировать существующий каталог m2repository , расположенный в папке Екстрас\андроид в пути пакета SDK (как показано в верхней части окна диспетчера пакет SDK для Android).

Вычислите хэш MD5 URL-адреса, возвращенного из ildasm. Отформатируйте результирующую строку, чтобы использовались только прописные буквы без пробелов в строке. Например, $url при необходимости измените переменную, а затем выполните следующие 2 строки (на основе $url ) в PowerShell:

Выходные данные примера:

Скопируйте android_m2repository.zip в папку %локалаппдата%\ксамарин\зипс\ . Переименуйте файл, чтобы использовать хэш MD5 из предыдущего шага вычисления хэша MD5. Пример:

% LOCALAPPDATA% \Xamarin\zips\F16A3455987DBAE5783F058F19F7FCDF.zip

Используемых Распакуйте файл в %LocalAppData%\Xamarin\Xamarin.Android.support.v4\23.4.0.0\content\ (создание подкаталога content\m2repository ). Если пропустить этот шаг, то первая сборка, использующая библиотеку, займет немного больше времени, так как потребуется выполнить этот шаг. Номер версии для подкаталога (23.4.0.0 в этом примере) не совпадает с версией пакета NuGet. Чтобы найти правильный номер версии, можно использовать ildasm :

Выходные данные примера:

Загрузите нужный пакет NuGet для Xamarin.Android.Support (например, установите его с помощью диспетчера пакетов NuGet).

Дважды щелкните сборку Xamarin.Android.Support.v4 в разделе Ссылки проекта Android в Visual Studio для Mac, чтобы открыть сборку в обозревателе сборок. Убедитесь, что для раскрывающегося списка Язык выбрано значение C# , и выберите сборку Xamarin.Android.support.v4 в обозревателе сборок. Выберите свойство SourceUrl в одном из атрибутов IncludeAndroidResourcesFrom или JavaLibraryReference :

Скачайте android_m2repository.zip из Google с помощью команды, полученной от Ildasm. Кроме того, вы можете проверить версию репозитория поддержки Android, установленного в настоящее время, в диспетчере SDK Android:

Если версия совпадает с версией, необходимой для пакета NuGet, вам не нужно загружать ничего нового. Вместо этого можно повторно заархивировать существующий каталог m2repository, расположенный в разделе extras/android в путь_к_пакету_SDK (как показано в верхней части окна Диспетчера SDK Android).

Вычислите хэш MD5 URL-адреса, возвращенного из ildasm. Отформатируйте результирующую строку, чтобы использовались только прописные буквы без пробелов в строке. Например, при необходимости исправьте строку URL-адреса, а затем выполните следующую команду в командной строке Terminal.app:

Другой вариант — использовать csharp интерпретатор для выполнения того csharp . Для этого измените url переменную по необходимости, а затем выполните следующую команду в командной строке url :

Выходные данные примера:

Скопируйте android_m2repository.zip в папку $Home/.локал/шаре/ксамарин/зипс/ . Переименуйте файл, чтобы использовать хэш MD5 из предыдущего шага вычисления хэша MD5. Пример:

$HOME/.local/share/Xamarin/zips/F16A3455987DBAE5783F058F19F7FCDF.zip

(Необязательно) распакуйте файл в:

$HOME/.local/share/Xamarin/Xamarin.Android.Support.v4/23.4.0.0/content/

(создавая подкаталог content/m2repository). Если пропустить этот шаг, то первая сборка, использующая библиотеку, займет немного больше времени, так как потребуется выполнить этот шаг.

Номер версии для подкаталога (23.4.0.0 в этом примере) не совпадает с версией пакета NuGet. Как и на шаге ildasm ранее, чтобы найти правильный номер версии, можно использовать обозреватель сборок в Visual Studio для Mac. Найдите свойство Version в одном из атрибутов IncludeAndroidResourcesFrom или JavaLibraryReference :

Дополнительные ссылки

• Ошибка 43245 — неточные сообщения об ошибках «Загрузка не выполнена. Скачайте <0>и вставьте его в <1>каталог. «и» установите пакет: » <0>» доступно в установщике пакета SDK «сообщения об ошибках, связанные с пакетами Xamarin. Android. support.

Next Steps

В этом документе рассматривается текущее поведение по состоянию на август 2016 года. Методика, описанная в этом документе, не является частью стабильного набора тестов для Xamarin, поэтому в будущем ее поддержка может прерваться.

Чтобы получить дополнительную помощь, связаться с нами или если проблема остается даже после использования указанных выше сведений, сведения о способах связи, предложениях, а также о том, как при необходимости сообщить о новой ошибке, см. здесь.

Источник

Как добавить репозиторий поддержки Android в Android Studio?

Я использую Android Studio с внешним SDK для Android. Я установил библиотеку поддержки и репозиторий поддержки. Репозиторий поддержки находится в:

Когда я добавляю зависимость от библиотеки поддержки в файле build.gradle , например:

Android Studio не может найти библиотеки поддержки (не может разрешить символ и т. Д.), А Gradle также не может найти библиотеки:

Как указать в Android Studio и / или файле build.gradle расположение репозитория поддержки Android?

Вероятно, вы попали в эту ошибку, которая не позволяет плагину Android Gradle автоматически добавлять «Репозиторий поддержки Android» в список репозиториев Gradle. m2repository , как указано в отчете об ошибке, заключается в том, чтобы явно добавить каталог m2repository в качестве локального каталога Maven в файле build.gradle верхнего уровня:

Gradle может работать с нотами 18.0. +, Однако теперь это зависит от нового репозитория поддержки, который теперь входит в комплект SDK.

Откройте диспетчер SDK и сразу же в разделе «Дополнительно» первым вариантом является «Репозиторий поддержки Android» и установите его

1) Перейдите к тому месту, где находится ваш SDK, который использует студия / eclipse для Android. Если вы используете Android-студию Android, перейдите в extras\android\m2repository\com\android\support\ . Если вы используете eclipse, перейдите в \extras\android\support\

2) Посмотрите, какие у вас есть папки, для меня у меня были gridlayout-v7, support-v4 и support-v13.

3) нажмите на support-v4 и посмотрите, какой номер в следующей папке, мой был назван 13.0

Поскольку вы используете «com.android.support:support-v4:18.0.+», измените это, чтобы отразить, какая у вас версия, например, у меня есть поддержка-v4, поэтому первая часть v4 остается прежней. Поскольку следующий путь равен 13,0, измените свой 18.0 на:

Это сработало для меня, надеюсь, что это поможет!

Я заметил, что у меня была андроид-студия с неправильным SDK, поэтому изначально было трудно обновить! Путь должен быть C: \ Users \ Username \ AppData \ Local \ Android \ android-sdk \ extras \

Также обратите внимание, что если ваш SDK обновлен, код будет выглядеть следующим образом:

У меня были похожие проблемы. Даже после установки репозитория поддержки сборка, используемая для сбоя.

В основном проблемы связаны с тем, как указан номер версии файлов jar в файлах gradle.

Например, в моем случае я установил его как «compile» com.android.support:support-v4:21.0.3+ ‘»

При удалении «+» сборка была успешной!

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

1. Установите все последние вещи в SDK Manager
2. Проверьте, какая последняя версия (22.1.0 на момент написания этой статьи)
3. Обновите раздел dependencies build.gradle соответственно.

Я добавил «+» в конце вместо последнего номера, потому что видел другие ответы, и это, казалось, сработало, но я мог бы просто использовать полный номер версии без плюса.

Одна из возможных причин для этого заключается в том, что в документации говорится

Внимание. Использование динамических зависимостей, особенно для более высоких номеров версий, может привести к неожиданным обновлениям версии и несовместимости регрессии.

См. Также (документация):

• Поддержка библиотеки
• Настройка библиотеки поддержки
• Поддержка функций библиотеки

Источник

How to add Android Support Repository to Android Studio?

Posted by: admin January 4, 2018 Leave a comment

I’m using Android Studio with an external Android SDK. I have installed the support library and the support repository. The support repository is in:

When I add a dependency to the support library in the build.gradle file, like:

Android Studio cannot find the support libraries (cannot resolve symbol etc) and Gradle also cannot find the libraries:

How do I specify in Android Studio and/or the build.gradle file the location of the Android support repository?

You are probably hit by this bug which prevents the Android Gradle Plugin from automatically adding the “Android Support Repository” to the list of Gradle repositories. The work-around, as mentioned in the bug report, is to explicitly add the m2repository directory as a local Maven directory in the top-level build.gradle file:

Gradle can work with the 18.0.+ notation, it however now depends on the new support repository which is now bundled with the SDK.

Open the SDK manager and immediately under Extras the first option is “Android Support Repository” and install it

Found a solution.

1) Go to where your SDK is located that android studio/eclipse is using.
If you are using Android studio, go to extras\android\m2repository\com\android\support\ .
If you are using eclipse, go to \extras\android\support\

2) See what folders you have, for me I had gridlayout-v7, support-v4 and support-v13.

3) click into support-v4 and see what number the following folder is, mine was named 13.0

Since you are using “com.android.support:support-v4:18.0.+”, change this to reflect what version you have, for example I have support-v4 so first part v4 stays the same. Since the next path is 13.0, change your 18.0 to:

This worked for me, hope it helps!

I noticed I had android studio set up with the wrong SDK which is why originally had difficulty updating! The path should be C:\Users\Username\AppData\Local\Android\android-sdk\extras\

Also note, if your SDK is up to date, the code will be:

I didn’t have to worry about specifying any particular directories. I just did the following to update my support library to the latest revision:

1. Install all the latest things in the SDK Manager
2. Check what the latest revision is (26.1.0 at the time of this writing)
3. Update the dependencies section of build.gradle accordingly

Note that starting with Android Studio 3.0, you should use implementation rather than compile . (See this)

See also (documentation):

I used to get similar issues. Even after installing the support repository, the build used to fail.

Basically the issues is due to the way the version number of the jar files are specified in the gradle files are specified properly.

For example, in my case i had set it as “compile ‘com.android.support:support-v4:21.0.3+’”

On removing “+” the build was sucessful!!

Источник

Антипаттерн “Репозиторий” в Android

Перевод статьи подготовлен в преддверии старта курса «Android Developer. Professional».

Официальное руководство по архитектуре приложений Android рекомендует использовать классы репозитории (Repository) для «предоставления чистого API, чтобы остальная часть приложения могла легко извлекать данные». Однако, на мой взгляд, если вы будете использовать в своем проекте этот паттерн, вы гарантированно увязнете в грязном спагетти-коде.

В этой статье я расскажу вам о «паттерне Репозиторий» и объясню, почему он на самом деле является антипаттерном для Android приложений.

Репозиторий

В вышеупомянутом руководстве по архитектуре приложений рекомендуется следующая структура для организации логики уровня представления:

Роль объекта репозитория в этой структуре такова:

Модули репозитория обрабатывают операции с данными. Они предоставляют чистый API, чтобы остальная часть приложения могла легко извлекать эти данные. Они знают, откуда брать данные и какие вызовы API выполнять при их обновлении. Вы можете рассматривать репозитории как посредников между различными источниками данных, такими как постоянные модели, веб-службы и кэши.

По сути, руководство рекомендует использовать репозитории для абстрагирования источника данных в вашем приложении. Звучит очень разумно и даже полезно, не правда ли?

Однако давайте не будем забывать, что болтать — не мешки ворочать (в данном случае — писать код), а раскрывать архитектурные темы с помощью UML диаграмм — тем более. Настоящая проверка любого архитектурного паттерна — это реализация в коде с последующим выявлением его преимуществ и недостатков. Поэтому давайте подыщем для обзора что-нибудь менее абстрактное.

Репозиторий в Android Architecture Blueprints v2

Около двух лет назад я рецензировал «первую версию» Android Architecture Blueprints. По идее они должны были реализовывать чистый пример MVP, но на практике эти блюпринты вылились в достаточно грязную кодовую базу. Они действительно содержали интерфейсы с именами View и Presenter, но не устанавливали никаких архитектурных границ, так что это по сути был не MVP. Вы можете посмотреть данный код ревью здесь.

С тех пор Google обновил архитектурные блюпринты с использованием Kotlin, ViewModel и других «современных» практик, включая репозитории. Эти обновленные блюпринты получили приставку v2.

Давайте же посмотрим на интерфейс TasksRepository из блюпринтов v2:

Даже до начала чтения кода можно обратить внимание на размер этого интерфейса — это уже тревожный звоночек. Такое количество методов в одном интерфейсе вызвало бы вопросы даже в больших Android проектах, но мы говорим о приложении ToDo, в котором всего 2000 строк кода. Почему этому достаточно тривиальному приложению нужен класс с такой огромной поверхностью API?

Репозиторий как Божественный объект (God Object)

Ответ на вопрос из предыдущего раздела кроется в именах методов TasksRepository. Я могу примерно разделить методы этого интерфейса на три непересекающихся группы.

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

Группа 1 — это в основном реализация паттерна Observer с использованием средства LiveData. Группа 2 представляет собой шлюз к хранилищу данных плюс два метода refresh , которые необходимы, поскольку за репозиторием скрывается удаленное хранилище данных. Группа 3 содержит функциональные методы, которые в основном реализуют две части логики домена приложения (завершение задач и активация).

Итак, у этого единого интерфейса есть три разных круга обязанностей. Неудивительно, что он такой большой. И хотя можно утверждать, что наличие первой и второй группы как части единого интерфейса допустимо, добавление третьей — неоправданно. Если этот проект нужно будет развивать дальше и он станет настоящим приложением для Android, третья группа будет расти прямо пропорционально количеству потоков доменов в проекте. Мда.

У нас есть специальный термин для классов, которые объединяют так много обязанностей: Божественные объекты. Это широко распространенный антипаттерн в приложениях на Android. Activitie и Fragment являются стандартными подозреваемыми в этом контексте, но другие классы тоже могут вырождаться в Божественные объекты. Особенно, если их имена заканчиваются на “Manager”, верно?

Погодите… Мне кажется, я нашел более подходящее название для TasksRepository:

Теперь имя этого интерфейса намного лучше отражает его обязанности!

Анемичные репозитории

Здесь вы можете спросить: «Если я вынесу доменную логику из репозитория, решит ли это проблему?». Что ж, вернемся к «архитектурной диаграмме» из руководства Google.

Если вы захотите извлечь, скажем, методы completeTask из TasksRepository, куда бы вы их поместили? Согласно рекомендованной Google «архитектуре», вам нужно будет перенести эту логику в одну из ваших ViewModel. Это не кажется таким уж плохим решением, но как раз таким оно на самом деле и является.

Например, представьте, что вы помещаете эту логику в одну ViewModel. Затем, через месяц, ваш менеджер по работе с клиентами хочет разрешить пользователям выполнять задачи с нескольких экранов (это релевантно по отношению ко всем ToDo менеджерам, которые я когда-либо использовал). Логика внутри ViewModel не может использоваться повторно, поэтому вам нужно либо продублировать ее, либо вернуть в TasksRepository. Очевидно, что оба подхода плохи.

Лучшим подходом было бы извлечь этот доменный поток в специальный объект, а затем поместить его между ViewModel и репозиторием. Затем разные ViewModel смогут повторно использовать этот объект для выполнения этого конкретного потока. Эти объекты известны как «варианты использования» или «взаимодействия». Однако, если вы добавите варианты использования в свою кодовую базу, репозитории станут по сути бесполезным шаблоном. Что бы они ни делали, это будет лучше сочетаться с вариантами использования. Габор Варади уже освещал эту тему в этой статье, поэтому я не буду вдаваться в подробности. Я подписываюсь почти под всем, что он сказал о «анемичных репозиториях».

Но почему варианты использования намного лучше репозиториев? Ответ прост: варианты использования инкапсулируют отдельные потоки. Следовательно, вместо одного репозитория (для каждой концепции домена), который постепенно разрастается в Божественный объект, у вас будет несколько узконаправленных классов вариантов использования. Если поток зависит от сети, и от хранимых данных, вы можете передать соответствующие абстракции в класс варианта использования, и он будет «проводить арбитраж» между этими источниками.

В общем, похоже, что единственный способ предотвратить деградацию репозиториев до Божественных классов, избегая при этом ненужных абстракций, — это избавиться от репозиториев.

Репозитории вне Android.

Теперь вы можете задаться вопросом, являются ли репозитории изобретением Google. Нет, не являются. Шаблон репозитория был описан задолго до того, как Google решил использовать его в своем «руководстве по архитектуре».

Например, Мартин Фаулер описал репозитории в своей книге «Паттерны архитектуры корпоративных приложений». В его блоге также есть гостевая статья, описывающая ту же концепцию. По словам Фаулера, репозиторий — это просто оболочка вокруг уровня хранения данных, которая предоставляет интерфейс запросов более высокого уровня и, возможно, кэширование в памяти. Я бы сказал, что, с точки зрения Фаулера, репозитории ведут себя как ORM.

Эрик Эванс в своей книге Domain Driven Design также описывал репозитории. Он написал:

Клиенты запрашивают объекты из репозитория, используя методы запросов, которые выбирают объекты на основе критериев, указанных клиентом — обычно значения определенных атрибутов. Репозиторий извлекает запрошенный объект, инкапсулируя механизм запросов к базе данных и сопоставления метаданных. Репозитории могут реализовывать различные запросы, которые выбирают объекты на основе любых критериев, которые требует клиент.

Обратите внимание, что вы можете заменить «репозиторий» в приведенной выше цитате на «Room ORM», и это все равно будет иметь смысл. Итак, в контексте Domain Driven Design репозиторий — это ORM (реализованный вручную или с использованием стороннего фреймворка).

Как видите, репозиторий не был изобретен в мире Android. Это очень разумный паттерн проектирования, на котором построены все ORM фреймворки. Однако обратите внимание, чем репозитории не являются: никто из «классиков» никогда не утверждал, что репозитории должны пытаться абстрагироваться от различия между доступом к сети и к базе данных.

На самом деле, я почти уверен, что они сочтут эту идею наивной и обреченной на провал. Чтобы понять, почему, вы можете прочитать другую статью, на этот раз Джоэла Спольски (основателя StackOverflow), под названием «Закон дырявых абстракций». Проще говоря: работа в сети слишком отличается от доступа к базе данных, чтобы ее можно было абстрагировать без значительных «утечек».

Как репозиторий стал антипаттерном в Android

Итак, неужели в Google неверно истолковали паттерн репозитория и внедрили в него «наивную» идею абстрагироваться от доступа к сети? Я в этом сомневаюсь.

Я нашел самую древнюю ссылку на этот антипаттерн в этом репозитории на GitHub, который, к сожалению, является очень популярным ресурсом. Я не знаю, изобрел ли этот антипаттерн конкретно этот автор, но похоже, что именно это репо популяризировало общую идею внутри экосистемы Android. Разработчики Google, вероятно, взяли его оттуда или из одного из вторичных источников.

Заключение

Итак, репозиторий в Android превратился в антипаттерн. Он хорошо выглядит на бумаге, но становится проблематичным даже в тривиальных приложениях и может вылиться в настоящие проблемы в более крупных проектах.

Например, в другом «блюпринте» Google, на этот раз для архитектурных компонентов, использование репозиториев в конечном итоге привело к таким жемчужинам, как NetworkBoundResource. Имейте в виду, что образец браузера GitHub по-прежнему является крошечным

2 KLOC приложением.

Насколько я убедился, «паттерн репозитория», как он определен в официальных документах, несовместим с чистым и поддерживаемым кодом.

Спасибо за прочтение и, как обычно, вы можете оставлять свои комментарии и вопросы ниже.

Источник