Android studio api запрос

Android для начинающих: использование REST API

Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)

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

Это может звучать сложно, но с большим количеством сайтов, которые раскрывают свои ресурсы через REST API, на самом деле это довольно просто. (Смотрите руководство для начинающих по HTTP и REST для примера.)

В этом уроке я расскажу вам, как использовать классы и методы, доступные в Android SDK, для подключения к удаленным веб-серверам и взаимодействия с ними с использованием их REST API.

1. Включение доступа к Интернету

Использование REST API, очевидно, связано с использованием Интернета. Тем не менее, приложения Android могут получить доступ к Интернету только в том случае, если у них есть разрешение android.permission.INTERNET . Поэтому перед началом написания любого сетевого кода вы должны убедиться, что в файле манифеста вашего проекта присутствуют следующие uses-permission теги:

Поскольку android.permission.INTERNET не считается опасным разрешением, вам не нужно запрашивать его во время выполнения на устройствах с уровнем API 23 или выше.

2. Создание фоновых потоков

Платформа Android не позволяет выполнять сетевые операции в основном потоке приложения. Поэтому весь ваш сетевой код должен принадлежать фоновому потоку. Самый простой способ создать такой поток — использовать метод execute() класса AsyncTask . В качестве единственного аргумента execute() ожидает объект Runnable .

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

3. Создание HTTP-соединения

Используя метод openConnection() класса URL , вы можете быстро настроить соединение с любой конечной точкой REST. Возвращаемое значение openConnection() должно быть передано в экземпляр HttpURLConnection или HttpsURLConnection , в зависимости от доступа к конечной точке через HTTP или HTTPS. Оба HttpURLConnection и HttpsURLConnection позволяют выполнять такие операции, как добавление заголовков запросов и чтение ответов.

В следующем фрагменте кода показано, как настроить соединение с корневой конечной точкой API GitHub:

Обратите внимание, что HttpsURLConnection является подклассом класса HttpURLConnection .

4. Добавление заголовков запросов

Большинство веб-сайтов, предлагающих REST API, хотят иметь возможность однозначно идентифицировать ваше приложение. Самый простой способ помочь им сделать это — включить уникальный заголовок User-Agent во все ваши запросы.

Чтобы добавить заголовок User-Agent в ваш запрос, вы должны использовать метод setRequestProperty() объекта HttpURLConnection . Например, вот как вы устанавливаете заголовок User-Agent в my-rest-app-v0.1:

Вы можете добавить несколько заголовков к своему запросу, вызвав несколько раз метод setRequestProperty() . Например, следующий фрагмент кода добавляет заголовок Accept и кастомный заголовок Contact-Me :

5. Чтение ответов

После того как вы передали все заголовки запросов, вы можете проверить, есть ли у вас валидный ответ, используя метод getResponseCode() объекта HttpURLConnection .

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

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

Большинство REST API в наши дни возвращают данные, отформатированные как документы JSON. Поэтому, вместо прямого чтения из объекта InputStream , я предлагаю вам создать для него InputStreamReader .

6. Разбор JSON ответов

Android SDK имеет класс JsonReader, который позволяет легко разбирать документы JSON. Вы можете создать новый экземпляр класса JsonReader , передав объект InputStreamReader его конструктору.

То как вы извлекаете определенную часть информации из документа JSON, зависит от его структуры. Например, документ JSON, возвращаемый корневой конечной точкой REST API GitHub, выглядит следующим образом:

Как вы можете видеть, ответ — это только один большой объект JSON, содержащий несколько ключей. Чтобы извлечь из него значение с именем organization_url, вам нужно будет написать следующий код:

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

После того как вы извлечете всю необходимую информацию, вы всегда должны вызвать метод close() для объекта JsonReader , чтобы он освобождал все сохраненные ресурсы.

Вы также должны закрыть соединение, вызвав метод disconnect() объекта HttpURLConnection .

7. Использование разных HTTP методов

HTTP-интерфейсы REST используют методы HTTP для определения типа операции, которая должна выполняться над ресурсом. На предыдущих шагах мы использовали метод HTTP GET для выполнения операции чтения. Поскольку класс HttpURLConnection использует по умолчанию метод GET , нам не нужно было его явно указывать.

