Общая модель на Mac и iPhone - PullRequest
3 голосов
/ 19 февраля 2010

В настоящее время я изучаю унификацию модели моего приложения. На данный момент я использую другую модель на Mac / Iphone. Отсутствующие классы (NSAttributedString) и отсутствующие технологии (Bindings) заставили меня принять это решение.

С появлением первого ограничения в SDK 3.2 и моим планом создания оптимизированной версии для iPad я пересматриваю свое решение. Так как мне также нужно хранить структуры / объекты NSPoints / CGPoints, NSRect / CGRects, NSColor / UIColor и NSImage / UIImage в моей модели, я не уверен, какой будет лучший способ их обработки.

Написание моего собственного объекта MNColor, который инкапсулирует NSColor и UIColor в зависимости от архитектуры? Пишу мои собственные функции rect, которые вызывают соответствующую функцию в зависимости от arch? Или использовать CGRect в модели на Mac?

Любой вклад будет очень признателен!

Ответы [ 4 ]

2 голосов
/ 20 февраля 2010

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

Строго говоря, «NSPoints / CGPoints, NSRect / CGRects, NSColor / UIColor и NSImage / UIImage структуры / объекты» - это все элементы реализации / пользовательского интерфейса, которые не имеют ничего общего с моделью данных. Конечно, API позволяет легко их архивировать, но это заманивает вас к проблеме, которая у вас есть сейчас. Вы сохраняете объекты / структуры, которые прикреплены к конкретному оборудованию и конкретным реализациям, и теперь вы можете легко их переносить / повторно использовать.

Лучший способ - создать абстрактную модель данных, которая ничего не знает об оборудовании или об остальном API. Он должен хранить все NSPoints / CGPoints, NSRect / CGRects в виде строк или чисел. Он должен хранить цвета в виде чисел, строк или необработанных данных. Изображения должны храниться в виде необработанных данных.

Таким образом, ядро ​​вашего приложения, то есть данные, которыми оно фактически манипулирует, является общим. Для отображения информации вам просто нужен контроллер, который запрашивает необработанные данные и позволяет контроллеру преобразовывать их в структуру / объект, специфичную для аппаратного / API-интерфейса.

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

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

2 голосов
/ 20 февраля 2010

CorePlot - это превосходная среда построения графиков Какао для iPhone и Mac OS X.
Он разделяет общий код для обеих платформ. Может быть, вы можете получить некоторые идеи, просмотрев их источник .

Для некоторых кросс-платформенных проблем CP использует специфичные для платформы определения в отдельных заголовочных файлах, чтобы получить «независимый» класс изображения.
Проект Xcode для каждой платформы включает один из соответствующих заголовков:

Они также имеют пользовательский класс цвета CPColor . (На основе CGColorRef)

Для NSPoint и NSRect я бы использовал структуры Core Graphics в модели и конвертировал их, используя NSRectFromCGRect и NSPointFromCGPoint , где это необходимо. (Mac OS 10.5 +)

Недавняя статья CIMGF также касается несовместимости iPhone / Mac:
Создание NSManagedObject, который является кроссплатформенным

1 голос
/ 19 февраля 2010

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

@ "Написание моего собственного объекта MNColor, который инкапсулирует NSColor и UIColor" - Будет хорошо, если ваш дизайн класса-обертки способен обрабатывать объект MNColor в кроссплатформенных ситуациях. Т.е. база данных из Mac при импорте в iPhone теперь должна быть способна каким-то образом предоставлять объект UIColor через вашу оболочку вместо NSColor.

0 голосов
/ 19 февраля 2010

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

Единственный случай, когда я вижу какие-либо выгоды от хранения изображений в базе данных, это если вам нужен один блок файловой системы, который вы можете перемещать, который перемещает все вокруг. Хотя в случае с iPhone это маловероятно.

...