03.06.2013 12:46

Es daudz cietu, jo FireMonkey trūka pārlūkprogrammas komponenta. Slavenais Delphi Chromium Embedded projekts iekļāva FMX atbalstu jaunākajā versijā. Bet, neskatoties uz to, ka ir pagājis diezgan daudz laika, autors nesteidzas pievienot FMX2 atbalstu. Galu galā man bija jāuzņemas lietas savās rokās.

TChromiumFMX komponents no oficiālās montāžas darbojas diezgan labi FireMonkey (XE2), bet tas pat netiek kompilēts FMX2. Man vajadzēja nedaudz izdomāt, kā tas darbojas, un to salabot. Par laimi, lielas izmaiņas nebija vajadzīgas.

FMX2 komponentam ir mainījušās divas lietas.

Pirmkārt, TBitmap vairs nav ScanLine un StartLine rekvizītu. Tiešā piekļuve TBitmap saturam ir pārveidota (nez kāpēc?) un tagad ir pieejama caur TBitmapData klasi, kas atgriež metodi TBitmap.Map.

Nu, otrā, zināmākā - Platform .* vairs nav, tagad jums ir jāiegūst vēlamais interfeiss caur TPlatformServices.GetPlatformService . Šeit viss ir diezgan vienkārši, un nav nekādu problēmu.

Es to nepārbaudīju ar īpašu atjautību, taču komponents ir diezgan piemērots maniem mērķiem - caur to varat skatīt vietnes. Lejupielādējiet to. Tāpat, iespējams, nosūtīšu autoram savus labojumus, varbūt viņš uzskatīs par nepieciešamu tos pievienot oficiālajai versijai.

30.07.2012 02:43

Džeisons Sautvels ierosina izstrādāt FireMonkey iesaiņojuma komplektu vietējām Windows/OSX vadīklām un piesaista šim nolūkam naudu. Sākumā viņš plāno savākt 20 000 USD.

Ideja skaidra. Esošie FireMonkey komponenti tiek renderēti, izmantojot Delphi rīkus gandrīz no nulles, kas, no vienas puses, lielā mērā nodrošina to starpplatformu, bet, no otras puses, rezultātā mēs iegūstam komponentus, kas neizskatās gluži dabiski abās pašlaik atbalstītajās darbībās. sistēmas. Un tas nav tik slikti - papildus izskatam jums ir patstāvīgi jāizstrādā šo komponentu loģika. Piemēram, RichEdit ir diezgan sarežģīts, un tā loģikas atkārtošana FireMonkey nav mazsvarīgs uzdevums. Gan VCL, gan CLX neizgudroja riteni no jauna, bet izmantoja jau gatavu.

Un tagad sliktās ziņas. Viss darbojas izpildlaikā, taču es neatradu nekādu veidu, kā pievienot savu jauno cilnes veidu vienumu noformētājam. Un šķiet, ka visām saraksta vadīklām ir viena un tā pati problēma: TListBox, TGrid utt. Sākumā man ļoti patika pieeja to īstenošanai, bet tagad es pat kaut kā par to šaubos. Meklējot internetā, atklājās, ka es neesmu viens ar šo problēmu.

Palīdzība klusē, arī kodā neko neatradu. Tiešām nekādā veidā? Tas būtu ārkārtīgi kaitinoši.

Ir pagājuši vairāk nekā trīs gadi, kopš CodeGear nodaļa, kas ir atbildīga par tādu pasaulslavenu rīku kā Delphi, C++Builder un JBuilder, kā arī Interbase DBVS izveidi, kļuva par daļu no Embarcadero Technologies, uzņēmuma, kas pazīstams ar savu datu bāzes dizainu un administrēšanu. rīki. , un divus gadus kopš mūsu žurnāla lapās apspriedām, ko sagaidīt, izstrādājot krievu izstrādātāju vidū tik populārus rīkus. Mēs jautājām Deividam Intersimonam, viceprezidentam izstrādātāju attiecību jautājumos un Embarcadero Technologies galvenajam evaņģēlistam, un Kirilam Rannevam, Embarcadero Technologies pārstāvniecības vadītājam Krievijā. Mūsu jaunākajiem lasītājiem informēsim, ka šī ir tālu no pirmās intervijas, ko Deivids un Kirils sniedz ComputerPress - mūsu sadarbība turpinās jau otro desmitgadi. Un apmēram tikpat daudz gadu mēs periodiski publicējam datu bāzes pārvaldības rīku apskatus, kuros liela uzmanība tiek pievērsta Embarcadero produktiem.

ComputerPrese: Deivid, jūsu nodaļa ir Embarcadero daļa jau trīs gadus. Pirms diviem gadiem jūs bijāt entuziasma pilns par to, ka tas kļuva par daļu no jums mērķtiecīgi un garā tuva uzņēmuma. Vai šajā laikā kaut kas ir mainījies? Vai jūs un jūsu kolēģi jūtat tādu pašu entuziasmu?

Jā, es joprojām esmu entuziasma pilns. Galvenās izmaiņas, kas notikušas, kopš kļuvām par Embarcadero kompāniju, ir tādas, ka Delphi attīstībā ir ieguldīts liels ieguldījums. Pieaudzis darbinieku skaits, kas strādā pie izstrādes instrumentiem, pieaudzis tehnoloģiju skaits, kuras varam izstrādāt vai nepieciešamības gadījumā iegūt.

RAD Studio XE 2 izlaidums, kuru plānojam demonstrēt Maskavā, ir lielākais šī produkta izlaidums ar milzīgām iespējām un lielu atbalstīto platformu skaitu kopš pirmās Delphi versijas, kas tika izveidota 16 bitu Windows operētājsistēmai un agrākajai novatoriskajai. produkts, kas savienoja komponentu pieeju un kompilāciju ar mašīnkodu. Tagad mēs atbalstām izstrādi ne tikai Windows, bet arī Macintosh, nemaz nerunājot par tīmekļa izstrādi un aplikāciju izveidi mobilajām ierīcēm, un šīm aplikācijām dažādām platformām var būt viens kods.

Jaunā izstrādes platforma FireMonkey ir Embarcadero un nesen iegādātās Ulan-Ude Krievijas firmas KSDev sadarbība, kas ir vektorgrafikas komponentu, DirectX un OpenGL, grafikas efektu tehnoloģiju un Delphi komponentu ražotājs, kas izmanto GPU ar PixelShader 2.0. Pirms gada iegādājāmies uzņēmumu KSDev (sk. ksdev.ru) un sākām strādāt kopā, lai izveidotu vairāku platformu izstrādes rīku, kas ietver platformu FireMonkey lietojumprogrammu izstrādei ar komponentiem Delphi un C ++ Buider lietojumprogrammu lietotāja saskarņu izveidei, integrēšanai. ar datu bāzēm, grafikas apstrādi, izmantojot grafisko procesoru, un integrāciju ar operētājsistēmu.

Izmantojot FireMonkey, varat izveidot lietojumprogrammu, kurā CPU un GPU darbojas kopā, un pēc tam, izmantojot dažādus kompilatorus un izpildlaika bibliotēkas (Run-time Libraries, RTL), varat to kompilēt operētājsistēmai Windows, Mac OS vai iOS. Tā vietā, lai apgūtu programmēšanu ar dažādām grafikas bibliotēkām, apgūstot API no dažādām platformām ar dažādām koordinātu sistēmām un dažādām iespējām, izstrādātāji, kas izmanto Delphi un C++Builder, var izmantot vienu un to pašu komponentu pieeju, vizuāli rediģējot veidlapas un izveidojot savienojumu ar datu bāzēm, pārvietojot komponentu ar pele. Šis ir principiāli jauns veids, kā izveidot lietojumprogrammas, kas darbojas dažādās platformās, un tas ir nākotne. Ja vēlaties savai aplikācijai pievienot atbalstu citām operētājsistēmām un platformām, tā nav jāpārveido un jāattīsta – pietiks tikai ar pārkompilēšanu.

Mēs veidojam jaunus kompilatorus, kas ģenerē vietējo kodu. Šodien ir Delphi kompilatori Windows 32 bitu un 64 bitu versijām, 32 bitu Mac OS 10 versijām. Mēs strādājam pie nākamās paaudzes Delphi un C++Builder kompilatoriem, kas ļaus jums izveidot augstas veiktspējas vietējais kods gan šīm, gan citām platformām, piemēram, Android vai Linux, un saglabāt to pašu dizainu, tos pašus komponentus, vienu un to pašu kodu, izmantojot dažādus kompilatorus un izpildlaika bibliotēkas.

Kā redzat, man ir pietiekami daudz iemeslu entuziasmam. Un izstrādātāji, kurus es sastopu visā pasaulē, zina, ka Embarcadero daudz iegulda Delphi un C++Builder, kā arī PHP izstrādes rīkos.

KP: Kādu progresu esat panācis abu uzņēmumu rīku integrēšanā pēdējo divu gadu laikā? Kādi ir Embarcadero nākotnes plāni šajā jomā?

DI.: Laikā, kad CodeGear nodaļa kļuva par Embarcadero daļu, šim uzņēmumam bija attīstības komandas Toronto, Monterrejā un Rumānijā, mēs bijām un joprojām esam Scotts Valley un Krievijā, Sanktpēterburgā. Embarcadero bija izstrādātāju rīki un datu bāzu administratori, CodeGear bija lietojumprogrammu izstrādes rīki, bet pēdējie izmanto arī datu bāzes. Uzņēmumu apvienošana ir ekspertīzes, zināšanu datubāzu jomā, koda optimizācija, ieskaitot servera kodu, apvienojums. Apvienošanās rezultātā tika izveidots arī jauns produkts AppWave, kas ir īpaša tehnoloģija, lai parastu Windows lietojumprogrammu pārvērstu par kaut ko ļoti viegli lietojamu (piemēram, iPhone vai citu ierīču lietojumprogrammām). AppWave ļauj neinstalēt aplikāciju, bet vienkārši to atlasīt un palaist no sagatavotā aplikāciju krātuves servera (app), savukārt tā tiks izpildīta lietotāja datorā, neveicot izmaiņas tās reģistra un failu sistēmas apgabalā. Starp citu, AppWave lietojumprogrammu pārlūkprogramma ir rakstīta Delphi. Embarcadero izmanto Dephi savai attīstībai un mūsu lietojumprogrammu izstrādes pieredzei.

iPhone (iOS) lietotni izveidoja
izmantojot FireMonkey platformu

Varat arī izmantot mūsu izstrādes rīku un DB optimizētāja integrāciju, lai optimizētu SQL vaicājumus, veidojot lietojumprogrammas. Nosūtot SQL kodu tieši DB optimizētājam, varat to profilēt, pārbaudīt un atgriezt tā optimizētu versiju atpakaļ izstrādes vidē. Embarcadero pieredze datubāzē ir arī uzlabojusi DataSnap tehnoloģiju. Pateicoties izstrādātājiem no Toronto, esam ieguvuši daudz zināšanu par daudzpakāpju sistēmu un datu bāzu arhitektūru. Tagad mums ir kopīgas zināšanas par servera kodu un saglabātajām procedūrām abos uzņēmumos. Mums ir tādi rīki kā RapidSQL un DB izmaiņu pārvaldnieks, kā arī izstrādes vides, kas atvieglo servera puses koda izveidi, piemēram, Code Insight un Code Completion tehnoloģijas, kas ir ļāvušas izveidot SQL ieskatu un SQL pabeigšanas tehnoloģijas. Mūsu kopīgā pieeja klienta un servera koda izveidei, mūsu kopīgā filozofija, ļauj mums koplietot datu bāzes pārvaldības rīku un lietojumprogrammu izstrādes rīku kopīgas iezīmes.

Kirils Ranņevs: Es gribu piebilst kaut ko svarīgu. No komerciālā viedokļa ir ļoti svarīgi, kā mēs piegādājam savus rīkus. Piemēram, jaunajā RAD Studio XE 2 Ultimate laidienā ir iekļauts pilns DB Power Studio rīku komplekts. Tas ir ļoti spēcīgs rīku komplekts, tostarp RapidSQL vaicājumu autorēšanas vide, DB Change Manager izmaiņu pārvaldības rīks un DB optimizētāja vaicājumu optimizācijas rīks, kas ļauj veikt svarīgu izstrādes un izvietošanas procesa daļu, pārvaldot izmaiņas datu modelis, datu bāze, kods utt. Šī ir ļoti laba un pareiza tehnoloģiju kombinācija.

DI.: Taču, ja nepieciešams, izstrādātāji var izmantot Subversion, lai pārvaldītu pirmkoda versijas, un DB izmaiņu pārvaldnieku, lai pārvaldītu metadatu versijas. Varat izmantot koda profilēšanu un DB optimizētāju, lai optimizētu servera kodu, RapidSQL, lai izveidotu un atkļūdotu servera kodu, un mūsu izstrādes vides, lai izveidotu un atkļūdotu lietojumprogrammas. Šī tehnoloģiju kombinācija RAD Studio XE Ultimate Edition demonstrē paralēles starp datu bāzes un lietojumprogrammu izstrādes modeļiem. Lielākā daļa izstrādātāju, kas veido biznesa lietojumprogrammas, izmantojot Delphi un C++Builder, strādā ar datu bāzēm, un tiem ir nepieciešami šie rīki, un RAD Studio XE Ultimate Edition ir lieliska kombinācija šiem izstrādātājiem.

KP: Mūsdienu lietotājs vairs nav tikai Windows platformas lietotājs. Mēs izmantojam mobilās ierīces, iPhone, iPad, ierīces, kuru pamatā ir Android platforma. Tas nozīmē, ka izstrādātājiem jāsāk orientēties uz dažādām platformām, būtiski nepalielinot ieguldījumus apmācībā – tas ir, ir nepieciešami universāli rīki. Acīmredzot ir nereāli sagaidīt universālu rīku parādīšanos no platformu ražotājiem, un šajā jautājumā varam paļauties tikai uz neatkarīgiem instrumentu ražotājiem. Kur mēs varam paļauties uz Embarcadero?

DI.: Mums joprojām ir daudz darāmā platformas atbalsta jomā. Šodien mēs ieviešam atbalstu iOS platformai iPhone un iPad, kam seko Android, Windows 7 un Blackberry viedtālruņu atbalsts. Programmā RAD Studio XE 2 mēs sākām, izveidojot FireMonkey platformu operētājsistēmai iOS, un vēlāk FireMonkey portēsim uz citām platformām.

Tajā pašā laikā ir liels skaits operētājsistēmu, kas atbalsta skārienekrānus (skārienjutīgos ekrānus), tālruņiem, planšetdatoriem un ierīcēm, galddatoriem, un mēs turpināsim tiem pievienot atbalstu. Turklāt ir arī balss vadības sistēmas, kustību vadības sistēmas, biometriskās sistēmas, akselerometri, tāpēc mums ir jāturpina paplašināt FireMonkey, lai visi izstrādātāji varētu izmantot jauno platformu priekšrocības. Piemēram, Microsoft Kinect ierīce tika izstrādāta Xbox 360, un tagad ir atbilstošs SDK (Software Development Kit) operētājsistēmai Windows. Un mums jau ir piemēri, kur mēs izmantojam kustību, lai vadītu lietojumprogrammu gandrīz tādā pašā veidā, kā mēs parasti izmantotu peli vai tastatūru.

Kad veidojat lietojumprogrammas ar daudz sarežģītu grafiku, jūs ģenerējat veselu jaunu lietotāja interfeisu pasauli. Ja mums ir darīšana ar Windows operētājsistēmu, mēs iekapsulējam tās Windows API VCL bibliotēkā (Visual Component Library — vizuālo komponentu bibliotēka, kas ir Delphi un C ++ Builder izstrādes rīku neatņemama sastāvdaļa. - Piezīme. ed.), ko, starp citu, var pielietot tālāk. Un FireMonkey mēs iekapsulējam operētājsistēmas API. Bet šodien mēs daudz plašāk manipulējam ar formām un grafiku. Varat arī pievienot fiziskās telpas rekvizītus animācijai un specefektiem. Turklāt ir pieejams milzīgs skaits citu papildu funkciju lietotāja interfeisu izveidei, ko plānojam ieviest tuvāko gadu laikā dažādām platformām, mobilajām ierīcēm un planšetdatoriem.

Microsoft nesen publicēja detalizētu informāciju par Windows 8, kas iznāks pēc gada. Mēs atbalstīsim šos jauninājumus VCL bibliotēkā un FireMonkey platformā. Bet Delphi ir izstrādes rīks, kas paredzēts ne tikai Windows, bet arī Macintosh, iPhone un iPad. Mēs arī izstrādājam savus PHP produktus, atbalstām jQuery Mobile, izmantojam iOS API, lai izstrādātu mobilo klientu lietojumprogrammas, un veidojam PHP servera lietojumprogrammas, izmantojot vedņus un rīkus, lai ģenerētu klienta puses JavaScript, HTML un kaskādes stila lapas. Mēs varam iepakot PHP lietojumprogrammas un iPhone iOS vietējās klienta lietojumprogrammas, klientam sarunājoties ar PHP serveri. Un tas, savukārt, sazināsies ar datu bāzes serveri un ar tīmekļa pakalpojumiem - ar visu, kas nepieciešams biznesam.

