Автоматизация мобильной игры с помощью Airtest IDE и других решений
Доброго дня всем! Меня зовут Роман Мелкумов, я тестировщик в студии IT Territory. И вот уже более года тестирую мобильную игру Castle Duels, которая сочетает в себе многопользовательские бои и коллекционирование персонажей.
Привет! Меня зовут Алексей Дёмин, я Android-разработчик в Prequel - мобильном редакторе для фото и видео. Даунскейл изображений встречается в приложениях повсеместно, но из-за высокого уровня абстракции работы с изображениями может возникнуть иллюзия о тривиальности этого процесса. Сегодня я бы хотел детальнее взглянуть на даунскейл и разобраться что именно происходит с изображением с точностью до пикселя.
Приблизительно три года назад на Google I/O 2019 была анонсирована новая перспективная библиотека для разработки Android-приложений под названием compose. С тех пор он рос все больше и больше и становился все лучше и лучше. Многие люди даже говорят, что он знаменует собой конец использования XML в разработке Android-приложений. С тех пор, как Google выпустил первую стабильную версию, была написана куча учебных пособий, выпущено множество курсов и разработано большое количество библиотек для поддержки экосистемы.
С приходом Compose в голове всё чаще всплывают мысли, что же ещё можно написать в декларативном стиле. И как мне кажется, на эту роль хорошо подходит аналитика, точнее, описание её событий. В среде разработчиков тема аналитики нечасто всплывает в обсуждениях. Отправка аналитики не является целью фичи, а лишь обязательной дополнительной частью. Сама отправка — задача довольно тривиальная и поэтому воспринимается обычно как «обязаловка», а не как интересный процесс, в котором можно блеснуть своими знаниями архитектуры. Тем не менее, если сложить время всех задач по отправке аналитики, то получится довольно приличное количество часов. Поэтому хочется, чтобы работа с этой частью была максимально комфортной. В этом и поможет декларативный подход.
Работа с разрешениями, загадочный TARE, изменения UI. Разбираемся, какие изменения несёт грядущее обновление Android 13.
Мы Дима и Настя, Android-разработчики в компании СберЗдоровье. В этой статье мы хотим рассказать о том, как мы перевели весь наш проект с LiveData на Flow, с какими трудностями столкнулись и что полезного узнали. Эта статья будет полезна тем, кто работает с LiveData, уже пробовал / хочет попробовать Flow для хранения состояний во ViewModel, а также командам, которые планируют миграцию всего проекта на новый инструмент.
Среди множества редакторов для разработки приложений под Android особенно выделяется Android Studio — это очевидный выбор большинства разработчиков не только потому, что это основной нативный редактор для разработки приложений, но и потому, что он предоставляет обширную оффлайн поддержку.
Этот набор фич гарантирует, что код, который мы пишем для нашего Android-приложения, будет эффективным и полнофункциональным. Одним из инструментов, цель которого заключается в оказании такого рода поддержки, является Lint.
Lint нужен для того, чтобы искать нетривиальные ошибки и плохо написанные фрагменты в вашем коде. В этой статье я расскажу вам о линтинге в Kotlin и о том, как его настроить и начать использовать. Давайте приступим.
В первой части статьи мы последовательно рассмотрели шаги по созданию и преобразования приложения для Android, необходимыми для реализации тестов, начиная от Unit-тестирования и заканчивая E2E-тестами. Сегодня мы рассмотрим архитектурные подходы Model-View-Intent (MVI), создадим собственную реализацию MVI и на ее примере разберем особенности разработки и тестирования приложений на MVI и подготовимся к обсуждению разработки тестируемых реактивных интерфейсов на Jetpack Compose в следующей части статьи.
В данном руководстве я актуализировал разрозненные инструкции на текущий момент (май 2022 года). Если совсем коротко, то собрать приложение можно командой
gradlew assembleDebug или gradlew assembleRelease
Но как всегда есть нюанс ;) Что нужно минимально поставить на ноутбук или компьютер, а главное, где это скачать?
В многомодульном приложении часто возникает ситуация, когда в одном модуле находится интерфейс, а вот его реализация находится в совершенно другом модуле. Как следствие, возникает потребность как-то получить реализацию при наличии лишь интерфейса. Всё так или иначе сводится к тому, чтобы обратится к какой-либо сущности, которая отдаст нам реализацию. Но ведь сначала этой сущности надо сообщить, где взять реализацию. Этот процесс я называю связыванием, так как мы связываем интерфейс с его реализацией. Видел, что многие называют это склейкой. Сегодня мне бы хотелось проговорить, какие есть для этого способы. И да, спойлер, их несколько.
В этой статье мы поговорим о том, как наша команда перешла на Kotlin DSL для описания Gradle файлов, и как в итоге мы получили типы сборок, описанные классами и имеющие общий интерфейс.
Привет, «Хабр»! Мы — Даня и Ксюша, разработчик и тестировщик команды мобильных приложений в компании ATI.SU. Сегодня хотим рассказать удивительную историю о том, как наши системные администраторы помогли нам развернуть мобильную ферму Android-девайсов, и с чем мы столкнулись. Опишем технические детали, чтобы вы могли повторить наш опыт. Однажды и ваша команда сможет отлаживать и тестировать удалённо на большом парке девайсов.
Хорошее мобильное приложение должно быть не только создано с использованием современных архитектурных шаблонов, но и быть подготовленным к реализации автоматических тестов. Мы рассмотрим с вами на практическом примере как создается приложение с учетом возможностей тестирования, чем отличаются архитектуры и соответствующие подходы к созданию тестов и как создать полный спектр тестов от unit-тестирования бизнес-логики до End-to-End тестов приложения как единого целого. В первой части статьи мы поговорим про разработку интерфейсов без использования реактивной модели, последовательно создадим (и доработаем) приложение на архитектурах MVP и MVVM и разработаем тесты (с использованием виртуального времени на тестовом диспетчере, моков и Hilt для подстановки тестовых объектов). Во второй части статьи речь пойдет о MVI и о тестировании приложений для Jetpack Compose (включая анимацию и передачу данных через LocalComposition-объекты). Всех, кому интересна мобильная разработка, приглашаю под кат.
Привет! Как и обещали, возвращаемся с записью второго митапа для мобильных разработчиков от Ozon Tech и сообщества Coffee&Code. В анонсе я уже рассказал о нашем стеке, что у нас 150+ мобильных инженеров и подход Backend-Driven UI — повторяться не буду. Вместо тысячи слов — просто посмотрите запись:)
Привет, меня зовут Саша, я Android-разработчик команды разработки мобильного приложения Банка РНКБ. Сегодня хочу поделиться своим опытом использования Compose.
В июле прошлого года Google анонсировал первую стабильную версию Jetpack Compose, а на момент написания статьи уже вышла версия 1.1. Несмотря на то, что использовать данный инструмент можно было задолго до фактического релиза, сейчас метаморфозы API завершились(хотя некоторые его части всё ещё помечены аннотацией @Experimental*Api). Сам Compose как инструмент для разработки теперь точно стал production ready (ну так обещают).
