Спасибо, что поделились CLAUDE.md, местами полезно, местами любопытно. Например, интересно, откуда такая нелюбовь к тестам компонента в изоляции, с каким опытом это связано? Заметил, что много запретов на mocks, причем местами термин mock вроде как и не применим по контексту, ну и совсем не упомянуты другие типы test doubles (dummy, fake, stub, spy), возможно, имеет место некоторая путаница. Еще любопытен подход к организации пирамиды тестирования, хрестоматийно e2e < integration < unit test, у Вас наоборот.
Многие, видимо, не в курсе, что разработчики, которые хотят выложить приложение в альтернативный Android стор, скорее всего собирают отдельную другую сборку для него. Как минимум, убрав использование всяческих Google API (пуши, карты и тд), иначе приложение просто упадёт на устройстве, где нет сервисов Google. Некоторые вендоры, например, Huawei, даже предоставляют свои аналоги сервисам Google. Соответственно, даже если разработчик использует проверки из новости для сборки в Google Play, но при этом сознательно заливает отдельную сборку в альтернативный стор, то он, естественно, эту проверку уберет.
Эта проверка ударит только по черным сторам, которые публиковали приложения без ведома разработчика. Возможно, при этом ещё и меняя код, заменяя рекламу на свою, внедряя вредоносы и тд.
Не соглашусь насчёт выступления на конференциях. Это — часть Tech PR, который формирует образ компании, то есть выгоден бизнесу. Умные компании привлекают звездных спикеров, пытаются вырастить своих.
Проще, согласен, но тогда никакого контроля над UI камеры. Нам надо было иметь кастомный UI.
На Kotlin мы не просто смотрим, мы его активно используем! Почти весь новый код пишем на Kotlin.
В примере никак не решаем, он ведь про camera2 API.
В реальной жизни обычно создается 2 имплементации для первой и второй версии Camera API, реализующих общий интерфейс, выбор между ними в рантайме. (Причем я видел довольно нетривиальный алгоритм выбора. Для некоторых устройств выбирается camera1 api даже если это Lollipop и новее.) Если лениво делать поддержку camera1 API, то можно, например, запускать системную камеру для pre Lollipop. Ну или minSdkVersion=21 и только camera2 api.
Observable, который создает функция fromSetRepeatingRequest является «горячим». Это может приводить к проблемам с операторами, которые накапливают события. В нашем случае мы первым делом к полученному Observable применяем цепочку операторов combineLatest.firstElement. CombineLatest держит только одно последнее событие для более быстрого Observable, переданного ему в качестве параметра. То есть он не накапливает элементы.
Действительно, вещи описаны простые и стандартные, и опытные девелоперы это все знают. Но меня поразило как много ответов на stackoverflow дают откровенно вредительские рекомендации. Я надеюсь, что эта статья будет полезной для начинающих разработчиков, которые в первый раз столкнулись с такой задачей.
Спасибо! Согласен, подключать зависимости никто не любит, но ведь область применения этих библиотек не ограничивается этой одной фичей. Вы сможете использовать их мощь повсюду. А без лямбд вообще грустно.
Простой пример, когда этот оператор не даст нам ожидаемого результата: граница буффера попала как раз на серию событий, в результате в каждом буффере будет меньше трех событий. Попробую это визуализировать: [...**][*....]. В первом буффере будет 2 события, во втором — одно событие.
К тому же, этот оператор генерирует события, даже если на входе вообще не было событий (генерируются пустые массивы), что не сильно вредно, но не нужно в нашем случае.
А вообще, предлагаемое решение — не единственное, ради тренировки можно попробовать решить еще короче!
Это просто как пример той ситуации, когда неудобно (мы не знаем что изменилось в модели). Да, конечно, мы можем сами посчитать разницу и сообщить RecyclerView через notifyItemSmth, но гораздо удобнее передать модель целиком и сказать notifyDataSetChanged. RecyclerView сделает всю работу по вычислению изменений (если есть stable IDs) и покажет эти изменения визуально.
Хочется добавить, что основной бонус от RecyclerView.Adapter.setHasStableIds(true) — это анимации изменений модели.
Благодаря тому, что RecyclerView понимает какие айтемы добавились, какие удалились или переместились, оно может красиво эти изменения анимировать после notifyDataSetChanged.
Вот тут есть пара гифок, где видно разницу при смене модели со стабильными ID и без.
Спасибо, что поделились CLAUDE.md, местами полезно, местами любопытно. Например, интересно, откуда такая нелюбовь к тестам компонента в изоляции, с каким опытом это связано? Заметил, что много запретов на mocks, причем местами термин mock вроде как и не применим по контексту, ну и совсем не упомянуты другие типы test doubles (dummy, fake, stub, spy), возможно, имеет место некоторая путаница. Еще любопытен подход к организации пирамиды тестирования, хрестоматийно e2e < integration < unit test, у Вас наоборот.
Можно ли заменить разработчика в машинных кодах на ассемблер и промпт-инженера на ассемблере?
Можно ли заменить разработчика на ассемблере на компилятор C и промпт-инженера на C?
Неужели рутуб считает, что "просто перемещение чужих роликов" - это нарушение законодательства?
Многие, видимо, не в курсе, что разработчики, которые хотят выложить приложение в альтернативный Android стор, скорее всего собирают отдельную другую сборку для него. Как минимум, убрав использование всяческих Google API (пуши, карты и тд), иначе приложение просто упадёт на устройстве, где нет сервисов Google. Некоторые вендоры, например, Huawei, даже предоставляют свои аналоги сервисам Google. Соответственно, даже если разработчик использует проверки из новости для сборки в Google Play, но при этом сознательно заливает отдельную сборку в альтернативный стор, то он, естественно, эту проверку уберет.
Эта проверка ударит только по черным сторам, которые публиковали приложения без ведома разработчика. Возможно, при этом ещё и меняя код, заменяя рекламу на свою, внедряя вредоносы и тд.
Не соглашусь насчёт выступления на конференциях. Это — часть Tech PR, который формирует образ компании, то есть выгоден бизнесу. Умные компании привлекают звездных спикеров, пытаются вырастить своих.
На Kotlin мы не просто смотрим, мы его активно используем! Почти весь новый код пишем на Kotlin.
В реальной жизни обычно создается 2 имплементации для первой и второй версии Camera API, реализующих общий интерфейс, выбор между ними в рантайме. (Причем я видел довольно нетривиальный алгоритм выбора. Для некоторых устройств выбирается camera1 api даже если это Lollipop и новее.) Если лениво делать поддержку camera1 API, то можно, например, запускать системную камеру для pre Lollipop. Ну или minSdkVersion=21 и только camera2 api.
К тому же, этот оператор генерирует события, даже если на входе вообще не было событий (генерируются пустые массивы), что не сильно вредно, но не нужно в нашем случае.
А вообще, предлагаемое решение — не единственное, ради тренировки можно попробовать решить еще короче!
Благодаря тому, что RecyclerView понимает какие айтемы добавились, какие удалились или переместились, оно может красиво эти изменения анимировать после notifyDataSetChanged.
Вот тут есть пара гифок, где видно разницу при смене модели со стабильными ID и без.