RadPHP XE2 izstrādes vide. Izveidojiet mobilā tīmekļa lietojumprogrammu
izmantojot jQuery Mobile komponentus iPhone 3G

Citiem vārdiem sakot, mēs plānojam paplašināt FireMonkey un VCL iespējas, tostarp atbalstu mobilajām platformām.

KP: Vai jūs varētu sīkāk pastāstīt par FireMonkey platformu?

DI.: Kā jau minēju, operētājsistēmai Windows izveidotā VCL bibliotēka turpinās attīstīties un pilnveidoties. Bet šodien, ja vēlaties faktiski izstrādāt biznesa lietojumprogrammas, jums tās ir jāizveido dažādām platformām. Tam ir paredzēta FireMonkey platforma. Tas atbalsta augstas izšķirtspējas lietotāja saskarņu, augstas veiktspējas 3D grafikas, augstu kadru nomaiņas ātrumu un, kas ir svarīgi, izmanto GPU, lai to izdarītu.

Šos līdzekļus varat izmantot, veidojot zinātniskas, inženierijas un biznesa lietojumprogrammas. Šādas lietojumprogrammas var izveidot savienojumu ar datu bāzēm, izmantojot dbExpress tehnoloģiju, joprojām izmantojot izstrādātājiem pazīstamus nevizuālus komponentus, piemēram, ClientDataSet vai DataSource, izmantot DataSnap tehnoloģiju, izveidot savienojumu ar jebkurām datu bāzēm, SOAP un REST serveriem. Varat izveidot pievilcīgas vadīklas, iesaiņotas pogas, greznas tabulas un citus interfeisa elementus 2D un 3D formātā. Aplikācijā var ielādēt gatavu 3D modeli un apvienot to ar 2D formu, kurā to var pagriezt un apskatīt no dažādiem leņķiem. Varat izveidot datu kubu vai 3D biznesa diagrammu un pagriezt to, izmantojot peli, tastatūru vai pat Kinect ierīci, vai arī varat ieiet kubā un aplūkot tā dažādās virsmas no iekšpuses. Un to visu var izdarīt ar ātrgaitas GPU. Pēc tam to pašu lietojumprogrammu var kompilēt citai platformai, piemēram, Mac OS.

Lietojumprogramma, kas satur rotējošu kubu ar datiem,
novietots uz tā malām

Vai arī varat izveidot 3D formu no jauna un izmantot kameras un gaismas, lai apgaismotu un pagrieztu lietotāja interfeisa daļas. Veidlapu izstrādātājam jau ir iebūvēta vide, kas atbalsta 3D lietotāja saskarni tieši projektēšanas laikā.

Operētājsistēmā Windows varat izmantot Direct2D bibliotēkas augstas izšķirtspējas 2D grafikai un Direct3D 3D grafikai. Mac OS izmanto Quartz un OpenGL bibliotēkas tam pašam mērķim. Operētājsistēmā iOS tiek izmantotas Quartz un OpenGL ES bibliotēkas. Taču tas viss ir slēpts no izstrādātāja – viņš izmanto FireMonkey platformu, tās koordinātu sistēmu un aplikāciju programmēšanas saskarni, nedomājot par šīm bibliotēkām, un var sastādīt vienu un to pašu aplikāciju dažādām platformām.

Atcerēsimies, kas ir VCL. VCL ir Windows API komponentu "iesaiņojums". Mums ir darīšana ar resursiem, izvēlnēm, dialoglodziņiem, krāsām, stiliem, Windows ziņojumiem. Tā kā FireMonkey ir vairāku platformu ietvars, atšķirībā no VCL, tas saglabā tos pašus notikumu un komponentu modeļus, ļaujot domāt par notikumiem (piemēram, OnClick, OnHasFocus, onMouseDown un onKeyDown notikumiem), bet apstrādāt Macintosh vai iPhone notikumus.

FireMonkey ietvarā ir arī pilnīga lietotāja interfeisa elementu animācijas sistēma. Tā noteikti nav visaptveroša Pixar stila animācijas sistēma, taču tā ļauj izmantot tādus efektus kā bitkartes animēšana, fokusa izcelšana uz lietotāja interfeisa elementu un darbs ar vektorgrafiku. Izstrādātājam ir pieejami vairāk nekā 50 vizuālie efekti: aizmiglošana, attēla pārvēršana melnbaltā, šķīdināšana, pārejas, atspulgs, ēnu veidošana – visa veida efekti, kas pieejami mūsdienu GPU, kas tagad ir gandrīz jebkurā datorā. Lietojumprogramma, kas izveidota, izmantojot FireMonkey platformu, nosūta komandas uz GPU, kas veic visu grafikas attēlošanas un lietotāja interfeisa izveides darbu. Tajā pašā laikā centrālais procesors ir brīvs aprēķiniem un piekļuvei operētājsistēmai. Izstrādātājam tikai pareizi jānovieto komponenti.

Pats galvenais FireMonkey platformā ir veids, kā tā veido lietotāja interfeisu. Ir iespējas ievietot bitkartes grafiku uz interfeisa elementiem, piemēram, izvēlnēm, pogām un ritjoslām. Programmā FireMonkey šim nolūkam mēs izmantojam GPU vektorgrafiku. No programmēšanas viedokļa tās visas ir vienas un tās pašas vadīklas, taču grafikas procesors veic visu darbu, lai tās parādītu. Mēs varam lietot stilus vadīklām, padarīt lietojumprogrammu līdzīgu Mac OS vai Windows lietojumprogrammai, izveidot savu stilu, piemērot savus stilus saskarnes elementiem (piemēram, padarīt pogu taisnstūrveida vai apaļu, mainot tās stilu veidlapu redaktorā) - šim nolūkam izstrādes vidē ir stila redaktors. Varat izveidot savu stilu vai mainīt jau pabeigtas lietojumprogrammas stilu.

FireMonkey platforma — izstrādes rīki
un atbalstītās platformas

Ja atceraties, VCL bibliotēkā bija ierobežots skaits vadīklu - konteineru (tas ir, kas ļāva tajos ievietot citus elementus), un FireMonkey katra vadīkla ir konteiners. Tas nozīmē, ka katrā vadīklā var būt jebkura cita vadīkla. Piemēram, nolaižamā saraksta vienumi var saturēt attēlus, pogas, rediģēšanas lodziņus un citas vadīklas. Un jūs varat arī novietot komponentus uz slāņiem.

FireMonkey renderēšanas sistēma ir diezgan elastīga – tā var izmantot Direct2D, Direct3D un OpenGL bibliotēkas, nosūtot komandas uz GPU. Lai to pašu panāktu VCL, bija nepieciešams ģenerēt atsevišķu ārpusekrāna buferi, izveidot tajā attēlu, izsaucot atbilstošās grafikas bibliotēku funkcijas, un pēc tam parādīt to formā.

FireMonkey atbalstīto grafisko efektu piemēri

Ja jums nav GPU, joprojām varat lietot 2D vai 3D formas un izmantot FireMonkey vadīklas. Šādā gadījumā FireMonkey platforma izmantos GDI+ bibliotēkas vai citas līdzīgas bibliotēkas un veiks tādus pašus efektus un animāciju vai manipulācijas ar 3D objektiem.

Vēl viena FireMonkey iezīme ir jauna sistēma interfeisa elementu saistīšanai ar datiem, kas ir atvērta un elastīga. VCL ir divu veidu saskarnes elementi: ar datiem saistīti un ar datiem nesaistīti (piemēram, TDBEdit un TEdit). Programmā FireMonkey katru vadīklu var saistīt ar jebkura veida datiem. Tā var būt tikai izteiksme, lauks no datu kopas, dati no izstrādātāja izveidotiem objektiem vai metodes izsaukumu rezultāti.

Turklāt, veidojot aplikāciju, tajā var ielādēt jau gatavu 3D modeli un to izmantot – šādas iespējas bieži vien ir nepieciešamas gan biznesa, gan inženierzinātņu aplikācijās. Mums ir klients, kas veido lietojumprogrammas loģistikai. Viņiem bija ar Delphi uzbūvēta informācijas sistēma un tajā lietojumprogramma, kas zīmēja plānu un attēloja informāciju no datu avotiem. Viņi nesen izdarīja ko interesantu - uzzīmēja pilnībā automatizētu 3D noliktavu AutoCAD, un to aplikācija ļauj redzēt, kā automātiskais iekrāvējs pārvietojas pa noliktavu un novieto preces plauktos. Un viņi attiecīgajā attēlā izliek datus no avotiem.

