Вопросы 

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

FireMonkey — это центральная технология «нового Delphi». Расскажите, пожалуйста, о целях, возможностях и технических аспектах устройства этой принципиально новой библиотеки. По истечении времени, оглядываясь назад, насколько тяжелым и оправданным оказался ваш отказ от дальнейшего развития сверхпопулярной VCL?

Была выбрана в качестве магистрального направления развития технологии Delphi для достижения конкретной цели — мульти-платформенной разработки из одной среды, на основе единой базы исходных кодов, причем без необходимости в кардинальной переподготовки разработчиков. В рамках ставшей классической и сверхпопулярной VCL это было невозможно, её связь с WinAPI была слишком тесной, можно сказать, «на генетическом уровне».

Компоненты VCL не имели «абстрактной» прослойки между функциональным уровнем с точки зрения интерфейса и механизмами их отображения. Функциональный уровень — то, как вёдет себя как элемент управления, на какие события реагирует, какое взаимодействие с пользователем обеспечивает. Отображение — вызов платформенно-ориентированных методов визуализации как некого изображения, сформированного растровыми объектами и векторными примитивами. FireMonkey изначально реализовывала принцип строгого разделения элемента управления на две составляющие: «поведенческую» и «визуальную».


Всеволод Леонов, Embarcadero Technologies

Первая в целом повторят даже не основы VCL, а суть объектно-ориентированного программирования. Компонент есть класс, классы компонентов образуют иерархию, где можно выделить семейства и модули. Класс компонента слабо связан с тем, как он изображается.

Визуальная «картинка» формируется динамически, она не прописана жёстко в классе компонента. Изображение или «стиль» в FireMonkey загружается в компонент при запуске приложения. Мы имеем некий функциональный каркас для компонента, а «обшивка» или «облицовка» может быть изменена, но зачем? Именно затем, чтобы приложения FireMonkey смотрелись аутентично на любой платформе — Windows 7, Windows 8, Mac OS, iOS и, в ближайшем будущем, в Android. Этого традиционная монолитная классовая структура VCL обеспечить не могла.

Здесь особую роль играет технологичность подхода. Принципиально можно взять библиотеку VCL и «нафаршировать» WinAPI и всеми другими возможными платформенными вызовами. На очень ограниченном подмножестве компонентов это ещё можно сделать, но VCL содержит несколько сотен компонентов, поэтому такой подход мог бы просто «убить» VCL. Было принято решение «не трогать» VCL, а новые возможности развивать на новой платформе — FireMonkey. Данная технология даже обладает определённым техническим изяществом — в момент сборки проекта под конкретную платформу среда Delphi IDE подключает нужный компилятор, а компоненты интерфейса получают платформенный стиль.

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

Когда стало ясно, что FireMonkey будет введена отдельной новой платформой, нужно было выбрать правильную стратегию сосуществования: Embarcadero не хотела никоим образом оказать негативное влияние на пользователей VCL. Поэтому мы выбрали следующий план: VCL остаётся идеологически и архитектурно стабильной для обеспечения максимально возможной совместимости, облегчая миграцию проектов на современные версии. Развитие FireMonkey будет идти естественным и параллельным путём, без «оглядки» на VCL.

Слабым местом такого решения является достаточно проблематичная миграция с VCL на FireMonkey в рамках одного проекта. Но зато для нового проекта разработчик может выбрать FireMonkey для обеспечения мульти-платформенности своего результирующего приложения. После релиза XE4 с поддержкой iOS мы уже можем говорить о ярких конкурентоспособных преимуществах Delphi для начала мобильной разработки в корпоративной среде, которые буду увеличены после реализации планируемой поддержки Android.

Поэтому как такового явного «отказа» от развития VCL нет. В новых версиях VCL-часть Delphi также развивается. Это и поддержка 64-bit, и введение стилизации для визуальных компонентов, и реализация механизма гибких динамических связей или «байндинга», и включение библиотеки FireDAC для работы с базами данных в VCL-проектах. Просто на фоне гигантского качественного скачка за счёт FireMonkey прогресс в VCL выглядит несколько непроявленным. Но, как бы то ни было, VCL — неотъемлемая часть Delphi и останется таковой ещё на долгие годы. Хотя эволюция платформ и современное положение дел в области ОС для настольных систем и мобильных устройств таковы, что будущее однозначно за FireMonkey.

В интервью мы уже обсудили поддержку iOS, давайте расскажем нашим читателям о поддержке других новейших технологий со стороны последней RAD Studio XE4, например, таких как Windows 8 и WinRT, 64-битных систем, MacOS и так далее. Можно перечислить, что вы ещё можете предложить современному избалованному новшествами программисту?

Скорее всего, современный программист не «избалован» новшествами. Для крупных проектов любое «новшество» зачастую оборачивается гигантским объемом работ.

Например, все долго ждали , многие тут же бросились переводить свои коды на новую платформу. Но выясняется, что даже весьма профессиональные команды к этому не готовы. Компилируемый 64-битный код не означает работоспособный. Стали всплывать «грехи молодости», например, использование инструкций в предположении о 4-байтном размере адреса. Отсутствие культуры проведения тестов, вкупе с технологической неготовностью в сжатые сроки внедрить данный процесс.

И тут — чем больше проект, измеряемый, допустим, количеством строк исходного кода, тем аккуратней и взвешенней относятся программисты к различного рода нововведениям в диапазоне от внешнего вида «кнопки» в интерфейсе до «синтаксического сахара» в компиляторе.

Одним из таких «проблематичных» достижений явился выход Windows 8. Лично у меня, как пользователя ПК, и просто современного IT-специалиста — Windows 8 вызывает восторг. Но для разработчиков, которым прислали партию компьютеров под Windows 8 с ТЗ на разработку под новую ОС в нагрузку, это означает определенные сложности.

Мы постарались максимально комфортно и безболезненно обеспечить поддержку разработки под новый интерфейс этой ОС. Поэтому и для VCL, и для FireMonkey введены специальные стили, а программист может либо перестроить интерфейс приложения, либо создать заново приложение, которое будет неотличимо от «родного» для Windows 8 по внешнему виду. Конечно, есть потребность в «нативной» поддержке Windows 8 за счёт WinRT. Но здесь сказывается приоретизация целей в современных условиях. Mac OS, iOS, Android в ближайших планах не дают пока возможности говорить о полноценной поддержке WinRT в ближайшем будущем.

