Всем привет, меня зовут Артём, я iOS-разработчик. Сегодня хочу рассказать о подходах к использованию UITableViewController и UICollectionViewController.

Едва ли можно найти мобильное приложение, в котором не используется списочное представление данных. Существенную часть времени мы (iOS-разработчики) проводим с TableView или CollectionView. Именно поэтому критически важным является выбор подходов к использованию этих базовых элементов из соображений скорости разработки и стоимости дальнейшей поддержки создаваемых решений. Хочу поделиться выводами, к которым мы пришли с коллегами в Touch Instinct.

Статья рассчитана на разработчиков, которые работают с TableView (CollectionView), но почему-то не работают с TableViewController (CollectionViewController). Далее будет упоминаться только TableView(Controller), но все написанное касается и CollectionView(Controller) тоже.

Я не буду тебя больше...
Я не буду тебя больше, больше ждать.
Полина Гагарина о версии Swift с обратной совместимостью.

Мы хотим пригласить вас на нашу очередную встречу Rambler.iOS, которая состоится 5 октября в нашем московском офисе на Даниловской Мануфактуре. Начало осени выдалось для iOS разработчиков очень богатым на различные мероприятия. Чтобы не отставать, основной упор в этот раз мы делаем на контент — вас ожидают четыре отличных доклада, причем один из них — от приглашенного иностранного спикера.

Сетевое ядро как часть приложения

Для начала немного поясню, о чем пойдет речь в данной статье. Сейчас большинство мобильных приложений, на мой взгляд, являются клиент-серверными. Это означает, что они содержат в составе кода сетевое ядро, отвечающее за пересылку запросов и получение ответов от сервера. Причем речь вовсе не о сетевых библиотеках, которые берут на себя ответственность по «низкоуровневому» управлению запросами вроде пересылки REST-запросов, построения multipart-тела, работы с сокетами, веб-сокетами, и так далее. Речь идет о дополнительной обвязке, которая позволяет управлять запросами, ответами и данными состояния, характерными конкретно для вашего сервера. Именно в вариантах реализации этой обвязки и заключены основные проблемы сетевого уровня во многих мобильных проектах, с которыми мне приходилось работать.

Данная статья ставит целью привести один из вариантов архитектурного решения по построению сетевого ядра приложения, к которому я пришел после долгого времени работы с разными моделями и различными серверными API, и который на данный момент является наиболее оптимальным для задач, встречающихся мне в процессе работы над проектами. Надеюсь, этот вариант поможет вам разработать хорошо структурированное и легко расширяемое сетевое ядро, если вы начинаете новый проект или модифицируете существующий. Также буду рад услышать ваши советы и комментарии по улучшению кода и/или предложенной архитектуры. И да, статья из-за большого объема будет выпущена в двух частях.

Подробности под катом.

Core Image представляет собой мощный API, встроенный в Cocoa Touch. Это важная часть IOS SDK. Тем не менее ее часто упускают из виду. В этой статье мы будем рассматривать возможность обнаружения лица и то, как использовать данную технологию в своих IOS приложениях!

Что мы будем делать в этом туториале?

Распознавание лиц в iOS появилось давно, еще с 5-го релиза (примерно в 2011 году), но эту особенность часто упускали из вида. API обнаружения лица позволяет разработчикам не только распознавать лица, но и проверять их на определенные свойства, такие как, наличие улыбки, зажмуривает ли человек глаза и т.д.

Во-первых, мы будем изучать технологию обнаружения лица с использованием фреймворка Core Image, создав приложение, которое распознает лицо на фотографии и обводит его специальной рамкой. Во втором примере, мы будем рассматривать более детальный способ использования, путем создания приложения, которое позволит пользователю сделать снимок, обнаружить, присутствует ли лицо, и получить координаты лица пользователя. Таким образом, мы собираемся узнать как можно больше об распознавании лиц в iOS, а также принцип использования мощного API, который так часто упускают из вида. Итак, поехали!

Здравствуйте! Эта статья нацелена на разработчиков, у которых есть минимальный навык работы с Core Data Framework. Напомню, что Core Data — это фреймворк для хранения данных на устройстве и взаимодействия с ними. На эту тему есть куча русскоязычных статей на хабре и в сети, поэтому не вижу необходимости повторять их содержание.

Зачастую начинающие особенно Stack Overflow разработчики пугаются использовать Core Data Framework, потому что он кажется им сложным, или используют лишь малую часть его возможностей. В реальности знание базовых функций классов данного фреймворка позволяет разработчику с удобством работать с моделью.

В статье я хочу акцентировать внимание на следующих моментах:

• мы рассмотрим класс NSFetchRequest, с помощью которого создаются запросы на извлечение данных из модели. Мы изучим его основные свойства и кейсы с их применением;
• мы подробно разберём функции и работу NSFetchedResultsController по эффективному представлению извлечённых данных с помощью NSFetchRequest на примере UITableView.

Добро пожаловать! В данной статье вы познакомитесь с ключевой темой операционной системы iOS: которая называется «слои». Вы, скорее всего, уже знаете о View, но вы можете не знать то, что каждое view опирается на то, что называется слоем(layer). Слои являются частью Core Animation фреймворка.

Вы можете сказать, «Какой это имеет смысл? Я никогда ранее не использовал слои, поэтому это может и не быть столь важным.» Знаете ли вы это или нет, но ваше приложение интенсивно использует слои. В iOS каждое представление подтверждается слоем, независимо от того, какое оно. Слои существуют, таким образом, что iOS может легко получить растровую информацию о представлениях, с целью ее дальнейшей передачи для GPU (Устройства Обработки Графики). Посмотрите на изображение ниже, для визуального представления, где Core Animation находиться в иерархии iOS структуры.

Чтобы отказаться от языка программирования, на котором уже ведется коммерческая разработка, и начать учить новый, программистам нужны серьезные основания. Но история ИТ-индустрии знает много случаев, когда выбор за них делало время, и переход происходил как бы сам по себе.

Что заставило множество разработчиков перейти на Objective C? Что сейчас заставляет отказаться от него и выбрать Swift?

Objective C является расширением языка Си, в который были добавлены новые возможности для объектно-ориентированного подхода программирования. Язык использует объектную модель Smalltalk. Полностью совместим с языком программирования Си. Компания Apple долгое время использовала Objective C как основной язык программирования для разработки своих продуктов.

Создателями Objective C являются Брэд Кокс и Том Лав. Они начали работать над ним в начале1980-х годов, когда еще были сотрудниками телекоммуникационной компании ITT Corporation. Примерно в то же время Кокс и Лав познакомились с языком программирования Smalltalk. Кокса тогда занимали проблемы повторного использования программного кода.

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

В этой статье речь пойдет о новой возможности в iOS 10 — Notification Content Extension. Это разновидность расширения, которая позволяет отображать пользователю собственный интерфейс при взаимодействии с уведомлением (remote или local). И отдельно коснемся того, что можно, а что нельзя делать в этом новом расширении — в том числе насколько оно гибко настраивается и конфигурируется.

Не так давно на WWDC 2016 был анонсирован обновленный интерфейс работы с интерактивными анимациями в iOS 10: теперь у разработчиков появился гибкий инструмент их создания, управления и модификации. В этой статье речь пойдет о том, какие произошли изменения и что из себя представляет новое API.

Привет, Хабр!

Недавно вышел AppCode 2016.2, новый релиз нашей IDE для разработки под iOS/OSX. Под катом много гифок и размышлений об автоматизированных рефакторингах в Objective-C и Swift.

В среду, 20 июля, состоялась седьмая встреча Rambler.iOS, которую мы уже анонсировали на Хабре. По просьбам участников предыдущих мероприятий в этот раз было уделено особое внимание общению между разработчиками.

Было заявлено 3 доклада, два из которых были связаны между собой общей темой – мобильные платежи.