Lietojumprogrammu stilu maiņas piemēri

KP: Kādi 3D modeļu formāti pašlaik tiek atbalstīti?

DI.:Šajā laidienā mēs atbalstām modeļu ielādi no AutoCAD, Collada (atvērtā koda 3D modelēšanas rīks. - Piezīme. ed.), Maya, OBJ formāts, ko atbalsta daudzi 3D grafikas pārdevēji.

KP: Kādus citus formātus plānots pievienot?

DI.: Plānojam pievienot 3DS (3D Studio MAX), SVG (parasti šis formāts tiek izmantots 2D vektorgrafikai, bet dažreiz arī 3D), Google SketchUp. Mēs varam atbalstīt arī citus formātus.

KP: Vai 3D modeļu izmantošanai lietojumprogrammās, kas veidotas ar FireMonkey, ir nepieciešama atbilstoša 3D modelēšanas rīka licence?

DI.: Nē, tā nav. Viss, ko mēs darām, ir nolasīt modeļa failu. Mēs importējam modeli, bet neeksportējam (lai gan, protams, varat uzrakstīt lietojumprogrammu, kas saglabā modeli jūsu formātā). Mēs nepretendējam uz 3D modelēšanas rīku ražotājiem – šim nolūkam varat izmantot AutoCAD, 3D Studio Max, Maya vai jebkuru citu 3D modelēšanas rīku, un izveidotos modeļus importēt mūsu aplikācijās.

KP: Cik efektīvas ir lietojumprogrammas, kas veidotas, izmantojot FireMonkey mūsdienu aparatūras platformās?

DI.: Veiktspēja ir diezgan augsta. Piemēram, 3D formu ar trim sfērām un trim gaismām MacBook Pro var atveidot ar ātrumu 100 kadri sekundē. Un tas var sasniegt 600 - tas ir atkarīgs no tā, ko tieši mēs darām. Atkal, tas viss ir atkarīgs no GPU jaudas.

KP: Vai tas nozīmē, ka ar FireMonkey palīdzību var izveidot mūsdienu prasībām atbilstošas ​​spēles?

DI.: Mēs nepozicionējam savus izstrādes rīkus kā spēļu rīkus. Tomēr, izmantojot mūsdienu GPU augsto veiktspēju, jūs varat arī izveidot spēles ar FireMonkey - galu galā tās tiek veidotas, izmantojot Direct3D vai OpenGL.

KP: Kādu darbu jūs pašlaik darāt žestu atpazīšanas atbalsta jomā un citas jaunas lietas? Vai šāds atbalsts ir pieejams?

DI.:Šajā laidienā mums vēl nav žestu atbalsta. Žestu vadība tiks pievienota nākamajā FireMonkey laidienā, taču pašlaik varat izmantot operētājsistēmā iebūvēto žestu atbalstu.

Mihails Filippenko, Fast Reports, Inc direktors.

K.R.: Jau teicām, ka FireMonkey tehnoloģijai ir krievu saknes - tās pamati tika radīti mūsu valstī, un tad pati tehnoloģija un tās izstrādātāji apvienojās Embarcadero. Kopumā ir patīkami redzēt Krievijas komponentes pieaugumu RAD Studio un Delphi. Tā ir mūsu attīstības centra Sanktpēterburgā darbība un neatkarīgo Krievijas izstrādātāju ieguldījums. Piemēram, Rad Studio XE2 ietver FastReport atskaišu ģeneratoru, kas ir pazīstams visā pasaulē un ļoti populārs mūsu valstī. Viņš ir no Rostovas pie Donas.

KP: Es gribētu runāt par kompilatoriem. Kāds kompilators tiek izmantots iOS lietotņu izveidei?

DI.: Mums nav sava Delphi kompilatora iPhone vai iPad - mēs vēl neesam izstrādājuši kompilatorus šajās ierīcēs izmantotajiem ARM procesoriem. Operētājsistēmā iOS mēs īslaicīgi izmantojam Free Pascal kompilatoru un izpildlaika bibliotēku. Bet mēs strādājam pie nākamās paaudzes kompilatoriem, tostarp tiem, kas paredzēti ARM procesoriem. Bet ir kompilatori operētājsistēmai Windows un Mac OS, jo abas aparatūras platformas ir balstītas uz Intel procesoriem.

KP: Un kas pēdējos divos gados paveikts kompilatoru izstrādes jomā?

DI.: Mums ir 32 un 64 bitu Delphi kompilatori operētājsistēmai Windows un Mac OS. Un mēs strādājam pie jaunas Delphi un C++ kompilatoru paaudzes. Darbs pie tiem vēl turpinās, taču, kad tas būs pabeigts, mums būs Delphi kompilatori ARM procesoriem, Android platformām, Linux un citam. Un mums būs 64 bitu C++ kompilatori operētājsistēmai Windows un citām platformām, kas ir saderīgi ar jaunāko C++ valodas standartu, ko tikko pieņēma ISO.

KP: Kas šodien notiek ar mākoņdatošanas atbalstu Embarcadero izstrādes rīkos?

DI.: Izmantojot RAD Studio XE 2, mēs atbalstām lietojumprogrammu migrēšanu uz Microsoft Azure vai Amazon EC2 mākoni, izmantojot platformas palīgu. Un mums ir servera komponenti Cloud Storage for Azure un Amazon S3 tabulu, bināro datu un ziņojumu rindu glabāšanai. Iepriekšējā RAD Studio XE versijā mēs arī atbalstījām lietojumprogrammu izvietošanu Amazon EC2, taču nebija krātuves atbalsta.

Mākoņdatošanas atbalsts programmā RAD Studio XE 2

KP: Pirms diviem gadiem jūs runājāt par jauno All-Access risinājumu. Cik tas bija pieprasīts? Kādas ir tās priekšrocības sistēmu integratoriem un izstrādātājiem?

DI.: All-Access risinājums un AppWave mākoņa rīks tiek plaši izmantoti visā pasaulē. Tie ir izstrādāti, lai atvieglotu gan mūsu uzņēmuma, gan trešo pušu lietojumprogrammu lietošanu. Faktiski tas ir risinājums licenču un lietojumprogrammu pārvaldībai, un tas ir ērti lieliem uzņēmumiem. Mazāki uzņēmumi, kuriem nav īpašas lietojumprogrammu pārvaldības komandas, var ievietot lietojumprogrammu repozitorijā, atlasīt lietotājvārdus no datu bāzes un padarīt šīs lietojumprogrammas pieejamas lietošanai, neatceroties, kur atrodas licences atslēga un cik licenču ir pieejamas. All-Access un AppWave pārlūks ir izstrādāti, lai pārvaldītu gan versiju izveidi, gan piekļuves kontroli.

K.R.: Tirgus ir tik daudzveidīgs un lietotāji ir tik dažādi, ka ar vienu risinājumu nav iespējams apmierināt visas vajadzības. Tāpēc mēs tiecamies pēc dažādiem "iepakošanas" risinājumiem. Mēs esam paveikuši daudz darba, lai vienotu licencēšanu, licenču pārvaldību un produktu instalēšanu. Šajā risinājumu līnijā ir iekļauti licenču un piekļuves pārvaldības rīki ne tikai Embarcadero produktiem, bet arī jebkuriem citiem produktiem, ieskaitot uzņēmumu iekšējās izstrādes.

Joprojām turpinās izstrādes rīku apvienošana efektīvos lietotāju komplektos. Mums ir All-Access — superkomplekts, kas apvieno visus Embarcadero produktus. Ja klients iegādājas All-Access Platinum versiju, viņš saņem visus Embarcadero rīkus. Bet dažreiz šis komplekts izrādās lieks, piemēram, mēs izveidojām divus citus komplektus datu bāzes speciālistiem - DB Power Studio Developer Edition un DB Power Studio DBA Edition. Atšķirība starp tiem ir tāda, ka izstrādātājam mēs piedāvājam RapidSQL - servera koda izstrādes rīku, bet administratoram ir iebūvēts DBArtizan - datu bāzes administrēšanas rīks, plašāks produkts nekā RapidSQL. Profesionāļiem mums ir šādi All-Access komplekti: visu produktu komplekts, DB Power Studio izstrādātājiem, DB Power Studio administratoriem, ER Studio Enterprise Edition arhitektiem un ikvienam, kas iesaistīts modelēšanā. Ir kombinācijas lietojumprogrammu izstrādei un administratoriem. Delphi ir izstrādātāju rīks, un ir ļoti lietderīgi tam pievienot SQL izstrādes rīkus un optimizācijas rīkus. Visbeidzot, DB izmaiņu pārvaldnieks ir ļoti loģisks rīks, lai pārvaldītu to izmaiņu sarežģītību, kas notiek datu bāzēs to dzīves cikla laikā.

