Давайте представим себе типичную ситуацию. Нашему приложению необходимо выполнить подключение к серверу и получить различные данные. Для примера, пускай это будут: список категорий, список продуктов, стоимость продуктов. Значения это не имеет, просто некая абстрактная задача.
Эти данные мы не можем собрать по ряду определенных причин в рамках одного запроса, поэтому нашей задачей является выполнить несколько запросов и после того, как все они выполнятся (мы получим данные), произведем какие-либо действия. Выполнять действия до получения всех данных нельзя, порядок получения данных нам неизвестен т.к. это асинхронные операции и объем данных так же неизвестен, как и скорость сети и т.д. думаю, в пояснении не нуждается...
А давайте перенесем релиз на завтра? Мне тут один баг осталось пофиксить.
Если у вас только что случились вьетнамские флешбеки, значит эта статья точно для вас. Именно так начинается самый страшный кошмар тестировщика. И тогда происходит всё, что только может произойти: долгое review, баги в тестировании, а сами тесты падают. И пока ты фиксишь одно, тебе приходит уже новая фича, которую хочется выпустить в релиз. Потом — пятница, а мы ничего не зарелизили.
В этой статье я расскажу, как мы пришли к эффективному способу измерения качества релиз-трейна, какие совершали ошибки по пути и с какими сложностями столкнулись в процессе.
Праздничные дни для Додо Пиццы — настоящий хайлоад. К ним мы готовимся заранее и заводим специальные правила.
Самое жаркое время — в декабре: много корпоративов, заказы становятся больше, прибыль выше. Во многих городах плохая погода — где-то выпал снег и дороги не расчищены, где-то очень холодно. Всё вместе это создаёт нагрузку и на IT, и на бизнес. От нагрузки может сломаться что угодно: то очередь задач переполнится, то печь выйдет из строя. Чтобы быть готовыми, мы регулярно проводим нагрузочные тестирования, повышаем закупки ингредиентов, распределяем заказы по пиццериям и много чего ещё.
Для мобильных разработчиков конец года раньше тоже был особенный: с 23 по 27 декабря App Store закрывался на рождественские праздники, приложения не проверялись, опубликовать что-то было невозможно.
Расскажу, как влияют эти ограничения на разработку, какие ошибки мы совершили в прошлые годы и что меняется в расписании. Возможно, что-то из практик пригодится и вам: подсветит риски, поможет договориться о код-фризе с бизнесом.
Мы в iOS команде Vivid Money стремимся глубже понимать инструменты, которыми пользуемся каждый день. Один из таких – это язык программирования Swift. Он состоит из нескольких частей: компилятора, стандартной библиотеки и рантайма. Компилятор преобразует код понятный для человека в код понятный компьютеру. Стандартная библиотека предоставляет разработчикам готовые структуры данных, оптимизированные для применения в боевых проектах. А вот рантайм – это, поистине, сердце языка. В нем происходит выделение памяти, динамическое приведение типов и подсчет ссылок. И нам стало интересно, как реализован подсчет ссылок в рантайме. И вот мы вдохновились публикациями легендарного Майка Эша (Mike Ash), собрали компилятор и начали исследовать. Посмотрели на работу алгоритма подсчета ссылок и в этой статье расскажем вам о нём.
В iOS 15 наконец-то появился способ управления высотой модальных контроллеров. Но насколько гибкой и удобной получилась реализация от Apple? Чтобы разобраться, вспомним, как эта задача решалась раньше, рассмотрим возможности и поведение нового UISheetPresentationController, оценим перспективы его применения в реальных проектах.
Обычно, в учебных пособиях, книгах и прочих источниках информации, class'ы объясняют примерно так «class это - описание объекта, а объект это экземпляр класса и бла бла бла», в принципе, это частично отражает суть конструкции, но называть class в рамках языка Swift, описанием объекта, будет не совсем корректно т.к. он же еще и представляет собой тип данных и вообще можно использовать классы как независимые, самодостаточные сущности, которые не требуют инициализации. Поэтому начинать со слов «Возьмем объект животного, пускай это будет кот...» я конечно же не буде. И вообще, давайте не будем о "сложном" т.к. материал рассчитан все же на новичков, а новички могут и не знать, что такое, эти ваши объекты и инициализации. В общем я считаю подобное (я про формулировку) не достаточно информативным, поэтому будем разбирать все на примерах с переходом от простого к более сложному. Попутно к ознакомлению с классами, мы будем так же рассматривать и другие возможности языка, но обо всем по порядку.
Большинство соревнований для программистов требуют максимально быстрого решения и реализации алгоритмических задач на любом из языков программирования. Среди мобильных разработчиков популярны хакатоны, но сегодня речь пойдет о контестах. Наиболее известные из них – Codeforces Rounds, VK Cup Engine, ACM ICPC. Мы поговорим о том, как они устроены, какие плюсы и минусы есть у разработчиков с «олимпиадным» бэкграундом и как этот опыт влияет на работу с коммерческими задачами в мобильной разработке.
Об управление памятью в iOS ходят много слухов, поэтому я собрал все самые интересные в интернете и попробовал их структурировать в один большой
В свободное время (а иногда и в рабочее) я изучаю микроконтроллеры и собираю умный дом у себя в квартире, а так как по профессии я iOS-разработчик, то на умный дом я смотрю через призму iPhone и HomeKit. После сборки более-менее рабочего умного дома и, столкнувшись с кучей проблем, решил рассказать про свой опыт и устройства в цикле из 2 статей. Первая статья будет небольшим ликбезом в теорию микроконтроллеров и протоколов, а во второй уже поделюсь конкретным применением этих протоколов и фреймворков в моем умном доме.
Сегодня делимся видео для мобильных разработчиков с IT-конференции ЮMoneyDay.
Начнём с процессов в UI. Что помогает команде работать быстро и слаженно и как срезать углы в работе с дизайн-системой? В первом докладе поделились, как наладить разработку в iOS-команде.
Далее перейдем к Android. Во втором докладе рассказали, как подружить мобильное приложение на сотню экранов с серверным API. В третьем докладе показали, как один (!) плагин на Kotlin позволяет опубликовать артефакты в разные репозитории.
Примечание
Слова layout, autolayout и constraints я перевёл, соответственно, как вёрстка, автовёрстка и ограничения.
Работа с автовёрсткой
Проблемы автовёрстки решать непросто. Запуская приложение, надеешься, что все установленные ограничения работают корректно, а получаешь кучу ошибок автовёрстки в логах консоли.
Interface Builder неплох как визуальный редактор вёрстки. В нём есть индикация некорректных граничных параметров. Однако ваша вёрстка может отличаться от видимой в IB. На экран приложения могут влиять различные параметры — например, ответы на сетевые запросы или локально сохранённые данные. Более того, могут быть экраны, частично или полностью построенные на информации, заданной сервером. От сервера может поступать вообще всё что угодно, в том числе шрифты, цвета и формы.
Кажется, остаётся только вручную разбирать гигантский лог ошибок автовёрстки. Но есть и другие варианты.
Обновление данных в интерфейсе всегда задействует немало ресурсов а его реализация может быть выполнена множеством неоптимальных способов. Повышение производительности, не только радует пользователя, но и расширяет круг целевой аудитории с более старыми устройствами. State management Как? Когда? Почему? Каким способом? Лучше всего изменять состояние виджета/древа виджетов? Сейчас можно увидеть большое кол-во различных библиотек и подходов для решения данной задачи. Вопрос обновления данных интерфейса настолько большой, что библиотеки, которые помогают с управлением состояний становятся Архитектурными подходами, паттернами, а статей про то какой подход лучше еще больше. Данное решение подойдет к любому проекту, ему не нужна библиотека и вовсе не обязательно использовать данный виджет.
Первое приложение со SwiftUI
- Шпаргалка по SwiftUI
- Некоторые нюансы работы SwiftUI
- PageView на SwiftUI
- WebImage на SwiftUI (AsyncImage)
Спойлер - нет! Ну, не совсем. Мы привыкли воспринимать UI как визуальную составляющую, но ведь UI – это User Interface. Так вот, интерфейс – это то, с помощью чего пользователь взаимодействует с нашим приложением. В случае с графическим интерфейсом пользователь его видел и воспринимает информацию. Однако он статичный и, когда пользователь хочет взаимодействовать с ним, он использует другие интерфейсы: тачскрин, клавиатуру или мышку. Да, это тоже интерфейсы. И UIKit как раз таки отвечает не за графический интерфейс, а за распознавание пользовательских жестов и их обработку.
Когда я начинал писать эту статью, хотелось рассказать много фундаментальных вещей. Одновременно с этим хотелось, чтобы она была понятна всем, поэтому я начал с описательной части. Со временем понял, что материала получается слишком много и я решил разбить ее на несколько частей. Возможно какие-то вещи для вас покажутся совсем простыми и очевидными, но они нужны для того, чтобы хорошо разобраться и ориентироваться, как же все-таки устроен UI.
Так как же он устроен? У нас же есть базовый класс UIView и куча его стандартных наследников. Мы можем сами создавать свои вью и как угодно их кастомизировать. И все это видим на экране. Почему тогда UIKit и UIView – это не про графический интерфейс? Давайте разбираться.
Я человек далекий от программирования и люблю бить баклуши. Но случилось непредвиденное, моему сербскому другу Джонни, приехавшему в гости, понадобился QR-код. Пришлось расчехлить клавиатуру.
Монолитный проект порос мхом, и хочется разбить его на модули? Рассказываем, какие инструменты помогут сделать это быстрее.
Run Loop (цикл исполнения) является механизмом, который позволяет потокам обрабатывать события (events) бесконечно в любое время.
Run Loop представляет из себя объект, который управляет событиями и сообщениями, обрабатывает их, и предоставляет функцию точки входа для выполнения логики события.
