03.06.2013 kell 12:46

Ma kannatasin suuresti FireMonkey brauseri komponendi puudumise tõttu. Tuntud Delphi Chromium Embedded projekt sisaldas endiselt uusimas versioonis FMX-i tuge. Kuid hoolimata sellest, et üsna palju aega on möödas, ei kiirusta autor FMX2-le toetust lisama. Lõpuks pidin olukorra enda kätte võtma.

Ametliku koostu TChromiumFMX komponent töötab FireMonkey-s (XE2-s) üsna hästi, kuid ei kompileeri isegi FMX2-s. Pidin natuke aru saama, kuidas see töötab ja parandama. Õnneks suuri muudatusi teha ei tulnud.

FMX2-s on muutunud kaks asja, mida komponent vajab.

Esiteks pole TBitmapil enam ScanLine'i ja StartLine'i atribuute. Otsene juurdepääs TBitmap sisule on ümber kujundatud (huvitav, miks?) ja on nüüd saadaval klassi TBitmapData kaudu, mis tagastab meetodi TBitmap.Map.

Noh, teist, tuntumat – Platform .* enam pole, nüüd tuleb hankida vajalik liides TPlatformServices.GetPlatformService kaudu. Siin on kõik üsna lihtne ja probleeme pole.

Ma ei testinud seda eriti loominguliselt, kuid minu jaoks on komponent üsna sobiv - selle kaudu saate veebisaite vaadata. Laadige see alla. Ilmselt saadan oma muudatused ka autorile, kes võib pidada vajalikuks need ametlikku versiooni lisada.

30.07.2012 kell 02:43

Jason Southwell teeb ettepaneku töötada välja FireMonkey ümbrised Windowsi/OSX-i loomulike juhtelementide jaoks ja kogub selle jaoks raha. Alustuseks plaanib ta koguda 20 tuhat dollarit.

Mõte on selge. Olemasolevad FireMonkey komponendid renderdatakse Delphi abil peaaegu nullist, mis ühest küljest tagab suures osas nende platvormideülese funktsionaalsuse, kuid teisest küljest saame tulemuseks komponendid, mis ei näe mõlemas hetkel toetatud operatsioonisüsteemis päris loomulikud välja. . Ja see pole nii hull - lisaks välimusele peate iseseisvalt välja töötama ka nende komponentide loogika. Näiteks RichEdit on üsna keeruline; selle loogika ise kordamine FireMonkey's ei ole tühine ülesanne. Nii VCL kui ka CLX ei leiutanud ratast uuesti, vaid kasutasid valmis ratast.

Nüüd tulevad halvad uudised. Kõik töötab käitusajal, kuid ma ei leidnud ühtegi võimalust oma uue vahekaarditüübi lisamiseks üksuste kujundajasse. Ja tundub, et kõigil loendi juhtelementidel on sama probleem: TListBox, TGrid jne. Alguses meeldis mulle väga lähenemine nende rakendamisele, kuid nüüd ma isegi kahtlen selles. Internetiotsing näitas, et ma pole selle probleemiga üksi.

Abi vaikib, koodist ka midagi ei leidnud. Kas tõesti ei saa kuidagi? See oleks äärmiselt ebameeldiv.

Rohkem kui kolm aastat on möödunud ajast, kui CodeGeari divisjon, mis vastutab maailmakuulsate tööriistade, nagu Delphi, C++Builder ja JBuilder, ning Interbase'i andmebaasihaldussüsteemi loomise eest, sai oma tööriistade poolest tuntud Embarcadero Technologies osaks. andmebaasi kujundamise ja haldamise jaoks ning kaks aastat pärast seda, kui arutasime oma ajakirja lehekülgedel, mida oodata Venemaa arendajate seas nii populaarsete tööriistade väljatöötamisel. Palusime Embarcadero Technologiesi arendajasuhete asepresidendil ja peaevangelistil David Intersimonel ning Embarcadero Technologiesi esinduse juhil Kirill Rannevil rääkida, mida on selles valdkonnas viimase kahe aasta jooksul uut tehtud ja mida oodata lähitulevikus Venemaa. Meie kõige pisematele lugejatele anname teada, et see pole esimene intervjuu, mille David ja Kirill ComputerPressile annavad – meie koostöö on kestnud juba teist kümnendit. Ja umbes sama palju aastaid oleme perioodiliselt avaldanud andmebaasihaldustööriistade ülevaateid, milles pööratakse palju tähelepanu Embarcadero toodetele.

Arvutipress: David, teie osakond on olnud Embarcadero osa kolm aastat. Kaks aastat tagasi olite entusiastlik, et saite osaks teie eesmärkidele ja vaimule lähedasest ettevõttest. Kas selle aja jooksul on midagi muutunud? Kas teie ja teie kolleegide entusiasm on endiselt sama?

Jah, ma olen ikka väga entusiastlik. Peamine muutus, mis on toimunud pärast Embarcadero ettevõtte osaks saamist, on see, et Delphi arendusse on palju investeeritud. Suurenenud on arendusvahendite kallal töötavate inimeste arv ning kasvanud on tehnoloogiate hulk, mida saame arendada või vajadusel omandada.

RAD Studio XE 2 väljalase, mida kavatseme Moskvas demonstreerida, on selle tohutute võimaluste ja suure hulga toetatud platvormidega toote suurim väljalase alates Delphi esimesest versioonist, mis loodi Windowsi 16-bitise versiooni jaoks ja mis oli uuenduslik toode, mis ühendas komponendipõhise lähenemise ja kompileerimise masinkoodiks. Nüüd toetame mitte ainult Windowsi, vaid ka Macintoshi arendust, rääkimata veebiarendusest ja rakenduste loomisest mobiilseadmed ja neil erinevate platvormide rakendustel võib olla üks kood.

Uus arendusplatvorm FireMonkey on koostöös Embarcadero ja hiljuti omandatud UlanUde-põhise Venemaa firma KSDev, vektorgraafika komponentide, DirectX-i ja OpenGL-i, graafikaefektide tehnoloogiate ja Delphi komponentide tootja. GPU PixelShader 2.0-ga. Omandasime aasta tagasi ettevõtte KSDev (vt ksdev.ru) ja alustasime koostööd luua mitmeplatvormiline arendustööriist, mis sisaldab FireMonkey rakenduste arendusplatvormi koos Delphi ja C++Buider komponentidega rakenduste kasutajaliidese loomiseks, andmebaaside integreerimiseks, GPU graafika töötlemiseks ja operatsioonisüsteemide integreerimiseks.

FireMonkey abil saate luua rakenduse, mis töötab CPU-s ja GPU-s koos, ning seejärel kasutada selle Windowsi, Mac OS-i või iOS-i jaoks kompileerimiseks erinevaid kompilaatoreid ja käitusaegseid teeke (RTL). Selle asemel, et õppida programmeerima erinevate graafikateekidega, õppida erinevate platvormide API-sid, millel on erinevad koordinaatsüsteemid ja erinevad võimalused, saavad Delphit ja C++Builderit kasutavad arendajad kasutada sama komponendipõhist lähenemist, vorme visuaalselt redigeerides ja andmebaasidega ühenduse loomiseks. komponendi liigutamine hiirega. See on põhimõtteliselt uus viis erinevatel platvormidel töötavate rakenduste loomiseks ja see on tulevik. Kui soovite oma rakendusele lisada tuge teistele operatsioonisüsteemidele ja platvormidele, ei pea te seda uuesti kujundama ja arendama – peate selle lihtsalt uuesti kompileerima.

Loome uusi kompilaatoreid, mis genereerivad omakoodi. Tänapäeval on Delphi kompilaatorid 32- ja 64-bitise jaoks Windowsi versioonid, 32-bitine Maci versioonid OS 10. Töötame Delphi ja C++Builderi järgmise põlvkonna kompilaatorite kallal, mis võimaldavad teil luua suure jõudlusega algkoodi nii nendele kui ka teistele platvormidele, nagu Android või Linux, ning säilitada sama kujunduse ja sama komponendid, sama kood, kasutades erinevaid kompilaatoreid ja käitusaja teeke.

