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

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

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

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

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

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

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

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

Что относительно того, чтобы использовать третий язык в качестве связующего звена для собственных вызовов?

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

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

То же может пойти для Java, но я думаю взгляды интеграции немного тяжелее.

BTW это - путь (или был?) классы как java.io. Работы файла.

Скажите нам, как это пошло.

править

Я думаю путь, которым крупные компании идут с этим, использует C++ и использует ветвления для платформы определенный код.

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

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

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

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

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

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