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

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

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

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

Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с Haskell и Scala, при программировании на Swift становятся ослепительно очевидными решениями для широкого спектра проблем.

Взять вот обработку ошибок. Конкретный пример – деление двух чисел, которое должно вызвать исключение если делитель равен нулю. В Objective C я бы решил проблему так:

NSError *err = nil;
CGFloat result = [NMArithmetic divide:2.5 by:3.0 error:&err];
if (err) {
    NSLog(@"%@", err)
} else {
    [NMArithmetic doSomethingWithResult:result]
}

Со временем это стало казаться самым привычным способом написания кода. Я не замечаю, какие загогулины приходится писать и как косвенно они связаны с тем, что я на самом деле хочу от программы:

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

Я передаю параметры, разыменовываю указатели, возвращаю значение в любом случае и в некоторых случаях потом игнорирую. Это неорганизованный код по следующим причинам:

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

Каждый из этих пунктов – источник возможных багов, и все эти проблемы Swift решает по-своему. Первый пункт, например, в Swift вообще не существует, поскольку он прячет под капотом всю работу с указателями. Остальные два пункта решаются с помощью перечислений.

Я разместила иконки курсов Стэнфордского университета по разработке приложений на iOS в обратном хронологическом порядке. На первом месте стоит иконка Swift — нового языка программирования для создания приложений на iOS, объявленного на WWDC 2014. Кроме Swift реализована новая версия iOS — iOS 8. Уже известно, что Стэнфордский университет запустит зимой 2015 года новый курс CS193P с неизвестным пока названием (может быть будет что-то вроде «Developing iOS 8 Apps for iPhone and iPad»). Лектор тот же — профессор Paul Hegarty.
В традиции Стэнфорда выкладывать курс CS193P на iTunes U в виде бесплатного курса обучения, но делают это они со сдвигом во времени, чтобы не мешать платному обучающему процессу, так что в феврале-марте 2015 года (как это было в 2013 году) можно ожидать постепенное появление лекций на iTunes U. Так что время есть.
Я прошла почти все курсы профессора Пола Хэгарти — от iOS 5 до iOS 7 — до самого конца (смотри Github ).
Для подготовки к перспективному курсу по iOS 8 разместила на своем сайте «Разработка iOS приложений» неавторизованные конспекты лекций, тексты домашних заданий и примеры их решения на русском языке для последнего доступного в настоящее время обучающего курса «Developing iOS 7 Apps for iPhone and iPad», запущенного Стэнфордским университетом в семестре «осень 2013 — зима 2014 года» на iTunes U.

Что в первую очередь сделает iOS разработчик, если перед ним встанет задача спрятать пользовательские данные от любопытных глаз? Конечно же, встроит экран парольной защиты. Особо хитрый разработчик даже не будет хранить установленный пользователем пароль в NSUserDefaults, а аккуратно спрячет его в связку ключей — в этом случае приложение в глазах как его, так и заказчика, сразу же перемещается в разряд «сверхзащищенных».
Мы не будем углубляться в описание опасностей хранения ключа в открытом доступе — ведь есть гораздо более интересный способ обхода такой защиты.

В конце мая 2014 года я писал подробную статью как тестировать приложения на iOS7 и Xcode 5.1.1, но не далее как два месяца назад миру был представлен iPhone 6 и iPhone 6 Plus с новой операционной системой iOS 8 и Apple изменила что-то в коде и старый «твик» более не работает. Знаю, что некоторым интересно попробовать написать приложение для iOS, чисто в познавательных целях, но 99USD платить Apple за «любознательность» не хочется. Не отчаивайтесь, не все так страшно, более того, теперь всё гораздо проще — больше не нужно создавать сертификаты и компилировать ldid для отладки.

Бывают такие ситуации, при которых лучше написать категорию к классу, чем использовать наследование. Так же иногда существует потребность использовать оригинальный метод класса внутри категории, как если бы мы вызвали super при наследовании. О такой возможности иногда любят спрашивать на собеседованиях и почему-то уверены, что этого нельзя сделать. Google так же умалчивает о такой возможности. Кому интересно — добро пожаловать под кат.

Одними из самых востребованных классов в UIKit до выхода iOS версии 8 являлись UIAlertView и UIActionSheet. Наверное, каждый разработчик приложений под мобильную платформу от Apple рано или поздно сталкивался с ними. Показ сообщений или меню выбора действий — это неотъемлемая часть практически любого пользовательского приложения. Для работы с этими классами, а точнее для обработки нажатий кнопок, программисту требовалось реализовывать в своем классе методы соответствующего делегата — UIAlertViewDelegate или UIActionSheetDelegate (если не требовалось чего-то сверх, то достаточно было реализовать метод clickedButtonAtIndex). На мой взгляд это очень неудобно: если внутри объекта создавалось несколько диалоговых окон с разными наборами действий, то их обработка все равно происходила в одном методе с кучей условий внутри. С выходом 8 версии iOS в составе UIKit появился класс UIAlertController, который пришел на смену UIAlertView и UIActionSheet. И одной из его главных отличительных черт является то, что вместо делегатов он использует блочный подход:

    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"Hello" message:@"Habr!" preferredStyle:UIAlertControllerStyleAlert];
    
    [alertController addAction:[UIAlertAction actionWithTitle:@"Action" style:UIAlertActionStyleDefault handler:^(UIAlertAction *action) {
        // код обработчика кнопки
    }]];

