2013. 03. 06. 12:46

Nagyon szenvedtem a FireMonkey böngésző összetevőjének hiánya miatt. A jól ismert Delphi Chromium Embedded projekt még mindig tartalmazta az FMX támogatást a legújabb buildben. De annak ellenére, hogy elég sok idő telt el, a szerző nem siet az FMX2 támogatásával. Végül a kezembe kellett vennem a helyzetet.

A hivatalos összeállításból származó TChromiumFMX komponens elég jól működik FireMonkey-ban (XE2-ben), de még FMX2-ben sem fordítódik le. Kicsit rá kellett jönnöm, hogyan működik, és javítanom kellett. Szerencsére komoly változtatásokra nem volt szükség.

Az FMX2-ben két dolog változott, amire az összetevőnek szüksége van.

Először is, a TBitmap már nem rendelkezik ScanLine és StartLine tulajdonságokkal. A TBitmap tartalmához való közvetlen hozzáférést újratervezték (vajon miért?) és már elérhető a TBitmapData osztályon keresztül, amely a TBitmap.Map metódust adja vissza.

Nos, a második, ismertebb - a Platform .* már nincs meg, most a TPlatformServices.GetPlatformService-en keresztül kell beszerezni a szükséges felületet. Itt minden nagyon egyszerű, és nincs probléma.

Nem teszteltem különösebben kreatívan, de az én céljaimra az összetevő teljesen megfelelő - megtekintheti a webhelyeket rajta keresztül. Töltsd le. Valószínűleg elküldöm a szerkesztéseimet a szerzőnek is, aki esetleg szükségesnek tartja, hogy kiegészítse azokat a hivatalos verzióval.

2012.07.30. 02:43

Jason Southwell FireMonkey burkolókészlet kifejlesztését javasolja natív Windows/OSX vezérlőkhöz, és pénzt gyűjt erre. Kezdésként 20 ezer dollár összegyűjtését tervezi.

Az ötlet egyértelmű. A meglévő FireMonkey komponensek a Delphi segítségével szinte a semmiből jelennek meg, ami egyrészt nagyrészt biztosítja a platformok közötti funkcionalitásukat, másrészt ennek eredményeként olyan komponenseket kapunk, amelyek nem tűnnek teljesen természetesnek mindkét jelenleg támogatott operációs rendszerben. . És ez nem is olyan rossz - a megjelenés mellett önállóan kell fejlesztenie ezeknek az összetevőknek a logikáját. Például a RichEdit meglehetősen összetett; logikáját saját kezűleg megismételni a FireMonkey-ban nem triviális feladat. A VCL és a CLX sem találta fel újra a kereket, hanem egy készet használt.

Most jön a rossz hír. Futás közben minden működik, de nem találtam módot arra, hogy hozzáadjam az új laptípusomat az Items Designerhez. És úgy tűnik, hogy minden listavezérlőnél ugyanaz a probléma: TListBox, TGrid stb. Eleinte nagyon tetszett a megvalósításuk megközelítése, de mostanra még ezt is kétlem. Egy internetes keresés kimutatta, hogy nem vagyok egyedül ezzel a problémával.

A súgó néma, én sem találtam semmit a kódban. Tényleg nincs mód? Ez rendkívül kellemetlen lenne.

Több mint három év telt el azóta, hogy az olyan világhírű eszközök, mint a Delphi, C++Builder és JBuilder, valamint az Interbase adatbázis-kezelő rendszer létrehozásáért felelős CodeGear részleg az eszközeiről ismert Embarcadero Technologies részévé vált. az adatbázisok tervezésére és adminisztrációjára , valamint két éve, hogy lapunk oldalain megbeszéltük, hogy mire számíthatunk az orosz fejlesztők körében oly népszerű eszközök fejlesztésében. David Intersimone-t, az Embarcadero Technologies fejlesztői kapcsolatokért felelős alelnökét és vezető evangélistát, valamint Kirill Rannev-et, az Embarcadero Technologies képviseleti irodájának vezetőjét megkértük, hogy beszéljenek arról, milyen újdonságok történtek ezen a területen az elmúlt két évben, és mire számíthatunk a közeljövőben, Oroszországban. Tájékoztatjuk legfiatalabb olvasóinkat, hogy nem ez az első interjú, amit David és Kirill ad a ComputerPressnek – együttműködésünk már második évtizede tart. Körülbelül ugyanennyi éve rendszeresen publikálunk adatbázis-kezelő eszközök ismertetőit, amelyekben nagy figyelmet szentelnek az Embarcadero termékeknek.

ComputerPress: David, az ön részlege három éve az Embarcadero része. Két évvel ezelőtt lelkesedtél, hogy egy olyan cég részévé válj, amely közel áll a céljaidhoz és szellemiségedhez. Változott valami ezalatt az idő alatt? Ön és kollégái még mindig ugyanolyan lelkesek?

Igen, még mindig nagyon lelkes vagyok. A fő változás, ami azóta történt, hogy az Embarcadero cég részévé váltunk, hogy rengeteget fektettek a Delphi fejlesztésébe. Nőtt a fejlesztői eszközökön dolgozók száma, nőtt azoknak a technológiáknak a száma, amelyeket fejleszteni tudunk, vagy szükség esetén beszerezhetünk.

A RAD Studio XE 2 kiadása, amelyet Moszkvában tervezünk bemutatni, ennek a terméknek a legnagyobb kiadása, hatalmas képességekkel és számos támogatott platformmal a Delphi első verziója óta, amelyet a Windows 16 bites verziójához készítettek. amely egy innovatív termék volt, amely egyesítette a komponens megközelítést és a fordítást gépi kódba. Most már nem csak Windowsra, hanem Macintoshra is támogatjuk a fejlesztést, nem is beszélve a webfejlesztésről és az alkalmazások létrehozásáról mobil eszközök, és ezek az alkalmazások különböző platformokhoz egyetlen kóddal rendelkezhetnek.

Az új fejlesztői platform, a FireMonkey az Embarcadero és a nemrég felvásárolt, UlanUde-ben működő orosz KSDev cég együttműködése, amely vektorgrafikus komponenseket, DirectX-et és OpenGL-t, grafikus effektus-technológiákat és Delphi-komponenseket gyárt. GPU a PixelShader 2.0-val. Egy éve megvásároltuk a KSDev céget (lásd ksdev.ru), és elkezdtük együttműködések egy többplatformos fejlesztőeszköz létrehozása, amely magában foglalja a FireMonkey alkalmazásfejlesztő platformot Delphi és C++Buider komponensekkel az alkalmazások felhasználói felületének létrehozásához, adatbázis-integrációhoz, GPU grafikus feldolgozáshoz és operációs rendszer integrációhoz.

A FireMonkey segítségével létrehozhat egy olyan alkalmazást, amely a CPU-n és a GPU-n együtt fut, majd különböző fordítók és futásidejű könyvtárak (RTL) segítségével lefordíthatja azt Windows, Mac OS vagy iOS rendszerre. Ahelyett, hogy megtanulnának programozni különböző grafikus könyvtárak használatával, megtanulnák a különböző platformok API-it, amelyek eltérő koordinátarendszerekkel és eltérő képességekkel rendelkeznek, a Delphi és a C++Builder fejlesztői ugyanazt a komponens alapú megközelítést használhatják, vizuálisan szerkeszthetik az űrlapokat és kapcsolódhatnak adatbázisokhoz. az alkatrész mozgatása az egérrel. Ez egy alapvetően új módja a különböző platformokon futó alkalmazások létrehozásának, és ez a jövő. Ha más operációs rendszerek és platformok támogatását szeretné hozzáadni az alkalmazásához, akkor nem kell újra megterveznie és fejlesztenie, csak újra kell fordítania.

Új fordítókat hozunk létre, amelyek natív kódot generálnak. Ma már léteznek 32 és 64 bites Delphi fordítók Windows verziók, 32 bites Mac verziók OS 10. Dolgozunk a Delphi és a C++Builder fordítók következő generációján, amelyek lehetővé teszik, hogy nagy teljesítményű natív kódot hozzon létre mind ezekre, mind más platformokra, például Androidra vagy Linuxra, és ugyanazt a dizájnt, ugyanazt összetevők, ugyanaz a kód különböző fordítók és futásidejű könyvtárak használatával.

