Пока все с нетерпением ждут новый iPhone и стабильную версию iOS 9, которые будут представлены на презентации Apple 9 сентября, мы собрали для вас подборку интересных материалов этой недели.

Кстати, про iOS 9. Начиная с нее, Apple будет дополнительно предупреждать пользователя при попытке установить Enterprise-приложение напрямую, без MDM. Такое вот небольшое стимулирование. Небольшое на первом шаге. Внутренний параноик говорит: «Сейчас у Apple нет полной связки для доставки Enterprise, Apple не контролирует цепочку, но может начать».

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

Зачастую эту информацию прячут где-нибудь, например, в приложении Яндекс.Маркет, нужно ткнуть в раздел Кабинет и выбрать пункт «О приложении»:


Для удобства (или потому, что этот экран ещё не готов), можно вынести эту полезную информацию прямо на иконку приложения.

Вступление

Всем привет, меня зовут Григорий, последние 5 лет занимался программированием под iOS. Сейчас решил сменить сферу деятельности и ударился в веб, но чтобы добро не пропадало, хочу поделиться с сообществом своими наработками, накопившимися за это время. Библиотеки выложены на GitHub и добавлены в CocoaPods. Инструкции по установке и использованию вы сможете найти по ссылкам на GitHub, здесь же будет краткое описание.

Минимальная поддерживаемая версия — iOS 6.0.

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

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

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

В заголовочном файле 279 строк, в файле реализации 2948 строк.
Привет, ⌘F, я не скучал.

Во время разработки iOS/OSX-приложений непременно приходится использовать Interface Builder и Auto Layout. В приложениях со сложными интерфейсом и в приложениях, находящихся в разработке достаточно давно, часто появляется проблема с большим количеством «исключенных констрейнов». Storyboard грузится необоснованно долго, а во время перехода между сценами можно успеть сходить за кофе.

Но, казалось бы, интерфейс всех контроллеров такой же незамысловатый, как и в релизе полгода назад. Что же случилось? Тем, кто использовал Size Classes, сразу понятно, что интерфейс — не такая простая штука, как кажется. Он ведет себя по-разному в разных ориентациях и на разных дисплеях. Делает он это, потому что некоторые constraints применяются только в определенной ситуации.

Это значит, что в остальных ситуациях эти constraints не используются. У Xcode Interface Builder есть особенность, которая помогает при разработке сложных интерфейсов и мешает при разработке простых. Если добавить constraint к какому-то UIView и затем удалить его из Xcode Inspector (а чаще всего это — самый удобный путь), Xcode не удалит его, а лишь сложит в список неиспользуемых на случай, если понадобится для другого дисплея или ориентации.

Иногда, если развернуть все группы constraints, можно ужаснуться происходящему в storyboard-файле:


Не хотите наблюдать подобное? Добро пожаловать под кат!

В сети можно найти множество туториалов, обучающих работе со встроенными фреймворками и сторонними библиотеками для iOS. Но редко можно встретить статьи, рассказывающие об общих вещах. Таких, как, например, создание удобной структуры проекта.

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

Добрый день, уважаемые хаброжители!

Images.xcassets даёт много приятных вещей, особенно мне нравятся Slicing и возможность добавить отдельную картинку для каждого типа устройства. Поэтому, начиная новый проект, я, даже не задумываясь, создаю Images.xcassets, добавляю туда иконки и splash, а потом и все новые ресурсы кидаю туда же. Сегодня я узнал пару неприятных вещей о xcassets, это заставило меня отказаться от него и потратить пару часов на переделку проекта. Не самое приятное и благодарное занятие. Если вы хотите учиться на чужих ошибках, прошу под кат.

CocoaPods — это очень мощный инструмент, имеющий статус must have для любого iOS Developer'а. С помощью него мы можем легко, быстро и просто подключать различные вкусные тулзы, утилиты и библиотеки, которые значительно облегчают нам жизнь при разработке приложений. Но всяким инструментом надо уметь пользоваться и CocoaPods не исключение.
Под катом информация, которая позволит начать освоение этого инструмента (основано на том, что изложено в документации и собственном опыте). И так, дорогой читатель, отложи в сторону микроскоп, хватит уже им гвозди заколачивать и продолжай читать.

