Для кого написана эта книга:

Книга предназначена для разработчиков, которые хотят углубить свои знания Objective-C, а также стремятся писать код, простой в сопровождении, эффективный и содержащий меньше ошибок.Даже если вы еще не являетесь разработчиком Objective-C, но у вас имеется опыт работы на других объектно-ориентированных языках (например, Java или C++), вы все равно узнаете много полезного. Впрочем, в таком случае неплохо заранее ознакомиться с синтаксисом Objective-C.

Какие темы рассматриваются в книге:

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

«Any magic, sufficiently analyzed is indistinguishable from technology.»

Артур Кларк
(эпиграф в официальной wiki проекта Typhoon Framework)

Цикл «Управляем зависимостями в iOS-приложениях правильно»

• Знакомство с Typhoon
• Устройство Typhoon
• Модульность Typhoon
• Typhoon Tips & Tricks
• Альтернативы Typhoon
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Слайды
• (Дополнительно) Rambler.iOS #3. Dependency Injection в iOS. Видео

Введение

В рамках этого цикла статей я не буду углубляться в теорию, рассматривать Dependency Inversion Principle или паттерны Dependency Injection — примем за данность, что читатель уже достаточно подготовлен к тому, чтобы познать дзен, и перейдем сразу к практике (ссылки для знакомства с теорией даны в самом конце поста).

Typhoon Framework — это самая известная и популярная реализация DI-контейнера для Objective-C и Swift приложений. Проект достаточно молодой — первый коммит был сделан в самом конце 2012 года, но уже обзавелся большим количеством поклонников. Отдельного упоминания заслуживает активная поддержка проекта его создателями (один из которых, между прочим, живет и работает в Омске) — на большинство создаваемых Issue отвечают в течение десяти минут, а уже через несколько часов к обсуждению присоединяется вся команда.

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

Для подключения по websocket мы будем использовать SocketIOClientSwift

Скачать можно тут.

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

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

Пришла мне как-то в голову идея, а можно ли взять блок и отдать для target-action?
Есть готовые решения, как к примеру BlocksKit и другие библиотеки, однако их решение заключается в сохранении блока, установкой таргета и вызова блока из указанного селектора.

Зачем тогда нужна эта статья?

Я захотел создать способ генерации селектора, по которому будет вызван блок. Что здесь сложного, скажете вы? imp_implementationWithBlock + class_addMethod и дело закрыто. Но при этом подходе есть одно серьезное требование, это первый аргумент блока — владелец метода.

Как обойти это требование и сделать такое?

    [button addTarget:self action:[self ax_lambda:^(UIButton *sender, UIEvent *event){
        NSLog(@"click on button %@, event = %@", sender, event);
    }] forControlEvents:UIControlEventTouchUpInside];

    [button addTarget:self action:[self ax_lambda:^{
        NSLog(@"click");
    }] forControlEvents:UIControlEventTouchUpInside];

Или даже вот так

    __block NSInteger sum = 0;
    [self performSelector:[self ax_lambda:^(NSNumber *argA, NSNumber *argB) {
        sum = [argA integerValue] + [argB integerValue];
    }] withObject:@(2) withObject:@(3)];
    //sum — 5

    SEL selSum = [self ax_lambda:^NSInteger(NSInteger argA, NSInteger argB){
        return argA + argB;
    }];
    NSInteger(*funcSum)(id, SEL, NSInteger, NSInteger) = (NSInteger(*)(id, SEL, NSInteger, NSInteger))objc_msgSend;
    NSInteger sum2 = funcSum(self, selSum, 2, 3);
    //sum2 — 5

Реализация оказалась настолько интересной, что я решил написать об этом.

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

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

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

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

Конец и начало года у разработчиков, как правило, всегда наполнены большим количеством проектов. Разобравшись со срочными делами и закатав повыше рукава, мы в Techmas пообещали себе делиться еще бОльшим количеством своих разработок с коллегами.

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

Для пояснения всех основных принципов работы c платформой, мы решили вернуться к примеру из прошлой публикации и дополнить его работой с выборками данных из Health.

За прошедший год мы организовали 8 встреч разработчиков под iOS — Apple Developers Community. По итогам накопилось около 20 видео-докладов, которые мы наконец-то структурировали и выложили на youtube-канал.

Смотрите, подписывайтесь и приходите на наши встречи!

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

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

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

Что же должен делать «несчастный» разработчик? Решение есть, оно состоит в том, чтобы отделить основной поток через параллелизм. Параллелизм, это свойство приложения выполнять задачи в несколько потоков одновременно – и при этом пользовательский интерфейс остается отзывчивым, поскольку Вы выполняете свою работу в разных потоках.