Amint látja, van elég okom a lelkesedésre. És a fejlesztők, akikkel világszerte találkozom, tudják, hogy az Embarcadero sokat fektet a Delphibe és a C++Builderbe, valamint a PHP fejlesztőeszközökbe.

KP: Milyen sikereket ért el a két cég eszközeinek integrálása terén az elmúlt két évben? Mik az Embarcadero tervei a jövőben ezen a területen?

DI.: Abban az időben, amikor a CodeGear az Embarcadero részévé vált, a cégnek Torontóban, Monterreyben és Romániában volt fejlesztőcsapata, mi pedig Scotts Valley-ben és Oroszországban, Szentpéterváron voltunk és vagyunk. Az Embarcaderonak voltak eszközei a fejlesztők és adatbázis-adminisztrátorok számára, a CodeGearnél az alkalmazásfejlesztéshez, de utóbbiak adatbázisokat is használnak. A cégek összevonása a szakértelem, az adatbázisok területén szerzett tudás, a kódoptimalizálás, ezen belül a szerverkód kombinációja. A cégek összefogása egy új termék, az AppWave létrehozásához is vezetett, amely egy speciális technológia, amellyel egy szokásos Windows-alkalmazást nagyon könnyen használhatóvá (például iPhone-ra vagy más eszközökre) lehet átalakítani. Az AppWave lehetővé teszi, hogy ne telepítsünk egy alkalmazást, hanem egyszerűen kiválasztjuk és elindítjuk az előkészített alkalmazástároló szerverről (app), és a rendszer a felhasználó számítógépén lefut anélkül, hogy módosítaná a rendszerleíró adatbázisát és a rendszer fájlrendszerét. Az AppWave alkalmazásböngésző egyébként Delphiben van írva. Az Embarcadero a Dephit használja saját fejlesztéséhez és alkalmazásfejlesztési szakértelméhez.

által létrehozott iPhone (iOS) alkalmazás
a FireMonkey platform használatával

A fejlesztői eszközeink és a DB Optimizer integrációját is használhatja az SQL lekérdezések optimalizálására alkalmazások létrehozásakor. Az SQL kód közvetlenül a DB Optimizerbe való átadásával profilozhatja, tesztelheti, és visszaküldheti az optimalizált verziót a fejlesztői környezetbe. Az Embarcadero adatbázis-szakértelme a DataSnap technológiát is továbbfejlesztette. A torontói fejlesztőknek köszönhetően sok ismeretet szereztünk a többrétegű rendszerek és adatbázisok architektúrájáról. Jelenleg mindkét vállalatnál közös szakértelemmel rendelkezünk a szerverkód és a tárolt eljárások létrehozásában. Olyan eszközökkel rendelkezünk, mint a RapidSQL és a DB Change Manager, valamint olyan fejlesztői környezeteink, amelyek leegyszerűsítik a szerverkód létrehozását – például a Code Insight és Code Completion technológiák lehetővé tették az SQL insight és SQL Completion technológiák létrehozását. A kliens- és szerverkód létrehozásának közös megközelítése, közös filozófiánk lehetővé teszi, hogy közös vonásokat adjunk az adatbázis-kezelő eszközöknek és az alkalmazásfejlesztő eszközöknek.

Kirill Rannev: Egy fontos dolgot szeretnék hozzátenni. Kereskedelmi szempontból nagyon fontos, hogy hogyan szállítjuk eszközeinket. Például az új RAD Studio XE 2 Ultimate kiadás tartalmazza a teljes DB Power Studio eszközkészletet. Ez egy nagyon hatékony eszközkészlet, beleértve a RapidSQL lekérdezésfejlesztő környezetet, a DB Change Manager változáskezelő eszközt és a DB Optimizer lekérdezésoptimalizáló eszközt, amely lehetővé teszi a fejlesztési és üzembe helyezési folyamat fontos részének végrehajtását a módosítások kezelésével. az adatmodell, adatbázis, kód stb. Ez a technológiák nagyon jó és helyes kombinációja.

DI.: De ha szükséges, a fejlesztők használhatják a Subversion-t a forráskód-verzióhoz és a DB Change Manager-t a metaadat-verzióhoz. A kódprofilozást és a DB Optimizert használhatja a kiszolgálókód optimalizálására, a RapidSQL-t a kiszolgálókód összeállítására és hibakeresésére, a fejlesztői környezeteinket pedig az alkalmazások készítésére és hibakeresésére. Ez a technológiai kombináció a RAD Studio XE-ben Ultimate Edition bemutatja az adatbázis- és alkalmazásfejlesztési modellek párhuzamait. A Delphi és C++Builder segítségével üzleti alkalmazásokat készítő fejlesztők többsége adatbázisokkal dolgozik, és szüksége van ezekre az eszközökre, a RAD Studio XE Ultimate Edition pedig nagyszerű kombináció az ilyen fejlesztők számára.

KP: Modern felhasználó- ez már nem csak a Windows platform felhasználója. Mobil eszközöket használunk, iPhone, iPad, Android platformon alapuló eszközöket. Ez azt jelenti, hogy a fejlesztőknek meg kell kezdeniük a különböző platformok megcélzását anélkül, hogy jelentősen növelnék a képzési befektetéseket – vagyis univerzális eszközökre van szükség. Nyilvánvalóan irreális a platformgyártóktól univerzális eszközöket várni, és ebben a kérdésben csak független szerszámgyártókra számíthatunk. Hogyan számíthatunk az Embarcaderóra?

DI.: A platformtámogatás terén még sok tennivalónk van. A mai napon bevezetjük az iOS platform támogatását iPhone-ra és iPadre, majd az Android platformra épülő okostelefonok, a Windows 7 és a Blackberry megkapják a támogatásunkat. A RAD Studio XE 2-ben a FireMonkey platform iOS-re való kiépítésével kezdtük, majd a FireMonkey-t más platformokra is elhoztuk.

Ugyanakkor számos operációs rendszer támogatja érintőképernyők(érintőképernyő), telefonokhoz, táblagépekés asztali eszközöket, és továbbra is támogatjuk őket. Ezen kívül van hang, mozgás, biometrikus rendszerek, gyorsulásmérők, ezért folytatnunk kell a FireMonkey bővítését, hogy minden fejlesztő kihasználhassa az új platformok előnyeit. Például a Microsoft Kinect eszközt Xbox 360-hoz tervezték, és most már létezik egy megfelelő SDK (Software Development Kit) a Windowshoz. És már vannak példáink arra, hogy mozgást használunk egy alkalmazás vezérlésére, ugyanúgy, ahogy az egeret vagy a billentyűzetet általában használnák.

Ha sok összetett grafikát tartalmazó alkalmazást hoz létre, új felhasználói felületek egész világát hozza létre. Ha a Windows operációs rendszerről van szó, akkor annak Windows API-ját a VCL könyvtárba foglaljuk (Visual Component Library - vizuális komponensek könyvtára, amely a Delphi és a C++Builder fejlesztőeszközök része. - jegyzet szerk.), amely egyébként tovább használható. A FireMonkey-ban pedig beágyazzuk az operációs rendszer API-t. De manapság sokkal szélesebb körben kezeljük a formákat és a grafikákat. Fizikai tulajdonságokat is hozzáadhat a térhez animáció és speciális effektusok számára. Ezen kívül rengeteg más is létezik további jellemzők olyan felhasználói felületek létrehozására, amelyeket a következő években fogunk megvalósítani különböző platformokon, mobil- és táblagépeken.

A Microsoft nemrégiben közölt részleteket az egy év múlva megjelenő Windows 8-ról. Támogatni fogjuk ezeket az újításokat a VCL könyvtárban és a FireMonkey platformon. A Delphi azonban nem csak Windowsra, hanem Macintoshra, iPhone-ra és iPadre is tervezett fejlesztőeszköz. Emellett PHP-termékeinket is fejlesztjük, támogatjuk a jQuery Mobile-t, az iOS API-t használjuk mobil kliens alkalmazások fejlesztésére, valamint szerveroldali PHP-alkalmazásokat készítünk varázslók és eszközök segítségével kliensoldali JavaScript, HTML és lépcsőzetes stíluslapok generálásához. Csomagokat készíthetünk belőle PHP alkalmazásokés natív kóddal rendelkező ügyfélalkalmazások iPhone iOS, és egy ilyen kliens kommunikál a PHP szerverrel. Ő pedig kommunikálni fog az adatbázis-kiszolgálóval és a webszolgáltatásokkal - mindennel, ami az üzlethez szükséges.

RadPHP XE2 fejlesztői környezet. Mobil webalkalmazás készítése
jQuery Mobile komponensek használatával iPhone 3G-hez

Vagyis a FireMonkey és a VCL képességeinek bővítését tervezzük, beleértve a mobil platformok támogatását is.

KP: Mondana többet a FireMonkey platformról?

DI.: Ahogy már megjegyeztem, a Windows számára létrehozott VCL-könyvtár tovább fog fejlődni és javulni fog. De ma, ha valódi üzleti alkalmazásfejlesztést szeretne, akkor különböző platformokra kell létrehoznia azokat. Erre tervezték a FireMonkey platformot. Támogatja a nagyfelbontású felhasználói felületek, a nagy teljesítményű 3D-s grafika, a nagy képkockasebesség létrehozását, és ami fontos, ehhez a grafikus processzort használja.

Ezeket a képességeket tudományos, mérnöki és üzleti alkalmazások létrehozásakor használhatja. Az ilyen alkalmazások a dbExpress technológiával kapcsolódhatnak adatbázisokhoz, továbbra is a fejlesztők számára ismert nem vizuális komponenseket használva, mint például a ClientDataSet vagy a DataSource, használhatják a DataSnap technológiát, csatlakozhatnak bármilyen adatbázishoz, SOAP és REST szerverekhez. Létrehozhat vonzó vezérlőket, dobozos gombokat, szokatlan táblázatokat és egyéb interfészelemeket, két- és háromdimenziós változatban. A kész 3D modellt betöltheti az alkalmazásba, és összekapcsolhatja egy 2D alakzattal, amelyben elforgathatja és különböző szögekből megtekintheti. Létrehozhat adatkockát vagy 3D-s üzleti diagramot, és elforgathatja az egér, a billentyűzet vagy akár egy Kinect eszköz segítségével, vagy beléphet a kocka belsejébe, és belülről nézheti meg annak különböző felületeit. Mindezt pedig nagy sebességű GPU segítségével lehet megtenni. Ugyanez az alkalmazás lefordítható egy másik platformra, például Mac OS-re.

Egy forgó adatkockát tartalmazó alkalmazás,
szélére helyezve

Vagy létrehozhat egy 3D alakzatot a semmiből, és kamerákat és lámpákat használhat a felhasználói felület egyes részei megvilágítására és elforgatására. Az űrlaptervező már rendelkezik egy beépített környezettel, amely támogatja a 3D felhasználói felületet a tervezés során.

Windows rendszeren a Direct2D könyvtárak nagy felbontású 2D grafikával, a Direct3D pedig 3D grafikával dolgozhat. Mac OS rendszeren a Quartz és az OpenGL könyvtárak ugyanazokra a célokra használhatók. iOS esetén a Quartz és az OpenGL ES könyvtárak használatosak. De mindez rejtve van a fejlesztő elől – a FireMonkey platformot, annak koordinátarendszerét és alkalmazásprogramozási felületét használja anélkül, hogy ezekre a könyvtárakra gondolna, és ugyanazt az alkalmazást tudja lefordítani különböző platformokra.

Emlékezzünk, mi az a VCL. A VCL egy komponens burkoló a Windows API körül. Foglalkozunk erőforrásokkal, menükkel, párbeszédpanelekkel, színekkel, stílusokkal, Windows üzenetek. Mivel többplatformos burkoló, a VCL-lel ellentétben a FireMonkey megtartja ugyanazokat az esemény- és komponensmodelleket, lehetővé téve az eseményekben való gondolkodást (például OnClick, OnHasFocus, onMouseDown és onKeyDown események), de kezeli a Macintosh vagy iPhone eseményeket.

A FireMonkey platform is jár hozzá komplett rendszer felhasználói felület elemeinek animációja. Ez természetesen nem egy átfogó Pixar-stílusú animációs rendszer, de lehetővé teszi az olyan effektusokat, mint a bittérképes animáció, a felhasználói felület elemeinek fókuszkiemelése és a vektorgrafika. Több mint 50 áll a fejlesztő rendelkezésére vizuális effektek: elmosódás, a kép fekete-fehérré alakítása, feloldódás, átmenetek, tükröződés, árnyékok létrehozása - mindenféle effektus elérhető a modern grafikus processzorokban, amelyek ma már szinte minden számítógépen megtalálhatók. A FireMonkey platformra épülő alkalmazás parancsokat küld a GPU-nak, amely elvégzi a grafika megjelenítésének és a felhasználói felület létrehozásának minden munkáját. Ebben az esetben a központi processzor szabad a számításokhoz és az operációs rendszer hívásához. A fejlesztő csak megfelelően helyezheti el az összetevőket.

A FireMonkey platform legalapvetőbb dolga a felhasználói felület felépítése. Vannak módok rasztergrafikák elhelyezésére a felület elemeire, például a menükre, gombokra és görgetősávokra. A FireMonkey-nál GPU-val hajtott vektorgrafikát használunk erre a célra. Programozási szempontból ezek még mindig ugyanazok a vezérlők, de a megjelenítésük minden munkáját a grafikus processzor végzi. Alkalmazhatunk stílusokat a vezérlőkre, az alkalmazást úgy nézhetjük ki, mint egy Mac OS vagy Windows operációs rendszer, létrehozhatunk saját stílust, alkalmazhatunk saját stílusokat az interfész elemeire (például egy gombot négyszögletessé vagy kerekíthetünk úgy, hogy megváltoztatjuk a stílusát az űrlapszerkesztőben ) - ehhez Van egy stílusszerkesztő a fejlesztői környezetben. Létrehozhatja saját stílusát, vagy megváltoztathatja egy már kész alkalmazás stílusát.

FireMonkey Platform – Fejlesztői eszközök
és támogatott platformok

Ha emlékszel, a VCL-könyvtárnak korlátozott számú vezérlője volt - konténerek (vagyis lehetővé tette, hogy más elemeket helyezzen el bennük), és a FireMonkey-ban minden vezérlő egy konténer. Ez azt jelenti, hogy minden vezérlő tartalmazhat bármilyen más vezérlőt. Például a legördülő lista elemei tartalmazhatnak képeket, gombokat, szerkesztőmezőket és egyéb vezérlőket. Az alkatrészeket rétegekben is elhelyezheti.

A FireMonkey renderelő rendszer meglehetősen rugalmas - képes használni a Direct2D, Direct3D és OpenGL könyvtárakat, parancsokat küldve a GPU-nak. Ahhoz, hogy a VCL-ben ugyanezt elérjük, külön képernyőn kívüli puffert kellett generálni, a megfelelő grafikus könyvtár függvények meghívásával létrehozni benne egy képet, majd megjeleníteni az űrlapon.

Példák a FireMonkey által támogatott grafikus effektusokra

Ha nem rendelkezik GPU-val, továbbra is alkalmazhat 2D vagy 3D alakzatokat, és használhatja a FireMonkey vezérlőket. Ebben az esetben a FireMonkey platform a GDI+ könyvtárakat vagy más hasonló könyvtárakat használja, és ugyanazokat az effektusokat, animációkat vagy 3D objektumok manipulációját hajtja végre.

A FireMonkey másik jellemzője az interfész elemek és adatok összekapcsolására szolgáló új, nyitott és rugalmas rendszer. A VCL-ben kétféle interfész elem létezik: adathoz kötött és nem adathoz kötött (például TDBEdit és TEdit). A FireMonkey-ban minden vezérlő bármilyen típusú adathoz társítható. Ez lehet egy egyszerű kifejezés, egy adatkészlet mezője, a fejlesztő által létrehozott objektumokból származó adatok vagy a metódushívások eredményei.

Ezenkívül egy alkalmazás létrehozásakor kész 3D-s modellt tölthet bele és használhatja - ilyen képességekre gyakran szükség van üzleti és mérnöki alkalmazásokban is. Van egy ügyfelünk, aki logisztikai alkalmazásokat készít. Delphi segítségével építettek ki információs rendszert, és abban egy olyan alkalmazást, amely tervet rajzolt és adatforrásokból információkat jelenített meg. Nemrég csináltak valami érdekeset - teljesen automatizált 3D raktárt rajzoltak az AutoCAD-ben, és az alkalmazásuk lehetővé teszi, hogy megnézze, hogyan mozog az automata targonca a raktárban, és hogyan helyezi el az árukat a polcokon. És a megfelelő képre felteszik a forrásokból származó adatokat.

