Delphi, FireMonkey, All-Access და სხვა სასიამოვნო სიურპრიზები. Delphi, FireMonkey, All-Access და სხვა სასიამოვნო სიურპრიზები რა უნდა გაითვალისწინოთ

Viber OUT 31.10.2021
Viber OUT

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

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

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

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

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

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

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

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

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

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

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

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

გასული წლის სექტემბერში გამოშვებული Delphi XE2 შეიცავს ინოვაციების რეკორდულ რაოდენობას.
Delphi XE2-ის შესაძლებლობების მოკლე მიმოხილვები უკვე გამოქვეყნებულია Habré-ზე. მაგრამ, ცხადია, ყველაზე თვალშისაცემი ინოვაცია არის FireMonkey პლატფორმა და აქ მინდა ცოტა ყურადღება მივაქციო.
მე გავაკეთე მასალების ბმულების მცირე არჩევანი, რომელიც, იმედი მაქვს, დაგეხმარება ამ პლატფორმის მეტ-ნაკლებად ადეკვატური წარმოდგენის მიღებაში. მაგრამ ჯერ მათთვის, ვინც არ იცის, მოკლედ გეტყვით რა არის FireMonkey.
Embarcadero Technologies პოზიციონირებს FireMonkey-ს, როგორც პლატფორმას მდიდარი ბიზნეს აპლიკაციების შესაქმნელად Windows, Mac და iOS-ისთვის. უფრო მეტიც, ეს პლატფორმა მშობლიურია თითოეული OS-ისთვის, ე.ი. FireMonkey-ის გამოყენებით შექმნილი აპლიკაციის გაშვებისას, დამატებითი დანამატები არ გამოიყენება.
FireMonkey პირდაპირ აკავშირებს მშობლიურ (OS-ის პერსპექტივიდან) გრაფიკულ ბიბლიოთეკას, როგორიცაა OpenGL ან DirectX. ამრიგად, შემოთავაზებულია საუკეთესო გამოსავალი GPU-ს თვალსაზრისით.
FireMonkey არქიტექტურის ბირთვი არის კლასების მძლავრი ბიბლიოთეკა (ვიზუალური კომპონენტების ჩათვლით).
სამიზნე პლატფორმა შეირჩევა შედგენის პროცესში.
FireMonkey-ის პირველი ვერსია მხარს უჭერდა მხოლოდ Win32, Win64, MacOSX და iOS, მაგრამ Embarcadero გეგმავს მის პორტირებას რამდენიმე სხვა პლატფორმაზე მომავალში.

რა უნდა გაითვალისწინოთ?

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

იმედი მაქვს, ქვემოთ მოცემული ბმულები დაგეხმარებათ გაიგოთ ახალი პლატფორმის ძირითადი მახასიათებლები.
პროდუქტის ოფიციალური გვერდი Embarcadero ვებსაიტზე (რუსული)

ინგლისურენოვან მასალას შორის მინდა გამოვყო სერიალი (ინგლისური)

რა ვნახოთ?

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

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 ათასი დოლარის მოზიდვას გეგმავს.

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

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

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

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

რამდენიმე სიტყვა პროგრამის შესახებ. უპირველეს ყოვლისა, უნდა აღინიშნოს, რომ Sphere-ის ამჟამინდელი ვერსია ოდნავ განსხვავებულად არის განლაგებული. დიახ, ზოგჯერ ხდება ...

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

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

ბუნებრივია, სფერო იყენებს თავის მთავარ უპირატესობას FireMonkey- ჯვარედინი პლატფორმა. აპლიკაცია ამჟამად ხელმისაწვდომია Windows და MacOS ვერსიებში. ანდროიდის ვერსია ახლა ნებისმიერ დღეს არის მოსალოდნელი.

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

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

ძირითადი განსხვავებები TListView-სა და TListBox-ს შორის არის:

  1. TListBoxItem- კონტროლი, TListViewItem- არა
  2. IN TListBoxItemთქვენ შეგიძლიათ დაამატოთ ნებისმიერი კონტროლი მშობლის გამოყენებით. IN TListVIewItem- არა.
  3. TListVIewItemინახავს მხოლოდ მონაცემებს ჩვენებისთვის
  4. TListVIewItemთავად ასრულებს შენახული მონაცემების რენდერირებას მეთოდის საშუალებით რენდერი
  5. TListVIewItem-ში ფაქტობრივი ხელით ნახაზის წყალობით, მიიღწევა სიჩქარის ზრდა და მეხსიერების დაბალი მოხმარება (მხოლოდ შესაბამისი მონაცემების შენახვა)
  6. საკუთარი ვერსიის შესაქმნელად TListViewItem, თქვენ უნდა შექმნათ თქვენი ნივთის კლასი, დანერგოთ მასში საჭირო მონაცემები (მაგალითად, დრო) და შექმნათ ადგილზე რედაქტორი დროის რედაქტირებისთვის, დაარეგისტრიროთ და ა.შ.

მხოლოდ გაზრდილი შესრულების და მეხსიერების მოხმარების შემცირების ფაქტი არის დამაჯერებელი არგუმენტი გამოყენების სასარგებლოდ TListView. მაგრამ არის კიდევ რაღაც.

