Портирование WPF в Cocoa (и/или наоборот)

Question

Я нахожусь на начальной стадии создания программного обеспечения для будущего mISV.Программа представляет собой настольное приложение, и в долгосрочной перспективе я хочу иметь собственную версию как для Windows, так и для OS X (я просмотрел различные кроссплатформенные API, и ни один из них не отвечает моим потребностям).Однако изначально я не думаю, что имеет смысл разрабатывать одновременно для двух платформ.Имея это в виду, я рассматривал WPF для Windows и Cocoa для OS X, и они кажутся похожими.

Был ли у кого-нибудь опыт портирования одного на другое?Существуют ли определенные методы/парадигмы, которым следует следовать, чтобы облегчить портирование?Не обращая внимания на деловые соображения, порекомендовали бы вы сначала разработать один из них?

Answer 1

В настоящее время я работаю над переносом инструментов в этом пространстве, и у меня многолетний трудный опыт использование или написание кроссплатформенных фреймворков на Mac и Windows.

Одной из самых больших проблем в прошлом был отказ Apple открыть формат nib для Какао (Carbon nibs были открытыми файлами XML много лет назад). Это изменилось в XCode 3 и .xib . Об этом также рассказывает Фрейзер Спирс .

По крайней мере, на базовом уровне компоновки теперь есть возможность автоматизировать перенос из одного формата XML в другой. Я считаю WPF (XAML) более чистым, поэтому я использую его в качестве базового формата и перехожу на Какао.

Когда дело доходит до кода, хотя вы можете использовать C # в Mono, CocoaSharp Проект кажется либо остановленным, либо очень медленным, и я бы его не рекомендовал.

Если вы знакомы с C ++, подумайте о том, чтобы иметь как можно больше логики в C ++ с тонким специфичным для платформы уровнем в C # и Objective-C.

Другой подход, который стоит изучить, - это использование динамического языка, такого как Python или Ruby. Я не уверен, что в настоящее время является более зрелым между IronPython и IronRuby , но теперь оба они поддерживаются сотрудниками Microsoft. Что касается какао, я думаю, что гибкость синтаксиса Ruby победит, и RubyCocoa , вероятно, обгонит PyObjC .

В противном случае работайте в C # и Objective-C и поддерживайте две полностью независимые базы кода с одинаковым дизайном. К счастью, у каркасов есть сопоставимая семантика для большинства вещей, особенно если вы используете привязки.

Answer 2

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

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

Был недавний эпизод с какао поздней ночи под названием Портирование крупных приложений на платформу Mac . Ваше приложение не может быть квалифицировано как "большое" но этот подкаст дает немало отличных знаний о портировании от кого-то, кто делал это несколько раз.

Answer 3

Хорошо.После того как вы написали приложение для Cocoa, его можно портировать на Windows.Это можно сделать, используя гнустеп или Кокотрон.

Если ты сделаешь это по-другому, ВИНО призван облегчить портирование.

Я бы предпочел сначала написать версию для OSX.Это связано с тем, что пользователи Windows не имеют четкого представления о том, как должно выглядеть приложение.По моему опыту, они вполне способны пережить любые виды пользовательских интерфейсов.Последовательность не имеет для них большого значения.Поскольку не существует единого мнения о том, как должно выглядеть приложение для Windows, ничто не мешает пользователям Windows действительно любить дизайн OSX, и они даже часто это делают.iTunes для Windows выглядит как очень типичное приложение для OSX, и вы слышите очень мало жалоб на то, что оно недостаточно похоже на Windows.

Если пойти в другую сторону, то это неправда.Пользователи OSX явно отдают предпочтение приложениям Cocoa и очень мало терпимо относятся, например, к таким вещам, как GIMP или Inkscape, которые работают под OSX так же хорошо, как и где-либо еще, но для опытного глаза OSX выглядят совершенно уродливо.

Answer 4

Ну, нет прямого пути. Лучший способ - использовать что-то вроде шаблона Model-View-Controller или другой архитектуры для отделения бизнес-логики и т. Д. От презентации. Однако, если вы не используете Mono, у вас будет очень мало кода для совместного использования, я думаю. Если вы разрабатываете WPF, то вы наверняка делаете .NET и, кроме Mono, Objective-C является стандартным инструментом программирования под Mac OS. X.

Сохраняйте хороший дизайн, и вы можете сделать так, чтобы большая часть кода была просто версией вашего кода .NET для Objective-C и наоборот, вместо того, чтобы пытаться найти путь миграции.