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

Подписывайтесь на email рассылку, push notifications для Safari или RSS. Под катом — выпуск этой недели.

8 июня на проводимом ежегодно WWDC компания Apple анонсировала новую версию языка Swift 2.0



Как написано в блоге Swift и на странице для разработчиков на Swift, новая версия получила более высокую производительность, новое API обработки ошибок, улучшения синтаксиса языка, а также функцию проверки доступности функций Swift для целевых ОС.

На мой взгляд, самое интересное – Apple открывает код Swift. Да, Swift 2.0 — это Open Source язык программирования.

При проектировании iOS приложений со многими MVC приходится решать вопросы передачи информации от одного MVC к другому как в прямом, так и в обратном направлении. Передача информации в прямом направлении при переходе от одного MVC к последующему осуществляется обычно установкой Mодели того MVC, куда мы переходим, а вот передача информации «назад» из текущего MVC в предшествующий осуществляется с помощью делегирования как в Objective-C, так и в Swift.

Кроме того, делегирование используется внутри одного MVC между View и Controller для их «слепого взаимодействия».

Дело в том, что Views — слишком обощенные (generic) стандартизованные строительные блоки, они не могут что-то знать ни о классе, ни о Controller, который их использует. Views не могут владеть своими собственными данными, данные принадлежат Controller. В действительности, данные могут находиться в Mодели, но Controller является ответственным за их предоставление. Тогда как же  View может общаться с Controller? С помощью делегирования.

Нужно выполнить 6 шагов, чтобы внедрить делегирование во взаимодействие View и Controller:

1. Создаем протокол делегирования (определяем то, о чем View хочет, чтобы Controller позаботился)
2. Создаем в View weak свойство delegate, типом которого будет протокол делегирования
3. Используем в View свойство delegate, чтобы получать данные/ делать вещи, которыми View  не может владеть или управлять
4. Controller объявляет, что он реализует протокол
5. Controller устанавливает self (самого себя) как делегата View путем установки свойства в пункте #2, приведенном выше
6. Реализуем протокол в Controller

Мы видим, что делегирование — не простой процесс.
Как в Swift, так и в Objective-C, процесс делегирования можно заменить использованием замыканий (блоков), принимая во внимание их способность захватывать любые переменные из окружающего контекста для внутреннего использования. Однако в Swift реализация этой идеи существенно упрощается и выглядит более лаконичной, так как  функции (замыкания) в Swift являются «гражданами первого сорта», то есть могут объявляться переменными и передаваться как параметры функций. Простота и абсолютная ясность кода в Swift позволят более широко использовать замыкания (closures), захватывающие контекст, для взаимодействия двух MVC или взаимодействия Controller и View без применения делегирования.

Я хочу показать использование захвата контекста замыканиями на двух примерах, взятых из стэнфордского курса 2015 «Developing iOS 8 Apps with Swift» (русский эквивалент находится на сайте «Разработка iOS+Swift+Objective-C приложений»).

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

Здравствуйте, уважаемые читатели.

Среди самых животрепещущих тем, которые поднимались на наших издательских советах в последние полгода, особое место занимает язык программирования Swift. При огромном интересе к нему со стороны западных разработчиков и при подлинном изобилии книг на эту тему язык пока кажется довольно сырым. Поэтому, прощупывая почву насчет востребованности нового языка, предлагаем познакомиться с постом великолепного Мэтта Нейбурга, автора книги «Programming iOS 8: Dive Deep into Views, View Controllers, and Frameworks». Автор подробно описывает перевод приложения на новый эппловский язык, убедительно доказывая: «глаза боятся — руки делают», а гибридная сборка Objective-C и Swift отнюдь не напоминает смесь французского с нижегородским.

Приятного прочтения и плодотворных экспериментов.

Приветствуем, Хаброжители!

Мы — компания «Центр информационных технологий», создаем инфраструктурные решения и высокотехнологичные программные продукты, поддерживающие глобальные государственные инициативы в Российской Федерации и странах Евразийского экономического союза.

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

Couchbase и Couchbase Lite

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

Использование «облаков» для синхронизации данных далеко не всегда позволительно, особенно если дело касается заказчиков высокого уровня, которые не допускают такого решения из соображений безопасности и требуют развёртывания всех компонентов системы in-house. В этой статье я расскажу о нашем опыте решения этой задачи с помощью связки полноценной серверной базы данных Couchbase и «облегчённой» мобильной базы данных Couchbase Lite.

Для разработчиков Apple Watch — не просто нашумевший гаджет. Теперь им приходится осваивать Watch Kit, чтобы создавать и адаптировать свои приложения для «умных» часов. По мере знакомства с этой технологией, конечно же, возникает множество вопросов.

