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

Question

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

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

Answer 1

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

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

Был недавний эпизод Late Night Cocoa под названием Портирование больших приложений на платформу Mac . Ваше приложение может не считаться «большим», но этот подкаст дает немало отличных знаний о портировании от человека, который делал это несколько раз.

Answer 2

Хорошо. После того, как вы написали приложение для Какао, можно портировать его на Windows. Это можно сделать с помощью gnustep или Cocotron .

Если вы сделаете это по-другому, WINE предназначен для облегчения переноса.

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

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

Answer 3

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

Одной из самых больших проблем в прошлом был отказ Apple открыть формат пера для Какао (углеродные пики были открытыми файлами XML много лет назад). Это изменилось с XCode 3 и форматом .xib , а также объяснено Frasier Speirs .

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

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

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

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

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

Answer 4

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

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