Мы не внедряли Sсrum ради Scrum’а — мы хотели дать клиентам онлайн-доступ к продуктам и сервисам банка и использовать обычный проектный подход, а не кросс-функциональные команды. Но у этой задачи была особенность, которая вынудила нас прийти к гибкой методологии.

Я, Константин Ахметов, начальник отдела разработки розничных кредитных технологий ПСБ, и я расскажу, почему мы решили использовать фреймворк Scrum для диджитализации продуктов банка.

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

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

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

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

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

Многие из вас прекрасно знают, что такое Google Ассистент. Это голосовой помощник, подобный Siri, Алисе, Алексе и другим. Когда пользователь что-то говорит, Google Ассистент понимает это с помощью natural language understanding (NLU). NLU преобразует человеческую речь в специальную структуру данных, которую уже можно обработать.

У разработчиков Android есть возможность интегрировать NLU в свои приложения через специальный api, который называется App Actions. Точнее, существует два вида интеграции: мы можем получить и использовать Deep Link из речи пользователя или получить данные из приложения, не открывая его, и показать их прямо в Google Ассистенте через Slice.

Примечание

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

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

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

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

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

В предыдущей статье мы начали разбирать, как избавиться от шаблонного многострочного кода в 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% страниц (их можно увидеть, кликнув по ссылке). Попутно мы дорабатываем разделы, добавляя их в эту бета-версию.