Небольшая предыстория

Собеседования в Яндексе

1. Вводится n и нужно посчитать сумму всех чисел от 1 до n < 1000000, где цифры не встречаются более одного раза.
2. Есть доска M x N (2<M,N<1000000) есть белая и черная лошадь. На входе начальная точка черной и белой лошади. Нужно совершить минимальное кол-во ходов, чтобы они оказались в одной точке и вывести это кол-во.
3. Вводиться 2 числа N-кол-во чисел в массиве и M-сумма подмассива. Нужно найти подмассив с минимальным кол-во чисел, сумма которой равнялась M, в противно случае нужно вывести что-то другое (не помню).

1. Есть пять человек: Т, М, А, Л, Д. Они стоят в очереди за магической колой, т.е. тот, кто выпивает его удваивается. На входе n номер следующего, кто должен выпить колу. Нужно найти того, кто будет n-ным.
   
   
   Идея решения

   Лучшее решение это hashmap, сам решил через арифметику, т.е. вывел формулу, которая посчитала бы это. //Рассказал всю идею того, как решал бы, потом дал оценку по времени и по памяти, а когда начал писать код, то интервьюер сказал, что он все понял и что код я ему точно напишу так, что давай перейдём к следущей задаче, т.к. у нас осталось чуть больше 20 минут
2. Есть бинарное дерево поиска. Нужно найти сумму элементов лежащих в сегменте от L до R. Функция на вход получает корневой элемент, левую и правую границу. Тогда уточнил и узнал, что элементы не повторяются и границы включены.
   
   
   Идея решения

   Делал через рекурсию. (можно через цикл, но рекурсия проще), опять же сложность алгоритма и т.д.

Собеседование в МегаФоне

Собеседование в Сбербанк

Собеседование в ВТБ

Заключение

Советы, которые могут помочь при поиске первой работы в IT

1. Нужно хорошо разбираться в теории, ибо научиться кодить не сложно.
2. Откликайтесь на вакансии middle/senior, т.к. найти вакансию intern/junior почти невозможно найти.
3. Если есть возможность попасть на собеседование, то идите, потому что это поможет вам поднять ваши скилы. (Даже если мало что знаете)
4. Изучите компанию, в которой будете проходить собеседование и покажите интервьюеру свою заинтересованность работать у них.
5. Обязательно спрашивайте о том, что вас лично интересует и что хотели бы узнать о рабочем процессе.
6. Когда чего-то не знаете или не помните, то задавайте уточняющие вопросы, они вам помогут. Если не смогли вспомнить, то просто скажите об это.
7. Думайте открыто, ведь интервьюер больше смотрит на то, как вы думаете и как ищете выход при сложившихся ситуациях. Если вы просто скажете ответ, то это ни о чем не говорит. Когда вы открыто рассуждаете, то интервьюер видит где вы ошиблись и помогает вам, задавая наводящие вопросы.
8. Прежде чем пойти на собеседование отрепетируйте его. Задавайте себе всякие вопросы связанные с тем, что должно быть и постарайтесь внятно ответить на них.

Совет компаниям

Начнем с небольших определений

Добавление элемента

let keychainItemQuery = [     kSecValueData: pass.data(using: .utf8)!,     kSecClass: kSecClassGenericPassword ] as CFDictionary let status = SecItemAdd(keychainItemQuery, nil) print("Operation finished with status: \(status)")

func SecItemAdd(_ attributes: CFDictionary,               _ result: UnsafeMutablePointer<CFTypeRef?>?) -> OSStatus

Получение элемента

let keychainItem = [     kSecValueData: pass.data(using: .utf8)!,     kSecClass: kSecClassGenericPassword,     kSecReturnAttributes: true,     kSecReturnData: true ] as CFDictionary         var ref: AnyObject? let status = SecItemCopyMatching(keychainItem, &ref) if let result = ref as? NSDictionary, let passwordData = result[kSecValueData] as? Data {     print("Operation finished with status: \(status)")     print(result)     let str = String(decoding: passwordData, as: UTF8.self)     print(str) }

Обновление элемента

let query = [     kSecClass: kSecClassGenericPassword,] as CFDictionarylet updateFields = [     kSecValueData: pass.data(using: .utf8)!] as CFDictionarylet status = SecItemUpdate(query, updateFields)

Удаление элемента

let query = [     kSecClass: kSecClassGenericPassword,     kSecValueData: pass.data(using: .utf8)!] as CFDictionarylet res = SecItemDelete(query)

Подведение итогов

Навигация во Flutter

Flutter набирает популярность среди разработчиков. Большенство подходов впостроении приложений уже устоялись иприменяются ежедневно вразработке E-commerce приложений. Тема навигации опускают навторой или третий план. Какой API навигации предоставляет Фреймворк? Какие подходы выработаны? Как использовать эти подходы иначто они годятся?

Введение

Начнём с того, что такое навигация? Навигация это метод который позволяет перемещаться между пользовательским интерфейсом с заданными параметрами.
К примеру в IOS мире организовывает навигацию UIViewController, а в Android Navigation component. А чтопредоставляет Flutter?

Navigator

Экраны в Flutter называются route. Для перемещениями между route существует класс Navigator который имеющий обширный API для реализации различных видов навигации.

Навигации на новый route и возвращение с него

Начнём спростого.Навигация нановый экран(route) вызывается методом push() который принимает всебя один аргумент это Route.

Navigator.push(MaterialPageRoute(builder: (BuildContext context) => MyPage()));

Давайте детальнее разберёмся ввызове метода push:

Navigator Виджет, который управляет навигацией.
Navigator.push() метод который добавляет новый route виерархию виджетов.
MaterialPageRoute() Модальный route, который заменяет весь экран адаптивным кплатформе переходом анимации.
builder обязательный аргумент конструктора MaterialPageRoute, который возвращает пользовательский интерфейс Фреймворк для отрисовки.
[MyPage](https://miro.medium.com/max/664/1Xm96KtLeIAAMtAYWcr1-MA.png)* пользовательский интерфейс реализованный при помощи Stateful/Stateless Widget

Возвращение на предыдущий route

Для возвращения с экрана на предыдущий необходимо использовать метод pop().

Navigator.pop();

Переда данных между экранами

Данные на новый экран передаются через конструктор при создании экрана в builder методе. Этот принцип работает в методах Navigator, где нужно реализовать метод build.

Navigator.push(context, MaterialPageRoute(builder: (context) => MyPage(someData: data)));

В примере продемонстрирована передача данных в класс MyPage (в этом классе хранится пользовательский интерфейс).

Для того чтобы передать данные на предыдущий экран нужно вызвать метод pop() и передать опциональным аргументом туда данные.

Navigator.pop(data);

Navigator State

Состояние виджета Navigator, который вызван внутри одного из видов MaterialApp/CupertinoApp/WidgetsApp. State отвечает за хранение истории навигации и предоставляет API для управления историей.
Базовые методы навигации повторяют структуру данных Stack. В диаграмме можно наблюдать методы и "call flow" NavigatorState.

Императивный vs Декларативный подход в навигации

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

Давайте на простом примере:

Императивный подход , отвечает на вопрос как?
Пример: Я вижу, что тот угловой столик свободен. Мы пойдём туда и сядем там.

Декларативный подход, отвечает на вопрос что?
Пример: Столик для двоих, пожалуйста.

Для более глубокого понимания разницы советую прочитать эту статью Imperative vs Declarative Programming

Императивная навигация

Вернёмся к реализации навигации. В императивном подходе описывается детали работы в вызывающем коде. В нашем случае это поля Route. В Flutter много типов route, например MaterialPageRoute и CupertinoPageRoute. Например в CupertinoPageRoute задаётся title, или settings.

Пример:

Navigator.push(    context,    CupertinoPageRoute<T>(        title: "Setting",        builder: (BuildContext context) => MyPage(),        settings: RouteSettings(name:"my_page"),    ),);

Этот код и знания о новом route будут хранитьсяв ViewModel/Controller/BLoC/ У этот подхода существует недостаток.

Представим что потребовалось внести изменения в конструкторе в MyPage или в CupertinoPageRoute. Нужно искать каждый вызов метода push в проекте и изменять кодовую базу.

Вывод:

Этот подход не имеет единообразный подход к навигации, и знание о реализации route проникает в бизнес логику.

Декларативная навигация

Принцип декларативной навигации заключается в использовании декларативного подхода в программировании. Давайте разберём на примере.

Пример:

Navigator.pushNamed(context, '/my_page');

Принцип императивной навигации выглядит куда проще. Говорите "Отправь пользователя на экран настроек" передавая путь одним из аргументов навигации.
Для хранении реализации роста в самом Фреймворке предусмотрен механизм у MaterialApp/CupertinoApp/WidgetsApp. Это 2 колбэка onGenerateRoute и onUnknownRoute отвеспющие за хранение деталей реализации.

Пример:

MaterialApp(    onUnknownRoute: (settings) => CupertinoPageRoute(      builder: (context) {                return UndefinedView(name: settings.name);            }    ),  onGenerateRoute: (settings) {    if (settings.name == '\my_page') {      return CupertinoPageRoute(                title: "MyPage",                settings: settings,        builder: (context) => MyPage(),      );    }        // Тут будут описание других роутов  },);

Разберёмся подробнее в реализации:
Метод onGenerateRoute данный метод срабатывает когда был вызван Navigator.pushNamed(). Метод должен вернуть route.
Метод onUnknownRoute срабатывает когда метод onGenerateRoute вернул null. должен вернуть дефолтный route, по аналогии с web сайтами 404 page.

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

Диалоговые и модальные окна

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

Методы для вызова диалоговых и модальных окон:

• showAboutDialog
• showBottomSheet
• showDatePicker
• showGeneralDialog
• showMenu
• showModalBottomSheet
• showSearch
• showTimePicker
• showCupertinoDialog
• showDialog
• showLicensePage
• showCupertinoModalPopup

Эти методы покрывают базовые потребности разработчиков которые хотят работать с окнами. Если не хватает этого API, тогда стоит разобраться как эти методы работают.

Как работает это под капотом?

Давайте рассмотрим исходный код одного из методов, например showGeneralDialog.

Исходный код:

Future<T> showGeneralDialog<T>({  @required BuildContext context,  @required RoutePageBuilder pageBuilder,  bool barrierDismissible,  String barrierLabel,  Color barrierColor,  Duration transitionDuration,  RouteTransitionsBuilder transitionBuilder,  bool useRootNavigator = true,  RouteSettings routeSettings,}) {  assert(pageBuilder != null);  assert(useRootNavigator != null);  assert(!barrierDismissible || barrierLabel != null);  return Navigator.of(context, rootNavigator: useRootNavigator).push<T>(_DialogRoute<T>(    pageBuilder: pageBuilder,    barrierDismissible: barrierDismissible,    barrierLabel: barrierLabel,    barrierColor: barrierColor,    transitionDuration: transitionDuration,    transitionBuilder: transitionBuilder,    settings: routeSettings,  ));}

Давайте детальнее разберёмся в устройстве этого метода. showGeneralDialog вызывает метод push у NavigatorState с _DialogRoute(). Нижнее подчёркивание обозначает что этот класс приватный и используется только в пределах области видимости в которой сам описан, то есть в пределах этого файла.

Диалоговые и модальные окна которые отображаются при помощи глобальных методов это кастомные route которые реализованы разработчиками Фреймворка.

Типы route в фреймворке

Теперь понятно что"every thins is a route", то есть что связанное с навигацией. Давайте взглянем на то, какие route уже реализованы в Фреймворке.

Два основных route в Flutter это PageRoute и PopupRoute.

PageRoute Модальный route, который заменяет весь экран.
PopupRoute Модальный route, который накладывает виджет поверх текущего route.

Реализации PageRoute:

• MaterialPageRoute
• CupertinoPageRoute
• _SearchPageRoute
• PageRouteBuilder

Реализации PopupRoute:

• _ContexMenuRoute
• _DialogRoute
• _ModalBottomSheetRoute
• _CupertinoModalPopupRoute
• _PopupMenuRoute

Реализация PopupRoute приватна и скрыты для внешних потребителей, но роуты используют глобальные методы для показа диалоговых и модальных окон.

Вывод:

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

Best practices

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

Начнём с того что мы сделаем некий сервис который будет будет соблюдать следующим аспектам:

• Декларативный вызов навигации.
• Отказ от использования BuildContext для навигации (Это критично если сервис навигации будет вызываться в компонентах, в которых нет возможности получить BuildContext).
• Модульность. Можно вызвать любой route, CupertinoPageRoute, BottomSheetRoute, DialogRoute и т.д.

Для нашего сервиса навигации нам понадобится интерфейс:

abstract class IRouter {  Future<T> routeTo<T extends Object>(RouteBundle bundle);  Future<bool> back<T extends Object>({T data, bool rootNavigator});  GlobalKey<NavigatorState> rootNavigatorKey;}

Разберём методы:
routeTo - выполняет навигацию на новый экран.
back возвращает на предыдущий экран.
rootNavigatorKey GlobalKey умеющий вызывать методы NavigatorState.

После того как мы сделали интерфейс навигации, давайте сделаем реализацию этого интерфейса.

class Router implements IRouter {    @override  GlobalKey<NavigatorState> rootNavigatorKey = GlobalKey<NavigatorState>();    @override  Future<T> routeTo<T>(RouteBundle bundle) async {   // Push logic here  }    @override  Future<bool> back<T>({T data, bool rootNavigator = false}) async {        // Back logic here    }}

Супер, теперь нам нужно реализовать метод routeTo().

@override  Future<T> routeTo<T>(RouteBundle bundle) async {        assert(bundle != null, "The bundle [RouteBundle.bundle] is null");    NavigatorState rootState = rootNavigatorKey.currentState;    assert(rootState != null, 'rootState [NavigatorState] is null');    switch (bundle.route) {      case "/routeExample":        return await rootState.push(          _buildRoute<T>(            bundle: bundle,            child: RouteExample(),          ),        );      case "/my_page":        return await rootState.push(          _buildRoute<T>(            bundle: bundle,            child: MyPage(),          ),        );      default:        throw Exception('Route is not found');    }  }

Данный метод вызывает у root NavigatorState (который описан в WidgetsApp) метод push и конфигурирует его относительно RouteBundle который приходит одним из аргументов в данный метод.

Теперь нужно реализовать класс RouteBundle. Это просто модель, которая хранит в себе набор полей для конфигурации.

enum ContainerType {  /// The parent type is [Scaffold].  ///  /// In IOS route with an iOS transition [CupertinoPageRoute].  /// In Android route with an Android transition [MaterialPageRoute].  ///  scaffold,  /// Used for show child in dialog.  ///  /// Route with [DialogRoute].  dialog,  /// Used for show child in [BottomSheet].  ///  /// Route with [ModalBottomSheetRoute].  bottomSheet,  /// Used for show child only.  /// [AppBar] and other features is not implemented.  window,}class RouteBundle {  /// Creates a bundle that can be used for [Router].  RouteBundle({    this.route,    this.containerType,  });  /// The route for current navigation.  ///  /// See [Routes] for details.  final String route;  /// The current status of this animation.  final ContainerType containerType;}

enum ContainerType тип контейнера, котрый будет задаваться декларативно из вызываемого кода.
RouteBundle класс-холдер данных отвечающих конфигурацию нового route.

Как вы могли заметить у я использовал метод _buildRoute. Именно он отвечает за то, кой тип route будет вызван.

Route<T> _buildRoute<T>({@required RouteBundle bundle, @required Widget child}) {    assert(bundle.containerType != null, "The bundle.containerType [RouteBundle.containerType] is null");    switch (bundle.containerType) {      case ContainerType.scaffold:        return CupertinoPageRoute<T>(          title: bundle.title,          builder: (BuildContext context) => child,          settings: RouteSettings(name: bundle.route),        );      case ContainerType.dialog:        return DialogRoute<T>(          title: '123',          settings: RouteSettings(name: bundle.route),          pageBuilder: (BuildContext context, Animation<double> animation, Animation<double> secondaryAnimation) {                        return child;                    },        );      case ContainerType.bottomSheet:        return ModalBottomSheetRoute<T>(          settings: RouteSettings(name: bundle.route),          isScrollControlled: true,          builder: (BuildContext context) => child,        );      case ContainerType.window:        return CupertinoPageRoute<T>(          settings: RouteSettings(name: bundle.route),          builder: (BuildContext context) => child,        );      default:        throw Exception('ContainerType is not found');    }  }

Думаю что в этой функции стоит рассказать о ModalBottomSheetRoute и DialogRoute, которые использую. Исходный код этих route позаимствован из раздела Material исходного кода Flutter.

Осталось сделать метод back.

@overrideFuture<bool> back<T>({T data, bool rootNavigator = false}) async {    NavigatorState rootState = rootNavigatorKey.currentState;  return await (rootState).maybePop<T>(data);}

Ну и конечно перед использованием сервиса необходимо передать rootNavigatorKey в App следующим образом:

MaterialApp(    navigatorKey: widget.router.rootNavigatorKey,    home: Home());

Кодовая база для нашего сервиса готова, давайте вызовем наш route. Для этого создадим инстанс нашего сервиса и каким-либо образом "прокинуть" в объект, который будет вызывать этот инстанс, например при помощи Dependency Injection.

router.routeTo(RouteBundle(route: '/my_page', containerType: ContainerType.window));

Теперь мы имеем единый подход к навигации, позволяющий решить вышеперечисленные проблемы:

• Декларативный вызов навигации
• Отказ от BuildContext по средствам GlobalKey
• Модульность достигнута возможностью конфигурирования route относительно имени пути и контейнера для View

Итог

В Фреймворке Flutter существуют различные методы для навигации, которые дают преимущества и недостатки.

Ну и конечно полезные ссылки:
Мой телеграм канал
Мои друзья Flutter Dev Podcast
Вакансии Flutter разработчиков

Почему именно SPM

Делает ли это сборку проекта быстрее

Как сделать эффективное разбиение

• CommonAssets набор ваших Assets'ов и public интерфейс для доступа к ним. Обычно он генерируется с помощью SwiftGen.
• CommonExtensions набор расширений, к примеру Foundation, UIKit, дополнительные зависимости.

• NewFlow экраны новостей и обзора конкретной новости.
• FavoritesFlow экран со списком избранных новостей и экран обзора конкретной новости с дополнительным функционалом.
• SettingsFlow экраны настроек приложения, аккаунта, категорий и т. д.

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

Когда нужно выносить компонент в отдельный модуль

Создаём проект с использованием SPM

• добавляем папку Frameworks без создания директории;
• создаём SPM-пакет Common.

• Добавляем поддерживаемые платформы в файл Package.swift. У нас это platforms: [.iOS(.v14), .macOS(.v10_15)]

• Теперь добавляем наш модуль в каждый таргет. У нас это SPMExampleProject для iOS и SPMExampleProject для macOS.

Как подключить зависимость у локального SPM-пакета

Пример, приближенный к реальности

1. Создаем новый корневой модуль по инструкции выше.
   
2. Добавляем к нему корневые каталоги Scripts и Templates.
   
3. Добавляем в корень модуля файл Palette.xcassets и пропишем какие-либо color set'ы.
   
4. Добавляем пустой файл Palette.swift в Sources/Palette.
   
5. Добавим в папку Templates шаблон palette.stencil.
   
6. Теперь нужно прописать конфигурационный файл для SwiftGen. Для этого добавим файл swiftgen.yml в папку Scripts и пропишем в нем следующее:
   

xcassets:  inputs:    - ${SRCROOT}/Palette/Sources/Palette/Palette.xcassets  outputs:    - templatePath: ${SRCROOT}/Palette/Templates/palette.stencil      params:        bundle: .module        publicAccess: true      output: ${SRCROOT}/Palette/Sources/Palette/Palette.swift

cd ${SRCROOT}/Palette/usr/bin/xcrun --sdk macosx swift run -c release swiftgen config run --config ./Scripts/swiftgen.yml

Подводные камни

• Всплывают ошибки архитектуры и портят всю логику разбиения на модули.
• SwiftLint & SwiftGen не уживаются вместе при подгрузке их через SPM. Причина в разных версиях yml.
• В крупных проектах не получится сразу избавиться от Cocoapods. А разбивать уже созданный проект с закреплёнными версиями подов настоящее испытание, потому что SPM только развивается и не везде поддерживается. Но SPM и Cocoapods более-менее работают параллельно: разве что поды могут кидать ошибку MergeSwiftModule failed with a nonzero exit code. Это происходит довольно редко, а решается очисткой и пересборкой проекта.
• На данный момент SPM не позволяет прописать пути поиска библиотек. Приходится явно указывать их с завязкой на -L$(BUILD_DIR).

SPM замена Bundler?

swift run swiftlint --autocorrect.

Привет, Хабр! Всреду 29июля мы проводим восьмой посчёту митап дляiOS-разработчиков. Впрограмме два доклада отинженеров Авито онашем CI и интересных аспектах перформанса, рассказ протехники нормализации отразработчика изSigma Software и выступление англоязычного гостя изLyft проIndexStore.

Тезисы и ссылка нарегистрацию подкатом. Приходите смотреть трансляцию сами и приглашайте коллег.

Доклады

iOS CI as a Service in da House Владислав Алексеев, Авито

Однажды вы поймете, что собирать приложение локально вXcode уже не то. Вам захочется истории сборок, хранения релизных бинарей и проверок наPR. Вам потребуется CI и CD. Помере роста команды будет расти нагрузка и наваш CI. Вам потребуется масштабировать сборочную ферму, ускорять компиляцию, заставлять тесты работать быстрее и стабильнее. Сразвитием ваших мобильных приложений вам рано или поздно потребуется познать лучшие практики CI/CD вiOS.

В Авито есть всё, что нужно, дляразработки iOS-приложений: дебажные и релизные сборки, юнит- и UI-тесты, ферма. Мы постоянно добавляем всё больше и больше проверок тысячи юнит-тестов, сотни нативных UI-тестов, множество performance-тестов, различные дополнительные проверки. Но всё это добро занимает почти30минут на pull request-е уже два года подряд. Киллер фича унас нет очередей насборки, они стартуют вместе соткрытием PR! Вдокладе я расскажу, как мы достигли этого. Надеюсь, что вы научитесь нанаших фейлах и воодушевитесь нашими идеями!

Затрагиваемые темы: TeamCity, bash, Python, билды и тесты, CocoaPods, build tracing, Puppet, ферма, Xcode, импакт анализ.

О спикере: Владислав работает винфраструктурных проектах, связанных сосборками и тестированием. Начал свою карьеру вЯндексе, где работал надприложениями Яндекс.Карты и Яндекс.Браузер подiOS. Затем работал вФейсбуке надпроизводительностью основного приложения и системной сборки Buck. С2017 года работает вАвито, занимается инфраструктурой мобильных приложений.

Укрощение нормализованного состояния. Граф объекты и санитайзеры Алексей Демедецкий, Sigma Software

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

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

О спикере: я занимаюсь мобильной разработкой около10лет. Заэто время успел попробовать много разных подходов. Последние 5лет практикую и рассказываю прооднонаправленные подходы (redux, flux, mvi) вмобильной разработке. Всвободное время пишу свой карманный язык Arrow. Задать мне вопросы можно втвиттере.

What the IndexStore Has To Say Dave Lee, Lyft

Code is data, but what kind ofdata? For a given token, a language server can give a JSON object ofrelevant info. For a file, a parser can provide an AST. Both of these scopes are optimized fordifferent use cases. Other use cases can benefit from having data for all the code ina project. Swift and Clang both provide a project wide view ofthe code, we know it as Xcode's index. The IndexStore has a lot ofpotential formaking tools. This talk will explore and demonstrate some uses forthe IndexStore

Dave Lee is a software engineer inthe Bay Area working onsoftware for other software engineers. Dave is a dad to two daughters who show no interest incode, except that one time I used Python to do word scramble homework.

Абстрактные техники перформанса Тимур Юсипов, Авито

Fun talk не проускорения, а проразные аспекты перформанса, о которых вы могли даже не задумываться в повседневной разработке.

О спикере: руководитель команды Performance вАвито. Люблю iOS, футбол, походы, велосипед и ролики.

Пароли и явки

Онлайн-трансляция нанашем ютуб-канале стартует 29июля в18:00 поМоскве. Закончить планируем к20:30. На трансляции можно сразу нажать кнопку напомнить, чтобы ничего не пропустить.

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

До встречи вонлайне!

Всем привет, меня зовут Виталий, я основатель Adapty. Подписки один из способов монетизировать приложение. С их помощью вы можете дать пользователю возможность получить постоянный доступ к обновляемому контенту в приложении или же к предоставляемому сервису. В отличие от обычных покупок, где Apple берет себе 30% комиссию, на подписках эта комиссия сокращена до 15% в случае, если пользователь подписан в течение 1 года и более.Важныймомент: если пользователь отменит подписку, то данный счетчик сбросится через 60 дней.

В этой части мы научимся:

• Создавать покупки в App Store Connect
• Конфигурировать подписки указывать длительность, стоимость, пробные периоды
• Получать список покупок в приложении

Создание покупок

Перед тем, как начать внедрять покупки внутри приложения необходимо:

• Оплатить Apple Developer аккаунт как физическое лицо или организация.
• Приняты все соглашения в App Store Connect. Обновленные соглашения будут появляться сверху в личном кабинете App Store Connect, их легко заметить.

Предположим, что в нашем приложении будет два вида подписок: месячная и годовая. У каждой из них мы сделаем пробный период длиной в 7 дней.

На странице нашего приложения в App Store Connect открываем вкладку In-App Purchases Manage. На этой вкладке отображается список созданных нами покупок. Для того, чтобы создать новую покупку, необходимо нажать на кнопку(+),которая находится около заголовка In-App Purchases.

Интерфейс создания покупок

Далее мы попадаем в диалог создания покупки. Наш выбор Auto-Renewable Subscription.

Выбираем 3 пункт

Следующим шагом нам будет предложено создать группу подписок(SubscriptionGroup). Группа подписок это множество подписок с главным свойством, что пользователь не может активировать две подписки одновременно из одной группы. Дополнительно, все introductory offers такие как триал применяются ко всей группе сразу. Группы нужны для того, чтобы отделять бизнес логику внутри приложения.

Назовем нашу группу Premium Access. При добавление следующей подписки интерфейс предложит добавить ее в уже существующую группу. Позже вы можете управлять группами в меню In-App Purchases Subscription Groups

Создание Группы подписок

Далее конфигурируем название подписки

• Reference Name то, как будет отображаться подписка в App Store Connect, а также в разделе Sales и в отчетах
• Product ID уникальныйидентификатор продукта, который используется в коде приложения

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

Добавим второй продукт точно так же, в итоге наш интерфейс вкладки In-App Purchases Manage будет выглядеть следующим образом:

Две подписки в приложении

Конфигурация подписок

Покупки добавили, но пока они не готовы к использованию: Status выше имеет значение Missing Metadata. Это означает, что мы пока не добавили информацию по цене и периоду подписки. Сейчас мы это исправим.

Длительность и цены

Кликаем на продукт и конфигурируем его.

Здесь нам необходимо выбрать период(SubscriptionDuration). В нашем случае, выбираем 1 Month или 1 Year. После чего переходим в меню конфигурации цен. Можно гибко настраивать цены в зависимости от стран, но мы ограничимся автоматическими ценами, выбрав только цену в USD. App Store Connect автоматически переведет цены в другую валюту, не всегда ясно, как это происходит. Скорее всего для ваших целевых рынков вы захотите поменять цену руками.

Бесплатный пробный период (free trial)

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

Чтобы зайти в нужное нам меню, нажмите на кнопку(+)рядом с заголовком и выберите пунктCreate Introductory Offerиз выпадающего списка:

Выбираем список стран

Выбираем длительность оффера. Можно поставить No End Date, если не хотите себя ограничивать.

Последний этап выбор типа оффера. Как видно на следующем скриншоте, существует три типа:

• Pay as you go использование со скидкой: пользователь платит сниженную цену в течение нескольких начальных периодов, а после становится обычным подписчиком со стандартными ценами.
• Pay up front предоплата за использование приложения: пользователь сразу платит некоторую стоимость и получает возможность использовать приложение в течение определенного времени, а затем, также становится обычным подписчиком.
• Free бесплатный пробный период, по истечение которого пользователь может стать подписчиком.

Нас интересует третий вариант, а продолжительность(Duration)устанавливаем на 1 неделю.

Сохраняем настройки.

Получение списка SKProduct

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

Хорошим правилом является создание класса-синглтона для работы со StoreKit. Такой класс имеет только один инстанс во всем приложении. МножествоproductIdentifiersбудет хранить в себе идентификаторы наших покупок:

import StoreKitclass Purchases: NSObject {    static let `default` = Purchases()    private let productIdentifiers = Set<String>(        arrayLiteral: "barcode_month_subscription", "barcode_year_subscription"    )    private var productRequest: SKProductsRequest?    func initialize() {        requestProducts()    }    private func requestProducts() {        // Will implement later    }}

Только идентификаторов недостаточно, чтобы полноценно пользоваться покупками необходимо получить: стоимость, валюту, локализацию, скидки. Возвращает всю эту и дальше большую информацию класс SKProduct. Чтобы получить эту информацию, нам необходимо сделать запрос к Apple. Создадим объектSKProductsRequest, назначим емуdelegate вметодыdelegateбудет приходить результат запроса. Вызываем методstart(), который инициализирует асинхронную процедуру:

private func requestProducts() {        productRequest?.cancel()        let productRequest = SKProductsRequest(productIdentifiers: productIdentifiers)        productRequest.delegate = self        productRequest.start()        self.productRequest = productRequest}

Если операция пройдет успешно, будет вызван методproductsRequest(didReceive response:), в котором и будет содержаться вся необходимая нам информация:

extension Purchases: SKProductsRequestDelegate {    func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) {        guard !response.products.isEmpty else {            print("Found 0 products")            return        }        for product in response.products {            print("Found product: \(product.productIdentifier)")        }    }    func request(_ request: SKRequest, didFailWithError error: Error) {        print("Failed to load products with error:\n \(error)")    }}

Если все прошло успешно, то в результате в лог будет выведены две строчки:

Found product: barcode_month_subscriptionFound product: barcode_year_subscription

При этом, если будет ошибка, то SKProduct с таким ID не вернется. Такое может быть, если продукт по какой то причине стал не валидный.

Ну вот и все, очередной забор за нашей спиной.

Спасибо Алексею Гончарову x401om за подготовку статьи. В следующей статье мы разберемся, как проводить покупки внутри приложения: открывать/закрывать транзакции, обрабатывать ошибки, валидировать receipt и другое.

Да, да. Я понимаю что на дворе 2020 год, что все хардкорные IOS разработчики пишут исключительно на SwiftUI и Combine, и писать статьи про UIKit как то не айс. И, тем не менее, 2020 год выдался не таким как все предыдущие года. Совсем не таким.

И, поэтому, как только на Дублин где то в середине марта опустился полный локдаун, я стал искать чем же занять себя холодными дождливыми вечерами. Побаловавшись со SwiftUI и Combine и, решив что я совершенно не хочу быть публичным альфа тестером, хотя, я и нахожу это все шагом в правильном направлении, я решил посмотреть поглубже на то, что еще что меня интересовало, но вечно не было времени разобраться. В этот самый момент компания WebSummit, в которой я недавно начал работать, решила сменить чат провайдера и мне пришлось поглубже закопаться в текущую имплементацию чата.

Чат использует MessageKit в качестве UI компонента. MessageKit swift библиотека поддерживаемая комьюнити призванная заменить устаревшую JSQMessagesViewController. Мне довелось работать с JSQMessagesViewController лет эдак 5 назад. Он справлялся со своими задачами, был минимально гибок, написан в лучших традициях UIKit где все наследуется от всего и, конечно, к выходу swift-а уже полностью морально устарел. К счастью, мне не пришлось к нему больше возвращаться и я только порадовался появившейся тогда инициативе написать библиотеку для создания UI для чата которая бы заменила JSQMessagesViewController. И забыл об этом до марта 2020-го.

Как же я возненавидел MessageKit в марте 2020-го. Она мне показалась построчной перепиской JSQMessagesViewController с Objective-C на Swift и приветом из IOS разработки 2009 года. Я не буду вдаваться в подробности и ругать чужую работу в которой я не принимал участие.

Но, среди огромного количества issues, которые остаются открытыми на гит хабе, или тех, которые прямо документированы в коде библиотеки, остро выделялась проблема скроллинга. UIScrollView по умолчанию ведет себя так, что якорь скроллинга закреплен в в верхнем левом углу контента и новый контент добавляется в низ без сдвига остального контента. Это поведение подходит для 99% случаев использования, но не для чата, где ожидается обратное поведение. При добавлении нового контента в низ нам нужно сместить коэффициент сдвига (contentOffset) на величину добавленного контента.

Этот факт натолкнул меня на простую мысль. Все это делается какими-то странными хуками и паразитированием на UICollectionViewFlowLayout. Почему бы просто не написать лайаут который делал бы все это из коробки?

Второй момент, который подтолкнул меня к тому что хорошо бы разобраться с UICollectionViewLayout было то что несмотря на паразитирование на UICollectionViewFlowLayout, MessageKit не поддерживала автоматические размеры ячеек используя Auto-Layout и нужно было все размеры считать в коде самому. Не смотря на то что данная фича доступна в UICollectionViewFlowLayout из коробки.

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

Анимированные вставка, удаление, обновление и изменение порядка

И вот тут то меня ждал первый сюрприз. Официальная документация на UICollectionViewLayout отсутствовала. Точнее она как бы номинально присутствует. Но слабо соответсвует действительности или опускает некоторые очень важные моменты.

Так, например, первым делом, я решил разобраться даже не с размером ячеек, а с анимацией вставки, удаления, обновления и изменения порядка ячеек. Как видим тут 4 типа обновления ячейки. За это дело в UICollectionViewLayout отвечают 2 метода:
initialLayoutAttributesForAppearingItem(at itemIndexPath: IndexPath) -> UICollectionViewLayoutAttributes?
finalLayoutAttributesForDisappearingItem(at itemIndexPath: IndexPath) -> UICollectionViewLayoutAttributes?
А вот и официальная документация initialLayoutAttributesForAppearingItem и finalLayoutAttributesForDisappearingItem
Давайте прочтем документацию к initialLayoutAttributesForAppearingItem вместе:

When your app inserts new items into the collection view, the collection view calls this method for each item you insert. Because new items are not yet visible in the collection view, the attributes you return represent the items starting state. For example, you might return attributes that position the item offscreen or set its initial alpha to 0. The collection view uses the attributes you return as the starting point for any animations. (The end point of the animation is the items new location and attributes.) If you return nil, the layout uses the items final attributes for both the start point and end point of the animation.
The default implementation of this method returns nil. Subclasses are expected to override this method, as needed, and provide any initial attributes.

Кроме сообщения нам как делать вставку и, еще, немного не очень ясной дополнительной информации, ни о каком апдейте ячейки или сдвиге ячейки речи не идет. С finalLayoutAttributesForDisappearingItem тоже самое. Ладно, можно попробовать по разному толковать

If you return nil, the layout uses the items final attributes for both the start point and end point of the animation.

и попробовать реализовать все остальное используя вот это утверждение.

Не тут то было. Оно работает так для самых примитивных случаев. Но, еще и самое забавное что никак не описан момент а что же происходит c itemIndexPath? Вот вставил я ячейку с индексом 0. Та которая была до этого 0 вероятно станет 1? А в какой момент? А если я вставляю ячейку 0 и сдвину ячейку которая была до этого номером 0 за ячейку номер 2?

Я не считаю себя шибко умным, но, мне всегда казалось, что с базовой арифметикой и логикой у меня порядок. Но с какими бы теориями я не подходил к данному вопросу, с базовой логикой, с нахрапу, я ответить на эти вопросы не мог. Самое забавное что еще и поведение на IOS 12 и IOS 13 отличалось. Один подход мог работать в одной и не работать в другой и наоборот. Ну что ж.

Тогда я решил что я буду логировать вызовы функций UICollectionViewFlowLayout и то, что выводит мой ChatLayout, и, когда приведу их к одному и тому же состоянию, наверняка, мой код будет вести себя идентично. Я провел несколько вечером вглядываясь в листинги вызова функций и отдаваемых значений UICollectionViewFlowLayout и моего лайаута, пытаясь уловить логику и подкручивая мой лайаут что бы он выдавал те же значения. О, Наивный. В тот момент я еще не знал/не думал что UICollectionViewFlowLayout использует private API мне не доступное Нетленная классика от Apple и UIKit. Вообще, это все тянет на отдельную статью. Скажу только что в какой то момент, когда я уже был готов сдаться, у меня все типы этой анимации стали получаться. При том что мой лог вызовов/значений отличался от того что выдавал UICollectionViewFlowLayout. Ну работает и работает.

Определение размера ячейки при помощи AutoLayout

Настало время идти дальше и разобраться с автоматическим определением размеров используя AutoLayout. Тут я стал задаваться вопросом. А не изобретаю ли я велосипед. Почему же все так сложно? Померить то еще можно, но как это все впихнуть еще и в анимацию? Может уже есть кто-то кто разобрался со всеми этими проблемами и готовое решение лежит на гит-хабе?

Первая странность была в том что кастомных UICollectionViewLayout не очень то и много. Да они существуют. Но они могут только разложить ячейки в зависимости от задачи которые они решают, а вот анимацию или не поддерживают толком или анимированная вставка будет из коробки. Либо они наследуются от UICollectionViewFlowLayout и как то там подменяют ему атрибуты в prepare методе и пытаются как то с этим взлететь. Причем, вся эта анимация и поддержка AutoLayout ячеек отсутсвует или оставляет желать лучшего. И тут, я натолкнулся на луч света в темном царстве: airbnb/MagazineLayout. Вот прям реально и без сарказма. Это был единственный реально кастомный лайаут который делал почти все что я хотел. И я с удивлением обнаружил что моя реализация initialLayoutAttributesForAppearingItem /finalLayoutAttributesForDisappearingItem ну прям очень похожа на то что написали ребята из AirBnB.

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

Так вот, некое подобие состояния ячейки описано в UICollectionViewLayoutAttributes, и если во время анимации вы сохраните именно тот объект который вы вернули из initialLayoutAttributesForAppearingItem а потом в методе invalidationContext(forPreferredLayoutAttributes:, withOriginalAttributes originalAttributes:) вы возьмете этот объект и поменяете у него значение frame то внутри UICollectionView сработает какое то KVO (Key-Value-Observing) и она выдаст вам анимацию которую вы ожидаете. Забудьте о preferredAttributes, забудьте originalAttributes. Стабильно работает только вот так. РукаЛицо.

О прокрутке

Теперь, когда вроде что то как то заработало настала очередь разбираться с прокруткой. Точнее мне нужно было изменить поведение UIScrollView на обратное стандартному, что бы когда мы добавляем контент в конец, он не уходил вниз, а наоборот все остальное сдвигалось вверх. Некоторые разработчики решают это поворачивая коллекцию вверх ногами а потом переворачивая контент внутри обратно. Но тогда вы теряете стандартные вещи такие как adjustedContextInsets, и отступ клавиатуры надо отсчитывать сверху а не снизу, и вообще вся геометрия встает с ног на голову. Я подумал что решить это наверняка можно прям из UICollectionViewLayout. Казалось бы, простая задача. У UICollectionViewLayout есть метод targetContentOffset(forProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint Переопределяй его и будет тебе счастье, UICollectionView перед обновлением скажет тебе я мол вот собираюсь сделать свой contentOffset вот таким, а если ты хочешь его поправить верни мне свой.

Вот только проблема в том что этот вызов происходит еще до того как ты можешь получить какие то реальные размеры ячеек, и, если какие то расчеты еще происходят во время анимированного апдейта, использовать его не получится. Да, можно частично в процессе анимированного апдейта возложить расчеты на имеющийся у UICollectionViewLayoutInvalidationContext contentOffsetAdjustment, но, вы не всегда можете им воспользоваться до завершения транзакции анимации. Поэтому пришлось рассчитывать 2 разных величины, proposedContentOffset то, что можно понять до начала анимации, и вторую которой я воспользуюсь в конце транзакции в методе finalizeCollectionViewUpdates. Вроде добился того что надо. Все это работало хорошо пока вы не удаляете ячейки таким образом, что у вас сверху не появляются ячейки, которые еще не были рассчитаны с помощью AutoLayout, и которые вовремя анимации могут изменить свой размер. А вот UICollectionView при уменьшении размера контента (contentSize) начинает игнорировать contentOffsetAdjustment и никаким образом я не смог заставить ее работать так как хотелось мне: ни используя contentSizeAdjustment в различных комбинациях, ни даже меняя contentOffset напрямую. Решением оказалось игнорировать необработанные ячейки при анимации и рассчитывать все остальное потом.

Но главное что желаемого удалось достичь.

Немного о багах и private API

У меня, при прокрутке, изображение слегка подергивалось и я никак не мог понять почему. Но решил не сосредотачиваться пока более менее не прояснится картинка. А потом начал гуглить и нашел вот такой rdar://40926834: Self Sizing + Prefetching Bugs От тех же замечательных ребят из AirBnB. Выключив префетчинг который включен по умолчанию, я моментально избавился от подобного поведения.

А вот еще один от них же rdar://46865293: Cell's autoresizing mask breaks self-sizing. Ну вот не вызывается func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? столько раз сколько обещано, хоть ты тресни.

Мой любимый, так же подсмотренный в MagazineLayout это использование UICollectionViewFlowLayout приватного метода _prepareForCollectionViewUpdates:withDataSourceTranslator: для того что бы все красиво рассчитать до вызова открытого метода prepareForCollectionViewUpdates. Ай да Apple, Ай да UIKit. Это удалось обойти введение специального флага: если транзакция начинается скажи UICollectionView что в ней ничего нет и начинай рассчитывать исходя из того что получишь в prepareForCollectionViewUpdates. Это позволило избавиться от некоторых артефактов.

Вишенкой на торте идут различия между различными версиями IOS, и то, что UICollectionView сама путается в собственной математике и может попросить у тебя атрибуты для несуществующих ячеек и т.д. и т.п. Перечислять все с чем пришлось столкнуться потянет на отдельную статью.

Может, конечно, это и не баги вовсе. Возможно, я что то не понял. И, вообще, зря я на ребят из UIKit наезжаю. Я оставлю этот вопрос открытым.

Немного о хрупкости

Вообще, все эти UICollectionView + UICollectionViewLayout вещи довольно хрупкие. Меняете размер коллекции и, в этот момент, что то вставляете получите артефакты. Меняете анимированно contentInset, например, для клавиатуры, и что то меняете в коллекции получите артефакты. Скроллите коллекцию и меняете ее получите артефакты. Просто что то делаете не так получите артефакты. Почему я не исправлял некоторые вещи? Если я подставлял вместо своего лайаута UICollectionViewFlowLayout и получал точно такое же поведение я записывал это в недостатки самого устройства связки UICollectionView + UICollectionViewLayout и это означало, что они должны быть исправлены "из вне". Поэтому, вы увидите в приложении-примере, которое идет вместе с библиотекой, набор флагов из серии: выдвигаешь клавиатуру не обновляй/Выдвинул обнови и т.д.

Пора в продакшен?

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

Из нового кода оказался только UIViewController средних размеров. Средних это если вы понимаете о чем я. И я смог убедиться что все это может и должно работать в продакшене. Показал коллегам и после полного тестирования было/стало мы смержили это в master.

Больше мы не используем MessageKit. И пока что всем довольны. Производительность и удобство внесения изменений оказались достойными периодических похвал коллег. А большинство открытых багов чата в Jira закрылись сами собой.

Что в остатке?

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

Я оставил пока код слегка не оптимизированым для того что бы было удобнее вносить изменения. Без всякой там прямой записи в память при изменении и т.д. Производительность в релизной сборке на актуальных устройствах достойная и без этого. Кроме того: надо вычистить приложение-пример. Да и тестов добавить. Я сам помимо основной работы поддерживаю библиотеку RouteComposer. и, боюсь, что 2 open-source проекта я просто не потяну. Я, вот, едва нашел время и вдохновение написать эту статью.

Перечислю то что я на данный момент считаю достоинствами данного подхода.

О библиотеке

ChatLayout альтернативный подход к созданию UI для чата. Фактически библиотека состоит кастомного UICollectionViewLayout, который предоставляет некоторые дополнительные методы, которые могут потребоваться для решения этой задачи. Плюсом, в Extras лежат небольшие UIView, которые, при желании, можно использовать для каких-то тривиальных задач.

Достоинства

• Полностью поддерживает динамический лайаут для ячеек (UICollectionViewCell) и вспомогательных UIView (UICollectionReusableView).
• Поддерживает анимированную вставку/удаление/обновление/перемещение ячеек.
• Удерживает contentOffset у основания видимой области UICollectionView во время апдейтов.
• Предоставляет методы для точной прокрутки к нужной ячейке.
• Поставляется с простыми UIView-контейнерами, которые могут облегчить создание кастомных ячеек сообщений.

Недостатки (но, по-моему, все равно достоинства)

ChatLayout это кастомный UICollectionViewLayout, поэтому:

• Вам не нужно наследоваться от какого либо UIViewController или UICollectionView. Вам нужно написать их самим. Так как вам удобно
• Вам не нужно использовать какие то особые UICollectionViewCell которые идут с библиотекой. Создавайте их так как вам удобно.
• Вам не нужно в обязательном порядке рассчитывать размеры ячеек. ChatLayout сделает это за вас. При том, только для видимых в данный момент ячеек, не важно, сколько их в всего в коллекции. Но, если вы укажите хотя бы приблизительный размер производительность только выиграет.
• Вам не предоставляется никакая базовая модель данных. Создавайте ее как вам удобно. И напишите свой UICollectionViewDataSource который будет отображать ее на экране. Приложение-пример использует для расчета изменений модели DifferenceKit, но вы можете использовать что угодно.
• ChatLayout не работает с клавиатурой. Вы можете написать свое решение или можете использовать любую подходящую для этого библиотеку. Все что требуется от вас в конечно итоге для поддержки клавиатуры это изменить contentInsets вашего UICollectionView.
• ChatLayout не предоставляет вам никакого поля для ввода текста. Приложение-пример использует стороннюю библиотеку InputBarAccessoryView (ту же что использует MessageKit). Вы можете использовать ее или любое другое решение.

Собственно все. Спасибо за внимание. Буду рад Вашим комментариям.

Ах, да. Гифки. (Осторожно эпилептикам)

Да, да. Я понимаю что на дворе 2020 год, что все хардкорные IOS разработчики пишут исключительно на SwiftUI и Combine, и писать статьи про UIKit как то не айс. Тем не менее, 2020 год выдался не таким как все предыдущие года. Совсем не таким.

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

Наш чат использует MessageKit в качестве UI компонента. MessageKit swift библиотека, поддерживаемая комьюнити, призванная заменить устаревшую JSQMessagesViewController. Мне довелось работать с JSQMessagesViewController лет эдак 5 назад. Он справлялся со своими задачами, был минимально гибок, написан в лучших традициях UIKit где все наследуется от всего, и он, конечно, к выходу swift-а уже полностью морально устарел. К счастью, мне не пришлось к нему больше возвращаться и я только порадовался появившейся тогда инициативе написать библиотеку для создания UI для чата которая бы заменила JSQMessagesViewController. И забыл об этом до марта 2020-го.

Как же я возненавидел MessageKit в марте 2020-го. Она мне показалась построчной перепиской JSQMessagesViewController с Objective-C на Swift и приветом из IOS разработки 2009 года. Я не буду вдаваться в подробности и ругать чужую работу, в которой я не принимал участие.

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

UIScrollView по умолчанию ведет себя так, что якорь скроллинга закреплен в в верхнем левом углу, и новый контент добавляется в низ без сдвига остального контента. Это поведение подходит для 99% случаев использования, но не для чата, где ожидается обратное поведение. При добавлении нового контента в низ нам нужно сместить коэффициент сдвига (contentOffset) на величину добавленного контента.

Этот факт натолкнул меня на простую мысль. Все это делается какими-то странными хуками и паразитированием на UICollectionViewFlowLayout. Почему бы просто не написать лайаут который делал бы все это из коробки?

Второй момент, который подтолкнул меня к тому что хорошо бы разобраться с UICollectionViewLayout было то что несмотря на паразитирование на UICollectionViewFlowLayout, MessageKit не поддерживала автоматические размеры ячеек используя Auto-Layout и нужно было все размеры считать в коде самому. Не смотря на то, что данная фича доступна в UICollectionViewFlowLayout из коробки.

Ну значит решено. Я напишу свой кастомный UICollectionViewLayout где постараюсь добавить из коробки все что нужно для чата. Сказано сделано. Я создал проект и создал класс который унаследовал от UICollectionViewLayout.

Все казалось довольно простым и я полез в документацию.

Анимированные вставка, удаление, обновление и изменение порядка

И вот тут то меня ждал первый сюрприз. Официальная документация на UICollectionViewLayout отсутствовала. Точнее она как бы номинально присутствует. Но слабо соответсвует действительности или опускает некоторые очень важные моменты.

Так, например, первым делом, я решил разобраться даже не с размером ячеек, а с анимацией вставки, удаления, обновления и изменения порядка ячеек. Как видим тут 4 типа обновления ячейки.

За это дело в UICollectionViewLayout отвечают 2 метода:
initialLayoutAttributesForAppearingItem(at itemIndexPath: IndexPath) -> UICollectionViewLayoutAttributes?
finalLayoutAttributesForDisappearingItem(at itemIndexPath: IndexPath) -> UICollectionViewLayoutAttributes?

А вот и официальная документация initialLayoutAttributesForAppearingItem и finalLayoutAttributesForDisappearingItem

Давайте прочтем документацию к initialLayoutAttributesForAppearingItem вместе:

When your app inserts new items into the collection view, the collection view calls this method for each item you insert. Because new items are not yet visible in the collection view, the attributes you return represent the items starting state. For example, you might return attributes that position the item offscreen or set its initial alpha to 0. The collection view uses the attributes you return as the starting point for any animations. (The end point of the animation is the items new location and attributes.) If you return nil, the layout uses the items final attributes for both the start point and end point of the animation.
The default implementation of this method returns nil. Subclasses are expected to override this method, as needed, and provide any initial attributes.

Кроме сообщения нам как делать вставку и, еще, немного не очень ясной дополнительной информации, ни о каком апдейте ячейки или сдвиге ячейки речи не идет. С finalLayoutAttributesForDisappearingItem тоже самое. Ладно, можно попробовать по разному толковать

If you return nil, the layout uses the items final attributes for both the start point and end point of the animation.

и попробовать реализовать все остальное используя вот это утверждение.

Не тут то было. Оно работает так как описано только для самых примитивных случаев. Еще и самое забавное, что никак не описан момент а что же происходит c itemIndexPath? Вот вставил я ячейку с индексом 0. Та которая была до этого 0 вероятно станет 1? А в какой момент? А если я вставляю ячейку 0 и сдвину ячейку которая была до этого номером 0 за ячейку номер 2?

Я не считаю себя шибко умным, но, мне всегда казалось, что с базовой арифметикой и логикой у меня порядок. Но с какими бы теориями я не подходил к данному вопросу: с базовой логикой, с нахрапом, ответить на эти вопросы я не мог. Самое забавное, что еще и поведение на IOS 12 и IOS 13 отличалось. Один подход мог работать в одной и не работать в другой и наоборот. Ну что ж.

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

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

О, Наивный. В тот момент я еще не знал/не думал что UICollectionViewFlowLayout использует private API мне не доступное Нетленная классика от Apple и UIKit. Вообще, это все тянет на отдельную статью. Скажу только, что в какой то момент, когда я уже был готов сдаться, у меня все типы этой анимации стали получаться. При том, что мой лог вызовов/значений отличался от того что выдавал UICollectionViewFlowLayout. Ну работает и работает.

Определение размера ячейки при помощи AutoLayout

Настало время идти дальше и разобраться с автоматическим определением размеров используя AutoLayout. Тут я стал задаваться вопросом. А не изобретаю ли я велосипед? Почему же все так сложно? Измерить ячейку то еще можно, но как это все впихнуть еще и в анимацию? Может уже есть кто-то кто разобрался со всеми этими проблемами и готовое решение лежит на гит-хабе?

Первая странность была в том что кастомных UICollectionViewLayout не очень то и много. Да они существуют. Но они могут только разложить ячейки в зависимости от задачи которые они решают, а вот анимацию или не поддерживают толком или анимированная вставка будет из коробки. Либо они наследуются от UICollectionViewFlowLayout и, как то там подменяя ему атрибуты в prepare методе, пытаются как то с этим взлететь. Причем, вся эта анимация и поддержка AutoLayout ячеек отсутсвует или оставляет желать лучшего.

И тут, я натолкнулся на луч света в темном царстве: airbnb/MagazineLayout. Вот прям реально и без сарказма. Это был единственный реально кастомный лайаут который делал почти все что я хотел. И я с удивлением обнаружил, что моя реализация initialLayoutAttributesForAppearingItem /finalLayoutAttributesForDisappearingItem ну прям очень похожа на то, что написали ребята из AirBnB.

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

Для справки: некое подобие состояния ячейки описывается в UICollectionViewLayoutAttributes, и, если во время анимации вы сохраните именно тот объект который вы вернули из initialLayoutAttributesForAppearingItem, а потом в методе invalidationContext(forPreferredLayoutAttributes:, withOriginalAttributes originalAttributes:) вы возьмете этот объект и поменяете у него значение frame то внутри UICollectionView сработает какое то KVO (Key-Value-Observing) и она выдаст вам анимацию которую вы ожидаете. Забудьте о preferredAttributes, забудьте originalAttributes. Стабильно работает только вот так. РукаЛицо.

О прокрутке

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

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

Я подумал, что решить это наверняка можно прямо из UICollectionViewLayout. Казалось бы, простая задача. У UICollectionViewLayout есть метод targetContentOffset(forProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint Переопределяй его и будет тебе счастье, UICollectionView перед обновлением скажет тебе: я, мол, вот, собираюсь сделать свой contentOffset вот таким то, а если ты хочешь его поправить верни мне свой.

Вот только проблема в том, что этот вызов происходит еще до того как ты можешь получить какие то реальные размеры ячеек, и, если какие то расчеты еще происходят во время анимированного апдейта, использовать его не получится. Да, можно частично в процессе анимированного апдейта возложить расчеты на имеющийся у UICollectionViewLayoutInvalidationContext contentOffsetAdjustment, но вы не всегда можете им воспользоваться до завершения транзакции анимации. Поэтому пришлось рассчитывать 2 разных величины, proposedContentOffset то, что можно понять до начала анимации, и вторую которой я воспользуюсь в конце транзакции в методе finalizeCollectionViewUpdates. Вроде добился того что надо.

Все это работает хорошо пока вы не удаляете ячейки таким образом, что у вас сверху не начинают появляться ячейки, которые еще не были рассчитаны с помощью AutoLayout и которые вовремя анимации могут изменить свой размер. А вот UICollectionView при уменьшении размера контента (contentSize) начинает игнорировать contentOffsetAdjustment и, никаким образом, я не смог заставить ее работать так как хотелось мне: ни используя contentSizeAdjustment в различных комбинациях, ни даже меняя contentOffset напрямую. Решением оказалось игнорировать необработанные ячейки при анимации и рассчитывать все остальное потом.

Но главное что желаемого результата удалось достичь.

Немного о багах и private API

У меня, при прокрутке, изображение слегка подергивалось и я никак не мог понять почему. Но решил не сосредотачиваться на этом пока более менее не прояснится картинка. А, потом, начал гуглить и нашел вот такой rdar://40926834: Self Sizing + Prefetching Bugs От тех же замечательных ребят из AirBnB. Выключив префетчинг который включен по умолчанию, я моментально избавился от подобного поведения.

А вот еще один от них же rdar://46865293: Cell's autoresizing mask breaks self-sizing. Ну вот не вызывается layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? столько раз сколько обещано, хоть ты тресни.

Мой любимый трюк, так же подсмотренный в MagazineLayout это наглое использование UICollectionViewFlowLayout приватного метода _prepareForCollectionViewUpdates:withDataSourceTranslator: для того что бы все красиво рассчитать до вызова открытого метода prepareForCollectionViewUpdates. Ай да Apple, ай да UIKit. Это удалось обойти введением специального флага: если транзакция начинается скажи UICollectionView что в ней ничего нет и начинай рассчитывать исходя из того что получишь в prepareForCollectionViewUpdates. Это позволило избавиться от некоторых артефактов.

Вишенкой на торте идут различия между версиями IOS и то, что UICollectionView сама путается в собственной математике и может попросить у тебя атрибуты для несуществующих ячеек и т.д. и т.п. Перечислять все с чем пришлось столкнуться потянет на отдельную статью.

Может, конечно, это и не баги вовсе. Возможно, я что то не понял. И, вообще, зря я на ребят из UIKit наезжаю. Я оставлю этот вопрос открытым.

Немного о хрупкости

Вообще, все эти UICollectionView + UICollectionViewLayout вещи довольно хрупкие. Меняете размер коллекции и, в этот момент, что то вставляете получите артефакты. Меняете анимированно contentInset, например, для клавиатуры, и что то меняете в коллекции получите артефакты. Скроллите коллекцию и меняете ее получите артефакты. Просто что то делаете не так получите артефакты. Почему я не исправлял некоторые вещи? Если я подставлял вместо своего лайаута стандартный UICollectionViewFlowLayout и получал точно такое же поведение я записывал это в недостатки самого устройства связки UICollectionView + UICollectionViewLayout и, это означало, что они должны быть исправлены "из вне". Поэтому, вы увидите в приложении-примере, которое идет вместе с библиотекой, набор флагов из серии: выдвигаешь клавиатуру не обновляй/Выдвинул обнови и т.д.

Пора в продакшен?

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

Из нового кода оказался только UIViewController средних размеров. Средних это если вы понимаете о чем я. И, я смог убедиться, что все это может и должно работать в продакшене. Показал коллегам и, после полного тестирования, было/стало мы смержили это в master.

Больше мы не используем MessageKit. И пока что всем довольны. Производительность и удобство внесения изменений оказались достойными периодических похвал коллег. А большинство открытых багов чата в Jira закрылись сами собой.

Что в остатке?

А в остатке оказалась открытая библиотека ChatLayout.

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

Я оставил пока код слегка не оптимизированым, для того что бы было удобнее вносить изменения. Без всякой там прямой записи в память при изменении и т.д. Производительность в релизной сборке на актуальных устройствах достойная и без этого. Кроме того: надо вычистить приложение-пример. Да и тестов добавить. Я сам помимо основной работы поддерживаю библиотеку RouteComposer. и, боюсь, что 2 open-source проекта я просто не потяну. Я, вот, едва нашел время и вдохновение написать эту статью.

Перечислю то, что я на данный момент считаю достоинствами данного подхода.

О библиотеке

ChatLayout альтернативный подход к созданию UI для чата. Фактически, библиотека состоит кастомного UICollectionViewLayout, который предоставляет некоторые дополнительные методы, которые могут потребоваться для решения этой задачи. Плюсом, в Extras лежат небольшие UIView, которые, при желании, можно использовать для каких-то тривиальных задач.

Достоинства

• Полностью поддерживает динамический лайаут для ячеек (UICollectionViewCell) и вспомогательных UIView (UICollectionReusableView).
• Поддерживает анимированную вставку/удаление/обновление/перемещение ячеек.
• Удерживает contentOffset у основания видимой области UICollectionView во время апдейтов.
• Предоставляет методы для точной прокрутки к нужной ячейке.
• Поставляется с простыми UIView-контейнерами, которые могут облегчить создание кастомных ячеек сообщений.

Недостатки (но, по-моему, все равно достоинства)

ChatLayout это кастомный UICollectionViewLayout, поэтому:

• Вам не нужно наследоваться от какого либо UIViewController или UICollectionView. Вам нужно написать их самим. Так, как вам удобно
• Вам не нужно использовать какие то особые UICollectionViewCell которые идут с библиотекой. Создавайте их так, как вам удобно.
• Вам не нужно в обязательном порядке рассчитывать размеры ячеек. ChatLayout сделает это за вас. При том, только для видимых в данный момент ячеек, не важно сколько их в всего в коллекции. Но, если вы укажите хотя бы приблизительный размер производительность только выиграет.
• Вам не предоставляется никакая базовая модель данных. Создавайте ее как вам удобно. Напишите свой UICollectionViewDataSource который будет отображать ее на экране. Приложение-пример использует для расчета изменений модели DifferenceKit, но вы можете использовать что вам угодно.
• ChatLayout не работает с клавиатурой. Вы можете написать свое решение или можете использовать любую подходящую для этого библиотеку. Все что требуется от вас в конечно итоге для поддержки клавиатуры это изменить contentInsets вашего UICollectionView.
• ChatLayout не предоставляет вам никакого поля для ввода текста. Приложение-пример использует стороннюю библиотеку InputBarAccessoryView (ту же, что использует MessageKit). Вы можете использовать ее или любое другое решение.

Собственно все. Спасибо за внимание. Буду рад Вашим комментариям.

Ах, да. Гифки. (Осторожно эпилептикам)

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

Победители категории Лучшее в App Store 2020:

Лучшие приложения:

• iPad: Zoom (Zoom, США)
• iPhone: Wakeout (Андрес Канелла, США)
• Mac: Fantastical (Flexibits, США)
• Apple TV: Disney+ (Disney, США)
• Apple Watch: Endel (Endel, Германия)

Лучшие тренды в приложениях:

• Тренд года: Shine поощрение пользователей к заботе о себе (Shine, США)
• Тренд года: Explain Everything Whiteboard оживление удаленных занятий (Explain Everything, Польша)
• Тренд года: Caribu поддержка контакта семей с близкими (Caribu, США)
• Тренд года: ShareTheMeal борьба с голодом (ООН, Германия)

Лучшие игры:

• iPhone: Genshin Impact (miHoYo, Китай)
• iPad: Legends of Runeterra (Riot Games, США)
• MacOS: Disco Elysium (ZA/UM, Великобритания и Эстония)
• Apple TV: Dandara Trials of Fear (Raw Fury, Швеция)
• Игра года для Apple Arcade: Sneaky Sasquatch (RAC7, Канада)
• Тренд года: Pokmon Go переосмысление подхода к игре (Niantic, США)

Zoom лучшее приложение 2020 г. для iPad

1. Присоединиться к встрече.
2. Ввести пароль или номер комнаты (при необходимости).
3. Ввести свое имя.

Caribu для iPhone и iPad тренд года

Caribu добавила на свою платформу для видеосвязи в реальном времени десятки интерактивных игр и более тысячи новых книг для семей, которые хотят общаться с близкими.
Apple

Это почти как виртуальный присмотр за детьми,

Максем Тухман, генеральный директор Caribu

Shine для iPhone и Apple Watch тренд года

Главное в Shine это простые мягкие формы и понимание психологии цвета. Приложение помогает бессознательно связывать каждый узор с эмоцией или настроением,

Ирина Коршак, иллюстратор

ShareTheMeal для iPhone и iPad тренд года

Приложение Всемирной продовольственной программы ООН ShareTheMeal дает любому человеку возможность участвовать в благотворительности: через него передано уже более 87 миллионов обедов для нуждающихся,
Apple

По словам Макса Косты, который возглавляет команду, ответственную за приложение в Берлине, пандемия подчеркнула важность ВПП, хотя можно было ожидать, что люди будут слишком заняты собственными проблемами, чтобы делиться с теми, кому повезло меньше,

Fast Company

Wakeout! лучшее приложение 2020 г. для iPhone

Fantastical лучшее приложение 2020 г. для macOS

Disney+ лучшее приложение 2020 г. для Apple TV

Explain Everything Whiteboard для iPhone и iPad тренд года

Endel лучшее приложение 2020 г. для Apple Watch

• текущая деятельность,
• время суток,
• пульс (измеряется через Apple Watch),
• погода
• и многое другое

Лучшие игры года

Pokmon GO тренд года

• Упражнения: позволяет отслеживать в качестве игровых достижений сделанные в помещении шаги например, бег на беговой дорожке.
• Социальное взаимодействие: виртуальные социальные функции в игре были улучшены, с тем чтобы игроки могли поддерживать контакт, даже когда они не могут встретиться в реальной жизни.

Когда в начале этого года разразилась пандемия COVID-19, Niantic быстро отреагировали и изменили Pokmon Go так, чтобы люди по-прежнему могли играть, но не выходя на улицу. Аудитория хорошо приняла нововведения, и в конце марта доходы от игры выросли это была лучшая неделя в 2020 году,

Game Industry

Legends of Runeterra для iPad

Приятно, когда есть возможность развлечь людей, которым остается лишь ждать, пока всё это закончится,
Джефф Джу, исполнительный продюсер Legends of Runeterra

Когда разразилась пандемия, Riot Games уже работали над Legends of Runeterra И оказалось, что застрявшие дома люди активно искали новые игры, похожие на Runeterra: это виртуальная карточная игра, поэтому у нее не было проблем из-за коронавируса, как в случае оффлайн игр например, Magic: The Gathering в ее традиционной бумажной форме,

Fast Company

Sneaky Sasquatch игра года для Apple Arcade

В череде невероятно забавных игр эта особо выделяется за что и выиграла в номинации Игра года для Apple Arcade. Дурашливый, но аккуратный визуальный стиль, чудесная музыка и великолепный игровой процесс не пропустите.
Apple

Сооснователь RAC7 Games Джесси Рингрос рассказал изданию Complex (Канадское подразделение):

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

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

Dandara: Trials of Fear для Apple TV

Сюжет игры кажется сегодня на удивление актуальным. Рассказ, по сути, сосредоточен на изоляции и ее влиянии на общество. Игра не тратит много времени на раскрытие сюжета; вы не найдете длинных анимационных вставок и продолжительных объяснений вам придется собирать историю по кусочкам с помощью дневников и заметок, разбросанных по всему миру. Чтобы найти некоторые из них, придется здорово постараться но если сюжет вас заинтересует, их стоит поискать,

Switch Player

Disco Elysium для MacOS

Disco Elysium это не привычная ролевая игра, а скорее даже наоборот: здесь нет сражений, у героя нет невероятных суперсил, и объем текстов в Disco Elysium больше, чем полное собрание сочинений Шекспира. Главное здесь это внимание к деталям, размышление о своих действиях и нестандартное мышление. По сути, это детективная ролевая игра,

обзор от Mef Tech

Топ бесплатных приложений для iPhone

1. ZOOM Cloud Meetings
2. TikTok
3. Disney+
4. YouTube
5. Instagram
6. Facebook
7. Snapchat
8. Messenger
9. Gmail
10. Cash App

Топ платных приложений для iPhone

1. TouchRetouch
2. Procreate Pocket
3. Dark Sky Weather
4. Facetune
5. HotSchedules
6. AutoSleep Track Sleep
7. The Wonder Weeks
8. SkyView
9. Shadowrocket
10. Sky Guide

Топ бесплатных игр для iPhone

1. Among Us!
2. Call of Duty: Mobile
3. Roblox
4. Subway Surfers
5. Ink Inc. Tattoo Drawing
6. Magic Tiles 3: Piano Game
7. Brain Test: Tricky Puzzles
8. Brain Out
9. Coin Master
10. Cube Surfer!

Топ платных игр для iPhone

1. Minecraft
2. Plague Inc
3. Heads Up!
4. Monopoly
5. Bloons TD6
6. Geometry Dash
7. NBA 2K20
8. Grand Theft Auto: San Andreas
9. The Game of Life
10. True Skate

Топ бесплатных приложений для iPad

1. ZOOM Cloud Meetings.
2. Disney+
3. YouTube
4. Netflix
5. Google Chrome
6. TikTok
7. Amazon Prime Video
8. Gmail
9. Hulu
10. Google Класс

Топ платных приложений для iPad

1. Procreate
2. GoodNotes 5
3. Notability
4. Duet Display
5. Teach Your Monster
6. LumaFusion
7. Affinity Designer
8. Toca Hair Salon 3
9. Toca Life: Hospital
10. Toca Kitchen 2

Топ бесплатных игр для iPad

1. Among Us!
2. Roblox
3. Magic Tiles 3: Piano Game
4. Ink Inc. Tattoo Drawing
5. Call of Duty: Mobile
6. Subway Surfers
7. Dancing Road: Color Ball Run!
8. Tiles Hop EDM Rush
9. Mario Kart Tour
10. Save The Girl!

Топ платных игр для iPad

1. Minecraft
2. Monopoly
3. Bloons TD 6
4. Plague Inc.
5. Geometry Dash
6. The Game of Life
7. Five Nights at Freddys
8. Human: Fall Flat
9. Stardew Valley
10. Terraria

Топ игр Arcade

1. Sneaky Sasquatch
2. Hot Lava
3. Skate City
4. Sonic Racing
5. PAC-MAN Party Royale
6. SpongeBob: Patty Pursuit
7. Oceanhorn 2
8. Crossy Road Castle
9. WHAT THE GOLF?
10. LEGO Brawls

О переводчике

Map(coordinateRegion: <#T##Binding<MKCoordinateRegion>#>)

@State private var isVisible = trueif isVisible == true {    Text("Hello") // Only rendered when isVisible is true.}

@mainstruct testmultiplatformApp: App {  @SceneBuilder var body: some Scene {        WindowGroup {            MailViewer()        }        Settings {            SettingsView()        }    }}

public func onChange<V>(of value: V, perform action: @escaping (V) -> Void) -> some Scene where V : Equatable

  ///    /// Use this modifier to trigger a side effect when a value changes, like    /// the value associated with an ``SwiftUI/Environment`` key or a    /// ``SwiftUI/Binding``. For example, you can clear a cache when you notice    /// that a scene moves to the background:    ///    ///     struct MyScene: Scene {    ///         @Environment(\.scenePhase) private var scenePhase    ///         @StateObject private var cache = DataCache()    ///    ///         var body: some Scene {    ///             WindowGroup {    ///                 MyRootView()    ///             }    ///             .onChange(of: scenePhase) { newScenePhase in    ///                 if newScenePhase == .background {    ///                     cache.empty()    ///                 }    ///             }    ///         }    ///     }    ///    /// The system calls the `action` closure on the main thread, so avoid    /// long-running tasks in the closure. If you need to perform such tasks,    /// dispatch to a background queue:    ///    ///     .onChange(of: scenePhase) { newScenePhase in    ///         if newScenePhase == .background {    ///             DispatchQueue.global(qos: .background).async {    ///                 // ...    ///             }    ///         }    ///     }    ///    /// The system passes the new value into the closure. If you need the old    /// value, capture it in the closure.    ///

XCTSkip для ваших тестов

• Закончить выполнение тестового набора;
• Пометить тест как пройденный и пойти дальше;
• Зафейлить тест.

Обработка прерываний и алертов в UI тестах

Class XCUIApplication {open func resetAuthorizationStatus(for: XCUIProtectedResource)}

// Examplefunc testAddingPhotosFirstTime() throws {let app = XCUIApplication()app.resetAuthorizationStatus(for: .photos)app.launch()// Test code...}

Устраняем лаги анимации с помощью XCTest

Триаж и диагностика упавших тестов

• Distinct types;
  
• Detailed description;
  
• Associated error;
  
• Attachments.
  

Пишите тесты для того, чтобы они падали

Получайте результат тест рана быстрее

1. Собирает отчет (spindump);
2. Убивает зависший тест;
3. Перезапускает тест раннер, чтобы оставшаяся часть сьюта смогла выполниться.

xcodebuild option-default-test-execution-time-allowance <seconds>

xcodebuild option-maximun-test-execution-time-allowance <seconds>

Class XCTestCase: XCTest {var executionTimeAllowance: TimeInterval // с округлением до минуты}

xcodebuild test    -project MyProject.xcodeproj    -scheme MyProject    -parallel-testing-enabled YES    -parallelize-test-among-desinations    -destination 'platform=iOS,name=iPhone 11'    -destination 'platform=iOS,name=iPad pro' 

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

При встраивании подписок, иногда упускаются важные вопросы:

• как и где хранить id для предлагаемых продуктов?
• как часто планируется итерация по новым продуктам?
• на каком этапе работы приложения стоит запрашивать продукт? На запуске или перед показом экрана
• есть ли время на встраивание сложной системы для работы с продуктами или необходим быстрый запуск?

В отличие от огромного количества UX-подходов для работы с подписками, техническое решение имеет всего два пути развития:

1. Мы переносим всю работу на сервер
2. Вся логика работы с продуктами остается на клиенте

У каждого подхода есть плюсы и минусы, далее мы рассмотрим следующие вопросы:

1. Хранение id продуктов: клиент или сервер?
2. В какой момент работы приложения стоит запросить продукты?
3. Кэшировать или не кешировать продукты?
4. Аналитика покупок: и снова клиент или сервер?

Итак, погнали!

Хранение id продукта

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

И появляется головная боль, как и где хранить этот самый id: захардкодить на устройстве или получать с сервера.

При хранении на клиенте вам не нужно задумываться о контрактах работы с бекендом или поиском SaaS решения, если в вашем проекте отсутствует надобность в сервере. Вы просто сохраняете массив нужных вам id продуктов внутри приложения, запрашиваете их и показываете. В целом вы даже можете довольно быстро итерироваться по разным подпискам, просто обновляя приложение в store.

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

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

1. Как клиент будет понимать к какому виду продуктов относится данный id
2. Как различать на экране покупки какие продукты где показывать

Также стоит всегда иметь массив id продуктов на случай если сервер, вдруг, неожиданно "отвалится". Поскольку в ином случае есть шанс упустить пользователей, которые могут с удовольствием заплатить за ваш продукт, но просто не иметь такой возможности из-за технических неполадок.

Запрос продуктов и кэширование

Когда запрашивать продукты? Это второй вопрос, о котором всегда стоит задуматься перед началом встраивания подписок в наше приложение. Поскольку чем раньше мы загрузим продукты, тем раньше мы сможем предложить пользователю купить нашу подписку. И в случае с клиентским хранением все обычно однозначно: запросили, сохранили, показали.

То в случае, когда мы работаем с сервером появляется разветвление. Потому что мы можем иметь желание показать пользователю только самое актуальное предложение: менеджер мог обновить новые подписки в тот момент, когда пользователь зашел в приложение и в итоге увидит старое предложение. При таком подходе стоит отложить запрос до момента захода пользователя на экран или запрашивать продукты в фоне раз в n-времени, но если пользователь уже зашел на экран, то стоит показать то, что уже было закешировано, чтобы избежать ожидания пользователя.

Сконцентрируемся немного на процессе запроса id продуктов с сервера и самих продуктов уже от Apple.

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

Однако стоит учитывать, что при таком подходе появляется промежуточный результат, при котором любой A/B тест способен сломаться. Представим ситуацию: пользователь заходит на экран покупки и видит продукты, загруженные из запасного списка. Затем пользователь выходит с экрана и продолжает пользоваться приложением. За это время загружаются актуальные продукты и снова показываются пользователю, и в этот раз пользователь совершает покупку. В такой ситуации перед бизнесом появляется вопрос, на который есть множество ответов, среди которых придется долго искать истину:Что мотивировало купить пользователя совершить покупку в этот раз?

Данный вопрос можно разрешить следующим образом

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

Итог

Встраивание покупок само по себе несложное действие, но стоит задуматься о том, как в дальнейшем будет развиваться ваш проект и продукт. Задайте себе вопросы:

• Я планирую делать большой продукт или маленький пет-проект?
• Как в дальнейшем я планирую развивать подписки?
• У меня есть время на разработку сложного решения?

Эти три вопроса помогут вам понять какие шаги для проектирования стоит сделать и куда смотреть дальше. Также если вы небольшой проект, но вам необходимо иметь серверную логику, то всегда лучше взглянуть на готовые решения и BaaS, которые уже прошли основную боль и сэкономят вам кучу времени.

Первые шаги

import UIKitimport FeatureOneimport FeatureTwoclass ViewController: UIViewController {//..}

import UIKitimport FeatureOneimport FeatureTwoclass ViewController: UIViewController {        var vc: Obj2ViewController?        override func viewDidLoad() {        super.viewDidLoad()        // Do any additional setup after loading the view, typically from a nib.    }

workspace 'myFrameworkTest'

def networkPods     pod 'Alamofire'end def uiPods     pod 'GoogleMaps' end

target 'myFrameworkTest' doproject 'myFrameworkTest'    networkPods    uiPods    target 'myFrameworkTestTests' do    endend 

target 'FeatureOne' do    project 'FeatureOne/FeatureOne'    uiPods    pod 'ChatThatMustNotBeNamed'end

Подводные камни

target 'myFrameworkTest' do    project 'myFrameworkTest'    pod 'ChatThatMustNotBeNamed'    networkPods    uiPods    target 'myFrameworkTestTests' do    endend

@objc public extension UITableView {    func registerClass(_ classType: AnyClass) {        let bundle = Bundle(for: classType)        let name = String(describing: classType)        register(UINib(nibName: name, bundle: bundle), forCellReuseIdentifier: name)    }}

Выводы

Предисловие

Стартуем от сюда

extension UserDefaults {    var onboardingCompleted: Bool {        get { return bool(forKey: #function) }        set { set(newValue, forKey: #function) }    }}

protocol InstanceEquatable: class, Equatable {}extension InstanceEquatable {    static func ==(lhs: Self, rhs: Self) -> Bool {        return lhs === rhs    }}extension Enemy: InstanceEquatable {}func testDestroyingEnemy() {    player.attack(enemy)    XCTAssertTrue(player.destroyedEnemies.contains(enemy))}

let workItem = DispatchWorkItem {    // Ваш асинхронный код здесь}// Вызовем его через 1 секундуDispatchQueue.main.asyncAfter(deadline: .now() + 1, execute: workItem)// А теперь можем прекратить его работу(в любое удобное для нас время)workItem.cancel()

enum Result<Value> {    case value(Value)    case error(Error)}class Promise<Value> {    private var result: Result<Value>?        init(value: Value? = nil) {        result = value.map(Result.value)    }}

public func generate() throws {    let contentFolder = try folder.subfolder(named: "content")    let articleFolder = try contentFolder.subfolder(named: "posts")    let articleProcessor = ContentProcessor(folder: articleFolder)    let articles = try articleProcessor.process()    ...}

public func generate() throws {    let contentFolder = try folder.subfolder(named: "content")    let articles = try processArticles(in: contentFolder)    ...}private func processArticles(in folder: Folder) throws -> [ContentItem] {    let folder = try folder.subfolder(named: "posts")    let processor = ContentProcessor(folder: folder)    return try processor.process()}

Дисклеймер: это сценарий идеального технического собеседования в Delivery Club Tech. Мнение нашей команды может не совпадать с мнением читателей.

1. Собесы бывают разные: жёлтые, зелёные, красные (лирическое отступление)

2. Идеальный формат, идеальный кандидат (формируем требования)

• ценности и взгляды кандидата, soft skills;
• профессиональные навыки и умения, hard skills;
• модели поведения и индивидуально-личностные качества.

3. О бедном эйчаре замолвите слово (про важность хорошего HR-специалиста)

4. Как играть на поле кандидата, не забывая про себя (требования к интервьюерам)

5. Сценарий идеального технического собеседования

Сценарий идеального технического интервью. Драма в пяти действиях

• Олег молодой, перспективный iOS-разработчик
• Василий умудрённый опытом тех лид команды iOS

Действие первое

Действие второе

Действие третье

Действие четвертое

Действие пятое

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

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

Наследование

Это и есть принцип наследования, где каждый админ/VIP-клиент/аноним являются пользователями, но не каждый пользователь должен быть админом или VIP-пользователем.

/**    Нужно сделать экран профиля пользователя, в котором отображаются имя и фамилия. Этот экран должен переиспользоваться. */// INCORRECTclass UserProfileViewController: UIViewController {    // MARK: - IBOutlets    @IBOutlet private var firstNameLabel: UILabel!    @IBOutlet private var lastNameLabel: UILabel!    /**    Заполнение данных оставляем классу наследнику в виде абстрактных методов     */    // MARK: - Abstract methods    func firstName() -> String? {        return nil    }    func lastName() -> String? {        return nil    }    // MARK: - Lifecycle    override func viewDidLoad() {        super.viewDidLoad()        firstNameLabel.text = firstName()        lastNameLabel.text = lastName()    }}/**    Создаем класс-наследник, который отвечает за функцию заполнения данных. В таком случае, наследник будет выполнять роль не только UIViewController, а и роль модели, которая предоставляет данные для отображения. */class UserProfileModel: UserProfileViewController {    override func firstName() -> String? {        return "Name"    }    override func lastName() -> String? {        return "Last name"    }}// CORRECT    /**    Корректней будет, добавить новый класс-модель, которая будет предоставлять данные.     */class UserProfileModel {    func firstName() -> String? {        return "Name"    }    func lastName() -> String? {        return "Last name"    }}/**    В таком случае у нас будут два отдельных класса, каждый из которых имеет свою зону ответственности. */class UserProfileViewController: UIViewController {    var model: UserProfileModel?    // MARK: - IBOutlets    @IBOutlet private var firstNameLabel: UILabel!    @IBOutlet private var lastNameLabel: UILabel!    // MARK: - Lifecycle    override func viewDidLoad() {        super.viewDidLoad()        setupUserInfo()    }    // MARK: - Private    private func setupUserInfo() {        firstNameLabel.text = model?.firstName()        lastNameLabel.text = model?.lastName()    }}// PERFECT/**    Еще лучше, взаимодействие между двумя типами классов, контроллер и модель, сделать через протокол, чтобы можно было создавать и использовать разные модели. */protocol UserProfileProtocol {    func firstName() -> String?    func lastName() -> String?}class UserProfileViewController: UIViewController {    var model: UserProfileProtocol?    // MARK: - IBOutlets    @IBOutlet private var firstNameLabel: UILabel!    @IBOutlet private var lastNameLabel: UILabel!    // MARK: - Lifecycle    override func viewDidLoad() {        super.viewDidLoad()        setupUserInfo()    }    // MARK: - Private    private func setupUserInfo() {        firstNameLabel.text = model?.firstName()        lastNameLabel.text = model?.lastName()    }}class UserProfileModel: UserProfileProtocol {        // MARK: - UserProfileProtocol        func firstName() -> String? {        return "Name"    }    func lastName() -> String? {        return "Last name"    }}

Это пример, когда непонимание принципа наследования приводит к сложности понимания системы.

Абстракция

Абстракция гласит останавливаем внимание на важных и необходимых аспектах объекта и игнорируем ненужные для нас.

/**    Распространенная ситуация: создаем класс, к примеру, простую модель пользователя. Но с добавлением функционала, все больше появляется полей и методов в этом классе. */// INCORRECTclass User {    let firstName: String    let lastName: String    let fullName: String    let age: Int    let birthday: Date    let street: String    let postalCode: Int    let city: String    var phoneNumber: String?    var phoneCode: String?    var phoneFlag: UIImage?    var isLoggined: Bool = false    var isAdmin: Bool = false    // MARK: - Init        init(firstName: String,         lastName: String,         fullName: String,         age: Int,         birthday: Date,         street: String,         postalCode: Int,         city: String) {        self.firstName = firstName        self.lastName = lastName        self.fullName = fullName        self.age = age        self.birthday = birthday        self.street = street        self.postalCode = postalCode        self.city = city    }    // MARK: - Admin functionality        func createNewReport() {        guard isAdmin else { return }                print("New report created")    }        func updateReport(for user: User) {        guard isAdmin else { return }                print("Update report for \(user.fullName)")    }}// CORRECT/**    Правильней будет, декомпозировать код, абстрагируя части большого сложного класса на маленькие компоненты. */class Address {    let street: String    let postalCode: Int    let city: String    init(street: String,         postalCode: Int,         city: String) {        self.street = street        self.postalCode = postalCode        self.city = city    }}class Name {    let firstName: String    let lastName: String    init(firstName: String,         lastName: String) {        self.firstName = firstName        self.lastName = lastName    }    var fullName: String {        firstName + " " + lastName    }}class PhoneNumber {    let phone: String    let code: String    let flag: UIImage    init(phone: String,         code: String,         flag: UIImage) {        self.phone = phone        self.code = code        self.flag = flag    }}class User {    /**    В результате, класс User уменьшился в размерах, при этом мы абстрагируемся от деталей имени и адреса.     */    let name: Name    let address: Address    let birthday: Date    var phoneNumber: PhoneNumber?    init(name: Name,         address: Address,         birthday: Date) {        self.name = name        self.address = address        self.birthday = birthday    }}/**    Так как после логина система получает залогиненого Пользователя, то класс User не должен отвечать за состояния системы. За статус логина будет отвечать новая сущность, тем самым система абстрагируется от деталей логики этого статуса. */class LoginSession {    var user: User?    var isLoggined: Bool {        user != nil    }}/**Дополнительные свойства Администратора выносяться в класс-наследник Пользователя. */class Admin: User {    func createNewReport() {        print("New report created")    }        func updateReport(for user: User) {        print("Update report for \(user.fullName)")    }}

Полиморфизм

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

Добавлю, что полиморфизм тесно связан с наследованием и проблемы в наследовании отзываются еще большими проблемами в полиморфизме.

Инкапсуляция

/**    Создаем кнопку, у которой при нажатии цвет бэкграунда устанавливается в оригинальный цвет но с альфаканалом 0,5 */// INCORRECTclass Button: UIButton {     /**    Добавляем два метода, которые устанавливают цвет бекграунда для состояния нажатой кнопки и нормального состояния кнопки     */    func decorateSelected() {        backgroundColor = backgroundColor?.withAlphaComponent(0.5)    }        func decorateDeselected() {        backgroundColor = backgroundColor?.withAlphaComponent(1)    }    override var isSelected: Bool {        didSet {            if isSelected {                decorateSelected()            } else {                decorateDeselected()            }        }    }}// SAMPLE /**    Проблемой будет то, что методы, декорирующие кнопку в разных состояних, являются публичными. А это значит, что можно нарушить логику работы кнопки, вызвав метод в неправильный момент. */let button = Button()button.decorateSelected()// CORRECTclass Button: UIButton {        override var isSelected: Bool {        didSet {            if isSelected {                decorateSelected()            } else {                decorateDeselected()            }        }    }     /**    Мы сделали методы, настраивающие внешний вид кнопки, приватными, тем самым обеспечили правильную логику отображения.     */    // MARK: - Private    private func decorateSelected() {        backgroundColor = backgroundColor?.withAlphaComponent(0.5)    }        private func decorateDeselected() {        backgroundColor = backgroundColor?.withAlphaComponent(1)    }}// PERFECT /**    Но! У кнопки остаеться возможнось измененить цвет через базовое поле var backgroundColor: UIColor?. Поэтому, немного заморочившись, делаем невозможным менять цвет в момент, когда кнопка нажата. */class Button: UIButton {            override var backgroundColor: UIColor? {        get {            super.backgroundColor        }        set {            if isHighlighted == false {                super.backgroundColor = newValue            }        }    }        override var isHighlighted: Bool {        willSet {            if newValue {                decorateSelected()            }        }                didSet {            if isHighlighted == false {                decorateDeselected()            }        }    }    // MARK: - Private    private func decorateSelected() {        backgroundColor = backgroundColor?.withAlphaComponent(0.5)    }        private func decorateDeselected() {        backgroundColor = backgroundColor?.withAlphaComponent(1)    }}

Инкапсуляция не бездумное сокрытие каких-то полей или методов, а проектирование класса с определенным набором возможностей, которые не должны нарушаться.

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

Заключение

Привет! Меня зовут Михаил и год назад я стал iOS-разработчиком в компании ЦФТ. До этого почти 8 лет я проработал в сфере логистики и таможенного оформления, а айосером меня можно было назвать разве что из-за наличия iPhone.

Я хочу поделиться своим опытом. Зачем? Меня такие истории мотивировали на старте, и, возможно, именно мой опыт не даст кому-то опустить руки. Моя история не из разряда как стать джуном за два месяца, а о том, как не соскочить в этом марафоне.

Немного о прошлом

До 2018 года я жил в небольшом городке Находка, что на берегу Японского моря. Несмотря на своё профильное IT-образование, меня мало интересовало программирование. В универе мы проходили древние Pascal и Delphi, которые меня никак не увлекали. Хотя в студенческие времена, меня мало что интересовало кроме корейских MMORPG. Играл в Lineage 2 и Aion.

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

Почему iOS?

До сих пор помню тот момент, когда я увидел iPhone впервые. Это был безумно красивый iPhone 4, который подарили моему другу. Меня сильно впечатлило то, как было реализовано взаимодействие с ОС, насколько оно было плавным и отзывчивым.

С тех пор началась, и все еще продолжается моя любовь к яблочным гаджетам. Эх, а это был далёкий 2011 год, когда Джобс ещё был жив, FruitNinja была в топе AppStore, а в Instagram не было рекламы.

Swift. Начало

Swift я начал изучать в 2017. Мне стало интересно сложно ли создать своё приложение. Сначала я наткнулся на стэндфордские курсы, а позже я нашёл swiftbook, который уже к тому времени запустил Иван Акулов.

Язык по первости казался не таким уж и сложным для понимания. Ну что там? If, else, циклы всё же понятно! Версия на тот момент была уже 3.x, которая в том же году прыгнула до 4.0.

Под это дело я приобрёл бу MacBook Pro 15 2010 за ~ 40 тыс. рублей, так как запускать Xcode в виртуалке было невыносимо. Но даже этот древний Mac вызывал у меня восторг от качества его исполнения. Там стоял SSD и для учёбы хватало за глаза! Теперь в свободное время я изучал азы программирования на Swift.

Казалось бы, все есть для учебы, бери и учись! Однако, пару раз столкнувшись с нерешаемыми проблемами (например, closures), которые заводили меня в тупик, разум начал меня предавать и подкидывать мысли вроде: а может это не моё?.

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

Переезд в Питер

Всё изменилось в 2018. К тому моменту я уже всерьёз думал о Петербурге. После первой неудачной попытки в программирование, я решил попробовать себя в написании сценариев и у меня даже получалось! Я участвовал в различных конкурсах и да, я не брал призовых мест, но попадал в шорт-листы, что для меня, как для новичка стало большим результатом и ещё одним аргументом для переезда, ведь в Питере есть сценарные курсы и школы.

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

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

Swift. Вторая попытка

Как ни странно, к изучению Swift и iOS-разработке я вернулся, после того как начал посещать очные курсы по сценарному мастерству в Питере. Параллельно я ещё интересовался работой мозга, даже посещал очный курс сейчас уже небезызвестного Андрея Курпатова.

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

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

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

В феврале 2019-го я записался на вебинары в группе с преподавателем. Три месяца я жил в режиме работа дом учёба. В таком графике было тяжело. Я проводил за компом по 12-14 часов в день: на работе 8-10 часов + дежурства, а после еще 3-4 часа за учёбой. Подсело зрение, и я решил, что так больше не должно продолжаться нужно что-то менять. И я решил уволиться.

Уволился я не сразу: сначала я проявил наглость и договорился с начальником ходить на работу 23 раза в неделю за половину оклада. Это наглость потому как в той сфере, ты либо работаешь фул-тайм, либо не работаешь.

Так продолжалось месяц, а потом, как только мне нашли замену уволили. Это позволило какое-то время не уходить в минус по деньгам и посвятить большую часть времени обучению.

Свободное плавание

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

Не сказать, что я учился 24/7. Я выдерживал 8-10 часовой учебный день, за который успевал проходить вебинары, делать домашки и изучать что-то параллельно (например, проходил очень интересный CS50, а иногда даже успевал посещать очные курсы по сценарному мастерству). Отдыхать я тоже не забывал: занимался спортом, играл c друзьями в PS4. Всё это помогало не перегорать и, на мой взгляд, качественней усваивать знания.

В таком режиме я провёл больше полугода. За это время я посетил пару бесплатных митапов для мобильных разработчиков: один от CocoaHeads в офисе Яндекса, а второй MobiFest от ЦФТ. Признаться, мне было неуютно: не имея опыта коммерческой разработки, я чувствовал себя недоразработчиком, но мне очень понравилась атмосфера. То, что люди собираются и делятся знаниями друг с другом очень круто! Это придавало сил и желания довести начатое до конца.

Первые собеседования

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

В общем, я решил, что пора ходить на собесы. Я причесал все свои учебные проекты в github и написал резюме, впихнув туда весь стек, о котором хоть что-то знал.

Первый отклик, конечно же, был отказом и довольно неприятным. Мне предложили сделать тестовое задание и дали срок в 3 дня. По заданию необходимо было создать форму регистрации агента с валидацией полей и отправить её на сервер (дали ссылку на их тестовый API). Я сделал тестовое, попутно изучив регулярные выражения и отправил в срок. В ответ тишина. Я решил перезвонить им сам, чтобы получить обратную связь, но мне лишь сказали, что я не подхожу.

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

Потом было ещё пара собесов, в том числе и очных, но заветного оффера я не получал. Было ощущение, что либо я недотягиваю, либо у компаний завышенные требования к джунам. Лишь одно собеседование из трёх, как мне показалось, было адекватным уровню Junior-разработчика. Тем не менее я не опускал руки и старался восполнять те пробелы, которые вскрывались на собеседованиях.

Стало понятно, что Петербург хоть и большой город, но предложений для новичков здесь немного, в общем-то, как и везде.

Focus Start

Осенью 2019, мне исполнилось 30 лет. Я всё ещё искал работу и наткнулся на объявление о наборе на очный курс по iOS-разработке от компании ЦФТ.

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

Недолго думая я отправил заявку. Предложили выполнить тестовое задание. На iOS это выглядело как обычный TableView + DetailView, с поддержкой CRUD и сохранением данных между запусками приложения.

Я отправил тестовое и стал ждать. Через некоторое время пришло письмо с приглашением на очное собеседование.

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

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

Нам пообещали сообщить результаты через неделю. К тому времени я уже закончил своё обучение на вебинарах, изучал только отдельные темы. И, конечно, мониторил вакансии.

Обучение на Focus Start

Через неделю мне пришло письмо! Мне сообщили, что я прошёл отбор. Всего на обучение отобрали 12 человек. Мы собирались 3 раза в неделю: по вторникам, четвергам и субботам.

По будням занятия длились 2 часа, а по субботам 4 часа. Суббота была ещё особенна тем, что в перерыв нас угощали пиццей. Ну, и чай/кофе были всегда в нашем распоряжении.

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

Учится было интересно и материала было довольно много. Я даже не знаю, как справлялись ребята, которые ещё параллельно учились или работали. Всё своё свободное время (а его на тот момент было предостаточно) я посвящал домашним заданиям.

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

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

В конце обучения был выпускной, на котором все команды презентовали свои проекты. Было очень интересно посмотреть на другие работы, и, конечно, все ребята справились на отлично. Вот что в итоге получилось у моей команды: https://github.com/c0dedbear/PhotoTune

Должен отметить, что преподаватели в течение всего срока обучения всегда были готовы прийти на помощь и поделится с нами своим опытом. Это было отличное время! Я даже немного скучаю по той атмосфере.

Что было дальше?

Дальше наступил недельный период неопределённости. Я не знал, возьмут ли меня, поэтому первым делом обновил резюме в соответствии с полученными навыками. Посмотрел на существующие вакансии и отправил пару откликов.

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

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

Подводя черту

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

• Нужно быть готовым к длительному обучению. Есть люди, которые, пройдя пару курсов, попали на работу, но это скорее исключение. Настраивайтесь как минимум на год непрерывного обучения. Примите это.
• Нужно продумать финансовую сторону вопроса: у вас должна быть подушка или другой источник дохода на время обучения. Либо же у вас должно быть время на обучение в отрыве от основной деятельности (желательно 34 часа в день). И здесь важна регулярность, лучше по часу-два каждый день, чем по полдня раз в неделю.
• Ходите на тематические митапы, если есть такая возможность. Там можно проникнуться атмосферой, познакомиться с другими разработчиками и даже найти работу.
• Не попадите в ловушку вечного студента. Проходить туториалы и курсы можно бесконечно, но чем раньше вы начнёте делать что-то самостоятельно, тем быстрее будете прогрессировать.
• Ходите на собеседования. Даже если не уверены или не хочется. Как только вы освоили базу по iOS время ходить по собеседованиям. Они принесут вам опыт и дадут возможность увидеть пробелы в знаниях.
• Правильный настрой. Проходя собеседования, не переживайте, о том возьмут вас или нет. Лучше заранее принять то, что вас не возьмут и сосредоточится на том, какие вопросы бьют по вашим слабым местам, чтобы впоследствии их проработать.