В сентябре 2016 года наши iOS-разработчики побывали в Вашингтоне на конференции CocoaConf DC, где получили массу интересного опыта. Там было очень много увлекательных докладов по разным направлениям, различного уровня сложности. В этой статье мы бы хотели рассказать о докладе, который заинтересовал своей необычностью и новизной — «Creating a Server Side Application with your Favourite Language: Swift!» Джонатана Гатри (Twitter, Github). Джонатан является одним из разработчиков Perfect — фреймворка, который позволяет использовать язык Swift в разработке серверных приложений. Эта тема интересна многим iOS-разработчикам, ведь большинство «домашних» идей останавливает проблема реализации серверной части. При этом изучение дополнительных языков или привлечение сторонних людей не добавляет энтузиазма.

В статье сделан упор на теоретическую часть вопроса, а не на код. Практические руководства можно найти в разделе «Дополнительные материалы», или же в поисковике.

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

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

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

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

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

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

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

Часть #2

Вступление

Идея для публикации возникла после прочтения перевода CSS для Swift: использование стилей для любых подклассов UIView. Подход достаточно интересный, но он оказался не очень гибким, т.к. не позволяет объединять стили разных типов. Подробнее можно прочитать в комментарии.

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

Декорации

Введем понятие декорации, которое будет олицетворять придание неких свойств объекту:

typealias Decoration<T> = (T) -> Void

---

Первая часть истории о медиапикере Paparazzo

---

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

Небольшое вступление

Я попал в мир IT относительно недавно: всего два года я занимаюсь разработкой приложений под iOS. Но кроме Objective-C и Swift меня всегда манил мир Java и C#. Периодически я выделял время, чтоб посмотреть какие-то видео, обучающие основам этих языков, но дальше простого просмотра и переписывания кода с экрана дело не заходило. И тут я вспомнил об одной математической игре, которую мне однажды посоветовал мой друг.

Суть игры заключается в следующем: вы идете по улице и смотрите на автомобильные номера. И в каждом номере считаете сумму всех цифр (например, в номере 8037 нужно посчитать 8 + 0 + 3 + 7). Это самый простой уровень игры. Второй по сложности уровень — посчитать сумму первой половины номера и второй (80 + 37). Есть еще третий уровень — умножить все цифры (нули при этом пропустив: 8 х 3 х 7) и четвертый — умножить первую половину номера на вторую (80 х 37).

В общем: эту игру (в консольном варианте) я и решил написать на четырех языках: Swift, Objective-C, Java и C#. Что из этого получилось? Давайте посмотрим.

Всем доброго времени суток! Меня зовут Николай, я iOS-Lead в компании Touch Instinct. В процессе разработки часто приходится иметь дело с проектами, которые должны работать на нескольких языках. Расскажу, к какому подходу мы пришли при работе с локализацией.

Минусы базовых подходов

Есть несколько основных подходов для локализации iOS-приложения. Сперва стоит определиться, разрабатывается приложение с использованием storyboards или нет.

С использованием storyboards

Можно локализовывать строки напрямую в storyboard. Однако, при таком подходе есть ряд минусов:

• в случае наличия большого количества storyboards, локализованные строки разбросаны по проекту;
• невозможность использования атрибутных строк, а также строк, которые состоят из нескольких составных частей;
• вам всё равно придется часть строк локализовывать в коде. Это ведет к еще большему разбросу в приложении;
• фактически отсутствует возможность что-то проверить другому разработчику при проведении code review.

Без storyboards

В этом случае локализуем всё в коде. Однако и тут есть ряд минусов. Дело в том, что файлы со строками локализации localizable.strings — магические. При изменении таких файлов очень велика вероятность возникновения ошибки из-за человеческого фактора. Изменения нельзя отследить, пока ошибка не будет найдена в процессе тестирования.

Таким образом, хотя для локализации уже есть готовые механизмы в iOS SDK, они имеют существенные минусы. Более подробно смотрите здесь.

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

Введение

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

Сегодня делимся опытом наших партнеров — компании Try Sports Now — о том, как с помощью фреймворка SceneKit дать приложению вторую жизнь.

