Видео, доклады и краткий отчет для тех, кто не доехал.

В новом офисе Superjob на Малой Дмитровке состоялся первый в 2017 году митап по мобильной iOS-разработке. Приложение Superjob для поиска работы стабильно «проживает» в топе AppStore, а счет установок давно идет на миллионы. Мы первыми запустили приложение для корпоративных пользователей, и сегодня тысячи работодателей уже даже и не обращаются к веб-версии. Так что опыт у нашей команды действительно уникальный. Таким обычно службы безопасности делиться не разрешают. Но у нас СБ нет — запретить вечеринку было некому.



Послушать и поспорить собрались 70 человек, еще 400 человек смотрели трансляцию в прямом эфире. Собираться в 2017 году по мобильной теме будем часто. Так что подписывайтесь, не пропускайте будущие митапы: трансляции будут не всегда, у кого-то СБ все-таки не дремлет, а оффлайновые места заканчиваются очень быстро.

Артем Тарадаш, главный по пользовательским интерфейсам Superjob, рассказал об опыте перехода к принципам атомарного дизайна, когда по аналогии с природными объектами проектируемый интерфейс формируется из атомарных элементов. Надежда Буцаева, менеджер продукта, рассказала о применяемом в Superjob подходе к постановке задач. На примере сервиса «Работа рядом с домом» она показала, как из аналитики запросов работодателей и пользовательских предпочтений опыта формируется задача развития продукта.

Сергей Токарев, старший разработчик мобильных приложений Superjob, представил такие подходы к архитектуре приложения, с помощью которых удалось избавиться от ”massive” view controller. В его кейсе для этого применяется разделение логики на четыре слоя: Adapter, Facade, ViewModel и View. Передача данных между слоями выполняется сигналами Reactive Cocoa (кроме delegate между ViewModel и View), а в качестве менеджера зависимостей используется фреймворк Objection. Каждый уровень архитектуры был проиллюстрирован примером кода для формирования одной страницы приложения: все эти примеры хорошо видны на опубликованном видео.




Владимир Бурдуков, iOS-разработчик Netco Sports, поделился своим опытом применения Fastlane — набора утилит для автоматизации процесса подготовки, сборки и деплоя iOS-приложений. Простые и удобные команды этого инструмента, кажется, действительно должны упростить рутинную работу каждого iOS-разработчика (если он все ещё не использует Fastlane, конечно). С помощью Fastlane, например, можно автоматизировать процесс создания скриншотов для всех моделей телефонов на 10 языках или раз и навсегда решить болезненные вопросы связанные с code signing. Или свернуть весь процесс релиза новой версии приложения в AppStore до одной команды fastlane appstore. Эти утилиты были написаны iOS-разработчиками для iOS-разработчиков, поэтому из коробки позволяют автоматизировать большинство процессов, связанных с разработкой, тестированием или релизом iOS приложений. Если же не хватает готового набора действий, то можно сделать собственные расширения, поделиться ими с сообществом или же сохранить и использовать у себя в компании с помощью системы Plugins.


  • Презентация Владимира здесь

Информация о новых IT-митапах будет появляться в официальной группе в Facebook. Присоединяйтесь!
Поделиться с друзьями
-->

Комментарии (6)


  1. SarkazmMan
    03.02.2017 12:10

    У меня немного вопросов к докладу Сергея:
    1. Почему не стали использовать VIPER? Из-за любви к MVVM и реактиву?
    2. Могут ли переиспользоваться фасады? Или что вы делаете, если в нескольких фасадах есть общая логика? Или фасады не относятся к определенному модулю?
    3. Как фасад определяет, к какому адаптеру обращаться? Он хранит какое-то состояние?
    4. Тестируете ли вы инъекции?
    5. Почему между VM и View связь через делегирование?
    6. Какой объект в вашей архитектуре отвечает за навигацию?
    7. Если UI одного экрана сложный, разбиваете ли вы его на сабмодули? Если да, то как?
    8. Что вы используете для работы с таблицами?
    9. Примеры в презентации были написаны на Objective-C. Используете ли вы эту архитектуру в Swift проекте? Если да, то как собираете модули?


    1. geserbox
      06.02.2017 10:08

      1. Когда мы начали менять нашу архитектуру, мы смотрели на VIPER, но некоторые аспекты нам показались лишними. Наличие небольшого опыта с MVVM, который хорошо ложился с использованием в связке с ReactiveCocoa, определил направление.
      2. Все фасады наследуются от корневого, который содержит общую логику. Фасады разделены по принципу сущностей данных, которые он может получать, например — фасад резюме, фасад вакансий и т.д.
      3. Аналогично разделению фасадов, адаптеры делятся образом и соответственно фасад резюме будет запрашивать данные у адаптера резюме.
      4. Нет, инъекции мы не тестируем, упор был больше на бизнес-логику.
      5. На самом деле можно было так же использовать сигналы как и на предыдущих слоях.
      6. Тут я возможно немного слукавил, когда говорил, про принцип единственной ответственности. ViewModel c помощью делегата передает на слой View информацию о навигации, то есть ViewModel выполняет чуточку больше :) есть желание избавить ее от этой ответственности.
      7. Все несколько проще, для данного случая мы выносим в категории модуля логику.
      8. Немного не понял вопрос, можешь уточнить?
      9. Что касается приложения на swift (производственный календарь), оно по своей структуре простое и оно написано в MVC.


      1. SarkazmMan
        07.02.2017 05:10

        • По 3 вопросу — а если фасад использует несколько адаптеров, как он понимает, к какому обращаться?, к какому обращаться?
        • По 8 вопросу — я увидел на слайдах кастомные протокол для секции таблицы. Используете ли вы какое-то стороннее или свое решение для таблиц, чтобы избежать огромных свичей и if-else конструкций и методах delegate/datasource таблицы?


        1. geserbox
          07.02.2017 19:00

          3. Если вернуться к примеру с авторизованным/неавторизованным пользователем, то фасад вакансий, на основе данных из фасада профиля, узнает статус пользователя и дальше if/else выбор адаптеров. Решили не усложнять данный момент механизмами состояний, и в то же время решение не мешает тестируемости кода.
          8. Тут ты подметил абсолютно точно на тему switch, в некоторых местах громоздо выглядит, пока не нашли решения. Сталкивался ли ты с подобным и как решал?


          1. SarkazmMan
            08.02.2017 05:18

            Насчет таблиц — мы используем самочинную библиотеку TableViewTools, она отлично решает эту задачу. Если кратко — каждой ячейке соответствует определенный объект, который знает, как отрисовать ячейку, заполнить данными и отреагировать на actions. И почти вся логика работы с таблицей выносится из контроллера.


            1. geserbox
              10.02.2017 16:32

              Спасибо за совет, изучим :)