User
Всем привет, меня зовут Сергей, я работаю в компании Joy Dev в должности iOS TeamLead. Эта статья - моя “проба пера” на Хабре. В ней, вместе с обзором видов диспетчеризации в Swift, мы рассмотрим несколько примеров, когда реализация методов в extension может вести себя неожиданным образом. Итак.
Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.
Как получается, что код становится мало понятным даже для его авторов? Почему нейминг так важен? Как придумывать названия, не применяя целые теории нейминга? Как лёгким процессом организовать работу с неймингом в команде? На все эти вопросы мы ответим в статье.
Преамбула
Этот пост в блоге является одним из серии. Обязательно прочитайте все части!
Modern SwiftUI: Parent-child communication
Modern SwiftUI: Identified arrays
Modern SwiftUI: State-driven navigation
Modern SwiftUI: Dependencies
На прошлой неделе мы завершили нашу амбициозную серию из 7 статей, посвященных современным передовым методам разработки SwiftUI. В этих эпизодах мы перестроили приложение компании Apple “Scrumdinger” с нуля (исходный код здесь), которое является отличной демонстрацией многих проблем, с которыми можно столкнуться в реальном приложении. На каждом этапе пути мы ставили перед собой задачу написать код максимально масштабируемым и ориентированным на будущее, в том числе:
Командная строка — довольно мощный инструмент. Его можно использовать для автоматизации множества вещей здесь и там. Очевидно, речь идёт не только о сценариях Shell, из него можно запустить и любой другой инструмент. Но использовать его напрямую не всегда возможно.
XCTest, например, работает внутри песочницы, это означает, что вы буквально не можете даже высунуть нос из коробки. Ну, почти. Давайте обойдём это ограничение и узнаем, как получить доступ к командной строке из тестов.
В разных языках программирования применяется механизм диспетчеризации методов (Method Dispatch), и все разработчики имеют с ним дело. Однако, не все это осознают и не все понимают, как этот механизм работает. Поэтому данная статья будет полезна всем разработчикам на Swift, которые хотят погрузиться глубже в диспетчеризацию методов и понять принципы ее работы, что в свою очередь позволит писать более эффективный код и избежать появления некоторых неочевидных проблем. Также статья будет полезна тем, кто в поисках работы – данный вопрос часто обсуждается на собеседованиях iOS разработчиков.
Давайте разберемся, что же такое диспетчеризация, рассмотрим ее виды и случаи применения.
Прошло много времени с тех пор, как язык программирования Swift был представлен на WWDC в 2014 году. С тех пор внедрение Swift сторонними разработчиками, безусловно, было массовым. Тем не менее, Objective-C всё ещё существует.
В этом посте мы предоставим несколько советов и приёмов для успешной разработки XCFrameworks (новые способы упаковки и поставки библиотек в различных вариантах). XCFrameworks сочетают Swift и Objective-C таким образом, чтобы совместимость языков не ставила под угрозу публичные API-интерфейсы фреймворка и не влияла на них.
«Начинайте тестировать как можно раньше» — эта фраза часто встречается в разных докладах и обучающих материалах. Это правда, чем раньше наши тесты найдут проблему, тем быстрее и дешевле мы ее решим. Это одна из главных причин эффективности CI. Часто встречаются команды, у которых очень много написанных автотестов, но они не используют тесты как подход к CI. Существуют различные причины, по которым команда считает, что эти тесты нельзя использовать в CI. Возможно, выполнение тестов занимает слишком много времени или они недостаточно надежны
Думаю, не я один упирался в стеклянный потолок, когда действия есть, а результата нет. Кажется, еще чуть-чуть и все изменится: бизнес попрет, навыки прокачаются, доходы увеличатся, но несмотря на все усилия — ничего не меняется. Хочу поделиться несколькими ловушками мышления, из-за которых возникает бег на месте, и которые доставили мне особенно много хлопот.
Всем привет!
В прошлой статье, посвящённой A/B-тестированию, мы коснулись технических деталей устройства нашей A/B-платформы, которая обеспечивает нам супербыстрое распределение пользователей по вариантам. Теперь пришло время поговорить о методологии и процессе A/B-тестирования, а если точнее, то о проблемах и заблуждениях, которые могут привести к тому, что, проснувшись однажды среди ночи, вы почувствуете нестерпимую боль ниже спины от внезапного осознания очень простого факта —все проведённые вами A/B-тесты невалидны.
Это не пустые слова, результат многомесячного труда кучи людей может обесцениться в один момент, например, из-за неправильной агрегации данных или неправильной оценки статистической значимости равенства средних для ratio-метрики. Что уж говорить о более сложных проблемах, таких как множественное тестирование и ранняя остановка ваших тестов.
У A/B-тестов есть хорошее свойство — они либо работают, либо нет. Сегодня вы узнаете, что нужно учесть, чтобы заставить ваши эксперименты работать и приносить тем самым пользу бизнесу. Мы рассмотрим шесть самых распространённых причин, ведущих к несостоятельности системы принятия решений с помощью A/B-тестирования.
Привет, Хабр! Меня зовут Сергей, я iOS-разработчик в компании SimbirSoft.
Уже наступил 2023 год, а обсуждения на тему выбора инструмента для обработки асинхронных событий не утихают. На сцене привычные колбэки, нотификейшн-центры с «бородатыми» Objective-C-селекторами, разные фреймворки для реактивной разработки, а не так давно Apple представила модный Swift Concurrency.
Combine все больше набирает популярность в продакшене. За счет нативного происхождения у него хороший уровень оптимизации, его легко «склеивать» как с существующими легаси-инструментами, так и с новыми — SwiftUI или async/await.
Пестрый «зоопарк» заставляет задуматься: что выбрать для нового проекта, а что для приложения с многолетней историей?
Поскольку Combine является отличным претендентом для разработки современных приложений с перспективой на будущее, о нем и поговорим подробнее.
Это первая часть статьи, где мы познакомимся с Combine, сравним его с RxSwift. Материал будет полезен для тех, кто до этого не сталкивался с реактивщиной, а также тем, кто успел поработать с аналогичными инструментами.
В iOS 16 Apple провела масштабную модернизацию Экран Блокировки. Одной из самых ожидаемых функций, которая появилась вместе с обновлением, - виджеты Экрана Блокировки. Как следует из названия, виджеты Экрана Блокировки — это виджеты, отображающие легко просматриваемый контент, который постоянно виден на экране блокировки iPhone и iPad.
Поскольку и виджеты Главного Экрана, и виджеты Экрана Блокировки работают на WidgetKit, способ создания виджета Экран Блокировки очень похож на то, как мы создаем виджеты Главного Экрана. Поэтому в этой статье я не буду показывать вам, как настроить и создать виджет с нуля, как это было описано в моей предыдущей статье.
Вместо этого я сосредоточусь на том, как обновить код существующих виджетов Главного Экрана для поддержки виджетов Экрана Блокировки.
С учетом всего сказанного, давайте начнем!
С помощью нескольких макетов мы можем компоновать представления различными способами. Одним из важнейших параметров является интервал (spacing) между дочерними элементами конкретного макета. На этой неделе мы узнаем, как создать кастомный макет, позволяющий задавать определенное расстояние между представлениями, и как соблюдать платформенно-ориентированные предопределенные правила интервалов в SwiftUI.
В прошлой статье я описал, как стартует процесс нашего приложения, что такое ActivityStarter и как стартуют все Activity.
Во второй части расскажу, как показываем сплеш-скрин, что такое Window, что происходит через первым показом Activity приложения, более подробно, как вызываются методы жизненных циклов Activity и что происходит с Activity при сворачивании и разворачивании.
При создании пользовательского интерфейса в SwiftUI мы, как правило, создаем два типа компонентов пользовательского интерфейса: экраны и (переиспользуемые) вью. Обычно мы начинаем с создания прототипа экрана, что неизбежно приводит к Massive ContentView, далее который мы начинаем рефакторить в более мелкие, используемые повторно компоненты.
Улучшения Функции Автозавершения в Xcode 14
Apple описывает Xcode 14 как «все, что вам нужно» для создания программного обеспечения для своих платформ. Компания реализовала ряд улучшений, таких как несколько обновленных функций автозавершения, для повышения производительности Xcode. Читайте дальше, чтобы узнать, какие из них я считаю особенно важными, и посмотреть, как они работают на практике.
Hello, World! Меня зовут Денис. Я IOS разработчик, пишу приложения для App Store. Хочу поделиться своим небольшим опытом на UIKit и SwiftUI.
Первый запуск
На WWDC19 Apple предоставила декларативный фреймворк SwiftUI. Новый фреймворк позволяет уменьшать время на написание UI-составляющей своих приложений.
Я написал приложение под названием SwiftUI View Lifecycle. Приложение позволяет вам наблюдать, как различные конструкции и контейнеры SwiftUI влияют на жизненный цикл вью, включая время жизни его состояния и время вызова onAppear. Код приложения находится на GitHub. Его можно собрать для iOS и macOS.
Цель этой публикации — помочь всем ищущим стать эффективнее и улучшить собственные результаты за счет организации своего рабочего пространства.
Речь пойдёт о следующих вещах:
· Смартфоны и популярные приложения — в чем их проблема и почему они мешают фокусироваться.
· Рабочий стол и текстовый редактор — как лучше настроить, чтобы улучшить свою результативность.
· Метод помидора — что с ним не так и мой опыт его использования.