Данная статья посвящена вопросу тестирования в рамках Objective-C используя Xcode 6. Рассматриваются стандартная библиотека для тестирования и сторонняя библиотека OCMock. Опытные разработчики, возможно, не найдут здесь слишком полезной информации, тем же, кто недавно встал на этот путь — статья откроет необходимые базовые знания по написанию unit-тестов на языке Objective-C.

Для основы тестирования просьба обратиться сюда.
Для основы unit-тестирования сюда.

А теперь мы начнем изучение unit-тестирования в рамках Objective-C.

При проектировании iOS приложений со многими MVC приходится решать вопросы передачи информации от одного MVC к другому как в прямом, так и в обратном направлении. Передача информации в прямом направлении при переходе от одного MVC к последующему осуществляется обычно установкой Mодели того MVC, куда мы переходим, а вот передача информации «назад» из текущего MVC в предшествующий осуществляется с помощью делегирования как в Objective-C, так и в Swift.

Кроме того, делегирование используется внутри одного MVC между View и Controller для их «слепого взаимодействия».

Дело в том, что Views — слишком обощенные (generic) стандартизованные строительные блоки, они не могут что-то знать ни о классе, ни о Controller, который их использует. Views не могут владеть своими собственными данными, данные принадлежат Controller. В действительности, данные могут находиться в Mодели, но Controller является ответственным за их предоставление. Тогда как же  View может общаться с Controller? С помощью делегирования.

Нужно выполнить 6 шагов, чтобы внедрить делегирование во взаимодействие View и Controller:

1. Создаем протокол делегирования (определяем то, о чем View хочет, чтобы Controller позаботился)
2. Создаем в View weak свойство delegate, типом которого будет протокол делегирования
3. Используем в View свойство delegate, чтобы получать данные/ делать вещи, которыми View  не может владеть или управлять
4. Controller объявляет, что он реализует протокол
5. Controller устанавливает self (самого себя) как делегата View путем установки свойства в пункте #2, приведенном выше
6. Реализуем протокол в Controller

Мы видим, что делегирование — не простой процесс.
Как в Swift, так и в Objective-C, процесс делегирования можно заменить использованием замыканий (блоков), принимая во внимание их способность захватывать любые переменные из окружающего контекста для внутреннего использования. Однако в Swift реализация этой идеи существенно упрощается и выглядит более лаконичной, так как  функции (замыкания) в Swift являются «гражданами первого сорта», то есть могут объявляться переменными и передаваться как параметры функций. Простота и абсолютная ясность кода в Swift позволят более широко использовать замыкания (closures), захватывающие контекст, для взаимодействия двух MVC или взаимодействия Controller и View без применения делегирования.

Я хочу показать использование захвата контекста замыканиями на двух примерах, взятых из стэнфордского курса 2015 «Developing iOS 8 Apps with Swift» (русский эквивалент находится на сайте «Разработка iOS+Swift+Objective-C приложений»).

Один пример будет касаться взаимодействия View  и Controller в пределах одного MVC, а другой — двух различных MVC. В обоих случаях  захват контекста замыканиями позволит нам заменить делегирование более простым и элегантным кодом, не требующим вспомогательных протоколов и делегатов.

Заинтересовавшись публикацией «Пишем свой Xcode plugin» решил написать простой тайм-трекер для Xcode. Процесс, через который я прошел — суть данной статьи. В ней мы с вами разберём несколько плагинов, которые помогут писать другие плагины быстрее и эффективнее.

Основная идея любого плагина с интерфейсом состоит в том, что он интегрируется в UI Xcode'a и выглядит максимально родным для него. Но как только мы смотрим на окно Xcode, сразу же встает вопрос: «Как понять где какой объект и как нам интегрироваться в нужный нам?» Так на нашем пути появляется первый плагин. Мы напишем простой плагин, который будет загружаться в Xcode и говорить, где какой объект расположен.

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

Как переводчик заранее прошу извинения за возможные ошибки в переводе. Буду признателен сообщениям об ошибках для их скорейшего исправления.

