Разработка кроссплатформенных мобильных приложений в Delphi #1
Как вы, наверное, знаете, в сентябре этого года компания Embarcadero Technologies представила очередной релиз RAD Studio, набора средств разработки, включающих в себя Delphi, C++ Builder, HTML5 Builder и ряд сопутствующих продуктов. Основное новшество RAD Studio XE5 состоит в том, что с помощью Delphi стало возможным вести разработку нативных приложений для Android – самой популярной на текущий момент мобильной платформы.
Предыдущие версии Delphi уже поддерживали разработку для Mac OS (XE2, XE3, XE4) и для iOS (XE4). Поэтому сейчас мы не говорим о том, что кроссплатформенная разработка стала «изюминкой» новой версии Delphi. Однако, по отношению к разработчикам приложений, Android по-настоящему демократичная система. Здесь не требуется ни дорогостоящего оборудования (как в случае с iOS), ни покупки сертификатов разработчика (возможность публиковать приложения в GooglePlay стоит всего $25, возможность отладки на своем Android устройстве абсолютно бесплатна).
Таким образом, если вы имеете некоторые навыки работы в Delphi, то именно сейчас у вас появилась прекрасная возможность попробовать себя в мобильной разработке.
Говоря о Delphi, следует упомянуть и C++ Builder. Обычно оба эти продукта развиваются параллельно. Однако, на этот раз Delphi, выражаясь спортивным языком, «немного вырвался вперед» и пользователям C++ Builder приходится некоторое время ожидать пока их средство разработки «подтянется к лидеру».
Многие Delphi разработчики со стажем ассоциируют Delphi с VCL – мощной расширяемой библиотекой классов, предназначенных для создания широчайшего спектра приложений для Windows. Однако, как вы знаете, или успели догадаться, для создания кроссплатформенных приложений используется не VCL, а платформа приложений FM, ранее известная как FireMonkey.
С точки зрения IDE FM, это, прежде всего, новая библиотека визуальных классов (элементов управления). С ее помощью можно создавать качественные пользовательские интерфейсы практически для любых видов программ. При этом среди прочего «в коробке» поставляются также и объекты для работы с 3D графикой, что позволяет задействовать FM для решения целого ряда специфических задач, таких как моделирование физических процессов, создание наглядных учебных пособий и т.д. Многие из компонентов, представленных в FM, имеют свои VCL аналоги. Однако, далеко не все.
В отличие от VCL, FM является «абстрактной» прикладной платформой. Ранее визуальные библиотеки классов обрабатывали соответствующие элементы операционной системы. В VCL, например, компонент «TButton» является оболочкой элемента управления Windows Button (кнопка). Вместо этого, в FireMonkey появилось абстрактное понятие кнопки, к которой могут применяться различные стили, для того чтобы она выглядела нативной под различными платформами, или использовала полностью настраиваемый стиль пользовательского интерфейса.
В то время, как другие библиотеки абстрагируют пользовательский интерфейс, FM привязывается непосредственно к нативной графической библиотеке, предлагая наилучшее решение с точки зрения использования GPU на целевой платформе.
Еще один момент, который следует затронуть, это сам термин «кроссплатформенность» в контексте мобильных приложений. Совершенно очевидно, что мобильные платформы используют специфичный набор элементов управления для организации пользовательского интерфейса. И по этой причине принципы построения классических настольных приложений в большинстве случаев не применимы в мобильной разработке.
Конечно, описанный выше принцип абстрагирования интерфейса во многих случаях решает проблему. Однако, далеко не всегда. И, говоря о кроссплатформенном приложении, мы не подразумеваем единое приложение для различных платформ. Мы говорим о единой кодовой базе в разных приложениях. И здесь очень важным становится правильное построение архитектуры приложения, а именно, максимальное разделение интерфейсной и логической части.
На сегодняшний день платформа FM поддерживает следующие операционные системы: Windows (Win32 и Win64), OSX, iOS и Android.
Для разработки мобильных приложений (для iOS и Android) в Delphi используется так называемый модульный компилятор LLVM. В контексте кроссплатформенной разработки это дает неоспоримое преимущество. Модульный компилятор разделен на две части: front-end и back-end. Front-end компилятора переводит исходный код программы конкретной в универсальный платформонезависимый виртуальный код (байт-код). Back-end обрабатывает полученный байт-код и преобразовывает его непосредственно в машинный код конкретной платформы. Back-end LLVM поддерживает целый ряд различных платформ, что в будущем даст возможность RAD Studio расширить список поддерживаемых платформ.
В контексте разработки бизнес-приложений так же следует упомянуть и о механизмах доступа к базам данных. Действительно, работа с БД всегда была сильной стороной Delphi, и вполне логично было бы ожидать, что мобильные Delphi приложения будут работать с базами так же хорошо, как и настольные.
Совсем недавно, весной этого года, комплект поставки старших редакций Delphi/RAD Studio пополнился новой библиотекой доступа к данным – FireDAC, созданной на базе хорошо известного решения AnyDAC, созданного и долгое время развиваемого Дмитрием Арефьевым. FireDAC является универсальным набором компонентов, поддерживающим доступ к весьма внушительному списку СУБД. И если мы говорим о настольных приложениях, то платформа FM с помощью FireDAC поддерживает практически все популярные СУБД. Что же касается мобильных приложений, то здесь существуют определенные ограничения, связанные, прежде всего, с отсутствием библиотек доступа к большинству СУБД. Так мобильные Delphi приложения будут поддерживать SQLite (родная СУБД как для iOS, так и для Android) и IBLite/IB ToGo. Но напрямую подключиться, например, к Oracle уже не получится. 
Тем не менее, существует возможность создания мобильных клиентов с помощью многозвенной технологии DataSnap. Эта технология не нова и довольно хорошо себя зарекомендовала среди разработчиков.
И, коль скоро мы затронули тему работы с базами данных, следует упомянуть об одном из ключевых отличий FM и VCL приложений. Для отображения данных в VCL обычно используются специальные элементы управления, так называемые DB-контролы. Для FM такие элементы управления не реализованы и для отображения данных используются обычные элементы управления. Связь между данными и элементами управления производится при помощи механизма Live Binding. И хотя Live Binding интуитивно понятен, прост в изучении и полностью визуализирован, работа с этой технологией все же требует некоторых навыков. 
Из всего вышесказанного следует, что мобильная разработка в Delphi довольно существенно отличается от «классической». И сейчас имеется некоторый дефицит технической информации, посвященной именно мобильной разработке в Delphi
Хотя подобная ситуация, в принципе, характерна для любой интенсивно развивающейся технологии.
Данная статья открывает цикл публикаций, посвященных созданию мобильных приложений в Delphi. Мы надеемся, что этот цикл поможет вам не только познакомиться с возможностями новой среды разработки, но и разобраться с основными техническими вопросами, которые могут вызвать сложность.
В следующей части мы перейдем от слов к делу. Для рассмотрения будет выбрана абсолютно реальная задача, и мы попытаемся пошагово рассмотреть процесс создания FM приложений для разных платформ.
Источник
Разработка кроссплатформенных мобильных приложений в Delphi #3
Часть #1
Часть #2
Настройка среды и создание нового мобильного приложения.
В предыдущей части цикла мы определились с задачей и создали простейшее FM приложение, которое отображает список рецептов. При этом мы использовали библиотеку доступа к данным FireDAC и технологию связывания объектов LiveBinding. Также мы условились, что в рамках поставленной задачи будет создано два приложения, использующих единую кодовую базу. И теперь, настало время для, возможно, самой интересной части – создания первого Android приложения.
Прежде всего, необходимо произвести настройку среды. Если при установке RAD Studio вы не устанавливали инструменты разработки Android (JDK/SDK/NDK), то вам следует сделать это вручную. Так же необходимо установить USB драйвер для того Android устройства, с помощью которого будет производиться разработка приложения. Стоит отметить, что далеко не для всех Android устройств можно найти USB драйвер. В таком случае можно воспользоваться возможностью отладки через Wi-Fi.
При создании нового проекта нам предлагается воспользоваться одним из нескольких шаблонов мобильного приложения. Выберем шаблон Header/Footer, представляющий собой мобильную форму с двумя панелями инструментов (Toolbar). После выбора шаблона необходимо сохранить проект. Новый проект удобнее всего создавать с помощью Project Manafer (правая верхняя панель IDE), как это показано на рисунке. Таким образом, мы сможем работать сразу с двумя проектами в группе.
Главная форма приложения для выбранного нами шаблона по умолчанию адаптирована под устройство Google Nexus 4. С помощью выпадающего списка в правой верхней части дизайнера формы можно выбрать другое устройство. Для нашего приложения выберем одно из наиболее популярных планшетных устройств Google Nexus 7. Сразу же изменим и текст заголовка на главной форме (свойство Text компонента HeaderLabel).
Первый запуск приложения
Как вы уже поняли, для отладки приложения мы будем использовать физическое устройство, подключенное по USB. Хотя возможны и другие варианты (подключение с помощью Wi-Fi или использование эмулятора). Если вы подключили свой планшет или телефон в соответствии с инструкцией и активировали режим разработчика, то название вашего «девайса» появится в списке целевых устройств (Targets). Активируем его.
Еще раз убедитесь в том, что Android SDK настроен для вашего устройства, а т. н. «режим разработчика» активирован. Подробно весь процесс настройки среды для разработки Android приложения описан здесь.
Запускается мобильное приложение точно так же, как и обычное «настольное» (нажатием клавиши F9). Если вы все сделали правильно, то после компиляции вы увидите главную форму приложения на своем планшете.
Теперь попробуем реализовать тот же функционал, который мы реализовали в предыдущей части. Для этого добавим в текущий проект уже существующий модуль данных из предыдущего проекта (меню Project | Add to Project…). Как и в первом проекте, модуль надо включить в секцию Uses главной формы.
Собственно, теперь нам ничего не мешает использовать ту же процедуру установки соединения, которую мы использовали в «настольном» приложении:
Таким образом, мы избавили себя от необходимости повторно писать код установки соединения.
Главная форма приложения
В принципе, разработка пользовательского интерфейса мобильного приложения это отдельная, весьма обширная тема. Зачастую, именно неправильно спроектированный GUI может стать причиной неудачи. И иногда программисты пытаются перенести свой опыт создания интерфейсов «настольных» приложений на мобильную разработку. Это не совсем правильно. Перед тем, как приступить к написанию мобильного приложения стоит внимательно изучить базовые принципы дизайна интерфейсов. И, конечно же, стоит изучить интерфейсы популярных программ.
В нашем случае мы вполне можем организовать интерфейс главной формы мобильного приложения по образу «настольного» (на самом деле, интерфейс Windows приложения мы строили с учетом того, что нам придется делать мобильное приложение). Поместим на форму компоненты TPanel, TSplitter и TCalloutPanel. В Object Inspector поменяем их свойства следующим образом:
Для отображения списка рецептов мы точно также используем TListBox и TBindNavigator, которые расположим на левой панели. TTabControl расположим на компоненте TCalloutPanel и настроим для каждого из компонентов свойство Align.
Как и в прошлый раз, используем механизм LiveBinding для подключения набора данных. Данная процедура полностью аналогична той, которую мы проделали в предыдущей части, создавая «настольное приложение».
Как и в прошлый раз, нам потребуется создать некий инструмент для ввода названия рецепта. Если в настольном приложении мы могли использовать модальную форму, то концепция мобильных приложений в большинстве случаев предлагает другое решение, более мягко регламентирующее действие пользователя. Однако здесь мы используем «диалог», который по сути можно расценивать как разновидность модальной формы.
Создадим новую мобильную форму. На ней поместим панель, и уже на панели разместим те элементы управления, которые мы размещали на форме добавления рецепта в прошлый раз (TEdit и две кнопки). Значение свойства Align – alCenter. Для кнопок зададим значение свойства ModalResult (mrOk и mrCancel).
Для класса формы создадим следующий метод класса:
При запуске приложения назначим данный метод в качестве обработчика события AfterInsert для единственного пока набора данных в программе.
Данная форма будет вызываться при каждом добавлении записи в набор данных FDTRecipe.
Естественно, такой код нуждается в оптимизации. Создавать экземпляр формы при запуске приложения — не лучшая идея. Особенно для мобильных приложений. Но это тема для отдельного разговора, а пока из соображений наглядности оставим все как есть.
Развертывание (deployment) Android приложения
Перед тем, как запустить приложение, работающее с БД на Android, следует сделать определенные настройки, которые позволят перенести базу данных на мобильное устройство, и дадут возможность приложению «увидеть» базу. Для этого следует использовать Deployment Manager (меню Project |Deployment).
Убедитесь, что выбрана отладочная конфигурация для платформы Android. В выпадающем списке на верхней панели инструментов должно быть выбрано значение Debug configuration – Android platform.
Для того, что бы при развертывании приложения на устройство переносилась и база данных, следует воспользоваться кнопкой «Add files» (добавить файлы) и выбрать файл базы данных.
Введите assets\ в качестве значения поля Remote Path, а значение поля Platform установите Android. Директория assets это специальная директория, предназначенная для хранения вспомогательных ресурсов приложения. В поле Platform следует выбрать Android.
Вы можете нажать кнопку Deploy, что бы протестировать процесс развертывания приложения.
И, наконец, для того, что бы приложение заработало, следует сделать еще один важный шаг – определить событие компонента FDConnection1 следующим образом:
Директива компилятора <$IFDEF ANDROID>передается для того, что бы данный код выполнялся только на Android устройствах. Таким образом, мы указываем приложению относительный путь к БД.
Запускаем приложение, и на экране устройства получаем практически полный аналог Windows приложения, которое мы создали в предыдущей части.
В этой части мы построили первое мобильное приложение и разобрались с тем, насколько процесс создания мобильных приложений в Delphi схож и насколько он отличается от процесса создания «обычного» desktop приложения. Естественно, пока мы реализовали только базовый функционал. Это касается как логики программы, так и ее интерфейса. Но, всему свое время. В следующей части мы продолжим работу над Windows приложением и более углубленно познакомимся с возможностями и принципами работы механизма LiveBinding.
Источник
