Синтаксис async/await, введенный в Swift 5.5, значительно упростил асинхронное программирование, сделав его более доступным и интуитивно понятным. Однако, как и любой мощный инструмент, он может быть использован неправильно. Здесь я хочу рассмотреть пять распространенных ошибок, которые разработчики часто допускают при использовании async/await и предложить стратегии их избегания.

Ошибка 1: Необработка Ошибок

Асинхронные функции Swift могут вызывать ошибки, так же как и их синхронные аналоги. Однако многие разработчики, особенно те, кто только начинает работать с синтаксисом async/await, могут упускать обработку ошибок, что приводит к сбоям или непредсказуемому поведению.

Решение

Синтаксис do-catch в Swift - ключ к обработке ошибок из асинхронных функций. Обернув вызов асинхронной функции в блок do-catch, вы можете перехватить и обработать любые выброшенные ошибки, предотвратив сбои и обеспечивая предсказуемое поведение вашего приложения.

Некоторое время назад, во время подготовки к интервью, я наткнулся на забавную цепочку задач на сайте leetcode.com. Сами задачки не слишком сложны, но их решения довольно любопытны. Кроме того, задачки такого типа довольно часто попадаются на собеседованиях в крупных компаниях.

Написать эту статью меня сподвиг почти случившийся нервный срыв, причиной которого стало мое желание научиться общаться с сторонними API, конкретно меня интересовал процесс декодирования JSON-докуметов! Нервного срыва я, к счастью, избежал, поэтому теперь настало время сделать вклад в сообщество и попробовать опубликовать свою первую статью на Хабре.

Почему вообще возникли проблемы с такой простой задачей?

Чтобы понять, откуда проблемы, нужно сначала рассказать об инструментарии, которым я пользовался. Для декодирования JSON-объектов я использовал относительно новый синтезированный (synthesized) протокол библиотеки Foundation - Сodable.

Codable - это встроенный протокол, позволяющий заниматься кодированием в объект текстового формата и декодированием из текстового формата. Codable - это протокол-сумма двух других протоколов: Decodable и Encodable.

Cтоит сделать оговорку, что протокол называется синтезированным тогда, когда часть его методов и свойств имеют дефолтную реализацию. Зачем такие протоколы нужны? Чтобы облегчить работу с их подписанием, как минимум уменьшив количество boilerplate-кода.

Еще такие протоколы позволяют работать с композицией, а не наследованием!

Вот теперь поговорим о проблемах:

Как часто вы обращали внимание на плавный скролл в мобильных приложениях?

В этой статье я предлагаю рассмотреть технические аспекты работы со сложными таблицами. Кстати говоря, работа с коллекциями будет аналогична.

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

Получается, реализация плавного скролла является одной из наших приоритетных задач, решить которую очень непросто. 

Одним из заметных событий WWDC 2023 для разработчиков, программируемых на языке Swift, стало появление фреймворка SwiftData. В этой статье показано, как создать Схему данных в SwiftData, как выполнить CRUD операции (Create - Создать, Read - прочитать, Update - модифицировать, Delete - удалить), как выполнять запросы Query к данным с помощью предиката Predicate, как использовать "живой" запрос @Queryв SwiftUI и как его динамически настроить. Вы узнаете, как эффективно "закачивать" JSON данные в SwiftData хранилище без блокировки пользовательского интерфейса (UI).

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

Статья основана на документации apple Implementing Modern Collection Views.

Compositional layouts - это декларативный вид API, который позволяет нам создавать большие макеты путем объединения небольших групп макетов. Compositional layouts имеют иерархию, состоящую из Item, Group, Sections, and Layout.

Чтобы создать любой Compositional layouts, необходимо реализовать следующие четыре класса:

NSCollectionLayoutSize: Размеры ширины и высоты относятся к типу NSCollectionLayoutDimension, которые могут быть определены путем установки доли ширины/высоты макета (в процентах по отношению к его контейнеру) или путем установки абсолютных или расчетных размеров.

NSCollectionLayoutItem: Это ячейка нашего макета, которая отображается на экране в зависимости от размера.

NSCollectionLayoutGroup: содержит NSCollectionLayoutItem в горизонтальной, вертикальной или пользовательской формах.

NSCollectionLayoutSection: используется для инициализации секции путем передачи NSCollectionLayoutGroup. Секции в конечном итоге составляют СompositionalLayout.

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

Я могу тут судить только по себе, возвращаясь к собственному становлению и личным ощущениям. Однако, в те далекие времена, когда джуном бы я, мало кто слышал про паттерны и рефакторинг. Но красивый и понятный код был всегда. Были книжки с листингами программ, были исходные коды открытых библиотек и фреймворков. Я тогда недоумевал, почему реальный код, даже написанный, в серьезных, по тогдашним меркам, отечественных организаций, настолько сильно отличается от образцового. Наверное, предполагал я, что напоказ люди пишут один код, а в свободное от написания умных книжек время садятся за компьютер и что-то очень непонятное, но как-то значительно лучше работающее.

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

Несмотря на то, что UIKit постепенно уступает место более современному во всех отношениях SwiftUI, до сих пор остается огромное количество проектов, которые основаны на фреймворке UIKit. Далее будет представлена библиотека, которая позволяет выполнять конструирование внешнего вида намного быстрее и удобнее, чем стандартные средства.

1+2+3+4+5+6+7+8+9+10+11+...

Почему -1/12?

Автор, используя ChatGPT, накатал целую книгу. Читайте кому совсем не жаль своего времени. Кому жаль времени — даже не начинайте. Убийца садовник. В смысле, ответ на вопрос «сколько» вы уже знаете, зачем вам ответ на «почему»?

Город был тёмным и опасным местом, его улицы полны теней и тайн. Детектив знал это слишком хорошо, проведя годы в поисках истины. Но эта задача была другой, более сложной, чем любая, с которой он сталкивался раньше. Сидя в своем тускло освещенном кабинете, глядя на папку на столе, он не мог не думать о морали города. Это было место, где границы между добром и злом были размыты, где каждому было что скрывать, а правосудие часто было лишь мимолётной мечтой. Тем не менее, несмотря на все шансы против него, детектив знал, что должен попытаться. На кону стояли жизни, и он был их единственной надеждой.

* Рассказ в стиле нуар. Детективу дали сложное задание. Начинается с его рассуждений. Детектив упоминает мораль города. Напиши первый абзац.

(Ответ приведён выше)

Не секрет, что на сегодняшний день Swift обладает одними из самых (возможно самыми) функциональными и гибкими в настройке перечислениями. Каждый Swift-разработчик может подтвердить, что работать с ними довольно приятно и удобно. Однако, мало кто задумывается как это устроено внутри. Может показаться, что за подобную функциональность обязательно придётся заплатить либо производительностью, либо памятью, либо размером билда. На самом деле, чтобы максимально избежать подобных издержек, под капотом в языке имеется шесть разных реализаций перечислений.