Объектив C <-> Мономост - PullRequest
Новая
       21

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

5 голосов
/ 29 октября 2009

Я подумываю о создании кроссплатформенного настольного приложения, первоначально для 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 - не очень-то это нужно)

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

* 1032.

Ответы [ 4 ]

2 голосов
/ 19 июля 2010

Если кто-нибудь наткнется на это ...

MonoMac похоже, что это будет очевидный путь вперед.

1 голос
/ 29 октября 2009

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

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

0 голосов
/ 24 сентября 2013

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

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

0 голосов
/ 24 февраля 2013

Я работаю над коммерческим настольным Mac-приложением 2 года, написанным на 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

...