В прошлой статье я рассказал о том, как создать простое реактивное приложение для iOS с помощью фреймворка RxSwift. В одном из комментариев прозвучала просьба рассказать про написание unit-тестов для реактивного кода. Я обещал написать об этом после пары других статей про RxSwift. Но меня опередили — то, о чём я собирался писать, прекрасно раскрыто в этой и этой статьях. Я лично хочу его поблагодарить автора за его титанический труд — эти две статьи прочно обосновались в моём избранном и помогают мне в работе.

Ну а мы приступим к написанию тестов!

В жизненном цикле мобильного продукта рано или поздно наступает момент, когда нужно радикально обновиться. Потому что за время, прошедшее с запуска, выросли требования бизнеса и ожидания клиентов, изменились возможности платформы и средства разработки — и обновления становится невозможно реализовать путем “косметического ремонта”. В мире мобильных приложений жизненный цикл ПО составляет 2-3 года против 10-15 лет в обычном Enterprise-сегменте. Для нас с командой “Открытие Digital” момент радикального обновления мобильного банка настал в конце прошлого года.

Раз Swift компилируется в нативный код, то почему бы не попробовать на нём написать модуль ядра? Всех заинтересовавшихся просьба под кат!

Архитектуру улучшая
Оптимизируя коллаж
В таблице получили скорость
И краш

Этим летом мы, команда iOS-разработки холдинга Rambler&Co, хотим пригласить Вас на встречу Rambler.iOS #7, которая состоится 20 июля в нашем офисе на Даниловской мануфактуре. По просьбам участников наших предыдущих мероприятий на этой встрече будет уделено особое внимание общению сообщества между собой и с участниками нашей команды.
Регистрация

А вот о чем мы будем рассказывать в этот раз.

Это заключительная часть статьи о Core Data, предыдущие части доступны здесь: часть 1 и часть 2.

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

Это вторая часть трилогии о Core Data, первая доступна здесь: Core Data + Swift для самых маленьких: необходимый минимум (часть 1).

В первой части мы познакомились с общими сведениями о Core Data, основными компонентами (NSManagedObjectModel, NSPersistentStoreCoordinator, NSManagedObjectContext), Редактором модели данных и создали нашу модель данных.

В этой части мы будем работать с объектами, познакомимся с NSEntityDescription и NSManagedObject, автогенерацией классов, а также напишем вспомогательный класс, существенно повышающий удобство работы с Core Data.

Всем привет! Мы в феврале писали пост о книге «Swift. Основы разработки приложений под iOS». Недавно у нас вышло второе издание:

Данная книга содержит исчерпывающую информацию для всех желающих научиться программировать на замечательном языке Swift и создавать собственные iOS-приложения. Вы найдете не только теоретический материал, но и большое количество практических примеров и заданий, которые позволят постичь все тонкости нового языка. Дерзайте, ведь, изучив Swift, вы сможете создавать приложения для любой платформы — iOS, OS X, tvOS или watchOS.

В сравнении с предыдущим изданием данная книга содержит следующие изменения и дополнения:
— весь материал актуализирован в соответствии со Swift версии 2.2 и Xcode 7.3.
— добавлено большое количество нового учебного материала. В частности, переработана глава 26. Теперь книга не просто обучает Swift, но и готовит вас к полноценной разработке приложений.
‰- учтены пожелания и замечания пользователей по оформлению и содержанию.
‰- исправлены найденные опечатки.

Про Core Data и Swift написано не так много, как хотелось бы, особенно это касается русскоязычного сегмента Интернета. При этом большинство статей и примеров используют довольно примитивные модели данных, чтобы показать только саму суть Core Data, не вдаваясь в подробности. Данной статьей я хотел бы восполнить этот пробел, показав немного больше о Core Data на практическом примере. Изначально, я планировал уместить весь материал в одну статью, но в процессе написания стало ясно, что для одной публикации объем явно великоват, а так как из песни слов не выкинешь, то я все-таки разобью данный материал на три части.

Вместо Введения

Core Data — это мощный и гибкий фреймворк для хранения и управления графом вашей модели, который заслуженно занимает свое место в арсенале любого iOS-разработчика. Наверняка вы, как минимум, слышали об этом фреймворке, и не один раз, и если по каким-то причинам вы его еще не используете, — то самое время начать это делать.