Swift *

Эта таинственная история рассказывает о том, как два брата акробата программиста Чук и Гек начали делать свой проект на SwiftUI и столкнулись с неведомым! Как Optional притворялся View и к чему это привело.

Эту статью я решил написать под впечатлением от выступления Евгения Ртищева (@katleta) на конференции Mobius. Так же как и в его докладе, в этой статье я хочу показать, как можно, используя подзабытые нативные средства iOS, без труда выполнять простые и очень частые задачи.

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

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

Эта о том, как нам удалось автоматизировать превращение SDK из кроссплатформенной библиотеки на С++ в привычную свифтовую библиотеку. Иначе говоря, как мы соединяли Swift с C++. Спойлер: без изобретения велосипеда не обошлось.

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

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

Привет, Хабр! Меня зовут Никитин Алексей, я iOS разработчик в компании 65apps. Хорошо было бы порассуждать о Dragon and Dangerous, но нет. Речь пойдет о перемещении объектов. Перетаскивание как внутри одного приложения, так и между разными — с точки зрения пользователя вещь обыденная. Но под капотом механизма D'n'D в современных приложениях могут скрываться разные варианты решения. О них и поговорим.

Привет! На связи iOS-разработчик KODE — Семён Медведев. Наша команда разрабатывает крутые цифровые продукты для государства и бизнеса, в том числе мобильные приложения.

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

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

В мобильных приложениях табличные экраны занимают значительное место в общем объёме интерфейса. Это происходит благодаря их возможности отображать большое количество контента. Но есть и обратный эффект — программирование таких экранов порождает много однотипного кода.

В прошлых своих статьях мы начали решать проблему шаблонного кода и его размножения путём введения нового подхода, а также поговорили об универсальном источнике данных для реализованных экранов. В этом тексте мы рассмотрим очередную подчасть нашего решения — конфигурируемый контроллер и фабрики для соединения всех компонентов воедино. Подробно и в деталях покажем, как реализовывать View-слой, придерживаясь принципов SOLID.

Вне зависимости от того, какую архитектуру (MVC, MVVM, VIPER и др.) вы используете, компоненты из этой статьи помогут сократить время разработки, поиска и исправления ошибок и добавления нового функционала.

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

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

Всем привет! 

Вышел AppCode 2021.3, а значит, пора о нем рассказать. 

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

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

Мы в iOS команде Vivid Money стремимся глубже понимать инструменты, которыми пользуемся каждый день. Один из таких – это язык программирования Swift. Он состоит из нескольких частей: компилятора, стандартной библиотеки и рантайма. Компилятор преобразует код понятный для человека в код понятный компьютеру. Стандартная библиотека предоставляет разработчикам готовые структуры данных, оптимизированные для применения в боевых проектах. А вот рантайм – это, поистине, сердце языка. В нем происходит выделение памяти, динамическое приведение типов и подсчет ссылок. И нам стало интересно, как реализован подсчет ссылок в рантайме. И  вот мы вдохновились публикациями легендарного Майка Эша (Mike Ash), собрали компилятор и начали исследовать. Посмотрели на работу алгоритма подсчета ссылок и в этой статье расскажем вам о нём.

Обычно, в учебных пособиях, книгах и прочих источниках информации, class'ы объясняют примерно так «class это - описание объекта, а объект это экземпляр класса и бла бла бла», в принципе, это частично отражает суть конструкции, но называть class в рамках языка Swift, описанием объекта, будет не совсем корректно т.к. он же еще и представляет собой тип данных и вообще можно использовать классы как независимые, самодостаточные сущности, которые не требуют инициализации. Поэтому начинать со слов «Возьмем объект животного, пускай это будет кот...» я конечно же не буде. И вообще, давайте не будем о "сложном" т.к. материал рассчитан все же на новичков, а новички могут и не знать, что такое, эти ваши объекты и инициализации. В общем я считаю подобное (я про формулировку) не достаточно информативным, поэтому будем разбирать все на примерах с переходом от простого к более сложному. Попутно к ознакомлению с классами, мы будем так же рассматривать и другие возможности языка, но обо всем по порядку.