Tādējādi All-Access ir lielas dažādu produktu komplektu grupas vadītājs.

KP: Ja nav noslēpums, kurš Krievijā izmanto All-Access?

K.R.: Mums ir klienti, kuri iegādājās All-Access, pamatojoties uz Delphi. Daudzi no viņiem veido sarežģītas klienta-servera sistēmas, izmantojot SQL Server un Oracle, un viņiem uzreiz iepatikās mūsu starpplatformu datu bāzes rīkkopa. Mums ir klientu uzņēmums, kas strādā ar Delphi kopš pirmās versijas un pirms gada pārcēlās no Delphi uz All-Access. Divi rīki, kurus garantēti izmantos visi šī uzņēmuma izstrādātāji, ir Delphi un DBArtisan. Un ir klienti, kuri nāca uz All-Access no datu bāzes puses. Viņu galvenais uzdevums ir administrēt datu bāzes, taču viņi reizēm izstrādā arī lietojumprogrammas. Klienti, kas izmanto All-Access, ir mediju uzņēmumi, mašīnu ražotāji un citas nozares.

Atsevišķi es vēlētos pakavēties pie maziem uzņēmumiem. Ļoti bieži mazās komandās izstrādātājs dara visu, un šāds uzņēmums dažkārt pērk lielas All-Access pārtikas pakas vienam vai diviem izstrādātājiem. Lielās komandās netiek mudināts, ka izstrādātājs pilda arī, piemēram, datu bāzes administratora lomu, tāpēc tur parasti populāras ir nelielas pārtikas pakas, un mazos uzņēmumos šāda pienākumu kombinācija ir visai pieņemama.

Delphi Architect ir plaši tirgots produkts, kas ietver modelēšanas un programmēšanas rīkus. Tomēr pārdoto kopiju skaits ir mazāks nekā Delphi Enterprise versijām, taču tas ir arī liels. Es atzīmēju, ka 2010. gadā mēs bijām labākā valsts pārdošanas apjoma ziņā, neskatoties uz to, ka visas valstis pārdzīvoja krīzi. Šis pieaugums bija saistīts ne tik daudz ar ekonomiskiem faktoriem, cik ar to, ka 2009. gada beigās iznākusī RAD Studio XE versija izrādījās ļoti pieprasīta. Un, lai gan mēs sagaidām turpmāku pārdošanas apjomu pieaugumu.

Esam spēruši vēl vienu saprātīgu soli, kas Krievijā ir ļoti pieprasīts. Dažādu mūsu produktu versiju legalizācijas pakāpe ir atšķirīga: jo augstāka versija, jo legalizētāka, jo agrāk programmatūra netika tik aktīvi pirkta. Sākot ar RAD Studio XE, licence attiecas uz versijām 2010, 2009, 2007 un pat Delphi 7, plaši izmantotu produktu.

Mūsdienās izstrādātāji saskaras ar faktu, ka viņiem ir gan jauni projekti, gan projekti atbalsta stāvoklī. Liels skaits projektu ir migrēti no agrīnajām Delphi versijām uz 7. versiju un paliek šajā versijā, turpinot strādāt ar salīdzinoši maziem resursiem. Neviens tos nepārvieto uz jaunākām versijām, taču tās tiek saglabātas dzīvotspējīgas. Un tagad par mazu naudu (mazāk par Delphi 7 licences cenu) ļaujam iegūt gan RAD Studio XE, gan Delphi 7 - proti, legalizējam izstrādātāju gan jaunu projektu realizācijai, gan atbalsta projektiem.

KP: Kā jūs vērtējat Embarcadero kopienas pašreizējo stāvokli?

DI.:Šī kopiena ir liela un ļoti prasīga. Viņiem vajag visu un uzreiz – viņi ir izstrādātāji. Bet dažreiz ir nepieciešams ilgs laiks, lai kaut ko sakārtotu.

Pirms dažiem gadiem mēs izmantojām Windows komponentu arhitektūru un ievietojām to Linux galddatoros. Tagad mēs redzam, ka tas nebija pareizs lēmums. Pareizais lēmums ir izveidot platformu lietojumprogrammām. Lietojumprogrammām pat dažādām platformām ir izvēlnes, logi, grafika, piekļuve tīklam un piekļuve ierīcēm. Dažādām platformām var būt dažādi plūsmas kontroles vai izņēmumu apstrādes modeļi, taču lietojumprogrammas kodā redzam tos pašus mēģinājuma blokus. Mūsu uzdevums ir nodrošināt, lai izstrādātājiem būtu viegli izveidot biznesa aplikācijas un tās kompilēt tām platformām, uz kurām tās paredzēts lietot, neatkarīgi no tā, kā ir sakārtota attiecīgo procesoru instrukciju sistēma un kādas vēl ir šo platformu iespējas. Un FireMonkey ir tieši tas, kas jums nepieciešams, lai atrisinātu šo problēmu.

KP: Ja uzņēmums izveido jaunu ierīci un vēlas tai FireMonkey atbalstu, vai tas būtu iespējams?

DI.: Ar jaunās paaudzes kompilatoriem, kuriem būs no platformas neatkarīga priekšgala un platformas atkarīga aizmugure, tas būs pilnīgi iespējams. Tikmēr katrai operētājsistēmai mēs no jauna izveidojam kompilatoru un izpildlaika bibliotēku.

Jebkurai modernai jaunai ierīcei parasti ir grafiskā lietotāja saskarne (daudzām no tām ir divkodolu procesors un GPU) un standarta SDK izstrādātājiem. Tas viss vienkāršo FireMonkey ierīču atbalsta izveidi. Ja jaunajā ierīcē ir tikai bibliotēkas 2D grafikai, piemēram, Quartz, mēs varēsim atbalstīt šādu ierīci programmā FireMonkey, taču tas prasīs aptuveni vairākus mēnešus. Tomēr daudz kas ir atkarīgs no platformas: ne visas platformas atbalsta visas funkcijas, piemēram, iOS nav izvēlņu un dialoglodziņu, un šādu aplikāciju formās nevarēs ievietot atbilstošos komponentus.

KP: Vai ir kaut kas mainījies darbā ar partneriem politikā? Kas tiek darīts, lai palielinātu jūsu produktu lietotāju īpatsvaru? Kas tiek darīts Krievijā?

DI.: Mūsu partneru ekosistēma ir plaša – ir simtiem tādu instrumentu un komponentu ražotāju, kas mūsu produktos nav atrodami, un mums ir tehnoloģiju partnerības programma. Tāpēc izstrādātājiem ir pieejams plašs komponentu, tehnoloģiju un rīku klāsts. Un risinājumi, ko viņi rada saviem klientiem, ir labāki nekā tad, ja tiktu izmantoti tikai mūsu produkti. Un pārdošanai mums ir biroji daudzās valstīs, tālākpārdevēji un izplatītāji.

K.R.: Mums ir svarīgs nevis partneru skaits, bet gan katra konkrētā partnera darba kvalitāte. Pagaidām mēs vēlamies koncentrēties uz ciešu sadarbību ar esošajiem partneriem, lai gan partneru loks joprojām ir atvērts. Mums ir daudz partneru, un mums ir jāpalīdz viņiem tehnoloģiju jomā. Mēs strādājam ar izstrādātājiem, un viņi zina, ko vēlas, un zina, kas ir pieejams tirgū, un partneru iespējām ir jāatbilst tam.

Mums ir biznesa partneri, kuri ir ieguldījuši lielus ieguldījumus Embarcadero kā biznesa virzienā - viņiem ir apmācīti speciālisti, mūsu produktu mārketings, īpaši darbinieki, kuri ir atbildīgi par šo jomu un uzrauga, kas notiek ar mūsu produktiem, cenrādi, mārketingu. Protams, viņi ir veiksmīgāki mūsu produktu pārdošanas jomā nekā uzņēmumi, kas pārdod mūsu produktus katrā atsevišķā gadījumā.

KP: Deivid, Kiril, liels paldies par interesanto interviju. Mūsu izdevuma un mūsu lasītāju vārdā novēlu jūsu uzņēmumam turpināt veiksmi, veidojot jūsu apbrīnojamos rīkus, kas izstrādātājiem ir tik ļoti nepieciešami!

Jautājumus uzdeva Natālija Elmanova

