ცეცხლი მაიმუნი. დაწყება

03/06/2013 12:46 pm

მე ძალიან განვიცდი FireMonkey-ში ბრაუზერის კომპონენტის ნაკლებობის გამო. ცნობილი Delphi Chromium Embedded პროექტი მოიცავდა FMX მხარდაჭერას უახლეს კონსტრუქციაში. მაგრამ იმისდა მიუხედავად, რომ საკმაოდ დიდი დრო გავიდა, ავტორი არ ჩქარობს FMX2 მხარდაჭერის დამატებას. საბოლოოდ, მე მომიწია საქმეების ხელში აყვანა.

ოფიციალური ასამბლეის TChromiumFMX კომპონენტი საკმაოდ კარგად მუშაობს FireMonkey-ში (XE2-ში), მაგრამ FMX2-ში ის არც კი კომპილირებულია. ცოტა უნდა გამეგო როგორ მუშაობს და გამომესწორებინა. საბედნიეროდ, მნიშვნელოვანი ცვლილებები არ იყო საჭირო.

FMX2-ში შეიცვალა ორი რამ, რაც კომპონენტს სჭირდება.

პირველი, TBitmap-ს აღარ აქვს ScanLine და StartLine თვისებები. TBitmap-ის შიგთავსზე პირდაპირი წვდომა შეიცვალა (მაინტერესებს რატომ?) და ახლა ხელმისაწვდომია TBitmapData კლასის მეშვეობით, რომელიც აბრუნებს TBitmap.Map მეთოდს.

მეორე, უფრო ცნობილი - პლატფორმა .* აღარ არის, ახლა თქვენ უნდა მიიღოთ სასურველი ინტერფეისი TPlatformServices.GetPlatformService-ის მეშვეობით. აქ ყველაფერი საკმაოდ მარტივია და არანაირი პრობლემა არ არის.

მე არ გამომიცდია იგი განსაკუთრებული ჭკუით, მაგრამ კომპონენტი საკმაოდ შესაფერისია ჩემი მიზნებისთვის - შეგიძლიათ საიტების ნახვა. ჩამოტვირთეთ. მაინც, ალბათ, ჩემს რედაქტირებებს გავუგზავნი ავტორს, იქნებ საჭიროდ ჩათვალოს მათი ოფიციალურ ვერსიაში დამატება.

07/30/2012 2:43 სთ

ჯეისონ საუთუელი გვთავაზობს შექმნას FireMonkey გარსაცმების ნაკრები მშობლიური Windows/OSX კონტროლისთვის და ამისთვის აგროვებს ფულს. დასაწყისისთვის ის 20 000 დოლარის შეგროვებას გეგმავს.

აზრი ნათელია. არსებული FireMonkey კომპონენტები გამოსახულია დელფის ინსტრუმენტების გამოყენებით თითქმის ნულიდან, რაც, ერთის მხრივ, დიდწილად უზრუნველყოფს მათ კროს პლატფორმას, მაგრამ მეორეს მხრივ, შედეგად, ჩვენ ვიღებთ კომპონენტებს, რომლებიც არ გამოიყურება საკმაოდ ბუნებრივად ორივე ამჟამად მხარდაჭერილ ოპერაციებში. სისტემები. და ეს არც ისე ცუდია - გარდა გარეგნობისა, თქვენ დამოუკიდებლად უნდა განავითაროთ ამ კომპონენტების ლოგიკა. მაგალითად, RichEdit საკმაოდ რთულია და მისი ლოგიკის გამეორება FireMonkey-ში არ არის ტრივიალური ამოცანა. VCL-მაც და CLX-მაც არ გამოიგონეს ველოსიპედები, არამედ გამოიყენეს მზა.

ახლა კი ცუდი ამბავი. ყველაფერი მუშაობს გაშვების დროს, მაგრამ მე ვერ ვიპოვე რაიმე გზა დავამატო ჩემი ახალი ჩანართის ტიპი Items Designer-ში. და როგორც ჩანს, სიის ყველა კონტროლს აქვს იგივე პრობლემა: TListBox, TGrid და ა.შ. თავიდან ძალიან მომეწონა მათი განხორციელების მიდგომა, მაგრამ ახლა რაღაცნაირად ეჭვიც კი მეპარება. ინტერნეტის ძებნამ აჩვენა, რომ მე არ ვარ მარტო ამ პრობლემის წინაშე.

დახმარება დუმს, კოდშიც ვერაფერი ვიპოვე. მართლა არანაირად? ეს იქნება უკიდურესად შემაშფოთებელი.

სამ წელზე მეტი გავიდა მას შემდეგ, რაც CodeGear განყოფილება, რომელიც პასუხისმგებელია ისეთი მსოფლიოში ცნობილი ინსტრუმენტების შექმნაზე, როგორიცაა Delphi, C++Builder და JBuilder, ისევე როგორც Interbase DBMS, გახდა Embarcadero Technologies-ის ნაწილი, კომპანია, რომელიც ცნობილია თავისი მონაცემთა ბაზის დიზაინითა და ადმინისტრირებით. ინსტრუმენტები. , და ორი წლის შემდეგ ჩვენ განვიხილეთ ჩვენი ჟურნალის გვერდებზე, თუ რას უნდა ველოდოთ ინსტრუმენტების შემუშავებაში, რომლებიც ასე პოპულარულია რუს დეველოპერებში. ჩვენ ვთხოვეთ დეველოპერებთან ურთიერთობის ვიცე-პრეზიდენტს და Embarcadero Technologies-ის მთავარ ევანგელისტს დევიდ ინტერსიმონს და რუსეთში Embarcadero Technologies-ის წარმომადგენლობის ხელმძღვანელს კირილ რანევს. ჩვენი ყველაზე ახალგაზრდა მკითხველისთვის გაცნობებთ, რომ ეს შორს არის პირველი ინტერვიუსგან, რომელსაც დევიდი და კირილი აძლევენ ComputerPress-ს - ჩვენი თანამშრომლობა უკვე მეორე ათწლეულია. და დაახლოებით ამდენივე წლის განმავლობაში პერიოდულად ვაქვეყნებთ მონაცემთა ბაზის მართვის ინსტრუმენტების მიმოხილვებს, რომლებშიც დიდი ყურადღება ეთმობა Embarcadero-ს პროდუქტებს.

ComputerPress:დავით, შენი დივიზიონი უკვე სამი წელია Embarcadero-ს ნაწილია. ორი წლის წინ ენთუზიაზმით იყავით სავსე იმის გამო, რომ იგი გახდა თქვენთვის ახლომდებარე კომპანიის ნაწილი მიზნებითა და სულით. რამე შეიცვალა ამ ხნის განმავლობაში? თქვენ და თქვენი კოლეგები ერთნაირ ენთუზიაზმს გრძნობთ?

დიახ, მე მაინც ენთუზიაზმით ვარ. მთავარი ცვლილება, რაც მოხდა მას შემდეგ, რაც ჩვენ გავხდით Embarcadero კომპანიაში, არის ის, რომ დიდი ინვესტიცია განხორციელდა Delphi-ს განვითარებაში. გაიზარდა განვითარების ინსტრუმენტებზე მომუშავე თანამშრომლების რაოდენობა, გაიზარდა ტექნოლოგიების რაოდენობა, რომლებიც შეგვიძლია განვავითაროთ ან, საჭიროების შემთხვევაში, შევიძინოთ.

RAD Studio XE 2-ის გამოშვება, რომლის დემონსტრირებასაც ვგეგმავთ მოსკოვში, არის ამ პროდუქტის ყველაზე დიდი გამოშვება უზარმაზარი შესაძლებლობებით და დიდი რაოდენობით მხარდაჭერილი პლატფორმებით Delphi-ის პირველი ვერსიის შემდეგ, შექმნილი 16-ბიტიანი Windows-ისთვის და ყოფილი ინოვაციური. პროდუქტი, რომელიც აკავშირებდა კომპონენტის მიდგომასა და კომპილაციას მანქანის კოდთან. ახლა ჩვენ მხარს ვუჭერთ განვითარებას არა მხოლოდ Windows-ისთვის, არამედ Macintosh-ისთვისაც, რომ აღარაფერი ვთქვათ ვებ-განვითარებაზე და მობილური მოწყობილობებისთვის აპლიკაციების შექმნაზე და სხვადასხვა პლატფორმისთვის ამ აპლიკაციებს შეიძლება ჰქონდეს ერთი კოდი.

