JavaFX 2.0 и Qt для кроссплатформенного приложения
Мне нужно немного советов от ваших разработчиков, которые занимаются кроссплатформенными приложениями (особенно программами с графическим интерфейсом).
Вскоре я буду создавать приложение, которое должно быть кроссплатформенным, поэтому я провел предварительное исследование двух разных сред: JavaFX 2.0 и Qt.
Честно говоря, оба более чем удовлетворяли бы мои потребности. И тогда я спросил себя, почему я выбрал одно из другого (ПРЕДУПРЕЖДЕНИЕ О СПОЙЛЕРЕ: Я не знаю ответа: P). Я знаю, что JavaFX 2.0 является довольно новым (по состоянию на 2012 год) и не полностью поддерживается на разных платформах, но это будет в конечном итоге.
Вопрос, который я задаю, заключается в следующем: какой из них вы бы использовали для кроссплатформенного приложения и на какие критерии вы смотрели при принятии этого решения?
Спасибо, что нашли время, чтобы прочитать это! 🙂
РЕДАКТИРОВАТЬ:
Для справки при рассмотрении этого вопроса приложение, которое я буду писать, включает чтение / запись файлов XML, отображение изображений и создание небольших виджетов с пользовательскими функциями. Я написал подобное приложение на C # с .NET, но хотел бы получить совет при рассмотрении JavaFX 2.0 или Qt для межплатформенного удобства использования.
Еще раз спасибо! 🙂
Решение
Это старый вопрос: стабильность против кровопролития. Я постараюсь дать вам некоторые личные идеи, основанные на функциях вашего приложения.
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 уже есть несколько хороших инструментов для настройки. / display / обрабатывать виджеты, которые мы просто не можем воспроизвести в JavaFX.
Какой из них вы бы использовали для кроссплатформенного приложения, и какие критерии вы учитывали при принятии этого решения?
Ну, JavaFX 2.2 сделан из и для Java. Я лично считаю, что программировать на Java намного лучше и проще, чем на C ++. Вам никогда не придется бороться с указателями в java, вы всегда можете рассчитывать на сборщик мусора для управления памятью, в Интернете есть множество учебных пособий и документации (которые, я считаю, превосходит C ++) и постоянно растущее сообщество Java Gurus.
В резюме я выбрал JavaFX 2.2, потому что он симпатичный, потому что он классный, потому что я могу легче обрабатывать MVC, и потому что я люблю Java, но я считаю, что вы должны использовать Qt, если основная часть вашего приложения — это виджет этого
Я надеюсь, что это помогло, ура
Другие решения
В настоящее время я изучаю различные кроссплатформенные среды, подходящие для разработки автономного приложения для разработки html5. Помимо кроссплатформенной работы (Windows, Linux, OS-X), мое приложение также имеет следующие основные требования:
Встроенная база данных
Встроенный (или, во-вторых, основной браузер) движок рендеринга HTML5
Высокофункциональное редактируемое дерево DND, панель сплиттера и виджеты редактора форматированного текста
Обработка изображений средней нагрузки
Портативность USB-флешки
Я серьезно взглянул на эти рамки:
JQuery (JavaScript), HTML5, CSS3
Google Web Toolkit [GWT] (Java для JavaScript)
JavaFX 2.0 (Java)
QT (C ++ (доступна привязка 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.
В то время я рассмотрел проблему file: // JavaScript с JavaFX, поэтому перешел к разработке прототипов jQuery, GWT и Xulrunner. В результате, однако, моя производительность прототипирования взяла огромный удар. Несоответствие Франкенштейна и импеданса с этими другими структурами было заметно хуже, чем с JavaFX.
Настолько, что после многих недель блуждания по сорнякам я вернулся к своему прототипу JavaFX, мотивированному найти обходной путь. В конце концов я решил эту проблему, встроив веб-сервер Java SE 6 в прототип и подключившись к локальным файлам, загрузив JavaFX WebEngine с URL-адресами в следующем формате: «http: // localhost: 58357 / xxxxx.html» Разблокировка прототипа JavaFX таким образом было похоже на возвращение домой. Это был настоящий глоток свежего воздуха, не говоря уже о большом, большом повышении производительности.
Основываясь на этом опыте, вот некоторые идеи, которые могут оказаться полезными в дебатах JavaFX против Qt.
- Я согласен с вопросом о JavaFX против Qt, так как эти две платформы соответственно оказались моими
# 1 и # 2 любимый, самый продуктивный выбор. - Тем не менее, я бы добавил фреймворк jQuery / HTML5 / CSS3. это
фреймворк настолько силен и настолько загружен потенциалом для x-платформы
разработка приложений, что я бы пошел так далеко, чтобы сказать, что это
неизбежная. В моем широком поиске элементов управления виджетом
ведущие кандидаты на редактируемое дерево DND, панель сплиттера и богатые
Текстовые виджеты редактора wysiwyg оказались с открытым исходным кодом jQuery
плагины. Как только вы обойдете локальный файл: // проблема,
jQuery / HTML5 / CSS3 хорошо совместим с JavaFX WebView
виджет. Единственная область, в которой jQuery / HTML5 / CSS3 терпит неудачу, это
хранилище базы данных на стороне клиента. Это где комбинация JavaFX
и фреймворки jQuery / HTML5 / CSS3 оказываются чрезвычайно мощными. - Хотя они написаны на C ++, модули Qt имеют Java и
Оболочки языка JavaScript означают, что разработчикам не нужно знать или использовать
C ++ для использования Qt. - Это поднимает вопрос о том, что это не обязательно должен быть JavaFX против Qt,
или-или вопрос. На самом деле, более конструктивный и полезный
вполне может быть вопрос «JavaFX AND Qt?» - Это поднимает еще один важный момент: я быстро обнаруживаю,
лучший кроссплатформенный фреймворк для разработки приложений на самом деле
Амальгама JavaFX 2, прямой Java SE, Swing (для устаревшего обычая
widget), WebKit и jQuery / HTML5 / CSS3. Вниз по дороге, GWT,
связанные сторонние библиотеки GWT и модули Qt могут
потенциально присоединиться к смеси. Дело в том, что план использования одного,
генетически чистый каркас быстро ушел в окно. - В настоящее время одна общая нить, которая связывает весь этот гибрид
Фреймворк вместе — это старая 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/
—ЧАС
Из временных меток я вижу, что это было 4 месяца назад, когда я сообщил, что выбрал JavaFX2 вместо QT для своего исследовательского проекта по созданию прототипов. Около 2 месяцев назад я начал переключаться с JavaFX2 на QT и с тех пор не оглядывался назад. Главным предметом спора был переход от создания прототипа к производству. Что касается написания производственного кода, QT оказался намного впереди JavaFX2.
Как всегда, дьявол кроется в деталях, и это была куча маленьких вещей, которые имели большое значение. С JavaFX2 я постоянно сталкивался с такими мелочами, как неконтролируемое поведение изменения размера разделительной панели, ограниченное управление деревом и ограниченный доступ к API-интерфейсу WebKit (например, попробуйте реализовать кнопки масштабирования браузера или сохранить целую веб-страницу в локальном HTML-файле — выполнимо). но в 100 раз громче, чем должно быть). При объединении эти «незначительные» обходные пути замедляют прогресс до полной остановки.
С QT такие препятствия присутствуют гораздо реже, и в результате переход от прототипа к продукту был естественным, плавным и на несколько порядков быстрее.
С другой стороны, добраться до «Hello World» с QT заняло гораздо больше времени. Оказавшись там, однако, производительность быстро обогнала и намного превзошла JavaFX2. Одна из причин этого — документация по QT, примеры программ и сообщество разработчиков гораздо более обширно. QT существует с 1992 года, JavaFX2 — с 2011 года, и эта разница в возрасте существенно влияет на уровни зрелости двух платформ GUI.
Что касается вопроса Java против C ++, то это вообще не проблема. Оба замечательные языки. Лично по ряду причин эффективности, производительности и производительности я считаю C ++ лучшим языком графического интерфейса, но опять же, это личное заключение.
Исходя из .NET / C #, вы должны также рассмотреть Настоящая студия как способ создания кроссплатформенных приложений. Это, безусловно, отвечает вашим требованиям к тому, что вы пытаетесь создать, и будет намного проще, чем JavaFX или Qt.