Delphi XE5 + Android: первые впечатления
Возвращение к истокам
Delphi XE5 я взял в руки по случаю конкурса «Осенняя Мобилизация». Идея (и возможность) писать под Андроид не на си-шарпе или яве, а на знакомом вдоль и поперёк паскале мне определённо понравилась. Расскажу тут о своих впечатления, проблемах, которые встретились, а также развенчаю некоторые «городские легенды».
Использовал триал-версию Update-1. Теперь уже вроде второй апдейт вышел и, возможно, что-то поменялось. Сразу замечу, что менять в установке настройки по умолчанию лучше не стоит. Установленный до этого Андроид-SDK прицепить к Делфи не удалось, поэтому ставил заново с тем, который к ней прилагается. После первого запуска выяснилось, что не работает Хелп. Нашёл решение
support.embarcadero.com/article/43035
Хелп оказался толковый и довольно подробный. Содержит не только свойства и методы, но и примеры и даже описание методик разработки. В общем, возвращение к истокам, как оно было ещё у Борланда.
Cама среда мне очень нравится. В Визуал Студио всё какое-то аморфное и невнятное. Юнити визуально неплох, но там совсем другая специфика. Короче – язык программиста всё равно не опишет то, что видит глаз эстета, даже если они принадлежат одному человеку…
Интерфейс пользователя
FireMonkey порадовал своей гибкостью. На любой контрол можно повесить другой, на тот ещё один, и так далее, достигая очень интересных результатов. По сравнению с VCL стандартизовано именование свойств. Никаких больше Caption’ов и прочего, если где-то есть текст – это всегда Text. Позиция – всегда Position. Масса способов выравнивания. Кроме того, есть TLayout – нечто «невещественное» (об этом будет и ниже), невидимое, на что можно положить контролы и выравнивать их «в пустоте», а не обязательно на какой-нибудь панели.
Когда много всего на форме, становится очень полезным свойство DesignVisible – скрыть в дизайн-тайме. Набор стилей для Андроида прилагался только один, но очень элегантный – белым по чёрному, как мне нравится.
В инете ходят слухи, что ссылки на стиль для контрола (StyleLookup) иногда «не сохраняются». Для многих типов контролов (а может и для всех) существует для каждого своя ссылка «по умолчанию», которая будет назначена, даже если не указана, и которая-то и не сохраняется, как я понимаю, для экономии места в ресурсе формы.
Контролу можно добавить анимацию, и даже несколько, и даже одновременно. И это не только перемещение по экрану, но и изменение любых вещественно-численных свойств (размеров, цвета, масштаба и т.д.). Для каждой анимации можно указать временную задержку её начала, что очень удобно в сложных случаях, т.к. можно обойтись без дополнительных таймеров, просто запустив все нужные анимации одновременно из одного блока кода.
Теперь о жестах. В принципе всё просто – назначаем контролу Touch.GestureManager, галочками помечаем интересующие жесты, назначаем искусственное расширение границ ловли жестов (если контрол мелкий) в TouchTargetExpantion, создаём для него событие OnGesture и ловим там по EventInfo.GestureID нужный жест. Но есть тонкости.
Например, на большом TLayout мы разместили какие-то мелкие (относительно него) контролы и независимо от того, насколько «попал» пользователь пальцем по этим контролам своим жестом, надо что-то там делать. Замечу – если всё описанное в абзаце выше сделано для этого TLayout, то мы поймаем только те жесты, начало которых приходится на «видимые» объекты – т.е. на один из тех самых мелких контролов. Это я определил экспериментально. В принципе ничего удивительного – лайоута-то как бы и нет, он невидим и виртуален, и все «экранные сообщения», которые он может получить – от положенных на него «видимых» объектов. Можно сделать по-другому — не лениться, назначить менеджера и создать событие для формы (как и делается в демках) и гарантированно его всегда получать – но тогда придётся вручную разбираться с координатами, чтобы определить, к какому контролу какой жест относится.
Ещё именно под Андроидом я бы настоятельно порекомендовал явно проверять GestureID каждого пойманного жеста и реагировать только на те, которые интересуют (независимо от того, какие жесты помечены галочками).
И пример. Долго не мог сообразить, как показать баннер в TWebBrowser. Решение нашёл на одном форуме и творчески переработал. Но, если быть уж совсем точным, не до конца. Практикующие перфекционисты могут поразвлечься и этот недочёт поискать. Однако код при этом абсолютно рабочий и именно его я использую:
HTML тут – это код этого самого банера.
Базы данных
В XE5 включён набор компонентов для универсального доступа к базам данных – FireDAC. В принципе все названия свойств и методов как у других аналогичных наборов, так что тут всё ясно. Я использовал его для общения с SQLite. Всё настолько просто и обычно, что даже не знаю, что рассказать. К тому же и не помню ничего – в это время смотрел что-то по медиаплейеру, руки сами всё сделали.
Чтобы почувствовать разницу, желающие могут для сравнения после FireDAC сделать что-нибудь с базой данных из программы на той же Юнити. Да ладно Юнити, она игровая, – вон из той же Визуал Студии. После этого начинаешь понимать, где пули свистят, а где туземки коктейли разносят…
Ну и для любителей делать всё своими руками приведу небольшой пример, как заполнять ListBox без Bindings:
Кроме всего прочего, в зависимости от кода в столбце d_result в строчку лист-бокса помещается та или иная картинка:
Главное, что тут не забыть – это aList.AddObject(aItem);
Ну и Next, конечно, чтобы не зависло.
Манипуляции с формами
То, к чему приучает Делфи – это каждому действию свою форму. Под Андроидом в ней можно точно так же, как и под Виндоуз, создавать, показывать и закрывать формы. Каждая новая так или иначе созданная и показанная форма будет как бы «модальной», т.е. закрывающей всё пространство приложения. Однако Form.ShowModal делать не следует (Андроид этого «не понимает»), а следует по старинке просто вызывать Form.Show. По системной кнопке Back автоматом вызывается Form.Close и самая верхняя на данный момент форма закрывается. Можно её потом опять использовать. При закрытии главной (первой) формы приложение, как и следовало ожидать, закрывается. Замечу, что не следует закрывать форму с параметром caFree либо явно её уничтожать (Free, Release) – не любит Андроид этого!
Читал в инете про проблемы у людей с ARC. Уверен, дело не в этом. Если всё правильно спроектировано, то вообще без разницы, считаются ссылки или нет, ходит там сборщик мусора с косой по расписанию как в .Net или уничтожается сразу как в Delphi. Я всё писал по-старинке:
и работало как часы и под Андроидом, и под Виндами.
Если же возникают какие-либо проблемы с пониманием этого процесса, без всякого стёба рекомендую немного пописать на си-шарпе. Там вообще деструкторы явно вызывать не принято, просто или выходишь из процедуры, где данный объект был локальной переменной, или присваиваешь (глобальной) переменной значение null. Через некоторое время уже спинным мозгом начинаешь чувствовать момент, когда ладьи с объектами отправляются в Вальгаллу, причём безо всякого с твоей стороны толчка.
Массивы
При разработке под мобильный компилятор в руководстве по адаптации кода сказано «не использовать статические массивы». Указано также одно исключение – когда статический массив является членом структуры. И всё. Не совсем ясно, относится ли это к константам-массивам. Например, таким как
Не исключено, что так делать можно, хотя я такого старался избегать и формировал массивы строк в initialization динамически. В си-шарпе там хоть это можно в описании делать… Короче, вопрос требует дальнейшего исследования и разъяснения.
Следует также помнить, что элементы строки (string) в мобильном компиляторе нумеруются с нуля.
Операторы
Появился (уж не знаю в какой версии) новый оператор
Похоже, все языки стремятся к общему знаменателю. Кстати, перебирать им в паскале можно не только массивы, но и множества.
Источник
Разработка кроссплатформенных мобильных приложений в Delphi #2
В предыдущей части цикла мы сделали обзор основных возможностей новой RAD Studio XE5. Сегодня же перейдем к практике. Прежде всего, давайте определимся с задачей.
Постановка задачи
Не смотря на некоторую академичность задачи, в качестве примера мы выбрали кулинарную книгу. А для придания оригинальности разрабатываемому приложению, попытаемся расширить обычный для подобных программ функционал несколькими дополнительными функциями:
Пересчет количества требуемых продуктов.
Обычно в рецептах указывается точное количество используемых продуктов. Но если требуется изменить количество порций, то соответственно, необходимо пересчитывать и количество продуктов. В процессе приготовления блюда это не всегда удобно.
Таймер.
Если вы новичок в кулинарии, то, вам следует использовать рецепты, в которых четко указано время той или иной операции. И таймер на планшете, телефоне или нетбуке вполне может стать удобной заменой кухонному таймеру.
Часто бывает, что несколько операций выполняются параллельно. Каждая операция может иметь свой «таймер».
При этом нас интересует, как «настольная», так и мобильная реализация приложения. Мобильное приложение будет использоваться в качестве пособия для визуализации рецепта и сопровождения процесса подготовки. Настольная версия может быть использована в более расширенном функционале для, например, формирования новых рецептов.
Здесь следует оговориться, что в принципе, поваренные книги, как и книги по программированию, могут быть рассчитаны на разный уровень подготовленности читателей. В нашем случае речь идет о «рецептах для чайников», т. е. тех, в которых указывается точное количество продуктов и точное время того или иного действия.
Данное приложение мы реализуем для Windows и для Android. Затем на основе единой базы исходных кодов мы сможем выполнить портирование приложения на MacOS и iOS.
Выбор средств разработки
Прежде чем приступить непосредственно к разработке, давайте определимся с инструментарием. Разумеется, что данные, которые будут использоваться в приложении, целесообразнее всего хранить в базе данных.
Для чистоты эксперимента в качестве СУБД используем SQLite. Эта СУБД обладает рядом преимуществ, среди которых скорость работы, простота использования, экономичность в отношении ресурсов. Она идеально подходит для решения несложных задач, а кроме того, Android имеет встроенную поддержку SQLite.
В дальнейшем мы рассмотрим, каким образом можно перевести приложение на использования СУБД InterBase и покажем все преимущества «родного» решения от Embarcadero.
Вместе с приложением мы будем распространять уже готовую СУБД, созданную отдельно. Такой подход обусловлен спецификой задачи.
Конечно же, нам понадобиться Delphi XE5. Для создания Windows приложения в принципе мы могли бы ограничиться Professional редакциях. Но для т.н. мобильной разработки нам понадобиться как минимум Enterprise редакция продукта. В качестве альтернативы можно воспользоваться пакетом Mobile Add-On Pack for Delphi XE5 Professional.
Для работы с SQLite в Windows нам понадобится скачать с официального сайта библиотеку sqlite-dll-win32-x86-3080100.zip. Проще всего поместить данную библиотеку в одну из системных папок (например, Windows/SYSTEM32).
В настоящий момент существует довольно большое количество бесплатных средств администрирования баз данных SQLite. Вы вполне можете воспользоваться одним из них.
Доступ к базе данных из приложения мы будем осуществлять с помощью библиотеки FireDAC.
FireDAC — это универсальная библиотека доступа к данным, предназначенная для разработки приложений, подключаемых к различным базам данных. С помощью FireDAC можно разрабатывать, как VCL, так и FireMonkey приложения. Библиотека поддерживает следующие СУБД: InterBase, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, DB2, SQL Anywhere, Advantage DB, Firebird, Access, Informix. Однако, на данном этапе, в мобильных приложениях «напрямую» (без использования технологии DataSnap) с помощью FireDAC можно подключиться только к SQLite и InterBase.
Создание базы данных
Процесс разработки мы начнем с создания структуры базы данных. Логическая модель ее приведена на диаграмме.
Данная диаграмма получена с помощью еще одного инструмента от компании Embarcadero Technologies — ER/Studio. Developer редакция этого продукта доступна пользователям RAD Studio Architect. В рамках настоящей публикации мы не станем детально останавливаться на описании ER/Studio. Этот мощный инструмент вполне заслуживает того, что бы посвятить ему отдельный материал.
При создании структуры базы данных каждой сущности логической модели будет соответствовать физическая таблица. Вкратце рассмотрим назначение полученных таблиц.
В таблице tblFoodstuff мы будем хранить список всех возможных продуктов. В таблице tblUnit – список единиц измерения (грамм, ложка, стакан и т.д.). Таблица tblRecipe содержит список рецептов. В таблицах tblIngredientes и tblAction содержатся перечень ингредиентов (с указанием количества в поле qty) и действий (с указанием времени и описаниями), соответственно.
Для создания SQLite базы вы можете просто воспользоваться приведенным ниже скриптом.
Создание Windows приложения
Непосредственно процесс разработки приложения мы организуем следующим образом. Начнем с создания базовой версии приложения для Windows, затем портируем его на платформу Android. Далее будем расширять функционал обоих приложений параллельно. MacOS и iOS версии приложения станут заключительным этапом. К их созданию мы приступим после того, как будем иметь готовую Windows и Android версию.
IDE Delphi предоставляет несколько шаблонов новых приложений. В данном случае нас интересует FireMonkey Desktop Application.
После выбора соответствующего пункта меню на экран будет выведен дополнительный диалог, в котором будет предложено выбрать тип нового FireMonkey приложения – HD (High Definition) или 3D.
Переименуем главную форму приложения (в инспекторе объектов меняем свойство Name) и сохраним вновь созданный проект. Добавим в проект новый Data Module (меню File| Other ветка Delphi Files), переименуем и сохраним его.
Таким образом, мы создали новый проект и подготовились непосредственно к разработке.
Настройка FireDAC соединения
habrahabr.ru/topic/edit/200490/#
Первое, что нам необходимо сделать – настроить подключение к базе данных. В FireMonkey данная процедура существенно не отличается от VCL.
Поместим в DataModule компоненты TFDConnection, TFDGUIxWaitCursor и TFDPhysSQLiteDriverLink. В Object Inspector изменим значение свойства LoginPrompt компонента TFDConnection:
Двойной щелчок по компоненту на форме вызовет диалог настройки подключения.
В качестве Driver ID в нашем случае следует указать SQLite, а также в качестве значения параметра Database указать путь к файлу базы данных. Проверить правильность настроек можно с помощью кнопки Test.
Сразу же создадим функцию, отвечающую за подключение к БД в Run Time.
Для того, что бы данную функцию можно было вызвать из главного модуля, вынесем ее заголовок в секцию public.
Главная форма приложения
На главную форму приложения последовательно поместим компоненты TGroupBox, TTabControl и TSplitter. Настроим для каждого из них свойство Align (alLeft, alLeft и alClient, соответственно). На левую панель помещаем два компонента – TListBox и TBindNavigator. Размещаем их как показано на рисунке. Двойным щелчком мыши вызовем дизайнер пунктов компонента TTabControl, и создадим два пункта.
В левом части нашего приложения будет отображаться список рецептов. На вкладках в правой части – список ингредиентов блюда (с указанием количества) и, непосредственно, сам рецепт, состоящий из определенного списка действий.
Подключение данных
Как мы уже говорили, в FireMonkey нет специальных компонентов отображения данных. Вместо этого используется механизм связывания LiveBinding. Давайте посмотрим, как он работает. Подключим список рецептов к компоненту TListBox на главной форме. Прежде всего, нужно создать набор данных для работы со списком рецептов. В модуле данных используем компонент TFDTable. Настроим его свойства следующим образом:
В код нашей функции ConnectToDB добавим вызов метода открытия набора данных.
Для того, что бы установить соединение с базой в режиме Run Time следует добавить вызов функции ConnectToDB. Можно привязать его к событию OnCreate модуля данных.
На начальном этапе разработки приложения мы не будем обрабатывать исключения, которые могут возникнуть при подключении, хотя в дальнейшем это необходимо будет сделать.
Организуем вывод данных из таблицы TRecipe в список на главной форме. Для этого, прежде всего, добавим модуль данных в секцию Uses модуля главной формы программы.
В редакторе формы вызовем контекстное меню и выберем пункт Bind Visually. В нижней части экрана откроется LiveBinding Designer. В нем в виде элементов диаграммы представлены объекты и их основные свойства. Простым перетаскиванием свяжем свойства трех объектов так, как это показано на рисунке.
Собственно, это все, что нужно для отображения данных из таблицы рецептов (т.е. списка названий рецептов). Если мы сейчас запустим программу, она покажет список, но он будет пустым, и нам следует позаботиться о том, как добавлять рецепты.
Создадим новую FireMonkey HD форму. Настроим ее свойства следующим образом:
Name = fAddRecipe
BorderStyle = bsToolWindow
Position = poMainFormCenter
Подключим модуль данных и поместим на форме компонент TEdit и две кнопки. В LiveBinding Designer свяжем свойство Text компонента TEdit с полем Title набора данных.
Сохраним новую форум и удалим ее из списка автоматически создаваемых форм (меню Project|Options вкладка Forms).
Для главной формы приложения создадим метод:
При запуске программы определим событие AfterInsert для набора данных с рецептами.
Теперь, запустив приложение, мы получим список рецептов, который можно модифицировать с помощью навигатора. При добавлении нового рецепта на экране появляется форма с полем ввода.
В этой части цикла мы создали простейшее FireMonkey приложение для Windows. Научились устанавливать соединение с базой данных при помощи пакета FireDAC и рассмотрели простейший пример использования LiveBinding.
В следующей, возможно самой интересной, части цикла мы создадим первое Android приложение.
Источник