განვითარების ახალი პლატფორმა, FireMonkey, არის Embarcadero-სა და ახლახან შეძენილ ულან-უდეში დაფუძნებულ რუსულ ფირმას KSDev-ს შორის თანამშრომლობა, ვექტორული გრაფიკის კომპონენტების, DirectX და OpenGL, გრაფიკული ეფექტების ტექნოლოგიებისა და Delphi კომპონენტების მწარმოებელი PixelShader 2.0-ით GPU-ს გამოყენებით. ჩვენ შევიძინეთ კომპანია KSDev (იხილეთ ksdev.ru) ერთი წლის წინ და დავიწყეთ ერთად მუშაობა მულტიპლატფორმული განვითარების ხელსაწყოს შესაქმნელად, რომელიც მოიცავს FireMonkey აპლიკაციების შემუშავების პლატფორმას Delphi-სა და C ++ Buider-ის კომპონენტებით, აპლიკაციის მომხმარებლის ინტერფეისის შესაქმნელად, ინტეგრაციისთვის. მონაცემთა ბაზებით, გრაფიკული დამუშავება გრაფიკული პროცესორის გამოყენებით და ოპერაციულ სისტემასთან ინტეგრაცია.

FireMonkey-ის გამოყენებით შეგიძლიათ შექმნათ აპლიკაცია, რომელიც გაუშვებს CPU-სა და GPU-ს ერთად, შემდეგ კი სხვადასხვა შემდგენელებისა და დროის ბიბლიოთეკების გამოყენებით (Run-time Libraries, RTL) შეგიძლიათ შეადგინოთ იგი Windows, Mac OS ან iOS-ისთვის. იმის ნაცვლად, რომ ისწავლონ პროგრამირება სხვადასხვა გრაფიკული ბიბლიოთეკებით, ისწავლონ API-ები სხვადასხვა პლატფორმიდან სხვადასხვა კოორდინატთა სისტემებით და სხვადასხვა შესაძლებლობებით, დეველოპერებს, რომლებიც იყენებენ Delphi-ს და C++Builder-ს, შეუძლიათ გამოიყენონ ერთი და იგივე კომპონენტის მიდგომა, ვიზუალურად შეცვალონ ფორმები და დაუკავშირდნენ მონაცემთა ბაზებს კომპონენტის გადაადგილებით. მაუსი. ეს არის ფუნდამენტურად ახალი გზა სხვადასხვა პლატფორმაზე გაშვებული აპლიკაციების შესაქმნელად და არის მომავალი. თუ გსურთ თქვენს აპლიკაციას დაამატოთ სხვა ოპერაციული სისტემებისა და პლატფორმების მხარდაჭერა, არ გჭირდებათ მისი ხელახალი დიზაინი და განვითარება - საკმარისი იქნება მხოლოდ მისი ხელახალი კომპილაცია.

ჩვენ ვქმნით ახალ შემდგენლებს, რომლებიც ქმნიან მშობლიურ კოდს. დღეს არის Delphi შემდგენელები Windows-ის 32-ბიტიანი და 64-ბიტიანი ვერსიებისთვის, Mac OS 10-ის 32-ბიტიანი ვერსიებისთვის. ჩვენ ვმუშაობთ შემდეგი თაობის Delphi და C++Builder შემდგენლებზე, რომლებიც საშუალებას მოგცემთ შექმნათ მაღალი ხარისხის. მშობლიური კოდი როგორც ამ, ასევე სხვებისთვის. პლატფორმებზე, როგორიცაა Android ან Linux და შეინარჩუნეთ იგივე დიზაინი, იგივე კომპონენტები, იგივე კოდი სხვადასხვა შემდგენელებისა და გაშვების ბიბლიოთეკების გამოყენებით.

როგორც ხედავთ, ენთუზიაზმისთვის საკმარისი მიზეზები მაქვს. და დეველოპერებმა, რომლებსაც ვხვდები მთელ მსოფლიოში, იციან, რომ Embarcadero დიდ ინვესტიციას ახორციელებს Delphi-სა და C++Builder-ში, ისევე როგორც PHP განვითარების ინსტრუმენტებში.

კპ:რა პროგრესს მიაღწიეთ ორი კომპანიის ინსტრუმენტების ინტეგრირებაში ბოლო ორი წლის განმავლობაში? როგორია Embarcadero-ს სამომავლო გეგმები ამ სფეროში?

DI.:იმ დროს, როდესაც 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 შეკითხვის ოპტიმიზაციის ინსტრუმენტი, რომელიც საშუალებას გაძლევთ შეასრულოთ განვითარებისა და დანერგვის პროცესის მნიშვნელოვანი ნაწილი, მართოთ ცვლილებები მონაცემთა მოდელი, მონაცემთა ბაზა, კოდი და ა.შ. ეს არის ტექნოლოგიების ძალიან კარგი და სწორი კომბინაცია.

DI.:მაგრამ, საჭიროების შემთხვევაში, დეველოპერებს შეუძლიათ გამოიყენონ Subversion წყაროს კოდის ვერსიების სამართავად და DB Change Manager მეტამონაცემების ვერსიების სამართავად. შეგიძლიათ გამოიყენოთ კოდის პროფილირება და DB Optimizer სერვერის კოდის ოპტიმიზაციისთვის, RapidSQL სერვერის კოდის შესაქმნელად და გამართვისთვის და ჩვენი განვითარების გარემო აპლიკაციების შესაქმნელად და გამართვისთვის. ტექნოლოგიების ეს კომბინაცია RAD Studio XE Ultimate Edition-ში აჩვენებს პარალელებს მონაცემთა ბაზისა და აპლიკაციის განვითარების მოდელებს შორის. დეველოპერების უმეტესობა, რომლებიც ქმნიან ბიზნეს აპლიკაციებს Delphi-თან და C++Builder-ით, მუშაობენ მონაცემთა ბაზებთან და სჭირდებათ ეს ხელსაწყოები, და RAD Studio XE Ultimate Edition შესანიშნავი კომბინაციაა ამ დეველოპერებისთვის.

კპ:თანამედროვე მომხმარებელი აღარ არის მარტო Windows პლატფორმის მომხმარებელი. ჩვენ ვიყენებთ მობილურ მოწყობილობებს, iPhone, iPad, Android პლატფორმაზე დაფუძნებულ მოწყობილობებს. ეს ნიშნავს, რომ დეველოპერებმა უნდა დაიწყონ სხვადასხვა პლატფორმის დამიზნება ტრენინგში ინვესტიციის მნიშვნელოვანი ზრდის გარეშე – ანუ საჭიროა უნივერსალური ინსტრუმენტები. ცხადია, არარეალურია პლატფორმის მწარმოებლებისგან უნივერსალური ხელსაწყოების გაჩენის მოლოდინი და ამ საკითხში მხოლოდ ხელსაწყოების დამოუკიდებელ მწარმოებლებს შეგვიძლია დავეყრდნოთ. სად შეიძლება დავეყრდნოთ Embarcadero-ს?

DI.:ჩვენ ჯერ კიდევ ბევრი გვაქვს გასაკეთებელი პლატფორმის მხარდაჭერის სფეროში. დღეს ჩვენ წარმოგიდგენთ 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-ის შესაძლებლობების გაფართოებას, მათ შორის მობილური პლატფორმების მხარდაჭერას.

კპ:შეგიძლიათ უფრო დაწვრილებით დაწეროთ FireMonkey პლატფორმაზე?

DI.:როგორც უკვე აღვნიშნე, Windows-ისთვის შექმნილი VCL ბიბლიოთეკა განაგრძობს განვითარებას და გაუმჯობესებას. მაგრამ დღეს, თუ გსურთ რეალურად განავითაროთ ბიზნეს აპლიკაციები, უნდა შექმნათ ისინი სხვადასხვა პლატფორმისთვის. სწორედ ამისთვის არის შექმნილი FireMonkey პლატფორმა. იგი მხარს უჭერს მაღალი გარჩევადობის მომხმარებლის ინტერფეისების შექმნას, მაღალი ხარისხის 3D გრაფიკას, მაღალი კადრების სიხშირეს და, რაც მთავარია, ამისათვის იყენებს GPU-ს.

