Автор: Роман Ивченко, iOS developer DataArt.

Введение

Наверняка каждый, кто хоть раз занимался поиском готового решения для обмена сообщениями, файлами, стримами между iOS-устройствами без использования серверной части, слышал о фреймворке Multipeer Connectivity, выпущенном в iOS 7.

Вцелом это один из самых инновационных фреймворков, выпущенных в 7-й версии системы. Он должен был заменить слегка устаревший CoreBluetooth.

Чтобы познать всю мощь и силу Multipeer Connectivity, мы попробовали обкатать его в нашем R&D-проекте, задача которого весьма проста — шаринг презентаций и синхронизация переключения слайдов между устройствами слушателей и устройством докладчика на конференциях, в учебных аудиториях и т. д.

Краткий обзор

Для реализации нашей задачи фреймворк, на первый взгляд, очень хорошо вписывался в архитектуру приложения. Условно у нас есть всего два типа пользователей — докладчик и слушатель. Multipeer Connectivity как раз предоставляет необходимые классы для имплементации функционала каждого типа пользователя.

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

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

С версии Xcode 7 этой фичей стало более-менее возможно пользоваться, поэтому мне захотелось проверить её возможности.

Почитать про IBDesignable/IBInspectable можно тут и тут.

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

В статье Objective-C Runtime. Теория и практическое применение этот процесс хорошо описан. Но с переходом на Swift появляются некоторые нюансы.

Корпорация IBM уже довольно давно сотрудничает с Apple. Взаимодействие двух компаний касается многих сфер, и одна из них — программирование. Причем программирование на Swift. Дело в том, что корпорация Apple сделала исходный код языка программирования Swift открытым. А в Mobile Innovation Lab от IBM создали специальную песочницу для разработчиков, которые хотели бы познакомиться со Swift.

Благодаря открытию кода, разработчики, которые создают приложения для iOS, OS X и watchOS, могут без проблем обходить существовавшие ранее ограничения, дополняя многие функции при необходимости. Apple для привлечения широкой аудитории опубликовала достаточно массивную библиотеку различной документации, которая позиционируется как пособие для начинающих программистов. Стоит отметить, что лицензируется Swift под лицензией Apache 2.0. Эта лицензия позволяет использовать программное обеспечение для собственных целей, и платить Apple не требуется.

Во вторник состоялся Rambler.iOS V, который мы анонсировали на Хабре ранее. Эксперимент с разбитием одной очень крупной темы на восемь связанных между собой докладов отлично состоялся — благодаря такой гранулированности докладчики смогли сосредоточиться именно на своем аспекте VIPER и подготовить действительно мощные выступления.

Автор: Игорь Литвиненко, Senior Mobile Developer.

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

Экскурс в историю

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

Мне очень понравился пример из книги «Думаем функционально» (или «Функциональное мышление»). Представьте, что вы лесоруб, и у вас есть самый большой топор в лесу, который позволяет вам быть самым лучшим и успешным лесорубом. Но потом вы читаете в каком-нибудь журнале заметку маркетолога о том, что сейчас придумали новую крайне эффективную и современную концепцию валки леса — при помощи бензопилы. Тогда вы заказываете себе бензопилу — вам ее доставляют, вы ее распаковываете, но не знаете, как она включается. Зато вы прекрасно знаете, как рубить лес топором. И вы берете бензопилу и пытаетесь ей рубить деревья так же, как обычно рубите топором. И, конечно же, у вас ничего не получается — вам ничего не остается, как снова вернуться к топору. Но потом к вам приходит сосед и объясняет, как заводить бензопилу — и вы наконец начинаете эффективно валить лес бензопилой.

Поводом для написания статьи стала публикация исходного кода языка Swift — мне стало интересно поближе познакомиться с ним. В глаза сразу же бросилась схожесть синтаксиса с другим молодым языком программирования под названием Rust, к тому же за схожими синтаксическими конструкциями просматривалась и схожая область применения этих языков. Оба языка имеют сильную статическую типизацию с локальным выводом типов, оба компилируются напрямую в машинный код. И тот и другой языки впитали в себя многие приемы из мира функционального программирования. И Swift и Rust имеют средства для запуска кода, написанного на C, что позволяет без труда писать обертки над огромным количеством библиотек. Оба языка рассматриваются как замена существующим системным языкам типа C, C++, ObjectiveC. Так что же в них общего, а что различается?

Существует бесчисленное множество статей относительно шаблона MVVM в iOS, но немного о RxSwift, и мало кто акцентирует внимание на том, как выглядит паттерн MVVM на практике и как его реализовать.



ReactiveX — библиотека для создания асинхронных и основанных на событии программ при помощи наблюдаемой последовательности.  — reactivex.io

RxSwift — относительно молодой фреймворк, который позволяет "реактивно программировать". Если Вы ничего о нем не знаете, тогда наведите справки, потому что функциональное реактивное программирование (FRP) набирает обороты, и не собирается останавливаться.

Мы строили, строили и наконец построили! Да здравствуем мы, ура!
Чебурашка

