Swift *

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

Большинству iOS разработчиков рано или поздно становится тесно в мире iOS SDK. И причина, отнюдь, не в том, что у IOS недостаточно возможностей для серьезной разработки, а в том, что большинство современных серьезных приложений имеет клиент -серверную архитектуру, но разработчикам iOS оказывается доступен только Клиентский мир. Серверная разработка отдана на откуп серверным оленям программистам, которые, весьма ревностно относятся к требованиям мобильных разработчиков что-то изменить в API. Не добавляет оптимизма тот факт, что для реализации простейшего API приходится изучать другой язык программирования, со своими парадигмами и нюансами. Даже для того чтоб обкатать какую-нибудь пилотную идею приходится либо привлекать людей со стороны, либо погружаться в мир чужеродных грез (PHP, Pyton, Ruby, C#). Все ли так плохо в стане Objectove-C / Swift? Оказалось, что совсем нет. Немного погуглив на предмет серверной разработки я наткнулся на довольно любопытное начинание, претендующее на то, чтоб стать реальным кросс-платформенным решением — т. е. работающим одинаково хорошо как в среде OSX, так и *nix систем (про Windows не говорю, там С# вряд ли кто подвинет — слишком много вкусностей).

Perfect — как заявляют создатели проекта — Идеальный веб-сервер и инструментарий для разработчиков, использующих Swift язык программирования для создания приложений и других служб REST. Понятно, что «Идеальный» — это не более чем игра слов, но вместе с тем, после знакомства с предлагаемым решеним начинаешь склоняться к тому, что толика правды в этом утверждении есть.

В «прессе» пробегали статьи о том, что на подходе новый язык программирования, который может стать промышленным стандартом с легкой подачи Apple. Язык, который базируется на продвигаемом в массы Swift. Как правило, статьи об этом вызывали больше вопросов, и еще больше раздражения у тех, кому надоело все переучивать (Swift сам по себе довольно быстро меняется). Однако, углубившись в изучение вопроса, становится понятным, что все намного лучше чем, кажется.

Perfect — это не новый язык, серверной разработки. Perfect это серверное окружение, которое позволяет создавать REST API сервисы используя исключительно Swift последней реализации (на момент написания статьи Swift 2.2) Там нет ничего, выходящего за рамки того, что приходится делать ежедневно клиентским разработчикам.

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

В основном для проработки материала используются стандартные примеры из RxExample, но для прояснения отдельных моментов была создана песочница UIExplanation и дополнительный пример в RxExample
Весь код можно найти здесь github.com/sparklone/RxSwift

При работе с UI элементами в Rx есть основные потребности:
1) понять какие подводные камни нас ожидают в принципе и зачем нужен Driver
2) научиться делать привязку UI к Observable, чтобы элементы Observable меняли состояние свойства/свойств UI элемента. Это решается с помощью UIBindingObserver
3) научиться переводить паттерн target-action на рельсы Rx. Это делается с помощью ControlEvent
4) сделать двустороннюю привязку к свойствам UI элемента. Это делается с помощью ControlProperty
5) т.к. зачастую у UI элементов delegate/dataSource предполагаются в единственном числе, — ввели класс DelegateProxy, который позволяет одновременно использовать как обычный делегат, так и Rx последовательности.

Рассмотрим каждую потребность отдельно

Пост основан на статье medium.com/@RobertGummesson/regarding-swift-build-time-optimizations-fc92cdd91e31 + небольшие изменения/дополнения, то есть текст идет от моего лица, не третьего.

Всем знакома ситуация после изменения файла(ов) или просто переоткрытия проекта:






Нужно сказать, что какой-то особой проблемы с компиляцией я не замечал когда писал на Objective-C, но всё изменилось с приходом в массы swift. Я частично отвечал за CI сервер по сборке iOS проектов. Так вот, проекты на swift собирались невыносимо медленно. Еще разработчики любят тащить поды (cocoapods зависимости) на каждый чих в свои swift проекты, иногда, в безумном количестве. Так вот, компиляция всей этой смеси могла продолжаться несколько минут, хотя сам проект состоял буквально из пары десятков классов. Ну ладно, как бы ясно, язык новый, на этапе компиляции происходит намного больше проверок, чем в том же ObjC, глупо ожидать, что она будет работать быстрее (да, swift это строго типизированный язык и всё должно быть максимально явно объявлено (как в Java, например), в отличии от ObjC, где не всё так строго). Разработчики swift с каждым релизом обещают в x раз ускорения скорости компиляции. Ну вроде, действительно, сборка 2.0 и уже потом 2.2 стала работать быстрее, вот вот на носу уже 3.0 версия (конец года).

