Объектив C <-> Мономост

Я подумываю о создании кроссплатформенного настольного приложения, первоначально для Mac/Windows, но в конечном итоге и для Linux.

В настоящее время я планирую структурировать это так:

  • Пользовательский интерфейс Mac с использованием Cocoa/Objective C/Interface Builder
  • Пользовательский интерфейс Windows с использованием WPF
  • В будущем Linux UI использует GTK#
  • Уровни доступа к бизнесу / данным в C# - т.е. .NET в Windows, Mono в Mac/Linux

Это, очевидно, будет хорошо для Windows, я уверен, что это будет хорошо для Linux/Gnome на основе приложений GTK#, которые я видел. Однако звоню в Mono на Mac... Я думаю, у меня есть следующие варианты:

  • ObjC#
  • Дамбартон (выглядит немного мертвым)
  • Monobjc (это будет означать написание Mac-интерфейса на C# вместо Objective C - не очень-то это нужно)

Мой вопрос: кто-нибудь имел опыт создания приложений подобным образом? Любые рекомендации? Я сумасшедший?

К вашему сведению - я довольно суетливый из-за того, что настольные пользовательские интерфейсы "едины" с их операционными системами, так что меня не интересуют неуклюжие решения WinForms/Java/QT...

Источник

4 ответа

Решение

Если кто-то наткнется на это...

MonoMac, похоже, станет очевидным способом продвижения вперед.

Источник

Что бы это ни стоило, я пришел со стороны Mac здесь, но я думаю, что мои комментарии универсально применимы.

Учитывая ваше заявленное желание писать приложения с пользовательским интерфейсом для конкретной платформы, я думаю, что ObjC# - единственный разумный выбор. В Objective-C есть масса ресурсов по реализации пользовательских интерфейсов на стороне Mac; Я думаю, что было бы напрасной тратой времени на то, чтобы попытаться перевести все советы, которые вы нашли, в Monobjc, особенно когда вы сталкиваетесь с API, который хочет, чтобы вы вертели некоторые указатели и передавали дескриптор функции и, о, нет, что вы делаете сейчас, Единственное, что вы можете поделиться между приложениями - это код модели; Я предполагаю, что нет причин пытаться держать вещи на одном языке на стороне презентации, если вы не думаете, что не можете или не сможете ознакомиться с Objective-C.

Источник

Вы посмотрите на Дубровник. Это обновленная версия Dumbarton, включающая генератор кода.

Генератор кода значительно избавляет от необходимости напрямую кодировать встроенный API. Просто наведите генератор на ваши управляемые сборки и интегрируйте выходные данные Obj-C в ваш проект.

Источник

Я 2 года работал над коммерческим настольным Mac-приложением, написанным на C#. У нас есть библиотека, написанная на Objective C, с простыми C-функциями. Наш код C# включает в себя простые функции языка Си.

Первоначально приложение использовало MonobjC, однако MonobjC оказался слишком неудобным для работы. Многие Mac API не очень хорошо переводят в C#, или вам нужно быть экспертом в семантике Objective C и MonobjC, чтобы сделать простой вызов функции. Система передачи сообщений в Objective C не всегда переводится в вызов метода C#.

Когда я оценивал MonoMac, он был менее зрелым, чем MonobjC. У меня не сложилось впечатления, что он добился каких-то реальных улучшений по сравнению с MonobjC, за исключением того, что он остался неизменным со стилем и моделями MonoTouch.

Таким образом, я настоятельно рекомендую использовать некоторую форму PInvoking в Objective C из C# или следовать руководству Embedded Mono. http://www.mono-project.com/Embedding_Mono

Источник
Другие вопросы по тегам