თქვენ შეგიძლიათ გამოიყენოთ ეს ფუნქციები სამეცნიერო, საინჟინრო და ბიზნეს აპლიკაციების შექმნისას. ასეთ აპლიკაციებს შეუძლიათ მონაცემთა ბაზებთან დაკავშირება 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-ის სტილის ყოვლისმომცველი ანიმაციური სისტემა, მაგრამ ის საშუალებას გაძლევთ გამოიყენოთ ეფექტები, როგორიცაა ბიტმაპის ანიმაცია, მომხმარებლის ინტერფეისის ელემენტის ფოკუსის ხაზგასმა და ვექტორულ გრაფიკასთან მუშაობა. დეველოპერისთვის ხელმისაწვდომია 50-ზე მეტი ვიზუალური ეფექტი: დაბინდვა, სურათის შავ-თეთრად გადაქცევა, დაშლა, გადასვლები, ასახვა, ჩრდილების შექმნა - ყველა სახის ეფექტი ხელმისაწვდომია თანამედროვე GPU-ებში, რომლებიც ახლა თითქმის ნებისმიერ კომპიუტერშია. 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-ით და მასში აპლიკაცია, რომელიც ასახავდა გეგმას და აჩვენებდა ინფორმაციას მონაცემთა წყაროებიდან. მათ ცოტა ხნის წინ გააკეთეს რაღაც საინტერესო - დახატეს სრულად ავტომატიზირებული 3D საწყობი AutoCAD-ში და მათი აპლიკაცია საშუალებას გაძლევთ ნახოთ, თუ როგორ მოძრაობს ავტომატური მტვირთავი საწყობში და ათავსებს საქონელს თაროებზე. და ისინი აქვეყნებენ მონაცემებს წყაროებიდან შესაბამის სურათზე.

აპლიკაციის სტილის შეცვლის მაგალითები

კპ:რა 3D მოდელის ფორმატებია ამჟამად მხარდაჭერილი?

DI.:ამ გამოშვებაში ჩვენ მხარს ვუჭერთ მოდელების ჩატვირთვას AutoCAD, Collada-დან (ღია კოდის 3D მოდელირების ინსტრუმენტი. - Შენიშვნა. რედ.), მაია, OBJ ფორმატი, რომელსაც მხარს უჭერს მრავალი 3D გრაფიკის გამყიდველი.

კპ:კიდევ რა ფორმატების დამატება იგეგმება?

DI.:ჩვენ ვგეგმავთ დაამატოთ 3DS (3D Studio MAX), SVG (ჩვეულებრივ, ეს ფორმატი გამოიყენება 2D ვექტორული გრაფიკისთვის, მაგრამ ზოგჯერ 3D-ისთვის), Google SketchUp. ჩვენ შესაძლოა სხვა ფორმატებსაც ვუჭერთ მხარს.

კპ:მოითხოვს თუ არა 3D მოდელების გამოყენება FireMonkey-ით აგებულ აპლიკაციებში ლიცენზიას შესაბამისი 3D მოდელირების ხელსაწყოსთვის?

DI.:არა, არა. ჩვენ მხოლოდ მოდელის ფაილის წაკითხვას ვაკეთებთ. ჩვენ ვახორციელებთ მოდელის იმპორტს, მაგრამ არა ექსპორტს (თუმცა, რა თქმა უნდა, შეგიძლიათ დაწეროთ აპლიკაცია, რომელიც შეინახავს მოდელს თქვენს ფორმატში). ჩვენ არ გვაქვს პრეტენზია, რომ ვართ 3D მოდელირების ხელსაწყოების მწარმოებელი - ამისთვის შეგიძლიათ გამოიყენოთ AutoCAD, 3D Studio Max, Maya ან ნებისმიერი სხვა 3D მოდელირების ხელსაწყო და შემოიტანოთ შექმნილი მოდელები ჩვენს აპლიკაციებში.

კპ:რამდენად ეფექტურია FireMonkey-ით აშენებული აპლიკაციები თანამედროვე აპარატურულ პლატფორმებზე?

DI.:შესრულება საკმაოდ მაღალია. მაგალითად, სამგანზომილებიანი ფორმა სამი სფეროთი და სამი შუქით შეიძლება გამოისახოს 100 კადრი წამში MacBook Pro-ზე. და შეიძლება მიაღწიოს 600-ს - ეს დამოკიდებულია იმაზე, თუ რას ვაკეთებთ კონკრეტულად. ისევ და ისევ, ეს ყველაფერი დამოკიდებულია GPU-ს სიმძლავრეზე.

კპ:ნიშნავს თუ არა ეს, რომ FireMonkey-ის დახმარებით შეგიძლიათ შექმნათ თამაშები, რომლებიც აკმაყოფილებენ თანამედროვე მოთხოვნებს?

DI.:ჩვენ არ ვაყენებთ ჩვენს განვითარების ინსტრუმენტებს, როგორც თამაშების ინსტრუმენტს. თუმცა, თანამედროვე GPU-ების მაღალი წარმადობის გამოყენებით, თქვენ ასევე შეგიძლიათ შექმნათ თამაშები FireMonkey-ით - ბოლოს და ბოლოს, ისინი შექმნილია Direct3D ან OpenGL გამოყენებით.

კპ:რა სამუშაოს ასრულებთ ახლა ჟესტების ამოცნობისა და სხვა ახალი საგნების მხარდაჭერის სფეროში? არის თუ არა ასეთი მხარდაჭერა?

DI.:ამ გამოშვებაში ჯერ არ გვაქვს ჟესტების მხარდაჭერა. ჟესტების კონტროლი დაემატება FireMonkey-ის მომავალ გამოშვებას, მაგრამ ამ დროისთვის შეგიძლიათ გამოიყენოთ ოპერაციულ სისტემაში ჩაშენებული ჟესტების მხარდაჭერა.

მიხაილ ფილიპენკო, Fast Reports, Inc.

კ.რ.:ჩვენ უკვე ვთქვით, რომ FireMonkey ტექნოლოგიას რუსული ფესვები აქვს - მისი საფუძვლები შეიქმნა ჩვენს ქვეყანაში, შემდეგ კი თავად ტექნოლოგია და მისი დეველოპერები გაერთიანდნენ Embarcadero-ში. ზოგადად, სასიხარულოა რუსული კომპონენტის ზრდა RAD Studio-სა და Delphi-ში. ეს არის ჩვენი განვითარების ცენტრის საქმიანობა პეტერბურგში და დამოუკიდებელი რუსი დეველოპერების წვლილი. მაგალითად, Rad Studio XE2 მოიცავს FastReport ანგარიშის გენერატორს, რომელიც ცნობილია მთელ მსოფლიოში და ძალიან პოპულარულია ჩვენს ქვეყანაში. ის დონის როსტოვიდანაა.

კპ:მსურს ვისაუბრო შემდგენლებზე. რა კომპილერი გამოიყენება iOS აპლიკაციების შესაქმნელად?

DI.:ჩვენ არ გვაქვს საკუთარი Delphi კომპილერი iPhone-ისთვის ან iPad-ისთვის - ჩვენ ჯერ არ შეგვიმუშავებია კომპილატორები ამ მოწყობილობებში გამოყენებული ARM პროცესორებისთვის. iOS-ისთვის ჩვენ დროებით ვიყენებთ უფასო პასკალის შემდგენელს და გაშვების ბიბლიოთეკას. მაგრამ ჩვენ ვმუშაობთ შემდეგი თაობის შემდგენელებზე, მათ შორის ARM პროცესორებისთვის. მაგრამ არსებობს Windows-ისა და Mac OS-ის შემდგენელები, რადგან ორივე ტექნიკის პლატფორმა დაფუძნებულია Intel პროცესორებზე.

კპ:და რა გაკეთდა კომპილატორების განვითარების სფეროში ბოლო ორი წლის განმავლობაში?

DI.:ჩვენ გვაქვს 32 და 64 ბიტიანი Delphi კომპილატორები Windows და Mac OS-ისთვის. ჩვენ ვმუშაობთ ახალი თაობის Delphi და C++ შემდგენელებზე. მათზე მუშაობა ჯერ კიდევ გრძელდება, მაგრამ როდესაც ის დასრულდება, გვექნება Delphi კომპილატორები ARM პროცესორებისთვის, Android პლატფორმებისთვის, Linux-ისთვის და სხვა. ჩვენ გვექნება 64-ბიტიანი C++ შემდგენელები Windows-ისთვის და სხვა პლატფორმებისთვის, რომლებიც თავსებადია C++ ენის უახლეს სტანდარტთან, რომელიც ახლახან იქნა მიღებული ISO-ს მიერ.

კპ:რა ხდება ღრუბლოვანი გამოთვლის მხარდაჭერასთან დაკავშირებით Embarcadero-ს განვითარების ინსტრუმენტებში დღეს?

DI.: RAD Studio XE 2-ით, ჩვენ მხარს ვუჭერთ აპლიკაციების მიგრაციას Microsoft Azure ან Amazon EC2 ღრუბელში პლატფორმის ასისტენტის გამოყენებით. ჩვენ გვაქვს სერვერის კომპონენტები Cloud Storage-ისთვის Azure-სთვის და Amazon S3 ცხრილების, ბინარული მონაცემების, შეტყობინებების რიგების შესანახად. RAD Studio XE-ის წინა ვერსიაში ჩვენ ასევე მხარს ვუჭერდით აპლიკაციების განთავსებას Amazon EC2-ზე, მაგრამ არ იყო შენახვის მხარდაჭერა.

