Из видео вы узнаете о различных API, которые помогут вам эффективнее работать с REST API, когда вы используете OkHttp и Retrofit
🔗 Подпишись на канал / @androidbroadcast
🔗 Avito.Tech avito.tech/
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon / android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
🔗 Мерч от Android Broadcast androidbroadcaststore.by/
🔗 OkHttp square.github.io/okhttp
🔗 Retrofit square.github.io/retrofit
🔗 MockWebServer github.com/square/okhttp/tree...
#AndroidBroadcast #REST #OkHttp #Retrofit #HTTP #HTTPS #Сеть #RESTAPI #androidstudio
0:00 Вступление
1:09 Retrofit
1:57 Интеграция АвитоТех
2:19 Жизненный цикл запроса
4:20 Кэширование
9:06 Interceptors
14:05 Таймауты
15:58 ConnectionPool
16:59 MockWebServer
18:11 Отладка сетевых запросов в Android Studio
22:00 Заключение
🔗 Avito.Tech avito.tech/ 💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast 🔗 Мерч от Android Broadcast androidbroadcaststore.by/
Кирилл, крутой формат, мне очень понравился. Реально экономит время и позволяет быстро ознакомиться с возможностями технологии
authenticator() использую для refreshToken-а. Т.е. если interceptor добавляет в хедер реквеста Bearer token (который имеет время жизни), то лямбда, переданная в authenticator(), вызовется в ответ на 401 Unauthorized в любом сделанном нами запросе (т.е. когда наш токен устарел). И таким образом, непосредственно в лямбде, которая передается в метод authenticator(), можно прописать реквест на апдейт токена)
в моем приложении на бэкенде аутентификация(access и refresh token) реализована через JWT(делал не я), возможно ли использовать Okhttp Interceptor что делать рефреша токена?
@@andriyshatynskyy5214 возможно. Но только не interceptor, а authenticator. Стандартный подход: Interceptor для добавления accessToken-а в хэдэр запроса, authenticator для обновления accessToken-а с помощью refreshToken-a когда первый протух(бэк должен вернуть 401 в этом случае)
@@BelokonRoman спасибо
Тоже самое, но самый явный недостаток Authenticator в том, что при параллельных запросах, все неавторизованные запросы вызывают его, и нужно вручную их синхронизировать
В обычном interceptor будет тоже самое, тоже нужно использовать синхронизацию. Я не стал использовать authenticator т.к. при использовании стандартных логов okhttp логи рефреша токена не отображаются.
Формат - топ! Спасибо за видео)
Крутяк! Кирилл, спасибо за труды.
не знал про Network inspector. Спасибо за просвещение!
Если backend не поддерживает Cache-Control, мы все ещё можем сделать активацию http cache на стороне клиента используя interceptor (возможно network interceptor, точно не помню) OkHttp. В interceptor мы модифицируемых response добавляя нужные headers как бы от сервера. Это быстрое решение, чтобы снизить нагрузку на backend.
Привет. Для работы с Cache-Control header через Retrofit, можно добавить доп параметр в метод API, с аннотацией Header, и подкладывать туда значение динамически.
Спасибо за видео!
Спасибо, очень полезно.
Классное видео, вот в таком формате топ
Очень интересный формат, ждём про другие инструменты!
Было бы интересно про OAUTH2
Очень крутое и понятное видео , спасибо !
Видос очень полезный, хотелось бе видеть больше всяких советов и best practices по retrofit.
По retrofit мало чего рассказывать. Простая и эффективная библиотека, без усложнений и лишнего API
Очень интересный видос, некоторого не знал
Кирилл, спасибо большое, как раз вопрос попался такой на собесе месяца полтора назад, все никак руки не доходили разобраться)
Что именно спросили?)
Спасибо, очень полезно. В тему отслеживания запросов - стоило рассказать про чакер.
Тулинг к теме видео особо не хотел подмешивать, а рассказать отдельно
Спасибо
Network Inspector - хорошая штука, но было бы ещё хорошо, если бы он показывал ещё попытки отправки запроса на сервер (когда получаешь UnknownServerException - сервер лег или интернет плохой)
Очень круто! Сделайте пожалуйста видео по paging3 component с добавление и удаление данные в позиции)
Видео про Paging 3 есть на канале kzhead.info/sun/bN6Pnb2Oe4aZeIU/bejne.html.
Крутой видос, познавательный, спасибо) Ещё для отслеживания сетевых запросов можно использовать прокси. Например Charles или бесплатный burpsuite. Нетворк менеджер не всегда подключен к приложению. А прокси, если правильно настроить, перехватывает трафик всегда. И если вдруг вылетел какой-то непонятный баг, то с прокси можно просто посмотреть, не бэк ли это непонятно что кинул. + в прокси, (по крайней мере Charles) есть возможности подмены, как запросов, так и ответов. А такие фичи, как перезаписывание ответа сервера из выбранного файла делают разработку/тестирование новых/измененных ручек ооочень удобным. Ctrl+s после изменения файлика в любимом редакторе и вуаля, приложению приходит новый ответ. Приложение не надо ни пересобирать, ни перезапускать. Правда такую точную инфу, как сколько сейчас конекшенов и как между ними распределились запросы прокси конечно не скажет, но в большинстве случаев это и не надо.
Charles - это прокси и больше подходит для тестирования, а вот сетевой инспектор предоставляет больше информации для отладки и понимания, где происходит проблема с вызовами. Инструменты не взаимозаменяемые
@@AndroidBroadcast Если надо поинспектить приложение, то полностью согласен. Но если использовать его чисто как просматривалку запросов/ответов, то они вполне взаимозаменяемые. Я именно такой юзкейс и имел ввиду. Мне показалось, что будет полезно упомянуть прокси. Вдруг для кого-то новенького это будет лучшей альтернативой, про которую он не знал.
Я использую Authenticator для работы с корпоративным OpenId. Использование Authenticator не освобождает от использования Interceptor. Через Authenticator удобно обновлять токен доступа, а через Interceptor добавлять его в заголовки запроса централизованно. На каждый уровень аутентификации добавляю Interceptor.
А если прокси и нетворк менеджер не подходят, то можно посмотреть в сторону hyperion. Его можно так интегрировать, что помимо его основных функций, будет перехватываться весь трафик и выводиться в приложении в специальное меню. Однако смотреть трафик с девайса - не самое удобное занятие, поэтому я бы это оставил как запасной вариант.
Спаассииибо
Формат отличный. Почти 10К подписчиков. Много это или нет - не знаю. Но думаю, что если все 10К - разработчики, то вполне неплохо!
Тоже задумываюсь этим вопросом. Даже непонятно какой объем этой аудитории
Стоить заметить что кешировпние доступно только для GET запросов, также стоит заметить что без хедеров кеша никакой кеш не будет доступный.
Спасибо за видос. Немного для меня не ясно с chain. Если я добавлю несколько интерсепторов (в одном, скажем добавлю user-agent, в другом упомянутый apikey), то будет ли запрос отправлен на сервер несколько раз, обрастая параметрами?
Обработчик перехватывает запрос который происходит в OkHttp и изменяет его или просто отслеживает. Т.е. это не создаёт дополнительный запрос к оригинальному и количество перехватчиком может быть сколь угодным
@@AndroidBroadcast спасибо большое!
Спасибо за видео. А как добавить tab Network inspector? У меня его нет. Благодарю.
Он появился в Android Studio Bumble в том виде в котором я показал. До этого он был в секции "Profilers"
Круто и как всегда вовремя) Друзья, а если в примере с апи-кеем он бы менялся со временем, то что делать тогда?
Надо просто сделать другую реализацию, где можно поменять ключ. Это не так сложно. Проблема в том что часть запросов может уйти со старым ключом
Круто! А что если делать интеграцию после введения и до кода. В текущем варианте сильно сбивает с мысли/настроя.
Хорошое предложение
Полезное видео, можно видео про как делать Refresh token ?
Универсальное нет, только если взять что у вас все сделано по зачёту OAuth 2.0, что я не встречал (
10:05 - тут даже больше поможет value class чем именнованные параметры. Потому что именованные параметры - это добровольное дело на вызывающей стороне, а если token обернуть в какой нибудь value class AccessToken(private val token: String),то на вызывающей стороне уже полюбому придется передавать нужный объект. Но при этом в скомпилированном коде будет просто строка
Только с ним должен уметь работать сериализатор
@@AndroidBroadcast в том то и прелесть value class-ов, что ничего дополнительно не надо, т.к. он в конечном счете бедут заменен на примитив, который не требует дополнительных сериализаторов\десереализаторов.
Не во всех случаях. Как раз-то в интерфейсе они могут остаться обычным классом. Посмотрите спецификацию их, там много случаев когда остаётся класс обёртка
@@AndroidBroadcast Я знаю. Но голая обертка над не null-овым аргументом всегда будет упрощена до примитива и при этом дает compile time гарантию, что туда не передадут ничего другого. В этом случае есть только выгоды и я не вижу никаких недостатков. А если вы уже начинаете наварачивать что то дополнительное в этоу обертку - то тогда надо уже переходить к обычному классу. Ну и если параметр может быть null - то тоже теряется вся прелесть этого value class-а. Это всего лишь вопрос правильного применения инструментов.
Конкретно в этом случае должно хватить и typealias
Можно сделать обёртку для okhttp (работает при чистом okhttp, при retrofit+okhttp и в кмм ktor+okhttp engine/ktor+Ios engine). Возвращает или Single/suspend, если надо что-то одно (кэш или апи), или Observable/Flow, если надо оба или одно, но в каком-то определённом порядке (с флагом откуда данные пришли).
А зачем?
@@AndroidBroadcast чтобы сразу показать контент, а не пустой экран (если у нас есть кэш и он не просрочился), и поверх него догрузить уже новый (если он есть). Конечно можно сделать всё нативно через рум, но тогда надо хендлить когда кэш просрочился, как-то хендлить размер кэша, как-то мержить квери для нескольких таблиц, если на одном экране несколько запросов и у них разные данные и другие заботы. Но если поиск или другие квери по БД не нужны, то зачем? С обёрткой код менять практически не надо будет, а так же сохраняется возможность комбайнить несколько запросов (если экран сложный и состоит из N запросов), флэтмапить их (при этом если хоть в одном запросе в цепочке "кэш" будет ошибка кэша, то вся цепочка проигнорится и будет грузить только апишная) или комбайнить кэш + не кэш (условно один поддерживает кэш, а второй нет, но мы хотим первый показать сразу и догружать, а второй просто догружать) без какой-либо мудрёной логики. Ретрофит по дефолту вернёт кэш, только если ошибка с интернетом (и при чём никак не скажет о том, что данные из кэша, а не из апи)
В каких случаях может понадобиться использовать какие-то библиотеки кроме retrofit? Например, тот же OkHttp в чистом виде или Volley?
Например, когда нужно делать тонкую настройку Http запроса в runtime. Retrofit позволяет эффективно работать с REST, т.е. есть четкий набор вызовов.
Network Inspector очень похож на раздел Network профайлера. Это одно и то же или они все же различаются?
Да, просто в последней студии произошло перемещение раздела
@@AndroidBroadcast А, вот в чем дело. Спасибо за ответ и за видео.
Как правильно выбрать резмер кэша?
Общего правила нет и зависит от многих факторов: что вы туда будете класть, как много данных будет, как долго вы ожидаете его хранение в кэше, сколько место у вас у телефоне и пр.
А будут видео как создавалось приложение для devtools?
Да, в ноябре буду кодить в прямом эфире
в своих пет проектах использую ktor 😎
Насколько помню на JVM он работает поверх OkHttp ?
Про кэш: я правильно понял, что нужно создавать специальную директорию на андройде и тогда там это все хранить? как тогда можно сделать эту директорию безопасной, чтоб никто не имел доступа к вашему кэшу?
Нужно создавать эту директорию на internal storage. Можно использовать Context.cacheDir
Формат отличный, от содержания ожидал большей глубины
Апикей он же токен, верно?
Это разные вещи, но работа с ними примерно одинаково осуществляется
можно сказать так , мы так же токены через интерцептеры для всех запросов выткаем
По поводу размера кеша. Неужели сам Android на уровне ОС не ограничивает это?
Есть стандартный контролируемый кэш, но никто не мешает вне его содержание дать папку и туда что-то складывать
@@AndroidBroadcast Да... Google прислушивается к пользователям, старается снизить уровень энергопотребления, работает над безопасностью и прочим. Но не может помешать разработчику завалить всю память в устройстве как раз навреное по этой причине, потому что функицонирование программы может нарушиться.
+
Видео немного на 2:23 обрезалось
Про жизненный цикл ничего не знал :|
Sps