Чтобы изменить метод HTTP вашего объекта HttpURLConnection , вы должны использовать его метод setRequestMethod() . Например, следующий фрагмент кода открывает соединение с конечной точкой, принадлежащей httpbin.org, и устанавливает свой HTTP-метод в POST :

Как вы уже знаете, POST -запросы используются для отправки данных на сервер. При записи в выходной поток соединения вы можете легко добавить любые данные в тело запроса POST . Однако, прежде чем вы это сделаете, вы должны убедиться, что вы вызываете метод setDoOutput() объекта HttpURLConnection и передаете ему значение true .

В следующем фрагменте кода показано, как отправить на сервер простую пару «ключ-значение»:

8. Кэширование ответов

Всегда рекомендуется кэшировать ответы HTTP. Таким образом, вы можете не только сократить потребление пропускной способности вашего приложения, но и сделать его более отзывчивым. Начиная с уровня API 13, Android SDK предлагает класс HttpResponseCache , который позволяет легко реализовать кэширование без каких-либо изменений в вашей сетевой логике.

Чтобы установить кэш для вашего приложения, вы должны вызвать метод install() класса HttpResponseCache . Метод ожидает абсолютный путь, указывающий, где должен быть установлен кеш, и число, определяющее размер кеша. Вы можете использовать метод getCacheDir() , если вы не хотите указывать абсолютный путь вручную.

В следующем фрагменте кода устанавливается кеш размером 100 000 байт:

Как только кеш установлен, класс HttpURLConnection начинает использовать его автоматически. Чтобы проверить, работает ли ваш кеш, вы можете использовать его метод getHitCount() , который возвращает количество HTTP-ответов, которые были отправлены из кеша.

Заключение

Существуют тысячи REST API-интерфейсов, которые вы можете свободно использовать в своих приложениях для Android. Используя их, вы можете сделать ваше приложение более информативным, интересным и многофункциональным. В этом уроке вы узнали, как использовать класс HttpURLConnection для использования таких REST API. Вы также узнали, как создать кеш ответов HTTP, который снижает использование потребление сетевого трафика вашим приложением.

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

Чтобы узнать больше о работе с сетью на платформе Android, вы можете обратиться к руководству по сетевым операциям Android.

Источник

Изучение Android Studio за одну статью! Создание программы с API

ОС Андроид – одна из самых популярных ОС в мире. Мы подготовили большой урок по изучению программы Android Studio и построению полноценного Андроид приложения. За урок мы сделаем программу с API.

Информация про Андроид

На ОС Андроид сегодня работают не только мобильные и планшетные устройства, но также всевозможные часы, телевизоры, компьютеры и даже, как бы это не звучало, холодильники.

Несмотря на огромное множество устройств разработка под многие из них происходит через одну общую программу – Android Studio . Конечно же, у каждой платформы будут свои особенности: размер экрана, характеристики устройства и так далее. Тем не менее, общий процесс создания будет примерно схожим.

Таким образом, изучив Андроид Студио вы сможете в будущем спокойно переходить от одной платформы к другой. Напомним, на сегодняшний день только мобильные устройства на ОС Андроид занимают примерно 85% всего рынка смартфонов.

Языки программирования для Андроид

Разрабатывать под Андроид можно за использованием нескольких разных языков программирования. Зачастую все разрабатывают на основе языка Java, но помимо него можно использовать язык Kotlin, Python, React Native, Flutter и даже на HTML и CSS можно делать проекты.

Ниже видео на тему разработки Андроид проекта на HTML и CSS:

Вы можете использовать разные языки, но наиболее часто используется Джава или его более молодой собрат – Kotlin . В любом случае, если вы только приступаете к Андроид, то ни про какой другой язык помимо Джава вам не стоит думать. Если в будущем нужно будет писать на Котлин, то вам все равно знания разработки Андроид проектов на Джава будут нужны.

Установка всего необходимого

Для разработки под Андроид требуется всего две вещи. Во-первых, вам нужно скачать на компьютер Джава JDK. Это можно сделать через официальный сайт Oracle.

Во-вторых, вам потребуется программа Андроид Студио. Именно она является наиболее популярной программой для разработки приложений под Андроид. Скачать бесплатно эту программу можно также с ее официального сайта . После скачивания Джава и Андроид Студио выполните их установку и далее мы сможем приступить к разработке проекта.

Создание функций

Теперь нам нужно создать весь функционал для приложения.

В приложении мы будем получать данные о погоде. Чтобы это делать сперва зарегистрируйтесь и получите API ключ на сайте OpenWeaterMap .

Теперь остается прописать весь код. Код класса «MainActivity» представлен ниже вместе с комментариями.

Дополнительно скачать полностью весь проект можно по этой ссылке .

Видео на эту тему

Также вы можете просмотреть детальное видео по разработке данного приложения:

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

На нашем сайте также есть углубленный курс по изучению языка Java . В ходе огромной программы вы изучите не только язык Java, но также научитесь создавать веб сайты, программы под ПК, приложения под Андроид и многое другое. За курс вы изучите массу нового и к концу программы будете уметь работать с языком Java и создавать на нём полноценные проекты.

Источник

Сделать POST-запрос к Api в Android Studio

Я пытаюсь сделать запрос POST для API, который я создал в Visual Studio. API работает, и мне наконец-то удалось найти код, который позволяет мне подключаться к нему (и это не рекомендуется). Проблема в том, что этот код был создан для запроса GET, а мне нужно сделать POST. Я создал два блока, в которые вставляю данные, которые хочу передать (utente, пароль), и создал кнопку, которая берет данные из boxex и преобразует их в строку.

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

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

Может кто-нибудь объяснить мне, как взять данные и отправить их как объект JSON, который имеет

Ключи = пользователь, пароль

Values = utente, password (значения взяты из двух упомянутых выше полей)

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

Я использую Волей, так как это не так сложно и потому что, кажется, работает.

Используя метод GET, он показывает, что существующий json с сообщением не может быть преобразован в объект JSON (мне все равно, это просто подтверждение того, что он подключается к API)

Используя метод POST, он выдает ErrorResponse в конце (источник еды не отвечает)

РЕДАКТИРОВАТЬ: добавлен метод OnCreate, поскольку мне нужно возвращение StringRequest

РЕДАКТИРОВАТЬ. Я следовал предложенному ответу, но он не работает .

Полученный код показан ниже, но я получаю OnErrorResponse, я не думаю, что это проблема с API, потому что при попытке получить ответ GET он дает мне выходной массив json, поэтому я думаю, что это проблема с кодом.

Источник

RESTful API под Android: pattern B

Совсем недавно, на собеседовании в Яндексе, мне довелось обсуждать организацию Rest-взаимодействия в Android-приложениях. В ходе обсуждения всплыл вопрос – почему из трех паттернов, предложенных на Google IO 2010 Virgil Dobjanschi, первый используется существенно чаще двух других. Вопрос меня заинтересовал.

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

Краткое описание паттернов и обзор

(подробнее)

Pattern A	Pattern B	Pattern C
Используется Service API: Activity -> Service -> Content Provider. В данном варианте Activity работает с API Android Servcie. При необходимости послать REST-запрос Activity создает Service, Service асинхронно посылает запросы к REST-серверу и сохраняет результаты в Content Provider (sqlite). Activity получает уведомление о готовности данных и считывает результаты из Content Provider (sqlite).	Используется ContentProvider API: Activity -> Content Provider -> Service. В этом случае Activity работает с API Content Provider, который выступает фасадом для сервиса. Данный подход основан на схожести Content Provider API и REST API: GET REST эквивалентен select-запросу к базе данных, POST REST эквивалентен insert, PUT REST update, DELETE REST delete. Результаты Activity так же загружает из sqlite.	Используется Content Provider API + SyncAdapter: Activity -> Content Provider -> Sync Adapter. Вариация подхода «B», в котором вместо сервиса используется собственный Sync Adapter. Activity дает команду Content Provider, который переадресовывает ее в Sync Adapter. Sync Adapter вызывается из Sync Manager, но не сразу, а в «удобный» для системы момент. Т.е. возможны задержки в исполнении команд.

