Возможности OkHttp о которых вы не знали

[@AndroidBroadcast]

🔗 Avito.Tech avito.tech/ 💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast 🔗 Мерч от Android Broadcast androidbroadcaststore.by/

[@SergeyJasfex]

Кирилл, крутой формат, мне очень понравился. Реально экономит время и позволяет быстро ознакомиться с возможностями технологии

[@sergeykharuk5614]

authenticator() использую для refreshToken-а. Т.е. если interceptor добавляет в хедер реквеста Bearer token (который имеет время жизни), то лямбда, переданная в authenticator(), вызовется в ответ на 401 Unauthorized в любом сделанном нами запросе (т.е. когда наш токен устарел). И таким образом, непосредственно в лямбде, которая передается в метод authenticator(), можно прописать реквест на апдейт токена)

[@andriyshatynskyy5214]

в моем приложении на бэкенде аутентификация(access и refresh token) реализована через JWT(делал не я), возможно ли использовать Okhttp Interceptor что делать рефреша токена?

[@BelokonRoman]

@@andriyshatynskyy5214 возможно. Но только не interceptor, а authenticator. Стандартный подход: Interceptor для добавления accessToken-а в хэдэр запроса, authenticator для обновления accessToken-а с помощью refreshToken-a когда первый протух(бэк должен вернуть 401 в этом случае)

[@andriyshatynskyy5214]

@@BelokonRoman спасибо

[@aidardauylbay8116]

Тоже самое, но самый явный недостаток Authenticator в том, что при параллельных запросах, все неавторизованные запросы вызывают его, и нужно вручную их синхронизировать

[@RussianTeaMachine]

В обычном interceptor будет тоже самое, тоже нужно использовать синхронизацию. Я не стал использовать authenticator т.к. при использовании стандартных логов okhttp логи рефреша токена не отображаются.

[@ultraon83]

Если backend не поддерживает Cache-Control, мы все ещё можем сделать активацию http cache на стороне клиента используя interceptor (возможно network interceptor, точно не помню) OkHttp. В interceptor мы модифицируемых response добавляя нужные headers как бы от сервера. Это быстрое решение, чтобы снизить нагрузку на backend.

[@Nomad7541]

Очень интересный формат, ждём про другие инструменты!

[@матжонфаттоев-щ5ш]

Было бы интересно про OAUTH2

[@АлександрГапанович-ы6т]

Кирилл, спасибо большое, как раз вопрос попался такой на собесе месяца полтора назад, все никак руки не доходили разобраться)

[@tyt66612]

Что именно спросили?)

[@user-sankarsana]

Крутяк! Кирилл, спасибо за труды.

[@ultraon83]

Привет. Для работы с Cache-Control header через Retrofit, можно добавить доп параметр в метод API, с аннотацией Header, и подкладывать туда значение динамически.

[@qIKraytonIp]

Видос очень полезный, хотелось бе видеть больше всяких советов и best practices по retrofit.

[@AndroidBroadcast]

По retrofit мало чего рассказывать. Простая и эффективная библиотека, без усложнений и лишнего API

[@androidkotlin-6234]

не знал про Network inspector. Спасибо за просвещение!

[@shrekinator8000]

Формат отличный. Почти 10К подписчиков. Много это или нет - не знаю. Но думаю, что если все 10К - разработчики, то вполне неплохо!

[@AndroidBroadcast]

Тоже задумываюсь этим вопросом. Даже непонятно какой объем этой аудитории

[@ВиталийПерятин-с2ц]

Формат - топ! Спасибо за видео)

[@it-vk8ik]

Спасибо, очень полезно.

[@bolnoi8]

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

[@AndroidBroadcast]

Тулинг к теме видео особо не хотел подмешивать, а рассказать отдельно

[@thunderdoge]

Спасибо за видео!

[@mikhailtarasov7403]

Очень крутое и понятное видео , спасибо !

[@turlir]

Я использую Authenticator для работы с корпоративным OpenId. Использование Authenticator не освобождает от использования Interceptor. Через Authenticator удобно обновлять токен доступа, а через Interceptor добавлять его в заголовки запроса централизованно. На каждый уровень аутентификации добавляю Interceptor.

[@nazirjonm6560]

Очень круто! Сделайте пожалуйста видео по paging3 component с добавление и удаление данные в позиции)

[@AndroidBroadcast]

Видео про Paging 3 есть на канале kzbin.info/www/bejne/b6u5noyMebmWe68.

[@romankryvolapov]

Очень интересный видос, некоторого не знал

[@hievery9678]

