VIPER

Мы тут на работке потихоньку учим архитектуру VIPER. Поэтому, чтоб не терялись материалы, сложу их тут.

Первое с чего я начал было два видосика от Константина Кокорина:

Для закрепления небольшой пример построения master-detail приложения (от все того же Константина):

Конечно же книжка по VIPER от компании Rambler:
https://habrahabr.ru/company/rambler-co/blog/311248/

Хороший видос с презентацией по архитектуре:

И, самое главное — генератор модулей от того же Рамблера.

Реклама

Xcode: наверное, лучший способ работы со сторибордами.

Этот пост является вольным переводом статьи Xcode: A Better Way to Deal with Storyboards by Stan Ostrovskiy

Некоторые примеры кода в оригинальной статье устарели (ввиду выхода Swift 3) и в переводе были изменены.

Советы и рекомендации по работе с Interface Builder.

Apple серьезно улучшили Interface Builder в новом Xcode 8. Использование size classes стало более интуитивным, возможность масштабирования сториборда — очень удобной, а полное превью прям в Interface Builder — просто великолепным. Для тех у кого были сомнения насчет использования Interface Builder, это может стать хорошими плюсами.

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

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

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

В вашем проекте есть один файл main.storyboard, который выглядит вот так?

С точки зрения дизайнера, все хорошо: полностью видно UI и навигацию. И это именно то, для чего Interface Builder и был создан.

Но для разработчика это несет множество проблем:

  • Контроль версий: конфликты слияния сторибордов очень трудно решать, так что работа в отдельных сторибордах сделает жизнь вашей команды проще.
  • Файл сториборда становится объемным и в нем сложно ориентироваться. Как часто вы случайно меняли constraint кликом мышки не в том вью-контроллере?
  • Вам необходимо присваивать каждому вью-контроллеру свой storyboard ID и это может привести к ошибкам: вам нужно «хардкодить» этот ID каждый раз когда хотите использовать этот вью-контроллер в коде.

Как же связать различные сториборды в вашем проекте? Есть два способа.

  1. Используйте ссылки на сториборды (storyboard referencing), которые появились в Xcode 7.

  2. Связывайте сториборды непосредственно в коде.

О первом способе вы можете почитать детальнее здесь.

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

2. Используйте одни и те же имена для файла со сторибордом и для связанного класса контроллера (наследника UIViewController).

Это упростит правила именования, а также даст некоторые «плюшки» о которых поговорим в пункте 3.

3. Инициализируйте сториборд непосредственно в классе контроллера.

Когда дело доходит до инициализации вью-контроллера через сториборд, я часто вижу следующий код:

let storyboard = UIStoryboard(name: “Main”, bundle: nil)
let homeViewController = storyboard.instantiateViewController(withIdentifier: “HomeViewController”)

Немного «грязновато»: вам нужно назвать сториборд, вам нужен storyboard ID вью-контроллера, и вам необходимо использовать этот паттерн каждый раз, когда вы создаете HomeViewController.

Лучше перенести этот код в сам класс контроллера и использовать статический метод, чтоб инициализировать контроллер с помощью сториборда:

class HomeViewController: UIViewController { 
    static func storyboardInstance() -> HomeViewController? { 
        let storyboard = UIStoryboard(name: “HomeViewController”, bundle: nil)
        return storyboard.instantiateInitialViewController() as? HomeViewController    
    }
}

Если вы последуете предыдущему совету (одинаковые имена файлов), то можете избежать «харкода» имени сториборда и воспользоваться String(describing:):

let storyboard = UIStoryboard(name: String(describing: self), bundle: nil)

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

Это делает ваш код более читаемым и отказоустойчивым:

class HomeViewController: UIViewController {
    static func storyboardInstance() -> HomeViewController? { 
        let storyboard = UIStoryboard(name: String(describing: self), bundle: nil)
        return storyboard.instantiateInitialViewController() as? HomeViewController 
    }
}

Если вы хотите иметь доступ к вью-контроллеру через instantiateInitialViewController() убедитесь, что вы указали этот вью-контроллер как initialViewController в Interface Builder. Если у вас несколько вью-контроллеров на одном сториборде, вам придется использовать instantiateViewController(withIdentifier: _ )

Теперь, инициализация такого вью-контроллера займет одну строку:

let homeViewController = HomeViewController.storyboardInstance()

Просто и понятно, не так ли?

Вы можете использовать этот же подход для инициализации вью из nib:

class LoginView: UIView {
    static func nibInstance() -> LoginView? {
        let nib = Bundle.main.loadNibNamed(String(describing: self), owner: nil, options: nil)
        return nib?.first as? LoginView
    }
}
4. Не перегружайте свой проект переходами на сториборде.

