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

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

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

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

Плюсы сохранения паритета выглядят так:

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

Минусы для поддержания паритета кажутся:

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

Кажется, плюсы одного, а затем и другого:

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

Минусы одного, то другого, похоже, следующие:

  • Возвращаясь к тому, что будет тогда «старым» кодом для переноса алгоритмов
  • Потеря интереса к «переделке» того, что я уже сделал

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

обновленный

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

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

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

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

14.12.2008 23:00:29
9 ОТВЕТОВ
РЕШЕНИЕ

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

4
15.12.2008 01:40:16
Это был очень субъективный вопрос, и я собираюсь немного не согласиться с сообществом. Я принимаю это, потому что я решил сначала поработать с Mac. (Именно из-за этого вы получили кивок вместо da5id; его совет должен был начаться с Win - где в этом веселье? :))
John Rudy 28.12.2008 14:32:03
Я думаю, что это хороший подход - мне нравится идея начать с наименее знакомой (я предполагаю) платформы. Я собираюсь делать что-то подобное (только с моно вместо цели С и какао).
MusiGenesis 29.12.2008 03:08:55

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

5
14.12.2008 23:09:29

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

1
14.12.2008 23:15:27
По моему опыту, приложения, созданные для кроссплатформенных наборов инструментов, имеют тенденцию чувствовать себя чуждыми на любой платформе. Таким образом, практически каждое приложение Java чувствует себя не так как в OS X, так и в Windows. Я бы скорее потратил усилия на создание настоящих нативных приложений, как того хочет ОП.
Matthew Schinckel 15.12.2008 03:08:52
Теперь у нас разный опыт, я создал простое приложение, использующее QT, и оно выглядит как Windows и Linux, как я тестировал. Но, тем не менее, вы не можете обладать мощью кроссплатформенных инструментов.
milot 15.12.2008 08:06:28

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

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

2
14.12.2008 23:28:58

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

1
14.12.2008 23:32:54

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

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

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

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

Кстати, именно так (или было?) Классы, такие как java.io.File, работают.

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

редактировать

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

1
14.12.2008 23:46:58
Вы знаете, это то, что я не учел, и звучит как крутой способ приблизиться к этой стороне уравнения ... Конечно, я не знаю ни Python, ни Ruby, но я понимаю, что их не следует быть ужасно сложным
John Rudy 14.12.2008 23:42:27
Единственная «плохая вещь», которую я обнаружил в них, это то, что они работают не так быстро, как C #, Obj-C или Java. Вероятно, я бы пошел с вызовами Java + Native.
OscarRyz 14.12.2008 23:46:02

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

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

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

5
14.08.2012 14:35:57
Это было очень много намерений. +1!
John Rudy 15.12.2008 01:29:26

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

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

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

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

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

0
15.12.2008 01:08:13
Мое обоснование в Obj-C гораздо прочнее, чем в Java. Я уже примерно на 75 - 80% того, что мне нужно для этого, по сравнению с началом работы в Java. Это своего рода «итоговый экзамен». Но хорошие моменты. (И я никогда не буду зарабатывать миллионы. :)) И нет, для меня нет iPhone ... Никаких мобильных намерений с этим.
John Rudy 15.12.2008 01:30:56

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

0
14.08.2012 18:13:20