Такой подход позволяет писать более структурированный и логичный код. Отныне программисту больше не требуется разделять создание диалогового окна и обработку событий — UIAlertController устраняет это недоразумение, но одновременно с этим привносит историческую несправедливость из-за невозможности использования в iOS 7 и более ранних версиях. Решить эту проблему можно несколькими способами:

• Не обращать внимание на UIAlertController и продолжать использовать устаревшие UIAlertView и UIActionSheet.
  
• Использовать нестандартные диалоговые окна. Программист либо пишет собственную реализацию, что приводит к увеличению временных затрат, либо подключает сторонние компоненты (например, SIAlertView), использование которых имеет ряд недостатков:
  
  1. программные модули с хорошей поддержкой можно пересчитать по пальцам (зачастую их создатели быстро забрасывают это неблагодарное дело);
  2. если в проекте используются несколько компонентов от разных разработчиков, то при их взаимодействии могут возникать проблемы (редко, но это возможно).
  
  
• Проверять версию iOS и создавать либо UIAlertController, либо UIAlertView или UIActionSheet.
  

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

Я часто пишу небольшие тестовые проекты на Objective-C, чтобы поэкспериментировать или поиграться с чем-нибудь. Обычно, я помещаю код в main.m и избавляюсь от всего остального:

#!/usr/bin/env objc-run
@import Foundation;

@implementation Hello : NSObject
- (void) sayHelloTo:name
{
    printf("Hello %s, my address is %p\n", [name UTF8String], self);
}
@end

int main ()
{
    id hello = [Hello new];
    [hello sayHelloTo:@"sunshine"];
}

Это полноценный проект из одного файла, готовый к выполнению. Под катом — описание приемов, позволивших прийти к данному минимализму.

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

Один из этих типов расширений являются Today Extensions, также известные как Widgets. Они предоставляют Вам возможность отображать информацию в Центр Уведомления, который является отличным способом предоставления самой актуальной информации, которой интересуется пользователь.

В этой статье, Вы напишете приложение на основе расширения Today Extension, которое представит текущую рыночную стоимость Bitcoin на основе доллара США.

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

Давно подметил, что среди многих своих коллег по цеху присутствует некоторая подозрительность и даже в некотором роде неприязнь к Core Data, причем некоторые к фреймворку даже и не притрагивались. Чего уж там, и я в начале своего пути освоения новой платформы относился к нему предвзято, пойдя на поводу у подобных комментариев. Но не стоит поддаваться предрассудкам и мифам, не потрогав продукт самостоятельно. Тем из нас, кто пошел «против системы», но еще не постиг инструмент полностью, я и посвящаю эту статью. На основе небольшого примера, основанного на реальной задаче разработки мобильного клиента нашей социальной сети Мой Мир, я хочу рассказать о некоторых «подводных» камнях и заострить внимание начинающего разработчика на важных моментах оптимизации использования Core Data. Предполагается, что читающий уже имеет представление, для чего нужны основные элементы Core Data (NSManagedObjectContext, NSPersistentStoreCoordinator и т.д.) и хотя бы поверхностно ознакомлен с API.

Наш кейс: необходимо разработать приложение, позволяющее хранить и структурировать большой объем фотографий с различной метаинформацией о них. Для этого нам потребуется Core Data… и все.

Здравствуй, Хабражитель!

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

В поиске информации о работе с Кортежами (Tuples) в Swift работая над своим приложением, я решил, что будет лучше объединить в одну статью всю информацию, которую я изучил или нашел, чтобы ее можно было легко использовать.

Кортежи в основном являются значением, которое может содержать несколько других значений. Составной тип может содержать также “именованные типы”, которые включают в себя классы, структуры и перечисления (также протоколы, но так как они не хранят значения непосредственно, я знал, что должен упомянуть их отдельно), а также другие составные типы. Это означает, что кортеж может содержать другие кортежи. Другой составной тип, который может содержать кортеж, является “функциональным типом”, который различным способом ссылаться на тип. Он описывает замыкания в частности стиля типа “() >() ”, чьи функции и методы соответствуют ему. Также функциональный тип может содержать другие составные типы, как кортеж, и замыкания, про которые Вы читали в моем предыдущем посте "Замыкание и Определение в Swift".

Как вы знаете, в Xcode 6 и iOS 8 SDK Apple добавила возможность рендеринга кастомных компонентов и редактирования их свойств прямо в стандартном Interface Builder (здесь должно быть едкое упоминание о том, что это было еще в Delphi древних версий).

Основы