FireMonkey ir "jaunā Delphi" galvenā tehnoloģija. Lūdzu, pastāstiet mums par šīs fundamentāli jaunās bibliotēkas mērķiem, iespējām un tehniskajiem aspektiem. Pēc kāda laika, atskatoties pagātnē, cik smags un pamatots bija jūsu atteikums tālāk attīstīt superpopulāro VCL?

Tas tika izvēlēts kā galvenais Delphi tehnoloģiju attīstības virziens, lai sasniegtu konkrētu mērķi – vairāku platformu izstrāde no vienas vides, balstoties uz vienotu pirmkoda bāzi, un bez nepieciešamības veikt radikālu izstrādātāju pārkvalifikāciju. Tagad klasiskā un superpopulārā VCL ietvaros tas nebija iespējams, tā saistība ar WinAPI bija pārāk cieša, varētu teikt, “ģenētiskā līmenī”.

VCL komponentiem nebija "abstrakta" slāņa starp funkcionālo līmeni saskarnes ziņā un to kartēšanas mehānismiem. Funkcionālais līmenis- kā tas darbojas kā vadīkla, uz kādiem notikumiem tā reaģē, kāda veida lietotāja mijiedarbību tā nodrošina. Displejs- uz platformu orientētu renderēšanas metožu izsaukšana kā sava veida attēls, ko veido rastra objekti un vektoru primitīvi. FireMonkey sākotnēji ieviesa principu stingri sadalīt kontroli divās daļās: "uzvedības" un "vizuālā".

Vsevolods Ļeonovs, Embarcadero Technologies

Pirmais kopumā atkārtos nevis VCL pamatus, bet gan objektorientētās programmēšanas būtību. Komponents ir klase, komponentu klases veido hierarhiju, kurā var atšķirt ģimenes un moduļus. Komponenta klasei ir maz sakara ar to, kā tā tiek renderēta.

Vizuālais "attēls" veidojas dinamiski, tas nav iekodēts komponentu klasē. FireMonkey attēls vai "stils" tiek ielādēts komponentā, kad lietojumprogramma tiek startēta. Mums ir daži komponenta funkcionālie ietvari, un "apvalku" vai "apšuvumu" var mainīt, bet kāpēc? Tāpēc FireMonkey aplikācijas izskatās autentiskas uz jebkuras platformas – Windows 7, Windows 8, Mac OS, iOS un tuvākajā nākotnē arī Android. Tradicionālā monolītā VCL klases struktūra to nevarēja nodrošināt.

Šeit īpaša loma ir tehnoloģiskajai pieejai. Principā jūs varat aizņemt VCL bibliotēku un "piebāzt" WinAPI ar visiem citiem iespējamajiem platformas izsaukumiem. Ļoti ierobežotā komponentu apakškopā to joprojām var izdarīt, taču VCL satur vairākus simtus komponentu, tāpēc šī pieeja varētu vienkārši "nogalināt" VCL. Tika nolemts nepieskarties VCL un izstrādāt jaunas funkcijas jaunajā platformā - FireMonkey. Šai tehnoloģijai ir pat zināma tehniska elegance – konkrētas platformas projekta komplektēšanas brīdī Delphi IDE pieslēdz nepieciešamo kompilatoru, un saskarnes komponenti saņem platformas stilu.

Lietotājam tas ir viens peles klikšķis un tas pats pirmkods, Delphi tas ir daudzu gadu smags izstrādātāju darbs, lai izveidotu šādu daudzplatformu bibliotēku.

Kad kļuva skaidrs, ka FireMonkey tiks ieviesta kā atsevišķa jauna platforma, bija jāizvēlas pareizā līdzāspastāvēšanas stratēģija: Embarcadero nekādā veidā nevēlējās negatīvi ietekmēt VCL lietotājus. Tāpēc esam izvēlējušies šādu plānu: VCL paliek ideoloģiski un arhitektoniski stabils, lai nodrošinātu pēc iespējas lielāku savietojamību, atvieglojot projektu migrēšanu uz modernām versijām. FireMonkey attīstība notiks pa dabisku un paralēlu ceļu, neatskatoties uz VCL.

Šī risinājuma vājā vieta ir diezgan problemātiskā migrācija no VCL uz FireMonkey viena projekta ietvaros. Bet, no otras puses, jaunam projektam izstrādātājs var izvēlēties FireMonkey, lai nodrošinātu iegūtās lietojumprogrammas daudzplatformu raksturu. Līdz ar XE4 iznākšanu ar iOS atbalstu jau varam runāt par Delphi spēcīgo konkurences priekšrocību mobilajai attīstībai korporatīvajā vidē, kas tiks palielināta pēc plānotā Android atbalsta ieviešanas.

Tāpēc nav skaidra "atteikuma" no VCL izstrādes. Jaunās versijās tiek izstrādāta arī Delphi VCL daļa. Tas ietver 64 bitu atbalstu un vizuālo komponentu stila ieviešanu, elastīgu dinamisko saišu jeb "saistīšanas" mehānisma ieviešanu, kā arī FireDAC bibliotēkas iekļaušanu darbam ar datu bāzēm VCL projektos. Vienkārši uz milzīgā kvalitatīvā lēciena fona FireMonkey dēļ VCL progress izskatās nedaudz neizpaustas. Bet lai kā arī būtu, VCL ir neatņemama Delphi sastāvdaļa un tā paliks vēl daudzus gadus. Lai gan platformu attīstība un pašreizējais stāvoklis OS jomā galddatoru sistēmām un mobilajām ierīcēm ir tāds, ka nākotne nepārprotami ir saistīta ar FireMonkey.

Intervijā jau apspriedām iOS atbalstu, pastāstīsim saviem lasītājiem par jaunāko RAD Studio XE4 atbalstu citām jaunākajām tehnoloģijām, piemēram, Windows 8 un WinRT, 64 bitu sistēmām, MacOS un tā tālāk. Vai varat uzskaitīt, ko vēl varat piedāvāt mūsdienīgam, inovāciju izlutinātam programmētājam?

Visticamāk, mūsdienu programmētājs nav "lutināts" ar jauninājumiem. Lieliem projektiem jebkura "inovācija" bieži vien pārvēršas par gigantisku darba apjomu.

Piemēram, visi ilgi gaidīja, daudzi uzreiz metās pārsūtīt savus kodus uz jaunu platformu. Taču izrādās, ka pat ļoti profesionālas komandas tam nav gatavas. Kompilējams 64 bitu kods nenozīmē, ka tas ir iespējams. Sāka parādīties "jaunības grēki", piemēram, izmantojot norādījumus, pieņemot, ka adreses lielums ir 4 baiti. Pārbaužu veikšanas kultūras trūkums kopā ar tehnoloģisko nevēlēšanos ieviest šo procesu īsā laikā.

Un šeit - jo lielāks projekts, ko mēra, piemēram, pēc pirmkoda rindiņu skaita, jo rūpīgāk un līdzsvarotāk programmētāji izturas pret dažāda veida jauninājumiem, sākot no "pogas" parādīšanās saskarnē līdz "sintaktiskajam cukuram" kompilatorā.

Viens no šiem “problemātiskajiem” sasniegumiem bija Windows 8 izlaišana. Es personīgi kā datoru lietotājs un vienkārši moderns IT speciālists esmu sajūsmā par Windows 8. Bet izstrādātājiem, kuriem kā slodze tika nosūtīta Windows 8 datoru partija ar tehniskajām specifikācijām izstrādei saskaņā ar jauno OS, tas nozīmē zināmas grūtības.

Mēs centāmies nodrošināt atbalstu izstrādei saskaņā ar jauno šīs OS saskarni pēc iespējas ērtāk un nesāpīgāk. Tāpēc gan VCL, gan FireMonkey ir ieviesti īpaši stili, un programmētājs var vai nu pārbūvēt lietojumprogrammas saskarni, vai izveidot jaunu lietojumprogrammu, kas pēc izskata neatšķirsies no Windows 8 “vietējās”. Protams, ir nepieciešams "native" atbalsts operētājsistēmai Windows 8, izmantojot WinRT. Bet šeit ietekmē mērķu prioritāšu noteikšana mūsdienu apstākļos. Mac OS, iOS, Android tuvākajā nākotnē vēl nedod iespēju runāt par pilnīgu WinRT atbalstu tuvākajā nākotnē.

