Xcode *

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



Здесь есть один важный момент для начинающих разработчиков, которые горят желанием связать свою жизнь с миром ИТ-индустрии. Вы должны определить для себя максимально комфортную стратегию самообразования. Одному нужно регулярно решать практические задания, другой не сдвинется с места, пока не разберётся в тонких нюансах теории. Ведь подавляющее большинство, не смотря на чистоту своих намерений, имеют основную работу, семью, друзей, хобби… И так или иначе, весь этот рутинный водоворот влияет на время и качество вашего обучения. И может привести к тому, что вы забросите свои ежедневные занятия в долгий ящик и больше никогда к ним не вернётесь.

Лично для себя я определил, что максимально комфортный способ разработки, это когда я могу видеть целостную наглядную картину своего результата в виде игры, или приложения. В качестве платформы я выбрал IOS и сопутствующий язык Apple — objective-C. Для игрового фреймворка отлично подошел cocos2d-iphone. Он простой, бесплатный, а так же имеет огромное количество примеров и туториалов в интернете.

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

Совсем недавно я уже писал о том, сколько нужно получить загрузок для ТОП-10 бесплатных игр App Store. Сегодня хочу продолжить эту тему и рассказать о более значительных рубежах в рейтингах онлайн-магазина от Apple, а также о том сколько органических инсталлов можно получить с самых высоких позиций. Мне правда, так и не удалось поднять на первое место общего ТОПа, но я был к этому очень близок, и помешала мне только компания Viber. В общем дело было так:

На 31 августа был запланирован релиз моей игры 1-2-3-4 Premium. В российском App Store она стала видна на день раньше в 21:00 по московскому времени, и тут же началась активная PR-кампания. В ТОП-10 игр удалось попасть уже к 14:00, и для этого, как и в прошлый раз мне понадобилось около 6000 загрузок, которые, правда, на этот раз удалось сделать менее чем за сутки, потратив около 500 долларов.

9 сентября выйдет новый релиз iOS и OS X. Времени остается все меньше, и многие разработчики уже оптимизировали свои приложения для работы на новых ОС. Тем, кто этого ещё не сделал, предлагаю коротко рассмотреть, что необходимо для поддержки iOS 9.

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

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

В фары добавляются следящие элементы для предотвращения столкновения. Дно отслеживает разметку, чтобы автомобиль не ушел с дороги. В автомобиле все больше электронного управления. Wired показал удаленное управление Jeep. Хотя водитель был предупрежден, ему явно было не по себе. Больше внимания безопасности, товарищи. Больше внимания.

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

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


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

Вступление

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

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