Миграция модели данных

Сенсорные приложения какао, модель данных которых основывается на классах в Основе и Базовых платформах Основы, могут быть принесены к OS X с минимальной модификацией. OS X включает обе платформы, и они фактически идентичны своим дубликатам iOS. Большинство действительно существующих различий относительно незначительно или связано с функциями, не присутствующими в iOS. Например, приложения для iOS не поддерживают AppleScript. Для подробного списка различий посмотрите Различия в Платформе Основы.

Если Ваше Сенсорное приложение Какао создается поверх Базовых Данных, можно легко переместить ту модель данных на приложение OS X. Базовая платформа Данных в OS X поддерживает двоичный файл и хранилища данных SQLite (как это делает в iOS), и это также поддерживает хранилища данных XML. Для поддерживаемых хранилищ данных можно скопировать Базовые файлы Информационного ресурса в проект приложения OS X и использовать их как есть. Для получения информации о том, как использовать Базовые Данные в Вашем приложении, см. Базовое Руководство по программированию Данных.

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

Миграция пользовательского интерфейса

По различным причинам, структуре и реализации пользовательского интерфейса (UI) в приложении OS X очень отличается от этого в приложении для iOS. Адаптация Вашего приложения к этим различиям является основной работой миграции. Поскольку Вы приносите свое приложение для iOS к OS X, помните следующие темы.

• Различия в устройстве влияют на пользовательский опыт. В отличие от приложения для iOS, приложение OS X имеет доступ к большему экрану, более надежному электроснабжению и намного большему пулу памяти. Эти различия влияют, как приложение представляет информацию пользователям и как пользователи взаимодействуют с приложением. Например, существует обычно только одно окно на приложение в iOS, и то окно имеет фиксированный размер, играет ограниченную роль в UI и не может управляться пользователями. С другой стороны, приложение OS X часто имеет многократные окна. Эти окна могут содержать отдельные документы, или они могли бы вывести на экран вспомогательную информацию, такую как предпочтения приложения или палитры инструментов. Пользователи могут переместить, изменить размеры, закрыть, минимизировать и выполнить другие операции с окнами в приложении OS X.

• Пользователи взаимодействуют с приложениями по-другому на каждой платформе. Поскольку люди используют сенсорные жесты для взаимодействия с приложениями для iOS, экранные объекты пользовательского интерфейса должны быть достаточно большими для управления с человеческим пальцем. В OS X люди используют мышь, сенсорную панель или другое устройство ввода данных, чтобы переместить экранный указатель и взаимодействовать с объектами пользовательского интерфейса. Поскольку указатель намного более точен, чем палец, расположение приложения OS X имеет тенденцию очень отличаться от расположения приложения для iOS.

• Пользователи не всегда знают о файловой системе. у пользователей iOS нет прямого доступа к файловой системе; вместо этого, приложение для iOS читает и пишет файлы в предписанные расположения в его песочнице. В OS X пользователи могут получить доступ к файловой системе с помощью интерфейса Finder. Несмотря на то, что не все приложения OS X представляют файловую систему пользователям, те, которые делают должен также быть подготовлен обработать проблемы, связанные с форматом документа, кодированием файла, и т.д. Некоторые приложения OS X — например, iPhoto и iTunes — сохраняют свои базы данных в специфичном для приложения расположении и предоставляют пользователям способы управлять их содержанием, не взаимодействуя с файловой системой.

При создании нового проекта приложения OS X в XCode Вы не заставляете те же шаблоны приложений выбирать из этого, Вы делаете при запуске проекта приложения для iOS. (Несмотря на то, что OS X определяет несколько типов приложения — описанный в Приложениях — эти типы непосредственно не связаны с шаблонами проекта.) Шаблон приложений Какао является типичным выбором для разработки стандартного приложения OS X.

Для исчерпывающей информации о принципах разработки UI OS X см. Инструкции по Интерфейсу пользователя OS X. Для программируемой информации об окнах и представлениях Вы используете для создания интерфейса, и базовая архитектура, на которой они базируются, видит Руководство по программированию Приложения Mac.

