Кросс-платформенные приложения для настольных систем - подход?

У меня есть то, во что я верю, идея убийцы для приложения. По определению это будет настольное приложение, и оно связано с некоторыми довольно низкоуровневыми службами, предоставляемыми платформами, для которых я буду писать его (служба поиска Windows, сервер Mac OS X Spotlight).

Мое намерение - это Mac OS X и Windows. Абсолютное намерение состоит в том, чтобы не делиться кодом - в основном потому, что очень мало (если таковые имеются) его могли бы быть общими. Из-за этого я намереваюсь использовать совершенно разные фреймворки (Cocoa/Obj-C на Mac, С#/WPF/PInvoke в Windows), и, если хотите, вы почувствуете себя "родными" к своим платформам, первоклассным гражданам приложений.

Мой вопрос заключается в следующем: лучше ли пытаться создавать и их "одновременно", то есть стараться держать их в паритете характеристик даже через цикл разработки; или лучше получить одно "право", а затем следить за другим?

Плюсы к сохранению паритета кажутся такими:

Легче поддерживать выравнивание алгоритмов, поскольку я реализую на одном языке, я просто переношу на другой
Легче гарантировать, что при выпуске оба приложения будут немедленно доступны

Против сохранения паритета кажутся:

Сложнее сделать; постоянное переключение языка может привести к тому, что моя голова взорвется (я уже занимаюсь этим на работе, когда я работаю на С# в течение 4 дней, а затем вынужден поддерживать один из наших старых решений VB.NET).

Плюсы одного, а затем другого:

Нет постоянного переключения языков.
Одна платформа может тестироваться, а другая -

Против одного, а затем другого:

Возвращаясь к тому, что будет тогда "старым" кодом для переноса алгоритмов
Потенциальная потеря интереса к "повторению" того, что я уже сделал.

По общему признанию, это очень амбициозно... И я всего лишь один парень, делающий это в "свободное время" (hah). Если бы вы были в одной лодке и знакомы с обоими наборами технологий, как бы вы к этому подошли?

Обновление

В ответ на некоторые вопросы ниже:

Да, общий API выполним, однако вызывать соглашения не будет - или, по крайней мере, нелегко. Я намереваюсь иметь одни и те же классы, но с кодом, специфичным для платформы. (Это кажется довольно важным, так как Windows Search Service и Spotlight работают по-другому.)

Я мог бы пойти с чем-то вроде Java, но я выбираю не по нескольким причинам: (1) Я не делал Java навсегда, и теперь я опасно неквалифицирован.:) (2) Частью этого является упражнение в обучении Objective-C, делая "по существу" одно и то же приложение в тех технологиях, с которыми я знаком; и (3) Хотя Swing может обеспечить основной взгляд на OS X, его пользовательский интерфейс Windows никогда не чувствует себя совершенно правильно, и я действительно хочу, чтобы оба приложения чувствовали себя принадлежащими к их соответствующим системам.

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

Ответ 1

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

Ответ 2

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

Ответ 3

Хотя я фанатично искал настольное решение для обеих платформ, я не думаю, что есть проблемы с созданием приложения дважды... возможно, имеет смысл.

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

Идея состоит в том, чтобы не делиться базой кода, а делиться разработкой программного обеспечения.

Ответ 4

Оба плюса и минусы, которые вы упомянули, абсолютно верны. Лично я ненавижу возвращаться и переделывать что-то даже на другом языке, чем постоянно мысленно переключать менталитет языка. Я уже делаю это каждый день, когда занимаюсь разработкой сервера в Python и клиентской стороне в JavaScript.

Сказав, как насчет ветки низкоуровневого материала от высокоуровневого пользовательского интерфейса. Постройте материал низкого уровня на каждой платформе, чтобы у них были самые точные API. Внутренняя внутренняя реализация может быть совершенно другой, это не имеет значения, если обе они отображают один и тот же интерфейс. Думаю, вам будет интересно это сделать. Вы также сказали, что хотите, чтобы пользовательский интерфейс чувствовал себя родным на каждой платформе, то почему бы не рассмотреть что-то вроде SWT на Java. Если SWT и Java не являются опцией, то, я думаю, вам придется создавать материалы высокого уровня, используя WPF и Cocoa. Но к этому времени ваша работа будет проще, так как вы будете называть тот же API, который ранее был встроен в ваши низкоуровневые библиотеки.

Ответ 5

Если бы я был вами, я бы пошел с кросс-платформенной платформой и/или языком программирования, в настоящее время у вас есть много языков/фреймворков, которые работают на кросс-платформе, таких как Java, QT (с языками Java и С++ для использования toolkit), С# с MONO, GTK + с C (gtkmm с С++, gtk # и Mono для С#). Таким образом, это проще, если вы делаете это на одном языке/структуре, чем в двух одновременно, потому что, если вы пишете одно и то же приложение на двух разных языках/фреймворках, это будет стоить вам дополнительного времени разработки в течение половины того времени, когда вы сможете получить новые рамки и язык, потому что с самого начала вы знаете, что ваша целевая платформа является многоплатформенной. Если теперь вашей основной платформой будут, например, Windows, а затем пользователи Mac, такие как приложение, очень сильно, поэтому в этом заключается причина повторной записи таргетинга на другую платформу и использования ее средств разработки.

Ответ 6

Вы уверены, что не можете абстрагироваться от низкоуровневых сервисов в общий интерфейс и все еще иметь достаточно приложения (например, пользовательский интерфейс), чтобы сделать его более экономичным для разработки в чем-то кросс-платформенном? Если вы хотите, чтобы время от времени выходило на рынок, это звучит расточительно, чтобы планировать все в два раза.

Ответ 7

Как использовать третий язык в качестве клей для собственных вызовов?

Я слышал, что у python или ruby есть хорошие возможности для встроенной интеграции lib. Разница может быть абстрагирована с помощью внутреннего API.

Таким образом, вся логика может быть установлена в третьем языке и конкретной части в другой.

То же самое можно сказать о Java, но я думаю, что интеграция выглядит немного сложнее.

Кстати, это способ (или был?) классов, таких как java.io.File.

Расскажите, как все прошло.

изменить

Я думаю, что, как великие компании идут с этим, использует С++ и использует forks для кода, специфичного для платформы.

Ответ 8

Если вам все равно придется изучать новую технологию (Objective-C), я бы предложил Java другой взгляд. Попытка разработать одну и ту же программу дважды для двух разных платформ и одновременно изучить слишком много вещей, может означать, что вы завершаете программу, которая хорошо работает ни с одним из них, ни с неподдерживаемым беспорядком, если вы соблазняетесь использовать функции, доступные на одной платформе, но не с другой.

Если вы поедете с Java, вам нужно будет иметь дело с некоторыми пользовательскими интерфейсами и установками на каждой платформе - основная часть вашего приложения (и, что важно, любые исправления ошибок) вы собираетесь сразу же подключить. Java UI выглядят довольно зрелыми прямо сейчас, и существует много многоразового кода пользовательского интерфейса (например, компоненты JIDE хороши). Если ваша идея приложения действительно убийца, вы можете нанять сотрудников, чтобы делать "приложения для граждан первого класса" после того, как вы сделаете свои миллионы.

Вы также можете посмотреть, как были успешно реализованы другие кросс-платформенные приложения - например, посмотрите на firefox, thunderbird, openoffice и посмотрите, что вы можете повторно использовать. Я знаю о нескольких кросс-платформенных приложениях, написанных на Java, например, я использую PersonalBrain и crashplan, и оба они кажутся java-based, и это не навязчиво. (Интересно, что PersonalBrain впервые был поставлен только для Windows, и затем они переписывали Java. Однако некоторые функции все еще являются окнами, но я счастлив использовать его на Mac.)

В какой-то степени это зависит от приложения, которое вы хотите написать, например, хотите ли вы в какой-то момент поддержать iPhone? Если это так, в настоящее время мало выбора, но использовать объектив C, и вы, вероятно, увидите некоторое повторное использование ваших усилий MacOSX, если планируете заранее.

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

Ответ 9

Как я обычно упоминаю с такими вопросами, вы также должны по крайней мере взглянуть на Real Studio, который позволяет создавать собственный рабочий стол приложений из той же базы кода. Он также позволяет подключаться к низкоуровневым службам с помощью объявлений или плагинов.