У вас не будет переходов, если вы последуете совету из пункта 1. Но даже если у вас есть несколько вью-контроллеров в одном сториборде, использование переходов (segues) для навигации между ними — не очень хорошая идея:

  • Вам нужно дать имя каждому переходу (segue), что само по себе может привести к ошибкам. «Хардкодить» строки с именами — плохая практика.
  • Метод prepareForSegue будет просто нечитаем, когда вы будете работать в нем с несколькими segue, используя операторы ветвления if/else или switch.

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

@IBAction func didTapHomeButton(_ sender: AnyObject) {
    if let nextViewController = NextViewController.storyboardInstance() {
        // initialize all your class properties
        // nextViewController.property1 = … 
        // nextViewController.property2 = … 

        // either push or present the nextViewController,
        // depending on your navigation structure 
        // present(nextViewController, animated: true, completion: nil) 

        // or push  
        navigationController?.pushViewController(nextViewController, animated: true)
    }
}
5. Unwind segue? Не, не слышал.

Иногда навигация предполагает возврат пользователя к предыдущему экрану.

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

Начиная с iOS 7, Interface Builder дает вам возможность сделать «unwind» навигационного стэка.

Unwind segue позволяет вам указать возврат на предыдущий экран. Это звучит довольно просто, но на практике это требует некоторых дополнительных действий и только сбивает с толку разработчика:

  • Обычно, когда вы создаете действие для кнопки (action), Interface Builder создаст для вас код (IBAction). В этом же случае, ожидается, что код уже написан до того, как вы зажмете «Ctrl» и перетащите действие от вашей кнопки к «Exit».
  • Обычно когда вы создаете действие для кнопки, код этого действия создается в том же классе, которому и принадлежит кнопка. Для Unwind Segues, вам нужно писать код в классе того вью-контроллера, в который этот переход произойдет.
  • Метод prepareForUnwind будет иметь все те же недостатки, что и метод prepareForSegue (см. предыдущий пункт).

Каков же более простой способ?

Проще делать это в коде: вместо создания действия «unwind» для вашей кнопки, создайте обычный IBAction и используйте dismissViewController или popViewController (в зависимости от вашей навигации):

@IBAction func didTapBackButton(_ sender: AnyObject) { 
    // if you use navigation controller, just pop ViewController:
    if let nvc = navigationController {   
        nvc.popViewController(animated: true)
    } else {
        // otherwise, dismiss it
        dismiss(animated: true, completion: nil)
    }
}

На сегодня это все. Я надеюсь, вы найдете что-то полезное для себя.

От переводчика:

Благодаря методу описанному в этой статье, я очень сильно упростил работу со сторибордами в своем текущем проекте Zumme. Пока я работал над ним один — все было прекрасно, но как только появились другие разработчики — работа со сторибордом превратилась в настоящий ад. От отчаянья мы практически перешли к «банановому методу» (можно почитать здесь в разделе «Pass the banana»).

Конечно же, в идеале нужно будет рано или поздно прийти к VIPER. Но об этом будет уже другой пост. 🙂

Как отметить свои TODO, FIXME и ERROR в Xcode.

Этот пост является вольным переводом статьи How to highlight your TODOs, FIXMEs, & ERRORs in Xcode by Hector Matos

Это был самый обычный день: я писал код, устранял баги и вообще все было прекрасно. Именно тогда я написал блок кода, к которому нужно было вернуться позже. Это обычный случай, с которым вы тоже вероятно сталкивались: нужно было взаимодействовать с API который еще не был готов. Я знал общую структуру объекта, который получу по API, но я еще не мог протестировать работу с ним. Как и любой другой разработчик, я написал комментарий, который выглядит так:

В этот момент я хотел бы создать предупреждение в Xcode, такое же как мы привыкли делать в Objective-C с помощью директив компилятора:

Но увы, так не получилось и я загрустил.

Как человек действия, я сделал то, что и следовало: я действовал. Оказывается вы можете добавить run-скрипт, чтоб получить необходимый функционал.

RUN SCRIPT BUILD PHASES

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

Чтобы сделать это, перейдите в «Build Phases» своего проекта в Xcode, нажмите на «+» слева вверху и затем из выпадающего меню выберите «New Run Script Phase»:

Затем вы увидите новый раздел в котором можете написать bash-скрипт. Если вы уже эксперт по написанию Swift-скриптов после прочтения поста scripting in swift, вы можете просто положить файл со скриптом в корневой каталог проекта и вызвать его из своего нового run-скрипта.

# Отмечаем ваши TODO, FIXME и ERROR с помощью «родных» предупреждений Xcode

В тело вашего run-скрипта поместите вот этот замечательный код:

TAGS="TODO:|FIXME:"
find "${SRCROOT}" \( -name "*.h" -or -name "*.m" -or -name "*.swift" \) -print0 | xargs -0 egrep --with-filename --line-number --only-matching "($TAGS).*\$" | perl -p -e "s/($TAGS)/ warning: \$1/"

С этого момента вы будете видеть предупреждения когда поставите метку TODO: или FIXME: в комментарии! Посмотрите как работает эта магия:

Не будем останавливаться на достигнутом и исправим скрипт таким образом, чтобы подсвечивать ошибки используя //ERROR: в комментариях. Как вы знаете, бывают ситуации, когда мы хотим обратить особое внимание, выделив ошибку с помощью //ERROR:. Чтобы сделать это, измените ваш bash-скрипт вот так:

TAGS="TODO:|FIXME:"
ERRORTAG="ERROR:"
find "${SRCROOT}" \( -name "*.h" -or -name "*.m" -or -name "*.swift" \) -print0 | xargs -0 egrep --with-filename

Не знаю как вы, но я, наверное — самый забывчивый человек в мире. В конце дня у меня не всегда закончен текущий фрагмент кода и мне нравится использовать //ERROR: чтобы напомнить самому себе над чем работать завтра.

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

ЗАКЛЮЧЕНИЕ

В своей повседневной работе вы всегда столкнетесь с блоком кода, к которому нужно будет вернуться позже, но сейчас вы вынуждены поставить «заплатку» и двигаться дальше. К сожалению, даже простого //TODO:, //FIXME: или //ERROR: в комментарии, просто недостаточно. Вы удивитесь сколько людей забывают о своих //TODO:, //FIXME: и //ERROR: в проекте. Использование run-скрипта в этой ситуации — отличный способ, чтобы убедиться, что не упустите ничего в своем цикле разработки. Надеюсь это поможет!

Счастливого кодинга, товарищи ботаники!

П.С. Из комментариев к оригинальному посту извлечена еще одна модификация скрипта, на случай если вам все-таки нужно препятствовать сборке проекта при наличии пометок //ERROR: в коде:

TAGS="TODO:|FIXME:"
ERRORTAG="ERROR:"
OUTPUT=$(find "${SRCROOT}" \( -name "*.h" -or -name "*.m" -or -name "*.swift" \) -print0 | xargs -0 egrep --with-filename --line-number --only-matching "($TAGS).*\$|($ERRORTAG).*\$" | perl -p -e "s/($TAGS)/ warning: \$1/" | perl -p -e "s/($ERRORTAG)/ error: \$1/")
ECHO "$OUTPUT"

if [[ $OUTPUT == *" error: "* ]]
then
exit 1
fi

Уведомления в iOS 10

Как вы знаете, выход iOS 10 несет в себе наибольшее количество изменений и новых возможностей со времен выхода iOS 7. Одно из самых интересных новшеств — новый вид и новые возможности уведомлений (тех самых из Notification center).

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

Я лишь дам пару «гифок» для затравки, наслаждайтесь:

И, конечно же, ссылка на хабро-статью: Уведомления в iOS 10

JSON & Swift

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

Итак, первое что приходит в голову — воспользоваться библиотекой SwiftyJSON и радоваться жизни. Подключается и через CocoaPods, и через Carthage. Работать с ней просто и удобно, документация — прекрасна.

Но, как всегда, одного проверенного пути — недостаточно, поэтому обратил внимание еще на своих «любимчиков» Just Dev:

Ну и закончил исследование статьей на ХабреБыстрая работа с JSON в Swift. И именно благодаря ей, остановился на варианте — стандартного JSON Serialization (вариант из видео) — ведь в этом случае не нужно никаких сторонних библиотек, и все прекрасно работает.

Ну что ж, приложеньку написал, на GitHub выложил, жду ответа от рекрутера. 🙂

Какао-Макао.

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

Но какао в моей жизни осталось, оно просто приобрело другую форму.

Встречайте крайне необходимую вещь для любого iOS разработчика — CocoaPods.

CocoaPods — это отличный инструмент для использования сторонних библиотек в своем приложении. Причем работать с CocoaPods настолько просто, что даже ребенок разберется за 15 минут.

Изначально CocoaPods, конечно же, заточен под работу с Objective-C, но это ведь не значит, что и с языком Swift он не будет взаимодействовать (просто нужно добавить в проект bridge-файл, через который подключаются библиотеки).

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

Ну, и конечно, статья про CocoaPods на «Хабре»: CocоaPods — мощное средство в руках Objective-C разработчика

О паттернах.

Без паттернов в разработке никуда. Но сегодня уже не обязательно читать нудную «Банду четырех» (я честно пытался, но кроме слова «нудотина» никаким другим эту книгу охарактеризовать не могу).

Откуда же получить знания сегодня, причем в понятном и удобоваримом виде? Именно об этом сегодняшний пост.

Первая рекомендация: книга Андрея Будая «Дизайн-паттерны — просто, как двери». Простым и понятным языком всего на 90 страниц описаны основные паттерны проектирования, примеры из реальной жизни и примеры программного кода. Это лучшая книга по этой тематике, на которую я натыкался.

По теме iOS разработки есть интересные примеры реализаций паттернов на Swift. Тут на помощь приходит сообщество iOS Dev Course а если конкретнее, то вот эта серия видосов:

А на закуску — еще два, которые помогут прокачаться и в MVC, и в VIPER: