Windows 8 დეველოპერებისათვის: იმედი ბოლოს კვდება? [ნაწილი 2]

ჩინებული ახალი სამყარო

Windows-ის სემდეგ ვერსიაში იქნება პროგრამული კოდის შესრულების ორი გარემო — .Net-ის ახალი ვერსია (ჯერ-ჯერობით აღინიშნება ნომრით 4.5) და კლასიკური C++ გარემო (ტექნიკური თვალსაზრისით, ეს არის COM, ან მისი ერთგვარი წარმოებული), ახალი სახელწოდებით WinRT. ასევე ვინდოუსის ახალ ვერსიაში გამოჩნდება ჩადგმული ბიბლიოთეკა სამომხმარებლო ინტეფეისების შექმნისათვის — DirectUI — რომელიც დაფუძნებულია Direct2D და DirectWrite API-ზე, რომლებიც უკვე წარმოდგენილია Windows 7-ში. Silverlight-ის ახალი ვერსია (კოდური სახელწოდება Jupiter), როგორც ჩანს, იმუშავებს DirectUI-ს დახმარებით. WinRT-ს და DirectUI-ს პირდაპირ .Net-იდან იქნება ხელმისაწვდომი.

WinRT წარმოადგენს თანამედროვე API-ს მრავალი ფუნქციისათვის, რომლებიც ადრე Win32 API-ს წარმოადგენდა. უხეშად რომ ვთქვათ, WinRT — ეს არის ახალი Win32, რომელიც დაპროექტებულია თანამედროვე C++-იდან გამოყენებისათვის და აგრეთვე იმისათვის, რომ ლამაზად ჩაჯდეს .Net-ის კონცეფციაში. რათქმაუნდა ნაკლებ სავარაუდოა, რომ WinRT მთლიანად შეცვლის Win32-ს, რომელიც იმდენად დიდია, რომ ადვილად არ ექვემდებარება მოდერნიზაციას, მაგრამ შემდგომ ვერსიებში ეს სრულიად შესაძლებელია. WinRT-ს პოზიცია ყოველი ახალი ანწყობის შემდეგ სულ უფრო მყარდება.

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

DirectUI ეფუძნება WPF/Silverlight-ის მიმდინარე ტექნოლოგიის ქვესიმრავლეს და უზრუნველყოფს სამომხმარებლო ინტერფეისის დაკაბადონების მრავალფეროვან შესაძლებლობებს, რომლებიც Win32-ში არც არასოდეს ყოფილა. პროგრამები, რომლებიც დაწერილია C++-ზე, შეძლებენ DirectUI-ს გამოყენებას და ეს იქნება იგივე ხელსაწყო, რომელიც ექნებათ .Net-დეველოპერებს.

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

სამომხმარებლო ინტერფეისების შექმნა XAML-ის, WPF-ისა და Silverlight-ის მსგავსი ხელსაწყოებით წარმოადგენს პრიორიტეტს Microsoft-ისათვის მომავალში. ამის დასტურია კომპანიის სტრუქტურული რეორგანიზაცია, რომელიც გასულ კვირაში დაიწყო. XAML-ის დეველოპერების ჯგუფი, რომლებიც ადრე DevDiv-ში იყვნენ შეყუჟულები, სამ ნაწილად გაიყო — Windows-ის XAML-ის ჯგუფი გადავიდა WinDiv-ში, ხოლო Windows Phone, XBox-ის ჯგუფი — Windows Phone-ში. თანამშრომელთა მხოლოდ ის ჯგუფი, რომლებიც უშუალოდ მუშაობდნენ ისეთ პროდუქტზე, როგორიცაა Visual Studio და Expression Blend-ი, დაჩნენ DevDiv-ში. მაიკროსოფტის შიდა წერილი განმარტავს, რომ XAML-ის ჯგუფი მუშაობდა WinDiv-თან წლების მანძილზე Windows 8-ზე და მიმდინარე ცვლილებებმა უბრალოდ ამ საკითხის ფორმალიზება მოახდინა.

ერთიანი, თანამედროვე, უნიფიცირებული Windows API

თუ ახლა Win32/C++ და .NET-ი სრულიად სხვადასხვა პლათფორმებია, თითეული მათგანი საკუთარი შესაძლებლობებით, ახლო მომავალში ისინი ერთნაირი უნდა გახდეს. თუ მაიკროსოფტი დაამატებს ახალ API-ს Windows-ის ბირთვში, ისინი ხელმისაწვდომი გახდება კოდიდან, რაც C++-ის ნიველირებას მოახდენს .Net-თან შედარებით. მეორე მხრივ არსებული აპლიკაციები, რომლებიც დაწერილია C++-ზე, შეძლებენ გამოიყენონ ახალი სამომხმარებლო ინტერფეისი ზედმეტი დაძაბვის გარეშე. ეს აქტუალურია აგრეთვე მაიკროსოფტისათვის: ორი პლათფორმის გათანაბრება კარს უღებს .Net-აპლიკაციებს, რომლებიც სისტემაში დაემატება.

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