Cloud Computing მხარდაჭერა RAD Studio XE 2-ში

კპ:ორი წლის წინ თქვენ ისაუბრეთ ახალ All-Access გადაწყვეტაზე. რამდენი იყო მოთხოვნა? რა სარგებლობა მოაქვს მას სისტემური ინტეგრატორებისა და დეველოპერებისთვის?

DI.: All-Access გადაწყვეტა და AppWave ღრუბლოვანი ინსტრუმენტი ფართოდ გამოიყენება მთელ მსოფლიოში. ისინი შექმნილია იმისათვის, რომ გააადვილოს როგორც ჩვენი კომპანიის, ასევე მესამე მხარის აპლიკაციების გამოყენება. სინამდვილეში, ეს არის გამოსავალი ლიცენზიებისა და აპლიკაციების მართვისთვის და მოსახერხებელია დიდი კომპანიებისთვის. მცირე ფირმებს, რომლებსაც არ ჰყავთ გამოყოფილი აპლიკაციის მართვის გუნდი, შეუძლიათ განათავსონ აპლიკაცია საცავში, შეარჩიონ მომხმარებლის სახელები მონაცემთა ბაზიდან და გახადონ ეს აპლიკაციები ხელმისაწვდომი გამოსაყენებლად, არ დაიმახსოვრონ სად არის ლიცენზიის გასაღები და რამდენი ლიცენზია არის ხელმისაწვდომი. All-Access და AppWave ბრაუზერი შექმნილია როგორც ვერსიების, ასევე წვდომის კონტროლის სამართავად.

კ.რ.:ბაზარი იმდენად მრავალფეროვანია, მომხმარებლები კი იმდენად განსხვავებული, რომ შეუძლებელია ყველა საჭიროების დაფარვა ერთი გადაწყვეტით. ამიტომ, ჩვენ ვცდილობთ მრავალფეროვანი "შეფუთვის" გადაწყვეტილებებისკენ. ჩვენ ბევრი სამუშაო გავაკეთეთ ლიცენზირების, ლიცენზირების მართვისა და პროდუქტის ინსტალაციის გაერთიანებაზე. გადაწყვეტილებების ეს ხაზი მოიცავს ლიცენზიისა და წვდომის მართვის ინსტრუმენტებს არა მხოლოდ 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 არის სხვადასხვა პროდუქტის ნაკრების დიდი ოჯახის უფროსი.

კპ:თუ საიდუმლო არ არის, ვინ იყენებს რუსეთში All-Access-ს?

კ.რ.:ჩვენ გვყავს მომხმარებლები, რომლებმაც შეიძინეს 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 ვერსიებს, ფართოდ გამოყენებულ პროდუქტს.

დღეს დეველოპერები დგანან იმ ფაქტის წინაშე, რომ მათ აქვთ როგორც ახალი პროექტები, ასევე პროექტები მხარდაჭერის მდგომარეობაში. პროექტების დიდი რაოდენობა გადავიდა დელფის ადრეული ვერსიებიდან მე-7 ვერსიაში და რჩება ამ ვერსიაში და განაგრძობს მუშაობას შედარებით მცირე რესურსებზე. არავინ გადააქვს მათ ახალ ვერსიებზე, მაგრამ ისინი სიცოცხლისუნარიანია. ახლა კი ჩვენ ვაძლევთ საშუალებას მცირე ფულს (დელფი 7 ლიცენზიის ფასზე ნაკლები) მივიღოთ როგორც RAD Studio XE, ასევე Delphi 7 - ანუ ვაკანონებთ დეველოპერს როგორც ახალი პროექტების განსახორციელებლად, ასევე მხარდაჭერის პროექტებისთვის.

კპ:როგორ აფასებთ Embarcadero საზოგადოების ამჟამინდელ მდგომარეობას?

DI.:ეს საზოგადოება არის დიდი და ძალიან მომთხოვნი. მათ ყველაფერი სჭირდებათ და დაუყოვნებლივ - ისინი დეველოპერები არიან. მაგრამ ხანდახან რაღაცის გამოსწორებას დიდი დრო სჭირდება.

რამდენიმე წლის წინ ჩვენ ავიღეთ Windows კომპონენტის არქიტექტურა და განვათავსეთ Linux დესკტოპებზე. ახლა ჩვენ ვხედავთ, რომ ეს არ იყო სწორი გადაწყვეტილება. სწორი გადაწყვეტილებაა აპლიკაციებისთვის პლატფორმის შექმნა. აპლიკაციებს სხვადასხვა პლატფორმებისთვისაც კი აქვთ მენიუები, ფანჯრები, გრაფიკა, ქსელის წვდომა და მოწყობილობებზე წვდომა. სხვადასხვა პლატფორმას შეიძლება ჰქონდეს დინების კონტროლის ან გამონაკლისების მართვის განსხვავებული მოდელები, მაგრამ ჩვენ ვხედავთ იგივე საცდელ ბლოკებს აპლიკაციის კოდში. ჩვენი ამოცანაა გავუადვილოთ დეველოპერებს ბიზნეს აპლიკაციების შექმნა და მათი შედგენა იმ პლატფორმებისთვის, რომლებზეც ისინი უნდა გამოიყენონ, მიუხედავად იმისა, თუ როგორ არის მოწყობილი შესაბამისი პროცესორების ინსტრუქციული სისტემა და რა სხვა მახასიათებლები აქვს ამ პლატფორმებს. და FireMonkey არის ზუსტად ის, რაც გჭირდებათ ამ პრობლემის გადასაჭრელად.

კპ:თუ კომპანია ქმნის ახალ მოწყობილობას და სურს ჰქონდეს FireMonkey-ის მხარდაჭერა, იქნება ეს შესაძლებელი?

DI.:ახალი თაობის შემდგენელებით, რომლებსაც ექნებათ პლატფორმისგან დამოუკიდებელი წინა ნაწილი და პლატფორმაზე დამოკიდებული უკანა ნაწილი, ეს სავსებით შესაძლებელი იქნება. იმავდროულად, თითოეული ოპერაციული სისტემისთვის, ჩვენ ვქმნით კომპილატორს და გაშვების ბიბლიოთეკას ნულიდან.

ნებისმიერ თანამედროვე ახალ მოწყობილობას ჩვეულებრივ აქვს მომხმარებლის გრაფიკული ინტერფეისი (ბევრ მათგანს აქვს ორბირთვიანი პროცესორი და GPU) და სტანდარტული SDK-ები დეველოპერებისთვის. ეს ყველაფერი ამარტივებს მოწყობილობის მხარდაჭერის შექმნას FireMonkey-ში. თუ ახალ მოწყობილობას აქვს ბიბლიოთეკები მხოლოდ 2D გრაფიკისთვის, როგორიცაა Quartz, ჩვენ შევძლებთ მსგავსი მოწყობილობის მხარდაჭერას FireMonkey-ში, მაგრამ ამას დაახლოებით რამდენიმე თვე დასჭირდება. თუმცა, ბევრი რამ არის დამოკიდებული პლატფორმაზე: ყველა პლატფორმას არ აქვს ყველა ფუნქციის მხარდაჭერა, მაგალითად, iOS-ს არ აქვს მენიუები და დიალოგები და თქვენ ვერ შეძლებთ შესაბამისი კომპონენტების განთავსებას ასეთი აპლიკაციების ფორმებზე.

კპ:შეიცვალა თუ არა რაიმე პარტნიორებთან მუშაობის პოლიტიკაში? რა კეთდება თქვენი პროდუქციის მომხმარებელთა წილის გასაზრდელად? რა კეთდება რუსეთში?

DI.:ჩვენი პარტნიორის ეკოსისტემა ფართოა - არის ასობით მწარმოებელი ხელსაწყოებისა და კომპონენტების მწარმოებლები, რომლებიც არ გვხვდება ჩვენს პროდუქტებში და ჩვენ გვაქვს ტექნოლოგიური პარტნიორობის პროგრამა. ამიტომ, კომპონენტების, ტექნოლოგიებისა და ინსტრუმენტების ფართო სპექტრი ხელმისაწვდომია დეველოპერებისთვის. და გადაწყვეტილებები, რომლებსაც ისინი ქმნიან თავიანთი მომხმარებლებისთვის, უკეთესია, ვიდრე მხოლოდ ჩვენი პროდუქტების გამოყენება. და გაყიდვებისთვის, ჩვენ გვაქვს ოფისები ბევრ ქვეყანაში, გადამყიდველები და დისტრიბუტორები.