Стратегической целью Embarcadero, конечно, является мульти-платформенность. Релиз RAD Studio XE4 явился ключевым, прежде всего из-за поддержки iOS. Действующий программист, использующий VCL, может в считанные часы начать разработку под iOS. Даже простое мобильное приложение может быть мгновенно преобразовано в мощный проект, работающий в рамках сложившейся инфраструктуры. Не надо думать, что это просто новый компилятор к FireMonkey и новый стиль для обеспечения соответствия интерфейсу iOS.

Это и новый визуальный дизайнер, и встроенная поддержка различных форм-факторов, и библиотеки доступа к данным, включая новую FireDAC, и технология LiveBindings для гибкого и динамического связывания с корпоративными данными. Все эти нововведения поступают синхронно — и для Windows, и для Mac OS, и для iOS. Операционная система Mac OS развивается не так стремительно, поэтому таких проблем, как переход Windows 7 — Windows 8 там нет. Но появились дисплеи Retina, и это потребовало отдельного внимания. Сейчас любое MacOS-приложение, созданное в Delphi XE4, автоматически включает в себя два стиля — «обычный» и «высокочёткий».

Т.о. одно и то же приложение может иметь одинаково качественный «нативный» интерфейс на любом настольном компьютере от Apple.

Компания Embarcadero своими новыми инновационными релизами не хочет «удивить», «поразить» или даже «развлечь» разработчиков. Скорее, наоборот, IT-сфера и так уже полна различных сюрпризов: новые устройства, новые платформы, новые пользователи, новые их потребности, новые сценарии взаимодействия. Добавьте сюда ещё и новые технологии разработки ПО, и программистам просто не останется времени на создание новых систем и на существующих — они будут только и делать, что проводить миграцию из одной среды в другую, со старой библиотеки на новую, с одного языка на другой.

Но мы и не исповедуем отказ от всего нового. Мы лишь хотим обеспечить преемственность всего — кода, интерфейса, проекта, даже профессиональных навыков при появлении новых платформ и устройств. Можно сказать, что мы боремся с нездоровым консерватизмом в отношении новых платформ за счёт здорового консерватизма в средствах разработки. Не ждите от Embarcadero экзотических продуктов, нестандартных языков программирования и диковинных средств разработки.

У нас вы всегда найдёте — визуальную разработку, классические языки, «нативный» код, и пусть новыми будут целевые платформы для ваших приложений, созданных всё тем же проверенным классическим способом.

Прошло больше трех лет с того момента, как подразделение CodeGear, отвечающее за создание таких всемирно известных инструментов, как Delphi, C++Builder и JBuilder, а также СУБД Interbase, стало частью компании Embarcadero Technologies, известной своими инструментами для проектирования и администрирования баз данных, и два года - с тех пор, как мы обсуждали на страницах нашего журнала, чего ожидать в области развития инструментов, столь популярных у российских разработчиков. О том, что нового было сделано в этой области за последние два года и чего ждать в ближайшее время, мы попросили рассказать Дэвида Интерсимоне, вице-президента по связям с разработчиками и главного евангелиста компании Embarcadero Technologies, и Кирилла Раннева, главу представительства Embarcadero Technologies в России. Для самых молодых наших читателей сообщим, что это далеко не первое интервью, которое Дэвид и Кирилл дают КомпьютерПресс, - наше сотрудничество продолжается уже второй десяток лет. И примерно столько же лет мы периодически публикуем обзоры инструментов для управления базами данных, в которых большое внимание уделяется продуктам компании Еmbarcadero.

КомпьютерПресс: Дэвид, ваше подразделение является частью Embarcadero уже три года. Два года назад вы были полны энтузиазма по поводу того, что оно стало частью компании, близкой вам по целям и духу. Изменилось ли что­то за это время? Испытываете ли вы и ваши коллеги прежний энтузиазм?

Да, я по-прежнему полон энтузиазма. Главное изменение, произошедшее с того момента, как мы стали частью компании Embarcadero, - это то, что было сделано много инвестиций в развитие Delphi. Увеличилось количество сотрудников, работающих над средствами разработки, возросло количество технологий, которые мы можем разрабатывать или, при необходимости, приобретать.

Выпуск RAD Studio XE 2, который мы планируем продемонстрировать в Москве, - это самый крупный выпуск данного продукта с огромными возможностями и большим количеством поддерживаемых платформ со времен первой версии Delphi, созданной еще для 16-разрядной версии Windows и бывшей инновационным продуктом, который соединил компонентный подход и компиляцию в машинный код. Теперь мы поддерживаем разработку не только для Windows, но и для Macintosh, не говоря уже о веб­разработке и создании приложений для мобильных устройств, и эти приложения для разных платформ могут иметь единый код.

Новая платформа разработки - FireMonkey - это совместная работа компании Embarcadero и недавно приобретенной российской фирмы KSDev из Улан­Удэ, производителя компонентов для векторной графики, DirectX и OpenGL, технологий создания графических эффектов и компонентов Delphi, использующих графический процессор с PixelShader 2.0. Мы приобрели компанию KSDev (см. ksdev.ru) год назад и начали совместные работы с целью создания многоплатформенного средства разработки, включающего платформу с целью разработки приложений FireMonkey с компонентами для Delphi и C++Buider для создания пользовательского интерфейса приложений, интеграции с базами данных, обработки графики с применением графического процессора и интеграции с операционной системой.

С помощью FireMonkey можно создать приложение, при выполнении которого совместно работают центральный и графический процессоры, а затем с помощью разных компиляторов и библиотек времени выполнения (Run-time Libraries, RTL) можно скомпилировать его для Windows, Mac OS или iOS. Вместо того чтобы изучать программирование с применением различных графических библиотек, изучать API разных платформ, имеющих различные системы координат и разные возможности, разработчики, использующие Delphi и C++Builder, могут применять один и тот же компонентный подход, визуально редактируя формы и осуществляя подключение к базам данных путем перемещения компонента мышью. Это принципиально новый способ создания приложений, выполняющихся на разных платформах, и за ним будущее. Если вы захотите добавить для вашего приложения поддержку других операционных систем и платформ, не потребуется его заново проектировать и разрабатывать - достаточно будет просто перекомпилировать его.

Мы создаем новые компиляторы, генерирующие машинный код (native code). Сегодня есть компиляторы Delphi для 32- и 64-разрядных версий Windows, 32-разрядных версий Mac OS 10. И мы работаем над компиляторами Delphi и C++Builder следующего поколения, которые позволят создавать высокопроизводительный машинный код как для перечисленных, так и для других платформ, таких как Android или Linux, и сохранять тот же самый дизайн, те же самые компоненты, тот же самый код за счет применения разных компиляторов и библиотек времени выполнения.