ჯერ-ჯერობით სრულად არ არის ცნობილი, თუ რა ბედი ელის WPF-ს. WPF-ი და Silverlight-ი მუშავდება ადამიანების ერთი ჯგუფის მიერ, მაგრამ ბაზარი Silverlight-ს აღიქვამს უფრო უკეთ, ვიდრე მის უფროსს ძმას. WPF-ს შეუძლია გააკეთოს ის, რაც არ შეუძლია silverlight-ს და სამწუხარო იქნება, თუ მის შესაძლებლობებს არ გამოიყენებენ Windows 8-ში. WPF და Silverlight ძალიან გაქვს ერთმანეთს და შესაძლოა Jupiter-მა გაერთიანოს მათი შესაძლებლობები.

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

თუმცა ჯერ არ არის ინფორმაცია იმის შესახებ, თუ რამდენად კარგად იმუშავებს ეს იდეოლოგია Windows 8-ში. Windows Phone-ის დეველოპერები ჯერ არ არიან დარწმუნებულები, რომ მათი პროდუქტები ადვილად გადავა Windows-პლანშეტებზე, განსხვავებით iOS და Android დეველოპერებისა. Windows-იც და Windows Phone-ის მხარს უჭერს Silverlight-ს, მაგრამ მობილური ტელეფონის სპეციფიკა მოითხოვს დამატებითი ფუქნციონალის არსებობას, რაც ჯერ არ არის დამატებული.

მომავლის არ გვეშინია

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

და მათ არც მოუწევთ. გსურთ ახალი აპლიკაციების წერა C++-ზე? უპრობლემოდ. გსურთ C# და Silverlight? ასევე ეს ტექნოლოგიებიც მხარდაჭერილია. იმის მაგივრად, რომ გადავყაროთ დეველოპინგის მთელი გამოცდილება წარსულში — ზუსტად ასეთი შთაბეჭდილება დარჩა ბევრს — Windows 8 გადააქცევს C++ და C# დეველოპინგის პირველხარისხოვან საშუალებებად.

რაც შეეხება HTML5 და JavaScript-ს, ისინიც იქნება მხარდაჭერილი. თუ კარგად გახსოვთ, მაიკროსოფტმა უკვე მოსინჯა ნიადაგი თავისი ტექნოლოგიით HTA (HTML Application). შესრულებადი HTA-ფაილები შედგება HTML, JavaScript, CSS და სხვა სახის შიგთავსისაგან და ეშვება განსაკუთრებულ სანდო რეჟიმში. ამის ხარჯზე ის შეზღუდვები, რაც ჰქონდა HTML-გვერდს (მაგალითად კომპიუტერის ლოკალურ რესურსებზე წვდომის შეზღუდვა), არა აქვს HTA-ს.

ახალი HTML5-აპლიკაციები არ ეფუძნება HTA-ს, მაგრამ პრინციპები ძალიან მსგავსია. როგორც HTA, HTML5-აპლიკაციები მიიღებენ უფრო მეტ შესაძლებლობას ჰქონდეთ ურთიერთქმედება ოპერაციულ სისტემასთან, ვიდრე ეს შეუძლიათ ჩვეულებრივ ვებ-გვერდებს — მათ შეეძლებათ გამოიყენონ Windows API და ჰქონდეთ ინტერფეისი, ძალიან მსგავსი ჩვეულებრივი აპლიკიციისა. საუკეთესო შემთხვევაში ისინი უნდა იყვნენ .Net-ისა და კლასიკური აპლიკაციების დონეზე, იმ განსხვავებით, რომ გამოიყენებენ HTML5-სა და JavaScript-ს დაკაბდონებისა და პროგრამირების ენად. შედეგად მივიღებთ პროგრამირების სახეს, რომელიც ზალზედ ნაცნობია ვებ-დეველოპრესებისათვის, მაგრამ ფუქნციური შეზღუდვების გარეშე.

Windows 8 — სულაც არ არის დეველოპერის კოშმარი, პირიქით, წინ გადადგმული ნაბიჯია: ნაბიჯი, რომელიც დეველოპინგს მოხერხებულს გახდის როგორც C++ და C#-ისტებისათვის, აგრეთვე ვებ-დეველოპერებისათვის. .Net-ისა და კლასკური კოდის უნიფიკაცია, სრული აპარატურული აჩქარება, თანამედროვე API, Avalon-ი, როგორც Windows-ის ინტერფეისის შექმნის ძირთადი გადაწყვეტილება — ეს ის ყველაფერია, რაც უნდა მიგვეღო Longhorn-ში და რაც შეიძლება, რომ მივიღოთ Windows 8-ში.


Comments

2 responses to “Windows 8 დეველოპერებისათვის: იმედი ბოლოს კვდება? [ნაწილი 2]”

  1. ძალიან საინტერესო იყო! ბევრი რამ გავიგე…

    1. მოხარული ვარ, რომ მოგეწონა სტატია! :)