კ.რ.:ჩვენთვის მნიშვნელოვანია არა პარტნიორების რაოდენობა, არამედ თითოეული კონკრეტული პარტნიორის მუშაობის ხარისხი. ამ დროისთვის, ჩვენ გვინდა ფოკუსირება მოვახდინოთ არსებულ პარტნიორებთან მჭიდრო თანამშრომლობაზე, თუმცა პარტნიორების ფონდი ღია რჩება. ბევრი პარტნიორი გვყავს და მათ უნდა დავეხმაროთ ტექნოლოგიური თვალსაზრისით. ჩვენ ვმუშაობთ დეველოპერებთან და მათ იციან რა უნდათ და იციან რა არის ხელმისაწვდომი ბაზარზე და პარტნიორების შესაძლებლობები უნდა შეესაბამებოდეს ამას.

ჩვენ გვყავს ბიზნეს პარტნიორები, რომლებმაც დიდი ინვესტიცია მოახდინეს Embarcadero-ში, როგორც ბიზნესის ხაზში - მათ მოამზადეს სპეციალისტები, ჩვენი პროდუქციის მარკეტინგი, თავდადებული თანამშრომლები, რომლებიც პასუხისმგებელნი არიან ამ სფეროში და აკონტროლებენ რა ხდება ჩვენს პროდუქტებთან, ფასების სიაში, მარკეტინგი. ბუნებრივია, ისინი უფრო წარმატებულები არიან ჩვენი პროდუქციის გაყიდვის კუთხით, ვიდრე კომპანიები, რომლებიც ყიდიან ჩვენს პროდუქციას შემთხვევის მიხედვით.

კპ:დავით, კირილ, დიდი მადლობა საინტერესო ინტერვიუსთვის. ჩვენი პუბლიკაციისა და ჩვენი მკითხველების სახელით, ნება მომეცით ვუსურვო თქვენს კომპანიას წარმატებები თქვენი საოცარი ინსტრუმენტების შექმნაში, რომელიც დეველოპერებს ძალიან სჭირდებათ!

კითხვები დაუსვა ნატალია ელმანოვას

FireMonkey არის "ახალი დელფის" ძირითადი ტექნოლოგია. გთხოვთ, გვითხრათ ამ ფუნდამენტურად ახალი ბიბლიოთეკის მიზნების, შესაძლებლობებისა და ტექნიკური ასპექტების შესახებ. გარკვეული პერიოდის შემდეგ, გადახედეთ უკან, რამდენად რთული და გამართლებული იყო თქვენი უარი სუპერ პოპულარული VCL-ის შემდგომ განვითარებაზე?

იგი შეირჩა დელფის ტექნოლოგიის განვითარების მთავარ მიმართულებად კონკრეტული მიზნის მისაღწევად - მრავალპლატფორმული განვითარება ერთი გარემოდან, ერთი წყაროს კოდის საფუძველზე და დეველოპერების რადიკალური გადამზადების საჭიროების გარეშე. ახლა კლასიკური და სუპერ პოპულარული 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 აკავშირებს საჭირო შემდგენელს, ხოლო ინტერფეისის კომპონენტები იღებენ პლატფორმის სტილს.

მომხმარებლისთვის ეს არის მაუსის ერთი დაწკაპუნება და იგივე წყაროს კოდი, დელფისთვის, დეველოპერების მრავალწლიანი შრომაა ასეთი მრავალპლატფორმიანი ბიბლიოთეკის შექმნა.

როდესაც გაირკვა, რომ FireMonkey დაინერგებოდა, როგორც ცალკე ახალი პლატფორმა, სწორი თანაარსებობის სტრატეგია უნდა აერჩია: Embarcadero-ს არ სურდა რაიმე უარყოფითი ზემოქმედება მოეხდინა VCL მომხმარებლებზე. ამიტომ, ჩვენ ავირჩიეთ შემდეგი გეგმა: VCL რჩება იდეოლოგიურად და არქიტექტურულად სტაბილური, რათა უზრუნველყოს მაქსიმალური თავსებადობა, რაც აადვილებს პროექტების მიგრაციას თანამედროვე ვერსიებზე. FireMonkey-ის განვითარება მიჰყვება ბუნებრივ და პარალელურ გზას, VCL-ზე უკანმოუხედავად.

ამ გადაწყვეტის სუსტი წერტილი არის საკმაოდ პრობლემური მიგრაცია VCL-დან FireMonkey-ზე ერთი პროექტის ფარგლებში. მაგრამ მეორე მხრივ, ახალი პროექტისთვის, დეველოპერს შეუძლია აირჩიოს FireMonkey, რათა დარწმუნდეს, რომ მისი შედეგად მიღებული აპლიკაცია მრავალპლატფორმულია. iOS-ის მხარდაჭერით XE4-ის გამოშვებით უკვე შეგვიძლია ვისაუბროთ Delphi-ის ძლიერ კონკურენტულ უპირატესობაზე მობილურის განვითარებისთვის კორპორატიულ გარემოში, რომელიც გაიზრდება Android-ისთვის დაგეგმილი მხარდაჭერის განხორციელების შემდეგ.

ამიტომ, როგორც ასეთი, არ არსებობს აშკარა "უარი" VCL-ის განვითარებაზე. ახალ ვერსიებში ასევე ვითარდება დელფის VCL ნაწილი. ეს მოიცავს 64-ბიტიან მხარდაჭერას და ვიზუალური კომპონენტების სტილის დანერგვას და მოქნილი დინამიური ბმულების ან „დაკავშირების“ მექანიზმის დანერგვას და FireDAC ბიბლიოთეკის ჩართვას მონაცემთა ბაზებთან მუშაობისთვის VCL პროექტებში. უბრალოდ, FireMonkey-ის გამო გიგანტური ხარისხობრივი ნახტომის ფონზე, პროგრესი VCL-ში გარკვეულწილად გამოუვლენელია. მაგრამ როგორც ეს შეიძლება იყოს, VCL არის Delphi-ის განუყოფელი ნაწილი და ასე დარჩება მრავალი წლის განმავლობაში. მიუხედავად იმისა, რომ პლატფორმების ევოლუცია და ოპერაციული სისტემის ამჟამინდელი მდგომარეობა დესკტოპ სისტემებისა და მობილური მოწყობილობებისთვის ისეთია, რომ მომავალი აშკარად FireMonkey-ს ​​აქვს.

ინტერვიუში უკვე განვიხილეთ iOS-ის მხარდაჭერა, მოდით ვუთხრათ ჩვენს მკითხველს უახლესი RAD Studio XE4 მხარდაჭერის შესახებ სხვა უახლესი ტექნოლოგიებისთვის, როგორიცაა Windows 8 და WinRT, 64-ბიტიანი სისტემები, MacOS და ა.შ. შეგიძლიათ ჩამოთვალოთ კიდევ რა შეგიძლიათ შესთავაზოთ ინოვაციებით გაფუჭებულ თანამედროვე პროგრამისტს?

დიდი ალბათობით, თანამედროვე პროგრამისტი არ არის "გაფუჭებული" ინოვაციებით. დიდი პროექტებისთვის ნებისმიერი „ინოვაცია“ ხშირად იქცევა გიგანტურ სამუშაოდ.

მაგალითად, ყველა დიდხანს ელოდა, ბევრმა მაშინვე გაიქცა თავისი კოდების ახალ პლატფორმაზე გადასატანად. მაგრამ გამოდის, რომ ძალიან პროფესიონალური გუნდებიც კი არ არიან ამისთვის მზად. კომპილირებადი 64-ბიტიანი კოდი არ ნიშნავს ფუნქციონირებას. "ახალგაზრდობის ცოდვები" დაიწყო გაჩენა, როგორიცაა ინსტრუქციების გამოყენება 4 ბაიტიანი მისამართის ზომით. ტესტების ჩატარების კულტურის ნაკლებობა, ამ პროცესის მოკლე დროში განხორციელების ტექნოლოგიურ უქონლობასთან ერთად.

და აქ - რაც უფრო დიდია პროექტი, რომელიც იზომება, მაგალითად, კოდის ხაზების რაოდენობით, მით უფრო ფრთხილად და დაბალანსებულად ეპყრობიან პროგრამისტები სხვადასხვა სახის ინოვაციებს, დაწყებული ინტერფეისში "ღილაკის" გამოჩენადან "სინტაქსურ შაქარამდე". შემდგენელში.

