Android *

Представьте: теплый осенний вечер, на столе перед вами чашечка чего-нибудь вкусного, за окном порхают пожелтевшие листья, тонко насвистывает ветер, но на душе скребутся коварные мыши. И вам точно известно, откуда эти мыши растут: еще летом вышел стабильный Jetpack Compose, а вы таки не затащили его в ваши продакшн-приложения. 

Всем привет! Меня зовут Паша Стрельченко, я Android-разработчик в hh.ru. В этой статье поведаю историю о том, как начиналась адаптация Jetpack Compose в нашем продакшн-приложении. 

Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.

Несмотря на шутку в адрес многомодульности, это действительно полезный подход, но для большого проекта с богатой историей модуляризация может быть очень сложным процессом. Поэтому пока давайте посмотрим, что можно сделать без больших болей на уровне Gradle и AGP.

Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.

В один из зимних вечеров я сидел дома, читал замечательную книжку «Android-программирование для профессионалов» и наткнулся на главу про Accessibility. Раньше я об этой теме не задумывался: клал null в поле contentDescription и жил себе спокойно. Но когда узнал, как слабовидящие люди пользуются смартфоном, у меня появилось желание погрузиться в тему доступности глубже.

Рассказываю, как адаптировать приложение для людей с ограниченными возможностями и так ли это трудозатратно, как кажется.

Прежде мы рассмотрели отделение логики отображения от графики, а также разные вспомогательные классы и менеджеры. Все вместе они образуют каркас наших приложений и были вынесены в отдельную библиотеку — Core Framework. Осталось еще разработать методику по написанию остальной логики. В нее входит бизнес-логики и правила игры, данные и их обработка, а также взаимодействие с сервером.

Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).

Рассмотрев компоненты в общем виде, можно приступить к построению полноценного приложения на их основе. Первым делом нам нужно реализовать смену экранов и показ диалогов. Потом мы добавим возможность конфигурировать приложение и легко подставлять измененные реализации классов с помощью инверсии управления (IoC). Используя IoC-контейнер как контекст приложения создадим возможность запускать параллельно несколько игр в одном приложении, что позволит проводить сеансы одновременной игры, как это делается, например, в шахматах или в онлайн-покере. Под конец мы добавим централизованный доступ к ресурсам, локализации и управлению звуками, а также сделаем свою реализацию для логов и сигналов как более экономичную замену событиям.

Все вместе уже можно будет считать вполне оформившимся игровым фреймворком.

В конце прошлого года движок Flame для создания игровых приложений на Flutter опубликовал первую стабильную версию 1.0 и анонсировал большие изменения в системе миксинов, подходах к управлению компонентами и созданию сцены из иерархии объектов, каждый из которых может выступить в роли контейнера. Прежде всего Flame ориентирован на двумерную графику (спрайты, системы частиц, визуальные эффекты), но возможности Skia позволяют использовать трехмерные преобразования и обеспечивать работу с шейдерами, благодаря чему можно приблизиться к созданию трехмерных игр. В этой статье мы обсудим возможный путь создания трехмерных компонентов в Flame с произвольной визуализацией с использованием компилируемых шейдеров.

С выходом Jetpack Compose делать ui компоненты и, в целом, верстать стало проще. Да и сам инструмент так и навязывает переиспользовать ранее сделанные compose функции, делать их как можно меньше, чтобы можно было удобней переиспользовать.

Но что если это не всегда так удобно? Да и просто переиспользовать compose функции это слишком просто! Jetpack Compose дает куда большие возможности в вопросе декомпозиции задачи.
Простой пример: как переиспользовать compose функции, если мы строим многомодульное приложение? Нужно раскидать эти compose функции так, чтобы были доступны для разных модулей, но это все нужно организовать так, чтобы не наткнуться на circular dependency (при многомодульном построении приложения) или же чтобы это все не превратилось в "кашу" (при построении приложения в одном модуле), а также обойти кучу других проблем, которые могут возникнуть. Безусловно, решить этот пример можно множеством способов. Одно решение из множества, достаточно кардинальное, я опишу далее.

Статья посвящена ускорению скорости сборки флейворов и разных типов сборки монолитного проекта с помощью многомодульности и кастомного файла конфигурации.

