- Delphi. FireMonkey. Первое приложение под Android – “Позвони маме”
- Настраиваем Delphi для работы с FireMonkey – Android
- Marco Tech Blog
- From Delphi to Android
- Alternative Android Development Options
- Delphi Language Tools for Android
- Delphi XE5 + Android: первые впечатления
- Возвращение к истокам
- Базы данных
- Манипуляции с формами
- Массивы
- Операторы
Delphi. FireMonkey. Первое приложение под Android – “Позвони маме”
В Delphi, насколько я вижу, под Android можно писать на Firemonkey – и тогда мы получим нативное приложение. А можно писать при помощи UniGUI фрэймворка и тогда мы получим приложение работающее через браузер, основанное на популярной библиотеке jQueryMobile.
Плюс первого подхода (приложения на FireMonkey), насколько я понимаю в скорости, производительности программы, а также в том, что есть доступ к железу (вспышка, датчики и др.), минус в том, что такое приложение запустится не на всех устройствах, насколько я вижу по информации с форумов. Но на большинстве.
Ещё один плюс – приложение может быть полностью автономным, не зависящим от сети. Если, скажем использовать базу данных SQLite для каких то небольших приложений.
Также лично для меня, человека работающего с mySQL есть ещё один финт в работе с FireMonkey – напрямую, я оказывается не могу подключиться, в связи с ограничениями в FireDAC – библиотекой доступа к данным, выход – либо переход на другие компоненты либо через DataSnap.
Плюс второго подхода (приложения на UniGUI) состоит в том, что такое приложение будет работать практически везде, где есть браузер и интернет. На айфонах, айпадах, планшетах и так далее. Наверное, это даже удобнее, нежели 100 приложений под разные платформы. То есть, мы выходим за рамки конкретной платформы. Само приложение будет работать через сеть.
Минус этого подхода в том, что у нас практически нет доступа к железу. Но если этого не требуется, а для большинства задач этого достаточно – то всё в порядке. Также хорошо то, что вся мощь javascript библиотек будет под рукой и её можно будет использовать как напрямую, так и через язык Delphi. Другое ограничение – постоянный доступ к сети, но с этим проблем вроде бы нет в современном мире.
Есть ещё и третий подход)) Соединить первый и второй подходы – а именно – завернуть UniGUI приложение в FireMonkey. То есть, если, скажем нам нужно разместить наше приложение в магазине PlayMarket – мы просто берем TWebBrowser и прописываем в нём ссылку на наше приложение на UniGUI в сети.
Настраиваем Delphi для работы с FireMonkey – Android
Об этом много и хорошо написано на сайте Влада. За что ему огромное спасибо. Для меня это был стартовый импульс. Не всё, конечно, прошло гладко. Но, тем не менее, результат достигнут за приемлемое время.
Я, в частности, столкнулся вот с такой ошибкой…
Источник
Marco Tech Blog 
From Delphi to Android
Android is bigger and bigger every day. What does this mean for Delphi programmers, how can you move knowledge and code? How can you program in Object Pascal for Android? An overview of the current options in a rapidly moving area.
Android is bigger and bigger every day. What does this mean for Delphi programmers, how can you move knowledge and code? How can you program in Object Pascal for Android? An overview of the current options in a rapidly moving area.
It is about a month since I first considered writing a post on this topic, but given this is a rapidly evolving area I’m sure this is a better timing. having just seen two / three articles on specific technologies, I think it is time to get this moving. Let me first add a couple of personal considerations:
- I think Android is big and will grow a lot. I’ve been using an Android phone for over an year, and I like it. Won’t trade it for an iPhone or Lumia. I own an iPad, find it much more interesting than I anticipated (this is worth another post), but Kindle Fire, the coming GPad (Google iPad Clone), and more options will open this area to Android as well.
- I think development tools for mobile are still in their initial stage and will grow, landscape will change.
- I’m not generally terribly fond of code converters (sorry for those building similar tools, but I’m negatively biased).
Having said this which are the real and practical options for Delphi developers who want to build Android applications? These are the options I’ve noticed, let me know if I miss any, and if I missed any key information (feel free also to add more details, here I’m trying to provide summaries).
Alternative Android Development Options
Before we look to the available Delphi-oriented tools, let me try to summarize the options for building Android applications:
- Writing Java applications for the Delvik virtual machine, generally using Eclipse and the Android SDK and plug-ins. This is the standard and mainstream appraoch.
- Writing HTML + JavaScript Web applications optimized for the device, maybe using a library like jQuery Mobile. You can simply point users to URLs, or embed the page in a true Android Web App, and even interact with the device using a library like PhoneGAP. What’s interesting in this model is that you can use the same application also on iOS.
- Write native applications using the NDK, generally in C or C++.
Delphi Language Tools for Android
It is interesting to notice that different tools that bring the Delphi language (or Object Pascal) to Android follow each of the three models above. Here is a summary:
- Oxygene for Java, by RemObjects, is a tool for writing Delphi-like code (or more Delphi Prism-like code) in Visual Studio converting it to Java for Android. Has a nice way to let you refer to any existing Java library, more or less like Prism does with .NET libraries. Read more at http://www.remobjects.com/oxygene/java.aspx and Brian Long’s article at http://blong.com/Articles/OxygeneForJavaIntro/OxygeneForAndroid.htm. With this tool you create Java applications.
- SmartMobileStudio (formerly OP4JS) is a tool to convert Delphi code to JavaScript and create web applications. Official site is at http://www.op4js.com/. Primoz has a nice article at http://www.thedelphigeek.com/2012/01/first-steps-with-smart-mobile-studio.html. I tend to disagree on the main rationale (JavaScript is low level / not good / too complex / etc), but still this tool might get you to code faster. With this tool you create Web apps.
- Use FPC (Free Pascal Compiler) to build native apps, as detailed by Uwe at http://www.bitcommander.de/blog/index.php/2011/12/19/fpc-android-boot/. After all, if Embarcadero is using FPC for iOS, it could also be good for Android. Still quite an early version, but interesting. And native.
- UseDelphi DataSnap REST engine with a proper library to build Web Apps, like I did and documented on this blog at http://blog.marcocantu.com/blog/mobile_jquery_delphi_rest.html and http://blog.marcocantu.com/blog/web_andoird_app_delphi_datasnap.html. Yes, you need to write some JavaScrip, but can also use Delphi to generate some, as I do in my Relax Framework. You can probably use the JavaScript REST proxy also from SmartMobileStudio, but I’m not sure about this.
- Use Eclipse. and Delphi’s Mobile Connectors for DataSnap. You can still write the core code and the database access code in Delphi, and code the UI in native Android Java. Or possibly use Oxygene for the front end, and Delphi for the backend. Or other server plus client solutions. Bittime has written a «Connect Four» app with this model, see https://market.android.com/details?id=com.bittime.connectfour&hl=en.
- Wait. for a future Delphi for Android, and learn FireMonkey for now, as it seems likely the future, rumored, unofficially promised Delphi for Android will have the same user interface of the current Delphi / FPC for iOS, ties to OpenGL. At the 24 hours of Delphi, JT and DavidI promised a webinar for presenting the new roadmap in early 2012. so I’m waiting. Will this be a native / NDK solution?
Again, there might be more options and alternatives, particularly in the Web App arena, but this offers you some alternatives. to get to Android or get ready for it. Awaiting your comments (better on the blog than on Facebook, but anything goes).
Источник
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) в мобильном компиляторе нумеруются с нуля.
Операторы
Появился (уж не знаю в какой версии) новый оператор
Похоже, все языки стремятся к общему знаменателю. Кстати, перебирать им в паскале можно не только массивы, но и множества.
Источник