С развитием смартфонов в последние годы было разработано много инструментов, чтобы упростить жизнь разработчикам, обеспечив их максимальной производительностью и качеством. Занимать лидирующие позиций в App Store сегодня не простое задание. А научить ваше приложение масштабироваться еще сложнее. Когда приложением пользуются миллионы пользователей, вы должны следить за приложением и при необходимости выполнять все операции моментально. Поэтому одной из проблем, с которой сталкиваются многие разработчики, является Database. Она действительно вызывает сильную головную боль для каждого из нас, и я думаю, что сегодня у вас есть только два варианта: SQLite и Core Data. Я был большим поклонником Core Data и его способностью работать с записями и сохраняющимися данными, но я понял, что впустую трачу много времени, работая с ним при разработке приложений. Недавно, я столкнулся с Realm, новой лучшей заменой SQLite и Core Data.

Всем привет!
Нет, это не очередной пост в стиле «встречайте Swift и его возможности», а скорее краткий экскурс по практическому применению и тонкостях, где протоколо-ориентированность нового языка от Apple позволяет делать симпатичные и удобные вещи.

Язык Swift был представлен сообществу чуть больше года назад, что вызвало достаточно большой резонанс в среде разработчиков, при том не только iOS и OS X.

Но еще больший резонанс вызвал тот факт, что Apple пообещала открыть код компилятора и анонсировала возможность поддержки языка для операционных систем на базе linux.

Предистория

Под впечатлением статей про Sprite Kit и про GestureRecognizer возникла идея портировать простенькое приложение себе на телефон. А так как там достаточно часто используются структуры CGPoint, то озадачился изучением перегрузки операторов в Swift и подсмотрел тут.

Мы обратили внимание на активную работу по приложениям для watchOS выпускника нашего Акселератора, решили не отставать и поспособствовать активному использованию новой платформы.

Ниже представлен список фреймворков, библиотек и примеров приложений для watchOS.

С выходом iPhone 6s и iPhone 6s Plus компания Apple представила нам совершенно новый способ взаимодействия с нашими телефонами: жест сильного нажатия. Как вы знаете, эта функция уже доступна на Apple Watch и MacBook и в MacBook Pro под названием Force Touch. Это — буквально — добавило новое понятие к пользовательскому интерфейсу.

Если вы задаетесь вопросом, почему Force Touch было переименовано на 3D Touch для iPhone, тогда вы не одни такой. Вскоре после того, как Крейг Федериги (Craig Federighi), который также был явно озадачен названием, представил эту новую возможность, возникло много догадок. Чем не устроило название Force Touch? Слишком много шуток из Звездных войн?

Но есть разница! Очевидно, что Force Touch может распознать только сильное нажатие, тогда как функция 3D Touch более чувствительная и может выделить несколько уровней нажатий на основе того, как сильно вы нажимаете.

Как self и _cmd оказываются в методе? Как работает dispatch table и категории? Что такое мета-класс? Сколько на самом деле методов у ваших классов в ARC и в MRC? Как работает swizzling?
Интересно? Добро пожаловать под кат!

ВНИМАНИЕ!

Эта статья не рассчитана на начинающих разработчиков… Приношу свои извинения за то, что не рассматриваю многие моменты, которые должен знать Objective-C разработчик.

iOS разработчики это — фантастическое сообщество, которое предлагает широкий спектр доступных сторонних библиотек.

Если вы разрабатывали для этой платформы, тогда, скорее всего пользовались хотя бы одной из этих библиотек. Будь это AFNetworking, SDWebImage, SSKeychain или CocoaLumberjack, и уже должны понимать важность использования чужого кода, если вы не любите «изобретать свой велосипед».

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

CocoaPods широко используется в iOS сообществе, и даже Google использует его для распространения различных iOS SDK.

Хоть CocoaPods и потрясающее средство для управления зависимостями, есть и другие варианты. Carthage является одним из таких вариантов; это безжалостно простой менеджер зависимостей для Mac и iOS, созданный группой разработчиков из Github.

Это был первый менеджер зависимостей для работы с Swift; фактически, сам Carthage написан на Swift'e! Он использует исключительно динамические фреймворки вместо статических библиотек – это только способ распространения двоичных файлов Swift, которые поддерживаются в iOS 8 и выше.

Однажды я почти полностью отказался от мышки для навигации по Xcode и вполне этому рад. Следующий шаг — это отказ от визуальных средств управления отладчиком. Зачем? — Увеличиваем возможности, уменьшаем время дебага, тратим меньше калорий для перемещения тяжеленькой ручишки (нам калории нужны, чтобы головой работать) и тем самым провоцируем меньше туннельного синдрома.

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

Давно мы не публиковали новостей про AppCode, пора это исправить. К тому же у нас есть отличный повод — 2 ноября вышла новая версия нашей IDE для iOS/OS X.



Если в AppCode 3.2 мы упорно работали над “умными” возможностями для Swift (и многое успели реализовать), то в версии 3.3 все силы были брошены на поддержку новых языковых конструкций Swift 2.0 и Objective-C, анонсированных Apple в июне.

Поддержка Xcode

В конце августа мы пообещали, что постараемся как можно скорее реализовать поддержку Xcode 7 в AppCode. Часть необходимых изменений мы внесли в первой же EAP-версии, и продолжали работать над этой задачей в течение всей программы раннего доступа. Новый AppCode 3.3 официально совместим с Xcode 7/7.1, а вот поддержку Xcode 6.x на OS X 10.11 нам пришлось прекратить (почему — можно прочитать здесь).

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

tvOS поддерживает два типа приложений: TVML и традиционные.

Традиционные приложения — практически то же самое, что и приложения под iOS (UIKit, Storyboard);
TVML — фреймворк для создания клиент-серверных приложений. Вся логика, дизайн и данные находятся на удаленном сервере.