Компилятор компилятором, но оказывается, что время сборки проекта можно катастрофически увеличить буквально несколькими строчками кода. Часть примеров взято из вышеупомянутой статьи, часть самописные (не поверил автору и хотелось самому проверить). Время замерял через

time swiftc -Onone file.swift

Существуют два непримиримых лагеря разработчиков программного обеспечения: первый — утверждает, что чем больше крешится приложение, тем лучше оно работает. Второй — что программист достаточно умен, чтоб обработать любую нештатную ситуацию. Характерной особенностью первых является обилие директив Asset в кода, вторые же, даже операции сложения помещают в блок try — catch. Причем, оба лагеря называют такого рода подход «Программированием по контракту». Аргументы первых сводятся к статье в википедии, аргументы вторых — к книге «Почувствуй класс» Бертрана Мейера.

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

Стэнфордский курс «Developing iOS 9 Apps with Swift» теперь доступен на iTunes. Это долгожданное обновление предыдущего курса по iOS 8 и Swift.
Для того, чтобы воспользоваться этим контентом, вам нужно иметь только Mac — Macbook Pro, MacBook Air, iMac. Все программное обеспечение — бесплатное.

Этот курс в течение 10 недель читает профессор Пол Хегэрти. Он не только высвечивает множество нюансов операционной системы iOS и языка программирования Swift, которые не так-то легко найти в документации, но и снабжает вас приемами программирования на iOS, которые вы не найдете ни в одной книге (может быть, на WWDC 2011, 2012, 2013, 2014, 2015). Он многократно сократит ваш путь изучения. Реально, он — гений в преподавании программирования на iOS.

Представим себе экран обычного мобильного приложения с уже заполненным списком ячеек. С сервера приходит другой список. Нужно посчитать разницу между ними (что добавилось/удалилось) и проанимировать UICollectionView.

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

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

Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

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

Если вы когда – либо интересовались фреймворком ReactiveCocoa, то заметили, что есть небольшое количество постов на тему реактивного программирования и фреймворка ReactiveCocoa, такие как Знакомство с ReactiveCocoa, или Лучший мир с ReactiveCocoa. До сегодняшнего дня, все эти посты были на тему ReactiveCocoa 2 версий, которая была написана на и для Objective-C. Сейчас все больше набирает популярность язык Swift, разработчики ReactiveCocoa усиленно работают над новой версией, которая будет написана на языке Swift и будет иметь некоторые функциональные особенности, которые являются фундаментальными для данного языка.

Я подозреваю, что многие из вас, как и я, с огромным желанием оставили Objective-C и перешли на Swift. Если вы хотели бы использовать ReactiveCocoa с новым языком, я вам настоятельно рекомендую попробовать использовать новую версию ReactiveCocoa. И я уверен, что наше сообщество получит огромную пользу от вклада, сделанного вами. С другой стороны, если вы работаете над большими бизнес приложениями в продакшн для определенного заказчика, я должен вам сказать – не делайте этого или хорошенько подумайте перед тем как использовать его. Но об этом мы поговорим дальше, если кого заинтересовал — прошу под кат.

В среду, 30 марта, состоялась конференция Rambler.iOS #6 (плейлист), которую мы анонсировали ранее. Шестой митап, проводимый нашим iOS-отделом, стал юбилейным, ведь именно год назад мы провели первую подобную встречу.

Привет, Хабр!

На прошлой неделе вышел AppCode 2016.1. Изначально мы анонсировали его как 3.4, но потом совместно с другими десктопными продуктами JetBrains перешли на новую схему версионирования и теперь будем использовать ее.



С момента выпуска версии 3.3 прошло еще два минорных релиза, в которых появилось много полезного (например, Evaluate Expression и Set Value для отладчика в Swift). В 2016.1 мы в основном продолжали работать над поддержкой Swift — и вот что получилось.

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

Rust и Swift

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

Предыстория