Мы в компании Alconost перевели обширный FAQ по фреймворку WatchKit. Будем рады, если труд наших технических переводчиков окажется для вас полезным. Для некоторых вопросов четких решений пока нет: в таких случаях следует полагаться на здравый смысл, советы специалистов и обоснованные предположения. Эта технология все еще в значительной мере находится в разработке, а следовательно, может изменяться. Тем не менее, ответы на многие животрепещущие вопросы уже найдены. Приглашаем вас под кат!

Данная статья получилась из отчета программиста после «опыта» разработки небольшого приложения на новом языке Swift.

Дима занимается программированием почти два года и изучает языки самостоятельно. Документация, чужой код. На звание профессионала не претендует, но его опыт может быть полезен многим, кто подумывает начать кодить на Swift. Опыты, наблюдения и выводы. Приглашаем к дискуссии! Далее текст автора.

Эта публикация является конспектом соответствующего раздела замечательной книги «iOS 8 Programming Fundamentals with Swift» Matt Neuburg, O'Reilly, 2015. Статья, описывающая использование анонимных функций, может быть интересной новичкам или пригодится как шпаргалка для более продвинутых разработчиков.

Рассмотрим пример:

	func whatToAnimate() {//self.myButton является кнопкой в интерфейсе
		Self.myButton.frame.origin.y += 20
	}
	func whatToDoLater(finished:Bool) {
		printLn(“finished: \(finished)”)
	}
	UIView.animateWithDuration(
		0.4, animations: whatToAnimate, completion: whatToDoLater)

В этом участке кода есть некоторая странность. Я объявляю функции whatToAnimate и whatToDoLater только для того, чтобы передать эти функции на следующую строку кода. И действительно, имена этих функций мне больше ни для чего не нужны – ни имена, ни эти функции больше никогда не будут повторно использованы. Было бы хорошо передавать только тела этих функций, без необходимости декларации их имен.

Такие функции называются анонимными, они имеют право на существование и часто используются в Swift.

Добрый день, Хабровчане!

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

1. Книга для начинающих. Например такая
Swift for Beginners: Develop and Design

Доброго времени суток. Эта статья будет полезна тем, кто устал изо дня в день бороться с изменяемостью данных в интерфейсе, тем, кто еще не знает о существовании MVVM, и тем, кто сомневается, что данный паттерн можно успешно применять на практике при разработке iOS приложений. Заинтересовавшихся прошу под кат.

Как-то раз я спросил у своей жены:
— У нас же нет планов на выходные?
— Вроде нет, — ответила она.
— Тогда я еще разок поковыряю этот Swift.
— Поковыряй.

