🔗 Код из примера github.com/androidbroadcast/DynamicProxySample 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast 💰 Поддержать проект на Boosty boosty.to/androidbroadcast или Patreon patreon.com/android_broadcast 🔗 Dynamic Proxy Classes docs.oracle.com/javase/8/docs/technotes/guides/reflection/proxy.html 0:00 Вступление 1:17 Генерация кода в Retorfit 1:49 Задача для примера 2:20 Кодинг 22:46 Проверка API 25:22 Скорость работы 28:24 Заключение
Спасибо за выпуск. Всегда наивно полагал, что retrofit сделан какой-то магией с помощью annotation processing. Было бы здорово в одном из следующи выпусков разобрать, как работает LeakCanary.
"Вряд ли кто-то на моем канале пишет активно на джаве под андроид" - только так и пишем) Но у нас специфика такая - пишем библиотеки довольно таки низкоуровневые, в частности для работы с NFC, эмуляцией/чтения пластиковых карточек смартфоном и т.д. Кстати, на банковских карточках крутится облегченная версия джава-машины, если кто не знал) А когда вы подносите карту к банкомату, на нее подается питание и джава запускается. Но там сильно все порезано, для таких целей приходится писать прям сильно оптимизированный код
@@pigiion ну вот вы сами себе и ответили. вы писали для ЧТЕНИЯ nfc, а если бы писали что-то посложнее hello world для nfc, то поняли бы, о чем речь. а речь идет об ЭМУЛЯЦИИ карт. чтение любой джун-школьник реализовать сможет. а тут, как я уже объяснил, происходит полноценная эмуляция карт (ядро вообще на с++ написано) да и кодовая база одна с джава проектами непосредственно для ПЛАСТИКОВЫХ карт. там одних только стандартов на несколько томов толстенных книг
Ничего не понял( Что это и для чего нужно вообще, буду разбираться! Спасибо Кирилл!!! Очень качественная подача в материале, правда у меня не хватает экспертности чтобы осознать это, пока-что. P.s в 4к очень хорошо видно пятно из пыли на футболке)
Спасибо за твою работу! Если будет возможность, рассмотри пожалуйста лучшие практики построения нетворкинга в приложении. Или то, как ты бы рекомендовал это делать, чтобы результат был максимально гибким и эффективным.
насчет 26:21 Оптимизация рефлексии основанная на определении java машиной уровня понимания объекта java. Class object и Reflection понимается лучше и с вызовами легче ,чем простой кастомный класс. Reflection динамически развертывается большой объем кода , но GC сворачивает Рефлексию без мусора и в последующих вызовов это работает без лишних GC волн
Только вчера думал как же реализовать лучше свою обертку над ретрофитом с кучей функций, что бы не создавать миллион методов с разными параметрами. И это решение прям будет в тему, сделаю на основе него. Спасибо
Это можно также делать без проблем. Технология в методах имеет Object в качестве результата, а каст к нужному типу произойдет. Также получить информацию про тив вы сможете внутри прокси
@@AndroidBroadcast Извиняюсь, перепутал интерфейс. Не AnalyticsTracker из либы, а AppAnalytics, который в sample app лежит. Вот чтобы он возвращал результат. Но, думаю, суть от этого не меняется) Благодарю за ответ!
Спасибо за видео, было полезно! Но кажется что выглядит как сплошная плохая практика, скрыть детали реализации можно и используя классы. При том api будет более очевидным и возможности/ограничения библиотеки будут понятны из кода использования
Если скрыть детали реализации используя классы, то придется весь код каждый раз писать руками или вызывать какие-то стандартные методы. Интерфейс + аннотации + Java Dynamic Proxy позволяют описывать все декларативно без погружения в реализацию.
Спасибо за видео! С Retrofit получилось сделать, а подскажите, пожалуйста Room таким же образом делается? На основе Entity создаем таблицы, а из аннотаций методов Dao получаем информацию о запросе, вот только там еще зачем-то абстрактный класс, наследуемый от RoomDatabase появляется
Объясните, пожалуйста, зачем использовать Java Dynamic Proxy, если есть annotation processing? Ведь намного лучше переносить всю работу в compile time, нежели использовать рефлексию? Я провожу аналогию при сравнении Dagger 1, который работал на рефлексии и Dagger 2, использующий кодогенерацию.
У процессинга аннотаций есть минусы: - сложнее в реализации - процессинг аннотаций делают сборку больше и не позволяет использовать инкрементальную компиляцию - процессинг кода генерит код, что приводит к долгому времени индекса, поиска и компиляции Часть их проблем решаются, но все равно создаётся неудобство. Java Dynamic Proxy решает одни проблемы и создаёт новые
@@AndroidBroadcast спасибо! Как считаете, с развитием KSP и потенциальной миграции всех библиотек, использующих kapt на KSP, технология Java Dynamic Proxy не станет менее актуальной? Ведь по сути переход на KSP минимизирует минусы текущей реализации процессинга аннотаций. Вопрос касается именно разработки под Android на Kotlin.
Я сам работаю на двух MacBook Pro 16"/32 GB RAM/M1 PRO и M1 MAX в топовых конфигах ядер. Но учтите что один комп рабочий на огромный проект, а второй для кода и монтажа видео + кучи работы на коленях
![How Retrofit works. Java Dynamic Proxy. Library architecture [RU]](/img/logo.svg){kind=logo}