Как видите, причин для энтузиазма у меня достаточно. И разработчики, с которыми я встречаюсь по всему миру, знают, что Embarcadero вкладывает много средств в Delphi и C++Builder, а также в средства разработки для PHP.

КП: Каких успехов в области интеграции инструментов двух компаний вы сумели достичь за прошедшие два года? Каковы планы компании Embarcadero на будущее в этой области?

Д.И.: На момент, когда подразделение CodeGear стало частью Embarcadero, эта компания имела команды разработчиков в Торонто, Монтеррее и Румынии, мы находились и по-прежнему находимся в Скоттс­Вэлли и в России, в Санкт-Петербурге. У Embarcadero были инструменты для разработчиков и администраторов баз данных, у CodeGear - средства разработки приложений, но последние тоже используют базы данных. Объединение компаний - это объединение экспертизы, знаний в области баз данных, оптимизации кода, в том числе серверного. Объединение компаний привело также к созданию нового продукта AppWave - специальной технологии для превращения обычного Windows-приложения в нечто очень простое в использовании (наподобие приложений для iPhone или других устройств). AppWave позволяет не устанавливать приложение, а просто выбирать его и запускать с сервера­хранилища подготовленных приложений (app), при этом оно будет выполняться на пользовательском компьютере, не внося изменений в его реестр и системную область файловой системы. Кстати, браузер приложений AppWave написан на Delphi. Embarcadero использует Dephi для собственных разработок и нашу экспертизу в области разработки приложений.

Приложение для iPhone (iOS), созданное
с помощью платформы FireMonkey

Можно также применять интеграцию наших средств разработки и DB Optimizer для оптимизации SQL-запросов при создании приложений. Передавая SQL-код непосредственно в DB Optimizer, можно профилировать его, тестировать и вернуть обратно в среду разработки его оптимизированную версию. Экспертиза Embarcadero в области баз данных также позволила улучшить технологию DataSnap. Благодаря разработчикам из Торонто мы получили много знаний об архитектуре многозвенных систем и баз данных. Сейчас мы обладаем совместной экспертизой в области создания серверного кода и хранимых процедур в обеих компаниях. У нас есть такие инструменты, как RapidSQL и DB Change Manager, а также среды разработки, которые упрощают создание серверного кода, - например технологии Code Insight и Code Completion позволили создать технологии SQL insight и SQL Completion. Наши общие подходы к созданию клиентского и серверного кодов, наша общая философия позволяют придавать общие черты инструментам для управления базами данных и средствам разработки приложений.

Кирилл Раннев: Хочу добавить кое­что важное. С коммерческой точки зрения очень важно, как мы поставляем наши инструменты. Например, новый выпуск RAD Studio XE 2 Ultimate включает полный набор инструментов DB Power Studio. Это очень мощный набор инструментов, включающий среду разработки запросов RapidSQL, инструмент управления изменениями DB Change Manager и средство оптимизации запросов DB Optimizer, позволяющие осуществлять важную часть процесса разработки и развертывания, управляя изменениями в модели данных, базе данных, коде и т.д. Это очень хорошая и правильная комбинация технологий.

Д.И.: Но, если нужно, разработчики могут применять Subversion для управления версиями исходного кода и DB Change Manager для управления версиями метаданных. Можно использовать профилирование кода и DB Optimizer для оптимизации серверного кода, RapidSQL для создания и отладки серверного кода и наши среды разработки для создания и отладки приложений. Эта комбинация техологий в RAD Studio XE Ultimate Edition демонстрирует параллели между моделями разработки баз данных и приложений. Большинство разработчиков, создающих бизнес-приложения с помощью Delphi и C++Builder, работают с базами данных и нуждаются в этих инструментах, и RAD Studio XE Ultimate Edition - это отличная комбинация для таких разработчиков.

КП: Современный пользователь - это уже не пользователь одной только платформы Windows. Мы применяем мобильные устройства, iPhone, iPad, устройства на базе платформы Android. Это означает, что разработчики должны начать ориентироваться на различные платформы без существенного увеличения инвестиций в обучение - то есть нужны универсальные инструменты. Очевидно, что ожидать появления универсальных инструментов от производителей платформ нереально, и в этом вопросе мы можем рассчитывать только на независимых производителей инструментов. В чем мы можем рассчитывать на компанию Embarcadero?

Д.И.: Нам еще многое предстоит сделать в области поддержки платформ. Сегодня мы представляем поддержку для платформы iOS для iPhone и iPAD, затем нашу поддержку получат смартфоны на базе платформы Android, Windows 7 и Blackberry. В RAD Studio XE 2 мы начали с создания платформы FireMonkey для iOS, а затем перенесем FireMonkey на другие платформы.

В то же время существует большое количество операционных систем с поддержкой сенсорных экранов (touch screen), для телефонов, планшетных компьютеров и устройств, настольных компьютеров, и мы будем продолжать добавлять поддержку для них. Кроме того, существуют системы управления голосом, движением, биометрические системы, акселерометры, поэтому мы должны продолжать расширять FireMonkey, чтобы все разработчики могли воспользоваться преимуществами новых платформ. Например, устройство Microsoft Kinect было предназначено для Xbox 360, а сейчас есть соответствующий SDK (Software Development Kit) и для Windows. И у нас уже есть примеры, в которых мы используем движение для управления приложением примерно так же, как обычно применяются мышь или клавиатура.

Когда вы создаете приложения с большим количеством сложной графики, вы генерируете целый мир новых пользовательских интерфейсов. Если мы имеем дело с операционной системой Windows, мы инкапсулируем ее прикладной программный интерфейс Windows API в библиотеке VCL (Visual Component Library - библиотека визуальных компонентов, являющаяся составной частью средств разработки Delphi и C++Builder. - Прим. ред. ), которую, кстати, можно применять и далее. И в FireMonkey мы инкапсулируем API операционной системы. Но сегодня мы манипулируем формами и графикой гораздо более широко. Можно также добавить физические свойства пространства для анимации и спецэффектов. Кроме того, существует огромное количество иных дополнительных возможностей по созданию пользовательских интерфейсов, которые мы собираемся реализовать в ближайшие несколько лет для разных платформ, мобильных и планшетных устройств.

Компания Microsoft недавно обнародовала подробную информацию о Windows 8, которая должна выйти через год. Эти нововведения мы будем поддерживать в библиотеке VCL и в платформе FireMonkey. Но Delphi - это средство разработки, предназначенное не только для Windows, но и для Macintosh, iPhone и iPad. Мы также развиваем наши продукты для PHP, поддерживаем jQuery Mobile, используем прикладной программный интерфейс iOS для разработки мобильных клиентских приложений и создаем серверные PHP-приложения, используя мастера и инструменты для генерации клиентского JavaScript- и HTML-кодов и каскадных таблиц стилей. Мы можем создавать пакеты из приложений PHP и клиентских приложений с native-кодом для iPhone iOS, при этом такой клиент будет общаться с сервером PHP. А тот, в свою очередь, будет общаться с сервером баз данных и с веб­службами - со всем, что нужно для бизнеса.

Среда разработки RadPHP XE2. Создание мобильного веб-приложения
с применением компонентов jQuery Mobile для iPhone 3G

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

КП: Не могли бы вы подробнее рассказать о платформе FireMonkey?

Д.И.: Как я уже отметил, библиотека VCL, созданная для Windows, будет продолжать развиваться и совершенствоваться. Но сегодня, если вы хотите реальной разработки бизнес-приложений, вы должны создавать их для разных платформ. Для этого и предназначена платформа FireMonkey. Она поддерживает создание пользовательских интерфейсов с высоким разрешением, высокопроизводительной трехмерной графикой, высокой скоростью смены кадров и, что немаловажно, использует для этого графический процессор.

Применять подобные возможности можно при создании научных, инженерных и бизнес-приложений. Подобные приложения могут подключаться к базам данных с помощью технологии dbExpress, по-прежнему используя знакомые разработчикам невизуальные компоненты, такие как ClientDataSet или DataSource, применять технологию DataSnap, подключаться к любым базам данных, SOAP- и REST-серверам. Можно создавать привлекательные элементы управления, кнопки с боксами, необычные таблицы и другие интерфейсные элементы, причем в двух- и трехмерном вариантах. Можно загрузить в приложение готовую трехмерную модель и соединить ее с двумерной формой, в которой ее можно вращать и рассматривать с разных сторон. Можно создать куб с данными или трехмерную бизнес-диаграмму и вращать их c помощью мыши, клавиатуры или даже устройства Kinect, а можно войти внутрь куба и посмотреть на разные его поверхности изнутри. И всё это можно сделать с помощью графического процессора с высокой скоростью. Затем это же приложение можно скомпилировать для другой платформы, например для Mac OS.

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

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

В Windows для работы с двумерной графикой высокого разрешения можно применять библиотеки Direct2D, а для трехмерной графики - Direct3D. В Mac OS для тех же целей используются библиотеки Quartz и OpenGL. Для iOS применяются библиотеки Quartz и OpenGL ES. Но всё это скрыто от разработчика - он использует платформу FireMonkey, ее систему координат и прикладной программный интерфейс, не задумываясь об этих библиотеках, и может компилировать одно и то же приложение для разных платформ.

Вспомним, что такое VCL. VCL - это компонентная «обертка» вокруг Windows API. Мы имеем дело с ресурсами, меню, диалоговыми окнами, цветами, стилями, сообщениями Windows. Будучи, в отличие от VCL, многоплатформенной «оберткой», FireMonkey сохраняет те же событийную и компонентную модели, позволяя мыслить в терминах событий (например, событий OnClick, OnHasFocus, onMouseDown и onKeyDown), но обрабатываются при этом события Macintosh или iPhone.

Платформа FireMonkey также поставляется с полной системой анимации элементов пользовательского интерфейса. Это, конечно, не всеобъемлющая система анимации типа Pixar, но она позволяет применять такие эффекты, как анимация растровых изображений, подсветка фокуса у элемента пользовательского интерфейса и работа с векторной графикой. Разработчику доступно более 50 визуальных эффектов: размытие, превращение изображения в черно­белое, растворение, переходы, отражение, создание теней - все типы эффектов, доступные в современных графических процессорах, которые сейчас есть практически в любом компьютере. Приложение, созданное с применением платформы FireMonkey, посылает команды графическому процессору, который и выполняет всю работу по отображению графики и созданию пользовательского интерфейса. При этом центральный процессор свободен для вычислений и обращений к операционной системе. Разработчику же остается только правильно размещать компоненты.

Самое фундаментальное в платформе FireMonkey - это способ, с помощью которого она строит пользовательский интерфейс. Есть средства размещения растровой графики на интерфейсных элементах, таких как меню, кнопки и полосы прокрутки. В FireMonkey мы используем для этой цели векторную графику с применением графического процессора. С позиции программирования это всё те же элементы управления, но всю работу по их отображению осуществляет графический процессор. Мы можем применять стили к элементам управления, делать приложение похожим на приложение для Mac OS или для Windows, создавать свой собственный стиль, применять свои стили к интерфейсным элементам (например, сделать кнопку прямоугольной или круглой, изменив ее стиль в редакторе форм) - для этого в среде разработки есть редактор стилей. Можно создать свой собственный стиль, а можно изменить стиль уже готового приложения.

Платформа FireMonkey - средства разработки
и поддерживаемые платформы

Если помните, в библиотеке VCL было ограниченное число элементов управления - контейнеров (то есть позволяющих размещать в них другие элементы), а в FireMonkey каждый элемент управления - это контейнер. Это означает, что каждый элемент управления может содержать любой другой элемент управления. Например, внутри элементов выпадающего списка могут быть изображения, кнопки, поля редактирования и другие элементы управления. И еще можно размещать компоненты по слоям.

Система рендеринга FireMonkey достаточно гибкая - она может использовать библиотеки Direct2D, Direct3D и OpenGL, посылая команды графическому процессору. Чтобы добиться того же в VCL, нужно было генерировать отдельный буфер вне экрана, создавать изображение в нем, вызывая соответствующие функции графических библиотек, а затем отобразить его на форме.

Примеры графических эффектов, поддерживаемых FireMonkey

Если же у вас нет графического процессора - вы по-прежнему можете применять двух- или трехмерные формы и использовать элементы управления FireMonkey. В этом случае платформа FireMonkey будет задействовать библиотеки GDI+ или другие подобные библиотеки и осуществлять те же эффекты и анимацию либо манипуляцию трехмерными объектами.

Еще одна черта FireMonkey - новая система связывания интерфейсных элементов с данными, открытая и гибкая. В VCL присутствуют два типа интерфейсных элементов: связываемые с данными и не связываемые с данными (например, TDBEdit и TEdit). В FireMonkey каждый элемент управления может быть связан с данными, причем любого типа. Это может быть просто выражение, поле из набора данных, данные из созданных разработчиком объектов или результаты вызова методов.

