Создание кросс-платформенного приложения Windows, Mac OS X
Я хотел бы создать приложение, которое работает как на Windows, так и на Mac OS X. Я бы также нравится использовать лучшее из того, что платформа, на которой она работает, может предложить в отношении фреймворков, API и т. д. Есть ли способ сделать это без необходимости писать код Objective-C, а затем код c#? Я думал о C++ в качестве альтернативы, но мне было интересно, есть ли что-нибудь еще. Приложение будет основано на GUI (хотя я точно не знаю, что он будет делать пока)
-г.
21 ответов
хорошо, что вы думаете о переносимости на раннем этапе - гораздо сложнее "закрепить его" после этого факта.
доступны различные кросс-платформенные комплекты, но IMHO все они немного не обеспечивают "родной" внешний вид на всех поддерживаемых платформах. На Mac (что я использую), сторонники таких наборов всегда хочу отметить, что они используют собственные элементы управления. Это хорошее начало, но не весь путь. Другие вопросы, рассмотренные руководство по человеческому интерфейсу Apple включите, как должны быть организованы элементы управления, как должны быть сформулированы метки кнопок, какие стандартные сочетания клавиш должны использоваться и т. д.
даже Microsoft пришлось узнать трудный путь об опасностях попытки написать кросс-платформенный графический интерфейс, с злополучным словом 6.0 для Mac.
ИМХО, лучший подход-использовать MVC дизайн, с модельным слоем написанным в стандартном, портативном К++, и просмотр и слои контроллера с использованием собственного инструментария для каждой платформы. Для версии Mac Carbon и C++ во всем были интересным вариантом, который теперь больше не поддерживается, поэтому вы хотели бы использовать Cocoa, используя Objective-C в представлении и Objective-C++ в ваших контроллерах для преодоления языкового разрыва. Ваша версия Windows также может скомпилировать вашу модель как "управляемый C++" и использовать любой язык .NET для контроллеров и представлений.
посмотри Real Studio. Серьезно. Вы можете написать приложение в Real Studio и развернуть его в Windows, Mac OS X и Linux.
Edit: Real Studio теперь Xojo.
wxWidgets, в является кросс-платформенной библиотекой C++, которая является практическим выбором. Но я согласен с Sherm-все кросс-платформенные библиотеки создают уступающий пользовательский интерфейс для собственных приложений.
это усложняется тем, что каждая ОС имеет различную семантику пользовательского интерфейса (заказы кнопок и т. д.), Поэтому, хотя вы можете добиться хорошего внешнего вида, получение "ощущения" на каждой платформе через один слой представления почти неизбежно будет невозможно.
в зависимости от того, что вы в конечном итоге делает, вы можете найти веб-интерфейс лучше (например, встроить веб-сервер в приложение и обслуживать HTTP-страницы в браузере). Тогда вы избегаете проблем L&F!
кроме того, вы можете решить, что у вас просто будет совершенно нестандартный L&F, и пойти на что-то вроде wxWidgets или Tcl/Tk.
Adobe Flex, с библиотеками AIR, делает хорошую работу, давая вам одну среду разработки высокого уровня для такого рода вещей. Я написал несколько утилит, которые люди используют на обеих платформах заменимо.
вы также получаете разумную переносимость браузера, если это представляет интерес. Но я думаю, что это довольно хорошее решение без учета этой выгоды.
мое предложение, используйте Python. Python интегрируется как с Objective-C, так и с# (IronPython). Просто избегайте много новых особенностей кровоточащего края языка, и вы в порядке.
конечно, это не будет бездумно легко. Но я бы сказал, что это не стоит быть бездумно легко. Это становится очевидным, когда дизайнеры не учитывают, как будет работать их приложение, когда оно будет портировано на другую платформу.
для GUI я бы посмотрел в SDL или QT.
кроме того, проверьте mono http://mono-project.com/Main_Page
Если вы решите пойти с C++ , есть несколько хороших кросс-платформенных библиотек GUI, которые позволят вам избежать дублирования кода GUI для каждой платформы. Например:
есть ряд других подобных проектов, но это некоторые из лучших и более известных. Для остальной части вашего кода, ничего системная, конечно, должна быть написана с использованием отдельного кода C++ для взаимодействия с Win32 API или OS X system API, где это необходимо. Тем не менее, вы можете обнаружить, что можете избежать большей части системного кода, используя обширные библиотеки, такие как Boost.
другие предложения будут такими, как использование файла конфигурации вместо Реестра Windows или файла plist на mac. Вместо этого стреляйте по платформо-агностическим подходам, где это возможно минимизируйте места, где вам нужно писать код, используя системные API.
вы должны использовать лучшие инструменты, доступные для каждой ОС.
код C/C++ можно отделить от GUI и использовать в каждой отдельно разработанной программе.
прежде чем принять решение, взгляните на кросс-платформенные приложения, разработанные с помощью портативных наборов инструментов, таких как Qt или wxWidgets. По моему опыту, они никогда не бывают такими отполированными, как их родные коллеги, особенно на mac.
Если вы разработчик Windows, используйте Qt или C# Winforms; если вы разработчик Mac, вы можете попробовать Cocotron (http://www.cocotron.org/), но это еще не 100% закончено, хотя коммерческие приложения были отправлены с ним.
спасибо за все ваши ответы. Я проводил некоторые исследования и играл с WPF и CAnimation и т. д. Похоже, что использование модели C / C++ и выполнение GUI индивидуально для каждой платформы-лучший способ пойти. Спасибо за помощь.
также проверить fltk, wxWidgets очень хороший и богатый, но также очень большой...
Как уже упоминалось, это, безусловно, можно создать красивый кросс-платформенный GUI в Java как на Windows, так и на Mac. Однако, если вы хотите, чтобы ваше приложение смешалось и вело себя так, чтобы оно "чувствовало" себя как приложение, разработанное с нуля для платформы, на которой оно работает, вам действительно нужно разработать графический интерфейс и пользовательский интерфейс для каждой версии приложения отдельно.
Если вы проанализируете, что будет делать ваше приложение, и поймете, что есть значительная часть кода / логики, которая может быть разделена между платформами, затем записывает эту часть переносимым способом на языке, доступном в обеих системах. C, C++, Java, Python, Ruby и т. д. Если нет значительной части, то есть большая часть кода будет для GUI, тогда меньше случаев для совместного использования любого кода вообще.
в случае, если существует значительная часть общего кода, я бы предложил рассмотреть Python и Ruby в качестве языков реализации поскольку есть привязки Cocoa для этих языков на Mac и на Windows с использованием IronPython и IronRuby, вы можете использовать повторное использование этого кода в приложении .Net.
пока вы не привязаны к языкам, похоже, что Java-это хороший кандидат. Соедините это с SWT для GUI, и у вас будет собственное приложение на любой ОС, которая вам нравится.
Я планирую сделать аналогичную вещь, и я рассматриваю возможность создания приложения C#/.NET Windows, а затем портирования его в OS X с помощью Mono. Мое приложение уже имеет полностью (за исключением строки заголовка и угловых кнопок) пользовательский интерфейс, поэтому различия в косметической ОС не должны слишком сильно влиять на меня.
Я не уверен, что вы имеете в виду, используя лучшее из каждой платформы с точки зрения фреймворков и API и так далее. В общем, написание кросс-платформенного приложение означает запись в наименьший общий знаменатель и, следовательно, означает не получение лучшего из каждой платформы.
Java или Mono приходят мне на ум. Некоторые люди могут утверждать, что графические наборы инструментов java не являются самыми привлекательными, но это, по крайней мере, для меня, самый простой способ перенести ваше приложение на несколько платформ и избежать трудностей с развертыванием.
Mono, с другой стороны, может быть немного сложнее портировать, так как вам придется писать по крайней мере gui дважды, если вы планируете иметь собственные виджеты (winforms или GTK для windows и CocoaSharp для Max), но вы можно написать бэкэнд только один раз и разработать интерфейс для каждой платформы.
Как я уже сказал, Java GUI toolkits может не чувствовать себя "родным" внутри OSX или даже на Windows, но они наверняка работают на обеих платформах, вы можете использовать Swing или AWT.
Что касается mono, вы можете использовать GTK или Winforms для windows и OSX, но они все равно не будут чувствовать себя родными, вы можете, однако, использовать CocoaSharp, которые привязки к Cocoa framework, но я не уверен в состоянии проекта (читать: функциональная поддержка)
Я второй Java. Он разработан как кросс-платформенное решение.
другие упоминали Adobe Air.
подобно Adobe Air является Silverlight. Я считаю, что это (или будет) полностью кросс-платформа.
вы можете создавать фантастические кросс-платформенные приложения с Java Swing. Просто требуется немного больше усилий, чтобы научиться делать это.
вот, взгляните на некоторые из этих связи.
ребята в Magnetism Studios имеют хороший написать на использование Cocotron для создания исполняемого файла Windows с помощью Xcode.
У меня нет опыта работы с Cocotron, но если бы мне нужно было написать приложение для windows-с фоном разработки Mac - это было бы первое, что я бы попытался.
Если вы выбираете язык C++, я бы определенно рекомендовал Qt для этого. Ваше приложение может быть развернуто под Windows и Mac по запросу в OP, но и Linux, и теперь, с последней версией на смартфонах с использованием iOs, Windows RT и Android.
Это хорошо документировано и очень активно в интернете (в том числе на SO).
единственный отрицательный момент, который я вижу, - это инструмент Qt creator, который, IMHO, менее удобен для пользователя, чем исторические инструменты (например, Visual Studio, например), но вы фактически не вынуждены использовать его в качестве IDE для разработки Qt.
для полноты, теперь стоит добавить единство в список.
было бы очень трудно создать родное приложение для любой платформы, и общие инструменты GUI далеки от зрелости. Но это не просто игровой движок, и вы можете писать на C# / Mono, использовать приличный диапазон либов и развертывать для Win и OSX довольно безболезненно.