Летом 2015 года я начал изучать Rust. Затем, в сентябре 2015, я взялся за Swift. На первый взгляд, сходство между двумя языками очевидно, и они достигли стабильной версии примерно в одно время: релиз Rust 1.0 состоялся в мае 2015, а релиз Swift 2.0 (который фактически похож на 1.0, поскольку 1.0 служил публичной бетой) — в июне 2015. Оба вдохновлялись такими языками, как Haskell, в то же время сохраняя С-подобный (на самом деле, конечно, ALGOL-подобный) синтаксис, более привычный многим разработчикам, на которых ориентированы эти языки.

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

Мартовский вечер,
Расцветает сакура,
Быть Rambler.iOS.

Пришла весна, и мы, команда iOS-разработки холдинга Rambler&Co, с удовольствием анонсируем следующую конференцию — Rambler.iOS 6. Конференция состоится 30 марта в нашем офисе на Даниловской мануфактуре.

Я писал про KTV, но одно дело — придумать что-то непонятное, другое — попробовать это использовать. Помимо стилевой системы S2 я планирую использовать KTV для работы с сервером вместо JSON. Планов завоевать мир у меня нет, но разобраться, удобнее получилось или нет, хочется. Для того, чтобы общаться было легко, нужно уметь парсить объекты из ktv-файлов, и сериализовывать обратно в них же.

Swift, для которого я это пишу, в настоящий момент (Swift 2.x), не предназначен для динамического парсинга совсем, никак, вообще. Поэтому пришлось придумать что-то немного странное и нестандартное. После чего это странное и нестандартное нужно было реализовать.

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

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

Анонс мероприятия Apple, 3D графика без OpenGL, как использовать UILayoutGuide из кода и война с AdBlock — об этом и не только рассказывает подборка свежих статей в 57 выпуске Digest MBLTdev.

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

Это вторая часть обучающей статьи, связанной с изучением адаптивного поведения Split View Controller и Popover в iOS 9 на iPad и на iPhone, которое стало возможным благодаря концепции Size Classes. Обучение состоит в создания на Swift практических приложений, работающих с сервером Flickr.com, который является облачным сервисом для хранения фотографий.

В первой части перечислены пять интересных с точки зрения разработчика случаев применения адаптивного Split View Controller и Popover, которые отличаются сложностью Master. Detail везде один и тот же — единственный Image View Controller, вставленный в Navigation Controller и призванный показывать изображение фотографии:

1. Классический вариант: один элемент в Master, вставленный в Navigation Controller, (часто это Table View Controller)

2. Множество Table View Controller элементов, вставленных в Navigation Controller

3. Tab Bar Controller в качестве Master

4. Случай разных UI и разных пользовательских классов для приборов с разными Size Classes здесь не рассматривается, но идею можно посмотреть в “Адаптивный интерфейс с двумя storyboards для iOS 9”.

5. Адаптивный Popover

В первой части осуществлялось построение базового экспериментального приложения на Swift, которое было распространено на случаи 1-2. В этой статье мы будем дальше усложнять наше экспериментальное приложение и распространим его на случаи 3 и 5. Код для всех вариантов можно найти на Github.

С незапамятных времен Split View Controller и Popover в iOS были доступны только на iPad.
Начиная с iOS 8, они теперь работают и на iPad, и на iPhone, благодаря концепции Size Classes и их адаптивному поведению. Однако автоматическая адаптация, предложенная Apple «из коробки», чаще всего нас не устраивает и приходится писать небольшой дополнительный код, используя методы делегатов UISplitViewControllerDelegate и UIPopoverPresentationControllerDelegate. В данной статье мы будем исследовать адаптивные способности Split View Controller и Popover на примере очень простых практических приложений, работающих с сервером Flickr.com, представляющим собой облачный сервис для хранения фотографий. Сама по себе эта задача имеет большой практический смысл, так как является часто встречающимся случаем, когда данные считываются с некоторого сервера и представляются затем ввиде связанных таблиц и изображений. Попутно мы будем демонстрировать “вживую” такие синтаксические конструкции Swift, как вычисляемые свойства c {get} и {set}, наблюдатели свойств didSet{}, функции высшего порядка map, flatMap, filter, вывод типа из контекста и перегрузку (overload) функций, совместное использование Swift и Objective-C кода, работу со структурами struct, использование хранилища NSUserDefaults и т.д. Но все же в этой статье акцент делается на более сложных конфигурациях адаптивных Split View Controller и Popover.
Впоследствие все приведенные в этой статье приложения вы сможете использовать в качестве шаблонов для разработки ваших приложений с похожими задачами.