Кроме того, при создании приложения можно загрузить в него готовую трехмерную модель и использовать ее - такие возможности часто требуются и в бизнес-приложениях, и в приложениях для инженерных расчетов. У нас есть клиент, который создает приложения для логистики. У них была информационная система, построенная с помощью Delphi, а в ней - приложение, которое рисовало план и отображало информацию из источников данных. Недавно они сделали нечто интересное - нарисовали в AutoCAD полностью автоматизированный трехмерный склад, и их приложение позволяет увидеть, как автоматический погрузчик двигается по складу и помещает товар на полки. И они выкладывают данные из источников на соответствующее изображение.

Примеры изменения стилей приложения

КП: Какие форматы трехмерных моделей сейчас поддерживаются?

Д.И.: В этом релизе мы поддерживаем загрузку моделей из AutoCAD, Collada (средство трехмерного моделирования с открытым кодом. - Прим. ред .), Maya, формат OBJ, который поддерживается многими производителями средств трехмерной графики.

КП: А какие еще форматы планируется добавить?

Д.И.: Мы планируем добавить форматы 3DS (3D Studio MAX), SVG (обычно этот формат применяется для двумерной векторной графики, но иногда и для трехмерной), Google SketchUp. Возможно, мы будем поддерживать и другие форматы.

КП: Требует ли использование трехмерных моделей в приложениях, созданных с помощью FireMonkey, лицензии на соответствующее средство трехмерного моделирования?

Д.И.: Нет, не требует. Всё, что мы делаем, - это читаем файл с моделью. Мы импортируем модель, но не экспортируем ее (хотя, конечно, вы можете написать приложение, которое сохранит модель в вашем собственном формате). Мы не претендуем на то, чтобы быть производителем инструментов трехмерного моделирования - для этого вы можете применять AutoCAD, 3D Studio Max, Maya или любое другое средство трехмерного моделирования, а в наши приложения импортировать созданные модели.

КП: Насколько производительны приложения, созданные с применением FireMonkey, на современных аппаратных платформах?

Д.И.: Производительность довольно высока. К примеру, рендеринг трехмерной формы с тремя сферами и тремя источниками освещения на MacBook Pro может оcуществляться со скоростью 100 кадров в секунду. А может достигать и 600 - это зависит от того, что именно мы делаем. Опять же всё зависит от мощности графического процессора.

КП: Означает ли это, что с помощью FireMonkey можно создавать игры, удовлетворяющие современным требованиям?

Д.И.: Мы не позиционируем наши средства разработки в качестве инструмента для игр. Тем не менее, используя высокую производительность современных графических процессоров, с помощью FireMonkey можно создавать и игры - ведь создают же их с помощью Direct3D или OpenGL.

КП: Какие работы вы ведете сейчас в области поддержки распознавания жестов и иных новомодных вещей? Доступна ли такая поддержка?

Д.И.: У нас пока нет поддержки жестов в этом релизе. Управление жестами будет добавлено в одном из будущих релизов FireMonkey, а пока можно использовать поддержку жестов, встроенную в операционную систему.

Михаил Филиппенко, директор компании Fast Reports, Inc.

К.Р.: Мы уже говорили, что у технологии FireMonkey российские корни - ее основы были созданы в нашей стране, а потом и сама технология, и ее разработчики влились в состав Embarcadero. Вообще, отрадно видеть рост российской составляющей в составе RAD Studio и Delphi. Это и деятельность нашего центра разработок в Санкт-Петербурге, и вклад независимых российских разработчиков. Например, в состав Rad Studio XE2 вошел генератор отчетов FastReport - известный во всем мире и очень популярный в нашей стране. Он родом из Ростова-на-Дону.

КП: Хотелось бы поговорить о компиляторах. Что за компилятор используется при создании приложений для iOS?

Д.И.: Для iPhone или iPad у нас нет собственного компилятора Delphi - мы пока не разрабатывали компиляторы для процессоров ARM, применяемых в этих устройствах. Для iOS мы временно используем компилятор и библиотеку времени выполнения Free Pascal. Но мы работаем над следующим поколением компиляторов, в том числе и для процессоров АРМ. А вот для Windows и Mac OS компиляторы есть, поскольку обе аппаратные платформы основаны на процессорах Intel.

КП: А что было сделано в области создания компиляторов в последние два года?

Д.И.: У нас есть 32- и 64-разрядные компиляторы Delphi для Windows и Mac OS. И мы работаем над новым поколением компиляторов Delphi и C++. Работа над ними еще продолжается, но, когда она будет завершена, у нас будут компиляторы Delphi для процессоров ARM, платформ Android, Linux и всего, что угодно. И у нас будут 64-разрядные компиляторы C++ для Windоws и других платформ, совместимые с последним стандартом языка С++, только что принятым ISO.

КП: Что сегодня происходит с поддержкой «облачных» вычислений в средствах разработки Embarcadero?

Д.И.: В RAD Studio XE 2 мы поддерживаем перенос приложений в «облако» Microsoft Azure или Amazon EC2 с применением средства Platform Assistant. И у нас есть серверные компоненты для Сloud Storage for Azure и Amazon S3 для хранения таблиц, двоичных данных, очередей сообщений. В предыдущей версии RAD Studio XE мы также поддерживали развертывание приложений в Amazon EC2, но поддержка хранилища в ней отсутствовала.

Поддержка «облачных» вычислений в RAD Studio XE 2

КП: Два года назад вы рассказывали о новом решении All-Access. Насколько оно оказалось востребовано? Каковы его преимущества для системных интеграторов и разработчиков?

Д.И.: В мире решение All-Access и инструмент для «облака» AppWave применяются очень широко. Они предназначены для упрощения использования приложений как нашей компании, так и других производителей. Фактически это решение для управления лицензиями и применением приложений, и оно удобно для крупных компаний. Небольшие же фирмы, в которых нет специальных групп сотрудников, ответcтвенных за управление приложениями, могут положить приложение в репозиторий, выбрать имена пользователей из базы данных и обеспечить использование этих приложений без необходимости вспоминать, где лицензионный ключ и сколько лицензий имеется. All-Access и браузер AppWave предназначены для управления и версионностью, и контролем доступа.

К.Р.: Рынок настолько многообразен, а пользователи настолько разные, что невозможно одним решением охватить все потребности. Поэтому мы стремимся к разнообразным «упаковочным» решениям. Мы проделали большую работу по унификации способов лицензирования, управления лицензиями и инсталляции продуктов. Эта линия решений включает средства управления лицензиями и предоставлением доступа не только для продуктов Embarcadero, но и для любых других продуктов, включая внутренние разработки компаний.