Большинство соревнований для программистов требуют максимально быстрого решения и реализации алгоритмических задач на любом из языков программирования. Среди мобильных разработчиков популярны хакатоны, но сегодня речь пойдет о контестах. Наиболее известные из них – Codeforces Rounds, VK Cup Engine, ACM ICPC. Мы поговорим о том, как они устроены, какие плюсы и минусы есть у разработчиков с «олимпиадным» бэкграундом и как этот опыт влияет на работу с коммерческими задачами в мобильной разработке.

Об управление памятью в iOS ходят много слухов, поэтому я собрал все самые интересные в интернете и попробовал их структурировать в один большой

Примечание

Слова layout, autolayout и constraints я перевёл, соответственно, как вёрстка, автовёрстка и ограничения.

Работа с автовёрсткой

Проблемы автовёрстки решать непросто. Запуская приложение, надеешься, что все установленные ограничения работают корректно, а получаешь кучу ошибок автовёрстки в логах консоли.

Interface Builder неплох как визуальный редактор вёрстки. В нём есть индикация некорректных граничных параметров. Однако ваша вёрстка может отличаться от видимой в IB. На экран приложения могут влиять различные параметры — например, ответы на сетевые запросы или локально сохранённые данные. Более того, могут быть экраны, частично или полностью построенные на информации, заданной сервером. От сервера может поступать вообще всё что угодно, в том числе шрифты, цвета и формы.

Кажется, остаётся только вручную разбирать гигантский лог ошибок автовёрстки. Но есть и другие варианты.

Я человек далекий от программирования и люблю бить баклуши. Но случилось непредвиденное, моему сербскому другу Джонни, приехавшему в гости, понадобился QR-код. Пришлось расчехлить клавиатуру.

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

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

●      Покажем использование на конкретном примере,

●      Опишем результат с позиции SOLID,

●      Обсудим достоинства и недостатки подхода.

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

Акторы (Actors) — это фича, являющаяся частью структурированного параллелизма (Structured Concurrency) Swift, которая предлагает совершенно новый формат для написания и обработки асинхронного кода. Хотя они и являются чем-то инновационным для языка Swift, сама технология новой не является. Многие языки успели обзавестись поддержкой акторов и async/await раньше, чем Swift, но что интересно, так то, что везде они реализованы одинаково. Только-только получив этот функционал в Swift, мы уже можем многому научиться на опыте разработчиков, использовавших их в других языках.

Девять из десяти экранов любого iOS-приложения имеют табличный вид. Неважно, как реализовано это представление — на UITableView или UICollectionView, но для его реализации необходимо каждый раз писать шаблонный код:

1) реализация табличного источника данных (UITableViewDataSource);

2) реализация табличного делегата (UITableViewDelegate);

3) реализация обратных уведомлений вью об изменениях данных;

4) типичный код по работе с различными коллекциями (плоские, секционные списки на основе массивов, упорядоченных множеств и прочих коллекций) и преобразование их к табличным структурам для источника данных коллекции;

5) все предыдущие пункты придётся повторить, если вы вдруг решите использовать UICollectionView.

Такое большое количество шаблонного кода значительно увеличивает время разработки, тестирования и ревью. Для уменьшения time-to-market мы в ПСБ создали микромодуль, который скрывает в себе весь шаблонный код. Новый модуль представляет собой набор абстрактных реализаций, лёгких в переиспользовании и достаточно универсальных для использования в 90% общих задач. В этой статье расскажем подробности.

С весны этого года каждый iOS-разработчик должен запрашивать разрешение пользователя на использование рекламного идентификатора IDFA. В предыдущей статье мы сделали подробный обзор изменений в App Store и их влияния на мир iOS-разработки.

А сегодня — практический материал. Расскажем, как с помощью нового фреймворка App Tracking Transparency добавить в своё приложение обязательный запрос на использование персональных данных, как потом эти данные передавать рекламным сетям и что делать, если пользователь решил не делиться своей активностью.