Структуры пакета
Структуры пакета могут варьироваться в зависимости от типа пакета и целевой платформы. Следующие разделы описывают структуры пакета, используемые обычно и в OS X и в iOS.
Комплекты приложений
Комплекты приложений являются одним из наиболее распространенных типов пакета, создаваемого разработчиками. Комплект приложений хранит все, чего приложение требует для успешной операции. Несмотря на то, что определенная структура комплекта приложений зависит от платформы, для которой Вы разрабатываете, способом, которым Вы используете пакет, является то же на обеих платформах. В этой главе описываются структуру комплектов приложений и в iOS и в OS X.
Какие файлы входят в комплект приложений?
Таблица 2-1 суммирует типы файлов, которые Вы, вероятно, найдете в комплекте приложений. Точное расположение этих файлов варьируется от платформы до платформы, и некоторые ресурсы не могут поддерживаться вообще. Для примеров и более подробной информации, посмотрите специфичные для платформы разделы пакета в этой главе.
Файл | Описание |
|---|---|
| (Требуемый) информационный файл списка свойств является структурированным файлом, содержащим конфигурационную информацию для приложения. Система полагается на присутствие этого файла для идентификации релевантной информации о приложении и любых связанных файлах. |
Исполнимая программа | (Требуемый) Каждое приложение должно иметь исполняемый файл. Этот файл содержит основную точку входа приложения и любой код, статически соединенный с целью приложения. |
Файлы ресурсов | Ресурсы являются файлами данных, живущими вне исполняемого файла Вашего приложения. Ресурсы обычно состоят из вещей как изображения, значки, звуки, файлы пера, строковые файлы, конфигурационные файлы и файлы данных (среди других). Файлы ресурсов могут быть локализованы для определенного языка или области или совместно использованы всеми локализациями. Размещение файлов ресурсов в структуре каталогов пакета зависит от того, разрабатываете ли Вы приложение Mac или iOS. |
Другие файлы поддержки | Приложения Mac могут встроить дополнительные высокоуровневые ресурсы, такие как частные платформы, плагины, шаблоны документов и другие пользовательские информационные ресурсы, являющиеся неотъемлемой частью приложения. Несмотря на то, что можно включать пользовательские информационные ресурсы в пакеты приложения для iOS, Вы не можете включать пользовательские платформы или плагины. |
Несмотря на то, что большинство ресурсов в комплекте приложений является дополнительным, это может не всегда иметь место. Например, приложения для iOS обычно требуют дополнительных ресурсов изображения для значка приложения и экрана по умолчанию. И несмотря на то, что не явно требуемый, большинство приложений Mac включает пользовательский значок вместо значения по умолчанию одно предоставленное системой.
Анатомия Пакета приложения для iOS
Шаблоны проекта, предоставленные XCode, выполняют большую часть работы, необходимой для установки пакета для Вашего iPhone или приложения для iPad. Однако понимание структуры пакета может помочь Вам решить, куда необходимо поместить собственные файлы. Структура пакета приложений для iOS приспособлена больше к потребностям мобильного устройства. Это использует относительно плоскую структуру с немногими посторонними каталогами, чтобы сохранить дисковое пространство и упростить доступ к файлам.
Структура Пакета приложения для iOS
Типичный пакет приложения для iOS содержит исполнимую программу приложения и любые ресурсы, используемые приложением (например, значок приложения, другие изображения, и локализовал содержание) в каталоге пакета верхнего уровня. Перечисление 2-1 показывает структуру простого вызванного приложения для iPhone MyApp. Единственные файлы, требующиеся, чтобы быть в подкаталогах, являются теми, которые должны быть локализованы; однако, Вы могли создать дополнительные подкаталоги в своих собственных приложениях для организации ресурсов и других соответствующих файлов.
Структура Пакета перечисления 2-1 приложения для iOS
MyApp.app |
MyApp |
MyAppIcon.png |
MySearchIcon.png |
Info.plist |
Default.png |
MainWindow.nib |
Settings.bundle |
MySettingsIcon.png |
iTunesArtwork |
en.lproj |
MyImage.png |
fr.lproj |
MyImage.png |
Таблица 2-2 описывает содержание приложения, показанного в Перечислении 2-1. Несмотря на то, что само приложение в демонстрационных целях только, многие файлы, которые оно содержит, представляют определенные файлы, которые iOS ищет при сканировании комплекта приложений. Ваши собственные пакеты включали бы некоторых или все эти файлы в зависимости от функций, которые Вы поддерживаете.
Файл | Описание |
|---|---|
| (Требуемый) исполняемый файл, содержащий код Вашего приложения. Имя этого файла совпадает с Вашим именем приложения минус |
Значки приложения ( | (Требовал/Рекомендовал), чтобы Значки приложения использовались в определенные времена для представления приложения. Например, различные размеры значка приложения выведены на экран в домашнем экране в результатах поиска, и в приложении Настроек. Не все значки требуются, но большинство рекомендуется. Для получения информации о значках приложения посмотрите Изображения Значка приложения и Запуска. |
| (Требуемый) Этот файл содержит конфигурационную информацию для приложения, такого как его пакет ID, номер версии и имя дисплея. Посмотрите информационный Файл Списка свойств для получения дополнительной информации. |
Изображения запуска ( | (Рекомендуемый) или больше изображений, показывающих начальный интерфейс Вашего приложения в определенной ориентации. Система использует одно из предоставленных изображений запуска как временный фон до Ваших загрузок приложения его окно и пользовательский интерфейс. Если Ваше приложение не обеспечивает изображений запуска, черный фон выведен на экран, в то время как запускается приложение. Для получения информации о значках приложения посмотрите Изображения Значка приложения и Запуска. |
| (Рекомендуемый) основной файл пера приложения содержит интерфейсные объекты по умолчанию загрузиться во время запуска приложения. Как правило, этот файл пера содержит объект главного окна приложения и экземпляр делегата приложения объект. Другие интерфейсные объекты тогда или загружаются из дополнительных файлов пера или создаются программно приложением. (Имя основного файла пера может быть изменено путем присвоения различного значения |
| Пакет Настроек является специальным типом плагина, содержащего любые специализированные предпочтения, которые Вы хотите добавить к приложению Настроек. Этот пакет содержит списки свойств и другие файлы ресурсов, чтобы сконфигурировать и вывести на экран Ваши предпочтения. |
Пользовательские файлы ресурсов | Нелокализованные ресурсы помещаются в высокоуровневый каталог, и локализованные ресурсы помещаются в специфичные для языка подкаталоги комплекта приложений. Ресурсы состоят из файлов пера, изображений, звуковых файлов, конфигурационных файлов, строковых файлов и любых других пользовательских файлов данных, в которых Вы нуждаетесь для своего приложения. Для получения дополнительной информации о ресурсах, посмотрите Ресурсы в приложении для iOS. |
Приложение для iOS должно интернационализироваться и иметь язык.lproj папка для каждого языка это поддерживает. В дополнение к обеспечению локализованных версий пользовательских ресурсов Вашего приложения можно также локализовать значки приложения и запустить изображения путем размещения файлов с тем же именем в специфичных для языка каталогах проекта. Даже при обеспечении локализованных версий, однако, необходимо всегда включать версию по умолчанию этих файлов на верхнем уровне комплекта приложений. Версия по умолчанию используется в ситуациях, где определенная локализация не доступна. Для получения дополнительной информации о локализованных ресурсах, посмотрите Локализованные Ресурсы в Пакетах.
Информационный файл списка свойств
Каждое приложение для iOS должно иметь информационный список свойств (Info.plist) файл, содержащий информацию о подтверждении приложения. При создании нового проекта приложения для iOS XCode создает этот файл автоматически и устанавливает значение некоторых ключевых свойств для Вас. Таблица 2-3 перечисляет некоторые дополнительные ключи, которые необходимо установить явно. (XCode затеняет фактические ключевые имена по умолчанию, таким образом, строка, выведенная на экран XCode, также перечислена в круглой скобке, где каждый используется. Вы видите реальные ключевые имена для всех ключей Щелчком управления информационный ключ Списка свойств в редакторе и выборе Show Raw Keys/Values из появляющегося контекстного меню.)
Ключ | Значение |
|---|---|
| Имя дисплея пакета является именем, выведенным на экран под значком приложения. Это значение должно быть локализовано для всех поддерживаемых языков. |
| Строка идентификатора пакета идентифицирует Ваше приложение для системы. Эта строка должна быть универсальным идентификатором типа (UTI), содержащим только алфавитно-цифровой ( Идентификатор пакета используется в проверке подписи приложения. |
| Строка версии комплекта указывает число версии сборки пакета. Это значение является монотонно увеличенной строкой, состоявшей из один или несколько разделенные от периода целые числа. Это значение не может быть локализовано. |
| Массив строк, содержащих имена файлов изображений, используется для различных значков приложения. Несмотря на то, что технически не требуемый, это строго мотивировано, что Вы используете его. Этот ключ поддерживается в iOS 3.2 и позже. |
| Булево значение, указывающее, может ли пакет работать на iOS только. XCode добавляет этот ключ автоматически и устанавливает его значение в истину. Вы не должны изменять значение этого ключа. |
| Ключ, говорящий iTunes и App Store, знает, каких связанных с устройством функций приложение требует для выполнения. iTunes и Хранилище мобильного приложения используют этот список, чтобы препятствовать тому, чтобы клиенты установили приложения на устройстве, не поддерживающем перечисленные возможности. Значение этого ключа является или массивом или словарем. При использовании массива присутствие данного ключа указывает, что требуется соответствующая функция. При использовании словаря необходимо указать булево значение для каждого ключа, указывающего, требуется ли функция. В обоих случаях, не включая ключ указывает, что не требуется функция. Для списка ключей для включения в словарь посмотрите информационную Ключевую Ссылку Списка свойств. Этот ключ поддерживается в iOS 3.0 и позже. |
В дополнение к ключам в предыдущей таблице Таблица 2-4 перечисляет некоторые ключи, обычно использующиеся приложениями для iOS. Несмотря на то, что эти ключи не требуются, большинство обеспечивает способ скорректировать конфигурацию Вашего приложения во время запуска. Обеспечение этих ключей может помочь гарантировать, что Ваше приложение представлено соответственно системой.
Параграф | Параграф |
|---|---|
| Строка, идентифицирующая имя основного файла пера приложения. Если Вы хотите использовать файл пера кроме значения по умолчанию один создаваемый для Вашего проекта, связать имя того файла пера с этим ключом. Имя файла пера не должно включать |
| Строка, идентифицирующая стиль строки состояния как приложение, запускается. Это значение основывается Если Вы не указываете этот ключ, iOS выводит на экран строку состояния по умолчанию. |
| Булево значение, определяющее, скрыта ли строка состояния первоначально, когда запускается приложение. Установите его в истину для сокрытия строки состояния. Значение по умолчанию |
| Строка, идентифицирующая начальную ориентацию пользовательского интерфейса приложения. Это значение основывается |
| Булево значение, указывающее, включает ли значок приложения уже блеск и косоугольные эффекты. Значение по умолчанию |
| Булево значение, уведомляющее систему, что приложение использует сеть Wi-Fi для коммуникации. Приложения, использующие Wi-Fi в течение любого промежутка времени, должны установить этот ключ к Даже если значение этого свойства |
| Строка, содержащая основное имя файла, используется изображениями запуска приложения. Если Вы не указываете этот ключ, базовое имя взято, чтобы быть строкой |
Значок приложения и изображения запуска
Значки приложения и изображения запуска являются стандартной графикой, которая должна присутствовать в каждом приложении. Каждое приложение должно указать значок, который будет выведен на экран на домашнем экране устройства и в App Store. И приложение может указать несколько различных значков для использования в различных ситуациях. Например, приложения могут обеспечить небольшую версию значка приложения для использования при отображении результатов поиска. Изображения запуска предоставляют визуальную обратную связь пользователю, которого запустило Ваше приложение.
Файлы образа, используемые для представления значков и изображений запуска, должны все находиться на корневом уровне пакета. То, как Вы идентифицируете эти изображения для системы, может варьироваться, но рекомендуемый способ указать Ваши значки приложения состоит в том, чтобы использовать CFBundleIconFiles ключ. Для получения дальнейшей информации о том, как указать значки и изображения запуска в Вашем приложении, посмотрите обсуждение этих элементов в Усовершенствованных Приемах Приложения в Руководстве по программированию приложения для iOS.
Ресурсы в приложении для iOS
В приложении для iOS нелокализованные ресурсы расположены на верхнем уровне каталога пакета, вместе с исполняемым файлом приложения и Info.plist файл. Большинство приложений для iOS имеет, по крайней мере, несколько файлов на этом уровне, включая значок приложения, изображение запуска и один или несколько файлов пера. Несмотря на то, что необходимо поместить наиболее нелокализованные ресурсы в этот каталог верхнего уровня, можно также создать подкаталоги для организации файлов ресурсов. Локализованные ресурсы должны быть помещены в один или несколько специфичные для языка подкаталоги, обсужденные более подробно в Локализованных Ресурсах в Пакетах.
Перечисление 2-2 показывает вымышленное приложение, включающее и локализованные и нелокализованные ресурсы. Нелокализованные ресурсы включают Hand.png, MainWindow.nib, MyAppViewController.nib, и содержание WaterSounds каталог. Локализованные ресурсы включают все в en.lproj и jp.lproj каталоги.
Перечисление 2-2 приложение для iOS с локализованными и нелокализованными ресурсами
MyApp.app/ |
Info.plist |
MyApp |
Default.png |
Icon.png |
Hand.png |
MainWindow.nib |
MyAppViewController.nib |
WaterSounds/ |
Water1.aiff |
Water2.aiff |
en.lproj/ |
CustomView.nib |
bird.png |
Bye.txt |
Localizable.strings |
jp.lproj/ |
CustomView.nib |
bird.png |
Bye.txt |
Localizable.strings |
Для получения информации о нахождении файлов ресурсов в Вашем комплекте приложений посмотрите Доступ к Содержанию Пакета. Для получения информации о том, как загрузить файлы ресурсов и использовать их в Вашей программе, видит Руководство по программированию Ресурса.
Анатомия комплекта приложений OS X
Шаблоны проекта, предоставленные XCode, выполняют большую часть работы, необходимой для установки Вашего комплекта приложений Mac во время разработки. Однако понимание структуры пакета может помочь Вам решить, куда необходимо поместить собственные файлы. Пакеты OS X используют высоко организованную структуру, чтобы упростить для загружающего пакет кода находить ресурсы и другие важные файлы в пакете. Иерархическая природа также помогает системе отличить пакеты кода, такие как приложения от пакетов каталога, используемых другими приложениями для реализации типов документов.
Структура комплекта приложений OS X
Базовая структура комплекта приложений Mac очень проста. На верхнем уровне пакета названный каталог Contents. Этот каталог содержит все, включая ресурсы, исполняемый код, частные платформы, частные плагины и файлы поддержки, необходимые приложению. В то время как Contents каталог мог бы казаться лишним, он идентифицирует пакет как пакет современного стиля и отделяется, он из документа и наследства связывает типы, найденные в более ранних версиях Mac OS.
Перечисление 2-3 показывает высокоуровневую структуру пакета типового приложения, включая непосредственные файлы и каталоги, которые Вы, наиболее вероятно, найдете в Contents каталог. Эта структура представляет ядро каждого приложения Mac.
Перечисление 2-3 базовая структура приложения Mac
MyApp.app/ |
Contents/ |
Info.plist |
MacOS/ |
Resources/ |
Таблица 2-5 перечисляет некоторые каталоги, которые Вы могли бы найти в Contents каталог, вперед с целью каждого. Этот список не является исчерпывающим, но просто представляет каталоги в общем использовании.
Каталог | Описание |
|---|---|
| (Требуемый) Содержит автономный исполняемый код приложения. Как правило, этот каталог содержит только один двоичный файл с основной точкой входа Вашего приложения и статически соединенным кодом. Однако можно поместить другие автономные исполнимые программы (такие как инструменты командной строки) в этом каталоге также. |
| Содержит все файлы ресурсов приложения. Это удовлетворяет этого каталога, далее организованы для различения локализованные и нелокализованные ресурсы. Для получения дополнительной информации о структуре этого каталога, см. Каталог Ресурсов |
| Содержит любые частные совместно используемые библиотеки и платформы, используемые исполнимой программой. Платформы в этом каталоге заблокированы версией к приложению и не могут быть заменены никаким другим, еще более новым, версии, которые могут быть доступны операционной системе. Другими словами, платформы, включенные в этот каталог, имеют приоритет по любым другим столь же именованным платформам, найденным в других частях операционной системы. Для получения информации о том, как добавить частные платформы к Вашему комплекту приложений, см. Руководство по программированию Платформы. |
| Содержит загружаемые пакеты, расширяющие основные характеристики Вашего приложения. Вы используете этот каталог для включения модулей кода, которые должны быть загружены в пространство процесса приложения, чтобы использоваться. Вы не использовали бы этот каталог для хранения автономных исполнимых программ. |
| Содержит дополнительные некритические ресурсы, не влияющие на возможность приложения работать. Вы могли бы использовать этот каталог для включения вещей как шаблоны документов, иллюстрация и учебные руководства, что приложение ожидает присутствовать, но которые не влияют на возможность приложения работать. |
Комплекты приложений развились значительно за эти годы, но полной целью было то же. Организация пакета упрощает для приложения находить свои ресурсы при создании его тяжелее для пользователей для вмешательства в те ресурсы. Поскольку Средство поиска обрабатывает большинство пакетов как непрозрачные объекты, для обычных пользователей трудно переместить или удалить ресурсы, в которых, возможно, нуждалось бы приложение.
Информационный файл списка свойств
Для Средства поиска для распознавания комплекта приложений как такового необходимо включать информационный список свойств (Info.plist) файл. Этот файл содержит данные списка свойств XML, идентифицирующие конфигурацию Вашего пакета. Для минимального пакета этот файл содержал бы очень мало информации, наиболее вероятно просто имя и идентификатор пакета. Для более сложных пакетов, Info.plist файл включает намного больше информации.
Таблица 2-6 перечисляет ключи, которые необходимо всегда включать в Ваш Info.plist файл. XCode обеспечивает все эти ключи автоматически при создании нового проекта. (XCode затеняет фактические ключевые имена по умолчанию, таким образом, строка, выведенная на экран XCode, также перечислена в круглой скобке. Вы видите реальные ключевые имена для всех ключей Щелчком управления информационный ключ Списка свойств в редакторе и выборе Show Raw Keys/Values из появляющегося контекстного меню.)
Ключ | Описание |
|---|---|
| Краткое название для пакета. Значение для этого ключа обычно является именем Вашего приложения. XCode устанавливает значение этого ключа по умолчанию при создании нового проекта. |
| Локализованная версия Вашего имени приложения. Вы обычно включаете локализованное значение для этого ключа |
| Строка, идентифицирующая Ваше приложение для системы. Эта строка должна быть универсальным идентификатором типа (UTI), содержащим только алфавитно-цифровой ( Идентификатор пакета используется в проверке подписи приложения. |
| Строка, указывающая число версии сборки пакета. Это значение является монотонно увеличенной строкой, состоявшей из один или несколько разделенные от периода целые числа. Это значение может соответствовать или выпущенным или невыпущенным версиям приложения. Это значение не может быть локализовано. |
| Тип пакета это. Для приложений значение этого ключа всегда является четырьмя символьными строками |
| Код создателя для пакета. Это - четыре символьных строки, которые являются определенными для пакета. Например, подпись для приложения TextEdit |
| Имя основного исполняемого файла. Это - код, выполняющийся, когда пользователь запускает Ваше приложение. XCode обычно устанавливает значение этого ключа автоматически во время изготовления. |
Таблица 2-7 перечисляет ключи, включая которые необходимо также рассмотреть в Вашем Info.plist файл.
Ключ | Описание |
|---|---|
| Типы документов поддерживаются приложением. Этот тип состоит из массива словарей, каждый из которых предоставляет информацию об определенном типе документа. |
| Версия выпуска приложения. Значение этого ключа является строкой, состоявшей из трех разделенных от периода целых чисел. |
| Минимальная версия OS X, требуемого для этого приложения работать. Значение для этого ключа является строкой формы n.n.n, где каждый n является числом, представляющим или номер основной версии или номер вспомогательной версии требующегося OS X. Например, значение 10.1.5 представляло бы OS X v10.1.5. |
| Уведомление об авторском праве для приложения. Это - человекочитаемая строка и может быть локализовано включением ключа |
| Файл пера для загрузки, когда приложение запускается (без |
| Точка входа для динамично загруженного кода Objective C. Для комплекта приложений это почти всегда |
Точная информация Вы помещаете в Ваш Info.plist файл зависит от потребностей Вашего пакета и может быть локализован по мере необходимости. Для получения дополнительной информации об этом файле см. Инструкции по Конфигурации Во время выполнения.
Каталог ресурсов
Resources каталог - то, куда Вы помещаете все свои изображения, звуки, файлы пера, строковые ресурсы, файлы значков, файлы данных и конфигурационные файлы среди других. Содержание этого каталога далее подразделено на области, где можно сохранить локализованные и нелокализованные файлы ресурсов. Нелокализованные ресурсы находятся на верхнем уровне Resources сам каталог или в пользовательском подкаталоге, который Вы определяете. Локализованные ресурсы находятся в вызванных специфичных для языка каталогах проекта отдельных подкаталогов, которые называют для совпадения с определенной локализацией.
Лучший способ видеть, как Resources каталог организован, должен смотреть на пример. Перечисление 2-4 показывает вымышленное приложение, включающее и локализованные и нелокализованные ресурсы. Нелокализованные ресурсы включают Hand.tiff, MyApp.icns и содержание WaterSounds каталог. Локализованные ресурсы включают все в en.lproj и jp.lproj каталоги или их подкаталоги.
Перечисление 2-4 приложение Mac с локализованными и нелокализованными ресурсами
MyApp.app/ |
Contents/ |
Info.plist |
MacOS/ |
MyApp |
Resources/ |
Hand.tiff |
MyApp.icns |
WaterSounds/ |
Water1.aiff |
Water2.aiff |
en.lproj/ |
MyApp.nib |
bird.tiff |
Bye.txt |
InfoPlist.strings |
Localizable.strings |
CitySounds/ |
city1.aiff |
city2.aiff |
jp.lproj/ |
MyApp.nib |
bird.tiff |
Bye.txt |
InfoPlist.strings |
Localizable.strings |
CitySounds/ |
city1.aiff |
city2.aiff |
Каждый из Ваших специфичных для языка каталогов проекта должен содержать копию того же набора файлов ресурсов, и имя для любого единственного файла ресурсов должно быть тем же через все локализации. Другими словами, только содержание для данного файла должно измениться от одной локализации до другого. Когда Вы запрашиваете файл ресурсов в своем коде, Вы указываете только имя файла, который Вы хотите. Загружающий пакет код использует текущие языковые предпочтения пользователя для решения, какие каталоги искать файл Вы запросили.
Для получения информации о нахождении файлов ресурсов в Вашем комплекте приложений посмотрите Доступ к Содержанию Пакета. Для получения информации о том, как загрузить файлы ресурсов и использовать их в Вашей программе, видит Руководство по программированию Ресурса.
Файл значка приложения
Один специальный ресурс, принадлежащий Вашего верхнего уровня Resources каталог является Вашим файлом значка приложения. Условно, этот файл берет имя пакета и расширение .icns; формат изображения может быть любым поддерживаемым типом, но если никакое расширение не указано, система принимает .icns.
Локализация информационного списка свойств
Поскольку некоторые ключи в приложении Info.plist файл содержит видимые пользователем строки, OS X обеспечивает механизм для указания локализованных версий тех строк. В каждом специфичном для языка каталоге проекта можно включать InfoPlist.strings файл, указывающий надлежащие локализации. Этот файл является строковым файлом (не список свойств), чьи записи состоят из Info.plist ключ Вы хотите локализовать и надлежащий перевод. Например, в приложении TextEdit, немецкая локализация этого файла содержит следующие строки:
CFBundleDisplayName = "TextEdit"; |
NSHumanReadableCopyright = "Copyright © 1995-2009 Apple Inc.\nAlle Rechte vorbehalten."; |
Создание комплекта приложений
Самый простой способ создать комплект приложений использует XCode. Все новые проекты приложения включают соответственно сконфигурированную цель приложения, определяющую правила, должен был создать комплект приложений, включая который исходные файлы скомпилировать, который файлы ресурсов скопировать в пакет, и т.д. Новые проекты также включают предварительно сконфигурированный Info.plist файл и обычно несколько других файлов, чтобы помочь Вам начать быстро. Можно добавить любые пользовательские файлы по мере необходимости с помощью окна проекта и сконфигурировать те файлы с помощью окон Info или Inspector. Например, Вы могли бы использовать окно Info для указания пользовательских расположений для файлов ресурсов в пакете.
Для получения информации о том, как сконфигурировать цели в XCode, посмотрите Руководство по Системе сборки XCode.
Пакеты платформы
Платформа является иерархическим каталогом, инкапсулирующим динамическую совместно используемую библиотеку, и файлы ресурсов должны были поддерживать ту библиотеку. Платформы обеспечивают некоторые преимущества перед типичной динамической совместно используемой библиотекой в этом, они обеспечивают единственное расположение для всех связанных ресурсов платформы. Например, большинство платформ включает заголовочные файлы, определяющие символы, экспортируемые платформой. Группировка этих файлов с совместно используемой библиотекой и ее ресурсами упрощает устанавливать и удалять платформу и определять местоположение ресурсов платформы.
Точно так же, как динамическая совместно используемая библиотека платформы обеспечивают способ факторизовать обычно используемый код в центральное расположение, которое может быть совместно использовано многократными приложениями. Только одна копия кода и ресурсов платформы находится в памяти в любой момент времени, независимо от того, сколько процессов использует те ресурсы. Приложения, соединяющиеся против платформы тогда, совместно используют память, содержащую платформу. Это поведение сокращает объем потребляемой памяти системы и помогает улучшить производительность.
Несмотря на то, что можно создать собственные платформы, опыт большинства разработчиков с платформами прибывает из включения их в их проектах. Платформы - то, как OS X поставляет много главных особенностей Вашему приложению. Общедоступные основы, служившие OS X, расположены в /System/Library/Frameworks каталог. В iOS общедоступные платформы расположены в System/Library/Frameworks каталог надлежащего каталога SDK iOS. Для получения информации о добавляющих платформах к Вашим проектам XCode посмотрите Руководство по Системе сборки XCode.
Для более подробной информации о платформах и пакетах платформы, см. Руководство по программированию Платформы.
Анатомия пакета платформы
Структура пакетов платформы отличается от используемого приложениями и плагинами. Структура для платформ основывается на формате пакета, предшествующем OS X и поддерживающем включение многократных версий кода платформы и ресурсов в пакете платформы. Этот тип пакета известен как имеющий версию пакет. Поддержка многократных версий платформы позволяет более старым приложениям продолжать работать, как раз когда совместно использованная библиотека платформы продолжает развиваться. Пакет Versions в то время как символьные ссылки наверху каталога пакета указывают на последнюю версию, подкаталог содержит отдельные версии платформы.
Система идентифицирует пакет платформы .framework расширение на его имени каталога. Система также использует Info.plist файл в платформе Resources каталог для сбора информации о конфигурации платформы. Перечисление 2-5 показывает базовую структуру пакета платформы. Стрелки (->) в перечислении указывают символьные ссылки на определенные файлы и подкаталоги. Эти символьные ссылки обеспечивают удобный доступ к последней версии платформы.
Перечисление 2-5 простой пакет платформы
MyFramework.framework/ |
MyFramework -> Versions/Current/MyFramework |
Resources -> Versions/Current/Resources |
Versions/ |
A/ |
MyFramework |
Headers/ |
MyHeader.h |
Resources/ |
English.lproj/ |
InfoPlist.strings |
Info.plist |
Current -> A |
Платформы не требуются, чтобы включать a Headers каталог, но выполнение так позволяет Вам включать заголовочные файлы, определяющие экспортируемые символы платформы. Платформы могут сохранить другие файлы ресурсов и в стандартных и в пользовательских каталогах.
Создание пакета платформы
При разработке программного обеспечения для OS X можно создать собственные платформы и использовать их конфиденциально или сделать их доступными для других приложений для использования. Можно создать новую платформу с помощью отдельного проекта XCode или путем добавления цели платформы к существующему проекту.
Для получения информации о том, как создать платформу, см. Руководство по программированию Платформы.
Загружаемые пакеты
Плагины и другие типы загружаемых пакетов обеспечивают способ для Вас расширить поведение приложения динамично. Загружаемый пакет состоит из исполняемого кода, и любые ресурсы должны были поддерживать тот код, сохраненный в каталоге пакета. Можно использовать загружаемые пакеты, чтобы загрузить код лениво в приложение или позволить другим разработчикам расширять основное поведение приложения.
Анатомия загружаемого пакета
Загружаемые пакеты основываются на той же структуре как комплекты приложений. На верхнем уровне пакета сингл Contents каталог. В этом каталоге несколько подкаталогов для хранения исполняемого кода и ресурсов. Contents каталог также содержит пакет Info.plist файл с информацией о конфигурации пакета.
В отличие от исполнимой программы приложения, загружаемые пакеты обычно не имеют a main функционируйте как их основную точку входа. Вместо этого приложение, загружающее пакет, ответственно за определение ожидаемой точки входа. Например, пакет, как могли ожидать, определит функцию с помощью собственного имени, или он, как могли ожидать, будет включать информацию в Info.plist файл, идентифицирующий определенную функцию или класс использования. Этот выбор оставляют разработчику приложений, определяющему формат загружаемого пакета.
Перечисление 2-6 показывает расположение загружаемого пакета. Каталог верхнего уровня загружаемого пакета может иметь любое расширение, но общие расширения включают .bundle и .plugin. OS X всегда обрабатывает пакеты с теми расширениями как пакеты, скрывая их содержание по умолчанию.
Перечисление 2-6 простой загружаемый пакет
MyLoadableBundle.bundle |
Contents/ |
Info.plist |
MacOS/ |
MyLoadableBundle |
Resources/ |
Lizard.jpg |
MyLoadableBundle.icns |
en.lproj/ |
MyLoadableBundle.nib |
InfoPlist.strings |
jp.lproj/ |
MyLoadableBundle.nib |
InfoPlist.strings |
В дополнение к MacOS и Resources каталоги, загружаемые пакеты могут содержать дополнительные каталоги такой как Frameworks, PlugIns, SharedFrameworks, и SharedSupport— все функции поддерживаются законченными пакетами приложений.
Базовая структура загружаемого пакета является тем же, независимо от который язык, которые связывают использование в его реализации. Для получения дополнительной информации о структуре загружаемых пакетов, посмотрите, что Код Загружает Темы Программирования.
Создание загружаемого пакета
При разработке программного обеспечения для OS X можно создать собственные загружаемые пакеты и включить их в приложения. Если другие приложения экспортируют сменный API, можно также разработать пакеты, предназначенные для того APIs. XCode включает шаблонные проекты для реализации пакетов с помощью или C или Objective C, в зависимости от намеченного целевого приложения.
Для получения дополнительной информации о том, как разработать загружаемые пакеты с помощью Objective C, посмотрите, что Код Загружает Темы Программирования. Для получения информации о том, как разработать загружаемые пакеты с помощью языка C, посмотрите Плагины.
Локализованные ресурсы в пакетах
В Resources каталог пакета OS X (или каталог верхнего уровня пакета приложения для iOS), можно создать один или несколько специфичные для языка подкаталоги проекта для хранения языка - и специфичные для области ресурсы. Имя каждого каталога основывается на языке и области желаемой локализации, сопровождаемой .lproj расширение. Для указания языка и области Вы используете следующий формат:
язык
_область.lproj
Часть языка имени каталога является двумя алфавитными кодами, приспосабливающими ISO 639 соглашениям. Часть области является также двумя алфавитными кодами, но она приспосабливает ISO 3 166 соглашениям для обозначения определенных областей. Несмотря на то, что часть области имени каталога является полностью дополнительной, это может быть полезный способ настроить Ваши локализации для определенных частей мира. Например, Вы могли использовать сингл en.lproj каталог для поддержки всех английских говорящих стран. Однако обеспечивая отдельные локализации для Великобритании (en_GB.lproj), Австралия (en_AU.lproj), и США (en_US.lproj) позволяет Вам адаптировать свое содержание для каждой из тех стран.
Если большинство Ваших файлов ресурсов является тем же для всех областей данного языка, можно объединить каталог ресурса только для языка с одним или более специфичные для области каталоги. Обеспечение обоих типов каталогов улучшает потребность копировать каждый файл ресурсов для каждой области, которую Вы поддерживаете. Вместо этого можно настроить только подмножество файлов, которые необходимы для определенной области. При поиске ресурсов в пакете загружающий пакет код выглядит первым в любых специфичных для области каталогах, сопровождаемых специфичным для языка каталогом. И если никакой локализованный каталог не содержит ресурс, загружающий пакет код ищет надлежащий нелокализованный ресурс.
Перечисление 2-7 показывает потенциальную структуру приложения Mac, содержащего и язык - и специфичные для области файлы ресурсов. (В приложении для iOS, содержании Resources каталог был бы на верхнем уровне каталога пакета.) Замечают, что специфичные для области каталоги содержат только подмножество файлов в en.lproj каталог. Если специфичная для области версия ресурса не найдена, взгляды пакета в специфичном для языка каталоге (в этом случае en.lproj) для ресурса. Специфичный для языка каталог должен всегда содержать полную копию любых специфичных для языка файлов ресурсов.
Перечисление 2-7 пакет с локализованными ресурсами
Resources/ |
MyApp.icns |
en_GB.lproj/ |
MyApp.nib |
bird.tiff |
Localizable.strings |
en_US.lproj/ |
MyApp.nib |
Localizable.strings |
en.lproj/ |
MyApp.nib |
bird.tiff |
Bye.txt |
house.jpg |
InfoPlist.strings |
Localizable.strings |
CitySounds/ |
city1.aiff |
city2.aiff |
Для получения дополнительной информации о кодах языка и процессе для локализации ресурсов, посмотрите Руководство по Интернационализации и Локализации.