Если не получается через Espresso, можно попробовать с помощью UI Automator. В Kaspresso есть обертка над ним (Kautomator), которая содержит функцию device.uiDevice.swipe(startX, startY, endX, endY, steps).
FlakySafely работает посредством перехвата эксепшнов, возникающих при определенном действии над View. Поэтому его нужно обернуть в flakySafely{}. Если нужно просто ожидание, то в крайних случаях можно использовать какую-нибудь реализацию wait() (например, Thread.sleep()).
Любые вопросы про Kaspresso можно также задавать в чатике.
3) Уязвимости в используемых библиотеках, а также возможность их использования в соотвествии с лицензионным соглашением проверяются отдельными командами Лаборатории.
Первоначальное решение о необходимости затянуть библиотеку принимают разработчики. Если это достаточно узко специализированная библиотека, на которую не завязывается весь проект – тут всё просто.
На вашем примере перехода с RxJava2 на Coroutines расскажу про процедуру принятия решения.
Инициатор внедрения должен детально изучить новую библиотеку. После чего он предлагает команде рассмотреть плюсы от такого перехода и возможные проблемы. Если решение о внедрении принимается – мы стараемся подтянуть уровень знаний всей команды о ней. А инициатор становится неким "евангелистом", которому уходят наиболее сложные кейсы. Только после этого происходит переход.
В новом проекте без RxJava2 мы можем сразу начать использовать Coroutines.
2) Фреймворк развивается несколькими людьми внутри компании, плюс сообществом разработчиков вне её. Код полностью open-source, поэтому его можно форкать, развивать, и использовать без завязки на наш репозиторий. Если вы сможете помочь нам в его развитии – Pull Request-ы приветствуются.
1) Kaspresso – это многофункциональный фреймворк, который облегчает написание UI-автотестов для Android. Разработчики начинали с создания обертки над Kakao и Espresso для уменьшения количества флаков в тестах. По мере накопления опыта автотестирования у нас – развивался и Kaspresso. Получилось, например, ускорить в 10 раз работу с UI Automator. В планах – помощь с настройкой инфраструктуры для запуска тестов.
Более подробную информацию о фичах Kaspresso можно посмотреть в репозитории.
Я выделил несколько основных вопросов:
1) Какую роль выполняет Каспрессо?
2) Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий?
3) Как вы выбираете, тянуть какую-то библиотеку в проект или нет?
Отвечу по частям.
Спасибо за комментарий. Безусловно, основой собеседований будут те базовые темы, которые вы перечислили и некоторые стандарты в индустрии (та же RxJava2, например). Но, если Корутины и Compose будут намного удобнее и внедряться в боевые проекты — их понимание, по моему мнению, будет важным конкурентным преимуществом.
Корутины, например, уже активно спрашивают в тестовых задачках на мобильных конференциях.
Спасибо за дополнение. Хотелось показать, что работает, и что не работает на сегодняшний день.
Будем ждать DevSummit. После него попробую применить к моему экрану то, что там покажут, и посмотреть, что улучшится.
Если посмотреть на Padding во втором примере, то Padding в Compose то же самое, что Margin в XML, а Padding в XML реализован в Compose через HeightSpacer и WidthSpacer.
Так что, скорее всего, нам нужно обернуть в Padding только Text, чтобы между ним и Rectangle было пространство. Но нужно проверить.
Про сложные экраны и замену для Constraint самому очень интересно, как реализуют. Пока её нет, предсказать сложно. Возможно, что-то похожее на Flutter подход. Может, разрешат использовать @Composable внутри Constraint.
Если как в Flutter, то он предоставляет некий конструктор из Material-элементов. И для типичного приложения по Material-гайдлайнам вроде бы достаточно.
Но вот если хочется уникальный дизайн, тут согласен, что как-то сложнее, чем с XML.
Если взять классический MVP, MVVM, или что-то другое с буквой V внутри, то в качестве этого View мы обычно считаем XML (возможно, с Databinding внутри) + "глупый" фрагмент/активити, которые служат как прослойка между Android OS, XML и платформонезависимым кодом на Java/Kotlin (Presenter, ViewModel, ...).
С декларативным UI у нас будет в слое View тот же фрагмент/активити + классы с @Composableкомпонентами, которые мы кладем внутрь. Кажется, что так даже удобнее.
Ну и положить этот View слой в отдельную папочку (если еще не) для структурированности.
А еще терпеть не могу, когда сложный UI целиком делают в одном ConstraintLayout.
Если есть такая возможность, почему бы нет? Constraint Layout как раз и придумали для уменьшения вложенности элементов и повышения скорости их обсчёта.
Мне кажется, что тут нужно искать золотую середину между вёрсткой в редакторе и в коде.
Олды не используют редактор, потому что раньше он был очень не очень.
Сейчас, как мне кажется, ситуация улучшилась. Его можно использовать для :
накидывания элементов с обязательными атрибутами,
выравнивания в Constraint (хотя для меня это было не очевидно до просмотра курса от Google),
просмотра того, что получилось (не работает со сложными экранами и кастомными view).
При этом, безусловно, нужно всегда проверять, что получилось в xml (это кстати так же рекомендуют в курсе выше). Да и сложные моменты иногда проще сделать в xml.
Скорее всего примерно так, как сейчас это происходи в плагине для Android Studio для Flutter.
Можно в коде выделить элемент и нажать кнопочку Обернуть в Padding или Обернуть в Column, и так далее.
Вопрос с визульным редактором для просмотра (хотя бы приблизительно) того, что получилось, довольно интересный. В Flutter говорят — ребята, вам он не нужен, потому что у нас изменения в экране пересобираются за пару секунд, при этом вы остаетесь на том же экране, не нужно каждый раз доходить до него вглубь.
В нативном Android с этим сложнее, потому что и Instant Run намного дольше, и не всегда он работает правильно.
В то же время визуальный просмотр в Android уже достаточно близок к реальности (вкладка Preview). Использовал несколько раз для показа граф.дизайнеру и быстрых правок, прежде чем собрать сборку и показать финальный скриншот.
Я бы посмотрел еще в сторону Ktor
А вообще статья скорее про постепенный переход. Сначала с RxJava на корутины. А потом можно и библиотеки на котлиновские. И вообще всё вынести в отдельный Kotlin Native модуль и использовать бизнес-логику и для Android, и для iOS.
RxKotlin представляет собой обертку над RxJava с поддержкой Kotlin Extensions. В RxJava работа с потоками осуществляется не напрямую, а через Schedulers — пуллы из однопоточных ExecutorService-ов, что сокращает накладные расходы на открытие потока.
device.uiDevice.swipe(startX, startY, endX, endY, steps).flakySafely{}. Если нужно просто ожидание, то в крайних случаях можно использовать какую-нибудь реализациюwait()(например,Thread.sleep()).Любые вопросы про Kaspresso можно также задавать в чатике.
3) Уязвимости в используемых библиотеках, а также возможность их использования в соотвествии с лицензионным соглашением проверяются отдельными командами Лаборатории.
Первоначальное решение о необходимости затянуть библиотеку принимают разработчики. Если это достаточно узко специализированная библиотека, на которую не завязывается весь проект – тут всё просто.
На вашем примере перехода с RxJava2 на Coroutines расскажу про процедуру принятия решения.
Инициатор внедрения должен детально изучить новую библиотеку. После чего он предлагает команде рассмотреть плюсы от такого перехода и возможные проблемы. Если решение о внедрении принимается – мы стараемся подтянуть уровень знаний всей команды о ней. А инициатор становится неким "евангелистом", которому уходят наиболее сложные кейсы. Только после этого происходит переход.
В новом проекте без RxJava2 мы можем сразу начать использовать Coroutines.
2) Фреймворк развивается несколькими людьми внутри компании, плюс сообществом разработчиков вне её. Код полностью open-source, поэтому его можно форкать, развивать, и использовать без завязки на наш репозиторий. Если вы сможете помочь нам в его развитии – Pull Request-ы приветствуются.
1) Kaspresso – это многофункциональный фреймворк, который облегчает написание UI-автотестов для Android. Разработчики начинали с создания обертки над Kakao и Espresso для уменьшения количества флаков в тестах. По мере накопления опыта автотестирования у нас – развивался и Kaspresso. Получилось, например, ускорить в 10 раз работу с UI Automator. В планах – помощь с настройкой инфраструктуры для запуска тестов.
Более подробную информацию о фичах Kaspresso можно посмотреть в репозитории.
Я выделил несколько основных вопросов:
1) Какую роль выполняет Каспрессо?
2) Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий?
3) Как вы выбираете, тянуть какую-то библиотеку в проект или нет?
Отвечу по частям.
Спасибо за комментарий. Безусловно, основой собеседований будут те базовые темы, которые вы перечислили и некоторые стандарты в индустрии (та же RxJava2, например). Но, если Корутины и Compose будут намного удобнее и внедряться в боевые проекты — их понимание, по моему мнению, будет важным конкурентным преимуществом.
Корутины, например, уже активно спрашивают в тестовых задачках на мобильных конференциях.
Спасибо за дополнение. Хотелось показать, что работает, и что не работает на сегодняшний день.
Будем ждать DevSummit. После него попробую применить к моему экрану то, что там покажут, и посмотреть, что улучшится.
Слышал об этом тоже, но не стал тут писать, не проверив
Если посмотреть на Padding во втором примере, то Padding в Compose то же самое, что Margin в XML, а Padding в XML реализован в Compose через HeightSpacer и WidthSpacer.
Так что, скорее всего, нам нужно обернуть в Padding только Text, чтобы между ним и Rectangle было пространство. Но нужно проверить.
Про сложные экраны и замену для Constraint самому очень интересно, как реализуют. Пока её нет, предсказать сложно. Возможно, что-то похожее на Flutter подход. Может, разрешат использовать
@Composableвнутри Constraint.Если как в Flutter, то он предоставляет некий конструктор из Material-элементов. И для типичного приложения по Material-гайдлайнам вроде бы достаточно.
Но вот если хочется уникальный дизайн, тут согласен, что как-то сложнее, чем с XML.
Если взять классический MVP, MVVM, или что-то другое с буквой V внутри, то в качестве этого View мы обычно считаем XML (возможно, с Databinding внутри) + "глупый" фрагмент/активити, которые служат как прослойка между Android OS, XML и платформонезависимым кодом на Java/Kotlin (Presenter, ViewModel, ...).
С декларативным UI у нас будет в слое View тот же фрагмент/активити + классы с
@Composableкомпонентами, которые мы кладем внутрь. Кажется, что так даже удобнее.Ну и положить этот View слой в отдельную папочку (если еще не) для структурированности.
Возможно. Нужно перепроверить
Если есть такая возможность, почему бы нет? Constraint Layout как раз и придумали для уменьшения вложенности элементов и повышения скорости их обсчёта.
Мне кажется, что тут нужно искать золотую середину между вёрсткой в редакторе и в коде.
Олды не используют редактор, потому что раньше он был очень не очень.
Сейчас, как мне кажется, ситуация улучшилась. Его можно использовать для :
При этом, безусловно, нужно всегда проверять, что получилось в xml (это кстати так же рекомендуют в курсе выше). Да и сложные моменты иногда проще сделать в xml.
Скорее всего примерно так, как сейчас это происходи в плагине для Android Studio для Flutter.
Можно в коде выделить элемент и нажать кнопочку
Обернуть в PaddingилиОбернуть в Column, и так далее.Вопрос с визульным редактором для просмотра (хотя бы приблизительно) того, что получилось, довольно интересный. В Flutter говорят — ребята, вам он не нужен, потому что у нас изменения в экране пересобираются за пару секунд, при этом вы остаетесь на том же экране, не нужно каждый раз доходить до него вглубь.
В нативном Android с этим сложнее, потому что и Instant Run намного дольше, и не всегда он работает правильно.
В то же время визуальный просмотр в Android уже достаточно близок к реальности (вкладка Preview). Использовал несколько раз для показа граф.дизайнеру и быстрых правок, прежде чем собрать сборку и показать финальный скриншот.
Как минимум сейчас есть аннотация
@Model, которая превращает класс в observable источник данных для Compose. Похоже на scoped model в Flutter. Посмотреть пример использования можно в исходникахПросто extension-функция над Int, которая преобразовывает его в инстанс дата класса Dp. Исходники Dp.kt
А вообще статья скорее про постепенный переход. Сначала с RxJava на корутины. А потом можно и библиотеки на котлиновские. И вообще всё вынести в отдельный Kotlin Native модуль и использовать бизнес-логику и для Android, и для iOS.
Но в резюме такой домен смотрится не солидно