Работа по комплектации средств разработки в эффективные наборы для пользователей по-прежнему продолжается. У нас есть All-Access - супер­сет, в котором объединены все продукты Embarcadero. Если заказчик приобретает версию All-Access Platinum, он получает все инструменты, которые есть в Embarcadero. Но иногда этот набор оказывается избыточен, к примеру для специалистов по базам данных мы сделали два других набора - DB Power Studio Developer Edition и DB Power Studio DBA Edition. Разница между ними в том, что для разработчика мы предлагаем RapidSQL - средство разработки серверного кода, а для администратора туда встроен DBArtizan - средство администрирования баз данных, более широкий продукт, чем RapidSQL. Для специалистов у нас есть следующие наборы All-Access: набор, включающий все продукты, DB Power Studio для разработчиков, DB Power Studio для администраторов, ER Studio Enterprise Edition для архитекторов и всех, кто занят моделированием. Есть комбинации для разработки приложений и для администраторов. Delphi - это средство для разработчика, и к нему очень разумно добавить средства SQL-разработки и средства оптимизации. И наконец, DB Change Manager - это вполне логичный инструмент для того, чтобы управлять сложностью тех изменений, которые происходят с базами данных в ходе их жизненного цикла.

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

КП: Если не секрет, кто в России применяет All-Access?

К.Р.: У нас есть заказчики, которые купили All-Access, отталкиваясь от Delphi. Многие из них создают сложные клиент-серверные системы с SQL Server и Oracle, и им сразу понравился наш кроссплатформенный инструментарий для баз данных. У нас есть компания-клиент, которая работает с Delphi, начиная с первой версии, и год назад она перешла c использования Delphi к набору All-Access. Два инструмента, которые гарантированно применяют в этой компании все разработчики, - это Delphi и DBArtisan. И есть заказчики, которые пришли к All-Access со стороны баз данных. Их основная задача - администрировать базы данных, но при этом они иногда занимаются разработкой приложений. Среди клиентов, использующих All-Access, - медиакомпании, машиностроительные предприятия и представители других отраслей.

Отдельно хотелось бы остановиться на небольших компаниях. Очень часто в маленьких коллективах разработчик делает всё, и такая компания иногда покупает большие продуктовые наборы All-Access для одного-двух разработчиков. В крупных коллективах не поощряется, чтобы разработчик выполнял, к примеру, еще и роль администратора баз данных, поэтому обычно там популярны небольшие продуктовые наборы, а в мелких компаниях такое совмещение обязанностей вполне допустимо.

Delphi Architect - это активно продаваемый продукт, включающий средства моделирования и программирования. Число его проданных копий, правда, меньше, чем версии Delphi Enterprise, но оно тоже велико. Замечу, что в 2010 году мы оказались лучшей страной по объему продаж, при том что все страны пережили кризис. Этот рост был связан не столько с экономическими факторами, сколько с тем, что вышедшая в конце 2009 года версия RAD Studio XE оказалась очень востребованной. И пока мы ожидаем дальнейшего роста продаж.

Мы сделали еще один разумный шаг, крайне востребованный в России. Степень легализации различных версий наших продуктов разная: чем выше версия, тем больше она легализована, ведь раньше программное обеспечение не так активно покупалось. Начиная с версии RAD Studio XE лицензия распространяется на версии 2010, 2009, 2007 и даже на Delphi 7 - продукт широкой распространенности.

Сегодня разработчики сталкиваются с тем, что у них есть и новые проекты, и проекты в состоянии поддержки. Большое количество проектов было переведено с ранних версий Delphi на версию 7 и остается в рамках этой версии, продолжая работать на относительно небольших ресурсах. Никто не переводит их на более новые версии, но они поддерживаются в жизнеспособном состоянии. И сейчас мы позволяем за небольшие деньги (меньшие, чем цена лицензии Delphi 7) получить и RAD Studio XE, и Delphi 7 - то есть мы легализуем разработчика и для реализации новых проектов, и для проектов поддержки.

КП: Как вы оцениваете нынешнее состояние сообщества Embarcadero?

Д.И.: Это сообщество велико и очень требовательно. Им нужно всё и немедленно - они же разработчики. Но иногда, чтобы сделать что­то правильно, необходимо много времени.

Несколько лет назад мы брали компонентную архитектуру Windows и помещали ее в десктопы Linux. Теперь мы видим, что это было не самое верное решение. Правильное решение - создать платформу для приложений. Приложения даже для разных платформ имеют меню, окна, графику, сетевой доступ и доступ к устройствам. В различных платформах могут быть разные модели управления потоками или обработки исключений, но в коде приложения мы видим одинаковые try-блоки. Наша работа - упростить разработчикам создание бизнес-приложений и компиляцию их для тех платформ, на которых предполагается их использовать, независимо от того, как устроена система инструкций соответствующих процессоров и каковы иные особенности этих платформ. И FireMonkey - это именно то, что нужно для решения данной задачи.

КП: Если компания создаст новое устройство и захочет иметь его поддержку в FireMonkey, будет ли это возможно?

Д.И.: С компиляторами нового поколения, которые будут иметь не зависящий от платформы front-end и зависящий от платформы back-end, это будет вполне возможно. Пока же для каждой операционной системы мы создаем компилятор и библиотеку времени выполнения с нуля.

Любое современное новое устройство, как правило, обладает графическим пользовательским интерфейсом (многие из них имеют двухъядерный процессор и графический процессор) и стандартными SDK для разработчиков. Всё это упрощает создание поддержки устройства в FireMonkey. Если же новое устройство будет обладать только библиотеками для двумерной графики типа Quartz, мы сможем осуществить поддержку в FireMonkey и такого устройства, но для этого потребуется ориентировочно несколько месяцев. Тем не менее многое зависит от платформы: не все платформы поддерживают все возможности, например в iOS нет меню и диалоговых окон и вы не сможете поместить соответствующие компоненты на формы таких приложений.

КП: Изменилось ли что­то в политике работы с партнерами? Что делается для того, чтобы доля пользователей ваших продуктов увеличилась? Что осуществляется в России?

Д.И.: Наша партнерская экосистема широка - существуют сотни производителей инструментов и компонентов, которых нет в наших продуктах, и у нас есть программа технологического партнерства. Поэтому разработчикам доступен широкий спектр компонентов, технологий и инструментов. И решения, которые они создают для своих клиентов, оказываются лучше, чем если бы использовались только наши продукты. А для продаж у нас есть офисы во многих странах, реселлеры и дистрибьюторы.

К.Р.: Нам важно не количество партнеров, а качество работы каждого конкретного партнера. Сейчас мы хотим сосредоточиться на тесном взаимодействии с существующими партнерами, хотя пул партнеров остается открытым. Партнеров у нас много, и мы должны помогать им в плане технологий. Мы работаем с разработчиками, а они знают, чего хотят, и знают, что доступно на рынке, и возможности партнеров должны этому соответствовать.

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

