Декларативное программирование — это парадигма программирования, в которой задаётся ожидаемый результат, а не способ его получения. Об истоках этой технологии, её отличиях от императивной парадигмы и удобстве её использования рассказывает iOS-разработчик red_mad_robot Саша Евсеев.
На Google I/O 2021 продемонстрировали фичу, которая позволяет динамически менять цветовую схему приложения в зависимости от его контента. Но ни в документации, ни в официальных примерах не оказалось использования этого подхода или API, которое делало бы это на уровне отдельного экрана или элемента.
Ведущего android-разработчика red_mad_robot Рому Чорыева это не устроило, и он для этой цели решил разработать собственное простое решение, — а теперь рассказывает об этом в статье.
Если вам случалось работать над очень крупным Android проектом, с большим количеством модулей, кода, или наоборот не самой удачной декомпозицией на модули и наличием легаси, то вы наверняка знаете что сборка подобного проекта может занимать довольно много времени. К тому же, этапы сборки множатся и усложняются, да и средние размеры проектов серьёзных мобильных приложений продолжают увеличиваться. По моим субъективным ощущениям, с каждым годом среднее время сборки проекта растёт и не похоже что эта тенденция будет меняться.
Бывает довольно обидно, когда в работу поступает задача, решение которой очевидно, фикс проблемы делается за пару минут, но чтобы проверить что всё исправлено нужно переключать ветки, пересобирать проект, потом переключаться обратно и пересобирать исходную ветку. Это может занимать очень много времени. Или бывает так, что находясь “в потоке” нужно что-то быстро проверить, но увидеть вступили ли изменения в силу можно только пересобрав и перезапустив проект, а если что-то пойдёт не по плану, или по каким-то причинам кэш сборки не отработает и проект будет собираться почти "на холодную"? Подобные, казалось бы, мелочи могут занимать огромное количество времени в течение дня, отвлекают, мешают сосредоточиться и продуктивно использовать рабочее время. Особенно много времени тратится если рабочий компьютер далеко не самый производительный, или если вы пользуетесь ноутбуком, не ориентированным на выполнение тяжёлых сборок.
В этой статье я хочу показать вам как можно собирать огромные Android проекты на далеко не самых производительных компьютерах или ноутбуках, утилизируя для этого вычислительные мощности удалённого сервера или отдельного домашнего настольного компьютера, не потеряв при этом ни капли удобства инструментов Android Studio - графического интерфейса, отладчика, и т.д.
Интересующихся приглашаю под кат.
Мне очень нравится меню с Apple watch: плавность анимации, поведение иконок при перемещении, расположение элементов по необычной сетке. Я захотел повторить это меню на Android. Но делать это на старом подходе с помощью ViewGroup или кастомного Layout Manager для RecyclerView не очень хотелось: слишком уж затратно для работы «в стол».
С появлением Compose эта идея стала более привлекательной и интересной для реализации. Рассказываю, как создать собственный ViewGroup на Jetpack Compose.
Задача состояла в создании автономного приложения для редактирования медиафайлов на Swift без использования сторонних UI-фреймворков. Конкурсные функции и интерфейсы должны быть созданы с нуля. Использование сторонних реализаций медиаредакторов с похожими функциями строго запрещено.
Плавность анимации и общая стабильность приложения будут играть важную роль. И последнее, но не менее важное — отсутствие существенных недостатков (включая сбои, проблемы с производительностью, визуальные проблемы, заметное мигание элементов, несовершенство макета и многое другое).
Если вы хотите узнать, что же было реализовано, какие ошибки и выводы я сделал после конкурса, то заходите.
Примечание. Если статья покажется интересной, то вот тут я пишу об iOS-разработке и о том, что с ней связано.
Привет, Хабр!
Меня зовут Вильян Яумбаев, в этой статье я расскажу вам про наши приключения на пути к SPM.
В 2015 ПСБ начал разрабатывать проект для бизнеса. Для него, в свою очередь, было нужно приложение. Сперва всё находилось в одном репозитории одного проекта в одном воркспейсе. Первые авторы подключали сторонние зависимости через CocoaPods, поскольку проприетарного менеджера зависимостей ещё не существовало. Но в тот же год в Apple началась работа над Swift Package Manager. Им предстояло встретиться в нашем проекте.
В этой статье расскажу, через что мы прошли, переводя зависимости на SPM, и поделюсь нашими наработками.
Кофе — продукт, который можно покупать и пить несколько раз в день. Заказ в приложении Дринкит должен быть супер-пупер быстрым. В идеале, чтобы можно было даже не запускать его, а заказывать из виджета на домашнем экране.
Мы ускоряли оплату разными способами. Сначала сделали кнопку прямо в меню, но столкнулись с проблемами и решили переделать её на слайдер. Процесс оказался необычным с разных сторон, поэтому хотим подробно рассказать о нём: почему переделывали, как проектировали, зачем нужны вибрации и как с ними работать, в каком контексте живёт слайдер и о чём со стороны доступности надо подумать, чтобы сделать его удобным для всех.
Эта статья рассказывает о моём опыте создания пользовательских представлений под Android. Со временем это всё переросло в целую библиотеку.
Как-то одним вечером мне в голову забралась идея о создании собственного настраиваемого View компонента для выбора цвета в обёртке уже готовой к использованию библиотеки. На самом деле, таковых в сети достаточно и без меня, но довольно интересных, с возможностями кастомизации я не нашёл. Опыта в разработке View компонентов у меня на тот момент не было, а хотелось бы чуть больше, чем ничего. Так я и приступил к написанию кода.
Статья в большей степени не является руководством к тому, как стоит делать, соответственно и не претендует на правильность. Однако с помощью этой статьи я решил поделиться своим опытом разработки и описать грабли с костылями, на которые я наступал по мере реализации моей концептуальной идеи.
В октябре 2020 года в техническую поддержку Авито стали обращаться пользователи с проблемами нагрева девайса и просадками FPS вплоть до полного фриза iOS-приложения. Проблема, как казалось, была глобальной. Она не относилась к какой-то конкретной функциональности приложения и поэтому не подходила в бэклоги продуктовых команд. Выход был один: засучить рукава и самому разобраться, что пошло не так. Не даром же я performance engineer.
Достаточно плотно разработкой программного обеспечения для часов я занимаюсь с 2017 года. За этот период сменилось 4 версии WatchOS (5, 6, 7, 8). Появилось больше функционала и исправлено множество баг с внедрением каждой новой версии Swift. Complications стали более самостоятельной частью приложения.
За 5 лет работы в сфере разработки приложений для часов мне пришлось столкнуться с множеством различных проблем и задач. Я хотел бы поделиться опытом и получить критические замечания относительно проделанной работы. Заранее сделаю оговорку, что решения, используемые в моей разработке, не претендуют на истинно верные. Не буду спорить, что что-то можно было бы сделать по-другому и лучше.
Представьте: теплый осенний вечер, на столе перед вами чашечка чего-нибудь вкусного, за окном порхают пожелтевшие листья, тонко насвистывает ветер, но на душе скребутся коварные мыши. И вам точно известно, откуда эти мыши растут: еще летом вышел стабильный Jetpack Compose, а вы таки не затащили его в ваши продакшн-приложения.
Всем привет! Меня зовут Паша Стрельченко, я Android-разработчик в hh.ru. В этой статье поведаю историю о том, как начиналась адаптация Jetpack Compose в нашем продакшн-приложении.
Расскажу как я решил погрузиться в мобильную разработку. Какую поставил цель, какие ресурсы выделил для её достижения, с какими трудностями столкнулся и как решил возникшие проблемы. Также будет немного аналитики, размышлений о карьере программиста и личного опыта при взаимодействии с рекрутерами.
Привет, Хабр! Меня зовут Сергей, я занимаюсь мобильной разработкой 13 лет и недавно стал руководителем разработки мобильного приложения «Пункты выдачи заказов» в Ozon. Невольно став сместителем существующего строя в проекте (фреймворки, технологии, подход), я стал часто слышать вопрос: «Почему вы отказались от Flutter?».
Слышал я этот вопрос прежде всего от разработчиков моей команды и соискателей на наши вакансии, потом во время доклада на эту же тему на конференции Panda Meetup, в конце концов, даже менеджер нашего проекта подошёл с вопросом: «Ну а всё же почему?». Настолько людей захватывает эта тема, что я решил поделиться развёрнутым ответом.