ერთ-ერთი ასეთი „პრობლემური“ მიღწევა იყო Windows 8-ის გამოშვება. პირადად, როგორც კომპიუტერის მომხმარებელი და უბრალოდ თანამედროვე IT სპეციალისტი, აღფრთოვანებული ვარ Windows 8-ით. მაგრამ დეველოპერებისთვის, რომლებსაც გაუგზავნეს Windows 8 კომპიუტერების პარტია ტექნიკური მახასიათებლებით, ახალი OS-ით განვითარებისთვის, როგორც დატვირთვა, ეს ნიშნავს გარკვეულ სირთულეებს.

ჩვენ ვცდილობდით ამ OS-ის ახალი ინტერფეისით შეგვექმნა მხარდაჭერა განვითარებისთვის რაც შეიძლება კომფორტულად და უმტკივნეულოდ. ამიტომ, სპეციალური სტილები დაინერგა როგორც VCL-ისთვის, ასევე FireMonkey-სთვის და პროგრამისტს შეუძლია ან განაახლოს აპლიკაციის ინტერფეისი, ან შექმნას ახალი აპლიკაცია, რომელიც გარეგნულად განურჩეველი იქნება Windows 8-ის „მშობლიურისგან“. რა თქმა უნდა, საჭიროა Windows 8-ის „მშობლიური“ მხარდაჭერა WinRT-ის საშუალებით. მაგრამ აქ გავლენას ახდენს მიზნების პრიორიტეტიზაცია თანამედროვე პირობებში. Mac OS, iOS, Android უახლოეს მომავალში ჯერ კიდევ არ იძლევა შესაძლებლობას ვისაუბროთ WinRT-ის სრულ მხარდაჭერაზე უახლოეს მომავალში.

Embarcadero-ს სტრატეგიული მიზანი, რა თქმა უნდა, მრავალპლატფორმაა. RAD Studio XE4-ის გამოშვება იყო მთავარი, პირველ რიგში iOS-ის მხარდაჭერის გამო. აქტიური პროგრამისტი, რომელიც იყენებს VCL-ს, შეუძლია რამდენიმე საათში დაიწყოს განვითარება iOS-ისთვის. მარტივი მობილური აპლიკაციაც კი შეიძლება მყისიერად გარდაიქმნას ძლიერ პროექტად, რომელიც მუშაობს არსებულ ინფრასტრუქტურაში. არ იფიქროთ, რომ ეს არის FireMonkey-ის ახალი შემდგენელი და ახალი სტილი, რომელიც შეესაბამება iOS ინტერფეისს.

ეს მოიცავს ახალ ვიზუალურ დიზაინერს, სხვადასხვა ფორმის ფაქტორების ჩაშენებულ მხარდაჭერას, მონაცემთა ხელმისაწვდომობის ბიბლიოთეკებს, მათ შორის ახალ FireDAC-ს და LiveBindings ტექნოლოგიას კორპორატიული მონაცემების მოქნილი და დინამიური შეერთებისთვის. ყველა ეს ინოვაცია მოდის სინქრონულად - Windows-ისთვის, Mac OS-ისთვის და iOS-ისთვის. Mac OS ოპერაციული სისტემა ასე სწრაფად არ ვითარდება, ამიტომ არ არსებობს ისეთი პრობლემები, როგორიცაა Windows 7-დან Windows 8-ზე გადასვლა. მაგრამ გამოჩნდა ბადურის დისპლეები და ამას განსაკუთრებული ყურადღება მოითხოვდა. ახლა Delphi XE4-ში შექმნილი ნებისმიერი MacOS აპლიკაცია ავტომატურად მოიცავს ორ სტილს - "ნორმალური" და "მაღალი გარჩევადობის".

რომ. ერთსა და იმავე აპლიკაციას შეიძლება ჰქონდეს იგივე ხარისხის "მშობლიური" ინტერფეისი Apple-ის ნებისმიერ დესკტოპ კომპიუტერზე.

Embarcadero-ს არ სურს დეველოპერების „გაოცება“, „გაოცება“ ან თუნდაც „გართობა“ თავისი ახალი ინოვაციური გამოშვებებით. პირიქით, IT სფერო უკვე სავსეა სხვადასხვა სიურპრიზებით: ახალი მოწყობილობები, ახალი პლატფორმები, ახალი მომხმარებლები, მათი ახალი საჭიროებები, ურთიერთქმედების ახალი სცენარები. დაამატეთ პროგრამული უზრუნველყოფის განვითარების ახალი ტექნოლოგიები ამას და პროგრამისტებს უბრალოდ არ ექნებათ დრო, შექმნან ახალი სისტემები და არსებული სისტემები - ისინი გააკეთებენ მხოლოდ იმას, რომ გადავიდნენ ერთი გარემოდან მეორეში, ძველი ბიბლიოთეკიდან ახალში, ერთი ენიდან. სხვა.

მაგრამ ჩვენ არ ვაღიარებთ ყველა ახლის უარყოფას. ჩვენ უბრალოდ გვინდა უზრუნველვყოთ ყველაფრის უწყვეტობა - კოდი, ინტერფეისი, პროექტი, თუნდაც პროფესიული უნარები, როდესაც გამოჩნდება ახალი პლატფორმები და მოწყობილობები. შეიძლება ითქვას, რომ ჩვენ ვებრძვით არაჯანსაღ კონსერვატიზმს ახალ პლატფორმებთან მიმართებაში განვითარების ინსტრუმენტებში ჯანსაღი კონსერვატიზმის ხარჯზე. ნუ ელით ეგზოტიკურ პროდუქტებს, არასტანდარტულ პროგრამირების ენებს და არაჩვეულებრივ განვითარების ინსტრუმენტებს Embarcadero-სგან.

ჩვენთან ყოველთვის იპოვით ვიზუალურ განვითარებას, კლასიკურ ენებს, "მშობლიურ" კოდს და ნება მიეცით ახალი იყოს თქვენი აპლიკაციების სამიზნე პლატფორმები, რომლებიც შექმნილია იგივე დადასტურებული კლასიკური გზით.

რა არის Fire Monkey?


FireMonkey (FMX) არის კროს-პლატფორმული განვითარების ჩარჩო, როგორც დესკტოპის სისტემისთვის (Windows, Mac OS + უახლოეს მომავალში იგეგმება სერვერის ნაწილის მხარდაჭერა Linux-ზე) და მობილურისთვის (iOS და Android) Delphi/C++ ენის გამოყენებით. .

თავისებურებები:

  • ერთი კოდის ბაზა ყველა პლატფორმისთვის;

  • ნებისმიერი კონტროლი (ვიზუალური კომპონენტი) შეიძლება იყოს კონტეინერი (მშობელი) სხვა კომპონენტებისთვის;

  • კომპონენტების ძალიან მოწინავე ფარდობითი მოწყობის (20 ტიპის) არსებობა ფორმაზე;

  • LiveBinding საშუალებას გაძლევთ დააკავშიროთ ნებისმიერი ტიპის მონაცემები ან ინფორმაცია მომხმარებლის ნებისმიერ ინტერფეისს ან გრაფიკულ ობიექტს;

  • ფორმის/კომპონენტის სტილის არსებობა;

  • Multi-Device Preview საშუალებას გაძლევთ დააკონფიგურიროთ ვიზუალური პრეზენტაცია თითოეული პლატფორმისთვის;

  • FireUI Live Preview - აჩვენებს აპის ხედს რეალურ მოწყობილობებზე რეალურ დროში.

შესაძლებლობები:

  • თითოეული პლატფორმის მშობლიური API-ის გამოყენება, ასევე მესამე მხარის მშობლიურ ბიბლიოთეკების გამოძახების შესაძლებლობა;

  • ურთიერთქმედება ყველა სენსორთან (GPS, აქსელერომეტრი, კომპასი, Bluetooth (მათ შორის LE) და სხვა);

  • Push შეტყობინებების მხარდაჭერა, IoT;

  • ასინქრონული HTTP მოთხოვნების მხარდაჭერა;

  • მონაცემთა ბაზების უმეტესობის მხარდაჭერა (MsSQL, MySql, Oracle, PostgreSQL, MongoDB და ა.შ.);

  • Cloud Service-თან მუშაობა (Amazon, Azure);

  • ანდროიდის სერვისის მხარდაჭერა.

მინუსები (ამჟამად):

  • მშობლიური კლასების პერსონალიზაციის მხარდაჭერის ნაკლებობა;

  • კონკრეტული ნივთების განხორციელება ან შეუძლებელია (ვიჯეტები, გაფართოებები (iOS) და ა.შ.) ან აუცილებელია ტამბურით ცეკვა (ფონური სერვისი, სამაუწყებლო შეტყობინება და ა.შ.);

  • პერსონალიზაცია Splash screen (საწყისი ეკრანი) რბილად რომ ვთქვათ, არა;

  • FMX კონტროლი იყენებს საკუთარ რენდერს (ვიზუალიზაცია, ნახატი), რომელიც წმინდა ვიზუალურად ჰგავს მშობლიურს;

  • ადგილობრივი კონტროლის გამოყენება დაკავშირებულია სხეულის დიდ მოძრაობებთან;

  • კომპონენტების დიდი ბუდეებით წარმოუდგენელი რამ ხდება: აპლიკაცია იშლება სხვადასხვა ადგილას, იკარგება ფოკუსი, იყინება და ა.შ.;

  • მობილური პლატფორმებზე აპლიკაციის გამართვის საინფორმაციო შინაარსი ნულის ტოლია;

  • მობილური პლატფორმების შეცდომების აღწერილობა შემცირებულია უსარგებლო "შეცდომით 0x00000X";

  • შედგენის დრო სურს იყოს საუკეთესო საშუალო და დიდი პროექტებისთვის;

  • თითოეული პლატფორმისთვის მობილური აპლიკაციების გასაუმჯობესებლად ფაილის გამოყენების აუცილებლობა;

  • არ არის მხარდაჭერა Intel Atom არქიტექტურისთვის;

  • არაადეკვატური ფასი კონკურენტებთან შედარებით.

Დადებითი:

  • პროდუქტის და საზოგადოების ძალიან აქტიური ბოლოდროინდელი განვითარება, უფრო და უფრო მეტი ახალი ტექნოლოგიების მხარდაჭერა;

  • დიდი რაოდენობით უფასო და კომერციული კომპონენტების არსებობა;

  • აპლიკაციის სიჩქარე ძალიან ახლოს არის მშობლიურთან;

  • ძალიან მოწინავე ვიზუალური რედაქტორი და ზოგადად გარემო, სტილის არსებობა;

  • აპლიკაციის Win-ზე ტესტირების შესაძლებლობა და მხოლოდ ამის შემდეგ განთავსება მოწყობილობებზე, რაც მნიშვნელოვნად აჩქარებს განვითარებას;

  • რეჟიმის/პლატფორმის შეცვლა მაჯის მოძრაობით;

  • PAServer უზრუნველყოფს მარტივ ურთიერთქმედებას MacO-ებთან Apple OS-ისთვის შემუშავებისას;

  • 3D გრაფიკის მხარდაჭერა ყუთიდან.

დასასრულს, მინდა ვთქვა, რომ ბოლო რამდენიმე წლის განმავლობაში FireMonkey გადაიქცა პროფესიონალურ ინსტრუმენტად ბიზნეს აპლიკაციების კროს-პლატფორმული განვითარებისთვის და არა მხოლოდ. ბევრი ხარვეზი თანდათან იხსნება და ყოველი გამოშვებით პროდუქტი უფრო თანამედროვე და თვითკმარი ხდება, ასევე ქრება თავად დელფური ენის მიმართ არსებული სკეპტიციზმი, რომელიც დაკავშირებულია მრავალწლიან სტაგნაციასთან. FireMonkey-ზე ახალი პროექტების დაწერა „უსაფრთხო“ და პერსპექტიულია.

საკმაო დრო გავიდა მას შემდეგ, რაც ტერმინი FireMonkey მეტ-ნაკლებად ნაცნობი გახდა, თუ არა ყველა დეველოპერისთვის, მაშინ მაინც მათთვის, ვინც იყენებს Delphi-ს. ამ დროის განმავლობაში, იყო წიგნები FireMonkey-ზე, სტატიები FireMonkey-ზე, ჩანაწერები FireMonkey-ის შესახებ მრავალ ბლოგზე. ამ ყველაფრის წაკითხვა ძალიან საინტერესოა. მაგრამ ვერც ერთი თეორია ვერ შეცვლის პრაქტიკას. და მე, როგორც ბევრს ადრე, მქონდა ქავილი FireMonkey-ის გამოყენებით რაღაცის დაწერა.

თუმცა, ამით პრობლემა წარმოიშვა. რატომღაც გადავწყვიტე, რომ უბრალოდ მჭირდებოდა რაიმე არც თუ ისე რთული სამუშაო პროექტის განხორციელება.

იმის ასახსნელად, თუ რატომ აღმოჩნდა ეს ჩემთვის პრობლემად, გარკვეული (დაწერა უნდა, ლირიკული) გადახვევა დასჭირდება. ექსკურსია ჩემს წარსულში, როგორც დეველოპერი. ახსენი ჩემი ზოგიერთი შეხედულება დელფის გამოყენებით პროგრამირების შესახებ.

უნდა ითქვას, რომ დელფის გამოყენება დავიწყე Windows 3.1-ზე, ანუ პირველი ვერსიიდან. და მას შემდეგ ვსწავლობ VCL-ს. სწავლობდა ორიგინალში, ასე ვთქვათ. უყურე, მიმართა, მიკვლეული წყაროს კოდები. Ისევ და ისევ.

ცნობილია, რომ სხვადასხვა დროს Delphi-თან მიწოდებული კომპონენტების ნაკრები მოიცავდა მესამე მხარის კომპონენტებს, რომლებიც უნდა შეესაბამებინათ VCL-ში არსებული ხარვეზები და რომლებიც, ალბათ, გაივლიდნენ ხარისხის კონტროლს, სანამ ჩაერთვებოდნენ. ზოგიერთი კომპონენტის მიწოდება დღემდე გრძელდება. აიღეთ იგივე ინდი. არ მინდა ვინმეს შეურაცხყოფა მივაყენო, ეს არის ჩემი პირადი აზრი, რომელიც ასევე ეხება ჩემს თავს, როგორც კომპონენტის შემქმნელს: არც ერთი ნაკრები არ ყოფილა ასე ღრმად გააზრებული და დანერგილი, ისევე როგორც უზარმაზარი და მრავალფეროვანი VCL. არა, მე არ ვაპირებ პრეტენზიას, რომ ვიყო საბოლოო სიმართლე და, რა თქმა უნდა, არის მრავალი შეცდომა თავად VCL-ში, გადაწყვეტილებები, რომლებიც იწვევს გაუგებრობას, იწვევს უარყოფას და რომელთანაც გსურთ არ დაეთანხმოთ. მაგრამ მე ყოველთვის ვიტოვებდი გარკვეული სტილის შთაბეჭდილებას. VCL-ში, ჩემი აზრით, არის ლამაზი და ძლიერი ბირთვი, რომელიც მხარს უჭერს მთელ დელფის დიზაინს და რომლის ირგვლივ აგებულია როგორც პროგრამული უზრუნველყოფის ინფრასტრუქტურა, ასევე თავად დეველოპერის საზოგადოება. დიდი ნაწილი VCL-ის წყალობით, ისევ, ჩემი აზრით, ჭორები დელფის გარდაცვალების შესახებ ჯერ კიდევ ჭორებია. და როდესაც მესამე მხარის კომპონენტები შედიოდა VCL-ის მიწოდებაში, მაშინვე შესამჩნევი იყო, ისინი განსხვავებულები იყვნენ.

მაგრამ შემდეგ მოდის მომენტი და მესმის, რომ VCL არის ტექნოლოგია, რომელიც მოძველებულია. ტექნოლოგია, რომელიც წარსულში უნდა დარჩეს. დეველოპერებმა უნდა განახორციელონ ყველა ახალი პროექტი FireMonkey-ზე, მაგრამ რაც შეეხება ძველს... კარგი იქნებოდა მათი ახალ რელსებზე გადატანა. FireMonkey არის ყველგან და ყოველთვის. და მე ეს მესმის სხვადასხვა წყაროდან. და საკმაოდ დაჟინებით. არა, VCL-ს არავინ კლავს. ის ჩვენთან რჩება. მაგრამ ის აღარ არის ნომერ პირველი. ის უნდა იყოს დამდგარი. ყოველ შემთხვევაში, მე ასე მესმის, რას ამბობენ პროდუქტის მომავალზე.