КП: Дэвид, Кирилл, большое спасибо вам за интересное интервью. Позвольте от имени нашего издания и наших читателей пожелать вашей компании дальнейших успехов в создании ваших удивительных инструментов, столь нужных разработчикам!

Вопросы задавала Наталия Елманова

Что же такое 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 является “безопасным” и перспективным.

Прошло уже достаточно времени с тех пор, как термин 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 компоненты, или не должны.На практике, начиная новый проект, я оказался перед фактом: надо привыкать и к новым визуальным компонентам и к новому способу извлечения данных для отображения, редактирования и, в конечном счете, сохранения. Что, опять же, не плохо, и не хорошо. Просто для меня получилось именно так.

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

В контексте данного блога этот проект прежде всего интересен тем, что реализован на FireMonkey и является потрясающей демонстрацией возможностей данной платформы. И вот, буквально на прошлой неделе, была выпущена публичная бета продукта. Таким образом, читатели блога могут сами “пощупать” действительно сложное FireMonkey приложение.

Пару слов о программе. В первую очередь нужно отметить то, что нынешняя версия Sphere позиционируется немного по-другому. Да, иногда так бывает…

Новая SphereLive это, не просто очередной мессенджер. Прежде всего, это инструмент, позволяющий эффективно организовать образовательный процесс. Он позволяет проводить дистанционные лекции, частные консультации, индивидуальные занятия и другие подобные мероприятия. При этом он оснащён практически всем необходимым для работы. Начиная с уникальной системы передачи файлов и заканчивая мощнейшей подсистемой биллинга.

На данном этапе цены на использования продукта вполне демократичны. При условии ограниченного количества слушателей и небольшом объеме ресурсов, продукт можно использовать бесплатно.

Естественно, что Сфера использует главное преимущество FireMonkey – кроссплатформенность. Сейчас приложение доступно в Windows и MacOS редакциях. Android версия ожидается со дня на день.

Тем не менее, для меня, SphereLive интересна, прежде всего, как инновационный продукт с целым набором оригинальных решений. Иногда просто на уровне “… ух ты, как ты это сделал?” Кстати, один из разработчиков Сферы активно участвует в обсуждениях на форуме, посвящённом FireMonkey . Само по себе это может послужить поводом скачать приложение и обсудить технические вопросы непосредственно с автором. Поверьте, есть на что посмотреть, есть чему поучится.

TListView является одним из ключевых компонентов для построения интерфейса мобильного приложения в FireMonkey . Компонент этот не самый простой в использовании, зачастую предполагает значительный объем кода, зато предоставляет разработчику значительную свободу действий. Конечно, в приложениях можно использовать и TListBox , где все намного проще. Но TListBox , возможно, хорош для отображения фиксированного количества записей, для вывода данных из источников данных, однозначно нужно использовать TListView .

Главные отличия TListView от TListBox в:

  1. TListBoxItem - контрол, TListViewItem - нет
  2. В TListBoxItem можно добавлять любые контролы, используя Parent. В TListVIewItem - нет.
  3. TListVIewItem хранит только данные для отображения
  4. TListVIewItem сам выполняет отрисовку хранимых данных через метод Render
  5. За счет собственно ручной отрисовки в TListVIewItem достигается прирост скорости и малое потребление памяти (хранение только актуальных данных)
  6. Чтобы создать свой вариант TListViewItem , нужно создать свой класс итема, в нем реализовать требуемые данные (например время) и создать in-place редактор для редактирования времени, зарегистрировать его и т. д.

Сам по себе факт повышения производительности и уменьшения потребления памяти – веский аргумент в пользу использования TListView . Но есть и еще кое что.

Во многих Android приложениях мне приходилось наблюдать следующую реализацию списков. При нажатии на элемент списка (Item, если придерживаться выбранной терминологии), производится определенное действие. Обычно вызывается новая форма для редактирования данных. Но при нажатии с удерживанием (Long Tap) производится совершенно другое действие. И эти события не пересекаются. Иными словами Android приложения умеют четко различать “длинное нажатие” от “обычного”. Более того, ни одно из этих событий не срабатывает при скроллинге списка. Наглядный пример – список писем в Яндекс Почта.

Прежде всего хочу поздравить всех читателей блога с прошедшими праздниками и пожелать всего наилучшего в наступившем году.

В силу понятных обстоятельств я не стал делать традиционный новогодний отчет, как и строить какие-либо планы на год. Тем не менее, жизнь не стоит на месте, работа работается, и определенные события в мире Delphi происходят. Подборку пропущенных “новостей из мира Delphi” за время рождественских каникул обязуюсь опубликовать в ближайшее время. А пока расскажу о новом аппарате, который я приобрел.

С характеристиками вы можете ознакомиться на официальном сайте. А субъективное впечатление весьма приятное. Обращает на себя внимание тот факт, что аппарат буквально напичкан фирменным софтом от производителя. Да и от продавцов достался в подарок внушительный комплект софта. В работе смартфон достаточно шустр и вполне оправдывает свою стоимость (примерно $200). К слову, свой предыдущий телефон GSmart 1362 я покупал примерно за те же деньги 2 года назад. Но, как вы, наверняка, догадались, основной интерес для меня заключался в том, как будут работать FireMonkey приложения.

Прежде чем продолжить рассказ о таймере – две новости.

Во-первых, вышел первый апдейт XE7. По традиции он доступен зарегистрированным пользователям. Список исправленных багов вы можете найти . Мне хотелось посмотреть как поведет себя приложение в обновленной среде. Собственно, никаких исправлений вносить не пришлось, хотя поле для экспериментов осталось.

Вторая новость. Действие специальных предложений Embarcadero продлено до конца года:

Ну, а теперь непосредственно к теме поста. В принципе, все, что нам осталось – попытаться запустить уже созданное приложение под Android. Для это используем то, о чем я писал в предыдущих постах. А именно новый . Я отлаживал данное приложение на Nexus 7 , соответственно добавил представление Android 7″ Tablet. Дизайн пришлось “подрихтовать” лишь самую малость.

Наверное свой таймер не писал только ленивый. А в контексте поддержки разработки для мобильных платформ, задачу написания таймера на Delphi вообще можно считать культовой. Вот я и подумал, почему бы в качестве примера разработки FireMonkey приложения не разобрать именно таймер. Под Android, естественно. Конечно же, это будет именно мой взгляд на задачу, которая, хотя и не особо сложная, все же имеет свои нюансы. Возможно, у вас возникнут какие-то замечания, или предложения, было бы замечательно обсудить их в комментариях. Я отнюдь не эксперт в области написания мобильных приложений, поэтому любой ваше замечание будет для меня ценно.

Разрабатывать мы будем именно таймер, в англоязычном понимании этого термина. Т. е. на экране будет отображаться циферблат и четыре кнопки – “Пуск”, “Пауза”, “Стоп” и “Отмена”. Отсчет будет производиться в прямом направлении (т. е. время будет увеличиваться). Вариант, при котором задается время и идет обратный отсчет в англоязычной терминологии называется Stop Watch, возможно я попробую реализовать его позже. То, приложение, которым займемся мы, по функциональности ближе к секундомеру.

Delphi XE7, позволяет значительно упростить процесс разработки, за счет того, что теперь мы можем создать и отладить реальное приложение для Win32, а затем просто добавить представления форм для необходимых мобильных устройств и, немного подкорректировав их, получить рабочее мобильное приложение. Звучит слишком красиво, что бы быть правдой? Возможно. Но проверить данное утверждение я и хочу, реализовав поставленную задачу.

The more frequently I’m asked my colleagues in private conversations if it’s possible to develop mobile applications in FireMonkey or is it a prototype rather than a production solution?

I think, now I can ensure even the out-and-out sceptics.

My bosom friend and colleague Tagir Yumaguzin told me about the project he took part a long time ago. Now, when this project is in pre-release state, we decided that this description will be interesting for the Delphi community. In the essence, this is a really large project implemented in FM. We are talking about Sphere Live project. A little article devoted to that project was recently published in Habrahabr.ru Alexey Glyzin, chief of ‘ ‘ development department agreed to tell more about the project taking into consideration the audience of my blog.

A.B. – Alexey, in general, what your project is?

A. G. : – The idea has not appeared at once and instantly. Before the ‘Sphere’ project our team had been working on the project where stream audio/video technologies were implemented. Later we created our own software that was able to deliver multimedia streams to an unlimited amount of users including the feedback. But we needed to have a billing feature included.
The application had to comply the several requirements. First, the maximally simplified organization of conferences or transmission to the participants which amount we cannot predict. Second, the most important, is to give to our clients an opportunity to earn with our application and to reduce the complexity of the system, amount of instruments needed to use to reach the goal. The ease of organization of courses, webinar or just a consultation.

Небольшая зарубка на память, касающаяся FireDAC в актуальной версии Delphi XE6 . Но прежде, пару слов о том, где искать ответы на вопросы, касающиеся FireMonkey . Русскоязычные пользователи здесь оказались в привилегированном положении.

Еще при подготовке к харьковскому мероприятию в рамках Мирового тура RAD Studio XE5 я столкнулся с небольшой проблемой в работе с SQLite с помощью FireDAC . Если заполненную в Windows приложении базу перенести вместе с приложением на Android , кириллические строки в базе перестают читаться (вместо букв отображаются знаки вопроса). Однако, если заполнять базу непосредственно на мобильном устройстве, русские символы считываются вполне корректно. Данные из базы заполненной в стороннем приложении, или в Delphi приложении, использующем другие компоненты доступа к данным, так же отображались нормально. Слету найти решения не удалось, и мне пришлось процитировать известного украинского футбольного специалиста: “Будем разбираться!”

В отличие от последнего, разобраться с описанной проблемой мне удалось. По умолчанию при подключении к SQLite в FireDAC используется формат строк ANSI.

Если принудительно установить Unicode, то все будет работать как надо. Но есть и неприятный момент. Изменив формат строк придется во всех наборах данных пересоздать список полей, а так же заново подключить компоненты, отвечающие за отображение и ввод данных. Поэтому лучше позаботиться о кодировке сразу.

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

Простой редактор данных в таблице, обычно является частью комплексного приложения. Для редактирования таблиц я обычно использую отдельную форму. Начнем со списка продуктов. Прежде всего, нам необходимо создать DataSet для доступа к данным таблицы. В нашем случае вполне можно воспользоваться компонентом TADTable . Поместим его в DataModule и укажем значение свойства Connection . В редакторе свойства TableName появится список таблиц, из которого выбираем таблицу Products . Если вы все сделали правильно, то сможете присвоить свойству Active значение True. Компонент лучше сразу переименовать (например, ADTProduct). После этого я, обычно, создаю для DataSet’а набор полей. Вызываем редактор полей (двойное нажатие мыши на компоненте) и в контекстном меню выбираем пункт Add All Fields.

Для тех, кто не в курсе поясню суть данной операции. Здесь мы создаем предустановленный набор полей DataSet’a. Если мы этого не сделаем вручную в режиме проектирования, то, в принципе, ничего страшного не произойдет. В RunTime этот набор будет создан автоматически. Но я, все же, предпочитаю создавать его вручную. Причин тому несколько. Во-первых, так удобнее управлять набором полей, ведь мы можем создавать дополнительные (вычисляемые или lookUp) поля самостоятельно в режиме проектирования. Можем так же менять свойства самих полей. А кроме того, мы получаем возможность обращаться в коде к полям по имени компонента TField, что, на мой взгляд, существенно упрощает написание кода.

Как и в случае с VCL приложением, подключим к набору данных компонент TDataSource . Этот компонент обеспечит связь между набором данных и визуальными элементами управления. Свойство DataSet компонента должно ссылаться на наш набор данных (ADTProduct). Ниже я привожу фрагмент DFM файла

object ADTProduct: TADTable IndexFieldNames = "ID" Connection = ADConnection UpdateOptions. UpdateTableName = "Product" TableName = "Product" Left = 64 Top = 192 object ADTProductID: TADAutoIncField FieldName = "ID" Origin = "ID" ProviderFlags = [ pfInWhere, pfInKey] ReadOnly = True end object ADTProductTitle: TStringField FieldName = "Title" Origin = "Title" Size = 50 end object dsProduct: TDataSource DataSet = ADTProduct Left = 120 Top = 192 end

Обратите внимание на одну любопытную особенность, файл формы DataModule сохраняется не в формате FMX, как обычная FireMonkey форма, а в формате DFM, как и в VCL.

Следующим шагом будет создание процедуры открытия набора данных, которую мы должны будем вызывать в RunTime при запуске программы. Создадим ее в том же DataModul’е. Код процедуры предельно прост:

procedure TDM. ConnectToDB ; begin ADConnection. Open () ; ADTProduct. Open () ; end ;

Вызов процедуры разместим в обработчике события OnCreate для DataModule.