ArkadyGamza

Я не играл с видео, но на первый взгляд его добавить несложно, достаточно использовать Surface от MediaRecorder вместо ImageReader.

Проще, согласен, но тогда никакого контроля над UI камеры. Нам надо было иметь кастомный UI.
На Kotlin мы не просто смотрим, мы его активно используем! Почти весь новый код пишем на Kotlin.

Да, тест не сложный, как и обещали. С другой стороны, мы видим, что такого уровня тест успешно проходят примерно 10% кандидатов. Вы считаете, что нужно делать сложнее? Почему?

Ого, вот это подход! Напишите мне в личку, попробуем придумать что-нибудь.

Как вы узнали? Придется теперь новую задачу придумывать!

Мы нанимаем со всего мира, не только из РФ. В Москве мы здесь традиционно активны — у нас здесь есть офис, нас многие знают (в том числе благодаря хабру), логично использовать эти преимущества.

Безусловно!

На этом интервью мы оцениваем как кандидат подходит к проектированию приложения.

У нас огромное количество идей по развитию проекта и постоянно генерятся новые. Задач хватит на всех!

Отличный вопрос, он показывает, что зачастую у сильных разработчиков нет времени не только на интервью, но и на тест. Мы подумаем над процессом, который позволяет устранить и этот сдерживающий момент, может быть что-то изобретем!

Мы в понедельник начнем рассылать приглашения тем, кто успешно прошел тест. Напишите, пожалуйста, мне в личку ваш email я проверю, что ваш тест обработан.

Ссылки поправили, спасибо!

Да, видео выложим, сейчас монтируем.

В примере никак не решаем, он ведь про 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) и покажет эти изменения визуально.

Да, можно использовать notifyItemInserted/Moved/и т.д. Но это не всегда удобно. Например, если модель приходит с сервера.

Ссылка не вставилась, вот линк на гифки https://github.com/ArkadyGamza/MasteringRecyclerView_StableIDs/issues/1

Хочется добавить, что основной бонус от RecyclerView.Adapter.setHasStableIds(true) — это анимации изменений модели.
Благодаря тому, что RecyclerView понимает какие айтемы добавились, какие удалились или переместились, оно может красиво эти изменения анимировать после notifyDataSetChanged.
Вот тут есть пара гифок, где видно разницу при смене модели со стабильными ID и без.