Példák az alkalmazásstílusok megváltoztatására

KP: Milyen 3D-s modellformátumok támogatottak jelenleg?

DI.: Ebben a kiadásban támogatjuk az AutoCAD, Collada (nyílt forráskódú 3D modellező eszköz) modellek betöltését. jegyzet szerkeszteni.), Maya, egy OBJ formátum, amelyet számos 3D grafikus gyártó támogat.

KP: Milyen egyéb formátumokat tervez hozzáadni?

DI.: Terveink szerint hozzáadjuk a 3DS-t (3D Studio MAX), az SVG-t (általában ezt a formátumot használják 2D-s vektorgrafikákhoz, de néha 3D-hez), a Google SketchUp-ot. Talán más formátumokat is támogatunk.

KP: A 3D modellek FireMonkey-val épített alkalmazásokban való használatához szükséges a megfelelő 3D modellező eszköz licence?

DI.: Nem, ez nem igényli. Nincs más dolgunk, mint elolvasni a modellfájlt. Importáljuk a modellt, de nem exportáljuk (bár természetesen írhatna egy alkalmazást, ami a modellt saját formátumban menti el). Nem állítjuk magunkat 3D modellező eszközök gyártójának – ehhez használhatja az AutoCAD, 3D Studio Max, Maya vagy bármely más 3D modellező eszközt, és importálhatja a létrehozott modelleket alkalmazásainkba.

KP: Mennyire teljesítenek a FireMonkey-val készített alkalmazások modern hardverplatformokon?

DI.: A termelékenység meglehetősen magas. Például egy 3D-s alakzat három gömbbel és három lámpával való renderelése egy MacBook Pro gépen 100 képkocka/másodperc sebességgel jeleníthető meg. Vagy elérheti a 600-at – ez attól függ, hogy pontosan mit csinálunk. Ismét minden a GPU teljesítményétől függ.

KP: Ez azt jelenti, hogy a FireMonkey segítségével modern játékokat hozhat létre?

DI.: Fejlesztőeszközeinket nem játékeszközként pozícionáljuk. A modern GPU-k nagy teljesítményét kihasználva azonban FireMonkey segítségével is készíthet játékokat – elvégre Direct3D vagy OpenGL segítségével készülnek.

KP: Milyen munkát végez jelenleg a gesztusfelismerés és más újszerű dolgok támogatása terén? Van ilyen támogatás?

DI.: Ebben a kiadásban még nincs kézmozdulattámogatásunk. A FireMonkey egy jövőbeli kiadásában a gesztusvezérlés is megjelenik, de addig is használhatod az operációs rendszerbe épített gesztustámogatást.

Mikhail Filippenko, a Fast Reports, Inc. igazgatója.

K.R.: Azt már elmondtuk, hogy a FireMonkey technológia orosz gyökerekkel rendelkezik - az alapjait hazánkban hozták létre, majd maga a technológia és a fejlesztők is csatlakoztak az Embarcaderohoz. Általában véve örömteli látni az orosz komponens növekedését a RAD Stúdióban és a Delphiben. Ez magában foglalja a szentpétervári fejlesztési központunk tevékenységét és a független orosz fejlesztők közreműködését. Például a Rad Studio XE2 tartalmazza a FastReport jelentéskészítőt - az egész világon ismert és hazánkban is nagyon népszerű. Eredetileg Rostov-on-Donból származik.

KP: A fordítókról szeretnék beszélni. Milyen fordítót használnak iOS alkalmazások létrehozásakor?

DI.: Nincs saját Delphi-fordítónk az iPhone-hoz vagy iPad-hez – még nem fejlesztettünk fordítókat az ezekben az eszközökben használt ARM-processzorokhoz. iOS esetén ideiglenesen a Free Pascal fordítót és futásidejű könyvtárat használjuk. De dolgozunk a fordítók következő generációján, beleértve az AWP processzorokat is. De vannak fordítók a Windows és a Mac OS számára, mivel mindkét hardverplatform Intel processzorokon alapul.

KP: Mi történt a fordítóprogramok készítése terén az elmúlt két évben?

DI.: 32 és 64 bites Delphi fordítóink vannak Windows és Mac OS rendszerekhez. Dolgozunk a Delphi és a C++ fordítók új generációján. Ezek még folyamatban vannak, de ha elkészülnek, lesznek Delphi fordítóink ARM processzorokhoz, Android platformokhoz, Linuxhoz és mindenhez, ami a kettő között van. És lesznek 64 bites C++ fordítóink Windowshoz és más platformokhoz, amelyek kompatibilisek vele legújabb szabvány C++ nyelv, most átvett ISO.

KP: Mi történik ma az Embarcadero fejlesztői eszközeinek felhőalapú számítástechnikai támogatásával?

DI.: A RAD Studio XE 2-ben támogatjuk az alkalmazások Microsoft Azure vagy Amazon EC2 felhőbe való áthelyezését a Platform Assistant segítségével. A Cloud Storage for Azure és az Amazon S3 szerverösszetevői pedig táblák, bináris adatok és üzenetsorok tárolására szolgálnak. BAN BEN előző verzió A RAD Studio XE-vel az alkalmazások Amazon EC2-re történő telepítését is támogattuk, de hiányzott a tárolási támogatás.

Felhőalapú számítástechnikai támogatás a RAD Studio XE 2-ben

KP: Két évvel ezelőtt beszélt az új All-Access megoldásról. Mennyire volt népszerű? Milyen előnyei vannak a rendszerintegrátoroknak és a fejlesztőknek?

DI.: Az All-Access megoldást és az AppWave felhőeszközt széles körben használják szerte a világon. Úgy tervezték, hogy megkönnyítsék saját és harmadik féltől származó alkalmazásaink használatát. Ez alapvetően egy megoldás a licencek és az alkalmazáshasználat kezelésére, és kényelmes a nagyvállalatok számára. Azok a kisebb vállalkozások, amelyek nem rendelkeznek az alkalmazások kezeléséért felelős emberekből álló dedikált csapatokkal, elhelyezhetnek egy alkalmazást egy adattárba, kiválaszthatják a felhasználóneveket egy adatbázisból, és elérhetővé tehetik ezeket az alkalmazásokat anélkül, hogy emlékezniük kellene a licenckulcs helyére vagy a licencek számára. Az All-Access és az AppWave böngészőt úgy tervezték, hogy kezelje a verziószámot és a hozzáférés-szabályozást.

K.R.: A piac annyira sokszínű, a felhasználók pedig annyira különbözőek, hogy lehetetlen minden igényt egy megoldással lefedni. Ezért törekszünk változatos csomagolási megoldásokra. Sokat dolgoztunk azon, hogy egységesítsük a licencelési, licenckezelési és terméktelepítési módszereket. Ez a megoldássor nem csak az Embarcadero termékekhez, hanem bármely más termékhez, így a vállalaton belüli fejlesztésekhez is tartalmaz licenc- és kiépítés-kezelő eszközöket.

A csomagolásfejlesztési eszközökön a felhasználók számára hatékony készletek kialakítása még folyamatban van. Van All-Accessünk – egy szuperkészlet, amely az összes Embarcadero terméket egyesíti. Ha egy ügyfél All-Access Platinumot vásárol, megkapja az Embarcaderoban található összes eszközt. De néha ez a készlet feleslegesnek bizonyul; például az adatbázis-specialisták számára két másik készletet készítettünk - a DB Power Studio Developer Edition és a DB Power Studio DBA Edition. A különbség közöttük az, hogy a fejlesztők számára a RapidSQL-t kínáljuk - a szerverkód fejlesztésére szolgáló eszközt, az adminisztrátornak pedig a beépített DBArtizan - egy adatbázis-adminisztrációs eszköz, amely szélesebb termék, mint a RapidSQL. A szakemberek számára a következő All-Access csomagokat kínáljuk: az összes terméket tartalmazó csomag, a DB Power Studio a fejlesztőknek, a DB Power Studio rendszergazdáknak, az ER Studio Enterprise Edition az építészek és a modellezéssel foglalkozók számára. Vannak kombinációk alkalmazásfejlesztéshez és rendszergazdák számára. A Delphi egy fejlesztői eszköz, és nagyon logikus, hogy SQL fejlesztői és optimalizálási eszközöket adjunk hozzá. Végül a DB Change Manager egy logikai eszköz az adatbázisokban az életciklusuk során bekövetkező változások összetettségének kezelésére.

Így az All-Access a különféle termékkészletekből álló nagy család feje.

KP: Ha nem titok, Oroszországban ki használja az All-Access szolgáltatást?

K.R.: Vannak ügyfeleink, akik a Delphi alapú All-Access szolgáltatást vásárolták meg. Sokan közülük összetett kliens-szerver rendszereket építenek SQL Serverrel és Oracle-lel, és azonnal megkedvelték a platformok közötti adatbázis-eszközeinket. Van egy ügyfélcégünk, amely az első verzió óta használja a Delphit, és egy éve váltottak a Delphi használatáról az All-Access csomagra. Két eszköz, amelyet a cég minden fejlesztője garantáltan használni fog, a Delphi és a DArtisan. És vannak olyan ügyfelek, akik az adatbázis oldaláról érkeztek az All-Acceshez. Fő feladatuk az adatbázisok adminisztrálása, de időnként alkalmazásokat is fejlesztenek. Az All-Access szolgáltatást használó ügyfelek közé tartoznak a médiavállalatok, a mérnöki cégek és más iparágak.

Külön a kis cégekre szeretnék összpontosítani. Nagyon gyakran kis csapatokban a fejlesztő mindent megtesz, és egy ilyen cég néha nagy All-Access termékkészleteket vásárol egy-két fejlesztő számára. Nagy csapatokban nem ösztönzik, hogy egy fejlesztő egyben például adatbázis-adminisztrátor szerepet is töltsön be, így ott általában népszerűek a kis termékkészletek, de kis cégeknél a felelősségek ilyen kombinációja teljesen elfogadható.

A Delphi Architect egy erősen forgalmazott termék, amely modellező és programozó eszközöket is tartalmaz. Az eladott példányszám azonban kevesebb, mint a Delphi Enterprise verzióé, de ez is nagy. Szeretném megjegyezni, hogy 2010-ben mi bizonyultunk a legjobb országnak az értékesítési volumen tekintetében, annak ellenére, hogy minden ország válságot élt át. Ez a növekedés nem annyira gazdasági tényezőkkel függött össze, hanem azzal, hogy a RAD Studio XE 2009 végén megjelent verziója nagyon népszerűnek bizonyult. Egyelőre további értékesítési növekedésre számítunk.

Újabb ésszerű lépést tettünk, amely rendkívül népszerű Oroszországban. Termékeink különböző verzióinak legalizálási foka eltérő: minél magasabb a verzió, annál legalizáltabb, mert korábban szoftver nem olyan aktívan vásárolt. A RAD Studio XE-től kezdve a licenc a 2010-es, 2009-es, 2007-es verziókra, sőt a Delphi 7-re is kiterjed, amely egy széles körben használt termék.

Ma a fejlesztők szembesülnek azzal a ténnyel, hogy új projektjeik és támogatott projektjeik is vannak. Számos projektet migráltak a Delphi korai verzióiról a 7-es verzióra, és továbbra is ezen a verzión belül maradnak, és továbbra is viszonylag kis erőforrásokkal futnak. Senki nem helyezi át őket újabb verziókra, de működőképes állapotban vannak. És most lehetővé tesszük, hogy mind a RAD Studio XE-t, mind a Delphi 7-et kevés pénzért (kevesebb, mint egy Delphi 7 licenc ára) szerezze be - vagyis legalizáljuk a fejlesztőt mind új projektek megvalósításához, mind támogató projektekhez.

KP: Hogyan értékeli az Embarcadero közösség jelenlegi helyzetét?

DI.: Ez a közösség nagy és nagyon igényes. Mindenre azonnal szükségük van – ők fejlesztők. De néha sok időbe telik, hogy valamit jól csináljunk.

Néhány évvel ezelőtt átvettük a Windows komponens architektúrát, és Linux asztali számítógépekre helyeztük. Most látjuk, hogy nem ez volt a helyes döntés. A megfelelő megoldás egy alkalmazásplatform létrehozása. Az alkalmazások még a különböző platformokon is rendelkeznek menükkel, ablakokkal, grafikával, hálózati hozzáféréssel és eszközhozzáféréssel. A különböző platformok eltérő modellekkel rendelkezhetnek a szálak kezelésére vagy a kivételek kezelésére, de ugyanazokat a try blokkokat látjuk az alkalmazás kódjában. A mi feladatunk az, hogy megkönnyítsük a fejlesztők számára az üzleti alkalmazások létrehozását és lefordítását azokra a platformokra, amelyeken használni kívánják őket, függetlenül attól, hogy a megfelelő processzorok utasításkészlete hogyan épül fel, és milyen egyéb jellemzői vannak ezeknek a platformoknak. És a FireMonkey pontosan az, amire szüksége van a probléma megoldásához.

KP: Ha egy vállalat új eszközt hoz létre, és azt szeretné, hogy azt a FireMonkey támogassa, ez lehetséges?

DI.: Az új generációs fordítókkal, amelyek platformfüggetlen front-end és platform-függő hátterűek lesznek, ez teljesen lehetséges lesz. Eközben minden operációs rendszerhez a semmiből készítünk egy fordítót és egy futásidejű könyvtárat.

Minden modern új eszköz jellemzően grafikus felhasználói felülettel (sokan kétmagos CPU és GPU) és szabványos SDK-kkal érkezik a fejlesztők számára. Ez megkönnyíti az eszköztámogatás létrehozását a FireMonkey-ban. Ha az új eszköz csak kétdimenziós grafikákhoz, például a Quartzhoz rendelkezik könyvtárakkal, akkor a FireMonkey-ban is támogatni fogunk egy ilyen eszközt, de ez körülbelül több hónapot vesz igénybe. Sok múlik azonban a platformon: nem minden platform támogatja az összes funkciót, például az iOS nem rendelkezik menükkel és párbeszédpanelekkel, és az ilyen alkalmazások űrlapjain nem lehet megfelelő összetevőket elhelyezni.

KP: Változott valami a partnerekkel való együttműködés politikájában? Mit tesznek annak érdekében, hogy növeljék termékei felhasználóinak arányát? Mi folyik Oroszországban?

DI.: Partneri ökoszisztémánk széles – több száz olyan szerszám- és alkatrészgyártó létezik, amelyek nem találhatók meg termékeinkben, és van technológiai partnerségi programunk. Ezért az alkatrészek, technológiák és eszközök széles skálája áll a fejlesztők rendelkezésére. Az ügyfeleik számára készített megoldások pedig jobbak, mintha csak a mi termékeinket használnák. Az értékesítéshez pedig számos országban vannak irodáink, viszonteladóink és forgalmazóink.

K.R.: Számunkra nem a partnerek száma a fontos, hanem az egyes partnerek munkájának minősége. Egyelőre a meglévő partnerekkel való szoros együttműködésre szeretnénk összpontosítani, bár a partnerek köre továbbra is nyitva áll. Sok partnerünk van, és technikailag is segítenünk kell őket. Fejlesztőkkel dolgozunk, és ők tudják, mit akarnak, és tudják, mi kapható a piacon, és ehhez a partnerek képességeinek is meg kell felelniük.

Vannak olyan üzleti partnereink, akik komolyan fektettek be az Embarcaderóba, mint üzletágba – képzett szakemberekkel, termékeink marketingjével, elkötelezett munkatársakkal, akik felelősek ezért a vonalért, és figyelemmel kísérik, mi történik a termékeinkkel, az árlistával, a marketinggel. Természetesen termékeink értékesítésében sikeresebbek, mint azok a cégek, amelyek alkalmanként értékesítik termékeinket.

KP: David, Kirill, nagyon köszönöm az érdekes interjút. Engedjék meg, hogy kiadványunk és olvasóink nevében további sikereket kívánjak cégének az Ön csodálatos eszközeinek elkészítéséhez, amelyekre a fejlesztőknek oly nagy szüksége van!

Natalia Elmanova kérdései

A FireMonkey az „új Delphi” alaptechnológiája. Kérem, mondja el nekünk ennek az alapvetően új könyvtárnak a céljait, képességeit és technikai vonatkozásait. Egy idő után, visszatekintve, mennyire volt nehéz és indokolt, hogy megtagadta a szupernépszerű VCL továbbfejlesztését?

Ezt választották a Delphi technológia fejlesztésének fő irányának egy konkrét cél elérése érdekében - többplatformos fejlesztés egyetlen környezetből, egyetlen forráskód alapon, a fejlesztők radikális átképzése nélkül. A mára klasszikus és szupernépszerű VCL keretein belül ez lehetetlen volt, a WinAPI-val való kapcsolata túl szoros volt, mondhatni „genetikai szinten”.

A VCL komponensek nem rendelkeztek „absztrakt” réteggel a felület és a megjelenítési mechanizmusok funkcionális szintje között. Funkcionális szint— hogyan viselkedik vezérlőként, milyen eseményekre reagál, milyen felhasználói interakciót biztosít. Kijelző— a platform-orientált vizualizációs módszerek raszteres objektumok és vektorprimitívek által alkotott képként való meghívása. A FireMonkey kezdetben azt az elvet alkalmazta, hogy a vezérlést szigorúan két részre osztotta: „viselkedési” és „vizuális” részre.

Vsevolod Leonov, Embarcadero Technologies

Az első általában nem is a VCL alapjait ismétli meg, hanem az objektum-orientált programozás lényegét. A komponens egy osztály; az összetevő osztályok hierarchiát alkotnak, ahol a családok és a modulok megkülönböztethetők. Egy összetevő osztálya lazán kapcsolódik a megjelenítés módjához.

A vizuális „kép” dinamikusan alakul, nincs mereven beírva a komponensosztályba. A FireMonkey képe vagy "stílusa" az alkalmazás indításakor betöltődik az összetevőbe. Van valamilyen funkcionális keretünk az alkatrészhez, és a „héj” vagy „burkolat” változtatható, de miért? Ez azért van így, hogy a FireMonkey alkalmazások hitelesnek tűnjenek bármilyen platformon – Windows 7, Windows 8, Mac OS, iOS és a közeljövőben Androidon. Ezt a VCL hagyományos monolitikus osztálystruktúrája nem tudta biztosítani.

Itt a technológiai megközelítés kiemelt szerepet játszik. Elvileg meg lehet venni a VCL-könyvtárat és „megtömni” a WinAPI-val és az összes többi lehetséges platformhívással. Ez még mindig megtehető az összetevők nagyon korlátozott részhalmazán, de a VCL több száz összetevőt tartalmaz, így ez a megközelítés egyszerűen „megölheti” a VCL-t. Úgy döntöttek, hogy nem érintik a VCL-t, hanem új képességeket fejlesztenek ki egy új platformon - FireMonkey. Ennek a technológiának még egy bizonyos technikai eleganciája is van - a projekt egy adott platformra való összeállítása során a Delphi IDE csatlakoztatja a szükséges fordítót, és az interfész komponensei platformstílust kapnak.

A felhasználó számára ez egyetlen egérkattintás és ugyanaz a forráskód, a Delphi esetében pedig sok év kemény munkája a fejlesztők részéről egy ilyen többplatformos könyvtár létrehozása.

Amikor világossá vált, hogy a FireMonkey-t külön új platformként vezetik be, a megfelelő együttélési stratégiát kellett választani: az Embarcadero semmilyen módon nem akarta negatívan befolyásolni a VCL felhasználókat. Ezért a következő tervet választottuk: A VCL ideológiailag és építészetileg stabil marad, hogy biztosítsa a lehető legmagasabb kompatibilitást, megkönnyítve a projektek modern verziókba való migrálását. A FireMonkey fejlesztése természetes és párhuzamos utat fog követni, a VCL-re való tekintet nélkül.

Ennek a megoldásnak a gyenge pontja a meglehetősen problémás migráció VCL-ről FireMonkey-re ugyanazon a projekten belül. Egy új projekthez azonban a fejlesztő választhatja a FireMonkey-t, hogy biztosítsa az eredményül kapott alkalmazás többplatformos jellegét. Az iOS-támogatással ellátott XE4 megjelenése után már a Delphi egyértelmű versenyelőnyeiről beszélhetünk a vállalati környezetben történő mobilfejlesztés elindításához, ami a tervezett Android-támogatás megvalósítása után tovább bővül.

Ezért nincs nyilvánvaló „elutasítás” a VCL mint olyan fejlesztésétől. Az új verziókban a Delphi VCL része is fejlődik. Ez magában foglalja a 64 bites támogatást, a vizuális komponensek stílusának bevezetését, a rugalmas dinamikus kapcsolatok vagy „kötés” mechanizmusának megvalósítását, valamint a FireDAC könyvtár beépítését az adatbázisokkal való munkavégzéshez a VCL projektekben. Csak arról van szó, hogy a FireMonkey óriási minőségi ugrásához képest a VCL fejlődése kissé halványnak tűnik. De akárhogy is legyen, a VCL a Delphi szerves része, és az is marad még sok éven át. Bár a platformok fejlődése és a dolgok jelenlegi állása az asztali rendszerek és mobileszközök operációs rendszere terén olyan, hogy a jövő egyértelműen a FireMonkeyé.

Az interjúban már szó esett az iOS támogatásáról, meséljünk olvasóinknak mások támogatásáról legújabb technológiák például a legújabb RAD Studio XE4-ből, például Windows 8 és WinRT, 64 bites rendszerek, MacOS és így tovább. Felsorolnád, mit tud még nyújtani az újításokkal elkényeztetett modern programozónak?

Valószínűleg a modern programozót nem „rontják el” az innovációk. A nagy projekteknél minden „innováció” gyakran gigantikus mennyiségű munkát eredményez.

Például mindenki sokáig várt, sokan azonnal rohantak átvinni a kódjaikat az új platformra. De kiderül, hogy még a nagyon profi csapatok sem állnak készen erre. A 64 bites kód fordítása nem jelenti azt, hogy működik. A „fiatalság bűnei” például 4 bájtos címméretet feltételező utasítások segítségével kezdtek felszínre kerülni. A tesztkultúra hiánya, technológiai felkészületlenséggel párosulva ennek a folyamatnak a rövid időn belüli megvalósítására.

És itt - minél nagyobb a projekt, mondjuk a forráskód sorainak számával mérve, annál körültekintőbbek és kiegyensúlyozottabbak a programozók a különféle újításokkal, kezdve a „gomb” megjelenésétől a felületen a „szintaktikai cukorig” a fordítóprogramban.

Az egyik ilyen „problémás” vívmány a Windows 8 kiadása volt. Személy szerint PC-felhasználóként és csak modern informatikusként nagyon örülök a Windows 8-nak. Ez azonban bizonyos nehézségeket jelent azoknak a fejlesztőknek, akiknek terhelésként Windows 8-at futtató számítógépeket küldtek az új operációs rendszer alatti fejlesztési specifikációkkal.

Ennek az operációs rendszernek az új felületéhez igyekeztünk a lehető legkényelmesebben és fájdalommentesen fejlesztési támogatást nyújtani. Ezért mind a VCL, mind a FireMonkey esetében speciális stílusokat vezettek be, és a programozó vagy újraépítheti az alkalmazás felületét, vagy létrehozhat egy új alkalmazást, amely megjelenésében megkülönböztethetetlen lesz a Windows 8 „natív” alkalmazásától. Természetesen szükség van a Windows 8 „natív” támogatására a WinRT-n keresztül. De itt jön képbe a célok prioritása a modern körülmények között. Mac OS, iOS, Android a közeljövőben még nem teszi lehetővé, hogy a közeljövőben teljes körű támogatásról beszéljünk a WinRT számára.

Az Embarcadero stratégiai célja természetesen a többplatformos. A RAD Studio XE4 kiadása kulcsfontosságú volt, elsősorban az iOS támogatása miatt. A VCL-t használó meglévő programozó órákon belül elkezdheti az iOS-re való fejlesztést. Még egy egyszerű mobilalkalmazás is azonnal hatékony projektté alakítható, amely a meglévő infrastruktúrán belül működik. Ne gondolja, hogy ez csak egy új fordító a FireMonkey számára, és egy új stílus, amely illeszkedik az iOS felületéhez.

Ez magában foglalja az új vizuális tervezőt, a különféle formai tényezők beépített támogatását, az adathozzáférési könyvtárakat, beleértve az új FireDAC-ot, valamint a LiveBindings technológiát a vállalati adatokkal való rugalmas és dinamikus összekapcsoláshoz. Mindezek az újítások egyszerre érkeznek – Windows, Mac OS és iOS rendszerre. Műtőszoba Mac rendszer Az operációs rendszer nem fejlődik olyan gyorsan, így nincsenek olyan problémák, mint például a Windows 7-ről a Windows 8-ra való átállás. De megjelentek a retina kijelzők, és ez különös figyelmet igényelt. Mostantól minden Delphi XE4-ben létrehozott MacOS-alkalmazás automatikusan két stílust tartalmaz: „normál” és „nagy felbontású”.

Hogy. ugyanaz az alkalmazás ugyanazzal a kiváló minőségű „natív” felülettel rendelkezhet bármely Apple asztali számítógépen.

Az Embarcadero nem akarja „meglepni”, „lenyűgözni” vagy akár „szórakoztatni” a fejlesztőket új, innovatív kiadásaival. Éppen ellenkezőleg, az informatikai szféra már tele van különféle meglepetésekkel: új eszközök, új platformok, új felhasználók, új igényeik, új interakciós forgatókönyvek. Adjon hozzá új szoftverfejlesztési technológiákat, és a programozóknak egyszerűen nem lesz idejük új és meglévő rendszereket létrehozni – mindössze annyit fognak tenni, hogy egyik környezetből a másikba, egy régi könyvtárból egy újba, egyik nyelvről a másikra vándorolnak.

De nem vallunk minden új elutasítását. Csupán mindennek a folytonosságát akarjuk biztosítani – kódnak, interfésznek, projektnek, még a szakmai ismereteknek is, amikor új platformok és eszközök jelennek meg. Mondhatnánk, hogy a fejlesztési eszközök egészséges konzervativizmusával küzdünk az egészségtelen konzervativizmus ellen az új platformokat illetően. Ne várjon egzotikus termékeket, nem szabványos programozási nyelveket vagy szokatlan fejlesztőeszközöket az Embarcaderotól.

Nálunk mindig megtalálja a vizuális fejlesztést, a klasszikus nyelveket, a „natív” kódot, és hagyja, hogy az alkalmazásaihoz használt célplatformok, ugyanolyan jól bevált klasszikus módon készültek, újak legyenek.

Mi az a FireMonkey?

A FireMonkey (FMX) a platformok közötti fejlesztés keretrendszere mind asztali rendszerekre (a közeljövőben tervezik a Windows, Mac OS + szervertámogatást Linuxon), mind mobilra (iOS és Android) Delphi/C++ nyelvet használva.

Sajátosságok:

• egyetlen kódbázis minden platformhoz;

• bármely vezérlő (vizuális komponens) lehet tároló (szülő) más komponensek számára;

• nagyon fejlett relatív elrendezés (20 féle) jelenléte az űrlapon;

• A LiveBinding lehetővé teszi bármilyen típusú adat vagy információ csatlakoztatását bármilyen felhasználói felülethez vagy grafikus objektumhoz;

• forma/komponens stílusok jelenléte;

• A Multi-Device Preview lehetővé teszi a vizuális megjelenítés testreszabását az egyes platformokhoz;

• FireUI Live Preview – valós időben jeleníti meg az alkalmazás megjelenését valós eszközökön.

Lehetőségek:

• az egyes platformok natív API-jának használata, valamint a harmadik felek natív könyvtárainak hívásának lehetősége;

• interakció az összes érzékelővel (GPS, gyorsulásmérő, iránytű, Bluetooth (beleértve az LE-t) és mások);

• push értesítések, IoT támogatása;

• aszinkron HTTP kérések támogatása;

• a legtöbb adatbázis támogatása (MsSQL, MySql, Oracle, PostgreSQL, MongoDB stb.);

• a felhőszolgáltatással való munkavégzés (Amazon, Azure);

• Android szolgáltatás támogatása.

Hátrányok (jelenleg):

• a natív osztályok testreszabásához nyújtott támogatás hiánya;

• konkrét dolgok megvalósítása vagy lehetetlen (kütyü, bővítmény (iOS) stb.), vagy egy tamburával táncolni kell (háttérszolgáltatás, sugárzott üzenet stb.);

• A Splash screen (kezdeti képernyő) testreszabása enyhén szólva is hiányzik;

• Az FMX vezérlők saját megjelenítést (vizualizációt, rajzot) használnak, amely pusztán vizuálisan hasonlít a natívhoz;

• a natív vezérlők használata nagy testmozgásokat igényel;

• ha sok a komponens egymásba ágyazása, hihetetlen dolgok történnek: az alkalmazás különböző helyeken összeomlik, elveszti a fókuszt, lefagy stb.;

• egy alkalmazás hibakeresésének információtartalma a mobil platformokon nulla;

• a mobil platformokon előforduló hibák leírása a haszontalan „Error 0x00000X”-re redukálódik;

• az összeállítási idő a legjobb a közepes és nagy projektekhez;

• egy fájl használatának szükségessége a mobilalkalmazások csiszolásához minden platformon;

• nem támogatja az Intel Atom architektúrát;

• nem megfelelő ár a versenytársakhoz képest.

Előnyök:

• mind a termék, mind a közösség nagyon aktív fejlesztése az utóbbi időben, egyre több új technológia támogatása;

• hatalmas számú ingyenes és kereskedelmi komponens jelenléte;

• Az alkalmazás sebessége nagyon közel áll a natívhoz;

• nagyon fejlett vizuális szerkesztő és általában a környezet, stílusok jelenléte;

• Lehetőség van egy alkalmazás tesztelésére Win rendszeren, és csak azután telepíthető az eszközökre, ami nagyban felgyorsítja a fejlesztést;

• mód/platform váltása egy csuklómozdulattal;

• A PAServer egyszerű interakciót biztosít a MacO-kkal az Apple OS-re való fejlesztés során;

• 3D grafika támogatása a dobozból.

Végezetül szeretném elmondani, hogy az elmúlt néhány évben a FireMonkey professzionális eszközzé nőtte ki magát az üzleti alkalmazások és még sok más platformok közötti fejlesztéséhez. Számos hiányosság fokozatosan feloldódik, és minden kiadással modernebbé, önellátóbbá válik a termék, és megszűnik a sokéves stagnáláshoz kapcsolódóan fennálló szkepticizmus magával a Delphi nyelvvel szemben is. Új projekteket írni FireMonkey-ban „biztonságos” és ígéretes.

Elég idő telt el azóta, hogy a FireMonkey kifejezés többé-kevésbé ismertté vált, ha nem is minden fejlesztő számára, de a Delphit használók számára legalábbis. Ez idő alatt megjelentek a FireMonkey-ról szóló könyvek, a FireMonkey-ról szóló cikkek és számos blogon a FireMonkey-ról szóló bejegyzések jelentek meg. Mindezt nagyon érdekes olvasni. De egyetlen elmélet sem helyettesítheti a gyakorlatot. És nekem is, mint sokaknak korábban, meg kellett próbálnom írni valamit a FireMonkey segítségével.

Felmerült azonban egy probléma. Valamilyen oknál fogva úgy döntöttem, hogy csak egy nem túl bonyolult munkaprojektet kell megvalósítanom.

Ahhoz, hogy megmagyarázzam, hogy ez miért jelentett nekem problémát, némi (írásbeli, lírai) kitérésre lesz szükség. Kirándulás a fejlesztői múltamba. Magyarázza meg néhány nézetemet a Delphi programozásáról.

Azt kell mondanom, hogy a Delphi-t Windows 3.1-en kezdtem el használni, vagyis az első verziótól kezdve. És azóta is VCL-t tanulok. Úgymond eredetiben tanulmányoztam. Megnéztem, hozzáfértem, felkutattam a forrásokat. Újra és újra.

