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

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

@@BelokonRoman спасибо

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

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

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

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

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

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

Видео про Paging 3 есть на канале kzfaq.info/get/bejne/b-CGoLyHqbrHdYE.html.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А зачем?

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

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

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

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

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

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

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

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

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