Firemonkey fra enkelt til komplekst. Hva er FireMonkey? mangel på støtte for å tilpasse innfødte klasser
Hva er FireMonkey?
FireMonkey (FMX) er et rammeverk for utvikling på tvers av plattformer for både stasjonære systemer (Windows, Mac OS + serverstøtte på Linux er planlagt i nær fremtid) og mobil (iOS og Android) ved bruk av Delphi/C++-språket.
Egenskaper:
enkelt kodebase for alle plattformer;
enhver kontroll (visuell komponent) kan være en beholder (foreldre) for andre komponenter;
tilstedeværelsen av et veldig avansert relativt arrangement (20 typer) av komponenter på skjemaet;
LiveBinding lar deg koble alle typer data eller informasjon til et hvilket som helst brukergrensesnitt eller grafiske objekter;
tilstedeværelse av form-/komponentstiler;
Multi-Device Preview lar deg tilpasse den visuelle presentasjonen for hver plattform;
FireUI Live Preview - viser utseendet til applikasjonen på ekte enheter i sanntid.
Muligheter:
bruk av den opprinnelige API-en til hver plattform, samt muligheten til å ringe tredjeparts opprinnelige biblioteker;
interaksjon med alle sensorer (GPS, akselerometer, kompass, Bluetooth (inkludert LE) og andre);
støtte for push-varsler, IoT;
støtte for asynkrone HTTP-forespørsler;
støtte for de fleste databaser (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, etc.);
arbeider med Cloud Service (Amazon, Azure);
Android Service-støtte.
Ulemper (for øyeblikket):
mangel på støtte for å tilpasse innfødte klasser;
implementering av spesifikke ting er enten umulig (widgets, utvidelser (iOS), etc.) eller en dans med en tamburin er nødvendig (bakgrunnstjeneste, kringkastingsmelding, etc.);
Tilpasning av Splash-skjermen (startskjermen) mangler mildt sagt;
FMX-kontroller bruker sin egen gjengivelse (visualisering, tegning), som rent visuelt ligner den opprinnelige;
bruken av innfødte kontroller involverer store kroppsbevegelser;
når det er mye nesting av komponenter, skjer utrolige ting: applikasjonen krasjer på forskjellige steder, mister fokus, fryser osv.;
informasjonsinnholdet ved feilsøking av en applikasjon på mobile plattformer er null;
beskrivelser av feil på mobile plattformer er redusert til den ubrukelige "Feil 0x00000X";
kompileringstiden ønsker å være den beste for mellomstore og store prosjekter;
behovet for å bruke en fil til å polere mobilapplikasjoner for hver plattform;
ingen støtte for Intel Atom-arkitektur;
utilstrekkelig pris sammenlignet med konkurrentene.
Fordeler:
svært aktiv utvikling av både produktet og fellesskapet i det siste, støtte for flere og flere nye teknologier;
tilstedeværelsen av et stort antall gratis og kommersielle komponenter;
Hastigheten på applikasjonen er veldig nær native;
svært avansert visuell redaktør og miljø generelt, tilstedeværelsen av stiler;
muligheten til å teste en applikasjon på Win, og bare deretter distribuere den på enheter, noe som øker utviklingen betydelig;
endre modus/plattform med et knips med håndleddet;
PAServer gir enkel interaksjon med MacO-er ved utvikling for Apple OS;
3D-grafikkstøtte rett ut av esken.
Avslutningsvis vil jeg si at FireMonkey i løpet av de siste par årene har vokst til et profesjonelt verktøy for plattformutvikling av forretningsapplikasjoner og mer. Mange mangler blir gradvis løst og for hver utgivelse blir produktet mer moderne og selvforsynt, og den eksisterende skepsisen til selve Delphi-språket, forbundet med mange års stagnasjon, forsvinner også. Å skrive nye prosjekter i FireMonkey er "trygt" og lovende.
Delphi XE2, som ble utgitt i september i fjor, inneholder rekordmange innovasjoner.
Korte oversikter over egenskapene til Delphi XE2 er allerede publisert på Habré. Men, åpenbart, den mest slående innovasjonen er FireMonkey-plattformen, og her vil jeg gjerne være litt oppmerksom på den.
Jeg har laget et lite utvalg av lenker til materialer som jeg håper vil hjelpe deg med å få en mer eller mindre tilstrekkelig ide om denne plattformen. Men først, for de som ikke er i det, vil jeg kort fortelle deg hva FireMonkey er.
Embarcadero Technologies posisjonerer FireMonkey som en plattform for å lage rike forretningsapplikasjoner for Windows, Mac og iOS. Dessuten er denne plattformen hjemmehørende i hvert operativsystem, dvs. Når du kjører en applikasjon som er opprettet med FireMonkey, brukes ingen ekstra tillegg.
FireMonkey kobler direkte til et innebygd (fra et OS-perspektiv) grafikkbibliotek som OpenGL eller DirectX. Dermed foreslås den beste løsningen fra et GPU-synspunkt.
Kjernen i FireMonkey-arkitekturen er et kraftig bibliotek med klasser (inkludert visuelle komponenter).
Målplattformen velges under kompileringsprosessen.
Den første versjonen av FireMonkey støttet kun Win32, Win64, MacOSX og iOS, men Embarcadero planlegger å portere den til flere andre plattformer i fremtiden.
Hva bør du vurdere?
Selv om FireMonkey-plattformen tilbyr omfattende verktøy for å utvikle 3D-applikasjoner, bør den ikke betraktes som en spillmotor. FireMonkey er posisjonert spesifikt som en plattform for utvikling av forretningsapplikasjoner.
Produktet er for tiden i de innledende stadiene av utviklingen. Og mange funksjonalitet FireMonkey gjennomgår endringer, både kvalitative og kvantitative.
Jeg håper lenkene nedenfor vil hjelpe deg å forstå hovedfunksjonene til den nye plattformen.
Offisiell produktside på Embarcadero-nettstedet (russisk)
Blant det engelskspråklige materialet vil jeg fremheve serien (engelsk)
Hva er det å se?
Angående siste versjon Delphi, det er mer videomateriale dedikert til egenskapene til produktet og hvordan man jobber med det enn noen gang før. Både offisielle, fra Embarcadero, og fra uavhengige utviklere. Det er mange videoer om FireMonkey på YouTube, du kan bare bruke søket. Blant denne overfloden av materiale vil jeg fremheve en serie på tre videoer fra Marco Cantu - RAD in Action-destinasjonssiden, og dermed gi forskningen min en vektor av nytte.
Du er sannsynligvis klar over at Embarcadero aktivt fremmer sin nye visjon om å lage et grensesnitt på tvers av plattformer - FireMonkey ( de kaller det et rammeverk, men for den nåværende tilstanden høres det for kult ut). Den ene konkurransen etter den andre utlyses på RuNet, det holdes webinarer, og selv om kvaliteten på sistnevnte lar mye å være ønsket, er aktiviteten oppmuntrende. Nå, faktisk, til temaet. Som en del av den siste konkurransen ble det foreslått å utvikle en slags applikasjon for læring. Og i går dukket det opp et annet verk forfatter av Evgeniy Chmel ( Jeg vet ikke om dette etternavnet er tilbøyelig eller ikke). I motsetning til de enkle "enformede" som ble sett tidligere, ble det her forsøkt å trekke apen med alle lemmer: stilisering, 3D, skyggeeffekter ( Embarcadero-evangelister elsker å snakke om GPU-akselerert grafikk :))). La oss se hva som kom ut av det. For de som ikke har sett webinarene, vil jeg gjøre en liten digresjon. På et av webinarene fortalte Embarcadero-evangelisten Vsevolod Leonov en hjerteskjærende historie om hvordan han måtte "starte datamaskinen på nytt, spesielt hardt" (dette er et sitat) på grunn av det faktum at Silverlight SDK og Windows-emulator Telefon 7 "fungerte ikke" (dette er et sitat) på datamaskinen hans fordi... De likte ikke videoadapteren eller GPU-innstillingene. Men applikasjoner utviklet med FireMokey, fortsetter Vsevolod, er slett ikke krevende maskinvare. La oss se hvordan han løy for oss. Process Explorer v15.05 fra Mark Rusinovich vil være vårt upartiske vitne. Så last ned Evgeniys applikasjon og start ( Jeg gir ikke skjermbilder av Evgeniys applikasjon, de er tilgjengelige på lenken til arbeidet hans. Legg merke til de uskarpe skriftene).
Lanserte applikasjonen. La oss se på forbruket:
Ubeskjeden, men du kan tilgi" avansert teknologi" Gå til delen "Leksjoner" og velg "Leksjon 5". Sceneforberedelsen begynner. Denne prosessen er lang ( Det tok meg litt over et minutt, på en firekjerners Phenom II med en frekvens på 3,3 GHz), vær tålmodig. Scenen er bygget. La oss se på forbruket:
Apen ble godt matet. Veldig bra. Prøv nå å flytte musen over svaralternativknappene. Det føles som om GUI reagerer veldig tregt, ikke sant? Se på grafen for CPU-bruk ( Jeg mener du bør prøve det selv, på datamaskinen din) – i disse øyeblikkene nærmer belastningen seg 100 % ( Jeg hadde ~21,5% for en firekjerners prosessor, som tilsvarer 86% for en enkeltkjerne). Men noen fortalte oss om GPU-akselerert grafikk. Ok, la oss gå videre. Vi svarer på alle spørsmålene i leksjonen. La oss se på forbruket:
Er øynene dine store? Se nå, for sammenligning, hvor mye 3D-skytespillet FarCry bruker med aktivt spill ( nivået heter Factory, hvis noen er interessert) kjører i fullskjermmodus 1440x900:
Trekk dine egne konklusjoner.
Mer enn tre år har gått siden CodeGear-divisjonen, ansvarlig for opprettelsen av verdenskjente verktøy som Delphi, C++Builder og JBuilder, samt Interbase-databasestyringssystemet, ble en del av Embarcadero Technologies, kjent for sine verktøy for databasedesign og administrasjon, og to år siden vi diskuterte på sidene i magasinet vårt hva vi kan forvente i utviklingen av verktøy som er så populære blant Russiske utviklere. Vi spurte David Intersimone, visepresident for utviklerrelasjoner og sjefevangelist i Embarcadero Technologies, og Kirill Rannev, leder av Embarcadero Technologies representasjonskontor, om å snakke om hva nytt som har blitt gjort på dette området de siste to årene og hva du kan forvente i nær fremtid, Russland. For våre yngste lesere vil vi informere om at dette ikke er det første intervjuet David og Kirill gir til ComputerPress - samarbeidet vårt har pågått i det andre tiåret. Og i omtrent like mange år har vi med jevne mellomrom publisert anmeldelser av databaseadministrasjonsverktøy, der Embarcadero-produkter vies mye oppmerksomhet.
Datamaskinpress: David, avdelingen din har vært en del av Embarcadero i tre år. For to år siden var du entusiastisk over å bli en del av et selskap nær dine mål og ånd. Har noe endret seg i løpet av denne tiden? Har du og kollegene dine fortsatt den samme entusiasmen?
Ja, jeg er fortsatt veldig entusiastisk. Den viktigste endringen som har skjedd siden vi ble en del av Embarcadero-selskapet er at det har blitt investert mye i utviklingen av Delphi. Antallet personer som jobber med utviklingsverktøy har økt, og antallet teknologier vi kan utvikle eller om nødvendig anskaffe, har økt.
Utgivelsen av RAD Studio XE 2, som vi planlegger å demonstrere i Moskva, er den største utgivelsen av dette produktet med enorme muligheter og et stort antall støttede plattformer siden den første versjonen av Delphi, laget for 16-biters versjonen av Windows og som var et innovativt produkt som kombinerte komponenttilnærming og kompilering til maskinkode. Nå støtter vi utvikling ikke bare for Windows, men også for Macintosh, for ikke å snakke om webutvikling og oppretting av applikasjoner for mobile enheter, og disse applikasjonene for forskjellige plattformer kan ha en enkelt kode.
Den nye utviklingsplattformen - FireMonkey - er et samarbeid mellom Embarcadero og det nylig oppkjøpte russiske firmaet KSDev fra UlanUde, en produsent av komponenter for vektorgrafikk, DirectX og OpenGL, grafikkeffektteknologier og Delphi komponenter ved hjelp av GPU med PixelShader 2.0. Vi kjøpte selskapet KSDev (se ksdev.ru) for et år siden og startet samarbeidå lage et multiplattformutviklingsverktøy som inkluderer FireMonkey-amed Delphi- og C++Buider-komponenter for oppretting av applikasjonsbrukergrensesnitt, databaseintegrasjon, GPU-grafikkbehandling og operativsystemintegrasjon.
Ved å bruke FireMonkey kan du lage en applikasjon som kjører på CPU og GPU sammen, og deretter bruke forskjellige kompilatorer og Run-time Libraries (RTLs) for å kompilere den for Windows, Mac OS eller iOS. I stedet for å lære å programmere ved hjelp av forskjellige grafikkbiblioteker, lære API-ene til forskjellige plattformer som har forskjellige koordinatsystemer og forskjellige muligheter, kan utviklere som bruker Delphi og C++Builder bruke den samme komponentbaserte tilnærmingen, visuelt redigere skjemaer og koble til databaser ved å flytte komponenten med musen. Dette er en fundamentalt ny måte å lage applikasjoner på som kjører på forskjellige plattformer, og det er fremtiden. Hvis du vil legge til støtte for andre operativsystemer og plattformer til applikasjonen din, trenger du ikke designe og utvikle den på nytt - du trenger bare å kompilere den på nytt.
Vi lager nye kompilatorer som genererer innfødt kode. I dag er det Delphi-kompilatorer for 32- og 64-bit Windows-versjoner, 32-biters versjoner av Mac OS 10. Og vi jobber med neste generasjon av Delphi og C++Builder kompilatorer som lar deg lage høyytelses maskinkode for både disse og andre plattformer som Android eller Linux, og beholde samme design, samme komponenter, samme kode ved å bruke forskjellige kompilatorer og kjøretidsbiblioteker.
Som du ser, har jeg nok grunner til entusiasme. Og utviklerne jeg møter rundt om i verden vet at Embarcadero investerer tungt i Delphi og C++Builder, samt PHP-utviklingsverktøy.
KP: Hvilke suksesser har du oppnådd med å integrere verktøyene til de to selskapene de siste to årene? Hva er Embarcaderos planer for fremtiden på dette området?
DI.: På det tidspunktet CodeGear ble en del av Embarcadero, hadde selskapet utviklingsteam i Toronto, Monterrey og Romania, vi var og er fortsatt lokalisert i Scotts Valley og i Russland, i St. Petersburg. Embarcadero hadde verktøy for utviklere og databaseadministratorer, CodeGear hadde verktøy for applikasjonsutvikling, men sistnevnte bruker også databaser. Sammenslåingen av selskaper er en kombinasjon av kompetanse, kunnskap innen databaser, kodeoptimalisering, inkludert serverkode. Kombinasjonen av selskaper førte også til etableringen av et nytt produkt, AppWave, en spesiell teknologi for å gjøre en vanlig Windows-applikasjon til noe veldig enkelt å bruke (som applikasjoner for iPhone eller andre enheter). AppWave lar deg ikke installere en applikasjon, men bare velge den og starte den fra den forberedte applikasjonslagringsserveren (appen), og den vil bli utført på brukerens datamaskin uten å gjøre endringer i registeret og systemområdet. filsystem. AppWave-applikasjonsnettleseren er forresten skrevet i Delphi. Embarcadero bruker Dephi til sin egen utvikling og vår.
iPhone (iOS)-applikasjon laget av
ved hjelp av FireMonkey-plattformen
Du kan også bruke integrasjonen av våre utviklingsverktøy og DB Optimizer for å optimalisere SQL-spørringer når du lager applikasjoner. Ved å sende SQL-kode direkte inn i DB Optimizer kan du profilere den, teste den og returnere en optimalisert versjon tilbake til utviklingsmiljøet ditt. Embarcaderos databaseekspertise har også forbedret DataSnap-teknologien. Takket være utviklerne fra Toronto, fikk vi mye kunnskap om arkitekturen til flerlagssystemer og databaser. Vi har nå felles ekspertise på å lage serverkode og lagrede prosedyrer i begge selskapene. Vi har verktøy som RapidSQL og DB Change Manager, samt utviklingsmiljøer som forenkler oppretting av serverkode – for eksempel har Code Insight og Code Completion-teknologier muliggjort opprettelsen av SQL-innsikt og SQL Completion-teknologier. Våre vanlige tilnærminger til å lage klient- og serverkode, vår felles filosofi, lar oss gi felles funksjoner til databaseadministrasjonsverktøy og applikasjonsutviklingsverktøy.
Kirill Rannev: Jeg vil legge til noe viktig. Fra et kommersielt synspunkt er det veldig viktig hvordan vi leverer verktøyene våre. For eksempel, ny utgivelse RAD Studio XE 2 Ultimate inkluderer hele pakken med DB Power Studio-verktøy. Dette er et veldig kraftig sett med verktøy, inkludert RapidSQL spørringsutviklingsmiljøet, DB Change Manager endringsadministrasjonsverktøy og DB Optimizer spørringsoptimaliseringsverktøy, som lar deg utføre en viktig del av utviklings- og distribusjonsprosessen ved å administrere endringer i datamodellen, databasen, koden og så videre. Dette er en veldig god og riktig kombinasjon av teknologier.
DI.: Men om nødvendig kan utviklere bruke Subversion for versjonskontroll kildekode og DB Change Manager for metadataversjon. Du kan bruke kodeprofilering og DB Optimizer for å optimalisere serverkode, RapidSQL for å bygge og feilsøke serverkode, og utviklingsmiljøene våre for å bygge og feilsøke applikasjoner. Denne kombinasjonen av teknologier i RAD Studio XE Ultimate Edition demonstrerer parallellene mellom database- og applikasjonsutviklingsmodeller. De fleste utviklere som bygger forretningsapplikasjoner med Delphi og C++Builder jobber med databaser og trenger disse verktøyene, og RAD Studio XE Ultimate Edition er en flott kombinasjon for slike utviklere.
KP: Den moderne brukeren er ikke lenger en bruker av Windows-plattformen alene. Vi bruker mobile enheter, iPhone, iPad, enheter basert på Android-plattformen. Dette betyr at utviklere må begynne å målrette mot ulike plattformer uten å øke investeringene i opplæring nevneverdig – det vil si at det trengs universelle verktøy. Det er åpenbart urealistisk å forvente fremveksten av universelle verktøy fra plattformprodusenter, og i denne saken kan vi bare stole på uavhengige verktøyprodusenter. Hvordan kan vi stole på Embarcadero?
DI.: Vi har fortsatt mye å gjøre når det gjelder plattformstøtte. I dag introduserer vi støtte for iOS-plattformen for iPhone og iPad, deretter vil smarttelefoner basert på Android-plattformen, Windows 7 og Blackberry få vår støtte. I RAD Studio XE 2 startet vi med å bygge FireMonkey-plattformen for iOS og vil deretter bringe FireMonkey til andre plattformer.
Samtidig er det et stort antall operativsystemer som støtter berøringsskjermer for telefoner, nettbrett og stasjonære enheter, og vi vil fortsette å legge til støtte for dem. I tillegg er det stemme, bevegelse, biometriske systemer, akselerometre, så vi må fortsette å utvide FireMonkey slik at alle utviklere kan dra nytte av nye plattformer. For eksempel ble Microsoft Kinect-enheten designet for Xbox 360, og nå er det en tilsvarende SDK (Software Development Kit) for Windows. Og vi har allerede eksempler der vi bruker bevegelse til å kontrollere en applikasjon på omtrent samme måte som en mus eller et tastatur normalt ville blitt brukt.
Når du lager applikasjoner med mye kompleks grafikk, genererer du en hel verden av nye brukergrensesnitt. Hvis vi har å gjøre med en operasjonsstue Windows-system, kapsler vi inn anvendelsen programvaregrensesnitt Windows API i VCL-biblioteket (Visual Component Library - et bibliotek med visuelle komponenter som er en del av utviklingsverktøyene Delphi og C++Builder. - Merk utg.), som forresten kan brukes videre. Og i FireMonkey kapsler vi inn operativsystemets API. Men i dag manipulerer vi former og grafikk mye bredere. Du kan også legge til fysiske egenskaper til plassen for animasjon og spesialeffekter. I tillegg er det et stort antall andre tilleggsmuligheter for å lage brukergrensesnitt som vi skal implementere de neste årene for ulike plattformer, mobil- og nettbrett.
Microsoft annonserte nylig detaljert informasjon om Windows 8, som kommer ut om et år. Vi vil støtte disse innovasjonene i VCL-biblioteket og FireMonkey-plattformen. Men Delphi er et utviklingsverktøy designet ikke bare for Windows, men også for Macintosh, iPhone og iPad. Vi utvikler også våre PHP-produkter, støtter jQuery Mobile, bruker iOS API til å utvikle mobile klientapplikasjoner og lager PHP-applikasjoner på serversiden ved å bruke veivisere og verktøy for å generere JavaScript, HTML og overlappende stilark på klientsiden. Vi kan lage pakker fra PHP-applikasjoner og native-code klientapplikasjoner for iPhone iOS, og en slik klient vil kommunisere med PHP-server. Og han vil på sin side kommunisere med databaseserveren og med webtjenester – med alt som trengs for virksomheten.
RadPHP XE2 utviklingsmiljø. Opprette en mobil nettapplikasjon
bruker jQuery Mobile-komponenter for iPhone 3G
Med andre ord planlegger vi å utvide mulighetene til FireMonkey og VCL, inkludert støtte for mobile plattformer.
KP: Kan du fortelle oss mer om FireMonkey-plattformen?
DI.: Som jeg allerede har nevnt, vil VCL-biblioteket som er opprettet for Windows fortsette å utvikle og forbedre. Men i dag, hvis du vil ha ekte, må du lage dem for forskjellige plattformer. Dette er hva FireMonkey-plattformen er designet for. Den støtter oppretting av høyoppløselige brukergrensesnitt med høy ytelse 3D-grafikk, høy bildefrekvens og, viktigere, bruker en grafikkprosessor for dette.
Du kan bruke slike evner når du lager vitenskapelige, tekniske og forretningsapplikasjoner. Slike applikasjoner kan koble til databaser ved hjelp av dbExpress-teknologi, fortsatt bruke ikke-visuelle komponenter kjent for utviklere, for eksempel ClientDataSet eller DataSource, bruke DataSnap-teknologi, koble til hvilken som helst database, SOAP og REST-servere. Du kan lage attraktive kontroller, knapper med bokser, uvanlige tabeller og andre grensesnittelementer, både i to og tre dimensjoner. Du kan laste en ferdig 3D-modell inn i appen og koble den til en 2D-form der du kan rotere den og se den fra forskjellige vinkler. Du kan lage en datakube eller et 3D-forretningskart og rotere det ved hjelp av musen, tastaturet eller til og med en Kinect-enhet, eller du kan gå inn i kuben og se på dens forskjellige overflater fra innsiden. Og alt dette kan gjøres ved hjelp av en høyhastighets GPU. Den samme applikasjonen kan deretter kompileres for en annen plattform, for eksempel Mac OS.
En applikasjon som inneholder en roterende datakube,
plassert på kantene
Eller du kan lage en 3D-form fra bunnen av og bruke kameraer og lys til å belyse og rotere deler av brukergrensesnittet. Skjemadesigneren har allerede et innebygd miljø for å støtte et 3D-brukergrensesnitt under design.
På Windows for arbeid med todimensjonal grafikk høy oppløsning Du kan bruke Direct2D-biblioteker, og for tredimensjonal grafikk - Direct3D. På Mac OS brukes Quartz- og OpenGL-bibliotekene til samme formål. For iOS brukes Quartz- og OpenGL ES-bibliotekene. Men alt dette er skjult for utvikleren - han bruker FireMonkey-plattformen, dets koordinatsystem ogsnitt, uten å tenke på disse bibliotekene, og kan kompilere den samme applikasjonen for forskjellige plattformer.
La oss huske hva VCL er. VCL er en komponentomslag rundt Windows API. Vi håndterer ressurser, menyer, dialogbokser, farger, stiler, Windows-meldinger. FireMonkey er en multiplattform-innpakning, i motsetning til VCL, og beholder de samme hendelses- og komponentmodellene, slik at du kan tenke i form av hendelser (for eksempel OnClick, OnHasFocus, onMouseDown og onKeyDown-hendelser), men håndterer Macintosh- eller iPhone-hendelser.
FireMonkey-plattformen følger også med komplett system animasjon av brukergrensesnittelementer. Det er absolutt ikke et omfattende animasjonssystem i Pixar-stil, men det tillater effekter som bitmap-animasjon, fremheving av fokus på et brukergrensesnitt-element og arbeid med vektorgrafikk. Mer enn 50 visuelle effekter er tilgjengelige for utvikleren: uskarphet, gjøre bildet til svart-hvitt, oppløsning, overganger, refleksjon, skape skygger - alle typer effekter tilgjengelig i moderne grafikkprosessorer, som nå finnes i nesten alle datamaskiner. En applikasjon bygget ved hjelp av FireMonkey-plattformen sender kommandoer til GPUen, som gjør alt arbeidet med å vise grafikk og lage brukergrensesnittet. Hvori prosessor gratis for beregninger og anrop til operativsystemet. Utvikleren kan bare plassere komponentene riktig.
Det mest grunnleggende med FireMonkey-plattformen er måten den bygger brukergrensesnittet på. Det er overnattingsmuligheter rastergrafikk på grensesnittelementer som menyer, knapper og rullefelt. Hos FireMonkey bruker vi GPU-drevet vektorgrafikk til dette formålet. Fra et programmeringsperspektiv er dette fortsatt de samme kontrollene, men alt arbeidet med å vise dem utføres av grafikkprosessoren. Vi kan bruke stiler på kontroller, få applikasjonen til å se ut som en applikasjon for Mac OS eller Windows, lage vår egen stil, bruke våre egne stiler på grensesnittelementer (for eksempel gjøre en knapp rektangulær eller rund ved å endre stilen i skjemaeditoren ) - for dette Det er en stilredigerer i utviklingsmiljøet. Du kan lage din egen stil, eller du kan endre stilen til en allerede ferdig applikasjon.
FireMonkey-plattformen – utviklingsverktøy
og støttede plattformer
Hvis du husker, hadde VCL-biblioteket et begrenset antall kontroller - containere (det vil si at du kan plassere andre elementer i dem), og i FireMonkey er hver kontroll en container. Dette betyr at hver kontroll kan inneholde en hvilken som helst annen kontroll. For eksempel kan rullegardinlisteelementer inneholde bilder, knapper, redigeringsfelt og andre kontroller. Du kan også plassere komponenter i lag.
FireMonkey-gjengivelsessystemet er ganske fleksibelt - det kan bruke Direct2D-, Direct3D- og OpenGL-bibliotekene og sende kommandoer til GPUen. For å oppnå det samme i VCL, måtte du generere en separat buffer utenfor skjermen, lage et bilde i den ved å kalle de riktige funksjonene i grafikkbiblioteket, og deretter vise det på skjemaet.
Eksempler på grafiske effekter støttet av FireMonkey
Hvis du ikke har en GPU, kan du fortsatt bruke 2D- eller 3D-former og bruke FireMonkey-kontroller. I dette tilfellet vil FireMonkey-plattformen bruke GDI+-bibliotekene eller andre lignende biblioteker og utføre de samme effektene og animasjonene eller manipulasjonen av 3D-objekter.
En annen funksjon i FireMonkey er nytt system koble grensesnittelementer med data, åpent og fleksibelt. Det er to typer grensesnittelementer i VCL: databundet og ikke-databundet (for eksempel TDBEdit og TEdit). I FireMonkey kan hver kontroll assosieres med data av enhver type. Dette kan være et enkelt uttrykk, et felt fra et datasett, data fra utviklerskapte objekter eller resultatene av metodekall.
I tillegg, når du oppretter en applikasjon, kan du laste inn en ferdig 3D-modell i den og bruke den - slike evner kreves ofte i både forretnings- og ingeniørapplikasjoner. Vi har en oppdragsgiver som lager applikasjoner for logistikk. De hadde Informasjon System, bygget ved hjelp av Delphi, og i den - en applikasjon som tegnet en plan og viste informasjon fra datakilder. De gjorde nylig noe interessant – de tegnet et helautomatisert 3D-lager i AutoCAD, og applikasjonen deres lar deg se hvordan den automatiserte gaffeltrucken beveger seg rundt på lageret og plasserer varer i hyllene. Og de legger data fra kildene på det tilsvarende bildet.
Eksempler på endring av applikasjonsstiler
KP: Hvilke 3D-modellformater støttes for øyeblikket?
DI.: I denne utgivelsen støtter vi lasting av modeller fra AutoCAD, Collada (et åpen kildekode 3D-modelleringsverktøy. - Merk redigere.), Maya, et OBJ-format som støttes av mange 3D-grafikkleverandører.
KP: Hvilke andre formater planlegger du å legge til?
DI.: Vi planlegger å legge til 3DS (3D Studio MAX), SVG (vanligvis brukes dette formatet for 2D vektorgrafikk, men noen ganger for 3D), Google SketchUp. Kanskje vi støtter andre formater.
KP: Krever bruk av 3D-modeller i applikasjoner bygget med FireMonkey en lisens for det aktuelle 3D-modelleringsverktøyet?
DI.: Nei, det krever det ikke. Alt vi gjør er å lese modellfilen. Vi importerer modellen, men eksporterer den ikke (selv om du selvfølgelig kan skrive et program som lagrer modellen i ditt eget format). Vi later ikke til å være en produsent av 3D-modelleringsverktøy - for dette kan du bruke AutoCAD, 3D Studio Max, Maya eller et hvilket som helst annet 3D-modelleringsverktøy, og importere de opprettede modellene inn i applikasjonene våre.
KP: Hvor effektive er applikasjoner bygget med FireMonkey på moderne maskinvareplattformer?
DI.: Produktiviteten er ganske høy. For eksempel gjengivelse av en 3D-form med tre kuler og tre lyskilder på Macbook Pro kan utføres med en hastighet på 100 bilder per sekund. Eller det kan komme opp i 600 – det avhenger av hva vi gjør. Igjen, alt avhenger av kraften til GPU.
KP: Betyr dette at du kan lage moderne spill med FireMonkey?
DI.: Vi posisjonerer ikke utviklingsverktøyene våre som verktøy for spill. Men ved å dra nytte av den høye ytelsen til moderne GPUer, kan du lage spill ved hjelp av FireMonkey - de er tross alt laget med Direct3D eller OpenGL.
KP: Hvilket arbeid gjør du for øyeblikket innen området for å støtte gestgjenkjenning og andre nymotens ting? Er slik støtte tilgjengelig?
DI.: Vi har ikke geststøtte i denne utgivelsen ennå. Bevegelseskontroller vil bli lagt til i en fremtidig utgivelse av FireMonkey, men i mellomtiden kan du bruke bevegelsesstøtten innebygd i operativsystemet.
Mikhail Filippenko, direktør for Fast Reports, Inc.
K.R.: Vi har allerede sagt at FireMonkey-teknologien har russiske røtter - dens grunnlag ble skapt i vårt land, og da ble både teknologien selv og dens utviklere med i Embarcadero. Generelt er det gledelig å se veksten av den russiske komponenten i RAD Studio og Delphi. Dette inkluderer aktivitetene til vårt utviklingssenter i St. Petersburg og bidrag fra uavhengige russiske utviklere. For eksempel inkluderer Rad Studio XE2 rapportgeneratoren FastReport - kjent over hele verden og veldig populær i vårt land. Han er opprinnelig fra Rostov ved Don.
KP: Jeg vil gjerne snakke om kompilatorer. Hva slags kompilator brukes når du lager iOS-applikasjoner?
DI.: Vi har ikke vår egen Delphi-kompilator for iPhone eller iPad – vi har ennå ikke utviklet kompilatorer for ARM-prosessorene som brukes i disse enhetene. For iOS bruker vi midlertidig Free Pascal-kompilatoren og runtime-biblioteket. Men vi jobber med neste generasjon kompilatorer, inkludert for AWP-prosessorer. Men det finnes kompilatorer for Windows og Mac OS, siden begge maskinvareplattformene er basert på Intel-prosessorer.
KP: Hva har blitt gjort i feltet med å lage kompilatorer de siste to årene?
DI.: Vi har 32- og 64-bits Delphi-kompilatorer for Windows og Mac OS. Og vi jobber med en ny generasjon Delphi- og C++-kompilatorer. De pågår fortsatt, men når de er ferdige, vil vi ha Delphi-kompilatorer for ARM-prosessorer, Android-plattformer, Linux og alt i mellom. Og vi vil ha 64-bits C++-kompilatorer for Windows og andre plattformer, kompatible med den nyeste C++-språkstandarden som nettopp ble tatt i bruk av ISO.
KP: Hva skjer med støtte for cloud computing i Embarcadero utviklingsverktøy i dag?
DI.: I RAD Studio XE 2 støtter vi flytting av applikasjoner til Microsoft Azure eller Amazon EC2-skyen ved å bruke plattformassistenten. Og vi har serverkomponenter for Cloud Storage for Azure og Amazon S3 for lagring av tabeller, binære data, meldingskøer. I forrige versjon Med RAD Studio XE støttet vi også distribusjon av applikasjoner til Amazon EC2, men det manglet lagringsstøtte.
Cloud computing-støtte i RAD Studio XE 2
KP: For to år siden snakket du om den nye All-Access-løsningen. Hvor populær var den? Hva er fordelene for systemintegratorer og utviklere?
DI.: All-Access-løsningen og AppWave-skyverktøyet er mye brukt over hele verden. De er designet for å gjøre det enklere å bruke våre egne og tredjepartsapplikasjoner. Faktisk er det en løsning for å administrere lisenser og applikasjonsbruk, og den er praktisk for store selskaper. Mindre firmaer som ikke har dedikerte team med personer som er ansvarlige for å administrere applikasjoner, kan legge applikasjonen inn i et depot, velge brukernavn fra databasen og gjøre disse applikasjonene tilgjengelige uten å måtte huske hvor. lisensnøkkel og hvor mange lisenser som er tilgjengelige. All-Access og AppWave-nettleseren er utviklet for å administrere både versjonskontroll og tilgangskontroll.
K.R.: Markedet er så mangfoldig og brukerne er så forskjellige at det er umulig å dekke alle behov med én løsning. Derfor streber vi etter varierte emballasjeløsninger. Vi har gjort mye arbeid for å forene metodene for lisensiering, lisensadministrasjon og produktinstallasjon. Denne linjen med løsninger inkluderer lisens- og klargjøringsadministrasjonsverktøy, ikke bare for Embarcadero-produkter, men også for ethvert annet produkt, inkludert intern bedriftsutvikling.
Arbeidet med å pakke utviklingsverktøy til effektive sett for brukere pågår fortsatt. Vi har All-Access – et supersett som kombinerer alle Embarcadero-produkter. Hvis en kunde kjøper All-Access Platinum, mottar de alle verktøyene som finnes i Embarcadero. Men noen ganger viser dette settet seg å være overflødig; for eksempel for databasespesialister har vi laget to andre sett - DB Power Studio Developer Edition og DB Power Studio DBA Edition. Forskjellen mellom dem er at for utvikleren tilbyr vi RapidSQL - et verktøy for å utvikle serverkode, og for administratoren er det innebygd DBArtizan - et databaseadministrasjonsverktøy, et bredere produkt enn RapidSQL. For profesjonelle har vi følgende All-Access-suiter: en suite som inkluderer alle produkter, DB Power Studio for utviklere, DB Power Studio for administratorer, ER Studio Enterprise Edition for arkitekter og alle som er involvert i modellering. Det finnes kombinasjoner for applikasjonsutvikling og for administratorer. Delphi er et utviklerverktøy, og det er veldig fornuftig å legge til SQL-utviklings- og optimaliseringsverktøy til det. Endelig er DB Change Manager et logisk verktøy for å administrere kompleksiteten til endringer som skjer i databaser i løpet av deres livssyklus.
Dermed er All-Access leder av en stor familie av forskjellige produktsett.
KP: Hvis det ikke er en hemmelighet, hvem i Russland bruker All-Access?
K.R.: Vi har kunder som har kjøpt All-Access basert på Delphi. Mange av dem lager komplekse klient-serversystemer med SQL Server og Oracle, og de likte umiddelbart våre databaseverktøy på tvers av plattformer. Vi har et kundeselskap som har jobbet med Delphi siden den første versjonen, og for et år siden byttet det fra bruker Delphi til All-Access-settet. To verktøy som alle utviklere hos dette selskapet garantert vil bruke, er Delphi og DBArtisan. Og det er kunder som kom til All-Access fra databasesiden. Hovedoppgaven deres er å administrere databaser, men noen ganger utvikler de også applikasjoner. Kunder som bruker All-Access inkluderer medieselskaper, ingeniørfirmaer og andre bransjer.
Separat vil jeg fokusere på små selskaper. Svært ofte i små team gjør utvikleren alt, og et slikt selskap kjøper noen ganger store All-Access-produktsett for en eller to utviklere. I store team oppfordres det ikke til at en utvikler også utfører for eksempel rollen som databaseadministrator, så små produktsett er vanligvis populære der, men i små selskaper er en slik kombinasjon av ansvar ganske akseptabelt.
Delphi Architect er et sterkt markedsført produkt som inkluderer modellerings- og programmeringsverktøy. Antall solgte eksemplarer er imidlertid mindre enn Delphi Enterprise-versjonen, men det er også stort. Jeg vil merke meg at vi i 2010 viste seg å være det beste landet når det gjelder salgsvolum, til tross for at alle land opplevde en krise. Denne veksten var ikke så mye assosiert med økonomiske faktorer, men med det faktum at versjonen av RAD Studio XE, utgitt i slutten av 2009, viste seg å være veldig populær. Og foreløpig forventer vi ytterligere salgsvekst.
Vi har tatt et annet fornuftig skritt, som er ekstremt populært i Russland. Graden av legalisering av ulike versjoner av produktene våre er forskjellig: jo høyere versjon, jo mer legalisert er den, fordi tidligere programvare ikke så aktivt kjøpt. Fra og med RAD Studio XE, dekker lisensen versjonene 2010, 2009, 2007, og til og med Delphi 7, et mye brukt produkt.
I dag står utviklerne overfor at de har både nye prosjekter og prosjekter i støtte. Et stort antall prosjekter er overført fra tidligere versjoner Delphi til versjon 7 og forblir innenfor denne versjonen, fortsetter å jobbe med relativt små ressurser. Ingen flytter dem til nyere versjoner, men de opprettholdes i en levedyktig tilstand. Og nå lar vi deg få både RAD Studio XE og Delphi 7 for lite penger (mindre enn prisen på en Delphi 7-lisens) – det vil si at vi legaliserer utvikleren både for implementering av nye prosjekter og for støtteprosjekter.
KP: Hvordan vurderer du den nåværende tilstanden til Embarcadero-samfunnet?
DI.: Dette fellesskapet er stort og svært krevende. De trenger alt umiddelbart – de er utviklere. Men noen ganger tar det lang tid å gjøre noe riktig.
For noen år siden tok vi Windows-komponentarkitekturen og satte den på Linux-stasjonære datamaskiner. Nå ser vi at dette ikke var riktig avgjørelse. Den riktige løsningen er å lage en applikasjonsplattform. Applikasjoner selv på tvers av forskjellige plattformer har menyer, vinduer, grafikk, nettverkstilgang og enhetstilgang. Ulike plattformer kan ha ulike modeller flytkontroll eller unntakshåndtering, men i applikasjonskoden ser vi de samme prøveblokkene. Vår jobb er å gjøre det enklere for utviklere å lage forretningsapplikasjoner og kompilere dem for plattformene de er ment å brukes på, uavhengig av hvordan instruksjonssettet til de tilsvarende prosessorene er strukturert og hvilke andre funksjoner disse plattformene har. Og FireMonkey er akkurat det du trenger for å løse dette problemet.
KP: Hvis et selskap oppretter en ny enhet og ønsker at den skal støttes i FireMonkey, vil dette være mulig?
DI.: Med den nye generasjonen kompilatorer, som vil ha en plattformuavhengig front-end og en plattformavhengig back-end, vil dette være fullt mulig. I mellomtiden, for hvert operativsystem, lager vi et kompilator- og kjøretidsbibliotek fra bunnen av.
Enhver moderne ny enhet har som regel en grafikk brukergrensesnitt(mange av dem har dual core prosessor og GPU) og standard SDK-er for utviklere. Dette gjør det enklere å lage enhetsstøtte i FireMonkey. Hvis den nye enheten kun har biblioteker for todimensjonal grafikk som Quartz, vil vi kunne støtte en slik enhet i FireMonkey, men dette vil ta omtrent flere måneder. Mye avhenger imidlertid av plattformen: ikke alle plattformer støtter alle funksjoner, for eksempel har ikke iOS menyer og dialogbokser og du vil ikke kunne plassere de tilsvarende komponentene på skjemaene til slike applikasjoner.
KP: Har noe endret seg i politikken for samarbeid med partnere? Hva gjøres for å øke andelen brukere av produktene dine? Hva gjøres i Russland?
DI.: Partnerøkosystemet vårt er bredt - det er hundrevis av produsenter av verktøy og komponenter som ikke finnes i produktene våre, og vi har et teknologipartnerskapsprogram. Derfor er et bredt spekter av komponenter, teknologier og verktøy tilgjengelig for utviklere. Og løsningene de lager for sine kunder er bedre enn om de bare brukte produktene våre. Og for salg har vi kontorer i mange land, forhandlere og distributører.
K.R.: Det som er viktig for oss er ikke antall partnere, men kvaliteten på arbeidet til hver enkelt partner. Foreløpig ønsker vi å fokusere på å jobbe tett med eksisterende partnere, selv om poolen av partnere fortsatt er åpen. Vi har mange samarbeidspartnere, og vi må hjelpe dem teknisk. Vi jobber med utviklere, og de vet hva de vil ha, og de vet hva som er tilgjengelig på markedet, og partnernes evner må matche dette.
Vi har forretningspartnere som seriøst har investert i Embarcadero som forretningslinje – de har utdannet spesialister, markedsfører produktene våre, dedikerte medarbeidere som er ansvarlige for denne linjen og følger med på hva som skjer med produktene våre, prisliste, markedsføring. Naturligvis er de mer suksessrike når det gjelder salg av produktene våre enn selskaper som selger produktene våre av og til.
KP: David, Kirill, tusen takk for det interessante intervjuet. La meg, på vegne av vår publikasjon og våre lesere, ønske bedriften din videre suksess med å lage dine fantastiske verktøy som utviklere trenger så mye!
Spørsmål stilt av Natalia Elmanova
FireMonkey er kjerneteknologien til "nye Delphi". Fortell oss om målene, mulighetene og de tekniske aspektene ved dette fundamentalt nye biblioteket. Etter en stund, når du ser tilbake, hvor vanskelig og berettiget var din avvisning av å videreutvikle den superpopulære VCL?
Det ble valgt som hovedretning for utviklingen av Delphi-teknologi for å oppnå et spesifikt mål - multiplattformutvikling fra et enkelt miljø, basert på en enkelt kildekodebase, uten behov for radikal omskolering av utviklere. Innenfor rammen av den nå klassiske og superpopulære VCL var dette umulig; forbindelsen med WinAPI var for nær, kan man si, "på det genetiske nivået."
VCL-komponenter hadde ikke et "abstrakt" lag mellom funksjonsnivået når det gjelder grensesnittet og mekanismene for å vise dem. Funksjonsnivå— hvordan den oppfører seg som en kontroll, hvilke hendelser den reagerer på, hva slags brukerinteraksjon den gir. Vise— kaller plattformorienterte visualiseringsmetoder som et bestemt bilde dannet av rasterobjekter og vektorprimitiver. FireMonkey implementerte opprinnelig prinsippet om å strengt dele kontrollen i to komponenter: "atferdsmessig" og "visuelt".
Vsevolod Leonov, Embarcadero Technologies
Den første vil generelt ikke gjenta det grunnleggende i VCL, men essensen av objektorientert programmering. En komponent er en klasse; komponentklasser danner et hierarki der familier og moduler kan skilles fra hverandre. Klassen til en komponent er løst relatert til hvordan den er gjengitt.
Det visuelle "bildet" er dannet dynamisk; det er ikke stivt skrevet i komponentklassen. Bildet eller "stilen" i FireMonkey lastes inn i komponenten når applikasjonen starter. Vi har en slags funksjonell ramme for komponenten, og "huden" eller "kledningen" kan endres, men hvorfor? Det er slik at FireMonkey-applikasjoner ser autentiske ut på hvilken som helst plattform - Windows 7, Windows 8, Mac OS, iOS og i nær fremtid, Android. Dette er noe den tradisjonelle monolitiske klassestrukturen til VCL ikke kunne gi.
Her spiller den teknologiske tilnærmingen en spesiell rolle. I prinsippet kan du ta VCL-biblioteket og "stoppe det" med WinAPI og alle andre mulige plattformanrop. Dette kan fortsatt gjøres på et svært begrenset delsett av komponenter, men VCL inneholder flere hundre komponenter, så denne tilnærmingen kan ganske enkelt "drepe" VCL. Det ble besluttet å ikke røre VCL, men å utvikle nye muligheter på en ny plattform - FireMonkey. Denne teknologien Den har til og med en viss teknisk eleganse - på tidspunktet for montering av prosjektet for en spesifikk plattform kobler Delphi IDE den nødvendige kompilatoren, og grensesnittkomponentene får en plattformstil.
For brukeren er dette ett museklikk og den samme kildekoden; for Delphi er det mange års hardt arbeid av utviklere for å lage et slikt multiplattformbibliotek.
Da det ble klart at FireMonkey ville bli introdusert som en egen ny plattform, måtte den rette sameksistensstrategien velges: Embarcadero ønsket ikke å påvirke VCL-brukere negativt på noen måte. Derfor har vi valgt følgende plan: VCL forblir ideologisk og arkitektonisk stabil for å sikre høyest mulig kompatibilitet, noe som gjør det lettere å migrere prosjekter til moderne versjoner. Utviklingen av FireMonkey vil følge en naturlig og parallell vei, uten hensyn til VCL.
Det svake punktet med denne løsningen er den ganske problematiske migreringen fra VCL til FireMonkey innenfor samme prosjekt. Men for et nytt prosjekt kan en utvikler velge FireMonkey for å sikre multiplattform-naturen til den resulterende applikasjonen. Etter utgivelsen av XE4 med iOS-støtte, kan vi allerede snakke om de lyse konkurransefordelene til Delphi for en start mobil utvikling i bedriftsmiljøet, som vil økes etter implementering av planlagt Android-støtte.
Derfor er det ingen åpenbar "nektelse" fra utviklingen av VCL som sådan. I nye versjoner utvikles også VCL-delen av Delphi. Dette inkluderer 64-bits støtte, innføring av styling for visuelle komponenter, implementering av en mekanisme for fleksible dynamiske tilkoblinger eller "binding", og inkludering av FireDAC-biblioteket for arbeid med databaser i VCL-prosjekter. Det er bare det, sammenlignet med det gigantiske kvalitative spranget gjort av FireMonkey, virker fremgangen i VCL noe mangelfull. Men uansett er VCL en integrert del av Delphi og vil forbli det i mange år fremover. Selv om utviklingen av plattformer og den nåværende situasjonen innen OS for skrivebordssystemer og mobile enheter er slik at fremtiden definitivt er for FireMonkey.
I intervjuet diskuterte vi allerede iOS-støtte, la oss fortelle leserne våre om støtten for andre nyeste teknologier fra den nyeste RAD Studio XE4, for eksempel, for eksempel Windows 8 og WinRT, 64-bits systemer, MacOS og så videre. Kan du liste opp hva annet du kan tilby til den moderne programmereren som er bortskjemt med innovasjoner?
Mest sannsynlig er ikke en moderne programmerer "bortskjemt" av innovasjoner. Til store prosjekter enhver "innovasjon" resulterer ofte i en gigantisk mengde arbeid.
For eksempel ventet alle lenge, mange skyndte seg umiddelbart for å oversette kodene sine til ny plattform. Men det viser seg at selv svært profesjonelle team ikke er klare for dette. Å kompilere 64-bits kode betyr ikke at det fungerer. "Sins of youth" begynte å dukke opp, for eksempel ved å bruke instruksjoner som antok en adressestørrelse på 4 byte. Mangel på testkultur, kombinert med teknologisk uberedskap til å implementere denne prosessen på kort tid.
Og her - jo større prosjektet er, målt for eksempel ved antall linjer med kildekode, jo mer forsiktige og balanserte programmerere er med ulike typer innovasjoner som spenner fra utseendet til en "knapp" i grensesnittet til "syntaktisk sukker" i kompilatoren.
En av disse "problematiske" prestasjonene var utgivelsen av Windows 8. Personlig, som PC-bruker og bare en moderne IT-spesialist, er jeg fornøyd med Windows 8. Men for utviklere som ble sendt en gruppe datamaskiner som kjører Windows 8 med spesifikasjoner for utvikling under det nye operativsystemet som last, betyr dette visse vanskeligheter.
Vi prøvde å gi utviklingsstøtte for det nye grensesnittet til dette operativsystemet så komfortabelt og smertefritt som mulig. Derfor har spesielle stiler blitt introdusert for både VCL og FireMonkey, og programmereren kan enten gjenoppbygge applikasjonsgrensesnittet eller lage en ny applikasjon som ikke kan skilles fra den "native" for Windows 8. utseende. Selvfølgelig er det behov for "native" støtte for Windows 8 gjennom WinRT. Men dette påvirkes av prioritering av mål i moderne forhold. Mac OS, iOS, Android i nær fremtid tillater oss ennå ikke å snakke om full støtte for WinRT i nær fremtid.
Embarcaderos strategiske mål er selvfølgelig multiplattform. Utgivelsen av RAD Studio XE4 var nøkkelen, først og fremst på grunn av støtten for iOS. En eksisterende programmerer som bruker VCL kan begynne å utvikle for iOS i løpet av få timer. Til og med enkelt mobilapp kan umiddelbart transformeres til et kraftig prosjekt som opererer innenfor den eksisterende infrastrukturen. Tror ikke det er lett ny kompilator til FireMonkey og en ny stil for å sikre samsvar med iOS-grensesnittet.
Dette inkluderer en ny visuell designer, innebygd støtte for ulike formfaktorer, datatilgangsbiblioteker, inkludert den nye FireDAC, og LiveBindings-teknologi for fleksibel og dynamisk kobling med bedriftsdata. Alle disse innovasjonene kommer samtidig – for Windows, Mac OS og iOS. operativsystem Mac OS utvikler seg ikke så raskt, så det er ingen problemer som overgangen fra Windows 7 til Windows 8. Men de dukket opp Retina-skjermer, og dette krevde spesiell oppmerksomhet. Nå inkluderer alle MacOS-applikasjoner opprettet i Delphi XE4 automatisk to stiler - "normal" og "high definition".
At. den samme applikasjonen kan ha samme høykvalitets "native" grensesnitt på alle stasjonær datamaskin fra Apple.
Embarcadero ønsker ikke å "overraske", "overraske" eller til og med "underholde" utviklere med sine nye innovative utgivelser. Snarere tvert imot er IT-sfæren allerede full av forskjellige overraskelser: nye enheter, nye plattformer, nye brukere, deres nye behov, nye interaksjonsscenarier. Legg til ny programvareutviklingsteknologi til dette, og programmerere vil rett og slett ikke ha tid til å lage nye systemer og eksisterende - alt de vil gjøre er å migrere fra et miljø til et annet, fra et gammelt bibliotek til et nytt, fra ett språk til et annet.
Men vi bekjenner ikke at vi avviser alt nytt. Vi ønsker bare å sikre kontinuitet i alt - kode, grensesnitt, prosjekt, til og med profesjonelle ferdigheter når nye plattformer og enheter dukker opp. Du kan si at vi kjemper mot usunn konservatisme angående nye plattformer gjennom sunn konservatisme i utviklingsverktøy. Ikke forvent eksotiske produkter, ikke-standard programmeringsspråk eller merkelige utviklingsverktøy fra Embarcadero.
Hos oss vil du alltid finne visuell utvikling, klassiske språk, "native" kode, og la målplattformene for applikasjonene dine, skapt på samme velprøvde klassiske måte, være nye.
