iOS *

Мы продолжаем сражаться с шаблонным кодом в табличных экранах iOS-приложений. 

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

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

В этой статье рассмотрим, как избавиться и от такого кода. 

Наверняка, каждый разработчик, которому необходимо было программировать сетевой слой приложения решал задачу передачи параметров запроса. В большинстве случаев это несложная задача, которая решается стандартными средствами, которые предоставляет нативный sdk либо язык программирования. Но если рассматривать ситуацию в контексте платформы iOS и языка программирования Swift, то тут же станет ясно, что компилятор выдает ошибку при попытке сериализации параметров в виде словаря [String: Any]. Однако, благодаря нововведениям, которые появились в iOS 15.4 и Swift 5.6 сериализация словаря сильно упростилась.

Всем привет! Меня зовут Игорь Сорокин. В этой статье я поделюсь историей о том, куда нас завёл очередной рефакторинг, как мы оттуда выбрались, попутно разработав слой хранения данных. Также приведу практические примеры реализации, покажу подход, который удалось разработать, и расскажу об особенностях, с которыми мы столкнулись. Но обо всём по порядку.

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

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

Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).

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

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

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

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

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

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

Все примеры реализованы на Haxe + OpenFL), но код должен быть понятен всем, кто знаком с семейством языков ECMAScript. Главное же тут не код, а те идеи, которые за ним лежат.

Привет! Меня зовут Георгий Мишин, я мобильный разработчик в СберМаркете. Хочу рассказать, как подключить Swift в React Native-проект. В рамках статьи создадим простенький нативный модуль и компонент, обсудим layout в React Native-приложении и поговорим, что же происходит в shadow thread.

Это текстовая версия моего выступления на Android Meetup | СберМаркет Tech.

Привет! После прочтения прошлых двух статей (первая, вторая) и вас есть все вводные - мы знаем, какие проблемы необходимо решить и знаем новую модель по работе с асинхронными задачами.

Теперь можно изучать новые синтаксические конструкции языка Swift.

На WWDC 2022 Apple представила новый инструмент RoomPlan, реализованный на основе ARKit 6, который использует LiDAR датчик на новейших iPhone и iPad для быстрого создания 3D планов комнат. По словам Apple, API может быть полезен для приложений в сфере недвижимости, архитектуры и дизайна интерьеров, поскольку он, с одной стороны, точен и гибок в настройке и экспортировании результатов а, с другой стороны, достаточно прост в использовании. Так ли это, давайте разбираться.

По крайней мере в последнее десятилетие, количество приложений, которым требуется доступ в интернет, неимоверно возросло. Причем для большинства проектов требуется только выполнение REST запросов и загрузка изображений, с созданием preview. В связи с чем, необходим своего рода менеджер сетевых запросов для загрузки данных из сети. Далее будет представлен NetworkManager, с помощью которого выполняются REST запросы, а также загружаются файлы, в том числе и изображения.

Не так давно WWDC21 представила новый интерфейс асинхронности async/await. Это одно из самых важных обновлений Swift  за последнее время. Меня, как iOS-разработчика, это событие не могло оставить равнодушной. Я решила вникнуть в нюансы работы async/await и сейчас хочу поделиться своим пониманием механизма, а также показать все его внешние и некоторые внутренние преимущества.  

Для начала давайте разберемся с терминологией.

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

Внедрение SwiftUI (далее — SUI) в уже существующее приложение, написанное на UIKit, в середине 2022 г. уже не является вопросом времени, а скорее, определяется наличием соответствующих навыков. Перевод приложения Утконоса – одного из лидеров e-commerce на российском рынке – на SUI мы начали в конце 2020 года, когда подняли минимальную поддерживаемую версию iOS до 13-ой.

Ниже хочу поделиться опытом перевода UIKit-вого таб-бара на TabView, со всеми подводными камнями: когда у вас есть экраны, написанные как на SUI, так и на UIKit.

Возможно ли создать интерфейс для получения любого типа данных одинаковым способом?

Это исследование данных. Как внутри программы мы получаем данные, создаем, трансформируем и передаем.

Мой опыт разработки под iOS с 2008 года, примеры на языке Swift.

Для этого нам даже не понадобится писать код (ну почти). CocoaPods по мнению многих доживает свои славные времена, ведь развитие и распространение SPM (Swift Package Manager) продолжает набирать обороты. Но для тех, кто из вас до сих пор использует CocoaPods в проде, эта статья может оказаться актуальной.

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

Для этого нам понадобится связка плагина CocoaPods и Xcode.

Прежде чем приступить к управлению Settings bundle, давайте вкратце рассмотрим концепцию.