Одним из методов для одновременного выполнения операций в iOS являются использование классов NSOperation и NSOperationQueue. В этой статье вы узнаете, как их использовать! Вы будете работать с приложением, которое совсем не использует многопоточность, таким образом, оно будет очень медленным, и будет «тормозить». Когда вы измените приложение, чтобы можно было добавлять параллельные операций и — надеюсь – это обеспечит более отзывчивый интерфейс для пользователя!

На прошлой неделе я выступил с докладом об Объектно-ориентированном программировании в Мишлене, в компании, где я работаю. Я рассказывал о написании более эффективного кода, от STUPID коду SOLID коду! STUPID, а также SOLID являются акронимами, и рассматривались довольно много в течение длительного времени. Однако эти мнемоники не всегда известны, таким образом, имеет смысл распространить эту информацию.



Далее я познакомлю вас с принципами STUPID и SOLID. Следует иметь в виду, что это принципы, а не законы. Однако, рассматривая их в качестве законов было бы хорошо для тех, кто хочет усовершенствоваться в написании кода.

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



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

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

Поиск работы – задача не из простых, особенно в текущих неблагоприятных экономических условиях. Европейский ресурс Tech.eu в честь запуска своего сервиса по поиску работы подготовил список из десяти сайтов, которые помогут вам подыскать себе место под европейским солнцем, если вы, по какой-либо причине, желаете уехать на заработки в ЕС.

Стояла задача, чтобы программа отправляла через web socket текущие координаты по заданному пользователем интервалу. К тому же, программа должна работать в фоне и если пользователь или iOS по какой то причине её выгрузит из памяти, то желательно чтобы она перезапустилась и продолжила работу в фоне.
Поставленную задачу надо решить только средствами iOS без изменения серверной части (никаких Push Notifications).

Отправлять координаты по таймеру когда программа свернута в фон не составляет проблемы, для этого можно использовать background location mode для получения координат и long-running tasks для таймеров.

Но так как в iOS нет такой прелести как Android Background Services, то если вручную завершить программу, код перестает выполняться. Потому основная сложность заключается в том, как максимально быстро запустить программу в фоне, чтобы она продолжила выполнять свою задачу дальше, если её по каким то причинам выгрузила из памяти iOS, или если пользователь перезагрузил устройство, или если он вручную «убил» программу.

Теперь о том, что помогло решить данную задачу в приемлемом варианте:

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

Представление данных

До этого мы обращали много внимания на поведение и общую структуру кода, но забиывали про на данные, с которыми имеем дело. Сейчас у нас все является строками, включая возвращаемое значение CatApi::getRandomImage(). То есть вызывая этот метод, мы «знаем», что получим строку. Говорю «знаем», так как PHP может вернуть все — объект, ресурс, массив и т.д. Тем не менее, хоть в случае с RealCatApi::getRandomImage() мы и можем быть уверенны, что нам придет строка, так как мы явно приводим значение к ней, мы не можем точно сказать, что эта строка будет «полезна» (валидна) для того, кто вызвал этот метод: это может быть и пустая строка, строка, которая не содержит URL (типа «I am not a URL») и так далее.

Уже прошло много времени, с моменты выпуска компании Apple ее нового продукта — часов Apple Watch. Уже скоро выйдет финальная версия операционной системы для них — Watch OS 2.0. А на Хабре до сих пор нет более-менее развернутой статьи о том, как написать что-нибудь сложнее “Hello, world!” для Apple Watch. И в этой статье мы постараемся это исправить и написать приложение из нескольких экранов со списком, загрузкой данных и взаимодействием с основным приложением.

Привет всем! Сегодня хотелось бы сделать небольшое введение в такую штуку, как Size Classes. Она появилась недавно вместе с Xcode 6, документации по ней от самой Apple совсем немного.

Итак, для чего же предназначена Size Classes? Все мы знаем, что на подходе уже iPhone 6 двумя (как минимум) разными размерами дисплея (4,7 и 5,5), после чего разработчикам еще больше придется заморачиваться с версткой UI для них + само собой расширения iPad«ов. В итоге количество всех поддерживаемых экранов будет около 7 (маленький привет Android). Герой сегодняшнего дня — Size Classes — как раз и предназначен для того, что бы помочь решить данную проблему.

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

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

Отмечая окончание 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».

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

Причиной написания данной поста является то, что, как оказалось, можно преспокойно программировать под iOS полгода, и не знать полностью о жизненном цикле UIViewcontroller'ов. И на небольших проектах это даже получается. Однако, когда приходится иметь дело с серьезным, достаточно большим проектом, то появляются определенные проблемы с нехваткой памяти, «неправильной» и «непонятной» работой контроллеров, пропажей данных, и еще со многими типичными проблемами, о которых будет написано ниже.

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу