3.6.2013 12:46

Hodně jsem trpěl kvůli chybějící součásti prohlížeče ve FireMonkey. Slavný projekt Delphi Chromium Embedded zahrnoval podporu FMX v nejnovějším sestavení. Ale i přes to, že uplynulo poměrně dost času, autor s přidáním podpory FMX2 nijak nespěchá. Nakonec jsem to musel vzít do svých rukou.

Komponenta TChromiumFMX z oficiální sestavy funguje ve FireMonkey (v XE2) docela dobře, ale ve FMX2 se ani nezkompiluje. Musel jsem trochu přijít na to, jak to funguje a opravit to. Naštěstí nebyly potřeba žádné zásadní změny.

Ve FMX2 se změnily dvě věci, které komponenta potřebuje.

Za prvé, TBitmap již nemá vlastnosti ScanLine a StartLine. Přímý přístup k obsahu TBitmap byl přepracován (zajímalo by mě proč?) a je nyní dostupný prostřednictvím třídy TBitmapData, která vrací metodu TBitmap.Map.

No, druhá, známější - Platform .* již neexistuje, nyní musíte získat požadované rozhraní prostřednictvím TPlatformServices.GetPlatformService . Všechno je zde docela jednoduché a neexistují žádné problémy.

Netestoval jsem to se zvláštní vynalézavostí, ale komponenta je pro mé účely docela vhodná - můžete přes ni prohlížet stránky. Stáhnout to. Přesto možná pošlu své úpravy autorovi, možná bude považovat za nutné je přidat do oficiální verze.

30.07.2012 2:43

Jason Southwell navrhuje vyvinout sadu obalů FireMonkey pro nativní ovládací prvky Windows/OSX a získává na to peníze. Pro začátek plánuje vybrat 20 000 dolarů.

Myšlenka je jasná. Stávající komponenty FireMonkey jsou vykreslovány pomocí nástrojů Delphi téměř od nuly, což na jednu stranu z velké části zajišťuje jejich multiplatformnost, na druhou stranu však ve výsledku získáme komponenty, které v obou aktuálně podporovaných operačních systémech nevypadají zcela přirozeně. systémy. A to není tak špatné - kromě vzhledu musíte samostatně rozvíjet logiku těchto komponent. Například RichEdit je poměrně komplikovaný a opakování jeho logiky v rámci FireMonkey není triviální úkol. VCL i CLX nevynalezli kola, ale používali již hotová.

A teď ta špatná zpráva. Vše funguje za běhu, ale nenašel jsem žádný způsob, jak přidat svůj nový typ karty do Návrháře položek. A zdá se, že všechny ovládací prvky seznamu mají stejný problém: TListBox, TGrid atd. Zpočátku se mi velmi líbil přístup k jejich realizaci, ale teď už o tom i tak nějak pochybuji. Vyhledávání na internetu odhalilo, že s tímto problémem nejsem sám.

Nápověda je tichá, v kódu jsem také nic nenašel. Opravdu v žádném případě? To by bylo velmi nepříjemné.

Uplynuly více než tři roky od doby, kdy se divize CodeGear zodpovědná za vytváření světově proslulých nástrojů, jako jsou Delphi, C++Builder a JBuilder, stejně jako Interbase DBMS, stala součástí Embarcadero Technologies, společnosti známé svým návrhem a správou databází. tools. , a dva roky poté, co jsme na stránkách našeho magazínu diskutovali o tom, co očekávat při vývoji nástrojů, které jsou mezi ruskými vývojáři tak oblíbené. Zeptali jsme se Davida Intersimoneho, viceprezidenta pro vztahy s vývojáři a hlavního evangelisty Embarcadero Technologies, a Kirilla Ranneva, vedoucího zastoupení Embarcadero Technologies v Rusku. Pro naše nejmenší čtenáře informujeme, že to není zdaleka první rozhovor, který David a Kirill poskytli ComputerPress – naše spolupráce trvá již druhou dekádu. A zhruba stejný počet let pravidelně publikujeme recenze nástrojů pro správu databází, ve kterých je věnována velká pozornost produktům Embarcadero.

ComputerPress: Davide, vaše divize je již tři roky součástí Embarcadera. Před dvěma lety jste byl plný nadšení z toho, že se stal součástí cíleně i duchem vám blízké společnosti. Změnilo se za tu dobu něco? Cítíte vy i vaši kolegové stejné nadšení?

Ano, jsem stále nadšený. Hlavní změnou, ke které došlo od doby, kdy jsme se stali součástí společnosti Embarcadero, je to, že se do vývoje Delphi hodně investovalo. Zvýšil se počet zaměstnanců pracujících na vývojových nástrojích, zvýšil se počet technologií, které můžeme vyvinout nebo případně pořídit.

Vydání RAD Studio XE 2, které plánujeme předvést v Moskvě, je největší verzí tohoto produktu s obrovskými schopnostmi a velkým počtem podporovaných platforem od první verze Delphi, vytvořené pro 16bitová Windows a dřívější inovativní produkt, který spojuje komponentní přístup a kompilaci se strojovým kódem. Nyní podporujeme vývoj nejen pro Windows, ale i pro Macintosh, nemluvě o vývoji webu a tvorbě aplikací pro mobilní zařízení, přičemž tyto aplikace pro různé platformy mohou mít jeden kód.

Nová vývojová platforma FireMonkey je výsledkem spolupráce mezi Embarcaderem a nedávno získanou ruskou firmou KSDev se sídlem v Ulan-Ude, výrobcem komponent vektorové grafiky, DirectX a OpenGL, technologií grafických efektů a komponent Delphi využívajících GPU s PixelShader 2.0. Před rokem jsme získali společnost KSDev (viz ksdev.ru) a začali jsme spolupracovat na vytvoření multiplatformního vývojového nástroje, který zahrnuje platformu pro vývoj aplikací FireMonkey s komponentami pro Delphi a C++ Buider pro vytváření uživatelského rozhraní aplikace, integrace s databázemi, zpracování grafiky pomocí grafického procesoru a integrace s operačním systémem.

Pomocí FireMonkey můžete vytvořit aplikaci, která provozuje CPU a GPU společně, a poté pomocí různých kompilátorů a run-time knihoven (Run-time Libraries, RTL) ji můžete zkompilovat pro Windows, Mac OS nebo iOS. Místo učení programování s různými grafickými knihovnami, učení API z různých platforem s různými souřadnicovými systémy a různými schopnostmi mohou vývojáři používající Delphi a C++Builder používat stejný přístup ke komponentám, vizuálně upravovat formuláře a připojovat se k databázím přesouváním komponenty pomocí myš. Toto je zásadně nový způsob vytváření aplikací, které běží na různých platformách, a je budoucností. Pokud chcete do své aplikace přidat podporu pro další operační systémy a platformy, nemusíte ji předělávat a vyvíjet – postačí ji pouze překompilovat.

Vytváříme nové kompilátory, které generují nativní kód. Dnes existují kompilátory Delphi pro 32bitové a 64bitové verze Windows, 32bitové verze Mac OS 10. A pracujeme na nové generaci kompilátorů Delphi a C++Builder, které vám umožní vytvářet vysoce výkonné nativní kód pro tyto i další platformy jako Android nebo Linux a zachovávají si stejný design, stejné komponenty, stejný kód pomocí různých kompilátorů a runtime knihoven.

Jak vidíte, důvodů k nadšení mám dost. A vývojáři, které potkávám po celém světě, vědí, že Embarcadero hodně investuje do Delphi a C++Builderu a také do vývojových nástrojů PHP.

KP: Jakého pokroku jste dosáhli v integraci nástrojů těchto dvou společností za poslední dva roky? Jaké má Embarcadero v této oblasti plány do budoucna?

DI.: V době, kdy se divize CodeGear stala součástí Embarcadera, měla tato společnost vývojové týmy v Torontu, Monterrey a Rumunsku, my jsme byli a stále jsme ve Scotts Valley a v Rusku, v Petrohradu. Embarcadero mělo nástroje pro vývojáře a DBA, CodeGear měl nástroje pro vývoj aplikací, ale ty také využívají databáze. Fúze společností je spojením odbornosti, znalostí v oblasti databází, optimalizace kódu včetně serverového kódu. Fúze také vyústila ve vytvoření nového produktu, AppWave, speciální technologie pro přeměnu obyčejné Windows aplikace na něco velmi snadno použitelného (jako jsou aplikace pro iPhone nebo jiná zařízení). AppWave umožňuje neinstalovat aplikaci, ale jednoduše ji vybrat a spustit z připraveného aplikačního úložného (app) serveru, přičemž bude spuštěna na počítači uživatele bez provádění změn v oblasti jeho registru a systému souborů. Mimochodem, prohlížeč aplikací AppWave je napsán v Delphi. Embarcadero využívá Dephi pro svůj vlastní vývoj a naše odborné znalosti v oblasti vývoje aplikací.

Aplikace pro iPhone (iOS) vytvořená společností
pomocí platformy FireMonkey

Můžete také využít integraci našich vývojových nástrojů a DB Optimizer k optimalizaci SQL dotazů při sestavování aplikací. Předáním kódu SQL přímo do DB Optimizer jej můžete profilovat, testovat a vrátit jeho optimalizovanou verzi zpět do vývojového prostředí. Zkušenosti společnosti Embarcadero s databázemi také zlepšily technologii DataSnap. Díky vývojářům z Toronta jsme získali mnoho znalostí o architektuře vícevrstvých systémů a databází. Nyní máme společné odborné znalosti v oblasti serverového kódu a uložených procedur v obou společnostech. Máme nástroje jako RapidSQL a DB Change Manager a vývojová prostředí, která usnadňují vytváření kódu na straně serveru, jako jsou technologie Code Insight a Code Completion, které umožnily vytvářet technologie SQL insight a SQL Completion. Náš společný přístup k vytváření klientského a serverového kódu, naše společná filozofie, nám umožňuje sdílet společné funkce mezi nástroji pro správu databází a nástroji pro vývoj aplikací.

Kirill Rannev: Chci dodat něco důležitého. Z obchodního hlediska je velmi důležité, jak naše nástroje dodáváme. Například nové vydání RAD Studio XE 2 Ultimate obsahuje úplnou sadu nástrojů DB Power Studio. Jedná se o velmi výkonnou sadu nástrojů, včetně prostředí pro vytváření dotazů RapidSQL, nástroje pro správu změn DB Change Manager a nástroje pro optimalizaci dotazů DB Optimizer, které vám umožňují provádět důležitou část procesu vývoje a nasazení a spravovat změny v datový model, databáze, kód atd. Jedná se o velmi dobrou a správnou kombinaci technologií.

DI.: V případě potřeby však mohou vývojáři použít Subversion ke správě verzí zdrojového kódu a DB Change Manager ke správě verzí metadat. Můžete použít profilování kódu a DB Optimizer k optimalizaci kódu serveru, RapidSQL k vytváření a ladění kódu serveru a naše vývojová prostředí k vytváření a ladění aplikací. Tato kombinace technologií v RAD Studio XE Ultimate Edition demonstruje paralely mezi modely vývoje databází a aplikací. Většina vývojářů vytvářejících podnikové aplikace pomocí Delphi a C++Builderu pracuje s databázemi a potřebuje tyto nástroje a RAD Studio XE Ultimate Edition je pro tyto vývojáře skvělou kombinací.

KP: Moderní uživatel již není pouze uživatelem platformy Windows. Používáme mobilní zařízení, iPhone, iPad, zařízení založená na platformě Android. To znamená, že by vývojáři měli začít cílit na různé platformy bez výrazného navýšení investic do školení – to znamená, že jsou potřeba univerzální nástroje. Je zřejmé, že je nereálné očekávat vzhled univerzálních nástrojů od výrobců platforem a v této věci se můžeme spolehnout pouze na nezávislé výrobce nástrojů. Kde se můžeme na Embarcadero spolehnout?

DI.: V oblasti podpory platforem máme stále co dělat. Dnes představujeme podporu platformy iOS pro iPhone a iPad, následovat bude podpora pro smartphony Android, Windows 7 a Blackberry. V RAD Studio XE 2 jsme začali budováním platformy FireMonkey pro iOS a později portujeme FireMonkey na další platformy.

Zároveň existuje velké množství operačních systémů, které podporují dotykové obrazovky (touch screen), pro telefony, tablety a zařízení, stolní počítače a podporu pro ně budeme i nadále přidávat. Kromě toho existují systémy hlasového ovládání, systémy řízení pohybu, biometrické systémy, akcelerometry, takže musíme pokračovat v rozšiřování FireMonkey, aby všichni vývojáři mohli využívat výhod nových platforem. Například zařízení Microsoft Kinect bylo navrženo pro Xbox 360 a nyní existuje odpovídající SDK (Software Development Kit) pro Windows. A již máme příklady, kdy používáme pohyb k ovládání aplikace v podstatě stejným způsobem, jakým bychom normálně používali myš nebo klávesnici.

Když vytváříte aplikace se spoustou složité grafiky, vytváříte celý svět nových uživatelských rozhraní. Pokud máme co do činění s operačním systémem Windows, zapouzdřujeme jeho Windows API do knihovny VCL (Visual Component Library - knihovna vizuálních komponent, která je nedílnou součástí vývojových nástrojů Delphi a C++ Builder. - Poznámka. vyd.), který lze mimochodem aplikovat dále. A ve FireMonkey zapouzdřujeme API operačního systému. Ale dnes manipulujeme s formami a grafikou mnohem šířeji. Můžete také přidat vlastnosti fyzického prostoru pro animaci a speciální efekty. Kromě toho existuje obrovské množství dalších doplňkových funkcí pro vytváření uživatelských rozhraní, které se chystáme v příštích letech implementovat pro různé platformy, mobilní a tabletová zařízení.

Microsoft nedávno zveřejnil podrobnosti o Windows 8, který má vyjít za rok. Tyto novinky budeme podporovat v knihovně VCL a v platformě FireMonkey. Delphi je ale vývojový nástroj určený nejen pro Windows, ale také pro Macintosh, iPhone a iPad. Vyvíjíme také naše produkty PHP, podporujeme jQuery Mobile, používáme iOS API k vývoji mobilních klientských aplikací a vytváříme PHP aplikace na straně serveru pomocí průvodců a nástrojů pro generování JavaScriptu, HTML a kaskádových stylů na straně klienta. Můžeme zabalit PHP aplikace a iPhone iOS nativní klientské aplikace, přičemž klient komunikuje s PHP serverem. A to zase bude komunikovat s databázovým serverem a webovými službami – se vším, co je k podnikání potřeba.