Стратегии миграции

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

Миграция уровня контроллера

Объекты контроллера являются критической областью различия между разработкой приложений для iOS и для OS X. В iOS, UIViewController объекты являются ключевыми компонентами, поддерживающими представление данных и обрабатывающими много специфичных для устройства способов поведения, таких как изменения ориентации. В OS X v10.10 существует три контроллера представления: NSViewController, NSSplitViewController, и NSTableViewController. Каждый тип контроллера представления участвует в конечном счете цепочка сообщения и в состоянии реагировать на сообщения о событиях.

Перед OS X v10.10 был только один класс контроллера представления, NSViewController, это не получает сообщения о событиях. В тех более ранних версиях, NSWindowController класс является самым подобным UIViewController. В OS X контроллер окна управляет окном и его текущим содержанием.

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

В дополнение к представлению и классам контроллера окна, OS X также имеет NSController класс. Экземпляры этого класса (и его конкретные подклассы) являются объектами контроллера, использующимися в технологии привязки Какао. (Привязка какао, который не доступен в iOS, данных подключений в объекте модели с представлением тех данных в объекте представления, так, чтобы оба объекта были обновлены, когда изменяются данные.), Поскольку объекты контроллера управляют моделью данных приложения и не ее представлениями, их можно считать контроллерами данных, а не контроллерами представления.

Для получения информации о контроллерах представления в OS X посмотрите, что Ссылка класса NSViewController, и для получения информации о контроллерах окна видит Ссылку класса NSWindowController. Узнать больше NSController объекты и привязка Какао, посмотрите, что Привязка Какао Программирует Темы.

Пользовательские события и обработка событий

Обработка событий в OS X отличается значительно от обработки событий в приложениях для iOS, в основном потому что типы пользовательских событий на каждой платформе отличаются. Если Ваше приложение для iOS делает свою собственную обработку событий, необходимо будет переписать много, если не вся обработка событий кодирует при миграции приложения на OS X.

В отличие от iOS, определяющего сенсорные события и события движения, OS X определяет события от нажатия мыши, события клавиатуры, события сенсорной панели, события планшета и события области отслеживания. Все эти типы событий касаются периферийных устройств, которые могут быть присоединены к компьютеру. Кроме того, большинство этих типов событий включает фазы (например, ключ и мышь вниз) или модификаторы (например, нажимая Клавишу CTRL и клавишу символа одновременно), что код обработки событий часто должен тестировать на.

Несмотря на то, что платформа AppKit также определяет касание (NSTouch) объекты и события жеста, эти события являются подходящими только для портативных или настольных компьютеров с поддерживаемыми сенсорными панелями. В версии OS X Вашего приложения важно обработать события от как можно большего количества типов устройств ввода данных.

Основные методы для обработки событий на каждой платформе подобны. Например, пользовательское представление должно выбрать в обработать события. Затем для обработки события пользовательское представление должно реализовать один или несколько методов, объявленных классом респондента платформы приложения.

Типичные примеры обработчиков событий iOS, которые необходимо заменить в OS X, UITapGestureRecognizer и UILongPressGestureRecognizer. UITapGestureRecognizer может быть заменен в OS X с mouseUp: метод NSResponder или подклассы, в то время как UILongPressGestureRecognizer обычно заменяется событием щелчка правой кнопкой с меню, выведенным на экран с помощью menuForEvent: метод NSView.

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

Для получения дополнительной информации об обработке событий в приложениях OS X, посмотрите Руководство по Обработке событий Какао.

Windows

На базовом уровне окна в AppKit играют ту же роль, которую они делают в UIKit: Они представляют графическое содержание в прямоугольной области экрана, они в корне иерархии представления, они координируют операции рисования, и они помогают распределить события. В большинстве других отношений окна и объекты платформы, представляющие их в OS X и в iOS, отличаются. Вот несколько основных отличий между окнами OS X и iOS.