Когда iOS 7 была впервые анонсирована, одним из многих визуальных нововведений, которое особенно заинтересовало меня, был жест swipe-to-delete (смахни чтобы удалить) в приложении Mail. Вы уже давно прекрасно знакомы с этой функцией приложения. После того как проводите по ячейке таблицы, вы видите кнопки корзины, дополнительных опций («Ещё») и пометки письма флагом. При нажатии на кнопку «Ещё» становится активной панель выбора действия, на которой вы можете выбрать одну из опций действия с письмом — Ответить, Пометить флагом и т.д.

Думаю, что это отличный инструмент для манипулирования записями таблицы. Однако, как вы прекрасно знаете что Apple не предоставляет этой возможности для разработчиков в iOS 7. Вы можете только добавить жест для функции удаления записи из таблицы. Остальные опции работы с записью таблицы ограничены стандартным приложением Mail. Понятия не имею почему Apple ограничивает использование такого прекрасного инструмента только своими приложениями. К счастью, некоторые разработчики создали решения (такие как UITableView-Swipe-for-Options, MCSwipeTableViewCell) и сделали их абсолютно бесплатными.

В этом уроке я буду использовать библиотеку SWTableViewCell. Посмотрим, как она поможет нам реализовать функцию swipe-to-show-options (смахни чтобы увидеть опции) в вашем приложении. SWTableViewCell достаточно проста в использовании и если вы понимаете как работает UITableView, у вас не должно возникнуть проблем с SWTableViewCell. Кроме того, этот компонент поддерживает отображение кнопок опций при свайпе в обе стороны. Вы быстро поймете что это значит.

Итак, давайте приступим и создадим наше демонстрационное приложение.

Как переводчик заранее прошу извинения за возможные ошибки в переводе. Буду признателен сообщениям об ошибках для их скорейшего исправления.

Как я могу добавить панель бокового меню в свое iOS-приложение? Это один из самых часто задаваемых вопросов которые мы получаем от своих читателей. Сегодня мы покажем как создать боковое меню вроде того, которое вы можете наблюдать, например, в приложении от Facebook.

Для тех кто не знаком с понятием бокового меню в мобильных приложениях, Кен Ярмост (Ken Yarmost) дал хорошее объяснение этому элементу интерфейса и определил его как:

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

С того момента как Facebook представил боковое меню в своем мобильном приложении, этот элемент интерфейса быстро стал стандартом реализации навигации по приложению. В том или ином виде вы можете видеть боковое меню в таких популярных приложениях как Path, Mailbox, Gmail, Evernote и т.д.



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

Добрый день, хаброжители,

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

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

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

Добрый день. Я хотел бы рассказать о том, как можно облегчить поддержку iOS приложений.

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

Всем, кто создавал iOS приложение, и оно доходило хотя бы до открытого β-тестирования, скорее всего, знакома фраза: “Я тут поигрался с приложением и вот что получилось...”. И вот после этой фразы вы могли провести несколько часов, пытаясь понять, как же «это» получилось.

Если вам знакома эта ситуация, или хочется узнать о том, как спасти себя от такого в будущем — прошу под кат.

Многие разработчики затрудняются ответить на вопрос “для кого вы это создаете?”. Как показывают опросы и богатый личный опыт в большинстве своем ответы на подобные вопросы звучат слишком расплывчато или вообще являются догадками.



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

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

Разработка программных продуктов — очень интересный процесс, который нам всем очень-очень нравится, но есть некоторые вещи, которые слишком монотонны. Сегодня я бы хотел рассказать про то, как я упростил свой рабочий процесс в Xcode с помощью различных сторонних плагинов.



Заинтересованных прошу под кат

Дорогие читатели, я придумал для себя интересное хобби, которое принесет ощутимую пользу не только мне, но и вам. Так как сейчас я активно занимаюсь прокачкой своего навыка в создании игр, мне приходится изучать тонны различной информации по этой теме, а много полезной информации можно найти исключительно в буржнете. Я сам не очень люблю читать информацию на не родном для меня языке, поэтому я решил убить сразу целую стаю зайцев: совершенствовать свой язык переводя статьи, совершенствовать свои навыки как геймдизайнера, приносить пользу другим делясь интересным материалом. Погнали.



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

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

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

1. За пределами алхимии

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

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

А что если бы мы декодировали эти системы и превратили бы их в практическую методику создания игр?