This post is also available in: Английский

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

Интерфейс

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

Главная рекомендация Apple, которую она пытается донести до каждого начинающего разработчка: «Фокусируйтесь на обеспечении наилучшего пользовательского опыта на всех этапах разработки приложения». Основной документ, который подробно описывает, как именно это сделать — iOS Human Interface Guidelines (Рекомендации по разработке пользовательского интерфейса для iOS). С ним обязательно необходимо ознакомиться еще до того, как у вас в голове сформируется полное видение идеи будущего приложения, так как несколько глав в нем посвящены в том числе и этапу проектирования. Перечислим основные идеи HIG:

1. При проектировании интерфейса следуйте соглашениям, принятым на платформе iOS. Не пытайтесь бездумно копировать компоненты и парадигмы принятые на других платформах, в том числе на операционных системах для стационарных компьютеров.
2. В самом начале, на этапе проработки идеи приложения очень важно четко определить какой функционал вы планируете предоставить пользователям и какова ваша целевая аудитория.
3. Постарайтесь использовать в полной мере все доступные на платформе технические и программные средства, но только в том случае, если их использование обосновано для целей вашего приложения. Всегда следуйте рекомендациям Apple по использованию этих технологий.

Особенности платформы iOS, которые обуславливают подход к проектированию пользовательского интерфейса:

• Дисплей: минимальный размер элемента для нажатия пальцем — 44×44 точки, качество элементов оформления очень важно, внимание пользователя сосредоточено на главном содержании приложения, дисплей может поворачиваться в процессе работы приложения.
• Пользователи взаимодействуют с приложением с помощью жестов, а не кликов мышью. Нажатие пальцем на кнопку и клик мышью по кнопке — это не одно и то же.
• По возможности избегайте подсказок по использованию приложения. Интерфейс должен быть интуитивно понятным.
• В каждый момент времени на экране отображается только одно приложение и только один экран внутри этого приложения. Пользователь воспринимает приложение, как набор экранов, между которыми он перемещается.

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

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

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

Архитектура

Базовые представления об архитектуре приложений и основных принципах, используемых при их написании, можно получить из документа iOS App Programming Guide (Руководство по программированию приложений для iOS). Он помогает правильно выбрать архитектурные решения для наиболее эффективной реализации первоначальной идеи в законченном приложении. Этот документ пытается донести до разработчиков следующие основные идеи:

1. Перед тем как начать писать код, изучите основные технологии, которые помогут решить вашу задачу, познакомьтесь с теми паттернами проектирования, которые в них применяются. Всегда следуйте рекомендациям по использованию, приведенным в документации на ту или иную технологию.
2. UIKit — это основной фреймворк, вокруг которого строится большинство приложений. Критически важно иметь представление о том, какие средства он предоставляет, как их правильно применять и кастомизировать в своих приложениях.
3. Приложения необходимо оптимизировать по производительности. На мобильных платформах это прежде всего означает отзывчивость пользовательского интерфейса, разумное использование батареи и общих ресурсов системы, которые разделяются между всеми приложениями.

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

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

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

, интеграция с iCloud, версионирование модели данных.

Производительность

Зачастую заметные пользователю проблемы с производительностью бывают вызваны не нехваткой системных ресурсов, а тем, что приложение блокирует основную очередь задачей, которая слишком долго выполняется. В таких случаях рекомендуется использовать возможности iOS для параллельного выполнения кода. Здесь на выбор разработчику предоставлен целый ряд встроенных библиотек, выполняющих примерно одинаковую задачу: NSThread, POSIX threads, специальные методы NSObject, NSOperation, Grand Central Dispatch. Подробно обо всех этих технологиях и особенностях их использования рассказывается в документе Concurrency Programming Guide (Руководство по параллельному программированию).

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

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

Основные факторы, сказывающиеся на потреблении энергии в ходе работы приложения: нагрузка на процессор, использование модулей Wi-Fi, Bluetooth, 3G, определение местоположения, работа с диском и работа с акселерометром. Желательно минимизировать использование этих ресурсов. Когда вам все-таки приходится их использовать, старайтесь делать это, группируя множество мелких обращений к ресурсу в одно большое.

Приложение Instruments, входящее в комплект среды разработки Xcode, поможет исследовать существующее приложение на предмет наличия в нем проблем с производительностью, утечек памяти и выявить причины расходования заряда батареи.

Переносимость

Операционная система iOS работает на устройствах, характеристики которых различаются. Но пользователи ожидают, что одно и то же приложение будет одинаково хорошо работать на iPod Touch, iPhone 3GS и на последней версии iPad. Для того, чтобы этого добиться, необходимо приложить дополнительные усилия. В идеальном случае интерфейс для планшетов и для телефонов должен разрабатываться независимо. При этом правильное использование паттерна MVC позволит повторно использовать те же модели и контроллеры для разных интерфейсов. В условиях, когда на создание отдельного дизайна у разработчика не хватает времени, необходимо хотя бы предусмотреть гибкое расположение элементов на экране с помощью средств автоматической подстройки геометрии, доступных в классе

.

Не стоит забывать и об остальных различиях между устройствами, кроме размера экрана. Макрос

дает возможность определить тип устройства, на котором выполняется приложение, и в зависимости от этого выполнить тот или иной код. Всегда перед отправкой в App Store тестируйте приложение на разных реальных устройствах.