• Большинство приложений для iOS имеет только одно окно фиксированного размера. Напротив, приложение OS X может иметь многократные окна переменных размеров и стилей, и те окна совместно используют экранное пространство с окнами других приложений. В отличие от окна iOS, не имеющего никаких визуальных украшений, окно OS X обычно выводит на экран заголовок и может включать средства управления для перемещения, закрытия, изменения размеров и минимизации окна.

• Приложение OS X может иметь одно или более основных или вторичных окон (приложение, имеющее многократные главные окна, обычно основанное на документе приложение). Главное окно является главным фокусом пользовательских событий и представляет данные приложения. Вторичное окно обычно служит вспомогательной функции и могло бы обеспечить дополнительное управление данными, представленными в главном окне. Вторичные окна часто являются панелями — т.е. экземпляры NSPanel класс.

• В UIKit, UIWindow класс является подклассом UIView, но в AppKit, NSWindow класс является подклассом NSResponder. Следовательно, окна в AppKit не поддерживаются Базовыми Слоями анимации, как они находятся в UIKit. Это различие означает, что необходимо выполнить анимацию явно на уровне представления. Для сводки Базовых различий в Анимации посмотрите Таблицу 7-3.

Меню

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

По умолчанию строка меню приложения OS X имеет некоторые стандартные меню — такие как Меню Apple, меню приложения, Файл, Редактирование, и т.д. — и каждое из этих меню содержат стандартные элементы меню. При создании проекта приложения OS X в XCode шаблон файла пера дает Вам «набор для запуска» меню для Вашей строки меню; удалите и добавьте меню и пункты меню для настройки этого набора для приложения.

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

Для узнавания больше о меню считайте Меню приложения и Раскрывающийся Список, Программируя Темы.

Документы

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

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

OS X берет поддержку документов шаг дальше, определяя обширную архитектуру для основанных на документе приложений, потому что эта модель содержания характерна для платформы. Архитектура документа OS X близко на основе шаблона разработки Контроллера представления Модели. Каждый документ имеет свое собственное главное окно и может иметь вторичные окна для вспомогательных функций. При использовании XCode для разработки основанного на документе приложения, Вы получаете соответственно сконфигурированные файлы пера и тупиковые исходные файлы для NSDocument подкласс раньше управлял Вашими документами.

Для узнавания больше об архитектуре документа считайте Руководство по программированию Приложения Mac.

Представления и средства управления

Некоторые готовые к использованию представления, что предложения AppKit подобны представлениям UIKit в форме, функции и интерфейсе. Но даже с этими представлениями, существуют различия, о которых необходимо знать при миграции кода. Другие представления UIKit не имеют никакого дубликата в AppKit, потому что они не работали бы хорошо в OS X; для этих представлений необходимо найти подходящую альтернативу. Например, AppKit использует NSBrowser класс для управления дисплеем иерархической информации; напротив, приложение для iOS использовало бы контроллеры навигации. Некоторые представления, кажущиеся подобными на обеих платформах, имеют различные характеристики наследования. Например, в iOS UITableView наследовался от UIScrollView класс, тогда как в OS X NSTableView наследовался от NSControl.

Несмотря на то, что базовые классы представления — т.е. UIView и NSView— несколько подобны на обеих платформах, существуют некоторые принципиальные различия между ними.

• Базовые Слои анимации. представления iOS являются уровнем, поддержанным по умолчанию. приложения для iOS обычно управляют представлениями путем изменения свойств представления. В OS X приложение должно выбрать в сделать его представления поддержанными уровнем. Следовательно, представлениям AppKit более свойственно выполнить те же манипуляции в их drawRect: метод. Таблица 7-3 дает больше информации о различиях, связанных с Базовыми Слоями анимации.

• Система координат по умолчанию. Системы координат по умолчанию, используемые в операциях рисования, отличаются в iOS и OS X. В iOS источник получения в верхнем левом углу представления; в OS X источник получения в нижнем левом углу представления. Посмотрите Графику, Получение и Печать для получения дополнительной информации.