«Случается, что приложение, которое долгое время прозябало в безвестности, вдруг начинает набирать популярность среди пользователей и приносить прибыль. Само собой разумеется, что при таком раскладе целесообразно его развивать и обновлять. Одно плохо: может оказаться, что исходный код продукта настолько морально устарел за время отсутствия спроса, что временные затраты на его обновление сопоставимы с ресурсом, уходящим на разработку нового исходника с нуля. С подобной проблемой мы столкнулись в работе с проектом Human Anatomy 3D. В этой статье мы расскажем, как осуществлялся переход новой версии приложения с Unity3D исходников на нативные, и осветим некоторые проблемы возникшие в процессе.

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

Мне нравится использовать композицию и инъекцию зависимостей, но когда каждая сущность начинает инъектится несколькими зависимости, получается некое нагромождение.

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

Но есть более управляемый способ.

Хочу поделится довольно обычной, но показательной историей. Идея проекта появилась 3 месяца назад, за 1 месяц была реализована и вот уже два месяца как проект переодически висит в топе GitHub, попал в какие только можно профильные новостные ресурсы, и даже забрался в дайджест в статье “Топ 5 библиотек апреля”.

Привет, Хабр! Недавно мы выпустили AppCode 2017.1, сейчас готовим первое обновление — пора рассказать обо всех изменениях в этой версии.

Стэнфордский университет, США — один из лучших в мире в области информатики (Computer Science). Он щедро делится своими курсами, и одним из самых популярных и успешных курсов является курс CS193P по разработке приложений на iOS, который читает профессор Пол Хэгерти. Это курс читается ежегодно, начиная с 2010 года. На данный момент актуальным является курс CS193P «Developing iOS 10 Apps with Swift», Зима 2017 года — «Разработка iOS 10 приложений с использованием Swift», и уже выложены все 17 Лекций и 5 Заданий на iTunes U (но можно смотреть и на Youtube).
В новом курсе отчетливо видно, что профессор сделал небольшой разворот всего курса от ОБЪЕКТНО-ОРИЕНТИРОВАННОГО программирования, к ФУНКЦИОНАЛЬНОМУ программированию с множеством неизменяемых объектов с APIs похожими на математические функции.
Конечно, iOS вовсе не была сконструирована на основе идеи функционального программирования. Но люди, которые изобретали Swift, держали “в голове” идею о функциональном программировании. Так что при разработке вашего iOS приложения (по крайней мере в части Модели) вы можете использовать множество элементов функционального программирования.

Это новый рубеж в iOS программировании, потому что в течение 10 лет люди, в основном, использовали в iOS программировании только reference type объекты, имея в виду концепцию объектно-ориентированного программирования. Но когда вы программируете на Swift с помощью структур structs и перечислений enums, и особенно если вы подключаете механизмы протоколов protocols и Generics, то вы можете реально сделать прекрасную работу, имеющую дело с реальным функциональным программированием.

Введение

Облачная синхронизация — закономерный тренд нескольких последних лет. Если вы разрабатываете под одну или несколько Apple платформ (iOS, macOS, tvOS, watchOS) и задачей является реализация функционала синхронизации между приложениями, то в вашем распоряжении есть очень удобный инструмент, или даже целый сервис — CloudKit.

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

CloudKit — это не просто фреймворк. Это полноценный BaaS (Backend as a Service), т.е. комплексный сервис с полноценной инфраструктурой, включающей в себя облачное хранилище, пуш-уведомления, политики доступа и многое другое, а также предлагающий универсальный кросс-платформенный программный интерфейс (API).

Привет, Хаброжители! Мы выпустили 3-е издание книги по языку Swift. В ходе долгого и плодотворного общения со многими из вас была выработана масса идей, благодаря которым новое издание стало по-настоящему полезным. В сравнении с предыдущим изданием данная книга содержит следующие изменения и дополнения:

— Весь материал актуализирован в соответствии со Swift версии 3.0 и Xcode 8.
— Добавлено большое количество нового учебного материала, в частности, связанного с обучением основам программирования.
— Переработана глава, посвященная коллекциям. Теперь ее изучение станет для вас такой же приятной задачей, как и изучение остального материала.
— Значительно доработаны главы, посвященные функциям и замыканиям. В них вы найдете много нового и интересного, в том числе связанного с изменениями, пришедшими вместе со Swift 3.0.
— Добавлены вспомогательные главы, позволяющие вам еще глубже погрузиться в изучаемый материал. В частности, теперь не будет проблем с изучением ленивых вычислений.
— Учтены пожелания и замечания пользователей по оформлению и содержанию.
— Исправлены найденные опечатки.

