03/06/2013 12:46 pm
Ես մեծապես տուժեցի FireMonkey-ում բրաուզերի բաղադրիչի բացակայության պատճառով: Հայտնի Delphi Chromium Embedded նախագիծը դեռևս ներառում էր FMX աջակցություն վերջին նախագծում: Բայց չնայած այն հանգամանքին, որ բավականին շատ ժամանակ է անցել, հեղինակը չի շտապում ավելացնել աջակցություն FMX2-ին։ Ի վերջո, ես ստիպված էի իրավիճակը վերցնել իմ ձեռքը։
Պաշտոնական հավաքից TChromiumFMX բաղադրիչը բավականին լավ է աշխատում FireMonkey-ում (XE2-ում), բայց նույնիսկ FMX2-ում չի հավաքվում: Ես ստիպված էի մի փոքր պարզել, թե ինչպես է այն աշխատում և ուղղել այն: Բարեբախտաբար, մեծ փոփոխություններ չեն պահանջվել։
FMX2-ում փոխվել են երկու բան, որոնց կարիքն ունի բաղադրիչը:
Նախ, TBitmap-ն այլևս չունի ScanLine և StartLine հատկություններ: TBitmap-ի բովանդակության անմիջական մուտքը վերափոխվել է (հետաքրքիր է, ինչու՞) և այժմ հասանելի է TBitmapData դասի միջոցով, որը վերադարձնում է TBitmap.Map մեթոդը:
Դե, երկրորդ, ավելի հայտնի՝ Platform .*-ն այլևս չկա, այժմ դուք պետք է ստանաք անհրաժեշտ ինտերֆեյսը TPlatformServices.GetPlatformService-ի միջոցով: Այստեղ ամեն ինչ բավականին պարզ է և խնդիրներ չկան:
Ես այն առանձնապես ստեղծագործորեն չեմ փորձարկել, բայց իմ նպատակների համար բաղադրիչը բավականին հարմար է. դրա միջոցով կարող եք դիտել կայքերը: Ներբեռնեք այն: Հավանաբար, ես նույնպես կուղարկեմ իմ խմբագրումները հեղինակին, ով կարող է անհրաժեշտ համարել դրանք ավելացնել պաշտոնական տարբերակին:
07/30/2012 2:43 am
Ջեյսոն Սաութուելն առաջարկում է մշակել FireMonkey-ի փաթաթաների մի շարք բնիկ Windows/OSX կառավարիչների համար և գումար է հավաքում դրա համար: Սկզբից նա նախատեսում է հավաքել 20 հազար դոլար։
Գաղափարը պարզ է. Գոյություն ունեցող FireMonkey բաղադրիչները մատուցվում են Delphi-ի միջոցով գրեթե զրոյից, ինչը, մի կողմից, մեծապես ապահովում է դրանց միջպլատֆորմային ֆունկցիոնալությունը, բայց մյուս կողմից, արդյունքում մենք ստանում ենք բաղադրիչներ, որոնք այնքան էլ բնական չեն թվում ներկայումս աջակցվող երկու օպերացիոն համակարգերում: . Եվ դա այնքան էլ վատ չէ, բացի արտաքինից, դուք պետք է ինքնուրույն զարգացնեք այս բաղադրիչների տրամաբանությունը: Օրինակ, RichEdit-ը բավականին բարդ է, FireMonkey-ի ներսում դրա տրամաբանությունը կրկնելը աննշան խնդիր չէ: Ե՛վ VCL-ը, և՛ CLX-ը նորից չեն հայտնագործել անիվը, այլ օգտագործել են պատրաստ:
Հիմա գալիս է վատ լուրը. Ամեն ինչ աշխատում է գործարկման ժամանակ, բայց ես չեմ գտել իմ նոր ներդիրի տեսակը Items Designer-ին ավելացնելու որևէ միջոց: Եվ թվում է, որ ցուցակի բոլոր վերահսկիչները նույն խնդիրն ունեն՝ TListBox, TGrid և այլն: Սկզբում ինձ շատ դուր եկավ դրանց իրականացման մոտեցումը, բայց հիմա նույնիսկ ինչ-որ կերպ կասկածում եմ դրան։ Համացանցային որոնումը ցույց տվեց, որ ես մենակ չեմ այս խնդրի հետ։
Օգնությունը լուռ է, կոդում էլ ոչինչ չգտա։ Իսկապե՞ս ճանապարհ չկա։ Սա չափազանց տհաճ կլիներ։
Ավելի քան երեք տարի է անցել այն բանից հետո, երբ CodeGear բաժինը, որը պատասխանատու է այնպիսի աշխարհահռչակ գործիքների ստեղծման համար, ինչպիսիք են Delphi, C++Builder և JBuilder, ինչպես նաև տվյալների բազայի կառավարման Interbase համակարգը, դարձավ Embarcadero Technologies-ի մի մասը, որը հայտնի է իր գործիքներով: տվյալների բազայի նախագծման և կառավարման համար, և երկու տարի անց մենք մեր ամսագրի էջերում քննարկեցինք, թե ինչ կարելի է ակնկալել ռուս ծրագրավորողների շրջանում այդքան տարածված գործիքների մշակման մեջ: Մենք խնդրեցինք Դեյվիդ Ինտերսիմոնին՝ ծրագրավորողների հետ հարաբերությունների փոխնախագահ և Embarcadero Technologies-ի գլխավոր ավետարանիչին, և Embarcadero Technologies-ի ներկայացուցչության ղեկավար Կիրիլ Ռաննևին, խոսել այն մասին, թե ինչ նորություն է արվել այս ոլորտում վերջին երկու տարիների ընթացքում և ինչ սպասել: մոտ ապագայում.Ռուսաստան. Մեր ամենաերիտասարդ ընթերցողների համար կտեղեկացնենք, որ սա առաջին հարցազրույցը չէ, որ Դավիթն ու Կիրիլը տալիս են ComputerPress-ին. մեր համագործակցությունը շարունակվում է արդեն երկրորդ տասնամյակը։ Եվ մոտավորապես նույնքան տարի մենք պարբերաբար հրապարակում ենք տվյալների բազայի կառավարման գործիքների ակնարկներ, որոնցում մեծ ուշադրություն է դարձվում Embarcadero-ի արտադրանքին։
ComputerPress:Դեյվիդ, քո դիվիզիան երեք տարի է, ինչ մաս է կազմում Embarcadero-ին: Երկու տարի առաջ դուք ոգևորված էիք, որ դա դառնաք ձեր նպատակներին և ոգուն մոտ ընկերության մաս: Ինչ-որ բան փոխվե՞լ է այս ընթացքում։ Դու և քո գործընկերները դեռ նույն ոգևորությունն ունես։
Այո, ես դեռ շատ ոգեւորված եմ: Հիմնական փոփոխությունը, որը տեղի է ունեցել այն պահից, երբ մենք դարձել ենք Embarcadero ընկերության մաս, այն է, որ մեծ ներդրումներ են կատարվել Delphi-ի զարգացման համար: Ավելացել է զարգացման գործիքների վրա աշխատող մարդկանց թիվը, ավելացել է այն տեխնոլոգիաների թիվը, որոնք մենք կարող ենք զարգացնել կամ, անհրաժեշտության դեպքում, ձեռք բերել։
RAD Studio XE 2-ի թողարկումը, որը մենք նախատեսում ենք ցուցադրել Մոսկվայում, այս արտադրանքի ամենամեծ թողարկումն է՝ հսկայական հնարավորություններով և մեծ թվով աջակցվող հարթակներով՝ սկսած Delphi-ի առաջին տարբերակից, որը ստեղծվել է Windows-ի և 16-բիթանոց տարբերակի համար: որը նորարարական արտադրանք էր, որը միավորում էր բաղադրիչի մոտեցումը և կոմպիլյացիան մեքենայի կոդի մեջ: Այժմ մենք աջակցում ենք մշակմանը ոչ միայն Windows-ի, այլ նաև Macintosh-ի համար, էլ չեմ խոսում վեբ մշակման և հավելվածների ստեղծման մասին շարժական սարքեր, և տարբեր հարթակների համար նախատեսված այս հավելվածները կարող են ունենալ մեկ կոդ։
Զարգացման նոր հարթակը` FireMonkey-ը, համագործակցություն է Embarcadero-ի և վերջերս ձեռք բերված UlanUde-ի վրա հիմնված ռուսական KSDev ընկերության միջև, որն արտադրում է վեկտորային գրաֆիկական բաղադրիչներ, DirectX և OpenGL, գրաֆիկական էֆեկտներ և Delphi բաղադրիչներ, որոնք օգտագործում են: GPU PixelShader 2.0-ի հետ: Մենք մեկ տարի առաջ ձեռք բերեցինք KSDev ընկերությունը (տես ksdev.ru) և սկսեցինք համագործակցություններստեղծել բազմպլատֆորմ մշակման գործիք, որը ներառում է FireMonkey հավելվածների մշակման հարթակ՝ Delphi և C++Buider բաղադրիչներով՝ հավելվածների ինտերֆեյսի ստեղծման, տվյալների բազայի ինտեգրման, GPU գրաֆիկայի մշակման և օպերացիոն համակարգի ինտեգրման համար:
FireMonkey-ի միջոցով դուք կարող եք ստեղծել ծրագիր, որն աշխատում է CPU-ի և GPU-ի վրա միասին, այնուհետև օգտագործել տարբեր կոմպիլյատորներ և Run-time Libraries (RTL)՝ այն Windows-ի, Mac OS-ի կամ iOS-ի համար: Տարբեր գրաֆիկական գրադարանների միջոցով ծրագրավորել սովորելու, տարբեր հարթակների API-ները, որոնք ունեն տարբեր կոորդինատային համակարգեր և տարբեր հնարավորություններ սովորելու փոխարեն, Delphi-ն և C++Builder-ը օգտագործող ծրագրավորողները կարող են օգտագործել նույն բաղադրիչի վրա հիմնված մոտեցումը՝ տեսողականորեն խմբագրելով ձևերը և միանալով տվյալների բազաներին՝ բաղադրիչի տեղափոխում մկնիկի օգնությամբ: Սա տարբեր հարթակներում աշխատող հավելվածներ ստեղծելու սկզբունքորեն նոր եղանակ է, և դա ապագան է: Եթե ցանկանում եք ձեր հավելվածին ավելացնել այլ օպերացիոն համակարգերի և պլատֆորմների աջակցություն, ապա ձեզ հարկավոր չէ այն նորից նախագծել և զարգացնել, այլ պարզապես անհրաժեշտ է այն նորից կազմել:
Մենք ստեղծում ենք նոր կոմպիլյատորներ, որոնք ստեղծում են հայրենի կոդ: Այսօր կան Delphi կոմպիլյատորներ 32 և 64 բիթանոցների համար Windows-ի տարբերակները, 32-բիթ Mac տարբերակները OS 10: Եվ մենք աշխատում ենք Delphi-ի և C++Builder-ի հաջորդ սերնդի կոմպիլյատորների վրա, որոնք թույլ կտան ձեզ ստեղծել բարձր արդյունավետությամբ բնիկ կոդ ինչպես այս, այնպես էլ այլ հարթակների համար, ինչպիսիք են Android-ը կամ Linux-ը, և պահպանել նույն դիզայնը, նույնը: բաղադրիչները, նույն կոդը՝ օգտագործելով տարբեր կոմպիլյատորներ և աշխատաժամանակի գրադարաններ:
Ինչպես տեսնում եք, ես բավականաչափ պատճառներ ունեմ խանդավառության համար։ Իսկ մշակողները, որոնց ես հանդիպում եմ ամբողջ աշխարհում, գիտեն, որ Embarcadero-ն մեծ ներդրումներ է կատարում Delphi-ում և C++Builder-ում, ինչպես նաև PHP-ի մշակման գործիքներում:
KP:Ի՞նչ հաջողությունների եք հասել վերջին երկու տարիների ընթացքում երկու ընկերությունների գործիքների ինտեգրման հարցում: Որո՞նք են Embarcadero-ի ապագայի ծրագրերն այս ոլորտում:
ԴԻ.:Այն ժամանակ, երբ CodeGear-ը դարձավ Embarcadero-ի մաս, ընկերությունն ուներ զարգացման թիմեր Տորոնտոյում, Մոնտերեյում և Ռումինիայում, մենք գտնվում էինք և դեռ գտնվում ենք Սքոթս հովտում և Ռուսաստանում՝ Սանկտ Պետերբուրգում: Embarcadero-ն ուներ գործիքներ մշակողների և տվյալների բազայի ադմինիստրատորների համար, CodeGear-ը՝ հավելվածների մշակման գործիքներ, սակայն վերջիններս օգտագործում են նաև տվյալների բազաներ։ Ընկերությունների միաձուլումը փորձաքննության, տվյալների բազաների ոլորտում գիտելիքների, կոդերի օպտիմալացման, այդ թվում՝ սերվերի կոդի համակցություն է։ Ընկերությունների համատեղումը հանգեցրեց նաև նոր արտադրանքի՝ AppWave-ի ստեղծմանը, որը սովորական Windows հավելվածը շատ հեշտ օգտագործման (օրինակ՝ iPhone-ի կամ այլ սարքերի համար հավելվածներ) վերածելու հատուկ տեխնոլոգիա է: AppWave-ը թույլ է տալիս չտեղադրել հավելված, այլ պարզապես ընտրել այն և գործարկել պատրաստված հավելվածի պահպանման սերվերից (հավելվածից), և այն կկատարվի օգտատիրոջ համակարգչում՝ առանց նրա ռեեստրի և համակարգի ֆայլային համակարգի տարածքում փոփոխություններ կատարելու: Ի դեպ, AppWave հավելվածի բրաուզերը գրված է Դելֆիում։ Embarcadero-ն օգտագործում է Dephi-ն իր սեփական զարգացման և հավելվածների մշակման մեր փորձաքննության համար:
iPhone (iOS) հավելվածը ստեղծված է
օգտագործելով FireMonkey հարթակը
Դուք կարող եք նաև օգտագործել մեր մշակման գործիքների և DB Optimizer-ի ինտեգրումը SQL հարցումները հավելվածներ ստեղծելիս օպտիմալացնելու համար: Անցնելով SQL կոդը անմիջապես DB Optimizer-ին, դուք կարող եք պրոֆիլավորել այն, փորձարկել այն և վերադարձնել օպտիմիզացված տարբերակը ձեր զարգացման միջավայր: Embarcadero-ի տվյալների բազայի փորձը նաև բարելավել է DataSnap տեխնոլոգիան: Տորոնտոյի ծրագրավորողների շնորհիվ մենք շատ գիտելիքներ ձեռք բերեցինք բազմաշերտ համակարգերի և տվյալների բազաների ճարտարապետության մասին: Այժմ մենք երկու ընկերություններում սերվերի կոդի և պահվող ընթացակարգերի ստեղծման համատեղ փորձ ունենք: Մենք ունենք գործիքներ, ինչպիսիք են RapidSQL-ը և DB Change Manager-ը, ինչպես նաև մշակման միջավայրեր, որոնք պարզեցնում են սերվերի կոդի ստեղծումը. օրինակ՝ Code Insight և Code Completion տեխնոլոգիաները հնարավորություն են տալիս ստեղծել SQL insight և SQL Completion տեխնոլոգիաներ: Հաճախորդի և սերվերի կոդ ստեղծելու մեր ընդհանուր մոտեցումները, մեր ընդհանուր փիլիսոփայությունը թույլ են տալիս ընդհանուր հատկանիշներ տալ տվյալների բազայի կառավարման գործիքներին և հավելվածների մշակման գործիքներին:
Կիրիլ Ռաննև.Ես ուզում եմ մի կարևոր բան ավելացնել. Առևտրային տեսանկյունից շատ կարևոր է, թե ինչպես ենք մենք մատուցում մեր գործիքները: Օրինակ, նոր RAD Studio XE 2 Ultimate թողարկումը ներառում է ամբողջական DB Power Studio գործիքների հավաքածու: Սա գործիքների շատ հզոր հավաքածու է, ներառյալ RapidSQL հարցումների մշակման միջավայրը, DB Change Manager փոփոխության կառավարման գործիքը և DB Optimizer հարցումների օպտիմալացման գործիքը, որը թույլ է տալիս իրականացնել զարգացման և տեղակայման գործընթացի կարևոր մասը՝ կառավարելով փոփոխությունները: տվյալների մոդելը, տվյալների բազան, կոդը և այլն: Սա տեխնոլոգիաների շատ լավ և ճիշտ համադրություն է։
ԴԻ.:Բայց անհրաժեշտության դեպքում ծրագրավորողները կարող են օգտագործել Subversion-ը սկզբնական կոդի տարբերակման համար և DB Change Manager-ը՝ մետատվյալների տարբերակման համար: Դուք կարող եք օգտագործել կոդերի պրոֆիլավորումը և DB Optimizer-ը՝ սերվերի կոդը օպտիմալացնելու համար, RapidSQL՝ սերվերի կոդը ստեղծելու և վրիպազերծելու համար, և մեր զարգացման միջավայրերը՝ հավելվածներ ստեղծելու և վրիպազերծելու համար: Տեխնոլոգիաների այս համադրությունը RAD Studio XE-ում Ultimate Editionցույց է տալիս տվյալների բազայի և հավելվածների մշակման մոդելների զուգահեռները: Delphi-ով և C++Builder-ով բիզնես հավելվածներ կառուցող ծրագրավորողներից շատերը աշխատում են տվյալների բազաների հետ և կարիք ունեն այս գործիքների, իսկ RAD Studio XE Ultimate Edition-ը հիանալի համադրություն է նման մշակողների համար:
KP: Ժամանակակից օգտվող- սա այլևս միայնակ Windows պլատֆորմի օգտագործող չէ: Մենք օգտագործում ենք շարժական սարքեր, iPhone, iPad, Android հարթակի վրա հիմնված սարքեր: Սա նշանակում է, որ մշակողները պետք է սկսեն թիրախավորել տարբեր հարթակներ՝ առանց էապես ավելացնելու ներդրումները վերապատրաստման մեջ, այսինքն՝ անհրաժեշտ են ունիվերսալ գործիքներ: Ակնհայտ է, որ պլատֆորմի արտադրողներից ունիվերսալ գործիքներ ակնկալելը իրատեսական չէ, և այս հարցում մենք կարող ենք հույս դնել միայն գործիքների անկախ արտադրողների վրա: Ինչպե՞ս կարող ենք հույս դնել Embarcadero-ի վրա:
ԴԻ.:Մենք դեռ շատ անելիքներ ունենք հարթակի աջակցության առումով: Այսօր մենք ներկայացնում ենք iPhone-ի և iPad-ի iOS պլատֆորմի աջակցությունը, այնուհետև մեր աջակցությունը կստանան Android պլատֆորմի, Windows 7-ի և Blackberry-ի վրա հիմնված սմարթֆոնները: RAD Studio XE 2-ում մենք սկսել ենք ստեղծել FireMonkey հարթակ iOS-ի համար, այնուհետև FireMonkey-ին կբերենք այլ հարթակներ:
Միևնույն ժամանակ, կան մեծ թվով օպերացիոն համակարգեր, որոնք աջակցում են սենսորային էկրաններ(սենսորային էկրան), հեռախոսների համար, պլանշետային համակարգիչներև աշխատասեղանի սարքեր, և մենք կշարունակենք ավելացնել նրանց աջակցությունը: Բացի այդ, կան ձայն, շարժում, կենսաչափական համակարգեր, արագաչափեր, ուստի մենք պետք է շարունակենք ընդլայնել FireMonkey-ը, որպեսզի բոլոր մշակողները կարողանան օգտվել նոր հարթակներից: Օրինակ՝ Microsoft Kinect սարքը նախատեսված էր Xbox 360-ի համար, իսկ այժմ Windows-ի համար կա համապատասխան SDK (Software Development Kit): Եվ մենք արդեն ունենք օրինակներ, որտեղ մենք օգտագործում ենք շարժումը հավելվածը կառավարելու համար նույն կերպ, ինչպես սովորաբար օգտագործվում է մկնիկը կամ ստեղնաշարը:
Երբ դուք ստեղծում եք բազմաթիվ բարդ գրաֆիկայով հավելվածներ, դուք ստեղծում եք օգտատիրոջ նոր միջերեսների մի ամբողջ աշխարհ: Եթե մենք գործ ունենք Windows օպերացիոն համակարգի հետ, ապա մենք կցում ենք նրա Windows API-ն VCL գրադարանում (Visual Component Library - տեսողական բաղադրիչների գրադարան, որը հանդիսանում է Delphi և C++Builder մշակման գործիքների մաս: - Նշում խմբ.), որը, ի դեպ, կարող է օգտագործվել հետագա։ Իսկ FireMonkey-ում մենք ամփոփում ենք օպերացիոն համակարգի API-ն: Բայց այսօր մենք շատ ավելի լայնորեն շահարկում ենք ձևերն ու գրաֆիկան: Դուք կարող եք նաև ֆիզիկական հատկություններ ավելացնել տարածությանը անիմացիայի և հատուկ էֆեկտների համար: Բացի այդ, կան հսկայական թվով այլ լրացուցիչ հնարավորություններստեղծել օգտատերերի միջերեսներ, որոնք մենք պատրաստվում ենք իրականացնել առաջիկա մի քանի տարիների ընթացքում տարբեր հարթակների, բջջային և պլանշետային սարքերի համար:
Microsoft-ը վերջերս մանրամասներ է հրապարակել Windows 8-ի մասին, որը պետք է թողարկվի մեկ տարուց: Մենք կաջակցենք այս նորարարություններին VCL գրադարանում և FireMonkey հարթակում: Սակայն Delphi-ն մշակման գործիք է, որը նախատեսված է ոչ միայն Windows-ի, այլ նաև Macintosh-ի, iPhone-ի և iPad-ի համար: Մենք նաև զարգացնում ենք մեր PHP արտադրանքները, աջակցում ենք jQuery Mobile-ին, օգտագործում ենք iOS API՝ բջջային հաճախորդների հավելվածներ մշակելու համար և ստեղծում ենք սերվերի կողմից PHP հավելվածներ՝ օգտագործելով մոգեր և գործիքներ՝ հաճախորդի կողմից JavaScript, HTML և կասկադային ոճերի թերթիկներ ստեղծելու համար: Մենք կարող ենք ստեղծել փաթեթներ PHP հավելվածներև հաճախորդի հավելվածներ՝ հայրենի կոդով iPhone iOS, և այդպիսի հաճախորդը կշփվի PHP սերվերի հետ։ Իսկ նա, իր հերթին, կշփվի տվյալների բազայի սերվերի և վեբ ծառայությունների հետ՝ այն ամենի հետ, ինչ անհրաժեշտ է բիզնեսի համար։
RadPHP XE2 զարգացման միջավայր: Բջջային վեբ հավելվածի ստեղծում
օգտագործելով jQuery Mobile բաղադրիչներ iPhone 3G-ի համար
Այլ կերպ ասած, մենք նախատեսում ենք ընդլայնել FireMonkey-ի և VCL-ի հնարավորությունները, ներառյալ բջջային հարթակների աջակցությունը։
KP:Կարո՞ղ եք մեզ ավելին պատմել FireMonkey հարթակի մասին:
ԴԻ.:Ինչպես արդեն նշեցի, Windows-ի համար ստեղծված VCL գրադարանը կշարունակի զարգանալ և կատարելագործվել: Բայց այսօր, եթե ցանկանում եք իրական բիզնես հավելվածների զարգացում, դուք պետք է դրանք ստեղծեք տարբեր հարթակների համար: Ահա թե ինչի համար է նախատեսված FireMonkey հարթակը: Այն աջակցում է բարձր լուծաչափի ինտերֆեյսի ստեղծմանը, բարձր արդյունավետությամբ 3D գրաֆիկայի, բարձր կադրերի արագության և, որ կարևոր է, դրա համար օգտագործում է գրաֆիկական պրոցեսոր:
Դուք կարող եք օգտագործել նման հնարավորությունները գիտական, ինժեներական և բիզնես հավելվածներ ստեղծելիս: Նման հավելվածները կարող են միանալ տվյալների բազաներին՝ օգտագործելով dbExpress տեխնոլոգիան, դեռևս օգտագործելով մշակողներին ծանոթ ոչ վիզուալ բաղադրիչներ, ինչպիսիք են ClientDataSet կամ DataSource, օգտագործել DataSnap տեխնոլոգիա, միանալ ցանկացած տվյալների բազայի, SOAP և REST սերվերներին: Դուք կարող եք ստեղծել գրավիչ կառավարիչներ, տուփերով կոճակներ, արտասովոր աղյուսակներ և այլ ինտերֆեյսի տարրեր՝ ինչպես երկու, այնպես էլ եռաչափ: Դուք կարող եք բեռնել պատրաստի 3D մոդելը հավելվածում և միացնել այն 2D ձևի, որով կարող եք պտտել այն և դիտել այն տարբեր անկյուններից: Դուք կարող եք ստեղծել տվյալների խորանարդ կամ 3D բիզնես աղյուսակ և պտտել այն՝ օգտագործելով ձեր մկնիկը, ստեղնաշարը կամ նույնիսկ Kinect սարքը, կամ կարող եք մտնել խորանարդի ներս և նայել դրա տարբեր մակերեսները ներսից: Եվ այս ամենը կարելի է անել՝ օգտագործելով գերարագ GPU: Նույն հավելվածը կարող է այնուհետև կազմվել մեկ այլ հարթակի համար, ինչպիսին է Mac OS-ը:
Պտտվող տվյալների խորանարդ պարունակող հավելված,
տեղադրված է իր եզրերին
Կամ դուք կարող եք զրոյից ստեղծել 3D ձև և օգտագործել տեսախցիկներ և լույսեր՝ օգտատիրոջ միջերեսի մասերը լուսավորելու և պտտելու համար: Ձևամշակողն արդեն ունի ներկառուցված միջավայր՝ դիզայնի ընթացքում 3D օգտատիրոջ միջերեսին աջակցելու համար:
Windows-ում դուք կարող եք օգտագործել Direct2D գրադարանները՝ բարձր լուծաչափով 2D գրաֆիկայի հետ աշխատելու համար, իսկ Direct3D՝ 3D գրաֆիկայի համար: Mac OS-ում Quartz և OpenGL գրադարաններն օգտագործվում են նույն նպատակների համար: iOS-ի համար օգտագործվում են Quartz և OpenGL ES գրադարանները: Բայց այս ամենը թաքնված է մշակողից. նա օգտագործում է FireMonkey հարթակը, դրա կոորդինատային համակարգը և հավելվածների ծրագրավորման ինտերֆեյսը, առանց մտածելու այս գրադարանների մասին և կարող է նույն հավելվածը կազմել տարբեր հարթակների համար:
Եկեք հիշենք, թե ինչ է VCL-ը: VCL-ը Windows API-ի շուրջ բաղադրիչն է: Մենք գործ ունենք ռեսուրսների, մենյուների, երկխոսության տուփերի, գույների, ոճերի, Windows հաղորդագրություններ. Լինելով բազմահարթակ փաթաթան, ի տարբերություն VCL-ի, FireMonkey-ը պահպանում է իրադարձության և բաղադրիչի նույն մոդելները՝ թույլ տալով մտածել իրադարձությունների առումով (օրինակ՝ OnClick, OnHasFocus, onMouseDown և onKeyDown իրադարձությունները), բայց մշակում է Macintosh-ի կամ iPhone-ի իրադարձությունները:
FireMonkey հարթակը նույնպես գալիս է ամբողջական համակարգօգտագործողի միջերեսի տարրերի անիմացիա: Սա, իհարկե, Pixar-ի ոճի անիմացիոն համապարփակ համակարգ չէ, բայց այն թույլ է տալիս էֆեկտներ, ինչպիսիք են bitmap անիմացիան, UI տարրերի ֆոկուսի ընդգծումը և վեկտորային գրաֆիկան: Ավելի քան 50 հասանելի են մշակողին տեսողական էֆեկտներպղտորում, պատկերի վերածում սև ու սպիտակի, տարրալուծում, անցումներ, արտացոլում, ստվերների ստեղծում՝ ժամանակակից գրաֆիկական պրոցեսորներում առկա բոլոր տեսակի էֆեկտները, որոնք այժմ հանդիպում են գրեթե ցանկացած համակարգչում: FireMonkey հարթակի միջոցով կառուցված հավելվածը հրամաններ է ուղարկում GPU-ին, որն էլ կատարում է գրաֆիկայի ցուցադրման և օգտատիրոջ միջերեսի ստեղծման բոլոր աշխատանքները: Այս դեպքում կենտրոնական պրոցեսորն անվճար է հաշվարկների և օպերացիոն համակարգին զանգերի համար: Մշակողը կարող է միայն բաղադրիչները ճիշտ տեղադրել:
FireMonkey պլատֆորմի ամենահիմնական բանը օգտատիրոջ միջերեսը կառուցելու ձևն է: Գոյություն ունեն ռաստերային գրաֆիկա տեղադրելու միջոցներ ինտերֆեյսի տարրերի վրա, ինչպիսիք են ընտրացանկերը, կոճակները և ոլորման գծերը: FireMonkey-ում մենք օգտագործում ենք GPU-ով աշխատող վեկտորային գրաֆիկա այդ նպատակով: Ծրագրավորման տեսանկյունից դրանք դեռևս նույն հսկիչ սարքերն են, բայց դրանք ցուցադրելու ամբողջ աշխատանքն իրականացվում է գրաֆիկական պրոցեսորի կողմից: Մենք կարող ենք ոճեր կիրառել կառավարիչների վրա, հավելվածը դարձնել հավելվածի տեսք Mac OS-ի կամ Windows-ի համար, ստեղծել մեր սեփական ոճը, կիրառել մեր ոճերը ինտերֆեյսի տարրերի վրա (օրինակ՝ կոճակը ուղղանկյուն կամ կլոր դարձնել՝ փոխելով դրա ոճը ձևի խմբագրիչում ) - դրա համար զարգացման միջավայրում կա ոճի խմբագիր: Դուք կարող եք ստեղծել ձեր սեփական ոճը, կամ կարող եք փոխել արդեն ավարտված հավելվածի ոճը:
FireMonkey հարթակ - Զարգացման գործիքներ
և աջակցվող հարթակներ
Եթե հիշում եք, VCL գրադարանն ուներ սահմանափակ թվով հսկիչներ՝ կոնտեյներներ (այսինքն՝ թույլ էին տալիս տեղադրել այլ տարրեր դրանց մեջ), իսկ FireMonkey-ում յուրաքանչյուր հսկողություն կոնտեյներ է։ Սա նշանակում է, որ յուրաքանչյուր հսկողություն կարող է պարունակել ցանկացած այլ վերահսկողություն: Օրինակ, բացվող ցանկի տարրերը կարող են պարունակել պատկերներ, կոճակներ, խմբագրման դաշտեր և այլ հսկիչ սարքեր: Դուք կարող եք նաև բաղադրիչները տեղադրել շերտերով:
FireMonkey-ի մատուցման համակարգը բավականին ճկուն է. այն կարող է օգտագործել Direct2D, Direct3D և OpenGL գրադարանները՝ հրամաններ ուղարկելով GPU-ին: VCL-ում նույն բանին հասնելու համար դուք պետք է գեներացնեիք առանձին էկրանից դուրս բուֆեր, դրա մեջ պատկեր ստեղծեիք՝ կանչելով համապատասխան գրաֆիկական գրադարանի գործառույթները, այնուհետև այն ցուցադրեք ձևի վրա:
FireMonkey-ի կողմից աջակցվող գրաֆիկական էֆեկտների օրինակներ
Եթե չունեք GPU, դուք դեռ կարող եք կիրառել 2D կամ 3D ձևեր և օգտագործել FireMonkey-ի կառավարումը: Այս դեպքում FireMonkey հարթակը կօգտագործի GDI+ գրադարանները կամ այլ նմանատիպ գրադարաններ և կկատարի նույն էֆեկտները և անիմացիաները կամ 3D օբյեկտների մանիպուլյացիաները:
FireMonkey-ի մեկ այլ առանձնահատկություն է ինտերֆեյսի տարրերը տվյալների հետ կապելու նոր համակարգ՝ բաց և ճկուն: VCL-ում կան երկու տեսակի ինտերֆեյսի տարրեր՝ տվյալների հետ կապված և ոչ տվյալների հետ կապված (օրինակ՝ TDBEdit և TEdit): FireMonkey-ում յուրաքանչյուր հսկողություն կարող է կապված լինել ցանկացած տեսակի տվյալների հետ: Սա կարող է լինել պարզ արտահայտություն, դաշտ տվյալների հավաքածուից, տվյալներ մշակողի կողմից ստեղծված օբյեկտներից կամ մեթոդի կանչերի արդյունքներ:
Բացի այդ, հավելված ստեղծելիս կարող եք դրա մեջ բեռնել պատրաստի 3D մոդել և օգտագործել այն. նման հնարավորությունները հաճախ պահանջվում են ինչպես բիզնեսում, այնպես էլ ինժեներական ծրագրերում: Մենք ունենք հաճախորդ, ով ստեղծում է հավելվածներ լոգիստիկայի համար: Նրանք ունեին տեղեկատվական համակարգ, որը կառուցվել էր Delphi-ի միջոցով, և դրանում ծրագիր, որը գծում էր պլան և ցուցադրում տեղեկատվություն տվյալների աղբյուրներից: Նրանք վերջերս ինչ-որ հետաքրքիր բան արեցին՝ նրանք AutoCAD-ում գծեցին լիովին ավտոմատացված 3D պահեստ, և նրանց հավելվածը թույլ է տալիս տեսնել, թե ինչպես է ավտոմատացված բեռնատարը շարժվում պահեստում և ապրանքները դնում դարակների վրա: Իսկ աղբյուրներից տվյալներ են դնում համապատասխան պատկերի վրա։
Դիմումների ոճերի փոփոխման օրինակներ
KP: 3D մոդելի ո՞ր ձևաչափերն են ներկայումս աջակցվում:
ԴԻ.:Այս թողարկումում մենք աջակցում ենք մոդելների բեռնում AutoCAD-ից, Collada-ից (բաց կոդով 3D մոդելավորման գործիք: - Նշում խմբագրել.), Մայա, OBJ ձևաչափ, որն աջակցվում է 3D գրաֆիկայի բազմաթիվ վաճառողների կողմից:
KP:Ի՞նչ այլ ձևաչափեր եք նախատեսում ավելացնել:
ԴԻ.:Մենք նախատեսում ենք ավելացնել 3DS (3D Studio MAX), SVG (սովորաբար այս ձևաչափն օգտագործվում է 2D վեկտորային գրաֆիկայի համար, բայց երբեմն 3D), Google SketchUp: Միգուցե մենք կաջակցենք այլ ձևաչափերի:
KP:Արդյո՞ք FireMonkey-ով կառուցված հավելվածներում 3D մոդելներ օգտագործելը պահանջում է համապատասխան 3D մոդելավորման գործիքի լիցենզիա:
ԴԻ.:Ոչ, դա չի պահանջում: Մենք միայն կարդում ենք մոդելի ֆայլը: Մենք ներմուծում ենք մոդելը, բայց ոչ արտահանում (չնայած, իհարկե, դուք կարող եք գրել հավելված, որը կպահի մոդելը ձեր սեփական ձևաչափով): Մենք չենք հավակնում լինել 3D մոդելավորման գործիքներ արտադրող. դրա համար դուք կարող եք օգտագործել AutoCAD, 3D Studio Max, Maya կամ ցանկացած այլ 3D մոդելավորման գործիք և ներմուծել ստեղծված մոդելները մեր հավելվածներում:
KP:Որքա՞ն արդյունավետ են FireMonkey-ով կառուցված հավելվածները ժամանակակից ապարատային հարթակներում:
ԴԻ.:Արտադրողականությունը բավականին բարձր է։ Օրինակ, MacBook Pro-ի վրա երեք գնդերով և երեք լույսերով 3D ձևը կարող է ներկայացվել վայրկյանում 100 կադր արագությամբ: Կամ այն կարող է հասնել 600-ի, դա կախված է նրանից, թե կոնկրետ ինչ ենք անում: Կրկին, ամեն ինչ կախված է GPU-ի հզորությունից:
KP:Արդյո՞ք սա նշանակում է, որ դուք կարող եք ժամանակակից խաղեր ստեղծել FireMonkey-ի միջոցով:
ԴԻ.:Մենք մեր զարգացման գործիքները չենք դնում որպես խաղերի գործիքներ: Այնուամենայնիվ, օգտվելով ժամանակակից GPU-ների բարձր կատարողականությունից, դուք կարող եք խաղեր ստեղծել FireMonkey-ի միջոցով. ի վերջո, դրանք ստեղծվում են Direct3D-ի կամ OpenGL-ի միջոցով:
KP:Ի՞նչ աշխատանք եք կատարում ներկայումս ժեստերի ճանաչման և այլ նորամուծությունների աջակցման ոլորտում: Հասանելի է արդյոք նման աջակցություն:
ԴԻ.:Այս թողարկումում մենք դեռ չունենք ժեստերի աջակցություն: Ժեստերի կառավարումը կավելացվի FireMonkey-ի ապագա թողարկումում, սակայն մինչ այդ դուք կարող եք օգտագործել օպերացիոն համակարգում ներկառուցված ժեստերի աջակցությունը:
Միխայիլ Ֆիլիպենկոն, Fast Reports, Inc.
K.R.:Մենք արդեն ասել ենք, որ FireMonkey տեխնոլոգիան ունի ռուսական արմատներ. դրա հիմքերը ստեղծվել են մեր երկրում, իսկ հետո և՛ տեխնոլոգիան, և՛ դրա մշակողները միացել են Embarcadero-ին։ Ընդհանուր առմամբ, ուրախալի է տեսնել ռուսական բաղադրիչի աճը RAD Studio-ում և Delphi-ում։ Սա ներառում է Սանկտ Պետերբուրգում մեր զարգացման կենտրոնի գործունեությունը և անկախ ռուս ծրագրավորողների ներդրումը: Օրինակ, Rad Studio XE2-ը ներառում է FastReport հաշվետվությունների գեներատորը, որը հայտնի է ամբողջ աշխարհում և շատ տարածված մեր երկրում: Նա ծագումով Դոնի Ռոստովից է։
KP:Կցանկանայի խոսել կոմպիլյատորների մասին։ Ինչպիսի՞ կոմպիլյատոր է օգտագործվում iOS հավելվածներ ստեղծելիս:
ԴԻ.:Մենք չունենք մեր սեփական Delphi կոմպիլյատորը iPhone-ի կամ iPad-ի համար. մենք դեռ չենք մշակել այդ սարքերում օգտագործվող ARM պրոցեսորների համար կոմպիլյատորներ: iOS-ի համար մենք ժամանակավորապես օգտագործում ենք Free Pascal կոմպիլյատորը և աշխատաժամանակի գրադարանը: Բայց մենք աշխատում ենք հաջորդ սերնդի կոմպիլյատորների վրա, ներառյալ AWP պրոցեսորների համար: Բայց կան կոմպիլյատորներ Windows-ի և Mac OS-ի համար, քանի որ երկու ապարատային հարթակներն էլ հիմնված են Intel պրոցեսորների վրա:
KP:Ի՞նչ է արվել կոմպիլյատորների ստեղծման ոլորտում վերջին երկու տարիներին։
ԴԻ.:Մենք ունենք 32- և 64-բիթանոց Delphi կոմպիլյատորներ Windows-ի և Mac OS-ի համար: Եվ մենք աշխատում ենք Delphi և C++ կոմպիլյատորների նոր սերնդի վրա։ Դրանք դեռ ընթացքի մեջ են, բայց երբ դրանք ավարտվեն, մենք կունենանք Delphi կոմպիլյատորներ ARM պրոցեսորների, Android պլատֆորմների, Linux-ի և միջև եղած ամեն ինչի համար: Եվ մենք կունենանք 64-բիթանոց C++ կոմպիլյատորներ Windows-ի և այլ հարթակների համար՝ համատեղելի վերջին ստանդարտլեզու C++, նոր ընդունված ISO:
KP:Ի՞նչ է կատարվում այսօր Embarcadero-ի զարգացման գործիքներում ամպային հաշվողական աջակցության հետ:
ԴԻ.: RAD Studio XE 2-ում մենք աջակցում ենք հավելվածները տեղափոխել Microsoft Azure կամ Amazon EC2 ամպ՝ օգտագործելով Platform Assistant-ը: Եվ մենք ունենք սերվերի բաղադրիչներ Cloud Storage-ի համար Azure-ի և Amazon S3-ի համար՝ աղյուսակներ, երկուական տվյալներ, հաղորդագրությունների հերթեր պահելու համար: IN նախորդ տարբերակը RAD Studio XE-ի միջոցով մենք նաև աջակցում էինք հավելվածների տեղակայմանը Amazon EC2-ում, սակայն այն չուներ պահեստավորման աջակցություն:
Cloud computing աջակցություն RAD Studio XE 2-ում
KP:Երկու տարի առաջ դուք խոսեցիք նոր All-Access լուծման մասին: Որքանո՞վ էր այն հայտնի: Որո՞նք են դրա առավելությունները համակարգային ինտեգրատորների և մշակողների համար:
ԴԻ.: All-Access լուծումը և AppWave ամպային գործիքը լայնորեն կիրառվում են ամբողջ աշխարհում: Դրանք նախատեսված են մեր սեփական և երրորդ կողմի հավելվածների օգտագործումը հեշտացնելու համար: Այն, ըստ էության, լուծում է լիցենզիաների և հավելվածների օգտագործման կառավարման համար և հարմար է խոշոր ընկերությունների համար: Փոքր ձեռնարկությունները, որոնք չունեն հատուկ մարդկանց թիմեր, որոնք պատասխանատու են հավելվածների կառավարման համար, կարող են հավելվածը տեղադրել պահոց, ընտրել օգտանուններ տվյալների բազայից և հասանելի դարձնել այդ հավելվածները՝ առանց հիշելու, թե որտեղ է լիցենզիայի բանալին կամ քանի լիցենզիա կա: All-Access-ը և AppWave զննարկիչը նախագծված են ինչպես տարբերակման, այնպես էլ մուտքի վերահսկումը կառավարելու համար:
K.R.:Շուկան այնքան բազմազան է, և օգտվողներն այնքան տարբեր են, որ անհնար է մեկ լուծումով ծածկել բոլոր կարիքները։ Այդ իսկ պատճառով մենք ձգտում ենք փաթեթավորման բազմազան լուծումների: Մենք մեծ աշխատանք ենք կատարել լիցենզավորման, լիցենզիայի կառավարման և արտադրանքի տեղադրման մեթոդները միավորելու ուղղությամբ։ Լուծումների այս շարքը ներառում է լիցենզիայի և տրամադրման կառավարման գործիքներ ոչ միայն Embarcadero-ի արտադրանքի, այլ նաև ցանկացած այլ արտադրանքի համար, ներառյալ ներքին ընկերության զարգացումները:
Օգտագործողների համար արդյունավետ փաթեթների փաթեթավորման մշակման գործիքների մշակման աշխատանքները դեռ շարունակվում են: Մենք ունենք All-Access՝ գերհամակարգ, որը միավորում է Embarcadero-ի բոլոր արտադրանքները: Եթե հաճախորդը գնում է All-Access Platinum, նրանք ստանում են Embarcadero-ում հայտնաբերված բոլոր գործիքները: Բայց երբեմն այս հավաքածուն ավելորդ է դառնում, օրինակ տվյալների բազայի մասնագետների համար մենք պատրաստել ենք երկու այլ հավաքածու՝ DB Power Studio Developer Edition և DB Power Studio DBA Edition: Նրանց միջև տարբերությունն այն է, որ մշակողի համար մենք առաջարկում ենք RapidSQL՝ սերվերի կոդի մշակման գործիք, իսկ ադմինիստրատորի համար կա ներկառուցված DBArtizan՝ տվյալների բազայի կառավարման գործիք, ավելի լայն արտադրանք, քան RapidSQL-ը։ Պրոֆեսիոնալների համար մենք ունենք հետևյալ All-Access փաթեթները. փաթեթ, որը ներառում է բոլոր ապրանքները, DB Power Studio ծրագրավորողների համար, DB Power Studio ադմինիստրատորների համար, ER Studio Enterprise Edition ճարտարապետների և մոդելավորման մեջ ներգրավված բոլորի համար: Կան համակցություններ հավելվածների մշակման և ադմինիստրատորների համար: Delphi-ն մշակողի գործիք է, և շատ իմաստալից է դրան ավելացնել SQL մշակման և օպտիմալացման գործիքներ: Վերջապես, DB Change Manager-ը տրամաբանական գործիք է՝ կառավարելու փոփոխությունների բարդությունը, որոնք տեղի են ունենում տվյալների բազաներում իրենց կյանքի ցիկլի ընթացքում:
Այսպիսով, All-Access-ը տարբեր ապրանքատեսակների մեծ ընտանիքի ղեկավարն է:
KP:Եթե գաղտնիք չէ, ո՞վ է Ռուսաստանում օգտագործում All-Access-ը:
K.R.:Մենք ունենք հաճախորդներ, ովքեր գնել են All-Access-ը՝ հիմնվելով Delphi-ի վրա: Նրանցից շատերը կառուցում են բարդ հաճախորդ-սերվեր համակարգեր SQL Server-ի և Oracle-ի հետ, և նրանց անմիջապես դուր են եկել մեր միջպլատֆորմային տվյալների բազայի գործիքները: Մենք ունենք հաճախորդ ընկերություն, որն օգտագործում է Delphi-ն առաջին տարբերակից, և մեկ տարի առաջ նրանք Delphi-ի օգտագործումից անցան All-Access փաթեթին: Երկու գործիքներ, որոնք երաշխավորված են օգտագործել այս ընկերության բոլոր մշակողները՝ Delphi-ն և DBArtisan-ն են: Եվ կան հաճախորդներ, ովքեր եկել են All-Access տվյալների բազայի կողմից: Նրանց հիմնական խնդիրն է կառավարել տվյալների շտեմարանները, բայց նրանք երբեմն նաև հավելվածներ են մշակում: All-Access օգտագործող հաճախորդները ներառում են մեդիա ընկերություններ, ինժեներական ընկերություններ և այլ ոլորտներ:
Առանձին-առանձին, ես կցանկանայի կենտրոնանալ փոքր ընկերությունների վրա: Շատ հաճախ փոքր թիմերում ծրագրավորողն անում է ամեն ինչ, և նման ընկերությունները երբեմն գնում են մեծ All-Access ապրանքատեսակների հավաքածուներ մեկ կամ երկու մշակողների համար: Խոշոր թիմերում մշակողի համար չի խրախուսվում նաև կատարել, օրինակ, տվյալների բազայի ադմինիստրատորի դերը, ուստի փոքր արտադրանքի հավաքածուները սովորաբար այնտեղ տարածված են, բայց փոքր ընկերություններում պարտականությունների նման համակցությունը միանգամայն ընդունելի է:
Delphi Architect-ը մեծ շուկայական արտադրանք է, որը ներառում է մոդելավորման և ծրագրավորման գործիքներ: Վաճառված օրինակների թիվը, սակայն, ավելի քիչ է, քան Delphi Enterprise տարբերակը, բայց այն նաև մեծ է: Նշեմ, որ 2010 թվականին մենք վաճառքի ծավալով լավագույն երկիրն ենք, չնայած այն հանգամանքին, որ բոլոր երկրները ճգնաժամ ապրեցին։ Այս աճը կապված էր ոչ այնքան տնտեսական գործոնների հետ, որքան այն բանի հետ, որ RAD Studio XE-ի տարբերակը, որը թողարկվել էր 2009 թվականի վերջին, շատ հայտնի դարձավ։ Իսկ առայժմ մենք ակնկալում ենք վաճառքի հետագա աճ։
Մենք հերթական ողջամիտ քայլն ենք կատարել, որը չափազանց տարածված է Ռուսաստանում։ Մեր արտադրանքի տարբեր տարբերակների օրինականացման աստիճանը տարբեր է՝ որքան բարձր է տարբերակը, այնքան ավելի օրինականացված է, քանի որ ավելի վաղ. ծրագրային ապահովումոչ այնքան ակտիվ գնված: Սկսած RAD Studio XE-ից՝ լիցենզիան ընդգրկում է 2010, 2009, 2007 և նույնիսկ Delphi 7 տարբերակները՝ լայնորեն օգտագործվող արտադրանք:
Այսօր ծրագրավորողները կանգնած են այն փաստի հետ, որ նրանք ունեն և՛ նոր նախագծեր, և՛ նախագծեր, որոնք աջակցում են: Մեծ թվով նախագծեր Delphi-ի վաղ տարբերակներից տեղափոխվել են 7-րդ տարբերակ և մնում են այս տարբերակում՝ շարունակելով աշխատել համեմատաբար փոքր ռեսուրսներով: Ոչ ոք դրանք չի տեղափոխում ավելի նոր տարբերակների, բայց դրանք պահպանվում են կենսունակ վիճակում։ Եվ այժմ մենք թույլ ենք տալիս Ձեզ ստանալ և՛ RAD Studio XE, և՛ Delphi 7 փոքր գումարով (Դելֆի 7-ի լիցենզիայի գնից պակաս), այսինքն՝ մենք օրինականացնում ենք ծրագրավորողին և՛ նոր նախագծերի իրականացման, և՛ օժանդակ նախագծերի համար:
KP:Ինչպե՞ս եք գնահատում Embarcadero համայնքի ներկայիս վիճակը:
ԴԻ.:Այս համայնքը մեծ է և շատ պահանջկոտ: Նրանց անհապաղ պետք է ամեն ինչ՝ նրանք մշակողներ են։ Բայց երբեմն ինչ-որ բան ճիշտ անելու համար երկար ժամանակ է պահանջվում:
Մի քանի տարի առաջ մենք վերցրեցինք Windows բաղադրիչի ճարտարապետությունը և տեղադրեցինք Linux աշխատասեղանների վրա: Հիմա մենք տեսնում ենք, որ դա ճիշտ որոշում չէր։ Ճիշտ լուծումը կիրառական հարթակի ստեղծումն է: Հավելվածները նույնիսկ տարբեր հարթակներում ունեն մենյու, պատուհաններ, գրաֆիկա, ցանցային հասանելիություն և սարքի հասանելիություն: Տարբեր հարթակներ կարող են ունենալ թելերը կառավարելու կամ բացառություններ վարելու տարբեր մոդելներ, բայց մենք տեսնում ենք նույն փորձի բլոկները հավելվածի կոդում: Մեր խնդիրն է ծրագրավորողների համար հեշտացնել բիզնես հավելվածների ստեղծումը և դրանք կազմելը այն հարթակների համար, որոնց վրա դրանք նախատեսված են օգտագործել՝ անկախ նրանից, թե ինչպես է կառուցված համապատասխան պրոցեսորների հրահանգների հավաքածուն և ինչ այլ առանձնահատկություններ ունեն այդ հարթակները: Եվ FireMonkey-ն հենց այն է, ինչ ձեզ հարկավոր է այս խնդիրը լուծելու համար:
KP:Եթե ընկերությունը ստեղծի նոր սարք և ցանկանա, որ այն աջակցվի FireMonkey-ում, դա հնարավոր կլինի՞:
ԴԻ.:Կոմպիլյատորների նոր սերնդի հետ, որոնք կունենան հարթակից անկախ ճակատ և հարթակից կախված հետնամաս, դա միանգամայն հնարավոր կլինի: Միևնույն ժամանակ, յուրաքանչյուր օպերացիոն համակարգի համար մենք զրոյից ստեղծում ենք կոմպիլյատոր և գործարկման գրադարան:
Ցանկացած ժամանակակից նոր սարք սովորաբար գալիս է գրաֆիկական ինտերֆեյսով (շատերն ունեն երկմիջուկ պրոցեսոր և պրոցեսոր) և մշակողների համար ստանդարտ SDK-ներ: Սա հեշտացնում է FireMonkey-ում սարքի աջակցության ստեղծումը: Եթե նոր սարքն ունի միայն Quartz-ի նման երկչափ գրաֆիկայի գրադարաններ, մենք կկարողանանք աջակցել FireMonkey-ում նման սարքին, բայց դա կտևի մոտավորապես մի քանի ամիս: Այնուամենայնիվ, շատ բան կախված է հարթակից. ոչ բոլոր հարթակներն են ապահովում բոլոր հնարավորությունները, օրինակ, iOS-ը չունի մենյու և երկխոսության տուփեր, և դուք չեք կարողանա համապատասխան բաղադրիչներ տեղադրել նման հավելվածների ձևերի վրա:
KP:Գործընկերների հետ աշխատելու քաղաքականության մեջ ինչ-որ բան փոխվե՞լ է։ Ի՞նչ է արվում ձեր արտադրանքից օգտվողների մասնաբաժինն ավելացնելու համար։ Ի՞նչ է արվում Ռուսաստանում.
ԴԻ.:Մեր գործընկեր էկոհամակարգը լայն է. կան գործիքների և բաղադրիչների հարյուրավոր արտադրողներ, որոնք չեն հայտնաբերվել մեր արտադրանքներում, և մենք ունենք տեխնոլոգիական համագործակցության ծրագիր: Հետևաբար, մշակողների համար հասանելի են բաղադրիչների, տեխնոլոգիաների և գործիքների լայն շրջանակ: Եվ լուծումները, որոնք նրանք ստեղծում են իրենց հաճախորդների համար, ավելի լավն են, քան եթե նրանք օգտագործեին միայն մեր արտադրանքը: Իսկ վաճառքի համար մենք ունենք գրասենյակներ շատ երկրներում, վերավաճառողներ և դիստրիբյուտորներ:
K.R.:Մեզ համար կարևորը ոչ թե գործընկերների քանակն է, այլ յուրաքանչյուր կոնկրետ գործընկերոջ աշխատանքի որակը։ Առայժմ մենք ցանկանում ենք կենտրոնանալ առկա գործընկերների հետ սերտ համագործակցության վրա, թեև գործընկերների ֆոնդը մնում է բաց: Մենք ունենք բազմաթիվ գործընկերներ, և մենք պետք է օգնենք նրանց տեխնոլոգիական առումով։ Մենք աշխատում ենք մշակողների հետ, և նրանք գիտեն, թե ինչ են ուզում, և գիտեն, թե ինչ կա շուկայում, և գործընկերների հնարավորությունները պետք է համապատասխանեն դրան:
Մենք ունենք բիզնես գործընկերներ, ովքեր լրջորեն ներդրումներ են կատարել Embarcadero-ում որպես բիզնես գիծ. նրանք վերապատրաստել են մասնագետներ, մարքեթինգ են անում մեր արտադրանքը, նվիրված աշխատակիցներ, ովքեր պատասխանատու են այս գծի համար և վերահսկում են, թե ինչ է կատարվում մեր արտադրանքի, գնացուցակի, շուկայավարման հետ: Բնականաբար, նրանք ավելի հաջողակ են մեր արտադրանքի վաճառքի առումով, քան այն ընկերությունները, որոնք երբեմն վաճառում են մեր արտադրանքը:
KP:Դավիթ, Կիրիլ, շատ շնորհակալ եմ հետաքրքիր հարցազրույցի համար։ Թույլ տվեք, մեր հրատարակության և մեր ընթերցողների անունից ձեր ընկերությանը մաղթել հետագա հաջողություններ՝ ստեղծելու ձեր զարմանալի գործիքները, որոնց կարիքը շատ ունեն մշակողները:
Նատալյա Էլմանովայի տված հարցերը
FireMonkey-ը «նոր Delphi»-ի հիմնական տեխնոլոգիան է: Խնդրում եմ պատմեք մեզ այս հիմնովին նոր գրադարանի նպատակների, հնարավորությունների և տեխնիկական ասպեկտների մասին: Որոշ ժամանակ անց, հետադարձ հայացք գցելով, որքանո՞վ էր դժվար և արդարացված ձեր հրաժարումը գերճանաչված VCL-ի հետագա զարգացումից:
Այն ընտրվել է որպես Delphi տեխնոլոգիայի զարգացման հիմնական ուղղություն՝ հասնելու կոնկրետ նպատակին՝ բազմահարթակ զարգացում մեկ միջավայրից՝ հիմնված մեկ կոդերի բազայի վրա՝ առանց մշակողների արմատական վերապատրաստման անհրաժեշտության: Այժմ դասական և գերճանաչված VCL-ի շրջանակներում դա անհնար էր, դրա կապը WinAPI-ի հետ չափազանց սերտ էր, կարելի է ասել, «գենետիկ մակարդակում»:
VCL բաղադրիչները չունեին «վերացական» շերտ միջերեսի ֆունկցիոնալ մակարդակի և դրանց ցուցադրման մեխանիզմների միջև: Ֆունկցիոնալ մակարդակ— ինչպես է այն իրեն պահում որպես հսկողություն, ինչ իրադարձությունների է նա արձագանքում, ինչ տեսակի օգտատերերի փոխազդեցություն է ապահովում: Ցուցադրել— անվանել պլատֆորմի վրա հիմնված վիզուալիզացիայի մեթոդները որպես որոշակի պատկեր, որը ձևավորվում է ռաստերային օբյեկտներով և վեկտորային պարզունակներով: FireMonkey-ն ի սկզբանե կիրառել է հսկողությունը երկու բաղադրիչի խստորեն բաժանելու սկզբունքը՝ «վարքային» և «տեսողական»:
Վսևոլոդ Լեոնով, Embarcadero Technologies
Առաջինը հիմնականում կկրկնի ոչ թե VCL-ի հիմունքները, այլ օբյեկտի վրա հիմնված ծրագրավորման էությունը։ Բաղադրիչը դաս է, բաղադրիչ դասերը կազմում են հիերարխիա, որտեղ կարելի է տարբերակել ընտանիքները և մոդուլները: Բաղադրիչի դասը թույլ կապված է այն մատուցման հետ:
Տեսողական «նկարը» ձևավորվում է դինամիկ կերպով, այն կոշտ գրված չէ բաղադրիչ դասում: FireMonkey-ի պատկերը կամ «ոճը» բեռնվում է բաղադրիչի մեջ, երբ հավելվածը սկսվում է: Մենք բաղադրիչի համար ունենք ինչ-որ ֆունկցիոնալ շրջանակ, և «մաշկը» կամ «երեսպատումը» կարելի է փոխել, բայց ինչու: Դա այնպես է, որ FireMonkey հավելվածները վավերական տեսք ունենան ցանկացած հարթակի վրա՝ Windows 7, Windows 8, Mac OS, iOS և մոտ ապագայում՝ Android: Սա մի բան է, որը VCL-ի ավանդական մոնոլիտ դասի կառուցվածքը չէր կարող ապահովել:
Այստեղ առանձնահատուկ դեր է խաղում տեխնոլոգիական մոտեցումը։ Սկզբունքորեն, դուք կարող եք վերցնել VCL գրադարանը և «լցոնել» այն WinAPI-ով և հարթակի այլ հնարավոր զանգերով: Սա դեռ կարելի է անել բաղադրիչների շատ սահմանափակ ենթաբազմության վրա, սակայն VCL-ը պարունակում է մի քանի հարյուր բաղադրիչ, ուստի այս մոտեցումը կարող է պարզապես «սպանել» VCL-ին: Որոշվել է չդիպչել VCL-ին, այլ զարգացնել նոր հնարավորություններ նոր հարթակում՝ FireMonkey-ում։ Այս տեխնոլոգիան նույնիսկ ունի որոշակի տեխնիկական նրբագեղություն. կոնկրետ հարթակի համար նախագիծը հավաքելու պահին Delphi IDE-ն միացնում է պահանջվող կոմպիլյատորը, իսկ ինտերֆեյսի բաղադրիչները ստանում են հարթակի ոճ:
Օգտագործողի համար սա մկնիկի մեկ սեղմում է և նույն աղբյուրի կոդը, Delphi-ի համար ծրագրավորողների երկար տարիների քրտնաջան աշխատանք է նման բազմահարթակ գրադարան ստեղծելը:
Երբ պարզ դարձավ, որ FireMonkey-ը կներկայացվի որպես առանձին նոր հարթակ, պետք է ընտրվեր ճիշտ համակեցության ռազմավարություն. Embarcadero-ն չէր ցանկանում որևէ կերպ բացասաբար ազդել VCL-ի օգտատերերի վրա: Հետևաբար, մենք ընտրել ենք հետևյալ պլանը՝ VCL-ը մնում է գաղափարապես և ճարտարապետապես կայուն՝ ապահովելու հնարավոր առավելագույն համատեղելիությունը՝ հեշտացնելով նախագծերի տեղափոխումը ժամանակակից տարբերակներին: FireMonkey-ի զարգացումը կգնա բնական և զուգահեռ ճանապարհով՝ առանց հաշվի առնելու VCL-ը:
Այս լուծման թույլ կողմը VCL-ից FireMonkey-ի բավականին խնդրահարույց միգրացիան է նույն նախագծի շրջանակներում: Բայց նոր նախագծի համար ծրագրավորողը կարող է ընտրել FireMonkey-ն՝ ապահովելու իրենց արդյունքում ստացվող հավելվածի բազմահարթակ բնույթը: iOS-ի աջակցությամբ XE4-ի թողարկումից հետո արդեն կարելի է խոսել կորպորատիվ միջավայրում բջջային զարգացում սկսելու համար Delphi-ի հստակ մրցակցային առավելությունների մասին, որոնք կավելանան պլանավորված Android աջակցության ներդրումից հետո։
Հետևաբար, ակնհայտ «մերժում» չկա VCL-ի մշակումից որպես այդպիսին: Նոր տարբերակներում Delphi-ի VCL մասը նույնպես զարգանում է: Սա ներառում է 64-բիթանոց աջակցություն, տեսողական բաղադրիչների ոճավորման ներդրում, ճկուն դինամիկ կապերի կամ «կապման» մեխանիզմի ներդրում և VCL նախագծերում տվյալների բազաների հետ աշխատելու համար FireDAC գրադարանի ընդգրկում: Պարզապես, FireMonkey-ի կատարած հսկա որակական թռիչքի համեմատությամբ, VCL-ում առաջընթացը փոքր-ինչ անփայլ է թվում: Բայց, ինչպես դա կարող է լինել, VCL-ը Delphi-ի անբաժանելի մասն է և այդպես կմնա դեռ երկար տարիներ: Չնայած պլատֆորմների էվոլյուցիան և աշխատասեղանի համակարգերի և շարժական սարքերի ՕՀ-ի ոլորտում գործերի ներկա վիճակն այնպիսին է, որ ապագան ակնհայտորեն պատկանում է FireMonkey-ին:
Հարցազրույցում մենք արդեն քննարկել ենք iOS-ի աջակցությունը, եկեք մեր ընթերցողներին պատմենք ուրիշների աջակցության մասին նորագույն տեխնոլոգիաներվերջին RAD Studio XE4-ից, օրինակ, օրինակ՝ Windows 8 և WinRT, 64-բիթանոց համակարգեր, MacOS և այլն: Կարո՞ղ եք թվարկել, թե էլ ի՞նչ կարող եք առաջարկել նորարարություններից փչացած ժամանակակից ծրագրավորողին։
Ամենայն հավանականությամբ, ժամանակակից ծրագրավորողը «փչացած» չէ նորարարություններից։ Խոշոր նախագծերի դեպքում ցանկացած «նորարարություն» հաճախ հանգեցնում է հսկայական աշխատանքի:
Օրինակ, բոլորը երկար սպասեցին, շատերն անմիջապես շտապեցին իրենց ծածկագրերը տեղափոխել նոր հարթակ։ Բայց պարզվում է, որ նույնիսկ շատ պրոֆեսիոնալ թիմերը պատրաստ չեն դրան։ 64-բիթանոց կոդ կազմելը չի նշանակում աշխատել։ «Երիտասարդության մեղքերը» սկսեցին հայտնվել, օրինակ՝ օգտագործելով 4 բայթ հասցեի չափը ենթադրող հրահանգներ: Թեստային մշակույթի բացակայություն՝ զուգորդված այս գործընթացը կարճ ժամանակում իրականացնելու տեխնոլոգիական անպատրաստությամբ:
Եվ ահա, որքան մեծ է նախագիծը, որը չափվում է, ասենք, ելակետային կոդի տողերի քանակով, այնքան ավելի զգույշ և հավասարակշռված են ծրագրավորողները տարբեր տեսակի նորամուծություններով՝ սկսած միջերեսում «կոճակի» հայտնվելուց մինչև «շարահյուսական շաքար»: կոմպիլյատորում։
Այս «խնդրահարույց» ձեռքբերումներից մեկը Windows 8-ի թողարկումն էր: Անձամբ, որպես համակարգչի օգտագործող և պարզապես ժամանակակից ՏՏ մասնագետ, ես հիացած եմ Windows 8-ով: Բայց ծրագրավորողների համար, որոնց ուղարկվել է Windows 8-ով աշխատող համակարգիչների խմբաքանակ՝ նոր ՕՀ-ով մշակման բնութագրերով որպես բեռ, դա նշանակում է որոշակի դժվարություններ:
Մենք փորձեցինք ապահովել այս ՕՀ-ի նոր ինտերֆեյսի զարգացման աջակցությունը հնարավորինս հարմարավետ և ցավոտ: Հետևաբար, հատուկ ոճեր են ներդրվել ինչպես VCL-ի, այնպես էլ FireMonkey-ի համար, և ծրագրավորողը կարող է կամ վերակառուցել հավելվածի ինտերֆեյսը կամ ստեղծել նոր հավելված, որն իր տեսքով չի տարբերվի Windows 8-ի «հայրենիից»: Իհարկե, WinRT-ի միջոցով Windows 8-ի «բնական» աջակցության կարիք կա: Բայց այստեղ է, որ խաղում է ժամանակակից պայմաններում նպատակների առաջնահերթությունը: Մոտ ապագայում Mac OS-ը, iOS-ը, Android-ը դեռ թույլ չեն տալիս մոտ ապագայում խոսել WinRT-ի ամբողջական աջակցության մասին։
Embarcadero-ի ռազմավարական նպատակն, իհարկե, բազմահարթակ է: RAD Studio XE4-ի թողարկումը առանցքային էր, հիմնականում iOS-ի աջակցության շնորհիվ: VCL օգտագործող գոյություն ունեցող ծրագրավորողը կարող է սկսել զարգանալ iOS-ի համար մի քանի ժամվա ընթացքում: Նույնիսկ պարզ բջջային հավելվածը կարող է ակնթարթորեն վերածվել հզոր նախագծի, որն աշխատում է առկա ենթակառուցվածքում: Մի կարծեք, որ սա FireMonkey-ի նոր կոմպիլյատոր է և iOS ինտերֆեյսին համապատասխանող նոր ոճ:
Սա ներառում է նոր տեսողական դիզայներ, ներկառուցված աջակցություն տարբեր ձևերի, տվյալների հասանելիության գրադարաններ, ներառյալ նոր FireDAC-ը և LiveBindings տեխնոլոգիան՝ կորպորատիվ տվյալների հետ ճկուն և դինամիկ կապելու համար: Այս բոլոր նորամուծությունները գալիս են միաժամանակ՝ Windows-ի, Mac OS-ի և iOS-ի համար: վիրահատարան Mac համակարգՕՀ-ն այնքան էլ արագ չի զարգանում, ուստի խնդիրներ չկան, ինչպիսին է Windows 7-ից Windows 8-ի անցումը: Բայց հայտնվեցին Retina էկրաններ, և դա հատուկ ուշադրություն էր պահանջում: Այժմ Delphi XE4-ում ստեղծված MacOS-ի ցանկացած հավելված ավտոմատ կերպով ներառում է երկու ոճ՝ «նորմալ» և «բարձր հստակություն»:
Դա. նույն հավելվածը կարող է ունենալ նույն բարձրորակ «հայրենի» ինտերֆեյսը Apple-ի ցանկացած սեղանադիր համակարգչի վրա:
Embarcadero-ն չի ցանկանում «զարմացնել», «զարմացնել» կամ նույնիսկ «զվարճացնել» ծրագրավորողներին իր նոր նորարարական թողարկումներով: Ավելի շուտ, ընդհակառակը, ՏՏ ոլորտն արդեն լի է տարբեր անակնկալներով՝ նոր սարքեր, նոր հարթակներ, նոր օգտատերեր, նրանց նոր կարիքներ, փոխգործակցության նոր սցենարներ։ Դրան ավելացրեք ծրագրային ապահովման մշակման նոր տեխնոլոգիաներ, և ծրագրավորողները պարզապես ժամանակ չեն ունենա ստեղծելու նոր համակարգեր և գոյություն ունեցող համակարգեր. այն ամենը, ինչ նրանք կանեն, մի միջավայրից մյուսը, հին գրադարանից նորը, մի լեզվից մյուսը տեղափոխվելն է:
Բայց մենք չենք դավանում, որ մերժում ենք ամեն նորը։ Մենք պարզապես ցանկանում ենք ապահովել ամեն ինչի շարունակականությունը՝ կոդը, ինտերֆեյսը, նախագիծը, նույնիսկ մասնագիտական հմտությունները, երբ հայտնվում են նոր հարթակներ և սարքեր: Կարելի է ասել, որ մենք պայքարում ենք անառողջ պահպանողականության դեմ՝ կապված նոր հարթակների հետ՝ զարգացման գործիքների առողջ պահպանողականության միջոցով։ Embarcadero-ից մի սպասեք էկզոտիկ արտադրանքներին, ոչ ստանդարտ ծրագրավորման լեզուներին կամ զարգացման տարօրինակ գործիքներին:
Մեզ մոտ դուք միշտ կգտնեք վիզուալ զարգացում, դասական լեզուներ, «մայրենի» ծածկագիր և թող ձեր հավելվածների թիրախային հարթակները, որոնք ստեղծված են նույն ապացուցված դասական եղանակով, նոր լինեն:
Ի՞նչ է FireMonkey-ը:
FireMonkey-ը (FMX) միջպլատֆորմային մշակման շրջանակ է ինչպես աշխատասեղանի համակարգերի (Windows, Mac OS + սերվերի աջակցություն Linux-ում մոտ ապագայում), այնպես էլ բջջային (iOS և Android) համար՝ օգտագործելով Delphi/C++ լեզուն:
Առանձնահատկություններ:
միասնական կոդային բազա բոլոր հարթակների համար;
ցանկացած հսկիչ (տեսողական բաղադրիչ) կարող է լինել կոնտեյներ (ծնող) այլ բաղադրիչների համար.
ձևի վրա բաղադրիչների շատ առաջադեմ հարաբերական դասավորության (20 տեսակի) առկայությունը.
LiveBinding-ը թույլ է տալիս ցանկացած տեսակի տվյալներ կամ տեղեկատվություն միացնել օգտատիրոջ ցանկացած միջերեսին կամ գրաֆիկական օբյեկտին;
ձևի / բաղադրիչի ոճերի առկայությունը;
Multi-Device Preview-ը թույլ է տալիս հարմարեցնել տեսողական ներկայացումը յուրաքանչյուր հարթակի համար;
FireUI Live Preview - իրական ժամանակում ցուցադրում է հավելվածի տեսքը իրական սարքերում:
Հնարավորությունները:
յուրաքանչյուր հարթակի բնիկ API-ի օգտագործումը, ինչպես նաև երրորդ կողմի բնիկ գրադարաններ կանչելու հնարավորությունը.
փոխազդեցություն բոլոր սենսորների հետ (GPS, արագացուցիչ, կողմնացույց, Bluetooth (ներառյալ LE) և այլն);
աջակցություն push ծանուցումների, IoT;
Asynchronous HTTP հարցումների աջակցություն;
աջակցություն տվյալների բազաների մեծ մասի համար (MsSQL, MySql, Oracle, PostgreSQL, MongoDB և այլն);
աշխատել Cloud Service-ի հետ (Amazon, Azure);
Android ծառայության աջակցություն:
Դեմ (ներկայումս).
հայրենի դասերի հարմարեցման աջակցության բացակայություն;
կոնկրետ բաների իրականացումը կամ անհնար է (վիջեթներ, ընդլայնումներ (iOS) և այլն), կամ պահանջվում է դափի հետ պար (ֆոնային ծառայություն, հեռարձակման հաղորդագրություն և այլն);
Splash էկրանի (սկզբնական էկրանի) հարմարեցումը, մեղմ ասած, բացակայում է.
FMX հսկիչները օգտագործում են իրենց սեփական արտապատկերումը (տեսողականացում, նկարչություն), որը զուտ տեսողականորեն նման է բնօրինակին.
բնիկ հսկիչների օգտագործումը ներառում է մարմնի մեծ շարժումներ.
երբ բաղադրիչները շատ են բույնում, անհավանական բաներ են տեղի ունենում՝ հավելվածը խափանում է տարբեր վայրերում, կորցնում է կենտրոնացումը, սառչում և այլն;
բջջային հարթակներում հավելվածի վրիպազերծման տեղեկատվական բովանդակությունը զրո է.
Բջջային հարթակներում սխալների նկարագրությունները կրճատվում են մինչև անօգուտ «Սխալ 0x00000Х»;
Կազմման ժամանակը ցանկանում է լավագույնը լինել միջին և մեծ նախագծերի համար.
յուրաքանչյուր հարթակի համար բջջային հավելվածները փայլեցնելու համար ֆայլ օգտագործելու անհրաժեշտությունը.
ոչ մի աջակցություն Intel Atom ճարտարապետությանը;
ոչ համարժեք գին՝ համեմատած մրցակիցների հետ:
Կողմերը:
վերջին շրջանում և՛ արտադրանքի, և՛ համայնքի շատ ակտիվ զարգացում, ավելի ու ավելի շատ նոր տեխնոլոգիաների աջակցություն.
հսկայական քանակությամբ անվճար և առևտրային բաղադրիչների առկայությունը.
Հավելվածի արագությունը շատ մոտ է մայրենիին;
շատ առաջադեմ տեսողական խմբագիր և ընդհանուր առմամբ միջավայր, ոճերի առկայություն;
Հավելվածը Win-ում փորձարկելու և միայն այնուհետև այն սարքերում տեղակայելու ունակությունը, ինչը մեծապես արագացնում է զարգացումը.
փոխել ռեժիմը/հարթակը դաստակի շարժումով;
PAServer-ը ապահովում է հեշտ փոխազդեցություն MacO-ների հետ Apple OS-ի համար մշակելիս;
3D գրաֆիկայի աջակցություն առանց տուփի:
Եզրափակելով՝ ես ուզում եմ ասել, որ վերջին մի քանի տարիների ընթացքում FireMonkey-ն վերածվել է պրոֆեսիոնալ գործիքի՝ բիզնես հավելվածների միջպլատֆորմային զարգացման համար և այլն: Շատ թերություններ աստիճանաբար լուծվում են, և յուրաքանչյուր թողարկումով արտադրանքը դառնում է ավելի ժամանակակից և ինքնաբավ, ինչպես նաև վերանում է բուն դելֆի լեզվի նկատմամբ առկա թերահավատությունը, որը կապված է երկար տարիների լճացման հետ: FireMonkey-ում նոր նախագծեր գրելը «անվտանգ» է և խոստումնալից:
Բավական ժամանակ է անցել այն պահից, երբ FireMonkey տերմինը քիչ թե շատ ծանոթ է դարձել, եթե ոչ բոլոր ծրագրավորողների, ապա գոնե նրանց համար, ովքեր օգտագործում են Delphi-ը։ Այս ընթացքում հայտնվեցին գրքեր FireMonkey-ի մասին, հոդվածներ FireMonkey-ի մասին և FireMonkey-ի մասին գրառումներ բազմաթիվ բլոգներում։ Այս ամենը կարդալը շատ հետաքրքիր է։ Բայց ոչ մի տեսություն չի կարող փոխարինել պրակտիկային: Եվ ես, ինչպես նախկինում շատերը, քոր առաջացա FireMonkey-ով ինչ-որ բան գրել փորձելու համար:
Այնուամենայնիվ, խնդիր առաջացավ. Չգիտես ինչու, ես որոշեցի, որ ինձ պարզապես անհրաժեշտ է իրականացնել ոչ այնքան բարդ աշխատանքային նախագիծ։
Բացատրելու համար, թե ինչու դա ինձ համար խնդիր դարձավ, որոշ (ես ուզում եմ գրել, լիրիկական) շեղումներ կպահանջվեն։ Էքսկուրսիա դեպի իմ անցյալ՝ որպես ծրագրավորող: Բացատրեք Դելֆիի օգտագործմամբ ծրագրավորման վերաբերյալ իմ տեսակետներից մի քանիսը:
Ասեմ, որ ես սկսել եմ օգտագործել Delphi-ն Windows 3.1-ում, այսինքն՝ առաջին տարբերակից։ Եվ այդ ժամանակվանից ես ուսումնասիրում եմ VCL-ը: Ես, այսպես ասած, բնագրով եմ ուսումնասիրել։ Ես նայեցի, մուտք գործեցի, հետագծեցի աղբյուրները։ Նորից ու նորից.
Հայտնի է, որ տարբեր ժամանակներում Delphi-ով առաքված բաղադրիչների շարքը ներառում էր երրորդ կողմի բաղադրիչներ, որոնք նախատեսված էին VCL-ում բացերը լրացնելու համար, և որոնք հավանաբար անցել են որակի որոշակի հսկողություն նախքան ներառվելը: Այս բաղադրիչներից մի քանիսը շարունակում են մատակարարվել այսօր: Վերցրեք նույն Ինդիին: Ես չեմ ուզում վիրավորել որևէ մեկին, սա զուտ իմ անձնական կարծիքն է, որը վերաբերում է նաև ինձ՝ որպես բաղադրիչ մշակողի. ոչ մի հավաքածու այնքան խորը մտածված և այնքան լավ չի իրականացվել, որքան հսկայական և բազմազան VCL-ը: Ոչ, ես չեմ հավակնում որպես վերջնական ճշմարտություն, և, իհարկե, հենց VCL-ում կան բազմաթիվ սխալներ, որոշումներ, որոնք առաջացնում են թյուրիմացություն, առաջացնում են մերժում և որոնց հետ դուք ուզում եք չհամաձայնվել: Բայց ես միշտ որոշակի միասնական ոճի տպավորություն եմ ունեցել։ Իմ կարծիքով, VCL-ում կա գեղեցիկ և ուժեղ միջուկ, որն աջակցում է Delphi-ի ամբողջ դիզայնին, և որի շուրջ կառուցված են և՛ ծրագրային ենթակառուցվածքը, և՛ մշակողների համայնքը: Մեծ մասամբ VCL-ի շնորհիվ է, նորից, իմ կարծիքով, Դելֆիի մահվան մասին լուրերը դեռևս մնում են ասեկոսեներ: Եվ երբ VCL-ի առաքումը ներառում էր բաղադրիչներ երրորդ կողմի մշակողների կողմից, դա անմիջապես նկատելի էր, դրանք տարբեր էին:
Բայց հետո գալիս է պահը, և ես լսում եմ, որ VCL-ն հնացած տեխնոլոգիա է: Տեխնոլոգիա, որը պետք է թողնել անցյալում։ Ծրագրավորողները պետք է իրականացնեն իրենց բոլոր նոր նախագծերը FireMonkey-ում, իսկ ինչ վերաբերում է հներին... լավ կլիներ դրանք տեղափոխել նոր թրեքերի։ FireMonkey ամենուր, ցանկացած ժամանակ: Եվ ես դա լսում եմ տարբեր աղբյուրներից: Եվ բավականին համառորեն: Ոչ, ոչ ոք չի սպանում VCL-ին: նա մնում է մեզ հետ: Բայց նա այլեւս թիվ մեկ չէ։ Նա պետք է դառնա պահեստային: Համենայն դեպս ես այդպես եմ հասկանում, թե ինչ է ասվում ապրանքի ապագայի մասին։
Ես սկզբունքորեն հասկանում եմ այս իրավիճակը։ Մենք սահմանել ենք բազմահարթակ և, որ ավելի կարևոր է, միջպլատֆորմի կուրս: Ի վերջո, ինչ է VCL- ը: Տեսողական բաղադրիչ գրադարան: Տեսողական բաղադրիչների գրադարան: Դուք կարող եք չհամաձայնվել սրա հետ: Օրինակ, ես միշտ համարել եմ շատ ոչ վիզուալ բաղադրիչներ, և ոչ թե բաղադրիչներ, այլ պարզապես դասեր, որպես VCL-ի անբաժանելի մաս, իսկ երրորդ կողմի դասերի և բաղադրիչների հսկայական քանակությունը որպես VCL-ի շարունակություն, ընդլայնում: Դե, ես չեմ կարող մտածել TDataset-ի ժառանգների մասին որպես VCL-ի մաս: Չնայած, օրինակ, DBExpress Library տերմինը հուշում է, որ սա, ասես, VCL չէ: Ըստ երևույթին, Embarcadero-ն իսկապես բաժանում է մոնոլիտը, իմ տեսանկյունից, VCL-ը մի շարք առանձին գրադարանների: Ոչ, իհարկե, ոչ ամբողջությամբ առանձին, բայց այնուամենայնիվ։ Եվ եթե ընդունենք այս տեսակետը, FireMonkey-ը նախատեսված է փոխարինելու հենց VCL-ի տեսողական մասը (ինչպե՞ս պետք է դեռ կոչեմ դասերի և բաղադրիչների ամբողջական գրադարանը, գուցե Borland Component Library):
Որո՞նք են այն տեսողական բաղադրիչները, որոնք ներառված են շուրջ կառուցված գրադարանում: Օպերացիոն համակարգի կողմից տրամադրված ցածր մակարդակի հիմնական տարրերի շուրջ: Պատուհանների բռնակները, տառատեսակները, հենց պատուհանները, մուտքային տարրերը, հաղորդագրությունները, սարքի համատեքստը և շատ ավելին. սրանք գրադարանի հասկացությունները չեն, որը գալիս է Delphi-ի հետ, այլ օպերացիոն համակարգի հասկացություններ: Այո, հենց Windows. Իսկ եթե ցանկանում եք ստեղծել միջպլատֆորմային գրադարան, ապա տրամաբանական է հրաժարվել օպերացիոն համակարգի առաջարկած ենթակառուցվածքից, որն աշխատում է գրադարանի միջոցով գրված ծրագիրը։
Սա հենց այն է, ինչ փորձում է անել FireMonkey-ը: Նրանք փորձում են տարբեր օպերացիոն համակարգերում աջակցվող հիմնական մեխանիզմների հիման վրա ստեղծել ենթակառուցվածք, որը կարող է փոխարինել այն ծառայությունը, որն իրենք առաջարկում են օպերացիոն համակարգերը։
Շատերը հիշում են, որ փորձել ենխաչաձև հարթակ ոչ միայն գրադարանը, այլև հենց Դելֆին. Delphi 6-ին զուգահեռ թողարկվեցին Kylix արտադրանքը և CLX գրադարանը։ Այս ամենը արվել է, որպեսզի դուք կարողանաք զարգացնել Linux-ի համար։ Այնուամենայնիվ, Linux-ը չունի հիմնական հասկացություններից շատերը պատուհանի գրաֆիկական ինտերֆեյսի առումով, որն ունի Windows-ը: Linux-ի պատուհանի ինտերֆեյսը հիմնականում բնիկ երևույթ չէ: Սա ընտրովի հավելված է: Եվ ես պետք է գրեի ինչ-որ սինթետիկ գրադարան: Նրա օգնությամբ հնարավոր եղավ գրել ծրագիր ինչպես Windows-ի, այնպես էլ Linux-ի համար։ Այնուամենայնիվ, ես դեռ հիշում եմ ոչ թե հիասթափության, այլ ավելի շուտ նյարդայնացնող անհարմարության զգացումը, որը զգացի, երբ փորձեցի օգտագործել CLX-ի անալոգային տեսողական բաղադրիչները: Ես սկսեցի շատ բաներ բաց թողնել։ Այն, ինչ ես սովոր էի անել առանց մտածելու VCL-ի միջոցով մշակելիս, պարզվեց, որ դժվար էր, բոլորովին այլ կամ պարզապես անհնար էր անել CLX-ի միջոցով:
Ես մոտավորապես նույն կերպ էի զգում BDE-ից DBExpress-ի անցնելիս: Հին, ծանոթ Field Test BDE-ին (Borland-ն արդեն օգտագործում էր այն Quattro Pro-ում Windows-ի համար և Paradox-ում Windows-ի համար, և այն կոչվում էր ODAPI, այնուհետև IDAPI, և գլխով ու ուսերով վերև, իմ կարծիքով, Microsoft ODBC) հայտարարվեց հնացած տեխնոլոգիա, որը պետք է իր տեղը զիջի նոր գրադարանին նոր նախագծերում: DBExpress-ում ինձ միշտ ինչ-որ բան էր պակասում, հատկապես գիտելիքը:
Միևնույն ժամանակ, ես ոչ մի կերպ չեմ ուզում նախատել կամ քննադատել ոչ իրենց վերևում թվարկված գրադարաններին, ոչ էլ դրանց հայտնվելուն հանգեցրած որոշումներին։ Խոսքը միայն իմ տպավորությունների, երբեմն առաջին տպավորությունների մասին է։
Հիմա, հավանաբար, մի փոքր ավելի պարզ է դառնում, թե ինչու FireMonkey-ի միջոցով փոքր աշխատանքային նախագիծ գրելու որոշումը մի շարք խնդիրներ բերեց։ Երկար տարիների ընթացքում նախագծեր, նախագծեր և պլաններ մշակելիս ձևավորվել է որոշակի կարծրատիպ, որոշակի ձևանմուշ, թե ինչ և ինչպես անել: Իսկ իմ դեպքում ես ստիպված էի առերեսվել այն փաստի հետ, որ կաղապարը պետք է փոխվի։ Քանի որ դուք չեք կարող փոխանցել այն ամենը, ինչին սովոր եք VCL-ին օգտագործել FireMonkey-ի վրա կառուցված նախագծին:
Նախագիծը սկսելիս դեժավյուի որոշակի զգացում ապրեցի։ Մասնավորապես՝ անհարմարության զգացում։ Օրինակ, սովորական մուտքային տարրերը շատ հատկություններ չունեն: Գործնականում ամուր հաստատված տեխնիկան, որը հիմնված է օպերացիոն համակարգի որոշ առանձնահատկությունների իմացության հետ կապված հնարքների վրա, չի գործում նոր համատեքստում: Էլ չեմ ասում, որ որոշ բաղադրիչներ արմատապես փոխվել են։
Դե, ևս մեկ կարևոր նրբերանգ. Ինչպիսի՞ նախագծեր եք սովորաբար ստիպված լինում անել աշխատավայրում, եթե այն (աշխատանքը) կապված չէ գրելու կոմպիլյատորների, մոդելավորման համակարգերի կամ որևէ այլ բարձր գիտական բանի հետ: Կարծում եմ, մեծամասնության համար այն մշակում է մի բան, որը ներառում է տվյալների բազաների օգտագործումը: Ավելին, բարձր գիտական որևէ բան կարող է նաև օգտվել DBMS-ի կողմից տրամադրվող ծառայություններից:
Այստեղ ինձ հերթական դարան էր սպասում։ Չգիտես ինչու, երբ գործնականում հանդիպում եք այն փաստին, որ FireMonkey-ը չի պարունակում տվյալների բազայում պահվող տվյալների հետ աշխատելու վրա կենտրոնացած տարրեր, դուք ինքներդ ձեզ այնքան էլ պատրաստ չեք (մեղմ ասած): Չնայած ես արդեն բազմիցս կարդացել եմ այս մասին և գիտեմ (տեսականորեն) ինչ օգտագործել: Մենք խոսում ենք Live Bindings-ի մասին:
Ես չեմ ուզում վեճի մեջ մտնել այն մասին, թե իրական թույն ծրագրավորողները պետք է օգտագործեն db-aware բաղադրիչներ, թե ոչ: Գործնականում, երբ նոր նախագիծ սկսեցի, ես կանգնած էի այն փաստի հետ, որ ես պետք է վարժվեի երկուսին էլ: նոր տեսողական բաղադրիչներ և տվյալների որոնման նոր եղանակ՝ ցուցադրման, խմբագրման և, ի վերջո, պահպանման համար: Ինչը, դարձյալ, ոչ վատ է, ոչ լավ։ Ինձ համար ուղղակի այդպես եղավ։
Այստեղ ես ուզում եմ ավարտել իմ գրառումը առաջին տպավորությունների մասին: Հաջորդը պատմություններ են այն մասին, թե ինչ է հաղթահարվել և ինչպես ծրագրի վրա աշխատելիս:
