Добро пожаловать во вторую часть серии статей по AsyncDisplayKit (Texture)!

Система компоновки AsyncDisplayKit позволяет писать невероятно быстрый, декларативный код.

Помимо быстрой настройки, она автоматически адаптируется к устройству, на котором запущено приложение. Допустим, вы пытаетесь создать узел, который можно использовать во view controller приложения или в качестве popover в приложении для iPad. Если его layout будет правильно создан, вы сможете перенести узел в эту новую среду, не беспокоясь об изменении базового кода макета!

«Искусство – это все, что вы можете сделать хорошо. Все, что вы можете сделать качественно» (Robert M. Pirsig).

От переводчика:
С появлением autoLayout создавать интерфейс iOS-приложения стало намного проще и быстрее. Вам больше не нужно думать о подгонке размеров под определенные устройства, autoLayout сделает это за вас. Вычисление происходит на основе констрейнтов относительно ближайших элементов. Чем больше таких зависимостей, тем дольше будет строиться autoLayout, и это основная проблема всех приложений с сложным интерфейсом.
Использование AsyncDisplayKit позволит вам на порядок уменьшить объем работ, выполняемых в основном потоке, и реализовать сложные интерфейсы с минимальным количеством кода. Ребята из Raywenderlich сделали подробный и наглядный туториал по работе с ним. Надеюсь, что перевод статьи поможет вам ещё быстрее освоить этот фреймворк.

Так же как и в топике — «О блоках и их использовании в Objective-C часть 2-ая», мы продолжим говорить о преимуществах использования блоков на живых примерах.
Здесь мы рассмотрим удобства использования блоков при управлении последовательностью операций.

5. UIView анимации, последовательность анимаций.

Для начала напишем простенький пример, в котором мы будем двигать кнопку с помощью анимаций(без блоков). Затем поменяем порядок анимаций чтобы посмотреть, какие изменения потребуются в коде.

Продолжение топика — О блоках и их использовании в Objective-C часть 1-ая.

Многие из тех кто впервые сталкивается с блоками (или замыканиями), задают вопрос — «а зачем? Если и без них можно». Да можно. Но использование блоков имеет не мало преимуществ, и первое из них — существенная экономия на количестве кода, а следовательно и на времени написания и поддержке. Дальше буду говорить примерами.

Содержание:

1. Работа с контейнерами на примере NSArray.
2. Guards на примере UITableView.
3. Использование блоков вместо классов на примере scheduled операций.
4. Блоки вместо делегатов в UIAlertView.
5. UIView анимации, последовательность анимаций.
6. Асинхронные операции и управление ими. Переписываем пример с анимациями.

В OS X 10.6 и iOS 4.0 компания Apple анонсировала поддержку блоков, по сути являющиx собою замыкания. Дальше о блоках в контексте разработки под IOS, Objective-C (тоесть работа без gc).
Для использования блоков IOS ver. < 4.0 можно применить ESBlockRuntime или PLBlocks.

Кратко о теории

Экземпляр блока, тип блока и сам блоковый литерал обозначаются с помощью оператора ^, пример:

typedef int (^MyBlock)(int);

int multiplier = 7;
MyBlock myBlock = ^(int num) {
 return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

или

int multiplier = 7;
int (^myBlock)(int) = ^(int num) {
  return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

Вызов блока аналогичен вызову обычной сишной функции. Например, так:

myBlock( 3 )

* This source code was highlighted with Source Code Highlighter.

Главной особенностью блоков является их умение хранить контекст в котором они создавались. В примере выше «myBlock» всегда будет умножать число на 7. Как же это все работает?

В этой статье представлен гайд по настройке совместной работы светильников Xiaomi, работающих по Wi-Fi и Bluetooth, с Siri при помощи Homebridge. А также описаны грабли, на которые я успел наступить.

В параллельном программировании в Swift: Основы Я представил множество низкоуровневых способов для управления параллелизмом в Swift. Первоначальная идея состояла в том, чтобы собрать все различные подходы, которые мы можем использовать в iOS в одном месте. Но при написании этой статьи я осознал, что их слишком много, чтобы перечислить в одной статье. Поэтому я решил сократить методы более высокого уровня.



Я упомянул Operations в одной из моих статей, но давайте рассмотрим их более внимательно.

Если вы хотите добиться UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI).

В текущей версии Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).

Один из них использует GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.

Код для этой статьи можно посмотреть на Github.

Надо сказать, что многопоточность (сoncurrency) в iOS всегда входит в вопросы, задаваемые на интервью разработчикам iOS приложений, а также в число топ ошибок, которые делают программисты при разработке iOS приложений. Поэтому так важно владеть этим инструментом в совершенстве.
Итак, у вас есть приложение, оно работает на main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию».



Как можно изменить архитектуру приложения, чтобы таких проблем не возникало? В этом случае на помощь приходит многопоточность (сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.

В последнее время, часто вижу вопрос:

Можно ли в iOS работать с геолокацией, когда приложение свернули и отправлять данные на сервер?

Это действительно возможно и совсем не сложно.
How to вместится в превью статьи.

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

Чтобы была какая-то конкретика, я предположил, что перед нами стоит задача написать вело-трекер. Со стороны пользователя это выглядит так:

1. Скачиваю приложение
2. Запускаю
3. Регистрируюсь
4. Нажимаю куда просят
5. Закрываю
6. Катаюсь
7. Запускаю
8. Вижу результат

p.s. финальный код здесь.

На WWDC 2017 Apple анонсировала ARKit — SDK для работы с дополненной реальностью. Благодаря ему порог вхождения в эту технологию стал значительно ниже. Можно ожидать появления большого количества качественных игр и приложений.

Вступление

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