Vývojové prostředí RadPHP XE2. Vytvořte mobilní webovou aplikaci
pomocí komponent jQuery Mobile pro iPhone 3G

Jinými slovy, plánujeme rozšířit možnosti FireMonkey a VCL, včetně podpory mobilních platforem.

KP: Mohl byste více rozvést platformu FireMonkey?

DI.: Jak jsem již poznamenal, knihovna VCL vytvořená pro Windows se bude nadále vyvíjet a zlepšovat. Ale dnes, pokud chcete skutečně vyvíjet obchodní aplikace, musíte je vytvářet pro různé platformy. K tomu je určena platforma FireMonkey. Podporuje tvorbu uživatelských rozhraní s vysokým rozlišením, vysoce výkonnou 3D grafiku, vysoké snímkové frekvence a, co je důležité, k tomu využívá GPU.

Tyto funkce můžete využít při vytváření vědeckých, inženýrských a obchodních aplikací. Takové aplikace se mohou připojovat k databázím pomocí technologie dbExpress, stále využívají nevizuální komponenty známé vývojářům, jako je ClientDataSet nebo DataSource, využívají technologii DataSnap, připojují se k libovolným databázím, SOAP a REST serverům. Můžete vytvářet atraktivní ovládací prvky, tlačítka v rámečku, efektní tabulky a další prvky rozhraní ve 2D a 3D. Hotový 3D model můžete načíst do aplikace a spojit jej s 2D tvarem, ve kterém jej lze otáčet a prohlížet z různých úhlů. Můžete vytvořit datovou kostku nebo 3D obchodní graf a otáčet je pomocí myši, klávesnice nebo dokonce zařízení Kinect, nebo můžete vstoupit do krychle a podívat se na její různé povrchy zevnitř. A to vše lze provést pomocí vysokorychlostního GPU. Stejnou aplikaci pak lze zkompilovat pro jinou platformu, například Mac OS.

Aplikace obsahující rotující kostku s daty,
umístěn na jeho okrajích

Nebo můžete vytvořit 3D tvar od začátku a použít kamery a světla k osvětlení a otáčení částí uživatelského rozhraní. Návrhář formulářů již má vestavěné prostředí pro podporu 3D uživatelského rozhraní přímo v době návrhu.

V systému Windows můžete použít knihovny Direct2D pro 2D grafiku s vysokým rozlišením a Direct3D pro 3D grafiku. Mac OS používá ke stejnému účelu knihovny Quartz a OpenGL. Pro iOS se používají knihovny Quartz a OpenGL ES. To vše je ale vývojáři skryto – používá platformu FireMonkey, její souřadnicový systém a rozhraní pro programování aplikací, aniž by o těchto knihovnách přemýšlel, a dokáže sestavit stejnou aplikaci pro různé platformy.

Připomeňme si, co je VCL. VCL je "obal" komponenty kolem Windows API. Zabýváme se zdroji, nabídkami, dialogovými okny, barvami, styly, zprávami systému Windows. FireMonkey je na rozdíl od VCL multiplatformním obalem a zachovává stejné modely událostí a komponent, což vám umožňuje přemýšlet z hlediska událostí (například události OnClick, OnHasFocus, onMouseDown a onKeyDown), ale zpracovávat události na počítačích Macintosh nebo iPhone.

Rámec FireMonkey také přichází s kompletním systémem pro animaci prvků uživatelského rozhraní. Rozhodně se nejedná o komplexní animační systém ve stylu Pixar, ale umožňuje aplikovat efekty, jako je animace bitmap, zvýraznění zaměření prvku uživatelského rozhraní a práce s vektorovou grafikou. Vývojář má k dispozici více než 50 vizuálních efektů: rozmazání, přeměna obrazu na černobílý, rozpouštění, přechody, odraz, vytváření stínů – všechny typy efektů dostupné v moderních GPU, které jsou nyní téměř v každém počítači. Aplikace vytvořená pomocí platformy FireMonkey odesílá příkazy do GPU, které vykonává veškerou práci při zobrazování grafiky a vytváření uživatelského rozhraní. Centrální procesor je přitom volný pro výpočty a přístupy k operačnímu systému. Vývojář potřebuje pouze správně umístit komponenty.

Nejzásadnější věcí na platformě FireMonkey je způsob, jakým vytváří uživatelské rozhraní. Existují zařízení pro umístění bitmapové grafiky na prvky rozhraní, jako jsou nabídky, tlačítka a posuvníky. Ve FireMonkey k tomuto účelu používáme vektorovou grafiku GPU. Z programátorského hlediska jsou to všechny stejné ovládací prvky, ale veškerou práci při jejich zobrazení odvádí grafický procesor. Můžeme použít styly na ovládací prvky, vytvořit aplikaci, aby vypadala jako aplikace pro Mac OS nebo Windows, vytvořit vlastní styl, aplikovat naše styly na prvky rozhraní (například udělat z tlačítka obdélníkové nebo kulaté změnou jeho stylu v editoru formulářů) - k tomu má vývojové prostředí editor stylů. Můžete si vytvořit svůj vlastní styl, nebo můžete změnit styl již hotové aplikace.

FireMonkey Platform - Vývojové nástroje
a podporované platformy

Pokud si vzpomínáte, v knihovně VCL byl omezený počet ovládacích prvků - kontejnerů (to znamená, že do nich bylo možné umístit další prvky) a ve FireMonkey je každý ovládací prvek kontejnerem. To znamená, že každý ovládací prvek může obsahovat jakýkoli jiný ovládací prvek. Položky rozevíracího seznamu mohou například obsahovat obrázky, tlačítka, pole úprav a další ovládací prvky. A také můžete umístit komponenty do vrstev.

Vykreslovací systém FireMonkey je poměrně flexibilní – umí využívat knihovny Direct2D, Direct3D a OpenGL odesíláním příkazů do GPU. K dosažení téhož ve VCL bylo nutné vygenerovat samostatný off-screen buffer, vytvořit v něm obrázek voláním příslušných funkcí grafické knihovny a ten následně zobrazit na formuláři.

Příklady grafických efektů podporovaných FireMonkey

Pokud nemáte GPU, můžete stále používat 2D nebo 3D tvary a používat ovládací prvky FireMonkey. V tomto případě bude platforma FireMonkey používat knihovny GDI+ nebo jiné podobné knihovny a provádět stejné efekty a animace nebo manipulaci s 3D objekty.

Další funkcí FireMonkey je nový systém pro navázání prvků rozhraní na data, který je otevřený a flexibilní. Ve VCL existují dva typy prvků rozhraní: data-bound a non-data-bound (například TDBEdit a TEdit). Ve FireMonkey může být každý ovládací prvek spojen s daty jakéhokoli typu. Může to být jen výraz, pole z datové sady, data z objektů vytvořených vývojářem nebo výsledky volání metod.

Při vytváření aplikace do ní navíc můžete načíst hotový 3D model a používat jej – takové schopnosti jsou často vyžadovány jak v obchodních, tak v inženýrských aplikacích. Máme klienta, který vytváří aplikace pro logistiku. Měli vytvořený informační systém s Delphi a v něm aplikaci, která kreslila plán a zobrazovala informace z datových zdrojů. Nedávno udělali zajímavou věc - nakreslili plně automatizovaný 3D sklad v AutoCADu a jejich aplikace umožňuje vidět, jak se automatický nakladač pohybuje skladem a umísťuje zboží do regálů. A rozloží data ze zdrojů na odpovídající obrázek.

Příklady změn aplikačních stylů

KP: Jaké formáty 3D modelů jsou aktuálně podporovány?

DI.: V této verzi podporujeme načítání modelů z AutoCADu, Collada (open source nástroj pro 3D modelování. - Poznámka. vyd.), Maya, formát OBJ podporovaný mnoha prodejci 3D grafiky.

KP: Jaké další formáty se plánují přidat?

DI.: Plánujeme přidat 3DS (3D Studio MAX), SVG (obvykle se tento formát používá pro 2D vektorovou grafiku, ale někdy i pro 3D), Google SketchUp. Můžeme podporovat i jiné formáty.

KP: Vyžaduje použití 3D modelů v aplikacích vytvořených pomocí FireMonkey licenci pro příslušný nástroj pro 3D modelování?

DI.: Ne, není. Vše, co děláme, je číst soubor modelu. Model importujeme, ale neexportujeme (i když samozřejmě můžete napsat aplikaci, která model uloží ve vašem vlastním formátu). Netvrdíme, že jsme výrobcem nástrojů pro 3D modelování – k tomu můžete použít AutoCAD, 3D Studio Max, Maya nebo jakýkoli jiný nástroj pro 3D modelování a importovat vytvořené modely do našich aplikací.

KP: Jak výkonné jsou aplikace vytvořené pomocí FireMonkey na moderních hardwarových platformách?

DI.: Výkon je poměrně vysoký. Například 3D tvar se třemi koulemi a třemi světly lze na MacBooku Pro vykreslit rychlostí 100 snímků za sekundu. A může dosáhnout 600 - záleží na tom, co přesně děláme. Opět vše závisí na výkonu GPU.

KP: Znamená to, že s pomocí FireMonkey můžete vytvářet hry, které splňují moderní požadavky?

DI.: Naše vývojové nástroje neumisťujeme jako nástroj pro hry. Přesto s využitím vysokého výkonu moderních grafických procesorů můžete vytvářet hry i s FireMonkey – vždyť jsou vytvářeny pomocí Direct3D nebo OpenGL.

KP: Jakou práci nyní děláte v oblasti podpory rozpoznávání gest a dalších nových věcí? Je taková podpora dostupná?

DI.: V tomto vydání zatím nemáme podporu gest. Ovládání gesty bude přidáno v budoucí verzi FireMonkey, ale prozatím můžete používat podporu gest zabudovanou v operačním systému.

Michail Filippenko, ředitel Fast Reports, Inc.

K.R.: Již jsme si řekli, že technologie FireMonkey má ruské kořeny – její základy vznikly u nás a následně se samotná technologie a její vývojáři spojili do Embarcadera. Obecně je potěšující vidět růst ruské komponenty v RAD Studio a Delphi. Jde o činnost našeho vývojového centra v Petrohradu a o příspěvek nezávislých ruských vývojářů. Například Rad Studio XE2 obsahuje celosvětově známý a u nás velmi oblíbený generátor sestav FastReport. Pochází z Rostova na Donu.

KP: Chtěl bych mluvit o kompilátorech. Jaký kompilátor se používá k vytváření aplikací pro iOS?

DI.: Nemáme vlastní kompilátor Delphi pro iPhone nebo iPad – zatím jsme nevyvinuli kompilátory pro procesory ARM používané v těchto zařízeních. Pro iOS dočasně používáme kompilátor Free Pascal a runtime knihovnu. Ale pracujeme na další generaci kompilátorů, včetně těch pro procesory ARM. Existují však kompilátory pro Windows a Mac OS, protože obě hardwarové platformy jsou založeny na procesorech Intel.

KP: A co se za poslední dva roky udělalo na poli vývoje překladačů?

DI.: Máme 32 a 64bitové kompilátory Delphi pro Windows a Mac OS. A pracujeme na nové generaci kompilátorů Delphi a C++. Práce na nich stále pokračují, ale až budou dokončeny, budeme mít kompilátory Delphi pro procesory ARM, platformy Android, Linux a cokoli jiného. A budeme mít 64bitové kompilátory C++ pro Windows a další platformy kompatibilní s nejnovějším jazykovým standardem C++ právě přijatým ISO.

KP: Co se dnes děje s podporou cloud computingu ve vývojových nástrojích Embarcadero?

DI.: S RAD Studio XE 2 podporujeme migraci aplikací do cloudu Microsoft Azure nebo Amazon EC2 pomocí Platform Assistant. A máme serverové komponenty pro Cloud Storage for Azure a Amazon S3 pro ukládání tabulek, binárních dat, front zpráv. V předchozí verzi RAD Studio XE jsme také podporovali nasazení aplikací na Amazon EC2, ale nebyla zde podpora pro úložiště.

Podpora cloud computingu v RAD Studio XE 2

KP: Před dvěma lety jste mluvili o novém řešení All-Access. Kolik byla poptávka? Jaké jsou jeho výhody pro systémové integrátory a vývojáře?

DI.:Řešení All-Access a cloudový nástroj AppWave jsou široce používány po celém světě. Jsou navrženy tak, aby usnadnily používání aplikací naší společnosti i aplikací třetích stran. Ve skutečnosti se jedná o řešení pro správu licencí a aplikací a je vhodné pro velké společnosti. Menší firmy, které nemají vyhrazený tým pro správu aplikací, mohou uložit aplikaci do úložiště, vybrat uživatelská jména z databáze a zpřístupnit tyto aplikace k použití, aniž by si museli pamatovat, kde je licenční klíč a kolik licencí je k dispozici. All-Access a prohlížeč AppWave jsou navrženy tak, aby spravovaly správu verzí i řízení přístupu.

K.R.: Trh je tak rozmanitý a uživatelé jsou tak různí, že není možné pokrýt všechny potřeby jedním řešením. Proto se snažíme o nejrůznější „obalová“ řešení. Udělali jsme hodně práce na sjednocení licencování, správy licencí a instalace produktů. Tato řada řešení zahrnuje nástroje pro správu licencí a přístupu nejen pro produkty Embarcadero, ale i pro jakékoli další produkty, včetně interního vývoje společností.

Práce na sdružování vývojových nástrojů do efektivních uživatelských sad stále pokračuje. Máme All-Access – superset, který kombinuje všechny produkty Embarcadero. Pokud si zákazník zakoupí All-Access Platinum verzi, dostává všechny nástroje, které jsou v Embarcaderu. Někdy se ale tato sada ukáže jako nadbytečná, například jsme pro databázové specialisty vyrobili dvě další sady - DB Power Studio Developer Edition a DB Power Studio DBA Edition. Rozdíl mezi nimi je v tom, že pro vývojáře nabízíme RapidSQL - nástroj pro vývoj serverového kódu a pro administrátora je vestavěn DBArtizan - nástroj pro správu databází, širší produkt než RapidSQL. Pro profesionály máme následující sady All-Access: sada všech produktů, DB Power Studio pro vývojáře, DB Power Studio pro administrátory, ER Studio Enterprise Edition pro architekty a kohokoli, kdo se zabývá modelováním. Existují kombinace pro vývoj aplikací a pro administrátory. Delphi je vývojářský nástroj a má velký smysl přidat k němu vývojové nástroje SQL a nástroje pro optimalizaci. A konečně, DB Change Manager je velmi logický nástroj pro správu složitosti změn, ke kterým dochází v databázích během jejich životního cyklu.

All-Access je tedy hlavou velké rodiny různých sad produktů.

KP: Pokud to není tajemství, kdo v Rusku používá All-Access?

K.R.: Máme zákazníky, kteří si zakoupili All-Access založený na Delphi. Mnoho z nich staví komplexní klient-server systémy s SQL Server a Oracle a okamžitě si oblíbili naši multiplatformní databázovou sadu nástrojů. Máme klientskou společnost, která s Delphi spolupracuje od první verze a před rokem přešla z Delphi na All-Access. Dva nástroje, které budou zaručeně používat všichni vývojáři v této společnosti, jsou Delphi a DBArtisan. A jsou zákazníci, kteří do All-Access přišli ze strany databáze. Jejich primární náplní je správa databází, ale příležitostně také vyvíjejí aplikace. Mezi klienty využívající All-Access patří mediální společnosti, výrobci strojů a další průmyslová odvětví.

Samostatně bych se chtěl věnovat malým společnostem. Velmi často v malých týmech dělá vše vývojář a taková společnost někdy nakoupí velké balíčky All-Access potravin pro jednoho nebo dva vývojáře. Ve velkých týmech není podporováno, aby vývojář plnil například i roli správce databáze, takže tam jsou většinou oblíbené malé balíčky potravin a v malých firmách je tato kombinace povinností celkem přijatelná.

Delphi Architect je silně prodávaný produkt, který zahrnuje modelovací a programovací nástroje. Počet prodaných kopií je však menší než u verzí Delphi Enterprise, ale je také velký. Podotýkám, že v roce 2010 jsme byli nejlepší zemí z hlediska tržeb, přestože všechny země krizi přežily. Tento růst nebyl způsoben ani tak ekonomickými faktory, jako tím, že verze RAD Studio XE, vydaná na konci roku 2009, se ukázala být velmi žádanou. A přitom očekáváme další růst tržeb.

Udělali jsme další rozumný krok, který je v Rusku velmi žádaný. Stupeň legalizace různých verzí našich produktů je různý: čím vyšší verze, tím více legalizovaná, protože dříve nebyl software tak aktivně nakupován. Počínaje RAD Studio XE licence pokrývá verze 2010, 2009, 2007 a dokonce i Delphi 7, široce používaný produkt.

Dnes se vývojáři potýkají s tím, že mají jak nové projekty, tak projekty ve stavu podpory. Velké množství projektů bylo migrováno z raných verzí Delphi na verzi 7 a zůstávají v této verzi, přičemž nadále pracují na relativně malých zdrojích. Nikdo je nepřesouvá na novější verze, ale udržují se životaschopné. A nyní umožňujeme za málo peněz (méně než je cena licence Delphi 7) získat RAD Studio XE i Delphi 7 - to znamená, že legalizujeme vývojáře jak pro implementaci nových projektů, tak pro projekty podpory.

KP: Jak hodnotíte současný stav komunity Embarcadero?

DI.: Tato komunita je velká a velmi náročná. Potřebují všechno a hned – jsou to vývojáři. Někdy ale trvá dlouho, než se něco podaří.

Před několika lety jsme vzali architekturu komponent Windows a umístili ji na linuxové desktopy. Nyní vidíme, že to nebylo správné rozhodnutí. Správným rozhodnutím je vytvořit platformu pro aplikace. Aplikace i pro různé platformy mají nabídky, okna, grafiku, síťový přístup a přístup k zařízením. Různé platformy mohou mít různé modely řízení toku nebo zpracování výjimek, ale v kódu aplikace vidíme stejné zkušební bloky. Naším úkolem je usnadnit vývojářům vytváření podnikových aplikací a jejich kompilování pro platformy, na kterých mají být používány, bez ohledu na to, jak je uspořádán instrukční systém příslušných procesorů a jaké jsou další vlastnosti těchto platforem. A FireMonkey je přesně to, co k vyřešení tohoto problému potřebujete.

KP: Pokud společnost vytvoří nové zařízení a chce pro něj mít podporu FireMonkey, bylo by to možné?

DI.: S kompilátory nové generace, které budou mít front-end nezávislý na platformě a back-end závislý na platformě, to bude docela možné. Mezitím pro každý operační systém vytvoříme kompilátor a runtime knihovnu od začátku.

Každé moderní nové zařízení má obvykle grafické uživatelské rozhraní (mnoho z nich má dvoujádrový procesor a GPU) a standardní sady SDK pro vývojáře. To vše zjednodušuje vytváření podpory zařízení ve FireMonkey. Pokud má nové zařízení pouze knihovny pro 2D grafiku, jako je Quartz, budeme moci takové zařízení podporovat ve FireMonkey, ale to bude trvat přibližně několik měsíců. Hodně však záleží na platformě: ne všechny platformy podporují všechny funkce, například iOS nemá nabídky a dialogy a na formuláře takových aplikací nebudete moci umístit odpovídající komponenty.

KP: Změnilo se něco v politice spolupráce s partnery? Co se dělá pro zvýšení podílu uživatelů vašich produktů? Co se dělá v Rusku?

DI.: Náš partnerský ekosystém je široký – existují stovky výrobců nástrojů a komponentů, které v našich produktech nenajdeme, a máme program technologického partnerství. Proto je vývojářům k dispozici široká škála komponent, technologií a nástrojů. A řešení, která vytvářejí pro své zákazníky, jsou lepší, než kdyby byly používány pouze naše produkty. A pro prodej máme pobočky v mnoha zemích, prodejce a distributory.

K.R.: Není pro nás důležitý počet partnerů, ale kvalita práce každého konkrétního partnera. Prozatím se chceme zaměřit na úzkou spolupráci se stávajícími partnery, i když skupina partnerů zůstává otevřená. Máme mnoho partnerů a musíme jim pomoci v oblasti technologií. Spolupracujeme s vývojáři a ti vědí, co chtějí, vědí, co je na trhu dostupné, a schopnosti partnerů tomu musí odpovídat.

Máme obchodní partnery, kteří do Embarcadera jako oboru podnikání hodně investovali – mají vyškolené specialisty, marketing našich produktů, oddané zaměstnance, kteří jsou za tuto oblast zodpovědní a sledují, co se děje s našimi produkty, ceníkem, marketingem. Přirozeně jsou z hlediska prodeje našich produktů úspěšnější než společnosti, které naše produkty prodávají případ od případu.

KP: Davide, Kirille, mnohokrát vám děkuji za zajímavý rozhovor. Jménem naší publikace a našich čtenářů mi dovolte popřát vaší společnosti další úspěchy při vytváření vašich úžasných nástrojů, které vývojáři tolik potřebují!

Otázky položila Natalia Elmanova

FireMonkey je základní technologií „nového Delphi“. Řekněte nám prosím o cílech, schopnostech a technických aspektech této zásadně nové knihovny. Když se po chvíli ohlédnete zpět, jak těžké a oprávněné bylo vaše odmítnutí dále rozvíjet super populární VCL?

Byl zvolen jako hlavní směr vývoje technologie Delphi k dosažení konkrétního cíle – multiplatformního vývoje z jednoho prostředí, založeného na jednotné základně zdrojového kódu a bez nutnosti radikálního přeškolování vývojářů. V rámci dnes již klasického a super populárního VCL to nebylo možné, jeho spojení s WinAPI bylo příliš těsné, dalo by se říci, „na genetické úrovni“.

Komponenty VCL neměly „abstraktní“ vrstvu mezi funkční úrovní z hlediska rozhraní a jejich mapovacích mechanismů. Funkční úroveň- jak se chová jako ovládací prvek, na jaké události reaguje, jaký druh uživatelské interakce poskytuje. Zobrazit- volání platformově orientovaných renderovacích metod jako druhu obrazu tvořeného rastrovými objekty a vektorovými primitivy. FireMonkey zpočátku implementoval princip striktního rozdělení ovládání na dvě složky: „behaviorální“ a „vizuální“.

Vsevolod Leonov, Embarcadero Technologies

První z nich jako celek nebude opakovat ani základy VCL, ale podstatu objektově orientovaného programování. Komponenta je třída, třídy komponent tvoří hierarchii, kde lze rozlišit rodiny a moduly. Třída komponenty má jen málo společného s tím, jak je vykreslována.

Vizuální "obraz" se tvoří dynamicky, není pevně zakódován ve třídě komponent. Obrázek nebo „styl“ ve FireMonkey se načte do komponenty při spuštění aplikace. Máme nějaký funkční rámec pro komponentu a „skin“ nebo „plášť“ lze změnit, ale proč? Aplikace FireMonkey proto vypadají autenticky na jakékoli platformě – Windows 7, Windows 8, Mac OS, iOS a v blízké budoucnosti i Android. Tradiční monolitická struktura třídy VCL to nemohla poskytnout.

Zde hraje zvláštní roli technologický přístup. V zásadě můžete vzít knihovnu VCL a „nacpat“ WinAPI všemi ostatními možnými voláními platformy. Na velmi omezené podmnožině komponent to lze stále provést, ale VCL obsahuje několik stovek komponent, takže tento přístup by mohl jednoduše „zabít“ VCL. Bylo rozhodnuto nedotýkat se VCL a vyvinout nové funkce na nové platformě - FireMonkey. Tato technologie má dokonce jistou technickou eleganci – v době sestavování projektu pro konkrétní platformu připojí IDE Delphi potřebný kompilátor a komponenty rozhraní dostanou platformový styl.

Pro uživatele je to jedno kliknutí myší a stejný zdrojový kód, pro Delphi je to mnoho let tvrdé práce vývojářů vytvořit takovou multiplatformní knihovnu.

Když bylo jasné, že FireMonkey bude představen jako samostatná nová platforma, bylo třeba zvolit správnou strategii koexistence: Embarcadero nechtělo nijak negativně ovlivnit uživatele VCL. Proto jsme zvolili následující plán: VCL zůstává ideologicky a architektonicky stabilní, aby byla zajištěna co největší kompatibilita a usnadnila migrace projektů na moderní verze. Vývoj FireMonkey půjde přirozenou a paralelní cestou, bez ohlédnutí za VCL.

Slabou stránkou tohoto řešení je poměrně problematická migrace z VCL na FireMonkey v rámci jednoho projektu. Ale na druhou stranu u nového projektu si vývojář může vybrat FireMonkey, aby zajistil multiplatformnost jeho výsledné aplikace. S vydáním XE4 s podporou iOS již můžeme hovořit o silné konkurenční výhodě Delphi pro mobilní vývoj ve firemním prostředí, která bude po implementaci plánované podpory pro Android navýšena.

Proto jako takový neexistuje žádné výslovné „odmítnutí“ vývoje VCL. V nových verzích se vyvíjí i VCL část Delphi. To zahrnuje podporu pro 64bitovou verzi a zavedení stylů pro vizuální komponenty a implementaci mechanismu pro flexibilní dynamické vazby neboli „binding“ a zahrnutí knihovny FireDAC pro práci s databázemi v projektech VCL. Jen na pozadí obrovského kvalitativního skoku kvůli FireMonkey vypadá pokrok ve VCL poněkud neprojeveně. Ale ať je to jak chce, VCL je nedílnou součástí Delphi a zůstane jí po mnoho let. Přestože vývoj platforem a současný stav věcí v oblasti OS pro desktopové systémy a mobilní zařízení jsou takové, že budoucnost je jednoznačně s FireMonkey.

O podpoře iOS jsme již diskutovali v rozhovoru, pojďme našim čtenářům říci o nejnovější podpoře RAD Studio XE4 pro další nejnovější technologie, jako jsou Windows 8 a WinRT, 64bitové systémy, MacOS a tak dále. Můžete vyjmenovat, co dalšího můžete modernímu programátorovi zhýčkanému inovacemi nabídnout?

Moderní programátor s největší pravděpodobností není „rozmazlený“ inovacemi. U velkých projektů se jakákoli „inovace“ často promění v gigantické množství práce.

Všichni například dlouho čekali, mnozí se okamžitě vrhli na převod svých kódů na novou platformu. Ukazuje se ale, že ani velmi profesionální týmy na to nejsou připraveny. Kompilovaný 64bitový kód neznamená funkční. Začaly se objevovat „hříchy mládí“, například pomocí instrukcí předpokládajících velikost adresy 4 bajty. Neexistence kultury provádění testů spojená s technologickou neochotou tento proces v krátké době implementovat.

A zde – čím větší je projekt, měřeno například počtem řádků zdrojového kódu, tím pečlivěji a vyváženěji programátoři zacházejí s různými druhy inovací od vzhledu „tlačítka“ v rozhraní až po „syntaktický cukr“ v kompilátoru.

Jedním z těchto „problémových“ úspěchů bylo vydání Windows 8. Osobně, jako uživatel PC a pouze moderní IT specialista, mám z Windows 8 radost. Ale pro vývojáře, kterým byla jako zátěž zaslána dávka počítačů s Windows 8 s technickými specifikacemi pro vývoj pod novým OS, to znamená určité potíže.

Snažili jsme se poskytnout podporu pro vývoj pod novým rozhraním tohoto OS co nejpohodlněji a bezbolestně. Proto byly zavedeny speciální styly pro VCL i FireMonkey a programátor může buď přestavět rozhraní aplikace, nebo vytvořit novou aplikaci, která bude vzhledem k „nativní“ pro Windows 8 nerozeznatelná. Samozřejmě je potřeba "nativní" podpora pro Windows 8 přes WinRT. Zde však ovlivňuje upřednostňování cílů v moderních podmínkách. Mac OS, iOS, Android v blízké budoucnosti zatím nedávají příležitost mluvit o plné podpoře WinRT v blízké budoucnosti.

Strategickým cílem Embarcadera je samozřejmě multiplatformní. Vydání RAD Studio XE4 bylo klíčové, především kvůli podpoře iOS. Aktivní programátor využívající VCL může začít vyvíjet pro iOS během několika hodin. I jednoduchá mobilní aplikace může být okamžitě přeměněna na výkonný projekt, který funguje v rámci stávající infrastruktury. Nemyslete si, že je to jen nový kompilátor pro FireMonkey a nový styl, který odpovídá rozhraní iOS.

To zahrnuje nový vizuální návrhář, vestavěnou podporu pro různé tvarové faktory, knihovny pro přístup k datům, včetně nového FireDAC, a technologii LiveBindings pro flexibilní a dynamickou vazbu na podniková data. Všechny tyto inovace přicházejí synchronně – pro Windows, pro Mac OS a pro iOS. Operační systém Mac OS se nevyvíjí tak rychle, takže neexistují takové problémy jako přechod z Windows 7 na Windows 8. Ale objevily se Retina displeje a to vyžadovalo zvláštní pozornost. Nyní každá aplikace MacOS vytvořená v Delphi XE4 automaticky obsahuje dva styly – „normální“ a „vysoké rozlišení“.

Že. stejná aplikace může mít stejně kvalitní „nativní“ rozhraní na jakémkoli stolním počítači od Applu.

Embarcadero svými novými inovativními verzemi nechce vývojáře „překvapit“, „ohromit“ nebo dokonce „bavit“. Spíše naopak, IT sféra je již nyní plná různých překvapení: nová zařízení, nové platformy, noví uživatelé, jejich nové potřeby, nové scénáře interakce. Přidejte k tomu nové technologie vývoje softwaru a programátoři prostě nebudou mít čas vytvářet nové systémy a na těch stávajících – udělají jen to, co migrují z jednoho prostředí do druhého, ze staré knihovny do nové, z jednoho jazyka do další.

Ale nepřiznáváme odmítnutí všeho nového. Chceme jen zajistit kontinuitu všeho – kódu, rozhraní, projektu, dokonce i profesionálních dovedností, když se objeví nové platformy a zařízení. Dá se říci, že bojujeme s nezdravým konzervatismem ve vztahu k novým platformám na úkor zdravého konzervatismu ve vývojových nástrojích. Od Embarcadera nečekejte exotické produkty, nestandardní programovací jazyky a výstřední vývojářské nástroje.

U nás vždy najdete vizuální vývoj, klasické jazyky, "nativní" kód a necháte nové cílové platformy pro vaše aplikace vytvořené stejným osvědčeným klasickým způsobem.

Co je Fire Monkey?

FireMonkey (FMX) je framework pro multiplatformní vývoj jak pro desktopové systémy (Windows, Mac OS + podpora serverové strany na Linuxu v blízké budoucnosti), tak pro mobilní (iOS a Android) pomocí jazyka Delphi/C++.

zvláštnosti:

• jednotná kódová základna pro všechny platformy;

• jakýkoli ovládací prvek (vizuální komponenta) může být kontejnerem (rodičem) pro jiné komponenty;

• přítomnost velmi pokročilého relativního uspořádání (20 typů) součástí na formuláři;

• LiveBinding vám umožňuje připojit jakýkoli typ dat nebo informací k libovolnému uživatelskému rozhraní nebo grafickým objektům;

• přítomnost stylů formy/komponenty;

• Multi-Device Preview vám umožňuje přizpůsobit vizuální prezentaci pro každou z platforem;

• FireUI Live Preview – Zobrazuje zobrazení aplikace na skutečných zařízeních v reálném čase.

Schopnosti:

• použití nativního API každé z platforem a také možnost volat nativní knihovny třetích stran;

• interakce se všemi senzory (GPS, Akcelerometr, Kompas, Bluetooth (včetně LE) a další);

• podpora push notifikací, IoT;

• podpora asynchronních HTTP požadavků;

• podpora většiny databází (MsSQL, MySql, Oracle, PostgreSQL, MongoDB atd.);

• práce s Cloud Service (Amazon, Azure);

• podpora služby Android.

Nevýhody (aktuálně):

• nedostatek podpory pro přizpůsobení nativních tříd;

• implementace konkrétních věcí je buď nemožná (widgety, rozšíření (iOS) atd.) nebo je nutný tanec s tamburínou (služba na pozadí, vysílaná zpráva atd.);

• přizpůsobení Úvodní obrazovka (počáteční obrazovka), mírně řečeno, ne;

• FMX ovládací prvky využívají vlastní rendering (vizualizace, kresba), který je čistě vizuálně podobný nativnímu;

• použití nativních ovládacích prvků je spojeno s velkými pohyby těla;

• při velkém vnoření komponent se dějí neuvěřitelné věci: aplikace na různých místech padá, ztrácí se fokus, zamrzá atd.;

• informační obsah ladění aplikace na mobilních platformách je nulový;

• popisy chyb na mobilních platformách jsou zredukovány na zbytečné „Chyba 0x00000X“;

• doba kompilace si přeje být nejlepší pro střední a velké projekty;

• nutnost použít soubor k vylepšení mobilních aplikací pro každou platformu;

• žádná podpora architektury Intel Atom;

• neadekvátní cena ve srovnání s konkurencí.

Profesionálové:

• velmi aktivní nedávný vývoj jak produktu, tak komunity, podpora stále více nových technologií;

• přítomnost velkého množství bezplatných a komerčních komponent;

• rychlost aplikace je velmi blízká nativní;

• velmi pokročilý vizuální editor a prostředí obecně, přítomnost stylů;

• možnost otestovat aplikaci na Win, a teprve poté ji nasadit do zařízení, což značně urychluje vývoj;

• změna režimu / platformy pohybem zápěstí;

• PAServer poskytuje snadnou interakci s MacO při vývoji pro Apple OS;

• podpora 3D grafiky ihned po vybalení.

Na závěr chci říci, že za posledních pár let se FireMonkey rozrostl v profesionální nástroj pro multiplatformní vývoj obchodních aplikací a nejen to. Řada nedostatků se postupně řeší a s každým vydáním se produkt stává modernějším a soběstačným a také mizí dosavadní skepse k samotnému jazyku Delphi, spojená s mnohaletou stagnací. Psaní nových projektů na FireMonkey je „bezpečné“ a slibné.

Od doby, kdy pojem FireMonkey víceméně zdomácněl, už uplynulo dost, když ne všem vývojářům, tak alespoň těm, kteří používají Delphi. Během této doby byly knihy o FireMonkey, články o FireMonkey, příspěvky o FireMonkey v mnoha blozích. Číst to všechno je velmi zajímavé. Ale žádná teorie nemůže nahradit praxi. A stejně jako mnozí předtím jsem měl nutkání zkusit něco napsat pomocí FireMonkey.

Při tom však nastal problém. Z nějakého důvodu jsem se rozhodl, že jen potřebuji realizovat nějaký nepříliš složitý pracovní projekt.

Abych vysvětlil, proč se to pro mě ukázalo jako problém, bude to chtít (člověk chce psát, lyrickou) odbočku. Exkurze do mé minulosti vývojáře. Vysvětlete některé své názory na programování pomocí Delphi.

Musím říct, že Delphi jsem začal používat na Windows 3.1, tedy od první verze. A od té doby studuji VCL. Nastudováno takříkajíc v originále. Hledal, oslovoval, hledal zdrojové kódy. Znovu a znovu.

