Пройшло вже достатньо часу з тих пір, як термін 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.
На практиці, починаючи новий проект, я опинився перед фактом: треба звикати і до нових візуальних компонентів і до нового способу вилучення даних для відображення, редагування та, зрештою, збереження. Що, знову ж таки, не погано, і не добре. Просто для мене вийшло саме так.
На цьому хочу завершити посаду про перші враження. На черзі розповіді про те, що і як долалося під час роботи над проектом.
Пройшло більше трьох років з того моменту, як підрозділ CodeGear, який відповідає за створення таких всесвітньо відомих інструментів, як Delphi, C++Builder та JBuilder, а також СУБД Interbase, став частиною компанії Embarcadero Technologies, відомої своїми інструментами для проектування та адміністрування баз даних , і два роки - з того часу, як ми обговорювали на сторінках нашого журналу, чого очікувати в галузі розвитку інструментів, настільки популярних у російських розробників. Про те, що нового було зроблено в цій галузі за останні два роки і чого чекати найближчим часом, ми попросили розповісти Девіда Інтерсімоне, віце-президента зі зв'язків з розробниками та головного євангеліста компанії Embarcadero Technologies, та Кирила Раннева, голову представництва Embarcadero Technologies у Росії. Для наймолодших наших читачів повідомимо, що це далеко не перше інтерв'ю, яке Девід і Кирило дають Комп'ютерПрес - наша співпраця триває вже другий десяток років. І приблизно стільки ж років ми періодично публікуємо огляди інструментів для управління базами даних, у яких приділяють велику увагу продуктам компанії Embarcadero.
Комп'ютерПрес:Девіде, ваш підрозділ є частиною 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, можуть застосовувати той самий компонентний підхід, візуально редагуючи форми та здійснюючи підключення до баз даних шляхом переміщення компонента мишею. Це принципово новий спосібстворення програм, що виконуються на різних платформах, і за ним майбутнє. Якщо ви захочете додати для вашої програми підтримку інших операційних систем та платформ, не потрібно його заново проектувати та розробляти – достатньо буде просто перекомпілювати його.
Ми створюємо нові компілятори, що генерують машинний код. Сьогодні є компілятори 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-серверів. Можна створювати привабливі елементи управління, кнопки з боксами, незвичайні таблиці та інші інтерфейсні елементи, причому у дво- та тривимірному варіантах. Можна завантажити додаток готову тривимірну модель і з'єднати її з двовимірною формою, в якій її можна обертати та розглядати з різних боків. Можна створити куб з даними або тривимірну бізнес-діаграму і обертати їх за допомогою миші, клавіатури або навіть пристрою 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 може здійснюватися зі швидкістю 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 використовуються дуже широко. Вони призначені для спрощення використання програм як нашої компанії, так і інших виробників. Фактично це рішення для управління ліцензіями та застосуванням додатків, і воно зручне для великих компаній. Невеликі ж фірми, в яких немає спеціальних груп співробітників, відповідальних за управління додатками, можуть покласти додаток до репозиторію, вибрати імена користувачів з бази даних та забезпечити використання цих додатків без необхідності згадувати, де ліцензійний ключі скільки ліцензій є. 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, починаючи з першої версії, і рік тому вона перейшла з використання Delphi до набору All-Access. Два інструменти, які гарантовано застосовують у цій компанії всі розробники, - це Delphi та DBArtisan. І є замовники, які прийшли до All-Access із боку баз даних. Їхнє основне завдання - адмініструвати бази даних, але при цьому вони іноді займаються розробкою додатків. Серед клієнтів, які використовують All-Access, – медіакомпанії, машинобудівні підприємства та представники інших галузей.
Окремо хотілося б зупинитись на невеликих компаніях. Дуже часто у маленьких колективах розробник робить все, і така компанія іноді купує великі продуктові набори All-Access для одного-двох розробників. У великих колективах не заохочується, щоб розробник виконував, наприклад, ще й роль адміністратора баз даних, тому зазвичай там популярні невеликі продуктові набори, а в дрібних компаніяхтаке поєднання обов'язків цілком припустимо.
Delphi Architect - це продукт, що активно продається, що включає засоби моделювання та програмування. Число його проданих копій, щоправда, менше, ніж версії Delphi Enterprise, але воно також велике. Зауважу, що у 2010 році ми виявилися найкращою країною за обсягом продажів, при тому, що всі країни пережили кризу. Це зростання було пов'язане не стільки з економічними факторами, скільки з тим, що версія RAD Studio XE, що вийшла наприкінці 2009 року, виявилася дуже затребуваною. І поки що ми очікуємо подальшого зростання продажів.
Ми зробили ще один розумний крок, вкрай затребуваний у Росії. Ступінь легалізації різних версій наших продуктів різна: що вища версія, то більше вона легалізована, адже раніше програмне забезпеченняне так активно купувалося. Починаючи з версії 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додаток.
Кілька слів про програму. Нинішня версія Sphere позиціонується трохи по-іншому. Так, іноді так буває.
Нова SphereLiveце не просто черговий месенджер. Насамперед, це інструмент, що дозволяє ефективно організувати освітній процес. Він дозволяє проводити дистанційні лекції, приватні консультації, індивідуальні заняття та інші подібні заходи. При цьому він оснащений практично всім необхідним для роботи. Починаючи з унікальної системи передачі файлів і закінчуючи найпотужнішою підсистемою білінгу.
На цьому етапі ціни на використання товару цілком демократичні. За умови обмеженої кількості слухачів та невеликого обсягу ресурсів, продукт можна використовувати безкоштовно.
Звісно, що Сфера використовує головну перевагу FireMonkey- Кросплатформність. Зараз програма доступна в Windows і MacOS редакціях. Android версіяочікується день у день.
Тим не менш, для мене SphereLive цікава, перш за все, як інноваційний продукт з цілим набором оригінальних рішень. Іноді просто на рівні "... ух ти, як ти це зробив?" До речі, один з розробників Сфери бере активну участь в обговореннях на форумі, присвяченому FireMonkey. Саме по собі це може стати приводом скачати програму та обговорити технічні запитаннябезпосередньо з автором. Повірте, є що подивитися, є чому повчиться.
TListViewє одним з ключових компонентів для побудови інтерфейсу мобільного додатку в FireMonkey. Компонент цей не найпростіший у використанні, найчастіше передбачає значний обсяг коду, натомість надає розробнику значну свободу дій. Звичайно, у додатках можна використовувати і TListBoxде все набагато простіше. Але TListBoxможливо, хороший для відображення фіксованої кількості записів, для виведення даних з джерел даних, однозначно потрібно використовувати TListView.
Головні відмінності TListView від TListBox:
- TListBoxItem- Контроль, TListViewItem- Ні
- В TListBoxItemможна додавати будь-які контролі за допомогою Parent. В TListVIewItem- Ні.
- TListVIewItemзберігає лише дані для відображення
- TListVIewItemсам виконує відображення даних, що зберігаються через метод Render
- За рахунок власне ручного відмальовування в TListVIewItem досягається приріст швидкості та мале споживання пам'яті (зберігання лише актуальних даних)
- Щоб створити свій варіант 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 mі 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 хотілося б, щоб я хотів, щоб зробити цей проект протягом тривалого часу. Новий, коли цей проект є в попередньому державному управлінні, ми вирішили, що цей опис буде бути зацікавлений для Delphi community. У essence, this is a really large project implemented in FM. Ми говоримо про Sphere Live проект. А маленька стаття розрахована на те, що проект був оновлено в Habrahabr.ru Alexey Glyzin, chief of ' ' development department agreed to tell more about the project taking in consideration the audience of my blog.
A.B.– Alexey, в цілому, що ваш проект є?
A.G.: – The idea has not appeared at once and instantly. Після того, як 'Sphere' project our team мав бути працюючим на project where stream audio/video технології були implemented. Останнім часом ми створили наш сучасний software, який був здатний до deliver multimedia streams to an unlimited amount of users including the feedback. Але все, що потрібно, щоб розраховувати на included.
application had to comply the several requirements. Перший, максимально simplified організація з конференцій або переведення до учасників, які можуть бути невідомі. 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 organization of courses, webinar або 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] Origin = "Title" Size = 50 end об'єкт 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.
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 екзотичних продуктів, нестандартних мов програмування та дивовижних засобів розробки.
У нас ви завжди знайдете - візуальну розробку, класичні мови, "нативний" код, і нехай новими будуть цільові платформи для ваших додатків, створених тим самим перевіреним класичним способом.
Що таке 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 є "безпечним" та перспективним.
Завантаження...