Embarcadero stratēģiskais mērķis, protams, ir vairāku platformu. RAD Studio XE4 izlaišana bija svarīga, galvenokārt iOS atbalsta dēļ. Aktīvs programmētājs, kurš izmanto VCL, dažu stundu laikā var sākt izstrādāt iOS. Pat vienkāršu mobilo aplikāciju var uzreiz pārveidot par spēcīgu projektu, kas darbojas esošajā infrastruktūrā. Nedomājiet, ka tas ir tikai jauns FireMonkey kompilators un jauns stils, kas atbilst iOS saskarnei.

Tas ietver jaunu vizuālo noformētāju, iebūvētu atbalstu dažādiem formas faktoriem, datu piekļuves bibliotēkas, tostarp jauno FireDAC, un LiveBindings tehnoloģiju elastīgai un dinamiskai korporatīvo datu saistīšanai. Visi šie jauninājumi nāk vienlaicīgi – operētājsistēmai Windows, Mac OS un iOS. Operētājsistēma Mac OS neattīstās tik strauji, tāpēc nav tādu problēmu kā pāreja no Windows 7 uz Windows 8. Bet parādījās Retina displeji, un tam bija jāpievērš īpaša uzmanība. Tagad jebkura MacOS lietojumprogramma, kas izveidota Delphi XE4, automātiski ietver divus stilus - "parasto" un "augstas izšķirtspējas".

Tas. tai pašai lietojumprogrammai var būt tādas pašas kvalitātes "native" interfeiss jebkurā Apple galddatorā.

Embarcadero nevēlas "pārsteigt", "izbrīnīt" vai pat "izklaidēt" izstrādātājus ar saviem jaunajiem novatoriskajiem izlaidumiem. Drīzāk, gluži otrādi, IT sfēra jau ir pilna ar dažādiem pārsteigumiem: jaunas ierīces, jaunas platformas, jauni lietotāji, viņu jaunās vajadzības, jauni mijiedarbības scenāriji. Pievienojiet tam jaunas programmatūras izstrādes tehnoloģijas, un programmētājiem vienkārši nebūs laika izveidot jaunas sistēmas un uz esošajām sistēmām - viņi darīs tikai to, lai migrētu no vienas vides uz citu, no vecās bibliotēkas uz jaunu, no vienas valodas uz citu. cits.

Bet mēs neatzīstam visa jaunā noraidīšanu. Mēs tikai vēlamies nodrošināt nepārtrauktību visam - kodam, saskarnei, projektam, pat profesionālajām iemaņām, parādoties jaunām platformām un ierīcēm. Var teikt, ka mēs cīnāmies ar neveselīgu konservatīvismu saistībā ar jaunām platformām uz veselīga konservatīvisma rēķina izstrādes rīkos. Negaidiet no Embarcadero eksotiskus produktus, nestandarta programmēšanas valodas un neparastus izstrādes rīkus.

Pie mums jūs vienmēr atradīsiet vizuālo izstrādi, klasiskās valodas, "native" kodu un ļaujiet mērķa platformām jūsu lietojumprogrammām, kas izveidotas tādā pašā pārbaudītā klasiskā veidā, būt jaunas.

Kas ir Uguns mērkaķis?

FireMonkey (FMX) ir ietvars starpplatformu izstrādei gan galddatoru sistēmām (Windows, Mac OS+ tuvākajā nākotnē plānots atbalstīt servera daļu uz Linux), gan mobilajām ierīcēm (iOS un Android), izmantojot Delphi/C++ valodu. .

Īpatnības:

• viena koda bāze visām platformām;

• jebkura vadīkla (vizuālais komponents) var būt konteiners (sākotnējais) citiem komponentiem;

• ļoti progresīva komponentu relatīvā izkārtojuma (20 veidu) klātbūtne veidlapā;

• LiveBinding ļauj savienot jebkura veida datus vai informāciju ar jebkuru lietotāja interfeisu vai grafiskiem objektiem;

• formas/komponentu stilu klātbūtne;

• Vairāku ierīču priekšskatījums ļauj pielāgot vizuālo prezentāciju katrai platformai;

• FireUI tiešraides priekšskatījums — reāllaikā parāda lietotnes skatu reālajās ierīcēs.

Iespējas:

• katras platformas vietējā API izmantošana, kā arī iespēja izsaukt trešo pušu vietējās bibliotēkas;

• mijiedarbība ar visiem sensoriem (GPS, akselerometrs, kompass, Bluetooth (ieskaitot LE) un citi);

• atbalsts push paziņojumiem, IoT;

• atbalsts asinhroniem HTTP pieprasījumiem;

• atbalsts lielākajai daļai datu bāzu (MsSQL, MySql, Oracle, PostgreSQL, MongoDB utt.);

• darbs ar Cloud Service (Amazon, Azure);

• Android pakalpojumu atbalsts.

Mīnusi (pašlaik):

• atbalsta trūkums vietējo klašu pielāgošanai;

• konkrētu lietu realizācija ir vai nu neiespējama (logrīki, paplašinājumi (iOS) utt.), vai arī nepieciešama deja ar tamburīnu (fona serviss, apraides ziņojums utt.);

• pielāgošana Splash screen (sākotnējais ekrāns), maigi izsakoties, nē;

• FMX vadīklas izmanto savu renderēšanu (vizualizāciju, zīmēšanu), kas ir tīri vizuāli līdzīga vietējai;

• vietējo vadības ierīču izmantošana ir saistīta ar lielām ķermeņa kustībām;

• ar lielu komponentu ligzdošanu notiek neticamas lietas: lietojumprogramma avarē dažādās vietās, pazūd fokuss, sasalst utt.;

• lietojumprogrammas atkļūdošanas informācijas saturs mobilajās platformās ir nulle;

• kļūdu apraksti mobilajās platformās tiek samazināti līdz bezjēdzīgiem “Kļūda 0x00000X”;

• kompilācijas laiks vēlas būt labākais vidējiem un lieliem projektiem;

• nepieciešamība izmantot failu, lai uzlabotu mobilās lietojumprogrammas katrai platformai;

• nav atbalsta Intel Atom arhitektūrai;

• neadekvāta cena salīdzinājumā ar konkurentiem.

Plusi:

• ļoti aktīva pēdējā laikā gan produkta, gan kopienas attīstība, atbalsts arvien jaunām tehnoloģijām;

• milzīga skaita bezmaksas un komerciālu komponentu klātbūtne;

• lietojumprogrammas ātrums ir ļoti tuvu vietējam;

• ļoti attīstīts vizuālais redaktors un vide kopumā, stilu klātbūtne;

• iespēja pārbaudīt programmu Win un tikai pēc tam izvietot to ierīcēs, kas ievērojami paātrina izstrādi;

• mainīt režīmu/platformu ar plaukstas locītavu;

• PAServer nodrošina vienkāršu mijiedarbību ar MacO, izstrādājot Apple OS;

• 3D grafikas atbalsts no kastes.

Nobeigumā es vēlos teikt, ka pēdējo pāris gadu laikā FireMonkey ir kļuvis par profesionālu rīku biznesa lietojumprogrammu un ne tikai platformu izstrādei. Daudzas nepilnības pamazām tiek risinātas un ar katru izlaidumu produkts kļūst modernāks un pašpietiekamāks, zūd arī esošā skepse pret pašu Delfu valodu, kas saistīta ar daudzu gadu stagnāciju. Jaunu projektu rakstīšana vietnē FireMonkey ir "droša" un daudzsološa.

Ir pagājis pietiekami daudz laika, kopš termins FireMonkey ir kļuvis vairāk vai mazāk pazīstams ja ne visiem izstrādātājiem, tad vismaz tiem, kas lieto Delphi. Šajā laikā bija grāmatas par FireMonkey, raksti par FireMonkey, ieraksti par FireMonkey daudzos emuāros. Ir ļoti interesanti to visu lasīt. Bet neviena teorija nevar aizstāt praksi. Un man, tāpat kā daudziem iepriekš, bija nieze mēģināt kaut ko uzrakstīt, izmantojot FireMonkey.

To darot, tomēr radās problēma. Nez kāpēc nolēmu, ka vienkārši jāīsteno kāds ne pārāk sarežģīts darba projekts.

Lai izskaidrotu, kāpēc man tā izrādījās problēma, būs nepieciešama neliela (rakstīšanas gribas, liriska) atkāpe. Ekskursija manā kā izstrādātāja pagātnē. Izskaidrojiet dažus manus uzskatus par programmēšanu, izmantojot Delphi.

Man jāsaka, ka es sāku lietot Delphi operētājsistēmā Windows 3.1, tas ir, no pirmās versijas. Un kopš tā laika es studēju VCL. Mācījusies oriģinālā, tā teikt. Noskatījās, uzrunāja, izsekoja pirmkodus. Atkal un atkal.

