IT-meetup Superjob «iOS — архитектура дизайна, кода, деплоя» (отчет, презентации, видео)

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

    В новом офисе 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. Присоединяйтесь!
    • +19
    • 5,3k
    • 6
    SuperJob.ru 95,84
    Компания
    Поделиться публикацией
    Комментарии 6
    • 0
      У меня немного вопросов к докладу Сергея:
      1. Почему не стали использовать VIPER? Из-за любви к MVVM и реактиву?
      2. Могут ли переиспользоваться фасады? Или что вы делаете, если в нескольких фасадах есть общая логика? Или фасады не относятся к определенному модулю?
      3. Как фасад определяет, к какому адаптеру обращаться? Он хранит какое-то состояние?
      4. Тестируете ли вы инъекции?
      5. Почему между VM и View связь через делегирование?
      6. Какой объект в вашей архитектуре отвечает за навигацию?
      7. Если UI одного экрана сложный, разбиваете ли вы его на сабмодули? Если да, то как?
      8. Что вы используете для работы с таблицами?
      9. Примеры в презентации были написаны на Objective-C. Используете ли вы эту архитектуру в Swift проекте? Если да, то как собираете модули?
      • 0
        1. Когда мы начали менять нашу архитектуру, мы смотрели на VIPER, но некоторые аспекты нам показались лишними. Наличие небольшого опыта с MVVM, который хорошо ложился с использованием в связке с ReactiveCocoa, определил направление.
        2. Все фасады наследуются от корневого, который содержит общую логику. Фасады разделены по принципу сущностей данных, которые он может получать, например — фасад резюме, фасад вакансий и т.д.
        3. Аналогично разделению фасадов, адаптеры делятся образом и соответственно фасад резюме будет запрашивать данные у адаптера резюме.
        4. Нет, инъекции мы не тестируем, упор был больше на бизнес-логику.
        5. На самом деле можно было так же использовать сигналы как и на предыдущих слоях.
        6. Тут я возможно немного слукавил, когда говорил, про принцип единственной ответственности. ViewModel c помощью делегата передает на слой View информацию о навигации, то есть ViewModel выполняет чуточку больше :) есть желание избавить ее от этой ответственности.
        7. Все несколько проще, для данного случая мы выносим в категории модуля логику.
        8. Немного не понял вопрос, можешь уточнить?
        9. Что касается приложения на swift (производственный календарь), оно по своей структуре простое и оно написано в MVC.
        • 0
          • По 3 вопросу — а если фасад использует несколько адаптеров, как он понимает, к какому обращаться?, к какому обращаться?
          • По 8 вопросу — я увидел на слайдах кастомные протокол для секции таблицы. Используете ли вы какое-то стороннее или свое решение для таблиц, чтобы избежать огромных свичей и if-else конструкций и методах delegate/datasource таблицы?
          • 0
            3. Если вернуться к примеру с авторизованным/неавторизованным пользователем, то фасад вакансий, на основе данных из фасада профиля, узнает статус пользователя и дальше if/else выбор адаптеров. Решили не усложнять данный момент механизмами состояний, и в то же время решение не мешает тестируемости кода.
            8. Тут ты подметил абсолютно точно на тему switch, в некоторых местах громоздо выглядит, пока не нашли решения. Сталкивался ли ты с подобным и как решал?
            • 0

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

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

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

      Самое читаемое