We are familiar and well know all Swift changes between 2.0 and 2.1. And also difference between Xcode 6 and 7. But there are some changes between iOS 8 and 9.1 that we can’t ignore. Because... apps became malfunctioned.

CanOpenURL

Most significant and despicable difference is between iOS 9 and 9.1. The canOpenURL does not work as expected anymore. All checks for that are failing at this time.

if app.canOpenURL(url) {
   app.openURL(url)
}

To understand what happened, see this post: Quick Take on iOS 9 URL Scheme Changes.

But TL;DR is that you must explicitly set an array of URL schemes that your app may open. So add a key called LSApplicationQueriesSchemes to your Info.plist. And the value of this key is an array of URL schemes you want to be opened. Like: twitter, fb, instagram, vk.

More generally, xml for this in Info.plist should look like:

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>twitter</string>
    <string>instagram</string>
    <string>comgooglemaps</string>
    <string>yandexnavi</string>
</array>

3D Touch

Next big thing is how to fast implement quick actions for 3D-touching app icon.

As I have no 3D Touch devices (have just Force Touch one) and have no expertise in there, I just provide a link where it described very well: Add 3D Touch quick actions tutorial.

See also:

• Is your app iOS 9 ready? — Medium.
• iOS 9 not opening URL scheme — Stack Overflow
• Quick Take on iOS 9 URL Scheme Changes
• Add 3D Touch quick actions tutorial.

Let’s code!

Некоторые знакомые менеджеры и другие ребята спрашивают меня: что такое автолэйауты в Икскоде? Задают вопросы, типа: «можно сказать что много аутолэйаутов?», «сложный аутолэйайт?», «бывает сложная работа по ним или легкая, например?»

Я пытался уклончиво сказать, что это «распорки», и отправить в документацию Эпла с картинками. Но этого не хватило. Попробую описать тут.

Короче, автолэйаут — это одна из концепций построения интерфейса Айос-приложений.

TL;DR

Автолэйаут появился в Икскоде с версии 4.5 и в Айос-6. Автолэйаут можно выключить, и пытаться строить интерфейс без него. В простых интерфейсах это прокатывает, но в сложных — нет. (Хотя, некоторые выключают и в сложных.)

(См. также мой доклад про Size Classes.)

Так вот, когда автолэйаут включен, то интерфейс строится с помощью «распорок» (constraints), которые контролируют поведение при растягивании и сжимании.

Справа написано, какие 7 распорок установлены на простую надпись (это много), а слева почти все показаны:

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

Решил познакомиться с test-driven development. И, заодно, разобраться с XCTest Framework. Там много всего интересного, оказывается.

Например, Эпл пишет: Test-driven development is a first-class workflow within Xcode. То есть, в Икскоде четко соблюдается философия TDD, сформулированная Кентом Беком: те же утверждения, сравнения и т. д.

В Свифте для проверки утверждений тестирования используются примерно такие методы:

func XCTAssert(expression: @autoclosure () -> Bool, message: String, ...)

@autoclosure, которое я перевел как автозамыкание, — очень интересная штука. (В ранних бетах Икскоды-6 называлась @auto_closure.) Автозамыкание принимает ноль аргументов, и возвращает что угодно.

Если обычно замыкания в Свифте вызвываются так:

someFunc(doLater: (x: 2, y: 12, z: 85) -> Bool {
  // some code
}, lastPart: "06")

То автозамыкания — так:

someFunc(doLater(), lastPart: "0")

Применительно к ассертам в юнит-тестах, соответственно, так:

XCTAssert(colorMatch(), "rgb hex does not work")

Все красиво и ненавязчиво :) Что же нам еще почитать об этом?

Про автозамыкания:

• developer.apple.com/swift/blog;
• Мэттт Томпсон: XCTest​Case.

Про юнит-тестирование:

• Эпл-доки;
• Мэттт Томпсон: Unit Testing;
• какой-то интересный сайт: iOSUnitTesting.com;
• и лекции Яндекса, конечно.

Сегодня появилась видеозапись моего доклада на августовской встрече разработчиков CocoaHeads Moscow. Ура!

Хочу еще немного добавить про особенности сайз-классов. В докладе я немного упомянул про специальные отступы от границ экрана. Это Leading Margin и Trailing Margin по бокам, и Top и Bottom Layout Guides сверху и снизу.

Leading Margin и Trailing Margin по бокам, и Top и Bottom Layout Guides сверху и снизу.

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

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

Кроме того, интересно, что Leading и Trailing Margin меняются местами, если на устройстве установлен какой-нибудь язык, который пишется справа налево (RTL). Для обычных LTR-языков они находятся слева и справа, соответственно.

