Ka kaluar mjaft kohë që kur termi FireMonkey është bërë pak a shumë i njohur, nëse jo për të gjithë zhvilluesit, atëherë të paktën për ata që përdorin Delphi. Gjatë kësaj kohe, kishte libra mbi FireMonkey, artikuj mbi FireMonkey, shënime rreth FireMonkey në bloge të shumta. Leximi i gjithë kësaj është shumë interesant. Por asnjë teori nuk mund ta zëvendësojë praktikën. Dhe unë, si shumë më parë, pata një kruarje për të provuar të shkruaj diçka duke përdorur FireMonkey.
Megjithatë, duke vepruar kështu, u shfaq një problem. Për disa arsye, vendosa që thjesht më duhej të zbatoja një projekt pune jo shumë të komplikuar.
Për të shpjeguar pse kjo doli të ishte problem për mua, do të duhet një digresion (do të shkruajë, lirik). Një ekskursion në të kaluarën time si zhvillues. Shpjegoni disa nga pikëpamjet e mia për programimin duke përdorur Delphi.
Duhet të them që kam filluar të përdor Delphi në Windows 3.1, domethënë që nga versioni i parë. Dhe që atëherë unë kam studiuar VCL. Studuar në origjinal, si të thuash. Shikuar, adresuar, gjurmuar kodet burimore. Përsëri dhe përsëri.
Dihet se në periudha të ndryshme grupi i komponentëve të dërguar me Delphi përfshinte komponentë të palëve të treta që supozohej të plotësonin boshllëqet në VCL, dhe që ndoshta kaluan një lloj kontrolli të cilësisë përpara se të përfshiheshin. Disa nga këta komponentë vazhdojnë të furnizohen edhe sot e kësaj dite. Merrni të njëjtin Indy. Unë nuk dua të ofendoj askënd, ky është thjesht mendimi im personal, i cili vlen edhe për veten time si zhvillues i komponentëve: asnjë grup i vetëm nuk është menduar dhe zbatuar aq thellë, si dhe një VCL e madhe dhe e larmishme. Jo, nuk pretendoj të jem e vërteta përfundimtare dhe, natyrisht, ka shumë gabime në vetë VCL, vendime që shkaktojnë keqkuptim, shkaktojnë refuzim dhe me të cilat dikush dëshiron të mos pajtohet. Por gjithmonë kam pasur përshtypjen stil uniform. Ekziston në VCL, për mendimin tim, një bërthamë e bukur dhe e fortë që mbështet të gjithë dizajnin Delphi, dhe rreth së cilës ndërtohen infrastruktura e softuerit dhe vetë komuniteti i zhvilluesve. Falë një pjesë të madhe të VCL-së, përsëri, për mendimin tim, thashethemet për vdekjen e Delphi janë ende thashetheme. Dhe kur komponentët e palëve të treta u përfshinë në dorëzimin e VCL, u vu re menjëherë, ato ishin të ndryshme.
Por më pas vjen momenti dhe dëgjoj se VCL është një teknologji e vjetëruar. Një teknologji që duhet lënë në të kaluarën. Zhvilluesit duhet të zbatojnë të gjitha projektet e tyre të reja në FireMonkey, por për ato të vjetrat ... do të ishte mirë t'i transferoni në binarët e rinj. FireMonkey është kudo dhe gjithmonë. Dhe e dëgjoj nga burime të ndryshme. Dhe me mjaft këmbëngulje. Jo, askush nuk e vret VCL. ai qëndron me ne. Por ai nuk është më numri një. Ai duhet të jetë i palëkundur. Të paktën kështu e kuptoj atë që thuhet për të ardhmen e produktit.
Në parim, unë e kuptoj këtë shtrirje. Është marrë një kurs për multi-platformë, dhe, më e rëndësishmja, për ndër-platformë. Në fund të fundit, çfarë është VCL? Biblioteka e komponentëve vizualë. Biblioteka e komponentëve vizualë. Ju mund të mos jeni dakord me këtë. Për shembull, unë gjithmonë kam konsideruar shumë komponentë jo-vizualë, dhe jo komponentë, por thjesht klasa, një pjesë integrale e VCL dhe një numër të madh klasash dhe përbërësish të palëve të treta - një vazhdim, një zgjerim i VCL . Epo, nuk mund t'i konsideroj trashëgimtarët e TDataset si jo pjesë të VCL. Edhe pse, për shembull, termi DBExpress Library thotë se ai, si të thuash, nuk është një VCL. Me sa duket, Embarcadero e ndan vërtet VCL-në monolit, nga këndvështrimi im, në një numër bibliotekash të veçanta. Jo, sigurisht, jo krejtësisht të ndarë, por gjithsesi. Dhe nëse merrni këtë këndvështrim, FireMonkey ka për qëllim të zëvendësojë pjesën vizuale të VCL (si duhet ta quaj ende bibliotekën e plotë të klasës dhe komponentëve, ndoshta Borland Component Library?).
Cilat janë komponentët vizuale të bibliotekës? Rreth nivelit të ulët, elementet bazë ofruar nga sistemi operativ. Dorezat e dritareve, shkronjat, vetë dritaret, elementet hyrëse, mesazhet, kontekstet e pajisjes dhe shumë më tepër - këto nuk janë konceptet e bibliotekës që vjen me Delphi, por konceptet e sistemit operativ. Po, është e drejtë, Windows. Dhe nëse doni të ndërtoni një bibliotekë ndër-platformë, atëherë është logjike të refuzoni infrastrukturën e ofruar nga sistemi operativ që ekzekuton programin e shkruar duke përdorur bibliotekën.
Kjo është pikërisht ajo që FireMonkey po përpiqet të bëjë. Ata po përpiqen të krijojnë një infrastrukturë të bazuar në mekanizmat themelorë të mbështetur nga sisteme të ndryshme operative që mund të zëvendësojnë shërbimin që ofrojnë vetë sistemet operative.
Shumë kujtojnë se u përpoqën të bëninndër-platformë jo vetëm bibliotekën, por vetë Delphi. Paralelisht me Delphi 6, u lëshuan produkti Kylix dhe biblioteka CLX. E gjithë kjo është bërë për të qenë në gjendje të zhvillohet për Linux. Sidoqoftë, Linux nuk ka shumë nga konceptet bazë të dritares së GUI-së që ka Windows. Ndërfaqja e dritares për Linux në përgjithësi nuk është një fenomen vendas. Ky është një aplikacion opsional. Dhe më duhej të shkruaja një lloj biblioteke sintetike. Me ndihmën e tij, ishte e mundur të shkruante një program si për Windows ashtu edhe për Linux. Megjithatë, më kujtohet ende ajo ndjenjë, jo e zhgënjimit, por e bezdisjes së bezdisshme, që përjetova kur u përpoqa të përdorja analogët e komponentëve vizualë nga CLX. Fillova të më mungonte shumë. Ajo që bëja pa menduar gjatë zhvillimit me VCL doli të ishte e vështirë, shumë e ndryshme ose thjesht e pamundur për t'u bërë duke përdorur CLX.
Ndjeva pothuajse të njëjtën gjë kur kalova nga BDE në DBExpress. I vjetër, i njohur nga Field Test-a BDE (Borland atëherë e përdorte tashmë në Quattro Pro për Windows dhe në Paradox për Windows, dhe u quajt ODAPI, dhe më pas IDAPI, dhe ishte një prerje më lart, për mendimin tim, ODBC e Microsoft) u shpall teknologji e vjetëruar, e cila duhet t'i linte vendin në projekte të reja një biblioteke të re. Gjithmonë më mungonte diçka në DBExpress në fillim, veçanërisht njohuritë.
Në të njëjtën kohë, në asnjë mënyrë nuk dua të qortoj ose kritikoj as bibliotekat e listuara më lart, as vendimet që çuan në shfaqjen e tyre. Bëhet fjalë vetëm për përshtypjet e mia, ndonjëherë përshtypjet e para.
Tani, ndoshta, bëhet pak më e qartë pse vendimi për të shkruar një projekt të vogël pune duke përdorur FireMonkey solli një sërë problemesh. Për shumë vite, në zhvillimin e projekteve, projekteve dhe projekteve, është formuar një stereotip i caktuar, një shabllon i caktuar se çfarë dhe si duhet bërë. Dhe në rastin tim, më duhej të përballesha me faktin se shablloni duhet ndryshuar. Sepse nuk mund të transferoni gjithçka që jeni mësuar të përdorni VCL në një projekt të ndërtuar në FireMonkey.
Në fillim të projektit, përjetova një ndjenjë deja vu. Përkatësisht, një ndjenjë shqetësimi. Për shembull, elementët e zakonshëm hyrës nuk kanë shumë veti. Truket që janë vendosur fort në praktikë, bazuar në truket që lidhen me njohjen e disa veçorive të sistemit operativ, nuk funksionojnë në një kontekst të ri. Për të mos përmendur që disa komponentë kanë ndryshuar rrënjësisht.
Epo, një nuancë tjetër e rëndësishme. Çfarë lloj projektesh duhet të bëhen zakonisht në punë, nëse ajo (puna) nuk lidhet me përpiluesit e shkrimit, sistemet e modelimit ose ndonjë gjë tjetër shumë shkencore? Unë mendoj se për shumicën ka të bëjë me zhvillimin e diçkaje që përfshin përdorimin e bazave të të dhënave. Për më tepër, diçka shumë shkencore mund të përdorë gjithashtu shërbimet e ofruara nga DBMS.
Këtu më priste një pritë tjetër. Për disa arsye, kur hasni në praktikë që FireMonkey nuk përmban elementë të përqendruar në punën me të dhënat e ruajtura në bazën e të dhënave, nuk jeni plotësisht gati për këtë (për ta thënë butë). Edhe pse unë kam lexuar tashmë për këtë shumë herë dhe ju e dini (teorikisht) se çfarë duhet të përdorni. Bëhet fjalë për Live Live.
Nuk dua të hyj në një debat nëse programuesit e vërtetë duhet të përdorin komponentë të vetëdijshëm për db apo nuk duhet të shfaqin, modifikojnë dhe në fund të ruajnë. E cila, përsëri, nuk është as e keqe as e mirë. Mua më ndodhi kështu.
Kjo përfundon postimin tim të parë të përshtypjeve. Më pas janë tregimet se çfarë dhe si tejkaluan gjatë punës në projekt.
Kanë kaluar më shumë se tre vjet që kur divizioni CodeGear përgjegjës për krijimin e mjeteve të tilla me famë botërore si Delphi, C++Builder dhe JBuilder, si dhe Interbase DBMS, u bë pjesë e Embarcadero Technologies, një kompani e njohur për dizajnimin dhe administrimin e bazës së të dhënave. veglat. , dhe dy vjet që kur diskutuam në faqet e revistës sonë se çfarë të presim në zhvillimin e mjeteve që janë kaq të njohura në mesin e zhvilluesve rusë. Ne kërkuam David Intersimone, Zëvendës President për Marrëdhëniet me Zhvilluesit dhe Kryevangjelist i Embarcadero Technologies, dhe Kirill Rannev, Shef i Zyrës Përfaqësuese të Embarcadero Technologies në Rusi. Për lexuesit tanë më të vegjël, do t'ju informojmë se kjo është larg intervistës së parë që David dhe Kirill japin për ComputerPress - bashkëpunimi ynë ka vazhduar për dekadën e dytë. Dhe për të njëjtin numër vitesh, ne publikojmë periodikisht rishikime të mjeteve të menaxhimit të bazës së të dhënave, në të cilat i kushtohet shumë vëmendje produkteve Embarcadero.
ComputerPress: David, divizioni juaj është pjesë e Embarcadero për tre vjet tashmë. Dy vite më parë, ju ishit plot entuziazëm për faktin se ajo u bë pjesë e një kompanie afër jush në qëllim dhe shpirt. A ka ndryshuar ndonjë gjë gjatë kësaj kohe? A ndjeni ju dhe kolegët tuaj të njëjtin entuziazëm?
Po, jam ende entuziast. Ndryshimi kryesor që ka ndodhur që kur jemi bërë pjesë e kompanisë Embarcadero është se ka pasur shumë investime në zhvillimin e Delphi. Numri i punonjësve që punojnë në mjetet e zhvillimit është rritur, numri i teknologjive që ne mund të zhvillojmë ose nëse është e nevojshme, është rritur.
Lëshimi i RAD Studio XE 2, të cilin ne planifikojmë ta demonstrojmë në Moskë, është lëshimi më i madh i këtij produkti me aftësi të mëdha dhe një numër të madh platformash të mbështetura që nga versioni i parë i Delphi, i krijuar për Windows 16-bit dhe ish-inovativin. produkt që lidhi qasjen dhe kompilimin e komponentit me kodin e makinës. Tani ne mbështesim zhvillimin jo vetëm për Windows por edhe për Macintosh, për të mos përmendur zhvillimin e ueb-it dhe krijimin e aplikacioneve për pajisje celulare, dhe këto aplikacione për platforma të ndryshme mund të kenë një kod të vetëm.
Platforma e re e zhvillimit, FireMonkey, është një bashkëpunim midis Embarcadero dhe firmës ruse të blerë së fundmi me bazë në Ulan-Ude, KSDev, një prodhues i komponentëve grafikë vektorial, DirectX dhe OpenGL, teknologjive të efekteve grafike dhe komponentëve Delphi duke përdorur GPU me PixelShader 2.0. Ne blemë kompaninë KSDev (shih ksdev.ru) një vit më parë dhe filluam të punojmë së bashku për të krijuar një mjet zhvillimi me shumë platforma që përfshin një platformë për zhvillimin e aplikacioneve FireMonkey me komponentë për Delphi dhe C ++ Buider për krijimin e ndërfaqeve të përdoruesit të aplikacioneve, duke integruar me bazat e të dhënave, përpunim grafik duke përdorur një procesor grafik dhe integrim me sistemin operativ.
Duke përdorur FireMonkey, mund të krijoni një aplikacion që drejton CPU-në dhe GPU-në së bashku, dhe më pas duke përdorur përpilues të ndryshëm dhe biblioteka të kohës së ekzekutimit (Run-time Libraries, RTL) mund ta përpiloni atë për Windows, Mac OS ose iOS. Në vend që të mësoni programim duke përdorur të ndryshme bibliotekat grafike, studioni API-në e platformave të ndryshme që kanë sisteme të ndryshme koordinatat dhe aftësitë e ndryshme, zhvilluesit që përdorin Delphi dhe C++Builder mund të përdorin të njëjtën qasje të komponentit, duke redaktuar vizualisht format dhe duke u lidhur me bazat e të dhënave duke lëvizur komponentin me miun. Është në thelb rruge e re krijimi i aplikacioneve që funksionojnë në platforma të ndryshme dhe e ardhmja qëndron tek ai. Nëse dëshironi të shtoni mbështetje për sisteme dhe platforma të tjera operative në aplikacionin tuaj, nuk keni nevojë ta ridizajnoni dhe zhvilloni atë - do të mjaftojë vetëm ta ripërpiloni atë.
Ne krijojmë përpilues të rinj që gjenerojnë kodin vendas. Sot ka përpilues Delphi për 32-bit dhe 64-bit versionet e Windows, 32-bit Versionet Mac OS 10. Dhe ne po punojmë për gjeneratën e ardhshme të përpiluesve të Delphi dhe C++Builder që do t'ju lejojnë të krijoni kodin vendas me performancë të lartë për këto dhe platforma të tjera, si Android ose Linux, dhe të mbani të njëjtin dizajn, të njëjtat komponentë, i njëjti kod duke përdorur përpilues të ndryshëm dhe biblioteka të kohës së funksionimit.
Siç mund ta shihni, kam mjaft arsye për entuziazëm. Dhe zhvilluesit që takoj nëpër botë e dinë që Embarcadero po investon shumë në Delphi dhe C++Builder, si dhe mjetet e zhvillimit të PHP.
KP:Çfarë përparimi keni bërë në integrimin e mjeteve të dy kompanive gjatë dy viteve të fundit? Cilat janë planet e Embarcadero për të ardhmen në këtë fushë?
DI.: Në kohën kur divizioni CodeGear u bë pjesë e Embarcadero, kjo kompani kishte ekipe zhvillimi në Toronto, Monterrey dhe Rumani, ne ishim dhe jemi ende në Scotts Valley dhe në Rusi, në Shën Petersburg. Embarcadero kishte mjete zhvilluesish dhe administratorë të bazës së të dhënave, CodeGear kishte mjete për zhvillimin e aplikacioneve, por këta të fundit përdorin edhe bazat e të dhënave. Bashkimi i kompanive është një ndërthurje e ekspertizës, njohurive në fushën e bazave të të dhënave, optimizimit të kodit, përfshirë kodin e serverit. Bashkimi rezultoi gjithashtu në krijimin e një produkti të ri, AppWave, një teknologji e veçantë për kthimin e një aplikacioni të zakonshëm Windows në diçka shumë të lehtë për t'u përdorur (si aplikacionet për iPhone ose pajisje të tjera). AppWave ju lejon të mos instaloni një aplikacion, por thjesht ta zgjidhni atë dhe ta ekzekutoni nga serveri i përgatitur i ruajtjes së aplikacionit (app), ndërsa ai do të ekzekutohet në kompjuterin e përdoruesit pa bërë ndryshime në regjistrin e tij dhe zona e sistemit sistemi i skedarëve. Nga rruga, shfletuesi i aplikacionit AppWave është shkruar në Delphi. Embarcadero përdor Dephi për zhvillimin e vet dhe ekspertizën tonë të zhvillimit të aplikacioneve.
Aplikacioni iPhone (iOS) i krijuar nga
duke përdorur platformën FireMonkey
Ju gjithashtu mund të përdorni integrimin e mjeteve tona të zhvillimit dhe DB Optimizer për të optimizuar pyetjet SQL kur ndërtoni aplikacione. Duke kaluar kodin SQL direkt te DB Optimizer, mund ta profilizoni, ta testoni dhe të ktheni një version të optimizuar të tij përsëri në mjedisin e zhvillimit. Ekspertiza e bazës së të dhënave të Embarcadero ka përmirësuar gjithashtu teknologjinë DataSnap. Falë zhvilluesve nga Toronto, ne kemi fituar shumë njohuri rreth arkitekturës së sistemeve dhe bazave të të dhënave me shumë nivele. Tani kemi ekspertizë të përbashkët në kodin e serverit dhe procedurat e ruajtura në të dyja kompanitë. Ne kemi mjete si RapidSQL dhe DB Change Manager, dhe mjedise zhvillimi që e bëjnë të lehtë krijimin e kodit nga ana e serverit, të tilla si teknologjitë Code Insight dhe Code Completion që kanë bërë të mundur krijimin e teknologjive SQL Insight dhe SQL Completion. Qasja jonë e përbashkët për krijimin e kodit të klientit dhe serverit, filozofia jonë e përbashkët, na lejon të ndajmë veçori të përbashkëta midis mjeteve të menaxhimit të bazës së të dhënave dhe mjeteve të zhvillimit të aplikacioneve.
Kirill Rannev: Dua të shtoj diçka të rëndësishme. Nga pikëpamja komerciale është shumë e rëndësishme se si i dorëzojmë mjetet tona. Për shembull, versioni i ri i RAD Studio XE 2 Ultimate përfshin grupin e plotë të mjeteve të DB Power Studio. Është një grup shumë i fuqishëm mjetesh, duke përfshirë mjedisin e autorizimit të pyetjeve RapidSQL, mjetin e menaxhimit të ndryshimeve të menaxherit të ndryshimit të DB dhe mjetin e optimizimit të pyetjeve të DB Optimizer, që ju lejojnë të kryeni një pjesë të rëndësishme të procesit të zhvillimit dhe vendosjes, duke menaxhuar ndryshimet në modeli i të dhënave, baza e të dhënave, kodi, etj. Ky është një kombinim shumë i mirë dhe korrekt i teknologjive.
DI.: Por, nëse është e nevojshme, zhvilluesit mund të përdorin Subversion për kontrollin e versionit. Kodi i burimit dhe DB Change Manager për versionimin e meta të dhënave. Ju mund të përdorni profilizimin e kodit dhe DB Optimizer për të optimizuar kodin e serverit, RapidSQL për të ndërtuar dhe korrigjuar kodin e serverit dhe mjediset tona të zhvillimit për të ndërtuar dhe korrigjuar aplikacionet. Ky kombinim i teknologjive në RAD Studio XE Edition Ultimate demonstron paralelet ndërmjet modeleve të bazës së të dhënave dhe zhvillimit të aplikacioneve. Shumica e zhvilluesve që ndërtojnë aplikacione biznesi me Delphi dhe C++Builder punojnë me bazat e të dhënave dhe kanë nevojë për këto mjete, dhe RAD Studio XE Ultimate Edition është një kombinim i shkëlqyer për ata zhvillues.
KP: Përdoruesi modern nuk është më përdorues i vetëm i platformës Windows. Ne përdorim pajisje celulare, iPhone, iPad, pajisje të bazuara në platformën Android. Kjo do të thotë që zhvilluesit duhet të fillojnë të synojnë platforma të ndryshme pa një rritje të konsiderueshme të investimeve në trajnim - domethënë, nevojiten mjete universale. Natyrisht, është joreale të pritet shfaqja e mjeteve universale nga prodhuesit e platformave, dhe në këtë çështje mund të mbështetemi vetëm te prodhuesit e pavarur të mjeteve. Ku mund të mbështetemi te Embarcadero?
DI.: Kemi ende shumë për të bërë në fushën e mbështetjes së platformës. Sot ne ofrojmë mbështetje për platformat iOS për iPhone dhe iPad, më pas telefonat inteligjentë Android, Windows 7 dhe Blackberry do të marrin mbështetjen tonë. Në RAD Studio XE 2, ne filluam duke ndërtuar platformën FireMonkey për iOS dhe më vonë do ta portojmë FireMonkey në platforma të tjera.
Në të njëjtën kohë, ekziston një numër i madh i sistemeve operative që mbështesin ekranet me prekje(ekran me prekje), për telefonat, kompjuterët tabletë dhe pajisjet, desktopët dhe ne do të vazhdojmë të shtojmë mbështetje për to. Përveç kësaj, ekzistojnë sisteme të kontrollit të zërit, sisteme të kontrollit të lëvizjes, sisteme biometrike, përshpejtues, kështu që ne duhet të vazhdojmë të zgjerojmë FireMonkey në mënyrë që të gjithë zhvilluesit të mund të përfitojnë nga platformat e reja. Për shembull, pajisja Microsoft Kinect është projektuar për Xbox 360, dhe tani ekziston një SDK (Kit për Zhvillimin e Softuerit) përkatës për Windows. Dhe ne kemi tashmë shembuj ku ne përdorim lëvizjen për të kontrolluar një aplikacion në të njëjtën mënyrë që do të përdornim normalisht një maus ose tastierë.
Kur krijoni aplikacione me shumë grafika komplekse, krijoni një botë të tërë ndërfaqesh të reja përdoruesish. Nëse kemi të bëjmë me sistemin operativ Windows, ne e kapsulojmë API-në e tij të Windows në bibliotekën VCL (Visual Component Library - një bibliotekë e komponentëve vizualë që është pjesë integrale e mjeteve të zhvillimit të Delphi dhe C ++ Builder. - Shënim. ed.), i cili, nga rruga, mund të zbatohet më tej. Dhe në FireMonkey, ne kapsulojmë API-në e sistemit operativ. Por sot ne manipulojmë format dhe grafikat shumë më gjerësisht. Ju gjithashtu mund të shtoni veçori të hapësirës fizike për animacion dhe efekte speciale. Përveç kësaj, ka shumë të tjera veçori shtesë për të krijuar ndërfaqe përdoruesi që do të zbatojmë në vitet e ardhshme për platforma të ndryshme, pajisje celulare dhe tableta.
Microsoft së fundmi publikoi detaje për Windows 8, i cili pritet të dalë brenda një viti. Ne do t'i mbështesim këto risi në bibliotekën VCL dhe në platformën FireMonkey. Por Delphi është një mjet zhvillimi i krijuar jo vetëm për Windows, por edhe për Macintosh, iPhone dhe iPad. Ne gjithashtu zhvillojmë produktet tona për PHP, mbështesim jQuery Mobile, përdorim softuer aplikacioni Ndërfaqja iOS për të zhvilluar aplikacione të klientëve celularë dhe për të krijuar aplikacione PHP nga ana e serverit duke përdorur magjistarë dhe mjete për të gjeneruar kode JavaScript dhe HTML në anën e klientit dhe fletë stilesh kaskadë. Ne mund të paketojmë aplikacionet PHP dhe aplikacionet e klientëve me kodin vendas për iPhone iOS, ndërsa një klient i tillë do të komunikojë me serverin PHP. Dhe kjo, nga ana tjetër, do të komunikojë me serverin e bazës së të dhënave dhe me shërbimet në internet - me gjithçka që nevojitet për biznesin.
Mjedisi i zhvillimit të RadPHP XE2. Krijoni një aplikacion në internet për celular
duke përdorur komponentët jQuery Mobile për iPhone 3G
Me fjalë të tjera, ne planifikojmë të zgjerojmë aftësitë e FireMonkey dhe VCL, duke përfshirë mbështetjen për platformat celulare.
KP: A mund të elaboroni më shumë për platformën FireMonkey?
DI.: Siç e kam theksuar tashmë, biblioteka VCL e krijuar për Windows do të vazhdojë të zhvillohet dhe përmirësohet. Por sot, nëse doni të zhvilloni realisht aplikacione biznesi, duhet t'i krijoni ato për platforma të ndryshme. Kjo është ajo për të cilën është krijuar platforma FireMonkey. Ai mbështet krijimin e ndërfaqeve të përdoruesit me rezolucion të lartë, grafika 3D me performancë të lartë, shpejtësi të lartë të kuadrove dhe, më e rëndësishmja, përdor një GPU për këtë.
Ju mund t'i përdorni këto veçori kur krijoni aplikacione shkencore, inxhinierike dhe biznesi. Aplikacione të tilla mund të lidhen me bazat e të dhënave duke përdorur teknologjinë dbExpress, duke përdorur ende komponentë jo-vizualë të njohur për zhvilluesit, si ClientDataSet ose DataSource, të përdorin teknologjinë DataSnap, të lidhen me çdo bazë të dhënash, serverë SOAP dhe REST. Mund të krijoni kontrolle tërheqëse, butona me kuti, tabela të bukura dhe elementë të tjerë të ndërfaqes në 2D dhe 3D. Mund të ngarkoni një model 3D të gatshëm në aplikacion dhe ta kombinoni me një formë 2D, në të cilën mund të rrotullohet dhe të shikohet nga këndvështrime të ndryshme. Mund të krijoni një kub të dhënash ose një grafik biznesi 3D dhe ta rrotulloni duke përdorur miun, tastierën apo edhe një pajisje Kinect, ose mund të futeni brenda kubit dhe të shikoni sipërfaqet e ndryshme të tij nga brenda. Dhe e gjithë kjo mund të bëhet me një GPU me shpejtësi të lartë. I njëjti aplikacion mund të përpilohet më pas për një platformë tjetër, si p.sh. Mac OS.
Aplikacioni që përmban një kub rrotullues me të dhëna,
vendosur në skajet e saj
Ose mund të krijoni një formë 3D nga e para dhe të përdorni kamera dhe drita për të ndriçuar dhe rrotulluar pjesë të ndërfaqes së përdoruesit. Projektuesi i formularit tashmë ka një mjedis të integruar për të mbështetur ndërfaqen e përdoruesit 3D drejtpërdrejt në kohën e projektimit.
Në Windows, mund të përdorni bibliotekat Direct2D për grafika 2D me rezolucion të lartë dhe Direct3D për grafika 3D. Mac OS përdor bibliotekat Quartz dhe OpenGL për të njëjtin qëllim. Për iOS, përdoren bibliotekat Quartz dhe OpenGL ES. Por e gjithë kjo është e fshehur nga zhvilluesi - ai përdor platformën FireMonkey, sistemin e saj të koordinatave dhe ndërfaqen e programimit të aplikacionit, pa menduar për këto biblioteka dhe mund të përpilojë të njëjtin aplikacion për platforma të ndryshme.
Le të kujtojmë se çfarë është VCL. VCL është një "mbështjellës" komponenti rreth API-së së Windows. Kemi të bëjmë me burime, meny, dialog, ngjyra, stile, Mesazhet e Windows. Duke qenë një mbështjellës me shumë platforma ndryshe nga VCL, FireMonkey ruan të njëjtat modele të ngjarjeve dhe komponentëve, duke ju lejuar të mendoni për sa i përket ngjarjeve (për shembull, ngjarjet OnClick, OnHasFocus, onMouseDown dhe onKeyDown), por të trajtoni ngjarjet e Macintosh ose iPhone.
Platforma FireMonkey gjithashtu vjen me sistem të plotë animimi i elementeve të ndërfaqes së përdoruesit. Sigurisht që nuk është një sistem gjithëpërfshirës i animacionit të tipit Pixar, por ju lejon të aplikoni efekte të tilla si animacioni bitmap, duke theksuar fokusin e një elementi të ndërfaqes së përdoruesit dhe duke punuar me grafikë vektoriale. Zhvilluesi ka qasje në më shumë se 50 efektet vizuale: turbullim, bardh e zi, shpërbërje, tranzicione, reflektim, hijezim - të gjitha llojet e efekteve të disponueshme në procesorët grafikë modernë, të cilët tani janë pothuajse në çdo kompjuter. Një aplikacion i ndërtuar duke përdorur platformën FireMonkey dërgon komanda në GPU, e cila kryen të gjithë punën për shfaqjen e grafikëve dhe krijimin e ndërfaqes së përdoruesit. ku CPU falas për llogaritjet dhe thirrjet në sistemin operativ. Zhvilluesi duhet vetëm të vendosë saktë komponentët.
Gjëja më themelore në lidhje me platformën FireMonkey është mënyra se si ajo ndërton ndërfaqen e përdoruesit. Ekzistojnë lehtësira për vendosjen e grafikëve bitmap në elementët e ndërfaqes si menutë, butonat dhe shiritat e lëvizjes. Në FireMonkey, ne përdorim grafikë vektoriale GPU për këtë qëllim. Nga pikëpamja e programimit, këto janë të gjitha të njëjtat kontrolle, por procesori grafik bën të gjithë punën për t'i shfaqur ato. Ne mund të aplikojmë stile në kontrolle, ta bëjmë aplikacionin të duket si një aplikacion për Mac OS ose Windows, të krijojmë stilin tonë, të aplikojmë stilet tona në elementët e ndërfaqes (për shembull, të bëjmë një buton drejtkëndor ose të rrumbullakët duke ndryshuar stilin e tij në redaktuesin e formularit) - për këtë mjedisi i zhvillimit ka një redaktues stili. Ju mund të krijoni stilin tuaj, ose mund të ndryshoni stilin e një aplikacioni tashmë të përfunduar.
Platforma FireMonkey - Mjetet e Zhvillimit
dhe platformat e mbështetura
Nëse ju kujtohet, në bibliotekën VCL kishte një numër të kufizuar kontrollesh - kontejnerë (d.m.th., duke ju lejuar të vendosni elementë të tjerë në to), dhe në FireMonkey çdo kontroll është një enë. Kjo do të thotë që çdo kontroll mund të përmbajë çdo kontroll tjetër. Për shembull, artikujt e listës rënëse mund të përmbajnë imazhe, butona, kuti modifikimi dhe kontrolle të tjera. Dhe gjithashtu mund të vendosni komponentë në shtresa.
Sistemi i paraqitjes së FireMonkey është mjaft fleksibël - ai mund të përdorë bibliotekat Direct2D, Direct3D dhe OpenGL duke dërguar komanda në GPU. Për të arritur të njëjtën gjë në VCL, ishte e nevojshme të gjenerohej një tampon i veçantë jashtë ekranit, të krijoni një imazh në të duke thirrur funksionet e duhura të bibliotekave grafike dhe më pas ta shfaqni atë në formular.
Shembuj të efekteve grafike të mbështetur nga FireMonkey
Nëse nuk keni një GPU, mund të aplikoni përsëri forma 2D ose 3D dhe të përdorni kontrollet e FireMonkey. Në këtë rast, platforma FireMonkey do të përdorë bibliotekat GDI+ ose biblioteka të tjera të ngjashme dhe do të kryejë të njëjtat efekte dhe animacion ose manipulim të objekteve 3D.
Një veçori tjetër e FireMonkey është një sistem i ri për lidhjen e elementeve të ndërfaqes me të dhënat, i cili është i hapur dhe fleksibël. Ekzistojnë dy lloje të elementeve të ndërfaqes në VCL: të lidhura me të dhënat dhe jo të lidhura me të dhënat (për shembull, TDBEdit dhe TEdit). Në FireMonkey, çdo kontroll mund të shoqërohet me të dhëna, të çdo lloji. Mund të jetë vetëm një shprehje, një fushë nga një grup të dhënash, të dhëna nga objekte të krijuara nga zhvilluesi ose rezultatet e thirrjeve të metodës.
Përveç kësaj, kur krijoni një aplikacion, mund të ngarkoni një model 3D të gatshëm në të dhe ta përdorni - aftësi të tilla shpesh kërkohen si në aplikacionet e biznesit ashtu edhe në atë inxhinierik. Ne kemi një klient që krijon aplikacione për logjistikën. Ata kishin një sistem informacioni të ndërtuar me Delphi, dhe në të, një aplikacion që vizatonte një plan dhe shfaqte informacion nga burimet e të dhënave. Kohët e fundit ata bënë diçka interesante - ata vizatuan një depo plotësisht të automatizuar 3D në AutoCAD, dhe aplikimi i tyre ju lejon të shihni se si një ngarkues automatik lëviz nëpër magazinë dhe vendos mallrat në rafte. Dhe ata parashtrojnë të dhëna nga burimet në imazhin përkatës.
Shembuj të ndryshimit të stileve të aplikimit
KP: Cilat formate të modelit 3D mbështeten aktualisht?
DI.: Në këtë version, ne mbështesim ngarkimin e modeleve nga AutoCAD, Collada (mjet Modelimi 3D me burim të hapur. - Shënim. ed.), Maya, një format OBJ i mbështetur nga shumë shitës të grafikëve 3D.
KP: Cilat formate të tjera planifikohen të shtohen?
DI.: Ne planifikojmë të shtojmë 3DS (3D Studio MAX), SVG (zakonisht ky format përdoret për grafika vektoriale 2D, por ndonjëherë për 3D), Google SketchUp. Ne mund të mbështesim edhe formate të tjera.
KP: A kërkon përdorimi i modeleve 3D në aplikacionet e ndërtuara me FireMonkey një licencë për mjetin e duhur të modelimit 3D?
DI.: Jo, nuk ka. Gjithçka që bëjmë është të lexojmë skedarin e modelit. Ne po e importojmë modelin por jo po e eksportojmë atë (megjithëse sigurisht që mund të shkruani një aplikacion që e ruan modelin në formatin tuaj). Ne nuk pretendojmë të jemi prodhues të mjeteve të modelimit 3D - për këtë ju mund të përdorni AutoCAD, 3D Studio Max, Maya ose ndonjë mjet tjetër modelimi 3D dhe të importoni modelet e krijuara në aplikacionet tona.
KP: Sa performancë janë aplikacionet e ndërtuara me FireMonkey në platformat moderne të harduerit?
DI.: Performanca është mjaft e lartë. Për shembull, një formë 3D me tre sfera dhe tre drita mund të jepet me 100 korniza për sekondë në një MacBook Pro. Dhe mund të arrijë në 600 - varet se çfarë saktësisht po bëjmë. Përsëri, gjithçka varet nga fuqia e GPU-së.
KP: A do të thotë kjo se me ndihmën e FireMonkey mund të krijoni lojëra që plotësojnë kërkesat moderne?
DI.: Ne nuk i pozicionojmë mjetet tona të zhvillimit si një mjet për lojëra. Sidoqoftë, duke përdorur performancën e lartë të procesorëve grafikë modernë, ju gjithashtu mund të krijoni lojëra me FireMonkey - në fund të fundit, ato krijohen duke përdorur Direct3D ose OpenGL.
KP:Çfarë pune po bëni tani në fushën e mbështetjes për njohjen e gjesteve dhe gjëra të tjera të reja? A ekziston një mbështetje e tillë?
DI.: Nuk kemi ende mbështetje për gjeste në këtë version. Kontrolli i gjesteve do të shtohet në një version të ardhshëm të FireMonkey, por tani për tani, ju mund të përdorni mbështetjen e gjesteve të integruar në sistemin operativ.
Mikhail Filippenko, drejtor i Fast Reports, Inc.
K.R.: Ne kemi thënë tashmë që teknologjia FireMonkey ka rrënjë ruse - themelet e saj u krijuan në vendin tonë, dhe më pas vetë teknologjia dhe zhvilluesit e saj u bashkuan në Embarcadero. Në përgjithësi, është kënaqësi të shohësh rritjen e komponentit rus në RAD Studio dhe Delphi. Ky është aktiviteti i qendrës sonë të zhvillimit në Shën Petersburg dhe kontributi i zhvilluesve të pavarur rusë. Për shembull, Rad Studio XE2 përfshin gjeneratorin e raporteve FastReport, i cili është i njohur në të gjithë botën dhe shumë popullor në vendin tonë. Ai është nga Rostov-on-Don.
KP: Do të doja të flisja për përpiluesit. Cili përpilues përdoret për të krijuar aplikacione iOS?
DI.: Ne nuk kemi përpiluesin tonë Delphi për iPhone ose iPad - nuk kemi zhvilluar ende përpilues për procesorët ARM të përdorur në këto pajisje. Për iOS, ne përdorim përkohësisht përpiluesin Free Pascal dhe bibliotekën e kohës së funksionimit. Por ne jemi duke punuar në gjeneratën e ardhshme të përpiluesve, përfshirë ata për procesorët ARM. Por ka përpilues për Windows dhe Mac OS, pasi të dyja platformat harduerike bazohen në procesorë Intel.
KP: Dhe çfarë është bërë në fushën e zhvillimit të kompajlerëve në dy vitet e fundit?
DI.: Ne kemi përpilues Delphi 32 dhe 64 bit për Windows dhe Mac OS. Dhe ne jemi duke punuar për një gjeneratë të re të përpiluesve Delphi dhe C++. Puna për to është ende në vazhdim, por kur të përfundojë, do të kemi kompajlerët Delphi për procesorët ARM, platformat Android, Linux dhe çfarëdo. Dhe ne do të kemi përpilues 64-bitësh C++ për Windows dhe platforma të tjera të pajtueshme me standardin më të fundit të gjuhës C++ të sapo adoptuar nga ISO.
KP:Çfarë po ndodh sot me mbështetjen e kompjuterit cloud në mjetet e zhvillimit Embarcadero?
DI.: Me RAD Studio XE 2, ne mbështesim migrimin e aplikacioneve në renë kompjuterike të Microsoft Azure ose Amazon EC2 duke përdorur "Asistentin e platformës". Dhe ne kemi komponentë të serverit për Cloud Storage për Azure dhe Amazon S3 për ruajtjen e tabelave, të dhënave binare, radhëve të mesazheve. AT versioni i mëparshëm Në RAD Studio XE, ne gjithashtu mbështetëm vendosjen e aplikacioneve në Amazon EC2, por i mungonte mbështetja e ruajtjes.
Mbështetje për kompjuterin në renë kompjuterike në RAD Studio XE 2
KP: Dy vjet më parë ju folët për zgjidhjen e re All-Access. Sa ishte në kërkesë? Për cilat janë përfitimet e tij integruesit e sistemit dhe zhvilluesit?
DI.: Zgjidhja All-Access dhe mjeti cloud AppWave përdoren gjerësisht në mbarë botën. Ato janë krijuar për ta bërë më të lehtë përdorimin e aplikacioneve të kompanisë sonë dhe të palëve të treta. Në fakt, kjo është një zgjidhje për menaxhimin e licencave dhe aplikacioneve, dhe është e përshtatshme për kompanitë e mëdha. Firmat më të vogla që nuk kanë një ekip të dedikuar për menaxhimin e aplikacioneve mund ta vendosin aplikacionin në një depo, të marrin emrat e përdoruesve nga një bazë të dhënash dhe të sigurojnë që ato aplikacione të përdoren pa pasur nevojë të mbani mend se ku çelësi i licencës dhe sa licenca janë në dispozicion. All-Access dhe shfletuesi AppWave janë krijuar për të menaxhuar versionin dhe kontrollin e aksesit.
K.R.: Tregu është kaq i larmishëm dhe përdoruesit janë kaq të ndryshëm, saqë është e pamundur të mbulohen të gjitha nevojat me një zgjidhje. Prandaj, ne përpiqemi për një shumëllojshmëri zgjidhjesh "paketimi". Ne kemi bërë shumë punë për të unifikuar licencimin, menaxhimin e licencave dhe instalimin e produktit. Kjo linjë zgjidhjesh përfshin mjetet e menaxhimit të licencës dhe aksesit jo vetëm për produktet Embarcadero, por edhe për çdo produkt tjetër, përfshirë zhvillimet e brendshme të kompanive.
Puna e bashkimit të mjeteve të zhvillimit në komplete efektive të përdoruesve është ende në vazhdim. Ne kemi All-Access - një superset që kombinon të gjitha produktet Embarcadero. Nëse klienti blen versionin All-Access Platinum, ai merr të gjitha mjetet që janë në Embarcadero. Por ndonjëherë ky grup rezulton të jetë i tepërt, për shembull, ne kemi bërë dy grupe të tjera për specialistët e bazës së të dhënave - DB Power Studio Developer Edition dhe DB Power Studio DBA Edition. Dallimi midis tyre është se për zhvilluesin ne ofrojmë RapidSQL - një mjet për zhvillimin e kodit të serverit, dhe për administratorin ka DBArtizan të integruar - një mjet për administrimin e bazës së të dhënave, një produkt më i gjerë se RapidSQL. Për profesionistët, ne kemi paketat e mëposhtme të të gjitha aksesit: paketën me të gjitha produktet, DB Power Studio për zhvilluesit, DB Power Studio për administratorët, ER Studio Enterprise Edition për arkitektët dhe këdo që merret me modelim. Ka kombinime për zhvillimin e aplikacioneve dhe për administratorët. Delphi është një mjet zhvilluesish dhe ka shumë kuptim t'i shtohen mjetet e zhvillimit të SQL dhe mjetet e optimizimit. Së fundi, DB Change Manager është një mjet shumë logjik për menaxhimin e kompleksitetit të ndryshimeve që ndodhin në bazat e të dhënave gjatë ciklit të tyre jetësor.
Kështu, All-Access është kreu i një familjeje të madhe grupesh të ndryshme produktesh.
KP: Nëse nuk është sekret, kush në Rusi përdor All-Access?
K.R.: Ne kemi klientë që blenë të gjithë-qasjen bazuar në Delphi. Shumë prej tyre krijojnë sisteme komplekse klient-server me SQL Server dhe Oracle, dhe atyre u pëlqeu menjëherë paketa jonë e të dhënave ndër-platformë. Ne kemi një kompani klientësh që ka punuar me Delphi që nga versioni i parë dhe u zhvendos nga Delphi në All-Access një vit më parë. Dy mjete që garantohen të përdoren nga të gjithë zhvilluesit në këtë kompani janë Delphi dhe DBArtisan. Dhe ka klientë që erdhën në All-Access nga ana e bazës së të dhënave. Detyra e tyre kryesore është të administrojnë bazat e të dhënave, por ata gjithashtu zhvillojnë herë pas here aplikacione. Klientët që përdorin All-Access përfshijnë kompani mediatike, ndërtues makinerish dhe industri të tjera.
Më vete, do të doja të ndalesha te kompanitë e vogla. Shumë shpesh, në ekipe të vogla, zhvilluesi bën gjithçka, dhe një kompani e tillë ndonjëherë blen pako të mëdha ushqimore All-Access për një ose dy zhvillues. Në ekipet e mëdha, nuk inkurajohet që zhvilluesi të kryejë, për shembull, rolin e një administratori të bazës së të dhënave, kështu që paketat e vogla ushqimore zakonisht janë të njohura atje, dhe në kompanitë e vogla një kombinim i tillë i detyrave është mjaft i pranueshëm.
Delphi Architect është një produkt i tregtuar shumë që përfshin mjete modelimi dhe programimi. Megjithatë, numri i kopjeve të shitura është më i vogël se versionet e Delphi Enterprise, por është gjithashtu i madh. Theksoj se në vitin 2010 ishim vendi më i mirë për sa i përket shitjeve, pavarësisht se të gjitha vendet i mbijetuan krizës. Kjo rritje ishte për shkak të jo aq shumë faktorëve ekonomikë sa për faktin se versioni i RAD Studio XE, i lëshuar në fund të vitit 2009, doli të ishte shumë i kërkuar. Dhe ndërsa ne presim rritje të mëtejshme në shitje.
Ne kemi ndërmarrë një hap tjetër të arsyeshëm, i cili kërkohet shumë në Rusi. Shkalla e legalizimit të versioneve të ndryshme të produkteve tona është e ndryshme: sa më i lartë të jetë versioni, aq më i legalizuar është, sepse më herët software blerë jo aq aktivisht. Duke filluar me RAD Studio XE, licenca mbulon versionet 2010, 2009, 2007, madje edhe Delphi 7, një produkt i përdorur gjerësisht.
Sot, zhvilluesit përballen me faktin se ata kanë si projekte të reja ashtu edhe projekte në gjendje mbështetjeje. Një numër i madh projektesh janë migruar nga versionet e hershme të Delphi në versionin 7 dhe mbeten brenda këtij versioni, duke vazhduar të punojnë në burime relativisht të vogla. Askush nuk po i zhvendos ato në versione më të reja, por ato mbahen të zbatueshme. Dhe tani ne lejojmë për pak para (më pak se çmimi i një licence Delphi 7) për të marrë RAD Studio XE dhe Delphi 7 - domethënë, ne legalizojmë zhvilluesin si për zbatimin e projekteve të reja ashtu edhe për projektet mbështetëse.
KP: Si e vlerësoni gjendjen aktuale të komunitetit Embarcadero?
DI.: Ky komunitet është i madh dhe shumë kërkues. Ata kanë nevojë për gjithçka dhe menjëherë - ata janë zhvillues. Por ndonjëherë duhet shumë kohë për të bërë diçka të drejtë.
Disa vite më parë morëm arkitekturën e komponentit të Windows dhe e vendosëm në desktopët Linux. Tani e shohim se nuk ishte vendimi i duhur. Vendimi i duhur është krijimi i një platforme për aplikime. Aplikacionet edhe për platforma të ndryshme kanë meny, dritare, grafikë, akses në rrjet dhe akses në pajisje. Platforma të ndryshme mund të kenë modele të ndryshme kontrolli i rrjedhës ose trajtimi i përjashtimeve, por në kodin e aplikacionit shohim të njëjtat blloqe prove. Detyra jonë është t'ua lehtësojmë zhvilluesve krijimin e aplikacioneve të biznesit dhe përpilimin e tyre për platformat në të cilat supozohet të përdoren, pavarësisht se si është rregulluar sistemi i udhëzimeve të procesorëve përkatës dhe cilat janë veçoritë e tjera të këtyre platformave. Dhe FireMonkey është pikërisht ajo që ju nevojitet për të zgjidhur këtë problem.
KP: Nëse një kompani krijon një pajisje të re dhe dëshiron të ketë mbështetje FireMonkey për të, a do të ishte e mundur kjo?
DI.: Me përpiluesit e gjeneratës së re që do të kenë një front-end të pavarur nga platforma dhe një fund-fund të varur nga platforma, kjo do të jetë mjaft e mundur. Ndërkohë, për çdo sistem operativ, ne krijojmë një përpilues dhe bibliotekë të kohës së funksionimit nga e para.
Çdo pajisje e re moderne zakonisht ka një ndërfaqe grafike të përdoruesit (shumë prej tyre kanë një procesor me dy bërthama dhe GPU) dhe SDK standarde për zhvilluesit. E gjithë kjo thjeshton krijimin e mbështetjes së pajisjes në FireMonkey. Nëse pajisja e re ka vetëm biblioteka për grafikë 2D si Quartz, ne do të jemi në gjendje të mbështesim një pajisje të tillë në FireMonkey, por kjo do të zgjasë afërsisht disa muaj. Sidoqoftë, shumë varet nga platforma: jo të gjitha platformat mbështesin të gjitha veçoritë, për shembull, iOS nuk ka meny dhe dialog, dhe nuk do të jeni në gjendje të vendosni përbërësit përkatës në format e aplikacioneve të tilla.
KP: A ka ndryshuar ndonjë gjë në politikën e punës me partnerët? Çfarë po bëhet për të rritur përqindjen e përdoruesve të produkteve tuaja? Çfarë po bëhet në Rusi?
DI.: Ekosistemi ynë partner është i gjerë - ka qindra prodhues mjetesh dhe komponentësh që nuk gjenden në produktet tona, dhe ne kemi një program partneriteti teknologjik. Prandaj, një gamë e gjerë komponentësh, teknologjish dhe mjetesh janë në dispozicion të zhvilluesve. Dhe zgjidhjet që ata krijojnë për klientët e tyre janë më të mira sesa nëse do të përdoreshin vetëm produktet tona. Dhe për shitje, ne kemi zyra në shumë vende, rishitës dhe shpërndarës.
K.R.: Ajo që ka rëndësi për ne nuk është numri i partnerëve, por cilësia e punës së secilit partner specifik. Tani për tani, ne duam të fokusohemi në bashkëpunimin e ngushtë me partnerët ekzistues, megjithëse grupi i partnerëve mbetet i hapur. Kemi shumë partnerë dhe duhet t'i ndihmojmë në aspektin teknologjik. Ne punojmë me zhvilluesit, dhe ata e dinë se çfarë duan dhe e dinë se çfarë është në dispozicion në treg, dhe aftësitë e partnerëve duhet të përputhen me këtë.
Ne kemi partnerë biznesi që kanë investuar shumë në Embarcadero si një linjë biznesi - ata kanë trajnuar specialistë, marketing të produkteve tona, punonjës të përkushtuar që janë përgjegjës për këtë fushë dhe monitorojnë se çfarë ndodh me produktet tona, listën e çmimeve, marketingun. Natyrisht, ato janë më të suksesshme për sa i përket shitjeve të produkteve tona sesa kompanitë që shesin produktet tona rast pas rasti.
KP: David, Kirill, faleminderit shumë për intervistën interesante. Në emër të publikimit tonë dhe lexuesve tanë, më lejoni t'i uroj kompanisë suaj suksese të vazhdueshme në krijimin e mjeteve tuaja të mahnitshme që zhvilluesve u duhen kaq shumë!
Pyetjet u bënë nga Natalia Elmanova
Në kontekstin e këtij blogu, ky projekt është kryesisht interesant sepse zbatohet në FireMonkey dhe është një demonstrim i mahnitshëm i aftësive të kësaj platforme. Dhe kështu, vetëm javën e kaluar, u publikua beta publike e produktit. Kështu, lexuesit e blogut mund të "ndiejnë" vërtetë komplekse majmuni i zjarrit Shtojca.
Disa fjalë për programin. Para së gjithash, duhet të theksohet se versioni aktual i Sphere është pozicionuar pak më ndryshe. Po, ndonjëherë ndodh ...
I ri SphereLive Ky nuk është thjesht një tjetër lajmëtar. Para së gjithash, është një mjet që ju lejon të organizoni në mënyrë efektive procesin arsimor. Ai lejon leksione në distancë, konsultime private, mësime individuale dhe ngjarje të tjera të ngjashme. Në të njëjtën kohë, është i pajisur me pothuajse gjithçka të nevojshme për punë. Duke filluar me një sistem unik të transferimit të skedarëve dhe duke përfunduar me një nënsistem të fuqishëm faturimi.
Në këtë fazë, çmimet për përdorimin e produktit janë mjaft demokratike. Në varësi të një numri të kufizuar dëgjuesish dhe një sasie të vogël burimesh, produkti mund të përdoret falas.
Natyrisht, sfera përdor avantazhin kryesor majmuni i zjarrit- ndër-platformë. Tani aplikacioni është i disponueshëm në versionet Windows dhe MacOS. versioni android pritet nga dita në ditë.
Sidoqoftë, për mua, SphereLive është interesant, para së gjithash, si një produkt inovativ me një gamë të tërë zgjidhjesh origjinale. Ndonjëherë vetëm në nivelin e "...wow, si e bëre këtë?" Nga rruga, një nga zhvilluesit e Sphere merr pjesë aktive në diskutimet në forumin FireMonkey. Kjo në vetvete mund të jetë një rast për të shkarkuar aplikacionin dhe për të diskutuar pyetje teknike drejtpërdrejt me autorin. Më besoni, ka diçka për të parë, ka diçka për të mësuar.
TListViewështë një nga komponentët kryesorë për ndërtimin e një ndërfaqe aplikacioni celular në majmuni i zjarrit. Ky komponent nuk është më i lehtë për t'u përdorur, shpesh përfshin një sasi të konsiderueshme kodi, por i siguron zhvilluesit liri të konsiderueshme veprimi. Sigurisht, aplikacionet mund të përdorin gjithashtu TListBox ku gjithçka është shumë më e lehtë. Por TListBox, ndoshta e mirë për të shfaqur një numër fiks regjistrimesh, për shfaqjen e të dhënave nga burimet e të dhënave, duhet patjetër të përdorni TListView.
Dallimet kryesore midis TListView dhe TListBox janë:
- TListBoxItem- kontrolli, TListViewItem- Jo
- AT TListBoxItem Mund të shtoni çdo kontroll duke përdorur Prindin. AT TListVIewItem- Jo.
- TListVIewItem ruan vetëm të dhënat e ekranit
- TListVIewItem vetë kryen renderimin e të dhënave të ruajtura përmes metodës Render
- Për shkak të paraqitjes manuale aktuale në TListVIewItem, arrihet një rritje e shpejtësisë dhe konsumi i ulët i memories (duke ruajtur vetëm të dhënat aktuale)
- Për të krijuar tuajën TListViewItem, ju duhet të krijoni klasën tuaj të artikullit, të zbatoni të dhënat e kërkuara në të (për shembull, koha) dhe të krijoni një redaktues në vend për të modifikuar kohën, për ta regjistruar atë, etj.
Në vetvete, fakti i përmirësimit të performancës dhe reduktimit të konsumit të kujtesës është një argument i fortë në favor të përdorimit TListView. Por ka edhe diçka tjetër.
Ne shume Android aplikacionet, unë kam parë zbatimin e mëposhtëm të listave. Kur klikoni mbi një artikull të listës (Artikulli, nëse i përmbaheni terminologjisë së zgjedhur), kryhet një veprim i caktuar. Zakonisht një formë e re thirret për të redaktuar të dhënat. Por kur shtypni dhe mbani shtypur (Trokitje e gjatë), kryhet një veprim krejtësisht i ndryshëm. Dhe këto ngjarje nuk kryqëzohen. Me fjalë të tjera, aplikacionet Android mund të dallojnë qartë midis një "shtypje të gjatë" dhe një "normale". Për më tepër, asnjë nga këto ngjarje nuk aktivizohet kur lista lëviz. Një shembull i mirë është lista e letrave në Yandex Mail.
Fillimisht, dua t'i uroj të gjithë lexuesit e blogut për festat e kaluara dhe t'ju uroj gjithë të mirat në vitin e ardhshëm.
Për rrethana të kuptueshme, nuk kam bërë një raport tradicional të Vitit të Ri, si dhe nuk kam bërë asnjë plan për vitin. Sidoqoftë, jeta nuk qëndron ende, po punohet dhe ngjarje të caktuara në botën Delphi po ndodhin. Unë marr përsipër të publikoj një përzgjedhje të "lajmeve të humbura nga bota e Delphi" gjatë festave të Krishtlindjeve në të ardhmen e afërt. Ndërkohë, do t'ju tregoj për pajisjen e re që bleva.
Ju mund të gjeni specifikimet në faqen zyrtare të internetit. Dhe përshtypja subjektive është shumë e këndshme. Vlen të përmendet fakti se pajisja është e mbushur fjalë për fjalë me softuer të pronarit nga prodhuesi. Po, dhe nga shitësit mora një grup mbresëlënës softuerësh si dhuratë. Në funksionim, telefoni inteligjent është mjaft i shpejtë dhe justifikon plotësisht koston e tij (rreth 200 dollarë). Nga rruga, bleva telefonin tim të mëparshëm GSmart 1362 për afërsisht të njëjtat para 2 vjet më parë. Por, siç ndoshta e keni marrë me mend, interesi kryesor për mua ishte se si majmuni i zjarrit aplikacionet.
Para se të vazhdoni tregimin për kohëmatësin - dy lajme.
Së pari, është lëshuar përditësimi i parë XE7. Sipas traditës, ai është i disponueshëm për përdoruesit e regjistruar. Ju mund të gjeni një listë të gabimeve të rregulluara. Doja të shihja se si sillet aplikacioni në mjedisin e përditësuar. Në fakt, nuk duhej bërë asnjë korrigjim, megjithëse fusha për eksperimente mbeti.
Lajmi i dytë. Ofertat speciale të Embarcadero zgjaten deri në fund të vitit:
Epo, tani drejtpërdrejt në temën e postimit. Në parim, gjithçka që na mbetet është të përpiqemi të ekzekutojmë një aplikacion të krijuar tashmë për Android. Për këtë, ne përdorim atë që kam shkruar në postimet e mëparshme. Domethënë, e reja. E korrigjova këtë aplikacion Nexus 7, në përputhje me rrethanat shtoi pamjen e Tabletit Android 7″. Dizajni duhej të "ndryshohej" vetëm pak.
Ndoshta vetëm dembelët nuk e kanë shkruar kohëmatësin e tyre. Dhe në kontekstin e mbështetjes së zhvillimit për platformat celulare, detyra për të shkruar një kohëmatës në Delphi në përgjithësi mund të konsiderohet si një kult. Kështu mendova, pse jo si shembull zhvillimi majmuni i zjarrit Aplikacionet nuk analizojnë saktësisht kohëmatësin. Nën Android, sigurisht. Sigurisht, kjo do të jetë pikërisht pikëpamja ime për detyrën, e cila, edhe pse jo veçanërisht e vështirë, ka ende nuancat e veta. Ndoshta keni ndonjë koment ose sugjerim, do të ishte mirë t'i diskutoni ato në komente. Unë nuk jam aspak ekspert në fushën e shkrimit të aplikacioneve celulare, kështu që çdo vërejtje juaj do të jetë e vlefshme për mua.
Ne do të zhvillojmë saktësisht kohëmatësin, në kuptimin anglisht të këtij termi. Kjo do të thotë, ekrani do të shfaq një numërues dhe katër butona - "Fillimi", "Ndalo", "Stop" dhe "Anulo". Numërimi mbrapsht do të jetë përpara (d.m.th. koha do të rritet). Opsioni në të cilin caktohet koha dhe numërimi mbrapsht në terminologjinë angleze quhet Stop Watch, mbase do të përpiqem ta zbatoj më vonë. Aplikacioni me të cilin do të merremi është më afër funksionalitetit me një kronometër.
Delphi XE7 na lejon të thjeshtojmë shumë procesin e zhvillimit, për shkak të faktit se tani mund të krijojmë dhe korrigjojmë një aplikacion të vërtetë për Win32, dhe më pas thjesht të shtojmë pamjet e formularit për pajisjet e nevojshme celulare dhe, pasi t'i korrigjojmë pak ato, të marrim një celular funksional. aplikacion. Tingëllon shumë mirë për të qenë e vërtetë? Ndoshta. Por dua ta kontrolloj edhe këtë deklaratë duke realizuar detyrën.
Sa më shpesh më pyesin kolegët e mi në biseda private nëse është e mundur të zhvillohen aplikacione celulare majmuni i zjarrit apo është një prototip dhe jo një zgjidhje prodhimi?
Mendoj se tani mund të siguroj edhe skeptikët e jashtëzakonshëm.
Miku im i gjirit dhe kolegu Tagir Yumaguzin më tregoi për projektin që ai mori pjesë shumë kohë më parë. Tani, kur ky projekt është në gjendjen e para-publikimit, ne vendosëm që ky përshkrim do të jetë interesant për komunitetin Delphi. Në thelb, ky është një projekt vërtet i madh i zbatuar në FM. Po flasim për projektin Sphere Live. Një artikull i vogël kushtuar atij projekti u botua kohët e fundit në Habrahabr.ru Alexey Glyzin, shefi i "" departamentit të zhvillimit ra dakord të tregojë më shumë rreth projektit duke marrë parasysh audiencën e blogut tim.
A.B.– Alexey, në përgjithësi, cili është projekti juaj?
A.G.: – Ideja nuk është shfaqur menjëherë dhe në çast. Përpara projektit ‘Sphere’ ekipi ynë kishte punuar në projektin ku u zbatuan teknologjitë audio/video të transmetimit. Më vonë krijuam softuerin tonë që ishte në gjendje të jepte transmetime multimediale për një sasi të pakufizuar përdoruesish duke përfshirë reagimet. Por ne duhej të kishim një veçori faturimi të përfshirë.
Aplikimi duhej të plotësonte disa kërkesa. Së pari, organizimi maksimal i thjeshtuar i konferencave ose transmetimi te pjesëmarrësit, shuma e të cilave nuk mund të parashikohet. Së dyti, më e rëndësishmja, është t'u japim klientëve tanë një mundësi për të fituar me aplikacionin tonë dhe për të reduktuar kompleksitetin e sistemit, sasinë e instrumenteve që duhen përdorur për të arritur qëllimin. Lehtësia e organizimit të kurseve, webinar ose thjesht një konsultë.
Një nivel i vogël memorie në lidhje me FireDAC në versionin aktual Delphi XE6. Por së pari, disa fjalë se ku të kërkoni përgjigje për pyetjet në lidhje me majmuni i zjarrit. Përdoruesit që flasin rusisht janë në një pozitë të privilegjuar këtu.
Gjatë përgatitjes për ngjarjen në Kharkiv si pjesë e turneut botëror të RAD Studio XE5, hasa një problem të vogël në punën me SQLite nëpërmjet FireDAC. Nëse databaza e plotësuar në aplikacionin Windows transferohet së bashku me aplikacionin në Android, vijat cirilike në bazën e të dhënave nuk janë më të lexueshme (në vend të shkronjave shfaqen pikëpyetjet). Sidoqoftë, nëse plotësoni bazën e të dhënave direkt në një pajisje celulare, karakteret ruse lexohen mjaft saktë. Të dhënat nga databaza e plotësuar aplikimi i palës së tretë, ose në Delfi një aplikacion që përdor komponentë të tjerë të aksesit të të dhënave gjithashtu shfaqet normalisht. Tubimi nuk arriti të gjente një zgjidhje dhe më duhej të citoja një specialist të njohur të futbollit ukrainas: "Ne do ta kuptojmë!"
Ndryshe nga kjo e fundit, unë arrita të merrem me problemin e përshkruar. Si parazgjedhje, kur lidhet me SQLite në FireDAC Përdoret formati i vargut ANSI.
Nëse detyroni Unicode, atëherë gjithçka do të funksionojë siç duhet. Por ka edhe një moment të pakëndshëm. Pasi të keni ndryshuar formatin e linjave, do t'ju duhet të rikrijoni listën e fushave në të gjitha grupet e të dhënave, si dhe të rilidhni përbërësit përgjegjës për shfaqjen dhe futjen e të dhënave. Prandaj, është më mirë të kujdeseni menjëherë për kodimin.
Në pjesët e mëparshme të kësaj mini-serie u trajtuam me krijimin e bazës së të dhënave, strukturën e saj dhe lidhjen me të nga Delphi. Në këtë pjesë, unë propozoj të merremi me shfaqjen e të dhënave nga tabelat, duke filluar nga rasti më i thjeshtë.
Një redaktues i thjeshtë i të dhënave të tabelës është zakonisht pjesë e një aplikacioni kompleks. Për të redaktuar tabelat, unë zakonisht përdor një formular të veçantë. Le të fillojmë me listën e produkteve. Para së gjithash, ne duhet të krijojmë një DataSet për të hyrë në të dhënat e tabelës. Në rastin tonë, është mjaft e mundur të përdoret komponenti Tabela TAD. Le ta vendosim atë në DataModule dhe të specifikojmë vlerën e pronës lidhje. Në redaktorin e pronës emri i tabelës do të shfaqet një listë me tabela, nga e cila zgjedhim një tabelë Produktet. Nëse keni bërë gjithçka në mënyrë korrekte, mund të caktoni pronën Aktiv Vlera e vërtetë. Është më mirë të riemërtoni komponentin menjëherë (për shembull, ADTProduct). Pas kësaj, unë zakonisht krijoj një grup fushash për DataSet. Ne thërrasim redaktuesin e fushës (klikoni dy herë mbi komponentin) dhe zgjidhni artikullin Shto të gjitha fushat në menynë e kontekstit.
Për ata që nuk e dinë, unë do të shpjegoj thelbin e këtij operacioni. Këtu krijojmë një grup të paracaktuar fushash DataSet. Nëse nuk e bëjmë këtë me dorë në modalitetin e projektimit, atëherë, në parim, asgjë e tmerrshme nuk do të ndodhë. Në RunTime, ky grup do të krijohet automatikisht. Por unë ende preferoj ta krijoj me dorë. Ka disa arsye për këtë. Së pari, është më i përshtatshëm për të menaxhuar një grup fushash, sepse ne mund të krijojmë vetë fusha shtesë (të llogaritura ose të kërkimit) në modalitetin e projektimit. Ne gjithashtu mund të ndryshojmë vetitë e vetë fushave. Dhe përveç kësaj, ne kemi mundësinë t'u referohemi fushave në kod me emrin e komponentit TField, i cili, për mendimin tim, thjeshton shumë shkrimin e kodit.
Ashtu si në rastin me aplikacionin VCL, ne do të lidhim komponentin me grupin e të dhënave TDataBurimi. Ky komponent do të sigurojë lidhjen midis grupit të të dhënave dhe kontrolleve vizuale. Vetia DataSet e komponentit duhet t'i referohet grupit tonë të të dhënave (ADTProduct). Më poshtë jap një fragment të skedarit DFM
objekti ADTProdukti: TADTable IndexFieldNames = "ID" Lidhja = ADConnection UpdateOptions. UpdateTableName = "Produkt" TableName = "Produkt" Majtas = 64 Sipër = 192 objekt ADTProductID: TADAutoIncField Emri i fushës = "ID" Origjina = "ID" ProviderFlags = [pfInWhere, pfInKey] ReadOnlyTreductFieldT: Origjina = "Titulli" Madhësia = 50 objekti fundor dsProdukti: TDataSource Set = ADTProdukti majtas = 120 Top = 192 fundKushtojini vëmendje një veçorie kurioze, skedari i formularit DataModule nuk ruhet në formatin FMX, si një formë e zakonshme FireMonkey, por në formatin DFM, si në VCL.
Hapi tjetër është krijimi i një procedure për hapjen e një grupi të dhënash, të cilën do të na duhet ta thërrasim në RunTime kur të fillojë programi. Le ta krijojmë atë në të njëjtin DataModule. Kodi i procedurës është jashtëzakonisht i thjeshtë:
procedura TDM. ConnectToDB; filloni ADConnection. hapur(); Produkt ADT. hapur(); fundi ;Thirrja e procedurës do të vendoset në mbajtësin e ngjarjeve OnCreate për DataModule.
FireMonkey është teknologjia thelbësore e "New Delphi". Ju lutemi na tregoni për qëllimet, aftësitë dhe aspektet teknike të kësaj biblioteke thelbësisht të re. Pas pak, duke parë prapa, sa i vështirë dhe i justifikuar ishte refuzimi juaj për të zhvilluar më tej VCL-në super popullore?
Ai u zgjodh si drejtimi kryesor për zhvillimin e teknologjisë Delphi për të arritur një qëllim specifik - zhvillim me shumë platforma nga një mjedis, bazuar në një bazë të vetme kodi burimor dhe pa nevojën e rikualifikimit radikal të zhvilluesve. Në kuadrin e VCL-së tashmë klasike dhe jashtëzakonisht të njohur, kjo ishte e pamundur, lidhja e saj me WinAPI ishte shumë e ngushtë, mund të thuhet, "në nivelin gjenetik".
Komponentët VCL nuk kishin një shtresë "abstrakte" midis nivelit funksional për sa i përket ndërfaqes dhe mekanizmave të tyre të hartës. Niveli funksional- si sillet si kontroll, ndaj çfarë ngjarjesh reagon, çfarë lloj ndërveprimi me përdoruesit ofron. Ekrani- thirrja e metodave të renderimit të orientuara nga platforma si një lloj imazhi i formuar nga objekte raster dhe primitivë vektorialë. FireMonkey fillimisht zbatoi parimin e ndarjes rigoroze të kontrollit në dy komponentë: "sjellës" dhe "vizual".
Vsevolod Leonov, Embarcadero Technologies
E para në tërësi nuk do të përsërisë as bazat e VCL, por thelbin e programimit të orientuar nga objekti. Një komponent është një klasë, klasat e komponentëve formojnë një hierarki ku mund të dallohen familjet dhe modulet. Klasa e një komponenti ka pak të bëjë me mënyrën se si është dhënë.
"Piktura" vizuale është formuar në mënyrë dinamike, nuk është e koduar në klasën e komponentëve. Një imazh ose "stili" në FireMonkey ngarkohet në një komponent kur fillon aplikacioni. Ne kemi një lloj kornize funksionale për komponentin, dhe "lëkura" ose "veshja" mund të ndryshohet, por pse? Kjo është arsyeja pse aplikacionet FireMonkey duken autentike në çdo platformë - Windows 7, Windows 8, Mac OS, iOS dhe, në të ardhmen e afërt, Android. Struktura tradicionale monolitike e klasës VCL nuk mund ta siguronte këtë.
Këtu, qasja teknologjike luan një rol të veçantë. Në parim, ju mund të merrni bibliotekën VCL dhe të "plotësoni" WinAPI me të gjitha thirrjet e tjera të mundshme në platformë. Në një nëngrup shumë të kufizuar komponentësh, kjo ende mund të bëhet, por VCL përmban disa qindra komponentë, kështu që kjo qasje thjesht mund të "vrasë" VCL-në. U vendos që të mos preket VCL dhe të zhvillohen veçori të reja në platformën e re - FireMonkey. Kjo teknologji madje ka një elegancë të caktuar teknike - në kohën e ndërtimit të projektit për një platformë specifike, Delphi IDE lidh përpiluesin e nevojshëm dhe përbërësit e ndërfaqes marrin stilin e platformës.
Për përdoruesin, ky është një klikim i miut dhe i njëjti kod burim, për Delphi, është shumë vite punë e vështirë e zhvilluesve për të krijuar një bibliotekë të tillë me shumë platforma.
Kur u bë e qartë se FireMonkey do të prezantohej si një platformë e re më vete, duhej zgjedhur strategjia e duhur e bashkëjetesës: Embarcadero nuk donte të ndikonte negativisht në përdoruesit e VCL në asnjë mënyrë. Prandaj, ne kemi zgjedhur planin e mëposhtëm: VCL mbetet i qëndrueshëm ideologjikisht dhe arkitekturisht për të siguruar përputhshmërinë më të madhe të mundshme, duke e bërë më të lehtë migrimin e projekteve në versionet moderne. Zhvillimi i FireMonkey do të ndjekë një rrugë të natyrshme dhe paralele, pa shikuar prapa në VCL.
Pika e dobët e kësaj zgjidhjeje është migrimi mjaft problematik nga VCL në FireMonkey brenda një projekti. Por nga ana tjetër, për një projekt të ri, një zhvillues mund të zgjedhë FireMonkey për të siguruar natyrën multi-platformë të aplikacionit të tij që rezulton. Me lëshimin e XE4 me mbështetje iOS, tashmë mund të flasim për avantazhin e fortë konkurrues të Delphi për zhvillimin e celularëve në mjedisin e korporatës, i cili do të rritet pas zbatimit të mbështetjes së planifikuar për Android.
Prandaj, si i tillë, nuk ka asnjë "refuzim" të qartë nga zhvillimi i VCL. Në versionet e reja, pjesa VCL e Delphi është gjithashtu duke u zhvilluar. Kjo përfshin mbështetjen për 64-bit, dhe futjen e stilimit për komponentët vizualë, dhe zbatimin e një mekanizmi për lidhje dinamike fleksibël ose "lidhje", dhe përfshirjen e bibliotekës FireDAC për të punuar me bazat e të dhënave në projektet VCL. Është vetëm se në sfondin e një hapi gjigant cilësor për shkak të FireMonkey, përparimi në VCL duket disi i pamanifestuar. Por sido që të jetë, VCL është një pjesë integrale e Delphi dhe do të mbetet e tillë për shumë vite në vijim. Edhe pse evolucioni i platformave dhe gjendja aktuale e punëve në fushën e OS për sistemet desktop dhe pajisjet mobile janë të tilla që e ardhmja është e qartë me FireMonkey.
Në intervistë, ne kemi diskutuar tashmë mbështetjen për iOS, le t'u tregojmë lexuesve tanë për mbështetjen e të tjerëve teknologjitë më të fundit nga RAD Studio XE4 më i fundit, si Windows 8 dhe WinRT, sistemet 64-bit, MacOS etj. A mund të rendisni çfarë tjetër mund t'i ofroni një programuesi modern të llastuar me risi?
Me shumë mundësi, programuesi modern nuk është "prishur" nga risitë. Për projektet e mëdha, çdo "risi" shpesh kthehet në një punë gjigante.
Për shembull, të gjithë pritën një kohë të gjatë, shumë nxituan menjëherë për të transferuar kodet e tyre në një platformë të re. Por rezulton se edhe ekipet shumë profesionale nuk janë gati për këtë. Kodi 64-bit i përpilueshëm nuk do të thotë i zbatueshëm. Filluan të shfaqen "Mëkatet e rinisë", si p.sh. përdorimi i udhëzimeve duke supozuar një madhësi adrese prej 4 bajtësh. Mungesa e kulturës së kryerjes së testeve, e shoqëruar me mosgatishmërinë teknologjike për ta zbatuar këtë proces në një kohë të shkurtër.
Dhe këtu - sa më i madh të jetë projekti, i matur, për shembull, me numrin e linjave të kodit burimor, aq më me kujdes dhe më të ekuilibruar programuesit trajtojnë lloje të ndryshme risive, duke filluar nga shfaqja e një "butoni" në ndërfaqe deri tek "sheqeri sintaksor". në përpilues.
Një nga këto arritje “problematike” ishte lëshimi i Windows 8. Personalisht, si përdorues i kompjuterit dhe thjesht një specialist modern i IT-së, jam i kënaqur me Windows 8. Por për zhvilluesit të cilëve u dërguan një grup kompjuterësh Windows 8 me specifikime teknike për zhvillim nën sistemin operativ të ri si ngarkesë, kjo do të thotë vështirësi të caktuara.
Ne u përpoqëm të ofrojmë mbështetje për zhvillimin në mënyrën më komode dhe pa dhimbje. ndërfaqe e re ky OS. Prandaj, janë prezantuar stile të veçanta si për VCL ashtu edhe për FireMonkey, dhe programuesi ose mund të rindërtojë ndërfaqen e aplikacionit ose të krijojë një aplikacion të ri që do të jetë i padallueshëm nga ai "vendas" për Windows 8 në dukje. Natyrisht, ka nevojë për një "vendas" mbështetje për Windows 8 për shkak të WinRT. Por këtu prioritizimi i qëllimeve në kushte moderne. Mac OS, iOS, Android në të ardhmen e afërt nuk japin ende mundësinë për të folur për mbështetjen e plotë të WinRT në të ardhmen e afërt.
Qëllimi strategjik i Embarcadero është, natyrisht, multi-platformë. Lëshimi i RAD Studio XE4 ishte thelbësor, kryesisht për shkak të mbështetje për iOS. Një programues aktiv që përdor VCL mund të fillojë të zhvillohet për iOS brenda disa orësh. Edhe një aplikacion i thjeshtë celular mund të shndërrohet menjëherë në një projekt të fuqishëm që funksionon brenda infrastrukturës ekzistuese. Mos mendoni se ky është vetëm një përpilues i ri për FireMonkey dhe stil i ri për t'u përshtatur me ndërfaqen iOS.
Kjo përfshin një projektues të ri vizual, mbështetje të integruar për faktorë të ndryshëm formash dhe biblioteka të aksesit të të dhënave, duke përfshirë teknologjinë e re FireDAC dhe LiveBindings për lidhjen fleksibël dhe dinamike me të dhënat e korporatës. Të gjitha këto risi vijnë njëkohësisht - për Windows, dhe për Mac OS dhe për iOS. Sistemi operativ Mac OS nuk po zhvillohet aq shpejt, kështu që nuk ka probleme të tilla si kalimi nga Windows 7 në Windows 8. Por u shfaqën ekranet Retina dhe kjo kërkonte vëmendje të veçantë. Tani çdo aplikacion MacOS i krijuar në Delphi XE4 përfshin automatikisht dy stile - "normal" dhe "me definicion të lartë".
Se. i njëjti aplikacion mund të ketë të njëjtën cilësi ndërfaqe "amtare" në çdo kompjuter desktop nga Apple.
Embarcadero nuk dëshiron të "surprizë", "mahnis" apo edhe "argëtojë" zhvilluesit me publikimet e reja inovative. Përkundrazi, përkundrazi, sfera e IT-së është tashmë plot me surpriza të ndryshme: pajisje të reja, platforma të reja, përdorues të rinj, nevojat e tyre të reja, skenarë të rinj ndërveprimi. Shtoni teknologji të reja të zhvillimit të softuerit në këtë, dhe programuesit thjesht nuk do të kenë kohë për të krijuar sisteme të reja dhe në ato ekzistuese - ata do të bëjnë vetëm atë që të migrojnë nga një mjedis në tjetrin, nga një bibliotekë e vjetër në një të re, nga një gjuhë në një tjetër.
Por ne nuk e rrëfejmë refuzimin e çdo gjëje të re. Thjesht duam të sigurojmë vazhdimësinë e gjithçkaje - kodin, ndërfaqen, projektin, madje edhe aftësitë profesionale kur shfaqen platforma dhe pajisje të reja. Mund të themi se po luftojmë një konservatorizëm jo të shëndetshëm në lidhje me platformat e reja në kurriz të një konservatorizmi të shëndetshëm në mjetet e zhvillimit. Mos prisni produkte ekzotike, gjuhë programimi jo standarde dhe mjete të çuditshme zhvillimi nga Embarcadero.
Tek ne do të gjeni gjithmonë zhvillim vizual, gjuhë klasike, kod "amtare" dhe le të jenë të reja platformat e synuara për aplikacionet tuaja të krijuara në të njëjtën mënyrë klasike të provuar.
Çfarë është Fire Monkey?
FireMonkey (FMX) është një kornizë për zhvillimin ndër-platformë për të dy sistemet desktop (Windows, Mac OS + në të ardhmen e afërt është planifikuar të mbështesë pjesën e serverit në Linux) dhe celular (iOS dhe Android) duke përdorur gjuhën Delphi/C++ .
Veçoritë:
bazë e vetme e kodit për të gjitha platformat;
çdo kontroll (komponent vizual) mund të jetë një kontejner (prind) për komponentët e tjerë;
prania e një rregullimi relativ shumë të avancuar (20 lloje) të komponentëve në formular;
LiveBinding ju lejon të lidhni çdo lloj të dhënash ose informacioni me çdo ndërfaqe të përdoruesit ose objekte grafike;
prania e stileve të formës/komponentit;
Pamja paraprake me shumë pajisje ju lejon të personalizoni prezantimin vizual për secilën prej platformave;
Paraprakisht FireUI Live - Shfaq pamjen e aplikacionit në pajisjet reale në kohë reale.
Mundësitë:
përdorimi i API-së amtare të secilës prej platformave, si dhe aftësia për të thirrur bibliotekat vendase të palëve të treta;
ndërveprimi me të gjithë sensorët (GPS, Akselerometër, Compass, Bluetooth (përfshirë LE) dhe të tjerë);
mbështetje për njoftimet push, IoT;
mbështetje për kërkesat asinkrone HTTP;
mbështetje për shumicën e bazave të të dhënave (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, etj.);
punë me Cloud Service (Amazon, Azure);
mbështetje për shërbimin android.
Kundër (aktualisht):
mungesa e mbështetjes për personalizimin e klasave amtare;
zbatimi i gjërave specifike është ose i pamundur (widgets, zgjerime (iOS), etj.) ose është i nevojshëm një kërcim me një dajre (shërbim në sfond, mesazh transmetimi, etj.);
personalizimi Ekrani spërkatës (ekrani fillestar) për ta thënë butë, jo;
Kontrollet FMX përdorin interpretimin e tyre (vizualizimi, vizatimi), i cili është thjesht i ngjashëm vizualisht me atë vendas;
përdorimi i kontrolleve vendase shoqërohet me lëvizje të mëdha të trupit;
me një fole të madhe të komponentëve, ndodhin gjëra të pabesueshme: aplikacioni rrëzohet në vende të ndryshme, fokusi humbet, ngrin, etj.;
përmbajtja e informacionit të korrigjimit të një aplikacioni në platformat celulare është zero;
përshkrimet e gabimeve në platformat celulare reduktohen në "Gabim 0x00000X" të padobishëm;
koha e përpilimit dëshiron të jetë më e mira për projektet e mesme dhe të mëdha;
nevoja për të përdorur një skedar për të rafinuar aplikacionet celulare për secilën platformë;
nuk ka mbështetje për arkitekturën Intel Atom;
çmim joadekuat në krahasim me konkurrentët.
Të mirat:
zhvillim shumë aktiv i kohëve të fundit si i produktit ashtu edhe i komunitetit, mbështetje për gjithnjë e më shumë teknologji të reja;
prania e një numri të madh të komponentëve falas dhe komercialë;
shpejtësia e aplikacionit është shumë afër me vendasin;
një redaktues vizual dhe mjedis shumë i avancuar në përgjithësi, prania e stileve;
aftësia për të testuar aplikacionin në Win, dhe vetëm atëherë vendosjen e tij në pajisje, gjë që përshpejton shumë zhvillimin;
ndryshoni modalitetin/platformën me një lëvizje të kyçit të dorës;
PAServer siguron ndërveprim të lehtë me MacO kur zhvillohet për Apple OS;
mbështetje për grafika 3D jashtë kutisë.
Si përfundim, dua të them se gjatë dy viteve të fundit, FireMonkey është rritur në një mjet profesional për zhvillimin ndër-platformë të aplikacioneve të biznesit dhe jo vetëm. Shumë mangësi po zgjidhen gradualisht dhe me çdo lëshim produkti bëhet më modern dhe më i vetë-mjaftueshëm, si dhe zhduket skepticizmi ekzistues ndaj vetë gjuhës Delphi, i shoqëruar me stanjacion shumë vjeçar. Shkrimi i projekteve të reja në FireMonkey është "i sigurt" dhe premtues.
Po ngarkohet...