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

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

Я продолжил эксперименты с прототипом программы PhotoGuru, чтобы понять может ли распознавание «стиля» фотографии чем-то помочь пользователю.

В новой версии обновлен интерфейс и программа выдает всего один ответ. Чаще всего, это фамилия фотографа и процент «похожести» фотографии пользователя на стиль одного из шести фотографов.

Привет, Хабр! Представляю вашему вниманию перевод статьи "UICollectionView Tutorial: Changing presentation on the fly".

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

В результате мы получим такой пример:

Swift 5 — долгожданный релиз, включающий в себя несколько десятков улучшений и исправлений. Но самой главной целью релиза Swift 5.0 было достижение ABI стабильности. В этой статье вы узнаете, что такое ABI и что стабильный ABI даст iOS/macOS разработчикам. А также проведём разбор нескольких новых фич Swift 5.

Джозеф Райт, «Пленный» — иллюстрация «сильного» захвата

Список «захваченных» значений находится перед списком параметров замыкания и может «захватить» значения из области видимости тремя разными способами: используя ссылки «strong», «weak» или «unowned». Мы часто его используем, главным образом для того, чтобы избежать циклов сильных ссылок («strong reference cycles» aka «retain cycles»).
Начинающему разработчику бывает сложно принять решение, какой именно применить способ, так что вы можете потратить много времени, выбирая между «strong» и «weak» или между «weak» и «unowned», но, со временем, вы поймёте, что правильный выбор — только один.

В предыдущей статье мы узнали о причинах нестабильности unit-тестов и способах борьбы с этим. Теперь мы хотим рассмотреть один из новых инструментов Apple для отладки и профилирования кода. Речь о представленном на WWDC 2018 фреймворке для логирования os_log, который был расширен инструментом для анализа производительности — os_signpost.



В одном из спринтов нам поставили задачу реализовать генерацию pdf-документа на client-side. Мы выполнили задачу и успешно продемонстрировали результаты команде. Но нам захотелось убедиться в эффективности технических нюансов принятого решения. В этом нам помог signpost. С ним нам удалось ускорить отображение документа в несколько раз.

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

Сейчас практически 100% приложений используют работу с сетью, поэтому вопрос организации и использования сетевого слоя встает перед каждым. Есть два основных подхода к решению этой проблемы, это либо использование сторонних библиотек, либо собственная реализация сетевого слоя. В данной статье мы рассмотрим именно второй вариант, причем попробуем реализовать сетевой слой с использованием всех последних возможностей языка, применяя протоколы и перечисления. Это избавит проект от лишних зависимостей в виде дополнительных библиотек. Те, кто хоть раз видел Moya, сразу узнают множество схожих деталей в реализации и использовании, так оно и есть, только в этот раз мы все сделаем своими руками, не трогая Moya и Alamofire.

Как-то раз я (ну ладно, даже не я) столкнулся с задачей добавить в UICollectionView с определенным типом ячеек одну ячейку совершенно другого типа, причем делать это лишь в особенном случае, который обрабатывается «выше» и никак не зависит от UICollectionView напрямую. Задача эта породила, если мне не изменяет память, пару-тройку уродливых if-else-блоков внутри методов UICollectionViewDataSource и UICollectionViewDelegate, которые благополучно осели в «production»-коде и, наверное, никуда оттуда уже не денутся.

В рамках упомянутой задачи смысла продумывать какое-либо более элегантное решение, тратить на это время и «думательную» энергию, не было. Тем не менее эта история мне запомнилась: я размышлял над тем, чтобы попробовать реализовать некий «datasource»-объект, который бы мог составляться из любого числа других «datasource»-объектов в единое целое. Решение, очевидно, должно быть обобщенным, подходить для любого числа составляющих (включая ноль и один) и не зависеть от конкретных типов. Оказалось, что это не только реально, но и не слишком сложно (хотя сделать код при этом еще и «красивым» – немного труднее).

Я хотела бы представить концепцию Функционального Программирования новичкам самым простейшим образом, выделив некоторые его преимущества из множества остальных, которые реально позволят сделать код более читаемым и выразительным. Я подобрала для вас интересные демонстрационные примеры, которые находятся на Playground в Github.

Функциональное Программирование: Определение

Прежде всего, Функциональное Программирование — это не язык или синтаксис, а скорее всего — способ решения проблем путем разбиения сложных процессов на более простые и последующей их композиции. Как следует из названия "Функциональное программирование", единицей композиции для данного подхода является функция; и цель такой функции — избежать изменения состояния или значений за пределами своей области действия (scope).

В Мире Swift для этого есть все условия, ибо функции здесь являются такими же полноправными участниками процесса программирования, как и объекты, а проблема изменяемости (mutation) решается на уровне концепции value ТИПОВ (структур struct и перечислений enum), которые помогают управлять изменяемостью (mutation) и четко сообщают о том, как и когда это может произойти.

Однако Swift не является в полном смысле языком Функционального программирования, он не принуждает вас к Функциональному программированию, хотя и признает преимущества Функциональных подходов и находит способы встраивания их.

В этой статье мы сфокусируемся на использовании встроенных в Swift (то есть «из коробки») элементов Функционального программирования и понимании того, как можно их комфортно использовать в вашем приложении.

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

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

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

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

Привет! Меня зовут Азат Зулькарняев, я занимаюсь разработкой iOS-приложений в компании Badoo. При создании мобильных приложений большая часть времени уходит на разработку UI, и оптимизация этого процесса всегда является актуальной темой в среде разработчиков. Мой коллега Алексис Сантос написал статью о том, с какими проблемами мы столкнулись и как двигались в сторону их разрешения при работе над этой задачей. Я решил поделиться с вами переводом. Также рекомендую посмотреть запись недавнего доклада Игоря Савельева на Mobius 2018.

Несколько месяцев назад я наткнулся на очень интересный документальный сериал от Netflix — «Абстракция: Искусство дизайна». В нём подробно рассматривается работа дизайнеров из разных сфер: архитектура, графический дизайн, мода и т. д. Нетрудно заметить определённое сходство их работы с деятельностью iOS-разработчиков, занимающихся реализацией пользовательских интерфейсов. В частности, ведя работу над крупным проектом, дизайнеры стараются разбить её на множество мелких задач по принципу «разделяй и властвуй» и получают возможность собрать все элементы воедино на более позднем этапе.

Это последняя часть моего обзора компилятора Swift. Я покажу, как можно осуществить генерацию LLVM IR из AST и что выдаёт настоящий фронтенд. Если вы не читали предыдущие части, то переходите по ссылкам:

• Общий обзор компонентов
• Разбор исходного файла
• Swift intermediate language

Продолжаем изучать компилятор Swift. Эта часть посвящена Swift Intermediate Language.

Если вы не видели предыдущие, рекомендую перейти по ссылке и прочитать:

• Общий обзор компонентов.
• Разбор исходного файла.

Сегодня хочу вам быстренько рассказать как тестировать асинхронный код.

Представьте ситуацию, что вам надо загрузить данные из интернета и проверить все ли работает нормально, либо еще какую-нибудь задачу, которая выполняется асинхронно. И как же его протестировать? Что если попробовать так же как и обычный синхронный код?!

    func testAscynFunction() {
        someAsyncFunction()
    }

    func someAsyncFunction() {
        let bg = DispatchQueue.global(qos: .background)
        bg.asyncAfter(deadline: .now() + 5) {
            XCTAssert(false, "Something went wrong")
        }
    }

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

Для решения такой проблемы в тестах есть одна замечательная вещь:

Полгода назад мы представили одну из самых впечатляющих функций Badoo — прямые трансляции. Среди прочего она позволяет пользователям выразить благодарность любимым стримерам в виде подарков. Мы хотели сделать эти подарки максимально яркими и привлекательными, поэтому решили их оживить — другими словами, анимировать. А чтобы было ещё интереснее, мы планировали обновлять подарки и анимации каждые несколько недель.

iOS-инженеры наверняка догадались, о каких объёмах работы идёт речь: чтобы удалять старые и добавлять новые анимации, необходимо совершить множество действий с клиентской стороны. Для этого в каждом релизе должны быть задействованы Android- и iOS-команды, а вкупе со временем, необходимым на одобрение обновления в App Store, это означает, что запуск каждого релиза с обновлёнными анимациями может занять несколько дней. Однако нам удалось решить эту проблему, и сейчас я расскажу как.

Архитектура решения

К тому времени мы уже умели экспортировать анимации Adobe After Effects (далее — AAE) в понятный нашему iOS-приложению формат при помощи библиотеки Lottie. В этот раз мы пошли чуть дальше: решили хранить все актуальные анимации на сервере и скачивать их по мере необходимости.

Была цель создать приложение на mac, которое может распознавать текст кода с изображений и видео.

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

Проблема облегчается тем, что язык на котором пишут код всегда английский и ширина между всеми буквами одинаковая (моноширинный шрифт) — такие используются для программирования, и в этих шрифтах легко увидеть разницу между 1 и I, 0 и O и тд.

Если вкратце, то задача сводится к двум частям:

1. Нахождению самой буквы с ее границами

И с этим шикарно справился Vision, новый framework от Apple.

2. Распознавание буквы в заданных границах

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

Наглядный пример:




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

С ростом проекта, скорость компиляции проекта замедляется. Особенно это заметно становится, когда тестируешь программу, делая параллельно небольшие изменения в программе.

Сначала давайте узнаем как долго компилируется проект до наших улучшений. ЧТобы это сделать надо в терминале ввести

defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES

Для этого нужно зайти в раздел Product зажать alt и нажать Clean Build Folder, а потом собрать проект заново. Мой проект компилируется 81 секунду. Посмотрим какой результат будет после улучшения.



Нам, в первую очередь, стоит узнать какие места приводят к замедлению компиляции. По умолчанию Xcode не показывает предупреждения, где проблема, но мы можем это исправить.
Самые «тяжелые» места большие функции и проверка типов. Поэтому нам нужно вписать эти две строчки в раздел Build Settings -> Other Swift Flags -> Debug

-Xfrontend -warn-long-function-bodies=100
-Xfrontend -warn-long-expression-type-checking=100

(здесь у нас стоит 100мс время компиляции, мы можем поставить любое число)


Пример моего рабочего проекта



У меня есть участок который занимает 13778 ms, скорее всего у вас не будет такого, но из-за специфики проекта у меня такие участки есть. Так как там построено бинарное дерево для OCR.
Из-за глубокой вложенности друг в друга и определения типа только в самом начале, перед знаком равенства, компилятору требуется много времени понять какой перед ним тип. (Дерево занимает 30 строк, вот его часть)

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

О том, как я решаю данную проблему — под катом.

Вторая часть моего рассказа о компиляторе Swift. Мы начнём изучать фронтенд, а точнее те его части, которые отвечают за первоначальный разбор и анализ исходного кода.