Прошло уже достаточно времени с тех пор, как термин FireMonkey стал более менее знаком, если, и не для всех разработчиков, то хотя бы тех, кто использует Delphi. За это время появились книги по FireMonkey, статьи по FireMonkey, записи про FireMonkey в многочисленных блогах. Читать все это очень интересно. Но ведь никакая теория не заменит практику. И у меня, как и у многих ранее, появился зуд попробовать что-нибудь написать с использованием FireMonkey.
При этом, однако, возникла проблема. Я, почему-то, решил, что надо просто реализовать какой-нибудь не очень сложный рабочий проект.
Чтобы объяснить,почему это оказалось для меня проблемой, потребуется некоторое (так и хочется написать, лирическое) отступление. Экскурс в мое прошлое, как разработчика. Пояснить некоторые сформировавшиеся у меня взгляды на программирование с использованием Delphi.
Надо сказать, что использовать Delphi я начал еще на Windows 3.1, то есть, с первой версии. И с тех самых пор я изучал VCL. Изучал в оригинале, так сказать. Смотрел, обращался, трассировал исходники. Снова и снова.
Известно, что в разное время в набор компонентов, поставляемых с Delphi, входили компоненты сторонних разработчиков, которые должны были заполнить пробелы в VCL, и которые, наверное, проходили некий контроль качества перед включением. Некоторые из таких компонентов продолжают поставляться и сейчас. Взять тот же Indy. Никого не хочу обидеть, это сугубо мое личное мнение, которое относится и ко мне самому, как разработчику компонентов: ни один набор не был так глубоко продуман и так качественно реализован, как громадный и разнообразный VCL. Нет, я не претендую на истину в конечной инстанции, и, конечно же, в самом VCL множество ошибок, решений, которые вызывают непонимание, вызывают неприятие и с которыми хочется не соглашаться. Но у меня всегда складывалось впечатление некого единого стиля. Есть в VCL, на мой взгляд, красивый и прочный стержень, который поддерживает всю конструкцию Delphi, и вокруг которого строится и программная инфраструктура, и само сообщество разработчиков. Именно благодаря во многом VCL, опять же, на мой взгляд, слухи о смерти Delphi до сих пор остаются слухами. И когда а поставку VCL включались компоненты сторонних разработчиков, это стразу было заметно, они отличались.
Но вот приходит момент, и я слышу, что VCL - это технология, которая устарела. Технология, которую надо оставить в прошлом. Разработчикам следует все свои новые проекты реализовывать на FireMonkey, а про старые... неплохо бы и их перевести на новые рельсы. FireMonkey везде и всегда. И слышу я это из разных источников. Причем довольно настойчиво. Нет, никто VCL не убивает. он остается с нами. Но он теперь не номер один. Он должен стать дублером. По крайней мере так я понимаю то, что говорится о будущем продукта.
В принципе, я понимаю такой расклад. Взят курс на многоплатформенность, и, что важнее, на кроссплатформенность. Ведь что такое VCL? Visual Component Library. Библиотека визуальных компонентов. С этим можно не соглашаться. Я, например, всегда считал множество невизуальных компонентов, да и не компонентов, а просто классов, неотъемлемой частью VCL, а огромное количество сторонних классов и компонентов - продолжением, расширением VCL. Ну не получается у меня считать наследников TDataset-а не частью VCL. Хотя, например, термин DBExpress Library говорит о том, что это, как бы, не VCL. Видимо, Embarcadero действительно разделяет монолитную, с моей точки зрения, VCL, на некоторое количество отдельных библиотек. Нет, конечно, не совсем отдельных, но, тем не менее. И если принять такую точку зрения, FireMonkey призван заменить именно визуальную часть VCL (как же я все-таки должен называть полную библиотеку классов и компонентов, может, Borland Component Library?).
Вокруг чего построены визуальные компоненты, входящие в библиотеку? Вокруг низкоуровневых, базовых элементов, предоставляемых операционной системой. Дескрипторы окон, шрифты, сами окна, элементы ввода, сообщения, контексты устройств и многое многое другое - это есть не понятия библиотеки, поставляемой с Delphi, а понятия операционной системы. Да, именно, Windows. И если вы хотите построить кроссплатформенную библиотеку, то логично отказаться от той инфраструктуры, которую предлагает операционная система, исполняющая написанную с использованием библиотеки программу.
Именно это и пытаются сделать при помощи FireMonkey. Пытаются создать инфраструктуру, основанную на базовых механизмах, поддерживаемых в различных операционных системах, способную заменить тот сервис, который предлагают сами операционные системы.
Многие помнят попытку сделать кроссплатформенной не только библиотеку, но и сам Delphi . Параллельно Delphi 6 вышел продукт Kylix и библиотека CLX. Все это было сделано для того, чтобы можно было разрабатывать для Linux. Однако, нет у Linux многих базовых понятий в плане графического оконного интерфейса, какие есть у Windows. Оконный интерфейс для Linux вообще явление не родное. Это необязательное приложение. И пришлось писать какую-то синтетическую библиотеку. С ее помощью можно было писать программу и для Windows, и для Linux. Однако, я до сих пор помню то чувство не разочарования, нет, скорее, раздражающего неудобства, которое испытал, когда попробовал воспользоваться аналогами визуальных компонентов из CLX. Мне стало много чего не хватать. То, что я привык делать не задумываясь при разработке с использованием VCL, оказалось сделать трудно, совсем по другому, или просто невозможно, с использованием CLX.
Приблизительно также я чувствовал себя и при переходе с BDE на DBExpress. Старый, знакомый еще с Field Test-а BDE (Borland тогда уже использовал его в Quattro Pro for Windows и в Paradox for Windows, и носил он название ODAPI, а затем IDAPI, и был на голову выше, на мой взгляд, майкрософтовского ODBC) был объявлен устаревшей технологией, которая должна уступить место в новых проектах новой библиотеке. Мне все время чего-то не хватало в DBExpress в первое время, особенно знаний.
При этом я ни в коем случае не хочу ругать или критиковать ни сами перечисленные выше библиотеки, ни решения, которые привели к их появлению. Речь идет лишь о моих впечатлениях, иногда,первых впечатлениях.
Теперь, наверное, становится немного понятней, почему решение написать с использованием FireMonkey небольшой рабочий проект, принесло некоторое количество проблем. В течении многих лет при разработке проектиков, проектов и проектищ складывается определенный стереотип, некий шаблон того, что и как надо делать. И в моем случае пришлось столкнуться с тем, что шаблон надо менять. Потому, что нельзя перенести все то, к чему привык, используя VCL, в проект, строящийся на FireMonkey.
При старте проекта я испытал некоторое чувство дежавю. А именно, чувство неудобства. Например, нет многих свойств у привычных элементов ввода. Приемчики, которые прочно вошли в практику, основанные на трюках, связанных со знанием каких-то особенностей операционной системы, не проходят в новом контексте. Не говоря уже о том, что некоторые компоненты изменились радикально.
Ну и еще важный нюанс. Какие обычно проекты приходится делать на работе, если она (работа) не связана с написанием компиляторов, систем моделирования или еще чем-нибудь высоконаучным? Я думаю, что для большинства это разработка чего-либо, связанного с использованием баз данных. Причем что-то высоконаучное тоже может пользоваться сервисами, предоставляемыми СУБД.
Вот тут меня ожидала еще одна засада. Почему-то, когда сталкиваешься на практике с тем, что FireMonkey не содержит элементов, ориентированных на работу с данными, хранящимся в БД, оказываешься к этому не совсем готов (мягко говоря). Хотя и читал уже об этом много раз и знаешь (теоретически), чем следует воспользоваться. Речь про Live Bindings.
Я не хочу ввязываться в спор про то, должны ли настоящие крутые программисты использовать db-aware компоненты, или не должны.На практике, начиная новый проект, я оказался перед фактом: надо привыкать и к новым визуальным компонентам и к новому способу извлечения данных для отображения, редактирования и, в конечном счете, сохранения. Что, опять же, не плохо, и не хорошо. Просто для меня получилось именно так.
На этом хочу завершить пост про первые впечатления. На очереди рассказы о том, что и как преодолевалось при работе над проектом.
Вышедшая в сентябре прошлого Delphi XE2 содержит рекордное количество нововведений.
Краткие обзоры возможностей Delphi XE2 уже публиковались на Хабре. Но, очевидно, самым ярким новшеством стала платформа FireMonkey, и здесь я хотел бы уделить немного внимания именно ей.
Я сделал небольшую подборку ссылок на материалы, которые, как я надеюсь, помогут вам составить более-менее адекватное представление об этой платформе. Но прежде, для тех, кто не в курсе, я вкратце расскажу, что же такое FireMonkey.
Embarcadero Technologies позиционирует FireMonkey как платформу для создания полнофункциональных бизнес-приложений для Windows, Mac и iOS. При этом данная платформа является нативной для каждой из ОС, т.е. при работе приложения, созданного с помощью FireMonkey, не используется ни каких дополнительных надстроек.
FireMonkey привязывается непосредственно к нативной (с точки зрения ОС) графической библиотеке, такой как OpenGL или DirectX. Таким образом, предлагается наилучшее решение с точки зрения GPU.
Ядро FireMonkey архитектуры представляет собой мощную библиотеку классов (в том числе визуальных компонентов).
Целевая платформа выбирается в процессе компиляции.
Первая версия FireMonkey поддерживает только Win32, Win64, MacOSX и iOS, в будущем Embarcadero планирует портировать её на несколько других платформ.
Что стоит учитывать?
Несмотря на то, что платформа FireMonkey предоставляет обширный инструментарий для разработки 3D приложений, ее нельзя рассматривать как игровой движок. FireMonkey позиционируется именно как платформа для разработки бизнес-приложений.
Сейчас продукт находится в начальной стадии своей эволюции. И многие функциональные возможности FireMonkey претерпевают изменения, как качественные, так и количественные.
Я надеюсь, что ссылки, приведенные ниже, помогут разобраться с основными возможностями новой платформы.
Официальная страница продукта на сайте Embarcadero (рус.)
Среди англоязычного материала хотелось бы выделить серию (англ.)
Что посмотреть?
Что касается последней версии Delphi, то видеоматериала, посвященного возможностям продукта и приемам работы с ним, как никогда много. Как официального, от Embarcadero, так и от независимых разработчиков. На YouTube очень много видео о FireMonkey, вы просто можете воспользоваться поиском. Среди этого обилия материала выделю серию из трех роликов от Марко Канту - RAD in Action landing page ., таким образом, придав своим изысканиям вектор полезности.
06.03.2013 12:46 пп
Очень я страдал из-за отсутствия компонента-браузера в FireMonkey. Известный проект Delphi Chromium Embedded все-таки включил поддержку FMX в последнем билде. Но не смотря на то, что прошло довольно много времени, поддержку FMX2 автор добавлять не торопится. В итоге пришлось брать ситуацию в свои руки.
Компонент TChromiumFMX из официальной сборки вполне себе работает в FireMonkey (в XE2), но в FMX2 даже не компилируется. Пришлось немного разобраться с тем, как он устроен и исправить. Благо, серьезных изменений не потребовалось.
В FMX2 изменились две нужные компоненту вещи.
Первое — TBitmap больше не имеет свойств ScanLine и StartLine . Прямой доступ к содержимому TBitmap переделали (интересно, зачем?) и теперь оно доступно через класс TBitmapData , который возвращает метод TBitmap.Map .
Ну и второе, более известное — Platform .* больше нет, теперь необходимо получать нужный интерфейс через TPlatformServices.GetPlatformService . Здесь все довольно прямолинейно и проблем нет.
Особо изобретательно я его не тестировал, но для моих целей компонент вполне подходит — сайты через него смотреть можно. Скачать его . Еще, пожалуй, отправлю мои правки автору, может быть сочтет нужным добавить их в официальную версию.
30.07.2012 2:43 дп
Jason Southwell предлагает разработать набор FireMonkey-оберток для нативных контролов Windows/OSX и собирает на это деньги . Планирует для начала собрать 20 тысяч долларов.
Идея ясна. Существующие компоненты FireMonkey отрисовываются средствами Delphi практически с нуля, что с одной стороны во многом и обеспечивает их кроссплатформенность, но с другой — в результате мы получаем компоненты не вполне естественно выглядящие в обеих поддерживаемых на сегодня ОС. И это полбеды — кроме внешнего вида, приходится самостоятельно разрабатывать и логику этих компонентов. Например, RichEdit довольно сложен, самостоятельно повторить его логику в рамках FireMonkey — задача не из тривиальных. И VCL, и CLX не изобретали велосипедов, а пользовались готовым.
А теперь плохая новость. В рантайме все работает, но я не нашел никакого способа добавить свой новый тип вкладки в Items Designer. И похоже, что та же самая проблема есть у всех списковых контролов: TListBox, TGrid и т.п. Сначала мне подход к их реализации очень понравился, а вот теперь даже как-то сомневаюсь. Поиск в интернете показал, что я с этой проблемой не одинок .
Справка молчит, в коде я тоже не нашел ничего. Неужели никак? Это было бы крайне неприятно.
Вы, наверное, в курсе, что Embarcadero активно продвигает свое новое видение создания кроссплатформенного гуя – FireMonkey (они это называют фреймвоком, но для её нынешнего состояния это слишком круто звучит ). В рунете анонсируется один конкурс за другим, проводятся вебинары, и пусть качество последних оставляет желать лучшего, но активность радует. Теперь, собственно, к теме. В рамках последнего конкурса было предложено разработать какое-нибудь приложение для обучения. И вот вчера появилась очередная работа за авторством Евгения Чмеля (не знаю, склоняется эта фамилия или нет ). В отличии от виденных ранее, простеньких “одноформочек”, тут была сделана попытка подергать обезьяну за все конечности: стилизация, 3D, шейдерные эффекты (о GPU accelerated graphics очень любят говорить евангелисты Embarcadero:)) ). Давайте посмотрим, что из этого вышло. Для тех, кто не смотрел вебинары сделаю маленькое отступление. На одном из вебинаров, евангелист Embarcadero, Всеволод Леонов рассказал душещипательную историю о том, как ему пришлось “компьютер перегрузить, конкретно, жестко” (это цитата ), из-за того, что Silverlight SDK и эмулятор Windows Phone 7 “не cработали” (это цитата ) на его компьютере т.к. им не понравился видеоадаптер или настройки графического процессора. А вот приложения разработанные с использованием FireMokey, продолжает Всеволод, совершенно не требовательны к аппаратному обеспечению. Давайте посмотрим, как он нам врал. Беспристрастным свидетелем нам будет Process Explorer v15.05 от Марка Русиновича. Итак, качаем приложение Евгения и запускаем (скриншотов приложения Евгения не привожу, они есть по ссылке на его работу. Обратите внимание на размытость шрифтов ).
Запустили приложение. Смотрим на потребление:
Нескромно, но можно простить “передовой технологии”. Переходим к разделу “Уроки” и выбираем “Урок 5”. Начинается подготовка сцены. Процесс этот длительный (у меня заняло чуть больше минуты, на четырехядерном Phenom II с частотой 3.3GHz ), запаситесь терпением. Сцена построена. Смотрим на потребление:
Обезьяна хорошо подкрепилась. Даже очень хорошо. Теперь попробуйте подвигать мышку над кнопками вариантов ответов. Ощущение, что GUI реагирует ну о-о-очень вяло, не так-ли? Смотрите на график использования CPU (я имею ввиду, что вы должны сами это попробовать, на своем компьютере ) – в эти моменты его загрузка приближается к 100% (у меня было ~21.5% для четырехядерного процессора, что эквивалетно 86% для одноядерного ). А ведь нам кто-то рассказывал про GPU accelerated graphics. Ладно, идем дальше. Отвечаем на все вопросы урока. Смотрим потребление:
Глаза не округлились? Теперь посмотрите, для сравнения, сколько потребляет 3D-стрелялка FarCry с активным игровым процессом (уровень называется Фабрика, если кому, вдруг, интересно ) запущенная в полноэкранном режиме 1440x900:
Выводы делайте сами.
Что же такое FireMonkey?
FireMonkey (FMX) — фреймворк для кроссплатформенной разработки как для настольных систем (Windows, Mac OS + в ближайшем будущем планируется поддержка серверной части на Linux), так и мобильных (iOS и Android) с использованием языка Delphi/C++.
Особенности:
единая кодовая база для всех платформ;
любой контролл (визуальный компонент) может быть контейнером (родителем) для других компонентов;
наличие очень продвинутого относительного расположения (20 типов) компонентов на форме;
LiveBinding позволяет подключать любые типы данных или информации к любому пользовательскому интерфейсу или графическим объектам;
наличие стилей формы/компонентов;
Multi-Device Preview позволяет настроить визуальное представление для каждой из платформ;
FireUI Live Preview -— отображение вида приложения на реальных устройствах в режиме реального времени.
Возможности:
использование нативного API каждой из платформ, также возможность вызов сторонних родных библиотек;
взаимодействие со всеми датчиками (GPS, Accelerometer, Compass, Bluetooth (включая LE) и другие);
поддержка push уведомлений, IoT;
поддержка асинхронных HTTP запросов;
поддержка большинства баз данных (MsSQL, MySql, Oracle, PostgreSQL, MongoDB и др.);
работа с Cloud Service (Amazon, Azure);
поддержка Android Service.
Минусы (на текущий момент):
отсутствие поддержки кастомизации нативных классов;
реализация специфических вещей либо невозможна (виджеты, расширения (iOS) и др) либо необходима пляска с бубном (background service, broadcast message и др);
кастомизация Splash screen (начальный экран) мягко говоря никакая;
FMX контролы используют собственный рендеринг (визуализация, отрисовка), который чисто визуально похож на нативный;
использование нативных контроллов связано с большими телодвижениями;
при большой вложенности компонентов происходят невероятные вещи: приложение крашится в самых различных местах, теряется фокус, зависает и др.;
информативность отладки приложения на мобильных платформах нулевая;
описание ошибок на мобильных платформах сводятся к бесполезным “Error 0х00000Х”;
время компиляции желает быть лучшим для средних и крупных проектов;
необходимость использование напильника для доведения до ума мобильных приложений для каждой платформы;
отсутствует поддержка Intel Atom архитектуры;
неадекватная цена по сравнению с конкурентами.
Плюсы:
очень активное развитие в последнее время как продукта, так и сообщества, поддержка все новых и новых технологий;
наличие громадного числа бесплатных и коммерческих компонентов;
скорость работы приложения очень близка к нативному;
очень продвинутый визуальный редактор и среда в целом, наличие стилей;
возможность тестировать приложение на Win, и лишь потом разворачивать на устройствах, что очень ускоряет разработку;
смена режима/платформы легким движением руки;
PAServer обеспечивает легкое взаимодействие с MacOs при разработке для ОС Apple;
поддержка 3D графики из коробки.
В заключение хочу сказать, что FireMonkey за последние пару лет вырос в профессиональный инструмент кроссплатформенной разработки бизнес приложений и не только. Многие недостатки постепенно решаются и с каждым релизом продукт становиться все более современным и самодостаточным, также исчезает существующий скептизм к самому языку Delphi, связанный с многолетним застоем. Написание новых проектов на FireMonkey является “безопасным” и перспективным.
Загрузка...