Подтвердить что ты не робот

JavaFX 2.0 и Qt для кросс-платформенного приложения

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

Я скоро создам приложение, которое должно быть кросс-платформенным, и поэтому я провел предварительные исследования по двум различным платформам: JavaFX 2.0 и Qt.

Честно говоря, оба будут более чем соответствовать моим потребностям. Тогда я спросил себя, почему я выбираю один из них (SPOILER ALERT: я не знаю ответа: P). Я знаю, что JavaFX 2.0 является довольно новым (с 2012 года) и не поддерживается полностью на разных платформах, но в конечном итоге это будет.

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

Спасибо, что нашли время, чтобы прочитать это!:)

EDIT: Для справки при рассмотрении этого вопроса приложение, которое я буду писать, включает в себя чтение/запись XML файлов, отображение изображений и создание небольших виджета с настраиваемыми функциями. Я написал аналогичное приложение на С# с .NET, но хотел бы посоветоваться при рассмотрении JavaFX 2.0 или Qt для кросс-платформенной юзабилити.

Еще раз спасибо!:)

4b9b3361

ОТВЕТЫ

Ответ 1

Это старый вопрос: устойчивость против кровотечения. Я попытаюсь дать вам некоторые личные соображения на основе ваших функций приложения.

JavaFX 2.0 является довольно новым (начиная с 2012 года) и не поддерживается полностью на платформах

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

Чтение/запись XML файлов

Мне еще нужно увидеть какой-то инструмент/интерфейс лучше/проще/быстрее, чем sax2 для синтаксического анализа XML. Разумеется, парсер QtXMLPatterns заслуживает уважения, но они даже разрабатывают XML-парсер на основе SAX2 (который, кстати, не является полным и не полностью совместим с устаревшими методами SAX1), поэтому я бы сказал, что добавьте JavaFX 2 в какой-то балл.

Отображение изображений

Обе технологии могут отображать изображения с достаточной легкостью, но в JavaFX 2.2 отсутствуют некоторые инструменты для манипуляции с изображениями (специальные кодеки формата). Если обработка изображений является критическим вопросом, я бы сказал, что Qt немного впереди в борьбе.

создание небольших виджетами с пользовательскими функциями.

На данный момент это непростая задача в JavaFX 2, поскольку объект Stage не имеет опции, такой как ALWAYS_ON_TOP, и не будет иметь значение до 3.0 (где-то в 2013 году). Это не сложно, но Qt уже имеет приятный инструменты для настройки/отображения/обработки виджетов, которые мы просто не можем воспроизвести в JavaFX.

какой из них вы бы использовали для кросс-платформенного приложения и какие критерии вы рассматривали при принятии такого решения?

Ну, JavaFX 2.2 создан и для Java. Я лично считаю, что программа на Java намного лучше и проще, чем С++. Вам никогда не придется бороться с указателями в java, вы всегда можете полагаться на сборщик мусора для управления памятью, в Интернете есть множество учебников и документации (которые, как я полагаю, превосходят С++) и постоянно растущее сообщество Java Gurus.

В реферате я выбрал JavaFX 2.2, потому что это довольно, потому что это круто, потому что я могу справиться с MVC более легко и потому, что я люблю Java, но я считаю, что вы должны пойти на Qt, если часть виджета вашего приложения главная цель этого.

Я надеюсь, что это помогло, приветствует

Ответ 2

В настоящее время я изучаю различные кросс-платформенные платформы, подходящие для разработки автономного html5-приложения. Помимо кросс-платформенной операции (Windows, Linux, OS-X), мое приложение также имеет следующие основные требования:

Встроенная база данных Встроенный (или, во-вторых, основной браузер) механизм визуализации HTML5 Высокофункциональное редактируемое дерево DND, панель сплиттера и виджеты с богатым текстовым редактором Обработка изображений среднего уровня Переносимость USB-накопителей

Я серьезно посмотрел на эти рамки:

jQuery (JavaScript), HTML5, CSS3 Google Web Toolkit [GWT] (Java для JavaScript) JavaFX 2.0 (Java) QT (С++ (доступно связывание Java)) Xulrunner (XML, JavaScript) GTK + (C) Adobe Air Пижамы

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

Изначально JavaFX 2.0 стал самым быстрым, с большим отрывом. Простое объяснение этого - с помощью JavaFX - все инструменты, IDE, библиотеки, документация, примеры кода, переходы, отладка, поддержка сообщества, поддержка производителя (Oracle) и кривые обучения сочетаются с минимальным несоответствием импеданса.

Вероятно, наибольшая победа в JavaFX заключалась в простоте внедрения встроенной базы данных на стороне клиента (Derby). Со всеми другими структурами эта задача была, что удивительно, значительно сложнее и "клочья".

К сожалению, я столкнулся с серьезным камнем преткновения JavaFX, когда обнаружил, что виджет WebView не выполняет JavaScript из локального файла://URL. QtWebKit, GTKWebKit, Safari и Opera (все основанные на WebKit) также демонстрируют один и тот же файл://поведение блокировки JavaScript (однако Chrome не работает), поэтому я предполагаю, что это стандартная мера безопасности WebKit.