Nagu näete, on mul entusiasmiks piisavalt põhjust. Ja arendajad, kellega üle maailma kohtun, teavad, et Embarcadero investeerib palju Delphisse ja C++Builderisse, aga ka PHP arendustööriistadesse.

KP: Milliseid edusamme olete kahe ettevõtte tööriistade integreerimisel viimase kahe aasta jooksul saavutanud? Millised on Embarcadero tulevikuplaanid selles vallas?

DI.: Ajal, mil CodeGear sai Embarcadero osaks, olid ettevõttel arendusmeeskonnad Torontos, Monterreys ja Rumeenias, asume ja asume siiani Scotts Valleys ja Venemaal, Peterburis. Embarcaderol olid tööriistad arendajatele ja andmebaaside administraatoritele, CodeGearil olid tööriistad rakenduste arendamiseks, kuid viimased kasutavad ka andmebaase. Ettevõtete ühinemine on kombinatsioon ekspertiisist, teadmistest andmebaaside vallas, koodi optimeerimisest, sh serverikoodist. Ettevõtete koosmõjul loodi ka uus toode AppWave, mis on spetsiaalne tehnoloogia tavalise Windowsi rakenduse muutmiseks millekski väga lihtsalt kasutatavaks (nagu rakendused iPhone'ile või muudele seadmetele). AppWave võimaldab teil rakendust mitte installida, vaid lihtsalt valida see ja käivitada see ettevalmistatud rakenduste salvestusserverist (rakendusest) ning see käivitatakse kasutaja arvutis ilma selle registris ja süsteemi failisüsteemi piirkonnas muudatusi tegemata. Muide, AppWave rakenduse brauser on kirjutatud Delphis. Embarcadero kasutab Dephit enda arendamiseks ja rakenduste arendamiseks.

iPhone'i (iOS) rakendus, mille on loonud
kasutades FireMonkey platvormi

Samuti saate rakenduste loomisel SQL-päringute optimeerimiseks kasutada meie arendustööriistade ja DB optimeerija integratsiooni. Kui edastate SQL-koodi otse DB optimeerijasse, saate selle profiili teha, testida ja optimeeritud versiooni oma arenduskeskkonda tagasi saata. Embarcadero andmebaaside teadmised on ka DataSnapi tehnoloogiat täiustanud. Tänu Toronto arendajatele saime palju teadmisi mitmetasandiliste süsteemide ja andmebaaside arhitektuuri kohta. Nüüd on meil mõlemas ettevõttes ühised teadmised serverikoodi ja salvestatud protseduuride loomisel. Meil on sellised tööriistad nagu RapidSQL ja DB Change Manager, aga ka arenduskeskkonnad, mis lihtsustavad serverikoodi loomist – näiteks Code Insight ja Code Completion tehnoloogiad võimaldasid luua SQL ülevaate ja SQL Completion tehnoloogiaid. Meie ühised lähenemised kliendi- ja serverikoodi loomisele, meie ühine filosoofia, võimaldavad meil anda andmebaasihaldustööriistadele ja rakenduste arendustööriistadele ühiseid jooni.

Kirill Rannev: Tahan lisada midagi olulist. Kaubanduslikust seisukohast on väga oluline, kuidas me oma tööriistu tarnime. Näiteks uus RAD Studio XE 2 Ultimate väljalase sisaldab täielikku DB Power Studio tööriistakomplekti. See on väga võimas tööriistade komplekt, sealhulgas RapidSQL päringu arenduskeskkond, DB Change Manager muudatuste haldamise tööriist ja DB Optimizer päringu optimeerimise tööriist, mis võimaldab teil läbi viia olulise osa arendus- ja juurutamisprotsessist, haldades muudatusi andmemudel, andmebaas, kood ja nii edasi. See on väga hea ja õige tehnoloogiate kombinatsioon.

DI.: Kuid vajadusel saavad arendajad kasutada Subversioni lähtekoodi versioonide loomiseks ja DB Change Manageri metaandmete versioonide loomiseks. Saate kasutada koodiprofiili ja DB optimeerijat serveri koodi optimeerimiseks, RapidSQL-i serverikoodi koostamiseks ja silumiseks ning meie arenduskeskkondi rakenduste koostamiseks ja silumiseks. See tehnoloogiate kombinatsioon RAD Studio XE-s Ultimate Edition demonstreerib paralleele andmebaasi ja rakenduste arendusmudelite vahel. Enamik arendajaid, kes loovad ärirakendusi Delphi ja C++Builderiga, töötavad andmebaasidega ja vajavad neid tööriistu ning RAD Studio XE Ultimate Edition on sellistele arendajatele suurepärane kombinatsioon.

KP: Kaasaegne kasutaja- see pole enam ainult Windowsi platvormi kasutaja. Kasutame mobiilseadmeid, iPhone, iPad, Android platvormil põhinevaid seadmeid. See tähendab, et arendajad peavad hakkama sihtima erinevaid platvorme, suurendamata oluliselt investeeringuid koolitusse – ehk on vaja universaalseid tööriistu. Ilmselgelt on ebareaalne oodata universaalsete tööriistade tekkimist platvormitootjatelt ja selles küsimuses saame loota vaid sõltumatutele tööriistatootjatele. Kuidas saame Embarcadero peale loota?

DI.: Platvormitoe osas on meil veel palju teha. Täna tutvustame iOS-i platvormi tuge iPhone'ile ja iPadile, seejärel saavad meie tuge Android-platvormil põhinevad nutitelefonid, Windows 7 ja Blackberry. RAD Studio XE 2-s alustasime iOS-i jaoks FireMonkey platvormi loomisega ja seejärel toome FireMonkey teistele platvormidele.

Samal ajal on olemas suur hulk toetavaid operatsioonisüsteeme puutetundlikud ekraanid(puuteekraan), telefonidele, tahvelarvutid ja lauaarvutiseadmed ning jätkame nende toe lisamist. Lisaks on hääl, liikumine, biomeetrilised süsteemid, kiirendusmõõtureid, seega peame jätkama FireMonkey laiendamist, et kõik arendajad saaksid uusi platvorme ära kasutada. Näiteks Microsoft Kinecti seade oli mõeldud Xbox 360 jaoks ja nüüd on Windowsile vastav SDK (Software Development Kit). Ja meil on juba näiteid, kus me kasutame liikumist rakenduse juhtimiseks samamoodi, nagu tavaliselt kasutatakse hiirt või klaviatuuri.

Kui loote palju keeruka graafikaga rakendusi, loote terve maailma uusi kasutajaliideseid. Kui tegemist on Windowsi operatsioonisüsteemiga, kapseldame selle Windowsi API VCL-i teeki (Visual Component Library – visuaalsete komponentide teek, mis on osa Delphi ja C++Builderi arendustööriistadest. - Märge toim.), mida, muide, saab edasi kasutada. Ja FireMonkeysse kapseldame operatsioonisüsteemi API. Kuid tänapäeval manipuleerime kujundite ja graafikaga palju laiemalt. Animatsiooni ja eriefektide jaoks saate ruumi lisada ka füüsilisi omadusi. Lisaks on tohutult palju muid lisafunktsioone luua kasutajaliideseid, mida hakkame lähiaastatel juurutama erinevatele platvormidele, mobiil- ja tahvelseadmetele.

Microsoft avaldas hiljuti üksikasjad Windows 8 kohta, mis peaks ilmuma aasta pärast. Toetame neid uuendusi VCL-i teegis ja FireMonkey platvormis. Kuid Delphi on arendustööriist, mis on loodud mitte ainult Windowsi, vaid ka Macintoshi, iPhone'i ja iPadi jaoks. Samuti arendame oma PHP-tooteid, toetame jQuery Mobile'i, kasutame iOS-i API-d mobiilikliendirakenduste arendamiseks ja loome serveripoolseid PHP-rakendusi, kasutades viisardeid ja tööriistu kliendipoolse JavaScripti, HTML-i ja kaskaadlaaditabelite genereerimiseks. Saame koostada pakke PHP rakendused ja kliendirakendused koos omakoodiga iPhone iOS, ja selline klient suhtleb PHP-serveriga. Ja ta omakorda suhtleb andmebaasiserveri ja veebiteenustega - kõigega, mida äritegevuseks vaja läheb.

RadPHP XE2 arenduskeskkond. Mobiilse veebirakenduse loomine
jQuery Mobile'i komponentide kasutamine iPhone 3G jaoks

Teisisõnu plaanime laiendada FireMonkey ja VCL-i võimalusi, sealhulgas mobiilsete platvormide tuge.

KP: Kas saaksite meile FireMonkey platvormi kohta rohkem rääkida?

DI.: Nagu ma juba märkisin, jätkub Windowsi jaoks loodud VCL-i teegi arendamine ja täiustamine. Kuid täna, kui soovite tõelist ärirakenduste arendamist, peate need looma erinevatele platvormidele. Selleks on FireMonkey platvorm loodud. See toetab kõrge eraldusvõimega kasutajaliideste, suure jõudlusega 3D-graafika, kõrge kaadrisageduse loomist ja, mis kõige tähtsam, kasutab selleks graafikaprotsessorit.

Selliseid võimalusi saate kasutada teadus-, inseneri- ja ärirakenduste loomisel. Sellised rakendused saavad luua andmebaasidega ühenduse dbExpressi tehnoloogia abil, kasutades siiski arendajatele tuttavaid mittevisuaalseid komponente, nagu ClientDataSet või DataSource, kasutada DataSnapi tehnoloogiat, luua ühenduse mis tahes andmebaasi, SOAP- ja REST-serveritega. Saate luua atraktiivseid juhtnuppe, kastidega nuppe, ebatavalisi tabeleid ja muid liideseelemente nii kahe- kui ka kolmemõõtmelisena. Saate laadida rakendusse valmis 3D-mudeli ja ühendada selle 2D-kujuga, mille abil saate seda pöörata ja vaadata erinevate nurkade alt. Saate luua andmekuubiku või 3D-äridiagrammi ja pöörata seda hiire, klaviatuuri või isegi Kinecti seadme abil või astuda kuubi sisse ja vaadata selle erinevaid pindu seestpoolt. Ja kõike seda saab teha kiire GPU abil. Seejärel saab sama rakenduse kompileerida mõnele teisele platvormile, näiteks Mac OS-ile.

rakendus, mis sisaldab pöörlevat andmekuupi,
asetatakse selle servadele

Või saate luua 3D-kujundi nullist ning kasutada kaameraid ja tulesid, et valgustada ja pöörata kasutajaliidese osi. Vormikujundajal on juba sisseehitatud keskkond, mis toetab kujundamise ajal 3D-kasutajaliidest.

Windowsis saate kõrge eraldusvõimega 2D-graafikaga töötamiseks kasutada Direct2D-teeke ja 3D-graafika jaoks rakendust Direct3D. Mac OS-is kasutatakse Quartz- ja OpenGL-i teeke samadel eesmärkidel. iOS-i jaoks kasutatakse teeke Quartz ja OpenGL ES. Kuid see kõik on arendaja eest varjatud – ta kasutab FireMonkey platvormi, selle koordinaatsüsteemi ja rakenduste programmeerimisliidest, mõtlemata nendele teekidele ning saab koostada sama rakenduse erinevatele platvormidele.

Tuletame meelde, mis on VCL. VCL on Windows API ümber olev komponentide ümbris. Tegeleme ressursside, menüüde, dialoogibokside, värvide, stiilidega, Windowsi sõnumid. Erinevalt VCL-ist säilitab FireMonkey sama sündmuste ja komponentide mudelid, mis võimaldab teil mõelda sündmustele (nt OnClick, OnHasFocus, onMouseDown ja onKeyDown sündmused), kuid tegeleb Macintoshi või iPhone'i sündmustega.

Kaasas ka FireMonkey platvorm täielik süsteem kasutajaliidese elementide animatsioon. See ei ole kindlasti kõikehõlmav Pixari stiilis animatsioonisüsteem, kuid see võimaldab selliseid efekte nagu bitmap animatsioon, kasutajaliidese elementide fookuse esiletõstmine ja vektorgraafika. Arendajale on saadaval üle 50 visuaalsed efektid: hägusus, pildi mustvalgeks muutmine, lahustumine, üleminekud, peegeldus, varjude loomine – kõikvõimalikud tänapäevastes graafikaprotsessorites saadaolevad efektid, mida leidub nüüd peaaegu igas arvutis. FireMonkey platvormi kasutades ehitatud rakendus saadab käsud GPU-le, mis teeb ära kogu graafika kuvamise ja kasutajaliidese loomise töö. Sel juhul on keskprotsessor arvutuste ja operatsioonisüsteemi kõnede jaoks vaba. Arendaja saab komponendid ainult õigesti paigutada.

FireMonkey platvormi kõige olulisem asi on kasutajaliidese loomise viis. On olemas vahendid rastergraafika paigutamiseks liidese elementidele, nagu menüüd, nupud ja kerimisribad. FireMonkey's kasutame selleks GPU-toega vektorgraafikat. Programmeerimise seisukohast on tegemist siiski samade juhtelementidega, kuid kogu nende kuvamise töö teostab graafikaprotsessor. Saame rakendada juhtelementidele stiile, muuta rakenduse Mac OS-i või Windowsi rakenduseks, luua oma stiili, rakendada liidese elementidele oma stiile (näiteks muuta nupp ristkülikukujuliseks või ümaraks, muutes selle stiili vormiredaktoris ) - selleks Arenduskeskkonnas on stiiliredaktor. Saate luua oma stiili või muuta juba valmis rakenduse stiili.

FireMonkey platvorm – arendustööriistad
ja toetatud platvormid

Kui mäletate, oli VCL-i teegil piiratud arv juhtelemente - konteinereid (see tähendab, et saate neisse paigutada muid elemente) ja FireMonkey'is on iga juhtelement konteiner. See tähendab, et iga juhtelement võib sisaldada mis tahes muud juhtelementi. Näiteks võivad ripploendi üksused sisaldada pilte, nuppe, redigeerimisvälju ja muid juhtelemente. Samuti saate komponente paigutada kihtidena.

FireMonkey renderdussüsteem on üsna paindlik – saab kasutada Direct2D, Direct3D ja OpenGL teeke, saates GPU-le käske. VCL-is sama asja saavutamiseks tuli genereerida eraldi ekraaniväline puhver, luua sinna vastavaid graafikateegi funktsioone kutsudes pilt ja see siis vormile kuvada.

FireMonkey toetatud graafiliste efektide näited

Kui teil pole GPU-d, saate siiski rakendada 2D- või 3D-kujundeid ja kasutada FireMonkey juhtelemente. Sel juhul kasutab FireMonkey platvorm GDI+ teeke või muid sarnaseid teeke ning teostab samu efekte ja animatsioone või manipuleerib 3D-objektidega.

FireMonkey teine ​​​​funktsioon on uus süsteem liidese elementide ühendamiseks andmetega, avatud ja paindlik. VCL-is on kahte tüüpi liidese elemente: andmetega seotud ja andmetega mitteseotud (näiteks TDBEdit ja TEdit). FireMonkeys saab iga juhtelementi seostada mis tahes tüüpi andmetega. See võib olla lihtne avaldis, andmekogumi väli, arendaja loodud objektide andmed või meetodikutsete tulemused.

Lisaks saab rakendust luues laadida sellesse valmis 3D mudeli ja seda kasutada – selliseid võimeid on sageli vaja nii äri- kui ka insenerirakendustes. Meil on klient, kes loob rakendusi logistika jaoks. Neil oli Delphi abil ehitatud infosüsteem ja selles rakendus, mis koostas plaani ja kuvas andmeallikatest infot. Hiljuti tegid nad midagi huvitavat – joonistasid AutoCADis täisautomaatse 3D lao ning nende rakendus võimaldab näha, kuidas automatiseeritud tõstuk laos ringi liigub ja kaupa riiulitele paigutab. Ja nad panevad vastavale pildile andmed allikatest.

Näiteid rakendusstiilide muutmisest

KP: Milliseid 3D-mudelite vorminguid praegu toetatakse?

DI.: Selles versioonis toetame mudelite laadimist AutoCADist, Colladast (avatud lähtekoodiga 3D-modelleerimistööriist. - Märge muuda.), Maya, OBJ-vorming, mida toetavad paljud 3D-graafika müüjad.

KP: Milliseid muid vorminguid kavatsete lisada?

DI.: Plaanime lisada 3DS (3D Studio MAX), SVG (tavaliselt kasutatakse seda formaati 2D vektorgraafika, aga vahel ka 3D puhul), Google SketchUp. Võib-olla toetame muid vorminguid.

KP: Kas 3D-mudelite kasutamine FireMonkeyga loodud rakendustes nõuab vastava 3D-modelleerimistööriista litsentsi?

DI.: Ei, see ei nõua seda. Kõik, mida me teeme, on mudelifaili lugemine. Me impordime mudelit, kuid mitte ekspordime (kuigi loomulikult võite kirjutada rakenduse, mis salvestab mudeli teie vormingus). Me ei pretendeeri 3D-modelleerimistööriistade tootjana – selleks saad kasutada AutoCADi, 3D Studio Maxi, Maya või mõnda muud 3D-modelleerimisvahendit ning importida loodud mudeleid meie rakendustesse.

KP: Kui tõhusad on FireMonkeyga loodud rakendused kaasaegsetel riistvaraplatvormidel?

DI.: Tootlikkus on üsna kõrge. Näiteks kolme sfääri ja kolme tulega 3D-kujundi renderdamist MacBook Pro puhul saab renderdada kiirusega 100 kaadrit sekundis. Või võib see ulatuda 600-ni - see sõltub sellest, mida me täpselt teeme. Jällegi sõltub kõik GPU võimsusest.

KP: Kas see tähendab, et saate FireMonkey abil kaasaegseid mänge luua?

DI.: Me ei positsioneeri oma arendustööriistu mängude tööriistadena. Kaasaegsete GPU-de suure jõudlusega eeliseid kasutades saate aga FireMonkey abil mänge luua – need on ju loodud Direct3D või OpenGL-i abil.

KP: Millist tööd te praegu teete žestide tuvastamise ja muude uudsete asjade toetamise vallas? Kas selline tugi on saadaval?

DI.: Meil pole selles versioonis veel liigutuste tuge. Liigutuste juhtelemendid lisatakse FireMonkey tulevasse väljalasesse, kuid seni saate kasutada operatsioonisüsteemi sisseehitatud žestide tuge.

Mihhail Filippenko, Fast Reports, Inc. direktor.

K.R.: Oleme juba öelnud, et FireMonkey tehnoloogial on Venemaa juured - selle alused loodi meie riigis ja seejärel liitusid Embarcaderoga nii tehnoloogia ise kui ka selle arendajad. Üldiselt on rõõmustav näha venekeelse komponendi kasvu RAD Studios ja Delphis. See hõlmab meie arenduskeskuse tegevust Peterburis ja sõltumatute Venemaa arendajate panust. Näiteks Rad Studio XE2 sisaldab FastReport aruannete generaatorit - tuntud üle maailma ja väga populaarne meie riigis. Ta on pärit Rostovist Doni ääres.

KP: Tahaksin rääkida koostajatest. Millist kompilaatorit kasutatakse iOS-i rakenduste loomisel?

DI.: Meil ei ole iPhone'i või iPadi jaoks oma Delphi kompilaatorit – me pole veel välja töötanud kompilaatoreid nendes seadmetes kasutatavate ARM-protsessorite jaoks. iOS-i jaoks kasutame ajutiselt Free Pascali kompilaatorit ja käitusaja teeki. Kuid me töötame järgmise põlvkonna kompilaatoritega, sealhulgas AWP-protsessorite jaoks. Kuid Windowsi ja Mac OS-i jaoks on kompilaatoreid, kuna mõlemad riistvaraplatvormid põhinevad Inteli protsessoritel.

KP: Mida on viimase kahe aasta jooksul koostajate loomise vallas tehtud?

DI.: Meil on 32- ja 64-bitised Delphi kompilaatorid Windowsi ja Mac OS-i jaoks. Ja me töötame uue põlvkonna Delphi ja C++ kompilaatorite kallal. Need on veel pooleli, kuid kui need on tehtud, on meil Delphi kompilaatorid ARM-protsessorite, Androidi platvormide, Linuxi ja kõige muu jaoks. Ja meil on Windowsi ja muude platvormide jaoks ühilduvad 64-bitised C++ kompilaatorid uusim standard keel C++, just kasutusele võetud ISO.

KP: Mis toimub Embarcadero arendustööriistade pilvandmetöötluse toega tänapäeval?

DI.: RAD Studio XE 2-s toetame rakenduste teisaldamist Microsoft Azure'i või Amazon EC2 pilve, kasutades Platform Assistantit. Samuti on meil serverikomponendid pilvesalvestuse jaoks Azure'i ja Amazon S3 jaoks tabelite, binaarandmete ja sõnumijärjekordade salvestamiseks. IN eelmine versioon RAD Studio XE-ga toetasime ka rakenduste juurutamist Amazon EC2-le, kuid sellel puudus salvestustugi.

Pilvandmetöötluse tugi rakenduses RAD Studio XE 2

KP: Kaks aastat tagasi rääkisite uuest All-Accessi lahendusest. Kui populaarne see oli? Millised on selle eelised süsteemiintegraatoritele ja arendajatele?

DI.: All-Access lahendus ja AppWave pilvetööriist on laialdaselt kasutusel üle maailma. Need on loodud meie enda ja kolmandate osapoolte rakenduste kasutamise hõlbustamiseks. See on sisuliselt lahendus litsentside ja rakenduste kasutamise haldamiseks ning on mugav suurtele ettevõtetele. Väiksemad ettevõtted, kellel ei ole rakenduste haldamise eest vastutavate inimeste meeskondi, saavad panna rakenduse hoidlasse, valida andmebaasist kasutajanimesid ja teha need rakendused kättesaadavaks, ilma et peaksid meeles pidama, kus on litsentsivõti või kui palju litsentse on. All-Access ja AppWave'i brauser on loodud nii versioonide loomiseks kui ka juurdepääsu juhtimiseks.

K.R.: Turg on nii mitmekesine ja kasutajad nii erinevad, et kõiki vajadusi ühe lahendusega katta on võimatu. Seetõttu püüdleme mitmekesiste pakendilahenduste poole. Oleme teinud palju tööd litsentsimise, litsentside haldamise ja toote installimise meetodite ühtlustamiseks. See lahenduste sari hõlmab litsentsi- ja varustamise haldustööriistu mitte ainult Embarcadero toodete, vaid ka kõigi muude toodete jaoks, sealhulgas ettevõttesisesed arendused.

Töö pakendite arendamise tööriistade kallal tõhusateks kasutajatele mõeldud komplektideks on endiselt käimas. Meil on All-Access – superkomplekt, mis ühendab kõik Embarcadero tooted. Kui klient ostab All-Access Platinumi, saab ta kõik Embarcaderos leiduvad tööriistad. Kuid mõnikord osutub see komplekt üleliigseks; näiteks andmebaasispetsialistide jaoks oleme teinud veel kaks komplekti - DB Power Studio Developer Edition ja DB Power Studio DBA Edition. Nende erinevus seisneb selles, et arendajale pakume RapidSQL-i - serverikoodi arendamise tööriista ja administraatorile on sisse ehitatud DArtizan - andmebaasi haldustööriist, laiem toode kui RapidSQL. Professionaalidele on meil järgmised All-Access komplektid: komplekt, mis sisaldab kõiki tooteid, DB Power Studio arendajatele, DB Power Studio administraatoritele, ER Studio Enterprise Edition arhitektidele ja kõigile, kes on seotud modelleerimisega. Rakenduste arendamiseks ja administraatoriteks on kombinatsioonid. Delphi on arendaja tööriist ja SQL-i arendus- ja optimeerimistööriistade lisamine on väga mõttekas. Lõpuks on DB Change Manager loogiline tööriist andmebaasides nende elutsükli jooksul toimuvate muudatuste keerukuse haldamiseks.

Seega on All-Access suure erinevate tootekomplektide perekonna juht.

KP: Kui see pole saladus, kes kasutab Venemaal All-Accessi?

K.R.: Meil on kliente, kes ostsid Delphi baasil All-Accessi. Paljud neist ehitavad keerukaid klient-serversüsteeme SQL Serveri ja Oracle'iga ning neile meeldisid kohe meie platvormidevahelised andmebaasitööriistad. Meil on klientfirma, kes on Delphit esimesest versioonist saati kasutanud ja aasta tagasi läksid nad Delphi kasutamiselt üle All-Access komplektile. Kaks tööriista, mida kõik selle ettevõtte arendajad kindlasti kasutavad, on Delphi ja DArtisan. Ja on kliente, kes tulid All-Accessi andmebaasi poolelt. Nende põhiülesanne on andmebaaside haldamine, kuid mõnikord arendavad nad ka rakendusi. All-Accessi kasutavate klientide hulka kuuluvad meediaettevõtted, inseneriettevõtted ja muud tööstusharud.

Eraldi tahaksin keskenduda väikeettevõtetele. Väga sageli teeb väikestes meeskondades kõike arendaja ja selline ettevõte ostab vahel ühe-kahe arendaja jaoks suuri All-Access tootekomplekte. Suurtes meeskondades ei soovita arendajal täita ka näiteks andmebaasihalduri rolli, seega on väikesed tootekomplektid seal tavaliselt populaarsed, kuid väikestes ettevõtetes on selline kohustuste kombinatsioon igati aktsepteeritav.

Delphi Architect on tugevalt turustatud toode, mis sisaldab modelleerimis- ja programmeerimistööriistu. Müüdud eksemplaride arv on siiski väiksem kui Delphi Enterprise'i versioonil, kuid see on ka suur. Tahan märkida, et 2010. aastal osutusime müügimahult parimaks riigiks, vaatamata sellele, et kõik riigid kogesid kriisi. Seda kasvu ei seostatud mitte niivõrd majanduslike teguritega, vaid sellega, et 2009. aasta lõpus välja antud RAD Studio XE versioon osutus väga populaarseks. Ja praegu ootame edasist müügikasvu.

Oleme astunud veel ühe mõistliku sammu, mis on Venemaal ülipopulaarne. Meie toodete erinevate versioonide legaliseerimise aste on erinev: mida kõrgem versioon, seda legaliseeritum see on, sest varem tarkvara pole nii aktiivselt ostnud. Alates RAD Studio XE-st hõlmab litsents versioone 2010, 2009, 2007 ja isegi laialdaselt kasutatavat toodet Delphi 7.

Täna seisavad arendajad silmitsi tõsiasjaga, et neil on toetatud nii uusi projekte kui ka projekte. Suur hulk projekte on üle viidud Delphi varasematest versioonidest versioonile 7 ja jäävad sellesse versiooni, töötades jätkuvalt suhteliselt väikeste ressurssidega. Keegi ei teisalda neid uuematesse versioonidesse, kuid neid hoitakse elujõulises olekus. Ja nüüd lubame väikese raha eest (vähem kui Delphi 7 litsentsi hind) hankida nii RAD Studio XE kui ka Delphi 7 – ehk legaliseerime arendaja nii uute projektide elluviimiseks kui ka tugiprojektide jaoks.

KP: Kuidas hindate Embarcadero kogukonna hetkeseisu?

DI.: See kogukond on suur ja väga nõudlik. Neil on kõike kohe vaja – nad on arendajad. Kuid mõnikord kulub palju aega, et midagi õigesti teha.

Paar aastat tagasi võtsime Windowsi komponentarhitektuuri ja panime selle Linuxi lauaarvutitele. Nüüd näeme, et see ei olnud õige otsus. Õige lahendus on rakendusplatvormi loomine. Isegi erinevatel platvormidel olevatel rakendustel on menüüd, aknad, graafika, juurdepääs võrgule ja juurdepääs seadmetele. Erinevatel platvormidel võivad lõimede haldamiseks või erandite käsitlemiseks olla erinevad mudelid, kuid me näeme rakenduse koodis samu prooviplokke. Meie ülesanne on teha arendajatele lihtsamaks ärirakenduste loomine ja nende kompileerimine nendele platvormidele, millel neid kasutada on mõeldud, olenemata sellest, kuidas on üles ehitatud vastavate protsessorite käsustik ja millised on nende platvormide muud omadused. Ja FireMonkey on täpselt see, mida vajate selle probleemi lahendamiseks.

KP: Kui ettevõte loob uue seadme ja soovib, et seda FireMonkey toetataks, kas see on võimalik?

DI.: Uue põlvkonna kompilaatoritega, millel on platvormist sõltumatu esiosa ja platvormist sõltuv taust, on see täiesti võimalik. Vahepeal loome iga operatsioonisüsteemi jaoks nullist kompilaatori ja käitusaja teegi.

Iga uus moodne seade on tavaliselt varustatud graafilise kasutajaliidesega (paljudel on kahetuumaline protsessor ja GPU) ja standardsed SDK-d arendajatele. See muudab FireMonkey's seadmetoe loomise lihtsamaks. Kui uuel seadmel on teegid ainult kahemõõtmelise graafika jaoks, nagu Quartz, saame sellist seadet FireMonkey's toetada, kuid selleks kulub umbes mitu kuud. Palju oleneb aga platvormist: kõik platvormid ei toeta kõiki funktsioone, näiteks iOS-il pole menüüsid ja dialoogibokse ning selliste rakenduste vormidele vastavaid komponente paigutada ei saa.

KP: Kas partneritega töötamise poliitikas on midagi muutunud? Mida tehakse teie toodete kasutajate osakaalu suurendamiseks? Mida Venemaal tehakse?

DI.: Meie partnerite ökosüsteem on lai – meie toodetest ei leidu sadade tööriistade ja komponentide tootjaid ning meil on tehnoloogiapartnerlusprogramm. Seetõttu on arendajatele saadaval lai valik komponente, tehnoloogiaid ja tööriistu. Ja lahendused, mida nad oma klientidele loovad, on paremad kui siis, kui nad kasutaksid ainult meie tooteid. Ja müügiks on meil esindused paljudes riikides, edasimüüjad ja turustajad.

K.R.: Meie jaoks ei ole oluline partnerite arv, vaid iga konkreetse partneri töö kvaliteet. Praegu tahame keskenduda tihedale koostööle olemasolevate partneritega, kuigi partnerite hulk on endiselt avatud. Meil on palju partnereid ja me peame neid tehnoloogia osas aitama. Teeme koostööd arendajatega ja nad teavad, mida tahavad, ja teavad, mis turul on saadaval, ning partnerite võimalused peavad sellega kattuma.

Meil on äripartnerid, kes on Embarcaderosse kui ärivaldkonda tõsiselt investeerinud – nad on koolitanud spetsialiste, meie tooteid turustavad, pühendunud töötajad, kes vastutavad selle liini eest ja jälgivad meie toodetega toimuvat, hinnakirja, turundust. Loomulikult on nad meie toodete müügis edukamad kui ettevõtted, kes meie tooteid aeg-ajalt müüvad.

KP: David, Kirill, tänan teid väga huvitava intervjuu eest. Lubage mul meie väljaande ja meie lugejate nimel soovida teie ettevõttele edu teie suurepäraste tööriistade loomisel, mida arendajad nii väga vajavad!

Natalia Elmanova küsimused

FireMonkey on "uue Delphi" põhitehnoloogia. Palun rääkige meile selle põhimõtteliselt uue raamatukogu eesmärkidest, võimalustest ja tehnilistest aspektidest. Mõne aja pärast tagasi vaadates, kui raske ja õigustatud oli teie keeldumine ülipopulaarse VCL-i edasiarendamisest?

See valiti Delphi tehnoloogia arendamise põhisuunaks konkreetse eesmärgi saavutamiseks - mitmeplatvormiline arendus ühest keskkonnast, mis põhineb ühel lähtekoodi baasil, ilma et oleks vaja arendajate radikaalset ümberõpet. Nüüdseks klassikalise ja ülipopulaarse VCL-i raames oli see võimatu, selle seos WinAPI-ga oli liiga tihe, võiks öelda, et "geneetilisel tasandil".

VCL-i komponentidel ei olnud liidese ja nende kuvamise mehhanismide funktsionaalse taseme vahel "abstraktset" kihti. Funktsionaalne tase— kuidas see käitub juhtelemendina, millistele sündmustele reageerib, millist kasutaja interaktsiooni see pakub. Ekraan— platvormile orienteeritud visualiseerimismeetodite nimetamine teatud kujutiseks, mille moodustavad rasterobjektid ja vektorprimitiivid. FireMonkey rakendas algselt põhimõtet jaotada juhtimine rangelt kaheks komponendiks: "käitumuslik" ja "visuaalne".

Vsevolod Leonov, Embarcadero Technologies

Esimene kordab üldiselt isegi mitte VCL-i põhitõdesid, vaid objektorienteeritud programmeerimise olemust. Komponent on klass; komponendiklassid moodustavad hierarhia, kus saab eristada perekondi ja mooduleid. Komponendi klass on lõdvalt seotud sellega, kuidas see renderdatakse.

Visuaalne “pilt” moodustatakse dünaamiliselt, see ei ole komponendiklassis jäigalt kirjas. FireMonkey pilt või "stiil" laaditakse rakenduse käivitamisel komponenti. Meil on komponendi jaoks mingi funktsionaalne raam ja “nahka” või “vooderdust” saab muuta, aga miks? See on nii, et FireMonkey rakendused näeksid autentsed välja igal platvormil – Windows 7, Windows 8, Mac OS, iOS ja lähitulevikus ka Android. See on midagi, mida VCL-i traditsiooniline monoliitne klassistruktuur pakkuda ei suutnud.

Siin mängib erilist rolli tehnoloogiline lähenemine. Põhimõtteliselt võite võtta VCL teegi ja "toppida selle" WinAPI ja kõigi muude võimalike platvormikõnedega. Seda saab siiski teha väga piiratud komponentide alamhulgaga, kuid VCL sisaldab mitusada komponenti, nii et see lähenemisviis võib VCL-i lihtsalt "tappa". Otsustati mitte puudutada VCL-i, vaid arendada uusi võimalusi uuel platvormil - FireMonkey. Sellel tehnoloogial on isegi teatav tehniline elegants - konkreetse platvormi jaoks projekti kokkupanemise ajal ühendab Delphi IDE vajaliku kompilaatori ja liidese komponendid saavad platvormi stiili.

Kasutaja jaoks on see üks hiireklõps ja sama lähtekood, Delphi jaoks on sellise mitmeplatvormilise teegi loomine arendajate aastatepikkune raske töö.

Kui sai selgeks, et FireMonkey võetakse kasutusele eraldi uue platvormina, tuli valida õige kooseksisteerimise strateegia: Embarcadero ei tahtnud VCL-i kasutajaid kuidagi negatiivselt mõjutada. Seetõttu oleme valinud järgmise plaani: VCL jääb ideoloogiliselt ja arhitektuuriliselt stabiilseks, et tagada kõrgeim võimalik ühilduvus, hõlbustades projektide migreerimist kaasaegsetele versioonidele. FireMonkey arendamine järgib loomulikku ja paralleelset rada, arvestamata VCL-i.

Selle lahenduse nõrk koht on üsna problemaatiline migratsioon VCL-ilt FireMonkeyle sama projekti raames. Kuid uue projekti jaoks saab arendaja valida FireMonkey, et tagada nende tulemuseks oleva rakenduse mitmeplatvormiline toimimine. Pärast iOS-i toega XE4 väljaandmist saame juba rääkida Delphi selgetest konkurentsieelistest mobiilse arenduse alustamiseks ettevõtte keskkonnas, mida suurendatakse pärast planeeritud Androidi toe rakendamist.

Seetõttu pole VCL-i kui sellise väljatöötamisest ilmne "keeldumine". Uutes versioonides areneb ka Delphi VCL osa. See hõlmab 64-bitist tuge, visuaalsete komponentide stiili kasutuselevõttu, paindlike dünaamiliste ühenduste või sidumise mehhanismi rakendamist ja FireDAC teegi kaasamist VCL-projektides andmebaasidega töötamiseks. Lihtsalt võrreldes FireMonkey tehtud hiiglasliku kvalitatiivse hüppega tundub VCL-i edusammud mõnevõrra puudulikud. Kuid olgu kuidas on, VCL on Delphi lahutamatu osa ja jääb selleks veel paljudeks aastateks. Kuigi platvormide areng ja hetkeseis lauaarvutisüsteemide ja mobiilseadmete OS-i valdkonnas on selline, et tulevik kuulub selgelt FireMonkeyle.

Intervjuus rääkisime juba iOS-i toest, räägime oma lugejatele teiste toest uusimad tehnoloogiad näiteks uusimatest RAD Studio XE4-st, nagu Windows 8 ja WinRT, 64-bitised süsteemid, MacOS ja nii edasi. Kas oskate loetleda, mida saate uuendustest rikutud kaasaegsele programmeerijale veel pakkuda?

Tõenäoliselt pole kaasaegne programmeerija uuendustega "rikutud". Suurte projektide puhul toob igasugune "uuendus" sageli kaasa hiiglasliku töömahu.

Näiteks ootasid kõik kaua, paljud tormasid kohe oma koode uuele platvormile üle kandma. Kuid selgub, et isegi väga professionaalsed meeskonnad pole selleks valmis. 64-bitise koodi koostamine ei tähenda töötamist. “Nooruse patud” hakkasid pinnale kerkima, kasutades näiteks juhiseid, mis eeldasid 4-baidise aadressi suurust. Katsekultuuri puudumine koos tehnoloogilise valmisolekuga seda protsessi lühikese aja jooksul rakendada.

Ja siin - mida suurem on projekt, mõõdetuna näiteks lähtekoodi ridade arvu järgi, seda hoolikamad ja tasakaalustatumad on programmeerijad mitmesuguste uuendustega, alates "nupu" ilmumisest liideses kuni "süntaktilise suhkruni". kompilaatoris.

Üks neist "probleemsetest" saavutustest oli Windows 8 väljaandmine. Isiklikult, arvutikasutajana ja lihtsalt kaasaegse IT-spetsialistina, olen Windows 8-ga väga rahul. Kuid arendajatele, kellele saadeti koormusena hulga Windows 8-ga töötavaid arvuteid koos spetsifikatsioonidega uue OS-i all arendamiseks, tähendab see teatud raskusi.

Püüdsime selle OS-i uue liidese arendustuge pakkuda võimalikult mugavalt ja valutult. Seetõttu on nii VCL-i kui ka FireMonkey jaoks kasutusele võetud spetsiaalsed stiilid ning programmeerija saab kas rakenduse liidese ümber ehitada või luua uue rakenduse, mis on välimuselt eristamatu Windows 8 jaoks mõeldud “natiivsest”. Loomulikult on WinRT kaudu Windows 8 jaoks vaja "natiivset" tuge. Aga siin tulebki mängu eesmärkide prioritiseerimine tänapäevastes tingimustes. Mac OS, iOS, Android lähitulevikus ei võimalda veel rääkida WinRT täielikust toest lähitulevikus.

Embarcadero strateegiline eesmärk on loomulikult mitmeplatvormiline. RAD Studio XE4 väljalaskmine oli võtmetähtsusega, peamiselt selle iOS-i toe tõttu. Olemasolev VCL-i kasutav programmeerija saab iOS-i jaoks arendama hakata mõne tunni pärast. Isegi lihtsa mobiilirakenduse saab hetkega muuta võimsaks projektiks, mis töötab olemasoleva infrastruktuuri raames. Ärge arvake, et see on lihtsalt FireMonkey uus kompilaator ja uus stiil, mis sobib iOS-i liidesega.

See hõlmab uut visuaalset kujundajat, sisseehitatud tuge erinevatele vormiteguritele, andmetele juurdepääsu teeke, sealhulgas uut FireDAC-i, ja LiveBindingsi tehnoloogiat paindlikuks ja dünaamiliseks sidumiseks ettevõtte andmetega. Kõik need uuendused jõuavad kohale korraga – Windowsi, Mac OS-i ja iOS-i jaoks. Operatsiooni ruum Mac süsteem OS ei arene nii kiiresti, seega pole probleeme, nagu üleminek Windows 7-lt Windows 8-le. Kuid ilmusid Retina ekraanid ja see nõudis erilist tähelepanu. Nüüd sisaldab iga Delphi XE4 loodud MacOS-i rakendus automaatselt kahte stiili - "tavaline" ja "kõrglahutus".

See. samal rakendusel võib olla sama kvaliteetne "native" liides mis tahes Apple'i lauaarvutis.

Embarcadero ei taha arendajaid oma uute uuenduslike väljaannetega "üllata", "hämmastada" ega isegi "lõbustada". Pigem, vastupidi, IT-sfäär on juba täis erinevaid üllatusi: uued seadmed, uued platvormid, uued kasutajad, nende uued vajadused, uued suhtlusstsenaariumid. Lisage sellele uued tarkvaraarendustehnoloogiad ja programmeerijatel ei jää lihtsalt aega uute ja olemasolevate süsteemide loomiseks – nad ei tee muud, kui migreeruvad ühest keskkonnast teise, vanast raamatukogust uude, ühest keelest teise.

Kuid me ei tunnista kõike uue tagasilükkamist. Tahame lihtsalt tagada kõige järjepidevuse – koodi, liidese, projekti, isegi professionaalsed oskused uute platvormide ja seadmete ilmumisel. Võib öelda, et me võitleme uute platvormide osas ebaterve konservatiivsusega arendustööriistade terve konservatiivsuse kaudu. Ärge oodake Embarcaderolt eksootilisi tooteid, mittestandardseid programmeerimiskeeli ega veidraid arendustööriistu.

Meilt leiate alati visuaalset arendust, klassikalisi keeli, “natiivset” koodi ja lasete oma rakenduste sihtplatvormidel, mis on loodud samal tõestatud klassikalisel viisil, olla uued.

Mis on FireMonkey?

FireMonkey (FMX) on raamistik platvormideüleseks arendamiseks nii lauaarvutisüsteemidele (Lähiajal on plaanis Linux, Mac OS + serveri tugi) kui ka mobiilile (iOS ja Android) kasutades Delphi/C++ keelt.

Iseärasused:

• ühtne koodibaas kõigile platvormidele;

• mis tahes juhtseade (visuaalne komponent) võib olla teiste komponentide konteiner (alam);

• komponentide väga arenenud suhtelise paigutuse (20 tüüpi) olemasolu vormil;

• LiveBinding võimaldab ühendada mis tahes tüüpi andmeid või teavet mis tahes kasutajaliidese või graafiliste objektidega;

• vormi/komponentstiilide olemasolu;

• Mitme seadme eelvaade võimaldab teil kohandada visuaalset esitlust iga platvormi jaoks;

• FireUI Live Preview – kuvab rakenduse välimust reaalajas reaalajas.

Võimalused:

• iga platvormi natiivse API kasutamine, samuti võimalus helistada kolmandate osapoolte omateekidele;

• interaktsioon kõigi anduritega (GPS, kiirendusmõõtur, kompass, Bluetooth (sh LE) ja teised);

• tõukemärguannete tugi, IoT;

• asünkroonsete HTTP-päringute tugi;

• enamiku andmebaaside tugi (MsSQL, MySql, Oracle, PostgreSQL, MongoDB jne);

• töötamine pilvteenusega (Amazon, Azure);

• Androidi teenuse tugi.

Miinused (praegu):

• emakeelsete klasside kohandamise toetuse puudumine;

• konkreetsete asjade realiseerimine on kas võimatu (vidinad, laiendused (iOS) jne) või on vaja tantsu tamburiiniga (taustateenus, saatesõnum jne);

• Splash screen (algkuva) kohandamine on pehmelt öeldes puudulik;

• FMX-juhtelemendid kasutavad oma renderdust (visualiseerimine, joonistamine), mis on puhtalt visuaalselt sarnane natiivsele;

• natiivsete juhtelementide kasutamine hõlmab suuri kehaliigutusi;

• kui komponente on palju pesastunud, juhtub uskumatuid asju: rakendus jookseb erinevates kohtades kokku, kaotab fookuse, hangub jne;

• mobiiliplatvormidel rakenduse silumise teabesisu on null;

• mobiilplatvormide vigade kirjeldused on taandatud kasutuks "Error 0x00000Х";

• koostamisaeg tahab olla parim keskmiste ja suurte projektide jaoks;

• vajadus kasutada faili iga platvormi mobiilirakenduste lihvimiseks;

• Intel Atomi arhitektuuri tugi puudub;

• ebapiisav hind võrreldes konkurentidega.

Plussid:

• viimasel ajal väga aktiivne nii toote kui kogukonna arendus, üha uute tehnoloogiate toetamine;

• tohutu hulga tasuta ja kaubanduslike komponentide olemasolu;

• Rakenduse kiirus on väga lähedane natiivsele;

• väga arenenud visuaalne redaktor ja keskkond üldiselt, stiilide olemasolu;

• võimalus testida rakendust Winis ja alles seejärel juurutada see seadmetes, mis kiirendab oluliselt arendust;

• muuta režiimi/platvormi randmeliigutusega;

• PAServer pakub Apple OS-i jaoks arendamisel hõlpsat suhtlemist MacO-dega;

• 3D-graafika tugi karbist välja.

Kokkuvõtteks tahan öelda, et FireMonkey on viimase paari aasta jooksul kasvanud professionaalseks tööriistaks ärirakenduste ja muu platvormiüleseks arendamiseks. Paljud puudused lahenevad tasapisi ja iga väljalaskega muutub toode kaasaegsemaks ja isemajandamaks ning kaob ka olemasolev skeptitsism Delfi keele enda suhtes, mis on seotud aastatepikkuse stagnatsiooniga. Uute projektide kirjutamine FireMonkey's on "turvaline" ja paljutõotav.

Mõiste FireMonkey enam-vähem tuttavaks saamisest on möödunud piisavalt aega, kui mitte kõigile arendajatele, siis vähemalt Delphi kasutajatele. Selle aja jooksul ilmusid FireMonkeyt käsitlevad raamatud, FireMonkeyt käsitlevad artiklid ja FireMonkeyt käsitlevad sissekanded paljudes ajaveebides. Seda kõike on väga huvitav lugeda. Kuid ükski teooria ei saa praktikat asendada. Ja mul, nagu paljudel varemgi, oli kihelus proovida midagi FireMonkey abil kirjutada.

Siiski tekkis probleem. Millegipärast otsustasin, et pean lihtsalt mõne mitte väga keerulise tööprojekti ellu viima.

Selgitamaks, miks see minu jaoks probleemiks osutus, on vaja mõningast (mulle meeldib kirjutada, lüüriline) kõrvalepõige. Ekskursioon minu kui arendaja minevikku. Selgitage mõningaid minu seisukohti Delphi abil programmeerimise kohta.

Pean ütlema, et alustasin Delphi kasutamist Windows 3.1-s, see tähendab esimesest versioonist. Ja sellest ajast peale olen õppinud VCL-i. Uurisin seda nii-öelda originaalis. Vaatasin, käisin ligi, jälgisin allikaid. Uuesti ja uuesti.

On teada, et erinevatel aegadel sisaldas Delphiga tarnitud komponentide komplekt kolmanda osapoole komponente, mis olid mõeldud VCL-i lünkade täitmiseks ja mis tõenäoliselt läbisid enne lisamist mingisuguse kvaliteedikontrolli. Mõnda neist komponentidest tarnitakse ka tänapäeval. Võtke seesama Indy. Ma ei taha kedagi solvata, see on puhtalt minu isiklik arvamus, mis kehtib ka minu kui komponentide arendaja kohta: mitte ükski komplekt pole olnud nii sügavalt läbi mõeldud ja nii hästi teostatud kui tohutu ja mitmekesine VCL. Ei, ma ei pretendeeri lõplikule tõele ja loomulikult on VCL-is endas palju vigu, otsuseid, mis põhjustavad arusaamatust, tagasilükkamist ja millega tahetakse mitte nõustuda. Aga mulle on alati jäänud mingi ühtse stiili mulje. VCL-is on minu arvates ilus ja tugev tuum, mis toetab kogu Delphi disaini ja mille ümber on üles ehitatud nii tarkvara infrastruktuur kui ka arendajate kogukond ise. See on suuresti tänu VCL-ile, minu arvates jällegi, et kuulujutud Delphi surmast jäävad endiselt kuulujuttudeks. Ja kui VCL-i tarne sisaldas kolmandate osapoolte arendajate komponente, oli see kohe märgatav, need olid erinevad.

Kuid siis saabub hetk ja ma kuulen, et VCL on tehnoloogia, mis on aegunud. Tehnoloogia, mis tuleks minevikku jätta. Arendajad peaksid kõik oma uued projektid FireMonkey's ellu viima ja mis puutub vanadesse, siis oleks tore need uutele radadele üle kanda. FireMonkey kõikjal ja igal ajal. Ja ma kuulen seda erinevatest allikatest. Ja üsna visalt. Ei, keegi ei tapa VCL-i. ta jääb meie juurde. Kuid ta pole enam number üks. Temast peaks saama varumees. Vähemalt nii saan mina aru, mida toote tuleviku kohta räägitakse.

Põhimõtteliselt saan sellest olukorrast aru. Oleme seadnud kursi mitme platvormi ja, mis veelgi olulisem, platvormidevaheliseks kasutamiseks. Lõppude lõpuks, mis on VCL? Visuaalsete komponentide raamatukogu. Visuaalsete komponentide raamatukogu. Te ei pruugi sellega nõustuda. Näiteks olen alati pidanud paljusid mittevisuaalseid komponente ja mitte komponente, vaid lihtsalt klasse VCL-i lahutamatuks osaks ning suurt hulka kolmandate osapoolte klasse ja komponente VCL-i jätkuks, laienduseks. Noh, ma ei saa mõelda TDataseti pärijatele VCL-i osana. Kuigi näiteks termin DBExpressi teek viitab sellele, et see pole justkui VCL. Ilmselt jagab Embarcadero monoliitse, minu vaatenurgast VCL-i, mitmeks eraldi teekiks. Ei, muidugi mitte täiesti eraldi, aga siiski. Ja kui me selle seisukohaga nõustume, on FireMonkey mõeldud asendama täpselt VCL-i visuaalset osa (kuidas ma peaksin ikkagi nimetama klasside ja komponentide täielikku raamatukogu, võib-olla Borlandi komponentteeki?).

Millistele visuaalsetele komponentidele on ehitatud raamatukogu? Operatsioonisüsteemi pakutavate madala taseme põhielementide ümber. Akende käepidemed, fondid, aknad ise, sisendelemendid, sõnumid, seadme kontekstid ja palju muud – need ei ole Delphiga kaasas oleva teegi mõisted, vaid operatsioonisüsteemi mõisted. Jah, täpselt, Windows. Ja kui soovite ehitada platvormidevahelist teeki, siis on loogiline loobuda infrastruktuurist, mida pakub teeki kasutades kirjutatud programmi käivitav operatsioonisüsteem.

Just seda FireMonkey püüab teha. Nad üritavad luua infrastruktuuri, mis põhineb erinevates operatsioonisüsteemides toetatavatel põhimehhanismidel, mis on võimeline asendama teenust, mida operatsioonisüsteemid ise pakuvad.

Paljud inimesed mäletavad proovimistplatvormideülene mitte ainult raamatukogu, vaid ka Delphi ise. Paralleelselt Delphi 6-ga anti välja Kylixi toode ja CLX teek. Kõik see tehti selleks, et saaksite Linuxi jaoks arendada. Linuxil pole aga paljusid Windowsi graafilise aknaliidese põhikontseptsioone. Linuxi aknaliides ei ole üldiselt omapärane nähtus. See on valikuline rakendus. Ja ma pidin kirjutama mingi sünteetilise raamatukogu. Tema abiga oli võimalik kirjutada programm nii Windowsile kui Linuxile. Siiski mäletan siiani mitte pettumust, vaid pigem ärritavat ebamugavust, mida kogesin, kui proovisin kasutada CLX-i analoogseid visuaalseid komponente. Ma hakkasin paljudest asjadest puudust tundma. See, mida olin harjunud VCL-i kasutades mõtlemata tegema, osutus CLX-i abil keeruliseks, täiesti erinevaks või lihtsalt võimatuks.

Umbes sama tundsin ka BDE-lt DBExpressile üleminekul. Vana, Field Test BDE-st tuttav (Borland kasutas seda juba Quattro Pro for Windows ja Paradox for Windows ning selle nimeks oli ODAPI ja siis IDAPI ning minu arvates Microsoft ODBC-st pea ja õlgade kohal) kuulutati vananenud tehnoloogia, mis peaks uutes projektides andma teed uuele raamatukogule. Mul jäi DBExpressis alguses alati millestki puudu, eriti teadmistest.

Samas ei taha ma kuidagi norida ega kritiseerida ei ülalloetletud raamatukogusid endid ega ka nende ilmumiseni viinud otsuseid. Räägime ainult minu muljetest, mõnikord ka esmamuljetest.

Nüüd saab ilmselt veidi selgemaks, miks otsus FireMonkey abil väike tööprojekt kirjutada tõi kaasa hulga probleeme. Paljude aastate jooksul on kavandeid, projekte ja plaane välja töötades välja kujunenud teatud stereotüüp, kindel mall, mida ja kuidas teha. Ja minu puhul pidin silmitsi seisma tõsiasjaga, et malli oli vaja muuta. Kuna te ei saa kõike, mida olete VCL-i kasutama harjunud, üle kanda FireMonkeyl ehitatud projekti.

Projekti alustades kogesin teatud déjà vu tunnet. Nimelt ebamugavustunne. Näiteks tavalistel sisendelementidel ei ole palju omadusi. Praktikas kindlalt kinnistunud tehnikad, mis põhinevad nippidel, mis on seotud mõne operatsioonisüsteemi funktsiooni tundmisega, ei tööta uues kontekstis. Rääkimata sellest, et mõned komponendid on kardinaalselt muutunud.

Noh, üks oluline nüanss veel. Milliseid projekte peate tavaliselt tööl tegema, kui see (töö) ei ole seotud kompilaatorite, modelleerimissüsteemide või millegi muu kõrgteadusliku kirjutamisega? Arvan, et enamiku jaoks on see millegi arendamine, mis hõlmab andmebaaside kasutamist. Lisaks võib DBMS-i teenuseid kasutada ka midagi väga teaduslikku.

Siin ootas mind järjekordne varitsus. Millegipärast, kui puutute praktikas kokku tõsiasjaga, et FireMonkey ei sisalda elemente, mis on keskendunud andmebaasi salvestatud andmetega töötamisele, ei ole te selleks (pehmelt öeldes) veel päris valmis. Kuigi olen selle kohta juba mitu korda lugenud ja tean (teoreetiliselt), mida kasutada. Me räägime reaalajas sidumisest.

Ma ei taha laskuda vaidlusesse selle üle, kas tõelised lahedad programmeerijad peaksid kasutama db-teadlikke komponente või mitte.Praktikas seisin uut projekti alustades tõsiasjaga, et tuleb mõlemaga harjuda. uued visuaalsed komponendid ja uus viis andmete toomiseks kuvamiseks, redigeerimiseks ja lõpuks salvestamiseks. Mis jällegi pole halb ega hea. Minuga juhtus just nii.

Siinkohal tahan lõpetada oma postituse esmamuljetest. Järgmiseks on lood sellest, millest ja kuidas projekti kallal töötades üle saadi.