Беглый обзор подтвердил, что Pattern A используется действительно гораздо шире. Dv в своей замечательной статье «REST под Android. Часть 1: паттерны Virgil Dobjanschi» упоминает целый ряд библиотек и примеров реализации Pattern A (есть такой и на хабре), и всего один пример Pattern B – описание в книге «Programming Android, 2nd Edition» by Zigurd Mednieks, Laird Dornin, G. Blake Meike and Masumi Nakamura [1], в главе 13 «A Content Provider as a Facade for a RESTful Web Service», реализация есть на github.com. Других мне найти не удалось.
Чтение оригинала доклада Virgil Dobjanschi только добавило интриги.

Please note that in this particular pattern we broke the Content Provider contract a little bit. … Again, we’re not forcing you to adopt these particular design patterns.

В общем, не хотите – не используйте. Это воодушевляет.
Предлагаю кратко рассмотреть существующую реализацию Pattern B и попытаться понять, в чём же заключаются его особенности.

Приложение FinchVideo

Сразу отмечу, что этот код писался уважаемым G. Blake Meike в 2012 году, и с тех пор существенно не модифицировался, поэтому мы отнесёмся с пониманием к использованию всяких deprecated конструкций типа managedQuery, неиспользованию таких замечательных вещей как Loader, synchronized (HashMap) вместо ConcurrentHashMap и прочего – на архитектуру приложения они никак не влияют.

Итак, начнём с пользовательского интерфейса. В FinchVideoActivity всё вполне прозрачно – к ListView через SimpleCursorAdapter привязывается Cursor, в который и сливаются результаты запросов managedQuery к FinchVideoContentProvider.
Дальше – интереснее.

и HashMap — mRequestsInProgress (соответственно, набор выполняемых запросов). Обрабатываются результаты запросов в YouTubeHandler implements ResponseHandler, который и передаётся в задачу UriRequestTask при её создании.

Сопоставим существующие классы со схемой Pattern B.
С Activity и Content Provider всё достаточно ясно. Объект Service в явном виде в примере не используется, его функции и частично функции ServiceHelper по структурированию и запуску запросов выполняет FinchVideoContentProvider. Он же выполняет функции Processor, про Rest method написано выше. Такая вот упрощённая реализация.

Выводы

На основе анализа существующей реализации Pattern B и её описания, я сделал для себя следующие выводы

1. Самый большой плюс Pattern B, как и описывает автор примера в разделе «Summary of Benefits» [1 — стр. 369] – увеличенная производительность запросов, поскольку они в первую очередь осуществляются к локальной БД (Content Provider);
2. Обратная сторона этого плюса – рассогласование локальной и серверной БД и усложнённая логика получения данных.
   Неудивительно, что автор примера использовал только query (GET) запрос – это самый простой вариант. Не получили новые данные – возьмём старые из кэша. А если реализовывать insert (PUT)? Нужно будет сначала внести изменения в локальную БД, выставить им (изменениям) флаг «несинхронизировано», потом при неудачной попытке GET-запроса – повторять эту попытку, например с экспоненциально возрастающей паузой (как предлагает автор паттерна) … Всё это время пользователь будет видеть добавленные данные, которых нет на сервере. Более того, что их нет на сервере, он тоже узнать не сможет (см. пункт 3);
3. И неприятный побочный эффект, связанный с ограниченностью взаимодействия Activity с REST (только через механизмы Content Provider) – в GUI мы не можем получить ничего, кроме данных.
   К примеру, мы никогда не узнаем о причинах отсутствия данных. Ошибка в парсинге? Сервер ничего не вернул? Вообще нет сети? Результат один – нет данных. В реализации Pattern A для этой цели мы могли передать из Activity в ServiceHelper RequestListener. C Content Provider этот номер не пройдёт.
   Конечно, мы можем получить данные, например через Broadcast Receiver, и в обход Content Provider, но к Pattern B это уже не будет иметь отношения.

Таким образом, при использовании Pattern B необходимо учитывать вышеуказанные моменты.

Может быть, кто-нибудь использовал этот паттерн в рабочих проектах или знает более удачные примеры реализации? Есть ли вообще смысл реализовать его более качественно (была такая идея), если за 4 года этим никто не озаботился? Буду рад видеть ответы в комментариях.

Источник