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

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

На конференции WWDC 2019 был представлен новый фреймворк Combine. Всё последнее десятилетие среди программистов становились популярными декларативный и Event-based подходы к разработке приложений, т. к. они дают преимущество в скорости разработки приложений.

В этой статье мы расскажем о том, как быстро и качественно сделать интерфейс приложения с помощью SwiftUI. А также зачем компании Apple новый UI-фреймворк.

Перед написанием данной статьи я спросил в нескольких iOS-чатах про эту фичу Swift, однако никто из iOS-разработчиков вообще(!) не знал о существовании Label Statements.

В предыдущей заметке мы упомянули такие термины, как Expression (Выражение), Statement (Предписание) и Declarations (Объявление), а также подробно поговорили о первом из них. Продолжаем разговор.

Expressions, Statements и Declarations — три важных термина, о которых разработчики либо не знают, либо не понимают смысл их различий.

Если подумать, каждая сложная система состоит из большого количества менее сложных частей. Например, у машины есть двигатель, колеса, кресла, руль, стёкла. Все эти части вместе составляют автомобиль, которым можно пользоваться только потому, что все его части правильно работают и хорошо подогнаны друг к другу. Каждая из таких частей на английском языке называется «unit». И это именно тот unit, который тестирует unit-тесты.

Паттерн delegate является одним из самых широко используемых в Cocoa и применяется буквально повсеместно. Многие делегаты, например, UIApplicationDelegate, объявляют внутри себя большое количество методов. И если реализовывать их в одном классе, то класс становится огромным, тяжело читаемым и плохо тестируемым. Так как мы не можем определить больше одного делегата, ситуация кажется безвыходной.

В реальных приложениях практически каждый класс имеет немалое число зависимостей — других классов, на которые он рассчитывает для осуществления своих задач. Эти зависимости, в свою очередь, могут зависеть от других классов, и т.д.

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

И здесь на помощь приходит паттерн Dependency Injection, или, сокращенно, DI.