Комментарии 9
А что на счет setRepeatingRequest и backpressure? Разве не нужно это обрабатывать? Как часто будут прилетать эти события?
Observable, который создает функция fromSetRepeatingRequest является «горячим». Это может приводить к проблемам с операторами, которые накапливают события. В нашем случае мы первым делом к полученному Observable применяем цепочку операторов combineLatest.firstElement. CombineLatest держит только одно последнее событие для более быстрого Observable, переданного ему в качестве параметра. То есть он не накапливает элементы.
А как вы решаете вопрос, если camera2 на устройстве ещё нет? Какой-то универсальный адаптер?
В примере никак не решаем, он ведь про camera2 API.
В реальной жизни обычно создается 2 имплементации для первой и второй версии Camera API, реализующих общий интерфейс, выбор между ними в рантайме. (Причем я видел довольно нетривиальный алгоритм выбора. Для некоторых устройств выбирается camera1 api даже если это Lollipop и новее.) Если лениво делать поддержку camera1 API, то можно, например, запускать системную камеру для pre Lollipop. Ну или minSdkVersion=21 и только camera2 api.
В реальной жизни обычно создается 2 имплементации для первой и второй версии Camera API, реализующих общий интерфейс, выбор между ними в рантайме. (Причем я видел довольно нетривиальный алгоритм выбора. Для некоторых устройств выбирается camera1 api даже если это Lollipop и новее.) Если лениво делать поддержку camera1 API, то можно, например, запускать системную камеру для pre Lollipop. Ну или minSdkVersion=21 и только camera2 api.
1) RxJava immutable, а значит куча лишних объектов на каждый ивент в observable. Rx не подходит для интенсивной работы на андроиде, потому что GC будет сходить с ума. Говорю как истинный фанат реактивщины на андроиде.
2) Для лямбд уже не нужна Retrolambda
3) Enum, сами знаете. Intdef наше все
В остальном все хорошо, плюсую.
2) Для лямбд уже не нужна Retrolambda
3) Enum, сами знаете. Intdef наше все
В остальном все хорошо, плюсую.
Мне кажется, опасения насчет enum на Андроиде были валидны в самом начале существования Андроида, лет так семь назад, когда устройства были слабее, памяти было мало, и Dalvik был на самой заре своего существования. Сейчас отказываться от enum-ов — это экономия на спичках в большинстве случаев.
так оно и есть, проблема с enum уже починена давно
Согласен, что это экономия на спичках. К тому же, Proguard оптимизирует использование простых enum: ответ на StackOverflow.
Чрезвычайно интересная и полезная статья, поставлю +, когда хватит кармы.
ArkadyGamza, Вы скорее всего не найдёте время, чтобы переработать код, но для читателей хочу подметить одну особенность: вызовы типа
и уж тем более присвоения внешних переменных вроде
не совсем в духе Rx. Это называется side effect, чего рекомендуется избегать (например, операторами map/flatMap). Если же применение операторов невозможно (из-за разнородности целевых данных, например), можно оформить обычную подписку.
ArkadyGamza, Вы скорее всего не найдёте время, чтобы переработать код, но для читателей хочу подметить одну особенность: вызовы типа
doAfterSuccess() // и другие doЧтоТои уж тем более присвоения внешних переменных вроде
.doAfterSuccess(this::setupSurface) // инициализация переменной класса mSurface не совсем в духе Rx. Это называется side effect, чего рекомендуется избегать (например, операторами map/flatMap). Если же применение операторов невозможно (из-за разнородности целевых данных, например), можно оформить обычную подписку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Побеждаем Android Camera2 API с помощью RxJava2 (часть 1)