Особенности разработки приложений с использованием FireUI

В сентябре 2014 года вышла очередная версия RAD Studio, которая на носит название XE7.

В числе новшеств одним из наиболее значимых является FireUI. Технология, которая представляет собой единый редактор интерфейса для различных платформ.

С обзором FireUI можно ознакомиться на официальном сайте компании Embarcadero и на её канале на YouTube. Поэтому, в данной статье не станем давать общее описание этой технологии и, по сути, перепечатывать содержание вышеуказанных ресурсов. А, вместо этого обратим внимание на некоторые особенности FireUI, которые в нём не освещены либо освещены недостаточно.

Один файл исходного кода и несколько файлов форм.

В версии XE7, для различных платформ используется одна и та же форма с одним общим файлом исходного кода, который собственно и содержит программную логику формы. Соответствующий внешний вид формы обеспечивается за счёт нескольких файлов форм. При этом обязательно существует один «главный» файл формы. Ему соответствует пункт «Master» в выпадающем списке «Views». Также именно этот файл формы используется при компиляции приложения для Windows. Остальные файлы форм предназначены каждый для своей платформы.

Файлы форм различаются между собой благодаря характерным суффиксам в названиях. При этом, «главный» файл суффикса не имеет.

В качестве примера, на скриншоте ниже можно увидеть один файл исходного кода и три файла форм: «главный», для Mac OS X и для Android (для экрана 3,5 дюйма).

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

Каждый сам по себе

Все файлы форм содержат одни и те же компоненты. То есть если на представление формы для Android поместить два компонента Label, то они автоматически также будут помещены на все остальные формы.

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

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

В качестве примера, разместим на представлении формы для Android два компонента Label так чтобы они располагались один под другим.

Как видно, компоненты разместились так как это и должно быть. Теперь посмотрим, что же получилось на «главной» форме.

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

Обработка событий. Главный – значит общий для всех.

Для того чтобы изучить особенности обработки событий напишем простейший код, который при показе формы просто на просто отобразит в первом компоненте Label текстовое сообщение.

При написании этого кода «текущим» представлением формы является «главное».

После компиляции, видим, что в Windows этот код отработал полностью корректно.

Если скомпилировать эту же программу под Android результат будет тот же самый.

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

Теперь поставим задачу несколько иначе. «Текущим» представлением теперь станет то, что предназначено для Android.

В случае компиляции под Android, всё работает безупречно (см. скриншот выше). Однако, если скомпилировать тоже самое приложение под Windows, при показе формы ничего не произойдёт.

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

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

Данную особенность обработки событий необходимо обязательно учитывать при разработке кроссплатформенных приложений. Те действия, которые являются «общими» для Windows и для других платформ, следует описывать для «главного» представления формы, а, действия, которые являются специфичными, для данной конкретной платформы – для соответствующих представлений формы.

В целом FireUI привнёс ряд новых нюансов в разработку приложений с использованием RAD Studio, но в тоже время его появление решило и целый ряд проблем связанных с организацией разработки и обеспечения единой кодовой базы. Если раньше было необходимо создание отдельного проекта для Windows или Mac OS X и отдельного проекта для мобильных платформ, то сейчас весь процесс разработки можно осуществлять в рамках одного и того же проекта. Что гораздо проще и удобнее.

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