Проблема поддержки предыдущих версий операционной системы не стоит в iOS так остро, как для других мобильных платформ. Большинство пользователей устанавливают последнюю версию операционной системы в течение нескольких месяцев после ее выхода. Однако часть пользователей продолжает использовать старую версию по разным причинам. Конечно, ответ на вопрос о том, когда можно прекратить поддержку старой версии в своем приложении, в каждом случае решается индивидуально, но и здесь есть несколько общих правил. Иногда сама Apple подает разработчикам четкие сигналы о том, что пора прекратить поддержку старых версий, удаляя ее из новой версии Xcode. Следите за тем, какие версии используют ваши пользователи в App Store. Иногда разработчики популярных приложений публикуют свою статистику распределения аудитории по версиям iOS. Пользователи, склонные платить за приложения и пользоваться встроенными покупками, обычно используют самую последнюю версию iOS.

Используйте проверки доступности символов из новой версии iOS на этапе выполнения приложения. Это позволит задействовать новые функции при их наличии в приложении, которое изначально было рассчитано на более старую версию iOS. SDK дает возможность проверить доступность заданного класса, метода или функции. Подробности можно найти в SDK Compatibility Guide (Руководство по обеспечению совместимости SDK).

Процесс разработки

Документ Developing for the App Store (Разработка для App Store) описывает административные процедуры, которые необходимо пройти для того, чтобы разместить свое приложение в App Store, а также дает рекомендации по организации процесса разработки приложения.

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

На этапе тестирования может возникнуть необходимость рассылать сборки приложения тестировщикам для ручной проверки или заказчикам для уточнения требований. Портал TestFlight помогает автоматизировать процесс рассылки сборок, сбора отзывов и крэш-логов. Чтобы автоматизировать в том числе и сам процесс сборки, полезно применять инструменты Continuos Integration (CI), такие как Jenkins.

Работа над приложением не прекращается после того, как оно опубликовано в App Store. Очень важно исправлять ошибки и реагировать на комментарии пользователей. Информацию о падениях приложения можно получить на портале iTunes Connect, куда отправляются крэш-логи пользователей. Но эта функция iTunes Connect не всегда работает хорошо: до разработчиков доходит только малая часть отправленных логов и со значительной задержкой. Существуют и сторонние средства, позволяющие решать аналогичную задачу, например, Airbrake, Errbit.

Работа в команде

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

По вопросам правильного написания кода существует столько мнений, сколько и программистов. Компания Apple свела все наилучшие рекомендации по этим вопросам в документе Coding Guidelines for Cocoa (Руководство по написанию кода для Cocoa). Все их запомнить с первого раза довольно сложно, поэтому полезно обращаться к этому документу, как к справочнику, непосредственно во время написания кода. Перечислим лишь некоторые из правил:

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

  1	- (NSString *)title;

  и

  1	- (void)setTitle:(NSString *)aTitle;

  .

Поддержка систем контроля версий Git и Subversion встроена непосредственно в Xcode. Среда предлагает создать репозиторий одновременно с созданием проекта, разработчику остается лишь не забывать пользоваться теми возможностями, которые ему предоставляются. На сегодняшний день наиболее популярной системой можно считать Git. Существует множество рекомендаций по ее наиболее правильному и эффективному использованию. Часть из них перечислена в официальной документации Git, которую нужно прочитать просто для того, чтобы осознать все возможности системы и понять, как ими пользоваться. Хотя Xcode и предоставляет доступ к некоторым функциям системы Git, мы все же рекомендуем в первую очередь ознакомиться с ее интерфейсом командной строки. Наиболее заметная функция, которая отсутствует в Xcode, — это функция трехстороннего разрешения конфликтов при слиянии изменений, полученных от других разработчиков. Для этой цели наиболее подходящий инструмент на платформе Mac OS X по нашему мнению — P4Merge. Процесс его интеграции с Git не столь очевиден, как хотелось бы, но в интернете существуют пошаговые инструкции о том, как это сделать.

Статья Commit Often, Perfect Later, Publish Once: Git Best Practices дает краткую выжимку всех основных рекомендаций по работе с Git. Из-за того, что Git — это очень мощная система с множеством различных функций, даже такое краткое перечисление на самом деле довольно длинное. Приведем список того, что нам кажется наиболее важным для начинающих разработчиков:

• Читайте документацию по системе Git.
• Делайте коммиты как можно чаще. Только в этом случае Git гарантирует сохранность всей истории изменений, и появляется возможность найти то изменение, которое вызвало сбой.
• Сформулируйте для своей команды правила workflow и старайтесь их придерживаться. Пример таких правил можно найти на странице Gitflow.
• Разделяйте код, относящийся к разным проектам, по разным репозиториям. Используйте функциональность субмодулей для подключения сторонних библиотек к своему проекту.
• Пишите описания коммитов, которые полезны остальным разработчикам. Они должны включать: суть сделанных правок, причину, по которой было сделано изменение, ссылку на задачу в системе управления задачами.
• Используйте сопутствующие инструменты: gitolite для контроля доступа, gerrit для code review, gitk для поиска по истории изменений и т.д. Интегрируйте систему контроля версий с теми инструментами, которые вы уже используете: система управления задачами, чаты и мессенджеры, вики, списки рассылки, система Continuous Integration.

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

* * *

Приведенные здесь рекомендации — лишь малая часть всех существующих правил и установившихся практик по разработке приложений для iOS. Но пусть это вас не пугает. Многие из них применимы и в программировании для других платформ. Старайтесь шаг за шагом постепенно внедрять их в ваш процесс разработки, чтобы каждое ваше следующее приложение было лучше предыдущего. Желаем успехов!