В пятницу, 19 мая, в нашем московском офисе прошел CocoaHeads-митап для iOS-разработчиков. Разнообразный по наполнению: два выступления докладчиков, викторина на проверку знаний и панельная дискуссия с экспертами из известных на рынке IT-компаний. Видеоотчет – под катом!

Николай Морев (Mail.Ru)

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

Здесь мы видим, что для большинства пользователей время запуска было порядка 4-х секунд, даже немного больше. Поэтому в последнее время мы решили больше внимания уделить именно качеству продукта, а не новой функциональности. Мы начали увеличивать покрытие тестами, начали работать над уменьшением размера приложения, над оптимизацией скорости запуска, над оптимизацией использования сетевых ресурсов. И вот чему мы научились.

«Even now, your enemies are eagerly watching Rambler.iOS videos»
Motivation for Harvard students

После длительного перерыва спешим анонсировать весеннюю встречу Rambler.iOS #9, которая состоится 25 мая в нашем офисе на Даниловской Мануфактуре.

Что такое 8037?

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

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

Введение

Привет, меня зовут Ник Снайдер и я инженер-программист в компании LinkedIn. Сегодня я хочу рассказать вам историю об Auto Layout:

1. Как мы в LinkedIn используем его.
2. Проблемы, с которыми мы встретились.
3. Почему в некоторых ситуациях мы прекратили использовать Auto Layout.
4. И что мы используем вместо него.

Хорошие новости

Я бы хотел начать с хороших новостей:

1. Мы в LinkedIn широко используем Auto Layout. Это наш основной метод построения интерфейсов во всех наших приложениях.
2. Auto Layout мощный инструмент, который облегчает поддержку:
   
   1. Различных размеров экрана;
   2. Языков с написанием справа налево.

Плохие новости

Плохие новости заключаются в том, что производительность Auto Layout недостаточно хороша:

1. Не масштабируется для сложных иерархий view (из последующего изложения будет ясно, что речь идет о нелинейном увеличении времени расчета при линейном росте количества view — прим. перев.).
2. Мы наблюдали регресс производительности, на некоторых релизах iOS.
3. Производительность может оказаться непредсказуемо плохой для некоторых разметок интерфейса (здесь и далее layout переведено как «разметка» — прим. перев.).

В сентябре 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.
— Добавлены вспомогательные главы, позволяющие вам еще глубже погрузиться в изучаемый материал. В частности, теперь не будет проблем с изучением ленивых вычислений.
— Учтены пожелания и замечания пользователей по оформлению и содержанию.
— Исправлены найденные опечатки.