Ismeretes, hogy a Delphivel szállított komponensek készlete különböző időpontokban tartalmazott harmadik féltől származó alkatrészeket, amelyek a VCL hiányosságainak pótlására szolgáltak, és amelyek valószínűleg átestek valamilyen minőségellenőrzésen, mielőtt bekerültek volna. Ezen alkatrészek egy részét ma is szállítják. Vegyük ugyanazt az Indyt. Nem akarok senkit megbántani, ez pusztán az én személyes véleményem, ami rám, mint alkatrészfejlesztőre is vonatkozik: még egyetlen készlet sem volt ennyire átgondolt és olyan jól kivitelezett, mint a hatalmas és változatos VCL. Nem, én nem állítom a végső igazságot, és természetesen magában a VCL-ben is sok olyan hiba, döntés van, amely félreértést, elutasítást okoz, és amivel nem akar egyet érteni. De mindig egy bizonyos egységes stílus benyomása volt bennem. Véleményem szerint a VCL-ben van egy gyönyörű és erős mag, amely támogatja a teljes Delphi-dizájnt, és amely köré épül a szoftverinfrastruktúra és maga a fejlesztői közösség is. Véleményem szerint nagyrészt a VCL-nek köszönhető, hogy a Delphi haláláról szóló pletykák továbbra is pletykák maradnak. És amikor a VCL szállítás külső fejlesztőktől származó alkatrészeket tartalmazott, azonnal észrevehető volt, hogy különböztek.

De aztán eljön a pillanat, és azt hallom, hogy a VCL egy elavult technológia. Egy technológia, amelyet a múltban kell hagyni. A fejlesztőknek minden új projektjüket FireMonkey-n kellene megvalósítaniuk, és ami a régieket illeti... jó lenne átvinni őket új pályákra. FireMonkey bárhol, bármikor. És ezt különböző forrásokból hallom. És elég kitartóan. Nem, senki sem öli meg a VCL-t. velünk marad. De már nem ő az első számú. Tartaléknak kell lennie. Én legalábbis így értem, amit a termék jövőjéről mondanak.

Elvileg megértem ezt a helyzetet. Kijelöltük a többplatformos, és ami még fontosabb, a többplatformos irányvonalat. Végül is mi az a VCL? Vizuális komponens könyvtár. Vizuális összetevők könyvtára. Lehet, hogy nem ért egyet ezzel. Például mindig is sok nem vizuális összetevőt, és nem komponenseket, hanem egyszerűen osztályokat tartottam a VCL szerves részének, és rengeteg harmadik féltől származó osztályt és komponenst a VCL folytatásának, kiterjesztésének. Nos, nem gondolhatok a TDataset örököseire a VCL részeként. Bár például a DBExpress Library kifejezés azt sugallja, hogy ez nem egy VCL. Úgy tűnik, az Embarcadero valóban felosztja a monolitikus, az én nézőpontomból a VCL-t számos külön könyvtárra. Nem, persze nem teljesen külön, de mégis. És ha elfogadjuk ezt a nézőpontot, akkor a FireMonkey pontosan a VCL vizuális részét hivatott helyettesíteni (hogyan is nevezzem az osztályok és komponensek teljes könyvtárát, esetleg Borland Component Library?).

Milyen vizuális összetevőket tartalmaz a könyvtár, amelyre épül? Az operációs rendszer által biztosított alacsony szintű, alapelemek körül. Ablakfogantyúk, betűtípusok, maguk az ablakok, beviteli elemek, üzenetek, eszközkontextusok és még sok más – ezek nem a Delphihez tartozó könyvtár fogalmai, hanem az operációs rendszer fogalmai. Igen, pontosan, Windows. Ha pedig többplatformos könyvtárat akarunk építeni, akkor logikus, hogy elhagyjuk a könyvtár segítségével írt programot futtató operációs rendszer által kínált infrastruktúrát.

A FireMonkey pontosan ezt próbálja megtenni. Olyan infrastruktúrát próbálnak létrehozni, amely a különféle operációs rendszerekben támogatott alapmechanizmusokra épül, és képes helyettesíteni azt a szolgáltatást, amelyet maguk az operációs rendszerek kínálnak.

Sokan emlékeznek a próbálkozásraplatformok közötti nemcsak a könyvtár, hanem maga a Delphi is. A Delphi 6-tal párhuzamosan megjelent a Kylix termék és a CLX könyvtár is. Mindez azért történt, hogy Ön Linuxra tudjon fejleszteni. A Linux azonban nem rendelkezik sok olyan alapfogalommal a grafikus ablakfelület tekintetében, mint a Windows. A Linux ablakfelülete általában nem natív jelenség. Ez egy opcionális alkalmazás. És valami szintetikus könyvtárat kellett írnom. Segítségével lehetett programot írni Windowsra és Linuxra egyaránt. Azonban még mindig emlékszem arra a nem csalódás, hanem inkább irritáló kellemetlenség érzésére, amit akkor tapasztaltam, amikor a CLX analóg vizuális komponenseit próbáltam használni. Kezdtem hiányozni sok mindenről. Amit gondolkodás nélkül megszoktam VCL-lel való fejlesztéskor, az nehéznek bizonyult, teljesen másnak, vagy egyszerűen lehetetlennek bizonyult CLX-szel.

Körülbelül ugyanezt éreztem, amikor BDE-ről DBExpressre váltottam. Régi, a Field Test BDE-ből ismerős (Borland már használta a Quattro Pro for Windowsban és a Paradox for Windowsban, és ODAPI-nak, majd IDAPI-nak hívták, és véleményem szerint a Microsoft ODBC felett volt) elavult technológia, amelynek át kell adnia helyét egy új könyvtárnak az új projektekben. A DBExpressben eleinte mindig hiányzott valami, főleg a tudás.

Ugyanakkor semmiképpen sem akarom szidni, kritizálni sem magukat a fentebb felsorolt ​​könyvtárakat, sem a megjelenésükhöz vezető döntéseket. Csak az én benyomásaimról beszélünk, néha az első benyomásokról.

Most valószínűleg egy kicsit világosabbá válik, hogy miért hozott számos problémát az a döntés, hogy egy kis munkaprojektet írunk a FireMonkey használatával. Az évek során a tervek, projektek és tervek kidolgozásakor kialakult egy bizonyos sztereotípia, egy bizonyos sablon, hogy mit és hogyan kell csinálni. Esetemben pedig szembesülnöm kellett azzal a ténnyel, hogy a sablont módosítani kell. Mert nem vihet át mindent, amit a VCL használatához szokott, egy FireMonkey-ra épített projektbe.

Amikor elkezdtem a projektet, átéltem egy bizonyos déjà vu érzést. Mégpedig egy kellemetlen érzés. Például a szokásos bemeneti elemeknek nincs sok tulajdonsága. A gyakorlatban megszilárdult technikák, amelyek az operációs rendszer egyes jellemzőinek ismeretéhez kapcsolódó trükkökön alapulnak, nem működnek új környezetben. Arról nem is beszélve, hogy egyes alkatrészek gyökeresen megváltoztak.

Nos, még egy fontos árnyalat. Általában milyen projekteket kell végeznie a munkahelyén, ha az (a munka) nem kapcsolódik fordítóprogramokhoz, modellezőrendszerekhez vagy bármi más magas tudományos igényhez? Úgy gondolom, hogy a legtöbben valami olyasmit fejlesztenek, amely magában foglalja az adatbázisok használatát. Sőt, valami nagyon tudományos is használhatja a DBMS által nyújtott szolgáltatásokat.

Itt újabb les várt rám. Valamilyen oknál fogva, ha a gyakorlatban szembesülünk azzal, hogy a FireMonkey nem tartalmaz olyan elemeket, amelyek az adatbázisban tárolt adatokkal való munkavégzésre irányulnának, valamiért úgy találjuk, hogy erre (enyhén szólva) nem vagyunk teljesen készen. Bár erről már sokszor olvastam, és tudom (elméletileg), hogy mit kell használni. Élő kötésekről beszélünk.

Nem akarok olyan vitába keveredni, hogy az igazi menő programozók használjanak-e db-tudatos komponenseket vagy ne.A gyakorlatban egy új projekt indításakor szembesültem azzal, hogy mindkettőt meg kell szoknom. új vizuális összetevők és az adatok lekérésének új módja a megjelenítéshez, szerkesztéshez és végső soron mentéshez. Ami megint csak nem rossz és nem jó. Nekem csak így történt.

Ezzel szeretném befejezni az első benyomásokról szóló bejegyzésemet. Következő történetek arról, hogy mit és hogyan sikerült legyőzni a projekten végzett munka során.