• Использование ячеек для средств управления. Поскольку представления AppKit могут подвергнуться значительным издержкам, некоторые ячейки использования средств управления AppKit (т.е. NSCell объекты) как легкая альтернатива представлениям. Ячейка содержит информацию, в которой ее управление нужно для отправки сообщения действия; ячейка также рисует себя, когда управляется ее управлением. Ячейки делают возможные средства управления, такие как матричный объект и табличное представление, имеющие двухмерные антенные решетки активных подобластей.

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

Для функциональных описаний представлений и средств управления, доступных в OS X, вместе с информацией о том, как использовать их в Вашем приложении, см. Инструкции по Интерфейсу пользователя OS X. Для приобретения знаний об общих характеристиках и поведении представлений AppKit см. Руководство по программированию Представления.

Файловая система

Много приложений OS X позволяют пользователям определить местоположение файлов и каталогов в файловой системе, сохранить файлы к определенным расположениям файловой системы, открытым файлам, и делают другие операции файловой системы. Приложение для iOS, с другой стороны, должно выполнить все читающие файл и пишущие файл операции в ограничениях его песочницы. В OS X v10.7 и позже, могут также «поиграться в песочнице» приложения Mac, и это может ограничить операции файловой системы, которые они могут выполнить (для получения дополнительной информации, посмотрите Тестовую среду приложения). Тем не менее, даже эти приложения, возможно, придется подготовить открыть и сохранить файлы в файловой системе, поскольку пользователь направляет (предполагающий, что у пользователя есть необходимые полномочия файла).

Приложение OS X включает эти способы поведения файловой системы в основном через панели Open и Save (реализованный классами AppKit NSOpenPanel и NSSavePanel). Через экземпляры этих объектов приложение может представить браузеры файловой системы пользователям, предотвратить файлы, которые оно не распознает от того, чтобы быть выбранным и получает выбор пользователей. Можно также присоединить пользовательские представления аксессуара к этим браузерам.

В дополнение к использованию панелей Open и Save Ваше приложение может вызвать методы NSFileManager и NSWorkspace классы для многих взаимодействий файловой системы. NSFileManager позволяет Вашему приложению создать, переместить, скопировать, удалить и соединить элементы файловой системы. Это также предлагает другие возможности, такие как обнаружение содержания каталога, и получение и установка атрибуты каталога и файл. Операции NSWorkspace те приращения класса NSFileManager; эти операции включают запускающиеся приложения, открывая определенные файлы, монтируя локальные тома и съемные носители, устанавливая информацию о Средстве поиска файлов и каталогов, и отслеживая изменения файловой системы. (Поигравшие в песочнице приложения не могут использовать NSWorkspace во многих ситуациях.)

Если Ваши записи приложения для iOS и файлы чтений в Documents каталог, это использует NSSearchPathForDirectoriesInDomains функция для получения надлежащего пути к каталогу в тестовой среде приложения. В OS X Вы используете URLsForDirectory:inDomains: метод NSFileManager класс вместо этого; для этой платформы Вы, возможно, должны были бы указать домены кроме пользовательского домена и стандартные расположения каталога кроме Documents. Например, Ваше приложение могло бы хотеть записать или считать данные в корневом каталоге пользователя, в Library/Application Support.

Для узнавания больше о доменах файловой системы, стандартных расположениях файловой системы, расширениях файла, полномочиях файла BSD, средства AppKit для управления операциями файловой системы и другой информацией, связанной с файловой системой OS X, читают Руководство по программированию Файловой системы.

Графика, получение и печать

Существует много параллелей между графикой и получением APIs AppKit и тех из UIKit, как показано в Таблице 7-2. И платформы имеют классы, экземпляры которых представляют изображения, цвета и шрифты. У обоих есть классы для рисования путей Безье и категорий для рисования строк. У обоих есть функции для перечеркивания и заполнения прямоугольников. У обоих есть программируемые средства для получения и преобразования графических контекстов различных типов. В некоторых случаях можно переместить код, использующий методы UIKit и функции к соответствующим методам AppKit и функции с немного больше, чем смены имени.

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