Для начала нам понадобится какой-то самодельный наследник UIView, чтобы заставить Xcode рендерить его в Interface Builder. Для этого его нужно пометить атрибутом IB_DESIGNABLE (технически в Objective-C это макрос, ну раз Apple называет это атрибутом, и в Swift это атрибут, так тому и быть):

IB_DESIGNABLE
@interface XXXStaticPriceView : UIView

@property (nonatomic, copy) IBInspectable NSNumber *price;
@property (nonatomic) IBInspectable NSUInteger amount;
@property (nonatomic) IBInspectable NSNumberFormatterRoundingMode roundingMode;

@property (nonatomic, getter = isHighlighted) IBInspectable BOOL highlighted;

@property (nonatomic, copy) IBInspectable UIColor *textColor;
@property (nonatomic, copy) IBInspectable UIColor *outlineColor;

@end

Теперь можно создать storyboard (или xib) и разместить там наш view, и Xcode должен будет его успешно отобразить (предварительно собрав проект):

Всем привет.

Когда Вы начинаете использовать CoreData для сохранения данных в Ваших приложениях, Вы начинаете работать с единственным управляемым объективным контекстом / managed object context (MOC). Это — то, что используется в шаблоне при создание проекта в xCode, если Вы при создание проекта ставите галочку рядом с «Use Core Data».

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

Это кажется волшебным? Так и должно быть. Потому что, если Вы их поищете, то обнаружите что URL, практически как и любовь, вокруг нас. Что используют UIWebView или WKWebView? Они используют URL. Что используется для трансляции видео с MPMoviePlayer? Для этого используется URL. Как Вы направляете кого-то в свое приложение на iTunes, запускаете FaceTime или Skype, запускаете другое приложение в системе или даже вставка изображение в HTML файле? С помощью URL. Загляните на NSFileManager и обратите внимание на то, для какого количества методов обработки файлов необходимы URL.

В этой статье про NSURLProtocol Вы научитесь определять обработчика протокола, который модифицирует URL схемы. Он добавит необработанный и готовый прозрачный слой кэширования, сохраняя извлеченные ресурсы в Core Data. Запуская его в работу, обычный UIWebView может тогда взять на себя роль браузера, кэшируя загруженные страницы, чтобы можно было позже просмотреть их в оффлайн режиме.

Хабралюди, добрый день!

Сегодня Вашему вниманию хочу представить очередной перевод, не судите строго :) Надеюсь, Вам этот материал пригодится в работе.

В течение многих лет, Core Data была неотъемлемой частью многих OS X и iOS-приложений, обеспечивая сохранение и запрашивая пользовательские данные. Компания Apple тратит много усилий для того, чтобы API Core Data было проще в использовании и облегчала разработчикам процесс интегрирования в приложения.

Этот факт указывает на то, что Core Data является сложно-модифицируемой проектом. Даже если вы знаете как пользоваться Data Core, выполнение простых, ежедневных задач может показаться вам сложной и объемной работой. Хорошо, что существует MagicalRecord – независимая библиотека для Core Data, созданная MagicalPanda. А это учебное пособие научит Вас, как ускорить работу с MagicalRecord быстро и легко.

MagicalRecord – прост в использовании, хорошо разработан и популярен. Авторы проекта заявил, что основная задача MagicalRecord – очистка кода который Вам нужно писать для использования Core Data и с помощью одной простой строки кода сделать выборку данных, одновременно позволяя пользователю оптимизировать производительность. «Как это возможно?» — подумаете Вы. Это возможно благодаря удобной технологии, которая использует один и тот же шаблон для настройки, запросов и обновления Core Data. Особенностью дизайна является влияние Ruby on Rails’ системы хранения данных ActiveRecord.

Вступление

Начиная с iOS 8 Apple открывает доступ к возможности использования технологии Touch ID (аутентификации с помощью сканера отпечатков пальцев, встроенного в iPhone 5s) в сторонних приложениях. В связи с этим я хотел бы поделиться с вами подробной информацией о том, что же именно стало доступно разработчикам, как это встроить в свое приложение, каким поведением это обладает, а также поделиться удобной «оберткой», которая реализует наиболее, на мой взгляд, вероятный сценарий использования Touch ID.

Как многие читали в книгах, в языке Objective-C изначально есть два корневых класса — NSObject и NSProxy. И если на первом основано практически все и с ним невозможно не столкнуться, то вторым пользуются значительно реже. В этой небольшой статье я опишу те применения этого класса, которые приходилось использовать мне.

Swift это новый язык программирования от компаний Apple, который она презентовала в этом году на WWDC. Вместе с языком программирования, Apple выпустила отличный справочник по языку Swift, который я рекомендую прочитать или ознакомиться с ним. Тем не менее, читать книгу это очень долго! Так что если у Вас нет много времени и Вы просто хотите узнать о новом языке Swift, то эта статья для Вас.

В данной статье я бы хотел поделиться некоторыми размышлениями по поводу перехода от Objective-C к Swift. Я постараюсь дать Вам несколько советов и указать на недостатки при разном подходе к обеим языкам. Поэтому без лишних отступлений, перейдем к самой статье.