Je známo, že v různých dobách sada komponent dodávaných s Delphi obsahovala komponenty třetích stran, které měly vyplnit mezery ve VCL a které pravděpodobně prošly nějakým druhem kontroly kvality, než byly zahrnuty. Některé z těchto komponentů jsou dodávány dodnes. Vezměte si stejného Indyho. Nechci nikoho urazit, je to čistě můj osobní názor, který platí i pro mě jako vývojáře komponent: ani jedna sada nebyla tak hluboce promyšlena a implementována, jako obrovský a rozmanitý VCL. Ne, nepředstírám, že jsem konečná pravda, a samozřejmě v samotném VCL je mnoho chyb, rozhodnutí, která způsobují nedorozumění, způsobují odmítnutí a se kterými chcete nesouhlasit. Vždy jsem ale nabyl dojmu určitého jediného stylu. Ve VCL je podle mého názoru krásné a silné jádro, které podporuje celý design Delphi a kolem kterého je postavena jak softwarová infrastruktura, tak samotná vývojářská komunita. Z velké části díky VCL, opět, podle mého názoru, zvěsti o smrti Delphi jsou stále fámy. A když byly součástí dodávky VCL komponenty třetích stran, bylo to okamžitě patrné, byly jiné.

Ale pak přijde chvíle a slyším, že VCL je technologie, která je zastaralá. Technologie, která by měla zůstat v minulosti. Vývojáři by měli implementovat všechny své nové projekty na FireMonkey, ale o těch starých ... bylo by hezké je přenést do nových kolejí. FireMonkey je všude a vždy. A slyším to z různých zdrojů. A docela vytrvale. Ne, nikdo nezabije VCL. zůstává s námi. Už ale není jedničkou. Měl by být náhradníkem. Alespoň tak chápu, co se o budoucnosti produktu říká.

V zásadě toto zarovnání chápu. Byl absolvován kurz pro multiplatformní, a co je důležitější, pro multiplatformní. Koneckonců, co je VCL? Knihovna vizuálních komponent. Knihovna vizuálních komponent. S tím možná nebudete souhlasit. Například jsem vždy považoval mnoho nevizuálních komponent, nikoli komponent, ale pouze tříd, za nedílnou součást VCL a obrovské množství tříd a komponent třetích stran - pokračování, rozšíření VCL . No, nemohu považovat dědice TDatasetu za součást VCL. I když například termín DBExpress Library říká, že to jakoby není VCL. Embarcadero zřejmě skutečně rozděluje monolitické, z mého pohledu VCL, na řadu samostatných knihoven. Ne, samozřejmě, ne zcela odděleně, ale přesto. A pokud se podíváte na tento úhel pohledu, FireMonkey má nahradit vizuální část VCL (jak bych měl stále nazývat kompletní knihovnu tříd a komponent, možná Borland Component Library?).

Na jakých vizuálních komponentách knihovny jsou postaveny? Kolem nízkoúrovňových základních prvků poskytovaných operačním systémem. Kliky oken, písma, samotná okna, vstupní prvky, zprávy, kontexty zařízení a mnoho dalšího – to nejsou koncepty knihovny, která je součástí Delphi, ale koncepty operačního systému. Ano, správně, Windows. A pokud chcete vybudovat multiplatformní knihovnu, pak je logické odmítnout infrastrukturu nabízenou operačním systémem, který spouští program napsaný pomocí knihovny.

Přesně o to se FireMonkey snaží. Snaží se vytvořit infrastrukturu založenou na základních mechanismech podporovaných různými operačními systémy, které mohou nahradit službu, kterou operační systémy samotné nabízejí.

Mnozí si pamatují, že se snažili vyrobitmultiplatformní nejen knihovnu, ale i samotné Delphi. Paralelně s Delphi 6 byl vydán produkt Kylix a knihovna CLX. To vše bylo provedeno proto, aby bylo možné vyvíjet pro Linux. Linux však nemá mnoho základních konceptů vytváření oken GUI, které má Windows. Rozhraní okna pro Linux obecně není přirozeným jevem. Toto je volitelná aplikace. A musel jsem napsat nějakou syntetickou knihovnu. S jeho pomocí bylo možné napsat program pro Windows i Linux. Dodnes si však pamatuji ten pocit, nikoli zklamání, spíše nepříjemného nepohodlí, které jsem zažil, když jsem se pokusil použít analogy vizuálních komponent z CLX. Začalo mi hodně chybět. To, co jsem při vývoji pomocí VCL dělal bez přemýšlení, se ukázalo jako obtížné, velmi odlišné nebo prostě nemožné pomocí CLX.

Při přechodu z BDE na DBExpress jsem se cítil přibližně stejně. Starý, známý z Field Test-a BDE (Borland ho už tehdy používal v Quattro Pro pro Windows a v Paradoxu pro Windows a jmenovalo se to ODAPI, a pak IDAPI a byl to ořez výše, podle mého názoru, ODBC od Microsoftu) prohlásil za zastaralou technologii, která by měla v nových projektech ustoupit nové knihovně. Vždy mi v DBExpressu zpočátku něco chybělo, hlavně znalosti.

Zároveň nechci v žádném případě nadávat ani kritizovat výše uvedené knihovny ani rozhodnutí, která vedla k jejich vzniku. Je to jen o mých dojmech, někdy i prvních dojmech.

Nyní je možná trochu jasnější, proč rozhodnutí napsat malý pracovní projekt pomocí FireMonkey přineslo řadu problémů. Dlouhá léta se ve vývoji projektů, projektů a projektů utvářel určitý stereotyp, určitá šablona, ​​co a jak dělat. A v mém případě jsem musel čelit tomu, že je potřeba změnit šablonu. Protože vše, na co jste zvyklí používat VCL, nemůžete přenést do projektu postaveného na FireMonkey.

Na začátku projektu jsem zažil určitý pocit deja vu. Totiž pocit nepohodlí. Například obvyklé vstupní prvky nemají mnoho vlastností. Triky, které se v praxi pevně usadily, založené na tricích souvisejících se znalostí některých vlastností operačního systému, v novém kontextu nefungují. Nemluvě o tom, že některé komponenty se radikálně změnily.

No, další důležitá nuance. Jaké projekty se obvykle musí dělat v práci, pokud to (práce) nesouvisí s psaním kompilátorů, modelováním systémů nebo čímkoli jiným vysoce vědeckým? Myslím, že pro většinu je to o vývoji něčeho, co zahrnuje používání databází. Navíc, něco vysoce vědeckého může také využít služeb poskytovaných DBMS.

Zde mě čekala další přepadení. Z nějakého důvodu, když v praxi narazíte na to, že FireMonkey neobsahuje prvky zaměřené na práci s daty uloženými v databázi, nejste na to tak úplně připraveni (mírně řečeno). I když už jsem o tom četl mnohokrát a víte (teoreticky), co byste měli použít. Řeč je o Live Bindings.

Nechci se pouštět do sporu o to, zda by skuteční cool programátoři měli používat komponenty s vědomím db nebo neměli zobrazovat, upravovat a nakonec ukládat. Což opět není ani špatné, ani dobré. Mně se to tak prostě stalo.

Tímto končím můj příspěvek o prvních dojmech. Další na řadě jsou příběhy o tom, co a jak při práci na projektu překonali.