Приветствую!
Сегодня я хотел бы вам рассказать о создании браузера на новом (относительно) языке Swift.
Код довольно простой. Как и сам браузер. Делал я его для практики. Все вопросы обсужу и помогу. Пишите в комментариях.
Читать полностью »
Приветствую!
Сегодня я хотел бы вам рассказать о создании браузера на новом (относительно) языке Swift.
Код довольно простой. Как и сам браузер. Делал я его для практики. Все вопросы обсужу и помогу. Пишите в комментариях.
Читать полностью »
Ребята из pipes в качестве саморекламы выложили в сеть простенький эмулятор Apple Watch http://www.demoapplewatch.com/
Функционал у этой штуки скудный, но покрутить экран и даже загрузить, например, лого хабра вполне можно. В общем для фанатов очередная игрушка, а для разработчиков скромная возможность, чтобы посмотреть как будут выглядеть приложения, которые совсем скоро будут заказывать и намек, что уже самое время попробовать сделать подобные эмулятору штуки, хотя бы для собственного пиараЧитать полностью »
Отмечая окончание 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 разработке.
Благодаря фреймворку ReactiveCocoa, новая парадигма программирования все чаще используется среди iOS разработчиков.
Отказоустойчивость, отзывчивость, ориентированность на события и масштабируемость — вот четыре принципа реактивного программирования. Подробности можете узнать в реактивном манифесте (перевод на Хабре).
Для себя я выделил следующие преимущества реактивного подхода:
В качестве альтернативы реактивному подходу рекомендую посмотреть на Futures. Есть как минимум два интересных фреймворка: PromiseKit и CollapsingFutures
Читать полностью »
Привет!
У нас для вас отличные новости — в новой версии нашей IDE для разработчиков под iOS/OS X — AppCode 3.1 — появилась долгожданная поддержка языка Swift, и даже Rename refactoring для кода на этом языке.
Сегодня мы выложим два новых доклада с нашей конференции мобильных разработчиков #MBLTDev, которая прошла в конце октября в Москве.
Оба доклада посвящены безопасности: один от главы EMEA PayPal Тима Мессершмидта про современные виды аутентификации, второй – от ведущего инженера по безопасности viaForensics Андрея Беленко про безопасность iOS-устройств.
Тим призвал отказывать от паролей и рассказал, чем их можно заменить. «8,5% пользователей используют в качестве пароля Password или 123456 45% уходят с сайта вместо того, чтобы восстановить пароль или ответить на секретные вопросы. — сказал Тим. — Для повышения безопасности мы в PayPal предлагаем использовать носимые устройства или аутентификацию без пароля (например, OpenID).»
Несмотря на то, что в Objective-C 2.0 присутствуют замыкания (известные как блоки), ранее эппловский API использовал их неохотно. Возможно, отчасти поэтому многие программисты под iOS с удовольствием эксплуатировали сторонние библиотеки, вроде AFNetworking, где блоки применяются повсеместно. С выходом Swift, а также добавлением новой функциональности в API, работать с замыканиями стало чрезвычайно удобно. Давайте рассмотрим, какими особенностями обладает их синтаксис в Swift, и какие трюки можно с ними «вытворять».
Продвигаться будем от простого к сложному, от скучного к веселому. Заранее приношу извинения за обильное использование мантр «функция», «параметр» и «Double», но из песни слов не выкинешь.
Читать полностью »
Это перевод статьи Tony DiPasquale «Efficient JSON in Swift with Functional Concepts».
Передо мной была поставлена задача: закачать данные в формате JSON с Flickr.com о 100 топ местах, в которых сделаны фотографии на данный момент, в массив моделей:
//------ Массив моделей Places
struct Places {
var places : [Place]
}
//-----Модель Place
struct Place {
let placeURL: NSURL
let timeZone: String
let photoCount : Int
let content : String
}
Кроме чисто прагматической задачи, мне хотелось посмотреть как в Swift работает «вывод типа из контекста» (type Inference), какие возможности Swift в функциональном программировании, и я выбрала для парсинга JSON алгоритмы из статьи Tony DiPasquale «Efficient JSON in Swift with Functional Concepts and Generics», в которой он «протягивает» generic тип Result<A>
для обработки ошибок по всей цепочке преобразований: от запроса в сеть до размещения данных в массив Моделей для последующего представления в UITableViewController
.
Чтобы посмотреть как Swift работает «в связке» с Objective-C, для считывания данных с Flickr.com использовался Flickr API, представленный в курсе Стэнфордского Университета «Stanford CS 193P iOS 7», написанный на Objective-C.
В результате помимо небольшого расширения Моделей:
extension Place: JSONDecodable {
static func create(placeURL: String)(timeZone: String)(photoCount: String)(content: String) -> Place {
return Place(placeURL: toURL(placeURL), timeZone: timeZone, photoCount: photoCount.toInt() ?? 0, content: content)
}
static func decode(json: JSON) -> Place? {
return _JSONParse(json) >>> { d in
Place.create
<^> d <| "place_url"
<*> d <| "timezone"
<*> d <| "photo_count"
<*> d <| "_content"
}
}
}
extension Places: JSONDecodable {
static func create(places: [Place]) -> Places {
return Places(places: places)
}
static func decode(json: JSON) -> Places? {
return _JSONParse(json) >>> { d in
Places.create
<^> d <| "places" <| "place"
}
}
}
мне самостоятельно пришлось написать только три строчки кода:
Читать полностью »
Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с 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 вообще не существует, поскольку он прячет под капотом всю работу с указателями. Остальные два пункта решаются с помощью перечислений.Читать полностью »