პრინციპში, მე მესმის ეს გასწორება. გავლილი იქნა კურსი მულტიპლატფორმისთვის და, რაც მთავარია, კროს პლატფორმისთვის. ბოლოს და ბოლოს, რა არის VCL? ვიზუალური კომპონენტის ბიბლიოთეკა. ვიზუალური კომპონენტების ბიბლიოთეკა. თქვენ შეიძლება არ დაეთანხმოთ ამას. მაგალითად, მე ყოველთვის განვიხილავდი უამრავ არავიზუალურ კომპონენტს და არა კომპონენტს, არამედ მხოლოდ კლასებს, VCL-ის განუყოფელ ნაწილს და მესამე მხარის კლასებსა და კომპონენტებს - გაგრძელებას, VCL-ის გაფართოებას. . ისე, მე ვერ მივიჩნევ TDataset-ის მემკვიდრეებს VCL-ის ნაწილად. მიუხედავად იმისა, რომ, მაგალითად, ტერმინი DBExpress Library ამბობს, რომ ეს არ არის VCL. როგორც ჩანს, Embarcadero ნამდვილად ყოფს მონოლითურ, ჩემი გადმოსახედიდან, VCL-ს ცალკეულ ბიბლიოთეკებად. არა, რა თქმა უნდა, არა მთლად ცალკე, მაგრამ მაინც. და თუ ამ თვალსაზრისს მიიღებთ, FireMonkey გამიზნულია VCL-ის ვიზუალური ნაწილის ჩანაცვლებისთვის (როგორ უნდა დავარქვათ სრული კლასის და კომპონენტის ბიბლიოთეკა, იქნებ Borland Component Library?).

რის გარშემოა აგებული ბიბლიოთეკის ვიზუალური კომპონენტები? ოპერაციული სისტემის მიერ მოწოდებული დაბალი დონის, ძირითადი ელემენტების ირგვლივ. ფანჯრის სახელურები, შრიფტები, თავად ფანჯრები, შეყვანის ელემენტები, შეტყობინებები, მოწყობილობის კონტექსტი და მრავალი სხვა - ეს არ არის ბიბლიოთეკის ცნებები, რომელიც მოყვება Delphi-ს, არამედ ოპერაციული სისტემის ცნებები. დიახ, ეს ასეა, Windows. და თუ გსურთ შექმნათ მრავალპლატფორმული ბიბლიოთეკა, მაშინ ლოგიკურია უარი თქვათ ოპერაციული სისტემის მიერ შემოთავაზებულ ინფრასტრუქტურაზე, რომელიც ახორციელებს ბიბლიოთეკის გამოყენებით დაწერილ პროგრამას.

ეს არის ზუსტად ის, რის გაკეთებასაც FireMonkey ცდილობს. ისინი ცდილობენ შექმნან ინფრასტრუქტურა სხვადასხვა ოპერაციული სისტემის მიერ მხარდაჭერილი ძირითადი მექანიზმების საფუძველზე, რომელსაც შეუძლია შეცვალოს სერვისი, რომელსაც თავად ოპერაციული სისტემები გვთავაზობენ.

ბევრს ახსოვს დამზადების მცდელობაcross-platform არა მხოლოდ ბიბლიოთეკა, არამედ თავად Delphi. Delphi 6-ის პარალელურად გამოიცა Kylix-ის პროდუქტი და CLX ბიბლიოთეკა. ეს ყველაფერი გაკეთდა იმისთვის, რომ შემეძლოს განვითარება Linux-ისთვის. თუმცა, Linux-ს არ აქვს ბევრი ძირითადი GUI windowing კონცეფცია, რაც Windows-ს აქვს. Linux-ის ფანჯრის ინტერფეისი ზოგადად არ არის მშობლიური ფენომენი. ეს არის არჩევითი აპლიკაცია. და მე მომიწია რაიმე სახის სინთეზური ბიბლიოთეკის დაწერა. მისი დახმარებით შესაძლებელი გახდა პროგრამის დაწერა როგორც Windows-ისთვის, ასევე Linux-ისთვის. თუმცა, მე მაინც მახსოვს ის გრძნობა და არა იმედგაცრუების, არამედ შემაშფოთებელი უხერხულობის გრძნობა, რომელიც განვიცადე, როდესაც ვცდილობდი გამომეყენებინა ვიზუალური კომპონენტების ანალოგები CLX-დან. დავიწყე ბევრი მენატრება. რასაც ვაკეთებდი დაუფიქრებლად, როდესაც ვმუშაობდი VCL-ით, რთული, ძალიან განსხვავებული ან უბრალოდ შეუძლებელი აღმოჩნდა CLX-ის გამოყენებით.

დაახლოებით იგივე ვიგრძენი BDE-დან DBExpress-ზე გადასვლისას. ძველი, ნაცნობი Field Test-a BDE-დან (შემდეგ Borland-მა უკვე გამოიყენა Quattro Pro-ში Windows-ისთვის და Paradox-ში Windows-ისთვის, და ერქვა ODAPI, შემდეგ კი IDAPI, და იყო ზემოთ მოჭრილი, ჩემი აზრით, Microsoft-ის ODBC) გამოცხადდა მოძველებული ტექნოლოგია, რომელმაც ახალ პროექტებში ადგილი უნდა დაუთმოს ახალ ბიბლიოთეკას. თავიდან ყოველთვის რაღაც მაკლდა DBExpress-ში, განსაკუთრებით ცოდნა.

ამავდროულად, მე არანაირად არ მინდა გაკიცხვა ან გავაკრიტიკო არც ზემოთ ჩამოთვლილი ბიბლიოთეკები და არც გადაწყვეტილებები, რამაც გამოიწვია მათი გამოჩენა. საუბარია მხოლოდ ჩემს შთაბეჭდილებებზე, ზოგჯერ პირველ შთაბეჭდილებებზე.

ახლა, ალბათ, ცოტა უფრო ნათელი ხდება, რატომ მოუტანა გადაწყვეტილებამ FireMonkey-ის გამოყენებით მცირე სამუშაო პროექტის დაწერა არაერთი პრობლემა. მრავალი წლის განმავლობაში, პროექტების, პროექტებისა და პროექტების შემუშავებისას ჩამოყალიბდა გარკვეული სტერეოტიპი, გარკვეული შაბლონი, თუ რა და როგორ უნდა გავაკეთოთ. ჩემს შემთხვევაში კი მომიწია ფაქტის წინაშე, რომ შაბლონი უნდა შეიცვალოს. იმის გამო, რომ თქვენ არ შეგიძლიათ გადაიტანოთ ყველაფერი, რასაც მიჩვეული ხართ VCL-ის გამოყენებას FireMonkey-ზე აგებულ პროექტზე.

პროექტის დასაწყისში მე განვიცადე დეჟავიუს გარკვეული განცდა. კერძოდ, დისკომფორტის განცდა. მაგალითად, ჩვეულებრივ შეყვანის ელემენტებს ბევრი თვისება არ გააჩნიათ. პრაქტიკაში მტკიცედ დამკვიდრებული ტრიუკები, ოპერაციული სისტემის ზოგიერთი მახასიათებლის ცოდნასთან დაკავშირებულ ხრიკებზე დაყრდნობით, ახალ კონტექსტში არ მუშაობს. რომ აღარაფერი ვთქვათ, რომ ზოგიერთი კომპონენტი რადიკალურად შეიცვალა.

კარგად, კიდევ ერთი მნიშვნელოვანი ნიუანსი. რა სახის პროექტები უნდა გაკეთდეს ჩვეულებრივ სამუშაოზე, თუ ის (სამუშაო) არ არის დაკავშირებული შემდგენელებთან, მოდელირების სისტემებთან ან რაიმე სხვა მაღალმეცნიერულ საკითხთან? ვფიქრობ, უმეტესობისთვის ეს არის ისეთი რამის შემუშავება, რომელიც მოიცავს მონაცემთა ბაზების გამოყენებას. უფრო მეტიც, რაიმე მაღალ მეცნიერულს ასევე შეუძლია გამოიყენოს DBMS-ის მიერ მოწოდებული სერვისები.

აქ კიდევ ერთი ჩასაფრება მელოდა. რატომღაც, როდესაც პრაქტიკაში შეგხვდებათ, რომ FireMonkey არ შეიცავს ელემენტებს, რომლებიც ორიენტირებულია მონაცემთა ბაზაში შენახულ მონაცემებთან მუშაობაზე, თქვენ არ ხართ ამისთვის მზად (რბილად რომ ვთქვათ). თუმცა ამის შესახებ უკვე ბევრჯერ წავიკითხე და თქვენ იცით (თეორიულად) რა უნდა გამოიყენოთ. საუბარია Live Bindings-ზე.

არ მინდა კამათში შევიდე იმის შესახებ, უნდა გამოიყენონ თუ არა რეალურმა მაგარმა პროგრამისტებმა db-aware კომპონენტები, აჩვენონ, შეცვალონ და საბოლოოდ შეინახონ. რაც, კიდევ ერთხელ, არც ცუდია და არც კარგი. უბრალოდ ასე მოხდა ჩემთვის.

ამით დასრულდა ჩემი პირველი შთაბეჭდილებების პოსტი. შემდეგი არის ისტორიები იმის შესახებ, თუ რა და როგორ გადალახეს პროექტზე მუშაობისას.