Ir zināms, ka dažādos laikos Delphi piegādātajā komponentu komplektā bija iekļauti trešo pušu komponenti, kuriem bija jāaizpilda nepilnības VCL un kuri, iespējams, pirms iekļaušanas tika pakļauti kaut kādai kvalitātes kontrolei. Dažas no šīm sastāvdaļām tiek piegādātas līdz šai dienai. Ņem to pašu Indy. Negribu nevienu aizvainot, tas ir tīri mans personīgais viedoklis, kas attiecas arī uz mani pašu kā komponentu izstrādātāju: ne viens vien komplekts ir tik dziļi pārdomāts un realizēts kā milzīgs un daudzveidīgs VCL. Nē, es nepretendēju uz galīgo patiesību, un, protams, pašā VCL ir daudz kļūdu, lēmumu, kas izraisa pārpratumus, izraisa noraidījumu un kuriem gribas nepiekrist. Bet man vienmēr radās iespaids par noteiktu vienotu stilu. VCL, manuprāt, ir skaists un spēcīgs kodols, kas atbalsta visu Delphi dizainu un ap kuru ir veidota gan programmatūras infrastruktūra, gan pati izstrādātāju kopiena. Lielā mērā pateicoties VCL, atkal, manuprāt, baumas par Delfu nāvi joprojām ir baumas. Un, kad VCL piegādē tika iekļauti trešo pušu komponenti, tas bija uzreiz pamanāms, tie bija atšķirīgi.

Bet tad pienāk brīdis, un es dzirdu, ka VCL ir novecojusi tehnoloģija. Tehnoloģija, kas jāatstāj pagātnē. Izstrādātājiem vajadzētu ieviest visus savus jaunos projektus uz FireMonkey, bet par vecajiem... būtu jauki tos pārcelt uz jaunām sliedēm. FireMonkey ir visur un vienmēr. Un es to dzirdu no dažādiem avotiem. Un diezgan neatlaidīgi. Nē, VCL neviens nenogalina. viņš paliek pie mums. Bet viņš vairs nav numur viens. Viņam vajadzētu būt pastāvīgajam. Vismaz tā es saprotu, ko runā par produkta nākotni.

Principā es saprotu šo saskaņošanu. Ir apgūts vairāku platformu un, vēl svarīgāk, starpplatformu kurss. Galu galā, kas ir VCL? Vizuālo komponentu bibliotēka. Vizuālo komponentu bibliotēka. Jūs varat tam nepiekrist. Piemēram, es vienmēr uzskatīju daudzus nevizuālus komponentus, nevis komponentus, bet tikai klases, neatņemamu VCL sastāvdaļu un milzīgu skaitu trešo pušu klašu un komponentu - VCL turpinājumu, paplašinājumu. Es nevaru uzskatīt, ka TDataset mantinieki nav daļa no VCL. Lai gan, piemēram, termins DBExpress Library saka, ka tā it kā nav VCL. Acīmredzot Embarcadero patiešām sadala monolīto, no mana viedokļa, VCL vairākās atsevišķās bibliotēkās. Nē, protams, ne pilnīgi atsevišķi, bet tomēr. Un, ja ņemat šo viedokli, FireMonkey ir paredzēts, lai aizstātu VCL vizuālo daļu (kā man joprojām vajadzētu saukt visu klases un komponentu bibliotēku, varbūt Borland Component Library?).

Kādi ir bibliotēkas vizuālie komponenti? Apmēram zema līmeņa pamata elementi, ko nodrošina operētājsistēma. Logu rokturi, fonti, paši logi, ievades elementi, ziņojumi, ierīču konteksti un daudz kas cits – tie nav Delphi komplektā iekļautās bibliotēkas jēdzieni, bet gan operētājsistēmas koncepcijas. Jā, tieši tā, Windows. Un, ja vēlaties izveidot starpplatformu bibliotēku, tad ir loģiski atteikties no infrastruktūras, ko piedāvā operētājsistēma, kas izpilda programmu, kas rakstīta, izmantojot bibliotēku.

Tas ir tieši tas, ko FireMonkey cenšas darīt. Viņi cenšas izveidot infrastruktūru, kuras pamatā ir dažādu operētājsistēmu atbalstītie pamatā esošie mehānismi, kas var aizstāt pakalpojumu, ko piedāvā pašas operētājsistēmas.

Daudzi atceras, ka mēģinājuši taisītstarpplatformu ne tikai bibliotēka, bet arī pats Delphi. Paralēli Delphi 6 tika izlaists Kylix produkts un CLX bibliotēka. Tas viss tika darīts, lai varētu izstrādāt Linux. Tomēr operētājsistēmā Linux nav daudz tādu pamata GUI logu koncepciju, kādas ir operētājsistēmai Windows. Linux logu saskarne parasti nav vietēja parādība. Šī ir izvēles lietojumprogramma. Un man bija jāraksta kaut kāda sintētiskā bibliotēka. Ar tās palīdzību bija iespējams uzrakstīt programmu gan Windows, gan Linux. Tomēr es joprojām atceros to sajūtu, nevis vilšanos, drīzāk kaitinošas neērtības, ko piedzīvoju, mēģinot izmantot CLX vizuālo komponentu analogus. Es sāku daudz pietrūkt. Tas, ko es darīju nedomājot, izstrādājot ar VCL, izrādījās sarežģīts, ļoti atšķirīgs vai vienkārši neiespējams, izmantojot CLX.

Es jutos apmēram tāpat, pārejot no BDE uz DBExpress. Vecais, pazīstamais no Field Test-a BDE (toreiz Borlands to jau izmantoja Quattro Pro operētājsistēmai Windows un Paradox for Windows, un to sauca ODAPI, pēc tam IDAPI, un tas bija mazāks par, manuprāt, Microsoft ODBC). pasludināja par novecojušu tehnoloģiju, kurai jaunos projektos vajadzētu piekāpties jaunai bibliotēkai. Sākumā man vienmēr kaut kā trūka DBExpress, it īpaši zināšanu.

Tajā pašā laikā es nekādā gadījumā nevēlos lamāt vai kritizēt ne iepriekš uzskaitītās bibliotēkas, ne lēmumus, kas noveda pie to parādīšanās. Tas ir tikai par maniem iespaidiem, dažreiz pirmajiem iespaidiem.

Tagad, iespējams, kļūst nedaudz skaidrāks, kāpēc lēmums rakstīt nelielu darba projektu, izmantojot FireMonkey, radīja vairākas problēmas. Jau daudzus gadus projektu, projektu un projektu izstrādē ir veidojies zināms stereotips, noteikts šablons, ko un kā darīt. Un manā gadījumā nācās saskarties ar faktu, ka veidne ir jāmaina. Tā kā jūs nevarat pārsūtīt visu, ko esat pieradis izmantot VCL, uz projektu, kas veidots uz FireMonkey.

Projekta sākumā es piedzīvoju zināmu deja vu sajūtu. Proti, diskomforta sajūta. Piemēram, parastajiem ievades elementiem nav daudz īpašību. Praksē stingri nostiprinājušies triki, kuru pamatā ir triki, kas saistīti ar dažu operētājsistēmas funkciju zināšanām, jaunā kontekstā nedarbojas. Nemaz nerunājot par to, ka daži komponenti ir radikāli mainījušies.

Nu vēl viena svarīga nianse. Kādi projekti parasti ir jādara darbā, ja tas (darbs) nav saistīts ar kompilatoru rakstīšanu, modelēšanas sistēmām vai ko citu augsti zinātnisku? Es domāju, ka lielākajai daļai tas ir saistīts ar tādu lietu izstrādi, kas ietver datu bāzu izmantošanu. Turklāt kaut kas ļoti zinātnisks var izmantot arī DBVS sniegtos pakalpojumus.

Šeit mani gaidīja vēl viens slazds. Kādu iemeslu dēļ, kad praksē saskaraties ar to, ka FireMonkey nesatur elementus, kas vērsti uz darbu ar datu bāzē glabātajiem datiem, jūs neesat tam gluži gatavs (maigi izsakoties). Lai gan es par to jau esmu lasījis daudzas reizes, un jūs zināt (teorētiski), kas jums vajadzētu izmantot. Tas ir par Live Bindings.

Es nevēlos iesaistīties strīdā par to, vai īstiem foršiem programmētājiem vajadzētu izmantot db-aware komponentus, vai nevajadzētu parādīt, rediģēt un galu galā saglabāt. Kas, atkal, nav ne slikti, ne labi. Man vienkārši tā notika.

Tas noslēdz manu pirmo iespaidu ierakstu. Tālāk seko stāsti par to, ko un kā viņi pārvarēja, strādājot pie projekta.