В то время я рассматривал проблему с файлом://JavaScript в showstopper JavaFX, поэтому перешел к разработке прототипов jQuery, GWT и Xulrunner. В результате, однако, моя производительность прототипирования заняла огромную нос. Франкенштейнирование и импеданс, несоответствующие этим другим структурам, были заметно хуже, чем с JavaFX.

Так много, что после многих недель, блуждающих по сорнякам, я вернулся к моему прототипу JavaFX, очень мотивированному, чтобы найти работу. В конечном итоге я решил проблему, вставив веб-сервер Java SE 6 в прототип и подключившись к локальным файлам, загрузив JavaFX WebEngine с URL-адресами в следующем формате: "http://localhost: 58357/xxxxx.html" Разблокирование прототипа JavaFX таким образом было похоже на возвращение домой. Это был настоящий глоток свежего воздуха, не говоря уже о большом, большом усилителе производительности.

Основываясь на этих опытах, вот некоторые идеи, которые могут оказаться полезными в обсуждениях JavaFX и Qt.

  • Я согласен с вопросом о JavaFX vs Qt, поскольку эти две структуры, соответственно, оказались моими # 1 и # 2 любимые, наиболее продуктивные варианты.
  • Тем не менее, я бы добавил рамки jQuery/HTML5/CSS3 в микс. Эта рамки настолько сильны и настолько нагружены потенциалом для x-платформы
    что я дошел до того, чтобы сказать, что это неизбежная. В моем широкомасштабном поиске элементов управления виджетами ведущие кандидаты на редактируемое дерево DND, панель сплиттеров и богатые текстовые виджеты редактора wysiwyg оказались открытым исходным кодом jQuery плагины. Как только вы обойдете локальный файл://issue, jQuery/HTML5/CSS3 прекрасно совместим с JavaFX WebView виджет. Единственная область, в которой отсутствует jQuery/HTML5/CSS3, - это клиентская база данных. Здесь сочетается JavaFX и фреймворки jQuery/HTML5/CSS3 оказываются чрезвычайно мощными.
  • Несмотря на то, что они написаны на С++, Qt-модули имеют Java и Оболочки языка JavaScript, означающие, что разработчикам не нужно знать или использовать С++, чтобы использовать Qt.
  • Это доказывает, что он не должен быть JavaFX vs Qt, либо - или вопрос. На самом деле, более конструктивный и полезный вопрос вполне может быть "JavaFX AND Qt?"
  • Это поднимает еще один важный момент: я быстро обнаруживаю свою лучшая межплатформенная платформа разработки приложений на самом деле амальгамы JavaFX 2, прямое Java SE, Swing (для устаревших пользовательских виджет), WebKit и jQuery/HTML5/CSS3. Вниз, GWT, ассоциированные сторонние библиотеки GWT, а модули Qt могли потенциально присоединиться к миксу. Здесь речь идет о плане использования единого, генетически чистый каркас быстро вышел из окна.
  • В настоящее время один общий поток, который связывает весь этот гибрид Framework вместе - это простой Java SE. И поскольку JavaFX 2 построенный на Java SE, мой голос заключается в том, чтобы начать с JavaFX 2, а затем добавить Swing, WebKit, jQuery/HTML5/CSS3, GWT и Qt по мере необходимости.
  • Наконец, эта статья помогла убедить меня перейти на универсал JavaFX. http://fxexperience.com/2012/04/interview-with-peter-zhelezniakov/

- Н

Ответ 3

Я вижу по меткам времени 4 месяца назад, когда я сообщил, что выбрал JavaFX2 над QT для моего исследовательского проекта прототипирования. Около 2 месяцев назад я начал переходить с JavaFX2 на QT и с тех пор не оглядывался назад. Главным моментом спора было переход от прототипирования к производству. Для написания кода производства QT оказался намного опережающим JavaFX2.

Как всегда, дьявол в деталях, и это была куча мелочей, которая имела большое значение. С JavaFX2 я постоянно сталкивался и работал над небольшими вещами, такими как неконтролируемое поведение изменения размера разделителя, ограниченное управление деревьями и ограниченный доступ к API WebKit (например, попробуйте реализовать кнопки масштабирования браузера или сохранить всю веб-страницу в локальном html файле но 100X clunkier, чем это должно быть). Когда они добавляются вместе, эти "незначительные" обходы замедляют прогресс до остановки.

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

С другой стороны, получение "Hello World" с QT заняло гораздо больше времени. Однажды там, однако, производительность быстро обогнала и значительно превзошла JavaFX2. Одна из причин этого - документация QT, примеры программ и сообщество разработчиков гораздо более обширны. QT существует с 1992 года, JavaFX2 с 2011 года, и эта разница в возрасте существенно влияет на уровни зрелости двух графических интерфейсов.

Что касается вопроса Java vs С++, это вообще не проблема. Оба являются прекрасными языками. Лично для разных факторов эффективности, производительности и производительности я считаю, что С++ является превосходным языком GUI, но опять же, что личный вывод.

Ответ 4

Исходя из .NET/С#, вы также должны рассмотреть Real Studio как способ создания кросс-платформенных приложений. Это, безусловно, соответствует вашим требованиям к тому, что вы пытаетесь создать, и будет намного проще, чем JavaFX или Qt.