В конце августа, на ежемесячной встрече разработчиков приложений для iOS и OS X CocoaHeads Moscow, я рассказывал про новую концепцию Size Classes, представленную Эплом на WWDC-2014. Это совершенно новый способ построения адаптивных интерфейсов для айос-дивайсов. Немного коснулся интересных тонкостей о том, как их использовать в приложениях на айос-8, и как их бекпортить на айос-6.

Марат Сайтаков @m4rr о Size Classes. #cocoaHeads pic.twitter.com/3xVmqeFchP

— CocoaHeads Moscow (@CocoaHeadsMSK) August 29, 2014

Встреча традиционно проходила в офисе Мейл-ру. Там точно была видеозапись и, кажется, даже трансляция. У меня пока этой записи нет, но вот слайды с презентации:

Очень интересно, какие вопросы появятся у читателей моего блога. Буду рад ответить :)

На этой встрече также докладывал Михаил Байнов про массивы и структуры ANSI C/C99, и Саша Зимин рассказывал материальный дизайн кнопок из нового Андроида-Л и показывал как это сделать на Свифте; с его презентации также доступны слайды.

Upd. Видеозапись доклада: http://blog.m4rr.ru/all/size-classes-addition/

Мы с другом сейчас работаем над одним очень интересным проектом, который выйдет осенью, вместе с Айос-8. И в этом проекте появилась задача: показать некоторые стандартные юникодные значки. Но, оказывается, если эти символы добавить в UILabel, то айось заменит их на картинки-эмоджи. Это, конечно, круто, но не то, что нам нужно.

Emoji UILabel

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

A variation sequence, which always consists of a base character followed by the variation selector, may be specified as part of the Unicode Standard. That sequence is referred to as a variant of the base character. The variation selector affects only the appearance of the base character,* and only in the variation sequences defined in this Standard. The variation selector is not used as a general code extension mechanism.
Источники: раз, два.

Итак, variation sequence — последовательность, которая состоит из базисного символа и следующего за ним модификатора (variation selector). Такая последовательность ссылается на вариацию базисного символа. Модификатор влияет только на внешний вид символа.

Таким образом, юникодный символ, для которого существует эмоджи-картинка, мапится в эмоджи. Но существует такой модификатор U+fe0e, который, будучи добавленным к юникодному символу форсит выбор не-эмоджи варианта символа.

Короче, можем написать любой символ (U+2709 — для конверта), и к нему U+fe0e:

// Swift:
label.text = "Привет, посылаю тебе ✉︎\u{fe0e} не из этой страны"
// Objective-C:
label.text = @"Привет, посылаю тебе \U00002709\U0000FE0E не из этой страны";

И получить то, что нужно:

Non-emoji UILabel

(Кстати, есть еще кодировка эмотиконов Softbank, которая используется в смс. В опенсорсе на сайте Эпла есть таблица их мапинга в эмоджи и обратно: Any_SoftbankSMS.txt)

Иногда в интерфейсе айос-приложений нужно расставить кнопки друг к другу, чтобы ширина у всех автоматически стала одинаковой, как, например, в старом добром Тотал-командере:

Кнопки Тотал-коммандера

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

С появлением Size Classes в iOS 8, становится понятно, что любой другой способ получается слишком громоздким. Поэтому, задача расставления кнопок (UIButton или вообще любой UIView) сводится к правильной расстановке констрейнтов автолейаута.

Решение, вроде, простое на первый взгляд: нужно в Интерфейс-билдере сделать все кнопки одного размера, поставить их друг к другу, и привязать левую границу каждой кнопки к правой границе предыдущей кнопки. А левую и правую границы крайних — привязать к супервьюхе. И с первого подхода выходит вот такая фигня:

Damn auto layout!

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

Good auto layout.

Ура!

В этом году даб-дабе (WWDC 14), как все уже знают, Эпл представила новый язык разработки — Свифт.

Свифт — современный и клевый язык для работы с Какао и Какао-тач (Cocoa, Cocoa Touch). И, так как этот блог был про всякие классные штуки в ОбджСи, то теперь это одновременно и блог про всякие классные штуки в Свифте! :)

Кстати, в одной из сессий на даб-дабе рассказали, что ОбджСи все равно останется важным:

И обратите внимание на колонку «Хорошие блоги» слева. Там сейчас про ОбджСи. Но скоро все поменяется :)

My projects become broken on building with following error:

error: PCH file built from a different branch clang-425.0.27 than the compiler clang-425.0.28 xcode 4.6.2

Solution: clean the project via menu Product → Clean.

via