Ბევრში Androidგანაცხადები მე უნდა დავაკვირდე სიების შემდეგ განხორციელებას. როდესაც დააწკაპუნებთ სიის ელემენტზე (პუნქტი, თუ არჩეულ ტერმინოლოგიას დაიცავთ), შესრულებულია გარკვეული მოქმედება. როგორც წესი, ახალ ფორმას ეძახიან მონაცემთა რედაქტირებისთვის. მაგრამ როდესაც დააჭირეთ და ხანგრძლივად დააჭირეთ (ხანგრძლივი შეხება), სრულიად განსხვავებული მოქმედება შესრულებულია. და ეს მოვლენები არ იკვეთება. სხვა სიტყვებით რომ ვთქვათ, ანდროიდის აპლიკაციებს შეუძლიათ მკაფიოდ განასხვავონ „გრძელი პრესა“ და „ნორმალური“. უფრო მეტიც, არცერთი ეს მოვლენა არ ირთვება სიის გადახვევისას. კარგი მაგალითია Yandex Mail-ის ასოების სია.

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

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

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

სანამ გავაგრძელებთ ამბავს ტაიმერის შესახებ, ორი სიახლე.

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

მეორე სიახლე. Embarcadero-ს სპეციალური შეთავაზებები გაგრძელდა წლის ბოლომდე:

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

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

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

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

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

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

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

ა.ბ.– ალექსეი, ზოგადად, რა არის შენი პროექტი?

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

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

RAD Studio XE5 მსოფლიო ტურის ფარგლებში ხარკოვის ღონისძიებისთვის მომზადებისას, მე შემხვდა მცირე პრობლემასთან მუშაობისას. SQLiteგამოყენებით FireDAC. თუ Windows აპლიკაციაში შევსებული მონაცემთა ბაზა გადადის აპლიკაციასთან ერთად Android, მონაცემთა ბაზაში კირილიცას სტრიქონები აღარ იკითხება (ასოების ნაცვლად კითხვის ნიშნებია ნაჩვენები). თუმცა, თუ მონაცემთა ბაზას პირდაპირ მობილურ მოწყობილობაზე შეავსებთ, რუსული სიმბოლოები საკმაოდ სწორად იკითხება. მონაცემთა ბაზიდან, რომელიც შევსებულია მესამე მხარის აპლიკაციაში, ან ქ დელფიაპლიკაციები, რომლებიც იყენებენ სხვა მონაცემთა წვდომის კომპონენტებს, ასევე ნაჩვენები იყო ნორმალურად. შეხვედრამ გამოსავალი ვერ მოიძებნა და მე მომიწია ცნობილი უკრაინელი ფეხბურთის სპეციალისტის ციტატა: "ჩვენ გავარკვევთ!"

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

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

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

მარტივი ცხრილის მონაცემთა რედაქტორი, როგორც წესი, რთული აპლიკაციის ნაწილი. მე ჩვეულებრივ ვიყენებ ცალკე ფორმას ცხრილების რედაქტირებისთვის. დავიწყოთ სასურსათო სიით. უპირველეს ყოვლისა, ჩვენ უნდა შევქმნათ DataSet ცხრილის მონაცემებზე წვდომისთვის. ჩვენს შემთხვევაში, სავსებით შესაძლებელია კომპონენტის გამოყენება TADTable. მოვათავსოთ ის DataModule-ში და დავაზუსტოთ ქონების ღირებულება კავშირი. ქონების რედაქტორში ცხრილის სახელიგამოჩნდება ცხრილების სია, საიდანაც ვირჩევთ ცხრილს პროდუქტები. თუ ყველაფერი სწორად გააკეთეთ, შეგიძლიათ დანიშნოთ ქონება აქტიურიღირებულება True. უმჯობესია დაუყოვნებლივ გადარქმევა კომპონენტი (მაგალითად, ADTProduct). ამის შემდეგ, მე ჩვეულებრივ ვქმნი ველების ერთობლიობას DataSet-ისთვის. დარეკეთ ველის რედაქტორს (ორჯერ დააწკაპუნეთ კომპონენტზე) და აირჩიეთ "ყველა ველის დამატება" კონტექსტური მენიუდან.

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

როგორც VCL აპლიკაციის შემთხვევაში, ჩვენ კომპონენტს დავაკავშირებთ მონაცემთა ნაკრებთან TDataSource. ეს კომპონენტი უზრუნველყოფს კავშირს მონაცემთა კომპლექტსა და ვიზუალურ კონტროლს შორის. კომპონენტის DataSet თვისება უნდა მიუთითებდეს ჩვენს მონაცემთა ნაკრებზე (ADTProduct). ქვემოთ მე გთავაზობთ DFM ფაილის ფრაგმენტს

ობიექტი ADTProduct: TADTable IndexFieldNames = "ID" კავშირი = ADConnection UpdateOptions. UpdateTableName = "პროდუქტი" TableName = "პროდუქტი" მარცხნივ = ​​64 ზევით = 192 ობიექტი ADTProductID: TADAutoIncField FieldName = "ID" Origin = "ID" ProviderFlags = [pfInWhere, pfInKey] "TrueStretchTrutle"=TrueStreet itle" წარმოშობა = "სათაური" ზომა = 50 ბოლო ობიექტი dsProduct: TDataSource DataSet = ADTProduct Left = 120 ზედა = 192 დასასრული

გთხოვთ გაითვალისწინოთ ერთი საინტერესო ფუნქცია: DataModule ფორმის ფაილი ინახება არა FMX ფორმატში, როგორც ჩვეულებრივი FireMonkey ფორმატი, არამედ DFM ფორმატში, როგორც VCL-ში.

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

პროცედურა TDM. ConnectToDB; დაწყებაADConnection. Open(); ADTპროდუქტი. Open(); დასასრული ;

ჩვენ განვათავსებთ პროცედურის ზარს OnCreate მოვლენის დამმუშავებელში DataModule-ისთვის.



ჩვენ გირჩევთ წაიკითხოთ

ზედა