Крутой видос, познавательный, спасибо) Ещё для отслеживания сетевых запросов можно использовать прокси. Например Charles или бесплатный burpsuite. Нетворк менеджер не всегда подключен к приложению. А прокси, если правильно настроить, перехватывает трафик всегда. И если вдруг вылетел какой-то непонятный баг, то с прокси можно просто посмотреть, не бэк ли это непонятно что кинул. + в прокси, (по крайней мере Charles) есть возможности подмены, как запросов, так и ответов. А такие фичи, как перезаписывание ответа сервера из выбранного файла делают разработку/тестирование новых/измененных ручек ооочень удобным. Ctrl+s после изменения файлика в любимом редакторе и вуаля, приложению приходит новый ответ. Приложение не надо ни пересобирать, ни перезапускать. Правда такую точную инфу, как сколько сейчас конекшенов и как между ними распределились запросы прокси конечно не скажет, но в большинстве случаев это и не надо.

[@AndroidBroadcast]

Charles - это прокси и больше подходит для тестирования, а вот сетевой инспектор предоставляет больше информации для отладки и понимания, где происходит проблема с вызовами. Инструменты не взаимозаменяемые

[@hievery9678]

@@AndroidBroadcast Если надо поинспектить приложение, то полностью согласен. Но если использовать его чисто как просматривалку запросов/ответов, то они вполне взаимозаменяемые. Я именно такой юзкейс и имел ввиду. Мне показалось, что будет полезно упомянуть прокси. Вдруг для кого-то новенького это будет лучшей альтернативой, про которую он не знал.

[@kirillsushilnikov9614]

Network Inspector - хорошая штука, но было бы ещё хорошо, если бы он показывал ещё попытки отправки запроса на сервер (когда получаешь UnknownServerException - сервер лег или интернет плохой)

[@radpem]

Классное видео, вот в таком формате топ

[@BelokonRoman]

10:05 - тут даже больше поможет value class чем именнованные параметры. Потому что именованные параметры - это добровольное дело на вызывающей стороне, а если token обернуть в какой нибудь value class AccessToken(private val token: String),то на вызывающей стороне уже полюбому придется передавать нужный объект. Но при этом в скомпилированном коде будет просто строка

[@AndroidBroadcast]

Только с ним должен уметь работать сериализатор

[@BelokonRoman]

@@AndroidBroadcast в том то и прелесть value class-ов, что ничего дополнительно не надо, т.к. он в конечном счете бедут заменен на примитив, который не требует дополнительных сериализаторов\десереализаторов.

[@AndroidBroadcast]

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

[@BelokonRoman]

@@AndroidBroadcast Я знаю. Но голая обертка над не null-овым аргументом всегда будет упрощена до примитива и при этом дает compile time гарантию, что туда не передадут ничего другого. В этом случае есть только выгоды и я не вижу никаких недостатков. А если вы уже начинаете наварачивать что то дополнительное в этоу обертку - то тогда надо уже переходить к обычному классу. Ну и если параметр может быть null - то тоже теряется вся прелесть этого value class-а. Это всего лишь вопрос правильного применения инструментов.

[@DonkeyKong68]

Конкретно в этом случае должно хватить и typealias

[@arsenthompson]

Спаассииибо

[@pasha09090]

Спасибо

[@mamyna_bysinka]

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

[@bekaryssailaukul1006]

Полезное видео, можно видео про как делать Refresh token ?

[@AndroidBroadcast]

Универсальное нет, только если взять что у вас все сделано по зачёту OAuth 2.0, что я не встречал (

[@LazyTram911]

Круто и как всегда вовремя) Друзья, а если в примере с апи-кеем он бы менялся со временем, то что делать тогда?

[@AndroidBroadcast]

Надо просто сделать другую реализацию, где можно поменять ключ. Это не так сложно. Проблема в том что часть запросов может уйти со старым ключом

[@kirillsushilnikov9614]

Спасибо за видос. Немного для меня не ясно с chain. Если я добавлю несколько интерсепторов (в одном, скажем добавлю user-agent, в другом упомянутый apikey), то будет ли запрос отправлен на сервер несколько раз, обрастая параметрами?

[@AndroidBroadcast]

Обработчик перехватывает запрос который происходит в OkHttp и изменяет его или просто отслеживает. Т.е. это не создаёт дополнительный запрос к оригинальному и количество перехватчиком может быть сколь угодным

[@kirillsushilnikov9614]

@@AndroidBroadcast спасибо большое!

[@hievery9678]

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

[@itgik]