Продолжаем серию про чтение бинарных файлов iOS-приложений. Для понимания технических деталей рекомендуется почитать первую часть здесь. В этой статье посмотрим, как укладывается в бинарный файл код на Swift.

Содержание:

Часть 0. Синглтон-Одиночка
Часть 1. Стратегия
Часть 2. Наблюдатель

Сегодня мы разберемся с "начинкой" паттерна "Наблюдатель". Сразу оговорюсь, что в мире iOS у вас не будет острой необходимости реализовывать этот паттерн, поскольку в SDK уже есть NotificationCenter. Но в образовательных целях мы полностью разберем анатомию и применение этого паттерна. К тому же, самостоятельная реализация может обладать большей гибкостью и, в некоторых случаях, быть более полезной.

Всем привет! В своей статье я хочу рассказать о опыте разработки игры для Apple Watch. Игра называется Space Beaver(Бобер и Космос). Она также доступна и на iphone. Но в этой статье будет рассказ именно о версии для часов. Исходный код здесь.

Коллекции

Разработчики, перешедшие на Swift с Objective-C, не могли не заметить удобнейший функционал, который предоставляет Swift для работы с коллекциями. Использование диапазонов в индексах

let slice = array[1..<10]

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

Filter

Самой часто используемой функцией для коллекций, пожалуй, является filter

let alex = Person(name: "Alex", age: 23)
let jenny = Person(name: "Jenny", age: 20)
let jason = Person(name: "Jason", age: 35)
let persons = [alex, jenny, jason]
let jNamedPersons = persons.filter { $0.name.hasPrefix("J") } // [jenny, jason]

Reduce

Реже используемой, но при этом крайне выразительной и удобной является функция reduce

let ages = persons.map{ Float($0.age) }
let average = ages.reduce(0, +) / Float(persons.count)

Можно писать свои функции высшего порядка и это довольно увлекательно:

func divisible(by numbers: Int...) -> (Int) -> Bool {
    return { input -> Bool in
        return numbers.reduce(true) { divisible, number in
            divisible && input % number == 0
        }
    }
}

let items = [6, 12, 24, 13]
let result = items.filter(divisible(by: 2, 3, 4)) // [12, 24]

Map

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

Итак, для простоты мы можем считать, что функтор это контейнер, к которому применима функция map, а монада это функтор, к которому применима функция flatMap.

Поскольку коллекции это контейнеры, и в Swift для них определена функция map, они могут выступать в роли функторов:
для того, чтобы трансформировать коллекцию одного типа в коллекцию другого типа, возьмем наш массив persons и получим из него массив возрастов типа [Int]

let ages = array.map{ $0.age } // [23, 20, 35]

FlatMap

И в роли монад:
для того, чтобы из массива oprtional типов вернуть массив не опциональных значений

let optionalStrings: [String?] = ["a", nil, "b", "c", nil]
let strings = optionalStrings.flatMap { $0 } // ["a", "b", "c"]

для того, чтобы расширить первоначальную коллекцию

let odds = [1,3,5,7,9]
let evensAndOdds = odds.flatMap { [$0, $0 + 1] } // [1,2,3,4,5,6,7,8,9,10]

Предлагаю вашему вниманию перевод оригинальной статьи Роберта С. Мартина.

За последние несколько месяцев я попробовал два новых языка. Swift и Kotlin. У этих двух языков есть ряд общих особенностей. Действительно, сходство настолько сильное, что мне стало интересно, не является ли это новой тенденцией в нашей языкомешалке. Если это действительно так, то это тёмный путь.

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

Проблема в том, что оба языка сделали ставку на сильную статическую типизацию. Кажется, оба намерены заткнуть каждую дыру в своём родном языке. В случае со Swift – это странный гибрид C и Smalltalk, который называется Objective-C; поэтому, возможно, упор на типизацию понятен. Что касается Kotlin – его предком является уже довольно строго типизированная Java.

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

Дело не в том, что меня беспокоит статическая типизация Swift и Kotlin. Скорее меня беспокоит глубина статической типизации.