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

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

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

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

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

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

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

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

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

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

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

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

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

В основном идея использования CI/CD для iOS, да и для других платформ, — это автоматизация рутинной работы. Когда мы работаем над одним приложением, можем вручную собирать небольшой проект. Но команда растёт, хочется тратить время эффективнее, чем вручную собирать проект или объяснять новичкам, что же там с Code-signing нужно делать.

Пожалуй, самое рутинное и самое важное занятие, которое берёт на себя CI, — это прогон тестов. Нет зелёных тестов? В master не попадёшь. А с ростом команды вероятность того, что кто-то вольёт в master нерабочий код, будет только увеличиваться. Нужна автоматизация.

В этой статье я хочу подробно рассказать о пути настройки Gitlab CI + Fastlane + Firebase + Testflight. Примеры приводятся на основе одного проекта, в котором участвовали 10 разработчиков. В конце будут описаны проблемы, с которыми мы сталкивались, и их решения.

Для кого будет полезен этот опыт? Для всех, кому нужен CI/CD и кто сидит на Gitlab. Для Github будет другая связка, например с Travis, — остальные компоненты неизменны. В нашей команде все используют Gitlab CI, Fastlane вместо голого xcodebuild для быстроты и удобства разработки, Firebase и Testflight.

Если у нас бесплатный Gitlab и мы укладываемся в лимит Firebase, то получаем бесплатное решение по настройке CI/CD.

Прошло полгода с момента публикации первой статьи о работе над сайтом банка. За это время Промсвязьбанк превратился в ПСБ, моя команда пополнилась еще тремя сильными спецами, мы запустили 300+ новых страниц на сайте, увеличив фокусные показатели и получив обратную связь от сотен пользователей.

Обо всем по порядку.

Если ты создаешь «Мобильный банк», будь готов к тому, что когда-нибудь придется заняться нетривиальной задачкой – сделать сервис мобильной бухгалтерии. Что в нем сложного? То, что это должно быть приложение, в котором нет ничего, напоминающего обычный бухгалтерский интерфейс.

Привет! Меня зовут Илья Голованов. Мы вместе с командой работаем над новым сайтом Промсвязьбанка. В этой статье я расскажу, какие задачи перед нами стоят, с какими проблемами мы сталкиваемся и к каким решениям приходим.

Пока новый вид доступен для 30% страниц (их можно увидеть, кликнув по ссылке). Попутно мы дорабатываем разделы, добавляя их в эту бета-версию.