Спасибо за видео. А как добавить tab Network inspector? У меня его нет. Благодарю.

[@AndroidBroadcast]

Он появился в Android Studio Bumble в том виде в котором я показал. До этого он был в секции "Profilers"

[@Mazaxict11]

Как правильно выбрать резмер кэша?

[@AndroidBroadcast]

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

[@malchikovma]

В каких случаях может понадобиться использовать какие-то библиотеки кроме retrofit? Например, тот же OkHttp в чистом виде или Volley?

[@AndroidBroadcast]

Например, когда нужно делать тонкую настройку Http запроса в runtime. Retrofit позволяет эффективно работать с REST, т.е. есть четкий набор вызовов.

[@ИванКурак-п3е]

А будут видео как создавалось приложение для devtools?

[@AndroidBroadcast]

Да, в ноябре буду кодить в прямом эфире

[@AndreyDerkach8]

в своих пет проектах использую ktor 😎

[@AndroidBroadcast]

Насколько помню на JVM он работает поверх OkHttp ?

[@danik030699]

Круто! А что если делать интеграцию после введения и до кода. В текущем варианте сильно сбивает с мысли/настроя.

[@AndroidBroadcast]

Хорошое предложение

[@WoffkaG94]

Можно сделать обёртку для okhttp (работает при чистом okhttp, при retrofit+okhttp и в кмм ktor+okhttp engine/ktor+Ios engine). Возвращает или Single/suspend, если надо что-то одно (кэш или апи), или Observable/Flow, если надо оба или одно, но в каком-то определённом порядке (с флагом откуда данные пришли).

[@AndroidBroadcast]

А зачем?

[@WoffkaG94]

​@@AndroidBroadcast чтобы сразу показать контент, а не пустой экран (если у нас есть кэш и он не просрочился), и поверх него догрузить уже новый (если он есть). Конечно можно сделать всё нативно через рум, но тогда надо хендлить когда кэш просрочился, как-то хендлить размер кэша, как-то мержить квери для нескольких таблиц, если на одном экране несколько запросов и у них разные данные и другие заботы. Но если поиск или другие квери по БД не нужны, то зачем? С обёрткой код менять практически не надо будет, а так же сохраняется возможность комбайнить несколько запросов (если экран сложный и состоит из N запросов), флэтмапить их (при этом если хоть в одном запросе в цепочке "кэш" будет ошибка кэша, то вся цепочка проигнорится и будет грузить только апишная) или комбайнить кэш + не кэш (условно один поддерживает кэш, а второй нет, но мы хотим первый показать сразу и догружать, а второй просто догружать) без какой-либо мудрёной логики. Ретрофит по дефолту вернёт кэш, только если ошибка с интернетом (и при чём никак не скажет о том, что данные из кэша, а не из апи)

[@kirillsushilnikov9614]

Network Inspector очень похож на раздел Network профайлера. Это одно и то же или они все же различаются?

[@AndroidBroadcast]

Да, просто в последней студии произошло перемещение раздела

[@kirillsushilnikov9614]

@@AndroidBroadcast А, вот в чем дело. Спасибо за ответ и за видео.

[@kirillsushilnikov9614]

По поводу размера кеша. Неужели сам Android на уровне ОС не ограничивает это?

[@AndroidBroadcast]

Есть стандартный контролируемый кэш, но никто не мешает вне его содержание дать папку и туда что-то складывать

[@kirillsushilnikov9614]

@@AndroidBroadcast Да... Google прислушивается к пользователям, старается снизить уровень энергопотребления, работает над безопасностью и прочим. Но не может помешать разработчику завалить всю память в устройстве как раз навреное по этой причине, потому что функицонирование программы может нарушиться.

[@user-not_defined]

Видео немного на 2:23 обрезалось

[@anddev6505]

Формат отличный, от содержания ожидал большей глубины

[@MrJackBn]

Апикей он же токен, верно?

[@AndroidBroadcast]

Это разные вещи, но работа с ними примерно одинаково осуществляется

[@aratj]

можно сказать так , мы так же токены через интерцептеры для всех запросов выткаем

[@ivanchepelkin6347]

Про кэш: я правильно понял, что нужно создавать специальную директорию на андройде и тогда там это все хранить? как тогда можно сделать эту директорию безопасной, чтоб никто не имел доступа к вашему кэшу?

[@AndroidBroadcast]

Нужно создавать эту директорию на internal storage. Можно использовать Context.cacheDir

[@kamilchulakov]

Про жизненный цикл ничего не знал :|

[@Vlad_Gromov_1992]

Sps

[@Chernov1984]

+