User
Всем привет! В прошлую субботу, 29 февраля, прошёл наш первый митап для Android-разработчиков в Нижнем Новгороде. Спикеры выступали с докладами о создании красивых анимаций с помощью MotionLayout, Kotlin Coroutines, CI/CD инфраструктуре для Android и дизайн-системе Авито.
Под катом вас ждут видеозаписи всех выступлений с таймкодами для удобной навигации, ссылки на презентации и фотоотчёт с митапа.
Начиная с версий Gradle 4.7 и Kotlin 1.3.30 появилась возможность получить ускорение инкрементальной сборки проектов за счет корректной работы инкрементальной обработки аннотаций. В статье разбираемся, как в теории работает модель инкрементальной компиляции в Gradle, что нужно сделать, чтобы раскрыть весь ее потенциал (не лишаясь при этом кодогенерации), и какой прирост к скорости инкрементальных сборок может дать активация инкрементальной обработки аннотаций на практике.
В этой статье пойдет речь о том, как рассказать человеку, ранее не знакомому с программированием под Android, об основных его компонентах. Заинтересовать и показать, что все не так сложно, как многие думают. При этом сделать это за 15 минут и не уходя в объяснение какой-то базовой теории, которую каждый может прочитать сам и вернуться уже с уточняющими вопросами.
Когда я попробовал сделать это первый раз, был неприятно удивлен собой. Мое "простое и понятное" объяснение превратилось в занудство, в рамках которого четко прослеживалась отчаянная попытка объять необъятное и рассказать в двух словах обо всем понемногу. Нужно ли говорить, что такой рассказ скорее не заинтересует, а напугает Вашего собеседника, попутно уменьшив желание сделать что-то свое, даже если раньше в планах был небольшой калькулятор.
Не секрет, что в Интернете размещено огромное количество статей на эту тему, но в моем случае повествование будет немного отличаться: здесь будет только наглядная практика, без определений и прочих деталей. То есть смотрим — видим — комментируем происходящее. Смотрится, на мой взгляд, все достаточно просто и наглядно, куски кода получились тоже небольшие и очень простые, готовые к быстрому использованию в собственном проекте. Мне кажется, такой подход дает достаточно широкую обзорную картину классических инструментов Android, и при написании первого приложения вместо вопросов "что мне использовать" будут более конкретные вопросы "как именно мне использовать компонент Х". А уже все подробности об этом человек сможет узнать сам — если захочет.
view таким образом, чтобы не нарушать работу системных панелей.
7-8 декабря отгремела конференция для мобильных разработчиков Mobius 2019 Moscow. Доклады прочитаны, гости накормлены, призы разыграны, и вот перед вами разбор самых интересных вопросов из трех quiz’ов со стенда hh.ru.
Данная статья предназначена для начинающих андроид разработчиков с небольшим опытом работы с видео и/или камерой, особенно тех кто начал разбирать примеры grafika и кому они показались сложными — здесь будет рассмотрен похожий код с упрощенным описанием основных шагов, проиллюстрированных диаграммами состояний.
Почему в заголовке вынесен класс Surface? В android множество классов имеют в своем названии слово Surface (Surface, SurfaceHolder, SurfaceTexture, SurfaceView, GLSurfaceView) они не связаны общей иерархией тем не менее объединены низкоуровневой логикой работы с вывод изображений. Мне показалось разумным использовать его в названии чтобы подчеркнуть попытку раскрытия работы именно с этой частью SDK.
Всем привет! Слышали ли вы когда-то про баны приложений и разработчиков в Google Play? Вот вам ещё одна такая история. Плюс попытка собрать в одном месте похожие случаи и предложить какой-то план действий по предотвращению произвола Google в этой области. Ибо нехорошо, когда тебя банят за легальное использование свободного материала. А мне лично нравится идея лицензий на контент типа CC BY-SA, которые разрешают любое оного использование, включая коммерческое. В частности, в том числе из-за такой лицензии, мы, разработчики, имеем такие прекрасные сайты как StackOverflow, где я даже модератором избран. К сожалению, такие компании как Google не уважают идеи, лежащие в основе таких лицензий. Вот вам моя история.
Как Flutter работает на самом деле?
Что такое Widgets, Elements, BuildContext, RenderOject, Bindings?..
Сложность: Новичок
В прошлом году (прим: в 2018), когда я начал свое путешествие в сказочный мир Flutter, в Интернете было очень мало информации по сравнению с тем, что есть сегодня. Сейчас, несмотря на то, что уже написано много материалов, лишь небольшая их часть рассказывает о том, как на самом деле работает Flutter.
Что же такое Widgets (виджеты), Elements (элементы), BuildContext? Почему Flutter быстрый? Почему иногда он работает не так, как ожидается? Что такое деревья и зачем они нужны?
В 95% случаев при написании приложения вы будете иметь дело только с виджетами, чтобы что-то отображать на экране или взаимодействовать с ним. Но неужели вы никогда не задумывались, как вся эта магия работает внутри? Как система узнает, когда обновить экран и какие части должны быть обновлены?
Содержание:
Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.
Я решил начать с буквы O, так как принцип открытости-закрытости, по сути, является центральным. Среди прочего тут есть много важных тонкостей, на которые стоит обратить внимание:
В предыдущей статье мы рассказали про перенос разработки в единый репозиторий с trunk-based подходом к разработке, с едиными системами сборки, тестирования, деплоя и мониторинга, про то, какие задачи должна решать система непрерывной интеграции для эффективной работы в таких условиях.
Сегодня мы расскажем читателям Хабра про устройство системы непрерывной интеграции.
Система непрерывной интеграции должна работать надежно и быстро. Система должна быстро реагировать на поступающие события и не должна вносить дополнительных задержек в процесс доставки результатов запуска тестов до пользователя. Результаты сборки и тестирования нужно доставлять до пользователя в режиме реального времени.
Поддержка огромной кодовой базы с одновременным обеспечением высокой производительности большого числа разработчиков — это серьезный вызов. В течение последних 5 лет в Яндексе идет разработка особой системы непрерывной интеграции. В данной статье мы расскажем про масштаб кодовой базы Яндекса, про перенос разработки в единый репозиторий с trunk-based подходом к разработке, про то, какие задачи должна решать система непрерывной интеграции для эффективной работы в таких условиях.
Много лет назад в Яндексе никаких особенных правил в разработке сервисов не было: каждый отдел мог использовать любые языки, любые технологии, любые системы деплоя. И как показала практика, такая свобода не всегда помогала двигаться вперед быстрее. В то время для решения одних и тех же задач часто существовало несколько собственных или open-source разработок. С ростом компании такая экосистема работала всё хуже. При этом мы хотели остаться одним большим Яндексом, а не разделиться на множество независимых компаний, потому что это дает массу преимуществ: много людей делают одни похожие задачи, результаты их труда можно использовать повторно. Начиная от разнообразных структур данных, типа распределённых хеш-таблиц и lock-free очередей, и заканчивая множеством разного специализированного кода, который мы написали за 20 лет.