В игры я люблю играть с детства и играя на работе в очередную игру на телефоне захотелось что то создать самому. Из знаний были только какие то остатки основ программирования на турбо паскале. Начал шерстить интернет и понял что для начала нужно выбрать движок для игры. Игру я собирался делать в 2Д и пошерстив инет нашел несколько вариантов а именно: Unity, Constructor, GameMaker. И поизучав их понял что в unity лучше использовать для 3Д и там все же нужно знать C#. Constructor был простым для новичка как и GameMaker но отказался от него из-за того что там нужно было платить ежемесячно, поэтому выбор сделал в пользу GameMaker.

Автотестирование View системы развивается уже достаточно давно. У нас есть множество инструментов, зарекомендовавших себя очень хорошо.  Напротив, Compose только начинает обрастать различными решениями и фреймворками, например, у kaspresso на момент написания статьи Compose находиться в раннем доступе.

Сегодня разберём в чём же особенности нативного тестирования на compose, наступим на пару граблей и напишем свои первые тесты. А в следующей статье уже будем копать вглубь и посмотрим как это всё работает под капотом.

Разработчики Вы там совсем обнаглели ? Зачем Вам мое местоположение ?

Типовой отзыв для андроид приложения, работающего с блютуз устройством.

Статья построена в виде спора с воображаемым пользователем. Для андроид разработчиков рассмотрены как классические способы, так и рекомендумые альтернативы.

Уже некоторое время команда создателей фреймворка Flutter проводит ежеквартальные опросы пользователей, чтобы сами разработчики могли выразить свое мнение. О чём это говорит? Если коротко, Flutter по-прежнему нравится большинству разработчиков.

Забегая вперёд отметим, что наша большая команда поклонников Flutter тоже приняла активное участие в голосовании. Мы поддерживаем развитие этого фреймворка на радость бизнесу и пользователю. А теперь по теме.

Меня зовут Саша Хрущев и я технический директор IT-компании WINFOX. Расскажу, почему необходимо адаптировать приложения для Huawei AppGallery и как это сделать.

Привет! Мы написали свою систему диплинков на основе кодогенерации. В этой статье поговорим, как мы упростили работу с диплинками и смогли отловить устаревшие, добавили мониторинг и как собрали все диплинки в одной статье в конфлюенсе.

Диплинк — это uri на конкретный ресурс в приложении. Они нужны бизнесу, чтобы упрощать пользовательский опыт. Так вместо нескольких переходов внутри приложения диплинки позволяют направить пользователя на определённый экран в один клик (польза для пользователя) и снимать статистику (польза для бизнеса). Например: на внешней площадке компания разместила баннер, в котором предлагается заказать виртуальную карту, пользователь может кликнуть по баннеру и сразу попасть на экран заказа карты, а бизнес сможет оценить, какая из площадок более эффективна.  

Самая большая проблема — это проблема безопасности. Объясню на примере активити, которая открывает веб-страницы. Активити открывается по диплинку, в нём указывается URL в качестве параметра. Один из вариантов атаки — когда злоумышленник может заставить пользователя пройти по диплинку с URL на вредоносный сайт и таким образом провести атаку. Ещё одна из возможных проблем — на некоторых экранах нам нужно валидировать параметры, а это иногда занимает значительную часть активити. Было бы хорошо вынести валидацию в отдельное место. 

Ещё у нас бывали случаи, когда маркетинг запускал промо-кампании либо с диплинками, в которых содержались ошибки, либо с устаревшими диплинками, которые уже не поддерживались, и мы могли об этом даже и не узнать. А при заведении новой кампании маркетинг обращался к разработчиками за диплинками и поиск занимал некоторое время. Если разработчик помнил название экрана и диплинк без параметров, то его можно было быстро найти, а если название экрана сразу не вспомнилось, то алгоритм поиска примерно такой: сбилдить проект -> пройти на нужный экран -> посмотреть в логах, какая активити открылась -> пойти в манифест для получения диплинка -> открыть исходных код активити для сбора входных параметров.

Посмотрев на это, мы поняли, что нам нужна единая точка обработки, анализа, мониторинга, и решили выбрать инструмент аннотаций и кодогенерации. Сейчас объявление диплинка у нас выглядит следующим образом. 

Всем привет!

Уже который год идёт, а мы все ещё пишем читалку со словарями под Android. Настало время для очередной статьи о том, что у нас появилось нового.

В первой части этой серии мы прошлись по теории, лежащей в основе использования тестовых дублеров. Теперь же давайте на примерах рассмотрим, как их можно использовать в среде Android.