Модель получения для представлений AppKit почти идентична модели получения для представлений UIKit за одним исключением. Представления UIKit используют систему координат, где источник для окон и представлений находится в верхнем левом углу по умолчанию с положительными осями, расширяющимися вниз и вправо. В AppKit точка источника по умолчанию находится в нижнем левом углу, и положительные оси расширяются и вправо. Это - система координат по умолчанию AppKit, который, оказывается, совпадает с системой координат по умолчанию Базовой Графики. Для изменения источника по умолчанию представления Appkit переопределите представление isFlipped метод и возврат YES. Следующие типы представлений, уже зеркально отражаются по умолчанию: NSButton, NSScrollView, NSSplitView, NSTabView, и NSTableView.

Для получения информации о графике и рисующий в OS X, посмотрите, что Какао Рисует Руководство. Для узнавания больше о печати в OS X посмотрите Ссылку класса NSPrintInfo.

Текст

AppKit предлагает приложениям сложную систему для выполнения связанных с текстом задач в пределах от простой текстовой записи в расположение пользовательского текста и набор. Поскольку текстовая система Какао основывается на Базовой текстовой платформе и обеспечивает сопоставимый набор способов поведения, приложения Какао редко должны использовать Базовый текст непосредственно.

Собственная текстовая поддержка UIKit ограничивается. Все еще существует некоторая корреспонденция между той поддержкой и поддержкой, предлагаемой AppKit — а именно, текстовые представления, текстовые поля, объекты шрифта, строковое получение и содержимое HTML. Если Ваше приложение для iOS использует Базовый текст, чтобы нарисовать и управлять шрифтами и текстовым расположением, можно переместить большую часть того кода к приложению OS X.

Для введения в текстовую систему AppKit посмотрите текстовое Руководство по архитектуре Какао.

Табличные представления

Табличные представления в AppKit структурно отличаются от табличных представлений в UIKit. В UIKit табличное представление имеет любое число строк и один или несколько разделов, но это имеет только один столбец. В AppKit табличное представление может иметь любое число строк и столбцов (и нет никакого формального понятия разделов). Приложение для iOS обычно использует ряд табличных представлений UIKit, каждого на их собственном экране, для представления иерархического набора данных. Приложение OS X, с другой стороны, обычно использует единственное табличное представление AppKit для представления всего набора данных одновременно.

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

Табличные представления в OS X существуют в основном для представления табличных данных в большем окне. AppKit обеспечивает другие объекты пользовательского интерфейса, подходящие для некоторых ролей, которые играют табличные представления UIKit — например, списки (раскрывающиеся списки, флажки и переключатели) и навигация иерархий данных (браузеры, и обрисуйте в общих чертах представления). Следовательно при миграции табличных представлений приложения на OS X необходимо сначала рассмотреть ли другое представление AppKit лучшие иски потребности приложения, чем табличное представление.

Табличные представления в AppKit NSTableView объекты. Ячейки занимают область, где пересекаются строки и столбцы табличного представления. Ячейки табличного представления могут основываться NSCell объекты или, в OS X v10.7 и позже, NSView объекты. Основанные на представлении табличные представления являются предпочтительной альтернативой. Заполнение табличных представлений AppKit подобно заполнению табличных представлений UIKit: источник данных запрашивают для числа строк в табличном представлении и тогда просят относительно значения поместить в каждую ячейку. Табличные представления в OS X имеют эти другие параллели с табличными представлениями UIKit:

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

• Анимированные операции. Оба NSCell- базируемый и NSView- основанные табличные представления имеют методы для вставки, удаления, и движущихся строк и элементов, дополнительно с анимацией.

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

Другие интерфейсные различия

При миграции приложения необходимо иметь в виду другие технологические различия между UIKit и AppKit; Таблица 7-3 суммирует эти различия.