И вот я поставил перед собой задачу, написать очень простую игрушку для iOS на Swift'е, не прибегая к какому-либо ^.*C.*$ (прошлый мой опыт ознакомления со Swift'ом закончился тем, что 80% проекта были написаны на Objective-C (который из-за моего С++'ного мышления, сократился до ближайшего известного мне (Objective-C)+2C-Objective = C)).

Задача

Дано: Одна картинка, какие-то соображения в голове.
Надо: Игра написанная до звонка будильника в понедельник.

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

Всем привет! Я — начинающий свифтер, то есть изучаю Swift без опыта ObjC. Недавно мы с компаньонами начали проект, требующий приложение под iOS. А еще у нас есть idée fixe: с нами непременно должен работать студент из Физтеха, а приложение должно быть написано на языке Swift. И вот, пока мы ищем физтеховцев и знакомимся с ними, я решил не терять время и параллельно начать своими силами пилить проект на Swift. Так я впервые открыл XCode.

Вдруг обнаружилось много знакомых, которые точно так же не имея опыта мобильной разработки, стали осваивать ее именно посредством Swift, а не ObjC. Кто-то из них подтолкнул меня поделиться опытом на Хабре.

Итак, вот топ пять «ловушек», своевременное понимание которых точно бы сэкономило мне время.

Я уже делился советами по разработке кастомной клавиатуры, а также опытом продвижения приложения до и сразу после релиза — статья. На этот раз хочу рассказать о процессе разработки и дать пару подсказок о том, что делать после загрузки приложения в App Store.

Мы запускаем 5-ую бесплатную школу iOS-разработчиков! Курс предназначен для программистов, имеющих базовое знание языка Swift, ООП. Для занятий необходимо наличие Mac или Win+vmware.



Все, что вам надо сделать — это скачать со страницы школы тестовое задание, выполнить его и прислать нам до 10:00 2 марта. Участники, прошедшие отбор, будут известны не позднее 13 марта.

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

Предисловие переводчика.

Отмечая окончание 2014 года, известная Swift группа SLUG из Сан-Франциско выбрала 5 наиболее популярных Swift видео за 2014 с организованных ею встреч. И среди них оказалось выступление Chris Eidhof «Функциональное программирование в Swift».
Сейчас Chris Eidhof — известная личность в Swift сообществе, он — автор недавно вышедшей книги «Functional programming in Swift», один из создателей журнала objc.io, организатор конференции «Functional Swift Conference», прошедшей 6-го декабря в Бруклине и будущей конференции UIKonf.
Но я открыла его, когда он, один из первых, опубликовал очень простую элегантную статью об эффективности функционального подхода в Swift к JSON парсингу.
В этой статье нет недоступных для понимания концепций, никаких мистических математических «химер» типа «Монада, Функтор, Аппликативный функтор», на которых Haskell программисты клянутся перед оставшимся миром, закатывая глаза.
Там нет и таких нововведений Swift, как дженерики (generics) и «вывод типа» (type inference).
Если вы хотите плавно «въехать» в функциональное программирование в Swift, то вы должны познакомиться с его статьей «Parsing JSON in Swift» и выступлением на SLUG «Functional Programming in Swift».

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

Functional Reactive Programming

Благодаря фреймворку ReactiveCocoa, новая парадигма программирования все чаще используется среди iOS разработчиков.

Отказоустойчивость, отзывчивость, ориентированность на события и масштабируемость — вот четыре принципа реактивного программирования. Подробности можете узнать в реактивном манифесте (перевод на Хабре).

Для себя я выделил следующие преимущества реактивного подхода:

• loose coupling — потоки события позволяют уменьшить связанность между различными частями кода;
• explicit state — состояние программы определяется набором событий, и поэтому им становится легко управлять.

В качестве альтернативы реактивному подходу рекомендую посмотреть на Futures. Есть как минимум два интересных фреймворка: PromiseKit и CollapsingFutures

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

У нас для вас отличные новости — в новой версии нашей IDE для разработчиков под iOS/OS X — AppCode 3.1 — появилась долгожданная поддержка языка Swift, и даже Rename refactoring для кода на этом языке.

Несмотря на то, что в Objective-C 2.0 присутствуют замыкания (известные как блоки), ранее эппловский API использовал их неохотно. Возможно, отчасти поэтому многие программисты под iOS с удовольствием эксплуатировали сторонние библиотеки, вроде AFNetworking, где блоки применяются повсеместно. С выходом Swift, а также добавлением новой функциональности в API, работать с замыканиями стало чрезвычайно удобно. Давайте рассмотрим, какими особенностями обладает их синтаксис в Swift, и какие трюки можно с ними «вытворять».



Продвигаться будем от простого к сложному, от скучного к веселому. Заранее приношу извинения за обильное использование мантр «функция», «параметр» и «Double», но из песни слов не выкинешь.

Это перевод статьи Tony DiPasquale «Efficient JSON in Swift with Functional Concepts».

Предисловие переводчика

Передо мной была поставлена задача: закачать данные в формате JSON с Flickr.com о 100 топ местах, в которых сделаны фотографии на данный момент, в массив моделей:

Как писал Роб Напьер, мы не знаем Swift. И ничего страшного — на самом деле, это даже здорово: у нас есть возможность самим решать, каким этот молодой мир станет дальше. Мы можем (и должны) оглядываться на аналогичные языки в поисках идей, хотя множество практик хорошего тона — скорее предпочтения сообщества, нежели объективная истина. Судя по длинным и напряженным беседам в форумах разработчиков о том, когда и как лучше использовать опциональные типы, я все больше предпочитаю с ними вообще не связываться.

Опциональные типы — такой же инструмент, как и все остальные. По закрепившейся на Objective C привычке, мы используем nil где ни попадя — в качестве аргумента, значения по умолчанию, логического значения и так далее. С помощью приятного синтаксиса для опциональных типов, который дает Swift, можно превратить в опциональный тип практически что угодно, и работать с ним почти так же. Поскольку опциональные типы распаковываются неявно, все еще проще: можно использовать их и даже не догадываться об этом. Но возникает вопрос — а разумно ли это?

Я бы сказал, что нет. Даже кажущаяся легкость использования обманчива — Swift был разработан как язык без поддержки nil, а концепция «отсутствия значения» добавлена в виде перечисления. nil не является объектом первого рода. Более того, работа с несколькими значениями опционального типа в одном методе зачастую приводит к такому коду, на который без слез не взглянешь. Когда что-то было настолько фундаментальным в Objective C, а теперь изгоняется из списка объектов первого рода, интересно разобраться в причинах.