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

API არის ენა, რეგულირებადი გზა, რომ ერთი კომპიუტერული პროგრამა დაუკავშირდეს მეორეს, რათა ერთობლივად შეასრულონ რაიმე საერთო დავალება, როდესაც ერთი პროგრამა ასრულებს მეორის მოთხოვნებს. Application Programming Interface (API) - აპლიკაციის პროგრამირების ინტერფეისი.

ეს არის პრიმიტიული ანალოგია დუმებისთვის, რომელიც უნებურად დაიბადა.

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

1. ფრანგი

2. ესპანელი

4. ინგლისელი

5. იტალიური

მოდით გავანაწილოთ მათ შორის როლები ქვეამოცნების შესასრულებლად შემდეგნაირად:

საკვების შეძენა: ფრანგული და ესპანური

კერძების მომზადება: ესპანური, გერმანული და ინგლისური

მაგიდის გაფორმება: ინგლისური და იტალიური

კვება და გემოვნების განხილვა კერძები: ALL

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

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

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

API 1: სიტყვები პროდუქტებისთვის და სად ვიყიდოთ
API 2: სიტყვები კერძებისთვის და მომზადების მეთოდები
API 3: მოწყობილობების აღმნიშვნელი სიტყვები და მათთან მოქმედებები
API 4: საკვების გემოსა და შეფასების აღმნიშვნელი სიტყვები

ეს შეიძლება იყოს უფრო რთული, მაგალითად, დაე, API 2 იყოს თურქული, API 3 იყოს ჩინური, API 4 იყოს ჰინდი

ნიმუშების მაგალითი:

1. არის გასასვლელი. მის უკან დგას უზარმაზარი ტექნოლოგია. მაგრამ მის გამოსაყენებლად საჭიროა გქონდეთ შტეფსელი 3 სმ დაშორებით და სოკეტი მიაწვდის 220 ვოლტს. ეს არის უზარმაზარი ელექტრო წარმოების სისტემის API ინტერფეისი.

2. არის რკინა? მას აქვს მუშაობის საკუთარი რთული სისტემა. მაგრამ იმისათვის, რომ იმუშაოთ სოკეტთან, ის აკმაყოფილებს API-ს მოთხოვნებს - გჭირდებათ შტეფსელი 3 სმ მანძილით და პასუხად ელით 220 ვოლტს.

Სულ ეს არის. 2 სისტემა დამოუკიდებელია, ისინი უზარმაზარი და რთულია. მაგრამ API შექმნილია იმისთვის, რომ ერთმანეთთან დაკავშირება რაც შეიძლება მარტივი იყოს.

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

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

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

Windows API - ოპერაციული სისტემის ფუნქციების ნაკრები

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

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

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

შესაბამისად, Windows API არის ფუნქციების ერთობლიობა, რომელიც თავად ოპერაციული სისტემის ნაწილია და ამავდროულად ხელმისაწვდომია ნებისმიერი სხვა აპლიკაციისთვის, მათ შორის VB გამოყენებით დაწერილი. ამასთან დაკავშირებით, ანალოგია BIOS/DOS სისტემის შეფერხების კომპლექტთან, რომელიც რეალურად არის DOS API, საკმაოდ გამართლებულია.

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

რატომ გვჭირდება Win API VB პროგრამისტებისთვის?

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

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

1. API ფუნქციები, რომლებიც სრულად არის დანერგილი, როგორც ჩაშენებული VB ფუნქციები. მიუხედავად ამისა, ზოგჯერ ამ შემთხვევაში სასარგებლოა API-ს გამოყენებაზე გადასვლა, რადგან ამან შეიძლება ზოგჯერ მნიშვნელოვნად გააუმჯობესოს შესრულება (კერძოდ, გავლილი პარამეტრების არასაჭირო გარდაქმნების არარსებობის გამო).
2. ჩაშენებული VB ფუნქციები ახორციელებს შესაბამისი API ფუნქციის მხოლოდ სპეციალურ შემთხვევას. ეს საკმაოდ გავრცელებული ვარიანტია. მაგალითად, CreateDirectory API ფუნქციას უფრო მეტი შესაძლებლობები აქვს, ვიდრე ჩაშენებული VB MkDir ოპერატორი.
3. API ფუნქციების დიდ რაოდენობას საერთოდ არ აქვს ანალოგები VB ენის მიმდინარე ვერსიაში. მაგალითად, თქვენ არ შეგიძლიათ წაშალოთ დირექტორია VB გამოყენებით - ამისათვის თქვენ უნდა გამოიყენოთ DeleteDirectory ფუნქცია.

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

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

როგორ ვისწავლოთ Win API

ეს არც ისე მარტივი კითხვაა, თუ გავითვალისწინებთ, რომ Win32 API ფუნქციების რაოდენობა დაახლოებით 10 ათასზეა შეფასებული (ზუსტი ციფრი არავინ იცის, Microsoft-მაც კი).

VB (ვერსიები 4-6) შეიცავს ფაილს, რომელიც აღწერს Win API დეკლარაციებს - WIN32API.TXT (მისი გამოყენების შესახებ უფრო მეტს მოგვიანებით მოგიყვებით). მაგრამ, პირველ რიგში, მისი დახმარებით შეგიძლიათ მიიღოთ ინფორმაცია კონკრეტული ფუნქციის მიზნისა და მისი პარამეტრების შესახებ მხოლოდ გამოყენებული მნემონური სახელებით და მეორეც, ამ ფაილის ფუნქციების სია შორს არის დასრულებული. ერთ დროს (შვიდი წლის წინ), VB 3.0-ს ჰქონდა სპეციალური დახმარების ფაილები, რომლებიც აღწერდნენ Win16 API-ს ფუნქციებს. თუმცა, უკვე v.4.0-ში ეს სასარგებლო ინფორმაცია მოსახერხებელი ინტერფეისით გაქრა.

ყოვლისმომცველი ინფორმაცია Win32 API-ის შესახებ შეგიძლიათ იხილოთ პლატფორმის პროგრამული უზრუნველყოფის განვითარების ნაკრების დახმარებაში, რომელიც შედის MSDN ბიბლიოთეკის დისკებში, რომლებიც მოყვება VB 5.0 და 6.0 Enterprise Edition და Office 2000 Developer Edition. თუმცა იქ საჭირო ინფორმაციის მოძიება და მისი გაგება სულაც არ არის ადვილი. რომ აღარაფერი ვთქვათ, რომ იქ ყველა აღწერილობა მოცემულია C ენასთან მიმართებაში.

ცნობილი ამერიკელი ექსპერტის დანიელ ეპლმანის წიგნები მსოფლიოში საყოველთაოდ აღიარებულია VB გარემოში API პროგრამირების სწავლისთვის. მისი Dan Appleman's Visual Basic პროგრამისტის სახელმძღვანელო Windows API სერიებისთვის (Win16, Win32 და VB-ის სხვადასხვა ვერსიებისთვის) 1993 წლიდან ერთ-ერთი ყველაზე გაყიდვადი წიგნია VB პროგრამისტებისთვის. წიგნი Dan Appleman's VB 5.0 Programmer's Guide to Win32 API, რომელიც გამოვიდა 1997 წელს, ავტორს აშშ-დან მიუტანა მეგობარმა, რომელმაც იპოვა იგი პატარა პროვინციული ქალაქის პირველ წიგნის მაღაზიაში.

ეს წიგნი 1500-ზე მეტი გვერდია, რომელიც მოიცავს API პროგრამირების ზოგად ტექნიკას VB-ში, ასევე 900-ზე მეტ ფუნქციას. ჩართული CD შეიცავს წიგნის სრულ ტექსტს და პროგრამის ყველა მაგალითს, ასევე რამდენიმე დამატებით თავს, რომელიც არ შედის ბეჭდურ ვერსიაში. 1999 წელს დენ ეპლმანმა გამოუშვა ახალი წიგნი, Dan Appleman's Win32 API თავსატეხი და სახელმძღვანელო Visual Basic პროგრამისტებისთვის, რომელიც შეიცავს ინფორმაციას კიდევ 7600 ფუნქციის შესახებ (თუმცა არც ისე ვრცელი).

Win API და დინამიური ბმული ბიბლიოთეკა (DLL)

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

ამ შემთხვევაში, DLL-ში ვგულისხმობთ ორობითი დინამიური ბიბლიოთეკების ტრადიციულ ვერსიას, რომელიც უზრუნველყოფს აპლიკაციებს პირდაპირ წვდომას აუცილებელ პროცედურებზე - ქვეპროგრამებზე ან ფუნქციებზე (ისევე როგორც ხდება VB პროექტის შიგნით პროცედურების გამოძახებისას). ასეთი ბიბლიოთეკების შექმნა შესაძლებელია სხვადასხვა ხელსაწყოების გამოყენებით: VC++, Delphi, Fortran, გარდა VB (ვნახოთ, რა ჩანს 7.0 ვერსიაში) - ამ უკანასკნელს შეუძლია შექმნას მხოლოდ ActiveX DLL-ები, რომელთა წვდომა შესაძლებელია OLE Automation ინტერფეისით.

როგორც წესი, დინამიური ბიბლიოთეკის ფაილებს აქვთ გაფართოება .DLL, მაგრამ ეს საერთოდ არ არის საჭირო (Win16-ისთვის ხშირად იყენებდნენ გაფართოებას .EXE); გარე მოწყობილობის დრაივერები მითითებულია .DRV-ის გამოყენებით.

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

და ახლა რამდენიმე რჩევა.

რჩევა 1. დარწმუნდით, რომ თქვენი DL რეკლამა სწორად არის ფორმატირებული L- პროცედურები

პროგრამაში DLL პროცედურების გამოძახება ზუსტად ისე გამოიყურება, როგორც Visual Basic-ის „ჩვეულებრივი“ პროცედურები, მაგალითად:

დარეკეთ DllName ([არგუმენტების სია])

თუმცა, გარე DLL ფუნქციების გამოსაყენებლად (მათ შორის Win API), ისინი უნდა გამოცხადდეს პროგრამაში Declare განაცხადის გამოყენებით, რომელიც ასე გამოიყურება:

გამოაცხადეთ Sub LibProcedureName _ “LibraryName” _ [([ArgumentList])]

გამოაცხადეთ ფუნქცია FunctionName _ Lib “LibraryName” _ [([ArgumentList])]

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

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

Win32 API კომპლექტი განხორციელებულია მხოლოდ ფუნქციების სახით (Win16 API-ს ჰქონდა მრავალი Sub-რუტინი). უმეტესწილად, ეს არის Long ტიპის ფუნქციები, რომლებიც ყველაზე ხშირად აბრუნებენ ოპერაციის დასრულების კოდს.

Declare ოპერატორი გამოჩნდა MS Basic-ში ჯერ კიდევ DOS-ის დღეებში და ის ასევე გამოიყენებოდა შიდა პროექტის პროცედურების დეკლარაციისთვის. Visual Basic-ში ეს არ არის საჭირო, რადგან შიდა პროცედურების დეკლარაცია ავტომატურად არის მათი ქვე ან ფუნქციის დეკლარაცია. Basic/DOS-თან შედარებით, ახალ აღწერილობაში უნდა იყოს მითითებული ბიბლიოთეკის ფაილის სახელი, სადაც განთავსებულია საჭირო პროცედურა. Wip API ბიბლიოთეკები განლაგებულია Windows სისტემის დირექტორიაში, ამიტომ საკმარისია მიუთითოთ მხოლოდ ფაილის სახელი. თუ თქვენ წვდებით DLL-ს, რომელიც მდებარეობს შემთხვევით ადგილას, თქვენ უნდა ჩაწეროთ ამ ფაილის სრული გზა.

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

გამოაცხადეთ ფუნქცია GetTempPath _ Lib "kernel32" მეტსახელი "GetTempPathA" _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) როგორც ხანგრძლივი

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

რჩევა 2: განსაკუთრებით ფრთხილად იყავით DLL ფუნქციებთან მუშაობისას

Win API და სხვადასხვა DLL ფუნქციების გამოყენება მნიშვნელოვნად აფართოებს VB-ის ფუნქციონირებას და ხშირად აუმჯობესებს პროგრამის მუშაობას. თუმცა, ამაში გადასახდელი ფასი არის აპლიკაციის სანდოობის შემცირების რისკი, განსაკუთრებით მისი გამართვის დროს.

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

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

პრობლემას კიდევ უფრო ამძიმებს ის ფაქტი, რომ სხვადასხვა პროგრამირების ენა იყენებს პროცედურებს შორის პარამეტრების გადაცემის სხვადასხვა ხერხს. (უფრო ზუსტად, ნაგულისხმევად გამოიყენება გავლის სხვადასხვა მეთოდი, რადგან ბევრ ენას შეუძლია მრავალი მეთოდის მხარდაჭერა.) Win API-ები დანერგილია C/C++-ში და იყენებენ C/C++ პარამეტრის გადაცემის კონვენციებს, რომლებიც განსხვავდება ჩვეულებრივი VB ვერსიისგან.

ამასთან დაკავშირებით, უნდა აღინიშნოს, რომ VB-ში ჩაშენებული API ფუნქციების ანალოგების გამოჩენა გამართლებულია სწორედ ამ უკანასკნელის VB სინტაქსის ადაპტაციით და მონაცემთა გაცვლის შესაბამისი კონტროლის მექანიზმის დანერგვით. აქვე აღვნიშნოთ, რომ აპლიკაციის ექსპერიმენტული გამართვის ეტაპზე შესრულებადი მოდულის შექმნისას უმჯობესია გამოვიყენოთ P-კოდის კომპილაციის ვარიანტი Native Code-ის (მანქანის კოდი) ნაცვლად. პირველ შემთხვევაში, პროგრამა იმუშავებს თარჯიმანის კონტროლის ქვეშ - უფრო ნელი ვიდრე მანქანის კოდს, მაგრამ უფრო საიმედო ოპერაციულ სისტემაზე შესაძლო მცდარი ზემოქმედების თვალსაზრისით და უზრუნველყოფს უფრო მოსახერხებელი რეჟიმის იდენტიფიცირებისთვის შესაძლო შეცდომები.

რჩევა 3: დენ ეპლმენის ათი რჩევა ძლიერი API პროგრამირებისთვის VB-ში

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

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

ეს მაგალითები აჩვენებს ByVal ოპერატორის გავლენას პარამეტრის გადაცემაზე

პარამეტრის ტიპი	ByVal-თან ერთად	ByVal-ის გარეშე
მთელი რიცხვი	16-ბიტიანი მთელი რიცხვი გადადის სტეკზე	16-ბიტიანი მთელი რიცხვის 32-ბიტიანი მისამართი გადადის სტეკზე
გრძელი	32-ბიტიანი მთელი რიცხვი გადადის სტეკზე	32-ბიტიანი მთელი რიცხვის 32-ბიტიანი მისამართი გადადის სტეკზე
სიმებიანი	სტრიქონი გარდაიქმნება C-ში გამოყენებულ ფორმატში (მონაცემები და დამთავრებული null ბაიტი). ახალი ხაზის 32-ბიტიანი მისამართი გადადის სტეკზე	VB სახელური სტრიქონზე მიდის დასტაზე. (ასეთ სახელურებს არასოდეს იყენებს თავად Windows API და მხოლოდ VB-სთვის დანერგილ DLL-ებშია აღიარებული.)

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

ამის გასაგებად, ჩაატარეთ ექსპერიმენტი შემდეგი პროგრამების გამოყენებით:

Dim v როგორც მთელი რიცხვი v = 2 გამოძახება MyProc(v) MsgBox “v = “ & v Sub MyProc (v როგორც მთელი რიცხვი) v = v + 1 ბოლო Sub

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

Sub MyProc (ByVal v როგორც მთელი რიცხვი)

შედეგად, ტესტის შესრულებისას მიიღებთ v=2, რადგან პროცედურას გადაეცემა მხოლოდ ცვლადის საწყისი მნიშვნელობა - მასთან შესრულებული ოპერაციების შედეგი არ ბრუნდება გამოძახების პროგრამაში. გადაცემის რეჟიმი მნიშვნელობის მიხედვით ასევე შეიძლება შეიცვალოს Call ოპერატორის გამოყენებით შემდეგნაირად:

Sub MyProc (v როგორც მთელი რიცხვი) ... Call MyProc((v)) ‘ (v) - ფრჩხილებში მითითებულია გადაცემის რეჟიმი მნიშვნელობის მიხედვით.

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

კლასიკურ შემთხვევაში (C, Fortran, Pascal) ByRef და ByVal რეჟიმებს შორის სხვაობა დამოკიდებულია იმაზე, თუ რა არის განთავსებული მონაცემთა გაცვლის სტეკზე - ცვლადის მისამართი თუ მისი მნიშვნელობა. Basic ისტორიულად იყენებს ByVal პროგრამული ემულაციის ვარიანტს - დასტაზე ყოველთვის არის მისამართი, მაგრამ მხოლოდ მნიშვნელობის გადაცემისას იქმნება დროებითი ცვლადი ამისათვის. ამ ორი ვარიანტის (კლასიკური და ძირითადი) გასასხვავებლად გამოიყენება ByVal რეჟიმის აღწერის სხვადასხვა ხერხი. გაითვალისწინეთ, რომ ByVal რეჟიმის ემულაცია VB-ში უზრუნველყოფს პროგრამის უფრო მაღალ სანდოობას: მითითების ფორმის შერევით, პროგრამისტი რისკავს მხოლოდ, რომ ცვლადის შესწორებული მნიშვნელობა დაუბრუნდეს (ან არ დაბრუნდეს) გამოძახების პროგრამაში. "კლასიკურ" ვერსიაში ასეთმა დაბნეულობამ შეიძლება გამოიწვიოს ფატალური შეცდომა პროცედურის შესრულებისას (მაგალითად, როდესაც მეხსიერების მისამართის ნაცვლად გამოიყენება ცვლადის მნიშვნელობა, რომელიც ტოლია, ვთქვათ, ნულს).

DLL ფუნქციები განხორციელებულია „კლასიკური“ პრინციპების მიხედვით და, შესაბამისად, მოითხოვს სავალდებულო აღწერას, თუ როგორ ხდება მონაცემთა გაცვლა თითოეულ არგუმენტთან. ამ მიზანს ემსახურება ფუნქციების დეკლარაციები Declare აღწერის საშუალებით (უფრო ზუსტად, მიღებული არგუმენტების ჩამონათვალი). Windows API ფუნქციაზე ან DLL-ზე პარამეტრების გადაცემის ყველაზე გავრცელებული გზა არის ByVal საკვანძო სიტყვის გამოყენება. უფრო მეტიც, მისი დაზუსტება შესაძლებელია როგორც Declare ოპერატორში, ასევე უშუალოდ ფუნქციის გამოძახებისას.

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

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

3. შეამოწმეთ დაბრუნების ტიპი.

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

• DLL ფუნქცია, რომელიც არ აბრუნებს მნიშვნელობას (ანალოგური void-ის 'C'-ში) უნდა გამოცხადდეს VB Sub.
• API ფუნქცია, რომელიც აბრუნებს მთელ მნიშვნელობას (მთლიანი ან გრძელი) შეიძლება განისაზღვროს როგორც Sub ან ფუნქცია, რომელიც აბრუნებს შესაბამისი ტიპის მნიშვნელობას.
• არცერთი API ფუნქცია არ აბრუნებს მცურავი წერტილის რიცხვებს, მაგრამ ზოგიერთ DLL-ს შეუძლია დააბრუნოს ამ ტიპის მონაცემები.

4. გამოიყენეთ "როგორც ნებისმიერი" კონსტრუქცია დიდი სიფრთხილით. Windows API-ს ბევრ ფუნქციას აქვს სხვადასხვა ტიპის პარამეტრების მიღების შესაძლებლობა და ამისათვის გამოიყენოს როგორც ნებისმიერი კონსტრუქცია (ტიპის ინტერპრეტაცია ხორციელდება სხვა გადაცემული პარამეტრების მნიშვნელობიდან გამომდინარე).

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

5. არ დაგავიწყდეთ სტრიქონების ინიციალიზაცია. Win API-ში ბევრი ფუნქციაა, რომლებიც აბრუნებენ ინფორმაციას პარამეტრად გადაცემულ სტრიქონულ ბუფერებში მონაცემების ჩატვირთვით. თქვენს პროგრამაში, როგორც ჩანს, შეგიძლიათ გააკეთოთ ყველაფერი სწორად: არ დაივიწყოთ ByVal, სწორად გადასცეთ პარამეტრები ფუნქციას. მაგრამ Windows ვერ ამოწმებს, რამდენად დიდია რიგისთვის გამოყოფილი მეხსიერების ზომა. მწკრივის ზომა უნდა იყოს საკმარისად დიდი, რათა განთავსდეს ყველა მონაცემი, რომელიც შეიძლება განთავსდეს მასში. საჭირო ზომის ბუფერის დაჯავშნაზე პასუხისმგებლობა ეკისრება VB პროგრამისტს.

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

ყველაზე ხშირად, Win API ფუნქციები საშუალებას გაძლევთ თავად განსაზღვროთ ბლოკის მაქსიმალური ზომა. კერძოდ, ზოგჯერ ეს მოითხოვს სხვა API ფუნქციის გამოძახებას, რომელიც „გეტყვის“ ბლოკის ზომას. მაგალითად, GetWindowTextLength გაძლევთ საშუალებას განსაზღვროთ ხაზის სიგრძე, რომელიც საჭიროა GetWindowText ფუნქციით დაბრუნებული ფანჯრის სათაურის შესანახად. ამ შემთხვევაში, Windows უზრუნველყოფს, რომ არ გადალახოთ ზღვარი.

6. დარწმუნდით, რომ გამოიყენეთ Option Explicit.

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

Windows 9x-მა გააუმჯობესა პარამეტრების შემოწმება API ფუნქციების უმეტესობისთვის. ამიტომ, შეცდომის არსებობა მონაცემებში, როგორც წესი, არ იწვევს ფატალურ შეცდომას, მაგრამ იმის დადგენა, თუ რამ გამოიწვია ის, არც ისე ადვილია.

აქ ჩვენ გირჩევთ გამოიყენოთ რამდენიმე გზა ამ ტიპის შეცდომის გამართვისთვის:

• გამოიყენეთ ნაბიჯ-ნაბიჯ გამართვის რეჟიმი ან Debug.Print ბრძანება API ფუნქციის ყოველი საეჭვო ზარის შესამოწმებლად. შეამოწმეთ ამ ზარების შედეგები, რათა დარწმუნდეთ, რომ ყველაფერი ნორმალურია და ფუნქცია სწორად არის დასრულებული;
• გამოიყენეთ Windows-ის გამართვა, როგორიცაა CodeView და Windows-ის გამართვის ვერსია (ხელმისაწვდომია Windows SDK-ში). ამ ინსტრუმენტებს შეუძლიათ პარამეტრის შეცდომის დადგენა და მინიმუმ იმის დადგენა, თუ რომელი API ფუნქცია იწვევს შეცდომას;
• გამოიყენეთ მესამე მხარის დამატებითი ხელსაწყოები პარამეტრების ტიპების და მათი მნიშვნელობების მართებულობის შესამოწმებლად. ასეთ ხელსაწყოებს შეუძლიათ არა მხოლოდ პარამეტრის შეცდომის პოვნა, არამედ მიუთითებენ VB კოდის ხაზზე, სადაც მოხდა შეცდომა.

გარდა ამისა, აუცილებელია API ფუნქციის შესრულების შედეგის შემოწმება.

8. გახსოვდეთ, რომ VB-ში და Windows-ში მთელი რიცხვები არ არის იგივე.უპირველეს ყოვლისა, უნდა გაითვალისწინოთ, რომ ტერმინი "Integer" VB-ში ნიშნავს 16-ბიტიან რიცხვს, ხოლო Win 32 დოკუმენტაციაში - 32-ბიტიან რიცხვს. მეორეც, მთელი რიცხვები (მთლიანი და გრძელი) VB-ში არის ხელმოწერილი რაოდენობები (ანუ ერთი ციფრი გამოიყენება როგორც ნიშანი, დანარჩენი, როგორც რიცხვის მანტისა), Windows-ში გამოიყენება მხოლოდ არაუარყოფითი რიცხვები. ეს გარემოება მხედველობაში უნდა იქნას მიღებული, როდესაც არითმეტიკული ოპერაციების გამოყენებით აყალიბებთ გავლილ პარამეტრს (მაგალითად, მისამართის გამოთვლა ზოგიერთი ბაზის და ოფსეტურის შეჯამებით). სტანდარტული VB არითმეტიკული ფუნქციები ამისათვის არ არის შესაფერისი. რა უნდა გავაკეთოთ ამ შემთხვევაში ცალკე განვიხილავთ.

9. დიდი ყურადღება მიაქციეთ ფუნქციების სახელებს. Win16-ისგან განსხვავებით, ყველა Win32 API ფუნქციის სახელები მგრძნობიარეა მცირე და დიდი ასოების ზუსტი გამოყენების მიმართ (ეს ასე არ იყო Win16-ში). თუ სადმე იყენებთ პატარა ასოს დიდის ნაცვლად ან პირიქით, მაშინ სასურველი ფუნქცია ვერ მოიძებნება. ასევე ფრთხილად იყავით A ან W სუფიქსის სწორად გამოყენება ფუნქციებში, რომლებიც იყენებენ სტრიქონების პარამეტრებს. (დაწვრილებით ამის შესახებ იხილეთ ქვემოთ.)

10. ხშირად დაზოგე სამუშაო. DLL-ების და Win API-ების არასწორ გამოყენებასთან დაკავშირებულმა შეცდომებმა შეიძლება გამოიწვიოს VB გარემოს და, შესაძლოა, მთელი ოპერაციული სისტემის გადაუდებელი შეწყვეტა. თქვენ უნდა დარწმუნდეთ, რომ თქვენს მიერ დაწერილი კოდი შენახულია ტესტირების დაწყებამდე. უმარტივესი რამ არის პროექტის მოდულების ავტომატური ჩაწერის რეჟიმის დაყენება VB გარემოში პროექტის დაწყებამდე.

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

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

1. Win32 API ფუნქციები სწორედ ეს არის: ფუნქციები, ანუ ფუნქციის ტიპის პროცედურები (Win16 API-ში იყო ბევრი Sub-რუტინი). ყველა ეს არის Long ტიპის ფუნქციები, ამიტომ მათი აღწერილობები იწერება შემდეგი ფორმით: გამოაცხადეთ ფუნქციის სახელი ... როგორც Long 'ფუნქციის ტიპი _ ცალსახად არის განსაზღვრული.

   Declare Function name& ‘ფუნქციის ტიპი _ განისაზღვრება სუფიქსის გამოყენებით

   API ფუნქციის ზარი ასე გამოიყურება:

შედეგი& = ApiName& ([ არგუმენტების სია]

1. ყველაზე ხშირად, ფუნქციის დაბრუნების მნიშვნელობა არის ოპერაციის დასრულების კოდი. უფრო მეტიც, არანულოვანი მნიშვნელობა ამ შემთხვევაში ნიშნავს ნორმალურ დასრულებას, ნული ნიშნავს შეცდომას. ჩვეულებრივ (მაგრამ არა ყოველთვის) შეცდომის ხასიათის გარკვევა შეგიძლიათ GetLastError ფუნქციის გამოძახებით. ამ ფუნქციის აღწერა ასე გამოიყურება: გამოაცხადეთ ფუნქცია GetLastError& Lib „kernel32“ ()

   ყურადღება! VB-ში მუშაობისას უმჯობესია გამოვიყენოთ Err ობიექტის LastDLLError თვისება, რომ მიიღოთ კვალიფიციური შეცდომის კოდის მნიშვნელობა, ვინაიდან VB ზოგჯერ აღადგენს GetLastError ფუნქციას API-ს გამოძახებასა და პროგრამის შესრულების გაგრძელებას შორის.

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

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

   • ERROR_INVALID_HANDLE = 6& - არასწორი სახელური
   • ERROR_CALL_NOT_IMPLEMENTED = 120& - Windows 9x ფუნქციის გამოძახება, რომელიც ხელმისაწვდომია მხოლოდ Windows NT-ისთვის
   • ERROR_INVALID_PARAMETER = 87& - არასწორი პარამეტრის მნიშვნელობა

   თუმცა, ბევრი ფუნქცია აბრუნებს ზოგიერთი მოთხოვნილი პარამეტრის მნიშვნელობას (მაგალითად, OpenFile აბრუნებს ფაილის სახელურის მნიშვნელობას). ასეთ შემთხვევებში, შეცდომა განისაზღვრება სხვა სპეციალური Return& მნიშვნელობით, ყველაზე ხშირად 0 ან –1.

2. Win32 API იყენებს მკაცრად ფიქსირებულ გზებს მონაცემთა უმარტივესი ტიპების გადასატანად. ა) ByVal... როგორც დიდხანს

   არგუმენტების გადაცემის მინიმუმ 80% ხორციელდება Long ცვლადების გამოყენებით. გაითვალისწინეთ, რომ არგუმენტი ყოველთვისთან ახლავს ByVal საკვანძო სიტყვა და ეს, სხვა საკითხებთან ერთად, ნიშნავს, რომ ხდება მონაცემთა ცალმხრივი გადაცემა - VB პროგრამიდან API ფუნქციამდე.

   ბ) ByVal... როგორც სტრინგი

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

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

   WinPath$ = Space$(144) ' დაჯავშნე _ 144 სიმბოლოანი სტრიქონი Result& = GetWindowsDirectory& (WinTath$, 144) _ ' შეავსე ბუფერი ' Result& - სიმბოლოების რეალური რაოდენობა _ დირექტორიას სახელში WinPath$ = Left$(WinPath , შედეგი &)

   მეორე პრობლემა არის ის, რომ API ფუნქციის გამოძახებისას, წყაროს სტრიქონი გარდაიქმნება რაიმე შიდა წარმომადგენლობაში, ხოლო ფუნქციიდან გასვლისას, პირიქით. თუ Win16-ის დღეებში ეს ოპერაცია შედგებოდა მხოლოდ სტრიქონის ბოლოს ნულოვანი ბაიტის დამატებისგან, მაშინ Win32-ის მოსვლასთან ერთად ამას დაემატა ორმაგი ბაიტიანი Unicode კოდირების ტრანსფორმაცია ANSI-ში და პირიქით. (ეს დეტალურად იყო განხილული სტატიაში "VB-ში სიმებიანი ცვლადებთან მუშაობის თავისებურებები", ComputerPress 10'99 და 01'2000). ახლა, მოდით, მხოლოდ აღვნიშნოთ, რომ ByVal-ის გამოყენებით ... როგორც String კონსტრუქცია, თქვენ შეგიძლიათ გაცვალოთ სტრიქონები მხოლოდ სიმბოლოების მონაცემებით.

   ბ) ...როგორც ნებისმიერი

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

   დ) ... როგორც UserDefinedType

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

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

API ფუნქციის გამოძახების მაგალითი

მოდით ავხსნათ ზემოთ აღნიშნული ფაილებთან მუშაობისთვის ორი სასარგებლო ფუნქციის გამოყენების მაგალითის გამოყენებით - lopen და lread, რომლებიც აღწერილია შემდეგნაირად:

გამოაცხადეთ ფუნქცია lopen Lib "kernel32" _ მეტსახელი "_lopen" (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) როგორც Long გამოაცხადეთ ფუნქცია lread Lib "kernel32" _ მეტსახელი "_lread" (_ ByVal Long, h File As lpBuffer As Any, _ ByVal wBytes As Long) As Long

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

ფაილის გახსნის ოპერაცია შეიძლება ასე გამოიყურებოდეს:

Const INVALID_HANDLE_VALUE = -1 ' არასწორი _ აღწერის მნიშვნელობა lpFileName$ = “D:\calc.bas” ' ფაილის სახელი wReadWrite& = 2 ' წაკითხვის-ჩაწერის რეჟიმი hFile& = lopen(lpFileName$, wReadWrite&) _ან განსაზღვროს ფაილი&h INVALID_HANDLE_VALUE შემდეგ _ ' ფაილის გახსნის შეცდომა ' მიუთითეთ შეცდომის კოდი CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' ეს კონსტრუქცია არ მუშაობს დასრულება თუ

აქ ყურადღება უნდა მიაქციოთ ორ პუნქტს:

• როგორც ფუნქციის მნიშვნელობა ვიღებთ ფაილის აღწერის მნიშვნელობას. შეცდომა შეესაბამება -1 მნიშვნელობას;
• სწორედ ამ შემთხვევაში არ მუშაობს GetLastError ფუნქციის გამოძახება - შეცდომის დახვეწილი მნიშვნელობის მისაღებად მივმართეთ Err ობიექტს (ასეთი სიტუაციის შესაძლებლობაზე ზემოთ ვისაუბრეთ).

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

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' კითხულობს რეალურ რიცხვს, 4 ბაიტი' wBytes არის რეალურად წაკითხული მონაცემების რაოდენობა, ' -1 არის შეცდომა... ჩაწერეთ MyStruct x As Single i As მთელი რიცხვის ბოლოს ტიპი Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' წაკითხული მონაცემთა სტრუქტურა, 6 ბაიტი

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

Dim MyVar As String MyVar = Space$(10) ‘დაჯავშნე ცვლადი 10 სიმბოლოსთვის wBytes = lread (hFile&, ByVal MyVar, Len(MyVar))’ წაიკითხე სიმბოლოების სტრიქონი, 10 სიმბოლო

აქ შეგიძლიათ იხილოთ მნიშვნელოვანი განსხვავება წინა მაგალითისგან - string ცვლადს აუცილებლად ახლავს ByVal საკვანძო სიტყვა.

ფაილის შიგთავსის წაკითხვა მასივში (სიმარტივისთვის გამოვიყენებთ ერთგანზომილებიან ბაიტის მასივს) შემდეგნაირად ხდება:

Dim MyArray(1-დან 10-მდე) როგორც ბაიტი wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ‘ წაიკითხავს მასივის 10 ელემენტს

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

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ‘ წაიკითხეთ მასივის ელემენტები 4-დან 8-მდე

რჩევა 5: გამოიყენეთ მეტსახელი Gears-ისთვისდა პარამეტრები როგორც ნებისმიერი

აქ, წინა მაგალითზე დაყრდნობით, გამოვავლენთ დენ ეპლმენის მეოთხე რჩევის არსს.

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

გამოაცხადეთ ფუნქცია lreadString Lib "kernel32" _ მეტსახელი "_lread" (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long)

ამ აღწერილობასთან მუშაობისას, თქვენ აღარ გჭირდებათ ByVal-ის მითითება:

WBytes = lreadString(hFile&, MyVarString, _ Len(MyVarString)) '

როგორც ჩანს, Declare ოპერატორის სინტაქსი საშუალებას გაძლევთ გააკეთოთ მსგავსი სპეციალური აღწერა მასივისთვის:

გამოაცხადეთ ფუნქცია lreadString Lib „kernel32“ მეტსახელად „_lread“ (_ ByVal hFile As Long, lpBuffer() როგორც Byte, _ ByVal wBytes As Long)

თუმცა, მიმართვა

WBytes = lreadArray(hFile&, MyArray(), 10)

გარდაუვალად იწვევს პროგრამის ფატალურ შეცდომას.

ეს არის საუბრის გაგრძელება Visual Basic-ში სიმებიანი ცვლადების დამუშავების თავისებურებებზე: VB იყენებს ორბაიტიან Unicode კოდირებას, Win API იყენებს ერთბაიტიან ANSI-ს (და C-ში მიღებული ფორმატით - ბოლოს ნულოვანი ბაიტით) . შესაბამისად, სიმებიანი ცვლადების არგუმენტად გამოყენებისას, კონვერტაცია Unicode-დან ANSI-ზე ყოველთვის ავტომატურად ხდება API ფუნქციის (უფრო ზუსტად, DLL ფუნქციის) გამოძახებისას და საპირისპირო კონვერტაცია დაბრუნებისას.

ამისგან გამოსავალი მარტივია: სიმებიანი ცვლადები შეიძლება გამოყენებულ იქნას სიმბოლოების მონაცემების გასაცვლელად, მაგრამ მათი გამოყენება არ შეიძლება თვითნებური ორობითი ინფორმაციის გასაცვლელად (როგორც ეს იყო VB-ის 16-ბიტიანი ვერსიების შემთხვევაში). ამ უკანასკნელ შემთხვევაში, უმჯობესია გამოიყენოთ ერთგანზომილებიანი ბაიტის მასივი.

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

• კატეგორიულად აკრძალულია შემდეგი კონსტრუქციის გამოყენება Win API-ზე წვდომისთვის: ჩაწერეთ MyStruct x As Single s As String ‘ცვლადი სიგრძის სტრიქონის ბოლო ტიპი

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

• თქვენ შეგიძლიათ გამოიყენოთ ფიქსირებული სიგრძის სტრიქონი, როგორც სტრუქტურის ელემენტი: Type MyStruct x As Single s As String*8 ‘ ფიქსირებული სიგრძის სტრიქონი ბოლოს ტიპი

ამ შემთხვევაში, შესაბამისი კოდირების კონვერტაცია ხორციელდება.

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

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

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

ავტორის აზრი ასეთია: ნებისმიერი სერიოზული პროგრამირება მოითხოვს დეველოპერს მინიმუმ ორი ინსტრუმენტის ცოდნა. რა თქმა უნდა, შრომის მკაფიო დანაწილების თანამედროვე პირობებში ძალიან ძნელია იყო შესანიშნავი ექსპერტი ორ სისტემაშიც კი, ამიტომ „მთავარი და დამხმარე ენების“ სქემა უფრო ლოგიკურია. აქ იდეა ისაა, რომ „დამხმარე“ ენის ზედაპირულმა ცოდნამაც კი (საკმაოდ მარტივი პროცედურების წერა) შეიძლება მნიშვნელოვნად გააუმჯობესოს „მთავარი“ ენის გამოყენების ეფექტურობა. გაითვალისწინეთ, რომ VB-ის ცოდნა, ყოველ შემთხვევაში, როგორც დამხმარე, დღეს თითქმის სავალდებულო მოთხოვნაა პროფესიონალი პროგრამისტისთვის. სხვათა შორის, DOS-ის დღეებში Assembler-ის საფუძვლების ცოდნა უაღრესად სასურველი იყო ნებისმიერი პროგრამისტისთვის, მათ შორის Basic-ისთვის.

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

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

• სხვადასხვა ენას შეუძლია გამოიყენოს სხვადასხვა კონვენცია იდენტიფიკატორების დასაწერად. მაგალითად, ჩვეულებრივია ქვედა ხაზის გამოყენება პროცედურის სახელის დასაწყისში, რაც დაუშვებელია VB-ში. ეს პრობლემა მარტივად მოგვარებულია ალიასის საკვანძო სიტყვის გამოყენებით Declare განცხადებაში (იხ. მაგალითი რჩევა 2.3).
• დასტაზე გადაცემული არგუმენტების ჩაწერის განსხვავებული თანმიმდევრობის გამოყენება შეიძლება. მაგალითად, DOS-ის დღეებში (გულწრფელად ვაღიარებ, არ ვიცი როგორ გამოიყურება ახლა Windows-ის გარემოში), C წერდა არგუმენტებს სიის ბოლოდან, სხვა ენებზე (Fortran, Pascal, Basic) - თავიდანვე.
• ნაგულისხმევად, გამოიყენება პარამეტრების გადაცემის სხვადასხვა პრინციპი - მითითებით ან მნიშვნელობით.
• სიმებიანი ცვლადების შენახვის სხვადასხვა პრინციპი. მაგალითად, C-ში (ისევე როგორც Fortran-სა და Pascal-ში), სტრიქონის სიგრძე განისაზღვრება მისი ბოლოში არსებული null ბაიტით, მაგრამ Basic-ში სიგრძე ცალსახად იწერება სტრიქონის აღმწერში. რა თქმა უნდა, თქვენ უნდა გაითვალისწინოთ სხვადასხვა სიმბოლოების კოდირების გამოყენების შესაძლებლობა.
• მრავალგანზომილებიანი მასივების გადაცემისას უნდა გახსოვდეთ, რომ შესაძლებელია მრავალგანზომილებიანი სტრუქტურების ერთგანზომილებიანად გადაქცევის სხვადასხვა ვარიანტები (პირველი ინდექსიდან დაწყებული ან ბოლოდან, ორგანზომილებიანი მასივების მიმართ - "სტრიქონების მიხედვით" ან "სვეტების მიხედვით" ).

ყოველივე ამის გათვალისწინებით, შეიძლება ჩამოყალიბდეს შემდეგი რეკომენდაციები:

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

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

ასე რომ: გამოიყენეთ DLL ფუნქციები. მაგრამ იყავი ფხიზლად...

ComputerPress 9"2000

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

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

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

შედეგად, ჩვენ ვიღებთ აპლიკაციის განვითარების შემდეგ მეთოდოლოგიას:

1. ჩვენ ვსწავლობთ სამიზნე აუდიტორიას - Android-ის რომელი ვერსიაა დაინსტალირებული მათ სმარტფონებზე. თუ ჩვენ ვწერთ ყველასთვის, სასარგებლო იქნება გაეცნოთ სისტემის ამა თუ იმ ვერსიის გამოყენების მუდმივად განახლებულ გრაფიკებს მობილურ მოწყობილობებზე: http://developer.android.com/intl/ru/about/ dashboards/index.html. დღეს ჩვენ ვხედავთ, რომ დიდი ნაწილი უკვე API მე-10 დონეზეა, მაგრამ ასევე არის დიდი ნაწილები, რომლებიც სხედან მე-7 და მე-8 დონეზე. დონეებში განსხვავებები შეგიძლიათ ნახოთ აქ (http://developer.android.com/intl/ru/guide /topics/manifest/uses-sdk-element.html) ცხრილში შესაბამის API ნომერზე დაწკაპუნებით.
2. თუ არ გვინდა დავკარგოთ აუდიტორიის დაახლოებით 10%, ვირჩევთ მინიმალურ API დონეს 7. წინააღმდეგ შემთხვევაში, ჩვენ შეგვიძლია ავირჩიოთ API დონე 10, სადაც არის დღეს მომხმარებელთა თითქმის ნახევარი. დააინსტალირეთ SDK, რომელიც შეესაბამება არჩეულ მინიმალურ დონეს.
3. ჩვენ ვადგენთ სამიზნე დონეს მინიმუმის ტოლფასი, ვწერთ და ვადგენთ მას პროგრამას. ჩვენ გავუშვით და ვამოწმებთ მას სმარტფონის ემულატორზე დაინსტალირებული მინიმალური დონის API-ით.
4. პროგრამის დაწერისა და გამართვის შემდეგ, ჩვენ ვზრდით სამიზნე დონეს ერთით, ვადგენთ პროგრამას ახალი სამიზნე დონის SDK-ით და ვამოწმებთ ახალ სმარტფონის ემულატორში შესაბამისი დონის მქონე. შემდეგი, ჩვენ ვაგრძელებთ სამიზნე API დონის გაზრდას, პროგრამის შედგენას და ტესტირებას მანამ, სანამ არ მივაღწევთ API-ს უმაღლეს დონეს.
5. ესე იგი, ახლა შეგიძლიათ პროგრამის გამოქვეყნება. როდესაც Android-ის ახალი ვერსია გამოვა ახალი API დონით, ჩვენი პროგრამა ჩართული იქნება თავსებადობის რეჟიმში და იმუშავებს როგორც ადრე. იმისთვის, რომ პროგრამამ პირდაპირ იმუშაოს და არა თავსებადობის რეჟიმში, ჩვენ ვიღებთ ჩვენს პროექტს, ჩამოვტვირთავთ უახლესი API დონის ახალ SDK-ს და ვადგენთ აპლიკაციას მის ქვეშ. ახლა აპლიკაცია ახალ სისტემაზე ნორმალურ რეჟიმში დაიწყება და შესაძლოა ცოტა განსხვავებულად გამოიყურებოდეს, ოპერაციული სისტემის ახალი ვერსიის ტრადიციის მიხედვით. ამავდროულად, სისტემის ძველ ვერსიებზე აპლიკაცია რჩება ისე, როგორც იყო.

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

Sandbox

ფოლადი, წაულასი, საქონლის ხორცი, ქაღალდი 2012 წლის 26 ნოემბერი, 13:59 საათი

რა არის API

სალამი!
ამ სტატიაში განვიხილავთ რა არის API, სად, როგორ და რისთვის გამოიყენება იგი. ჩვენ ასევე განვიხილავთ, თუ როგორ შეიძლება გამოყენებულ იქნას API თქვენს ვებ-განვითარებებში და როგორ გაამარტივებს მას ვებ პროგრამისტის ცხოვრება.

ასე რომ, დავიწყოთ განმარტებით. API (Application Programming Interface) არის პროგრამირების ინტერფეისი, აპლიკაციების შექმნის ინტერფეისი. უფრო გასაგებად რომ ვთქვათ, API არის მზა კოდი პროგრამისტის ცხოვრების გასაადვილებლად. API შეიქმნა ისე, რომ პროგრამისტს შეეძლო რეალურად გაეადვილებინა განაცხადის დაწერა მზა კოდის გამოყენებით (მაგალითად, ფუნქციები). კარგად ცნობილი jQuery, დაწერილი JavaScript-ში, ასევე არის ერთგვარი API. თუ კონკრეტულად გადავხედავთ ამ მაგალითს, jQuery აადვილებს კოდის დაწერას. ის, რაც შეიძლება გაკეთდეს 30 სტრიქონში რეგულარული JavaScript საშუალებების გამოყენებით, იწერება 5-6-ში jQuery-ის გამოყენებით. თუ გადავხედავთ API-ებს ზოგადად, ჩვენ შეგვიძლია ვიპოვოთ მრავალი სერვისი, რომელიც უზრუნველყოფს განვითარების გადაწყვეტილებებს. დღეს ყველაზე ცნობილია კოდი.google.com სერვისი, რომელიც გთავაზობთ ორმოცდაათამდე სხვადასხვა API-ს! ეს მოიცავს ინტერფეისს Android აპლიკაციების შესაქმნელად, სხვადასხვა API-ებს AJAX-თან მუშაობისთვის და სხვადასხვა აპლიკაციის API-ებს, რომლებიც მარტივად შეიძლება მორგებული იყოს თქვენი სურვილისამებრ.

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

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

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

ტეგები: api

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

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

უპირველეს ყოვლისა, თუ ჯერ კიდევ არ გესმით, რა არის API (Application Programming Interface), წაიკითხეთ Skillcrush-ის ახსნა-განმარტება და შემდეგ ამ სტატიის პირველი ნაწილი.

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

როდესაც თქვენ შექმნით აპლიკაციებს უფრო დინამიური წინა ფუნქციით (როგორც ერთგვერდიანი Javascript აპლიკაციები, ასევე მარტივი აპლიკაციები ინდივიდუალური AJAX ზარებით), ისინი დაუკავშირდებიან Rails-ს თქვენივე API-ს მეშვეობით, რაც ნამდვილად არის კოდის დამატებითი ხაზი ან ორი. , უთხარით თქვენს კონტროლერებს, როგორ მოემსახურონ JSON ან XML HTML-ის ნაცვლად.

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

გასათვალისწინებელი პუნქტები

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

• როგორ Rails ესმის, რა ტიპის ფაილს ელით პასუხად HTTP მოთხოვნის გაგზავნისას.
• რა არის მეთოდის #პასუხის_გამოხმაურების მიზანი?
• როგორ დააბრუნოთ მომხმარებლის ობიექტი და მიუთითოთ ის ატრიბუტები, რომლებიც არ გსურთ ამ ობიექტში შეტანილი (ანუ, თქვენ არ შეგიძლიათ უბრალოდ დააბრუნოთ User.first)?
• დაასახელეთ 2 ნაბიჯი #to_json მეთოდის კულისებში.
• როგორ ვუთხრათ კონტროლერის მოქმედებას, რომ მხოლოდ შეცდომის გაგზავნა?
• როგორ შევქმნათ საკუთარი შეცდომის შეტყობინება?
• რატომ არ შეგიძლიათ გამოიყენოთ სესიაზე დაფუძნებული კონტროლერის ავთენტიფიკაციის მეთოდები, თუ გსურთ დაუშვათ პროგრამული კავშირები თქვენს API-სთან?
• რა არის "სერვისზე ორიენტირებული არქიტექტურა"?

API საფუძვლები

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

თუმცა, ხშირად გსურს ისეთი მოთხოვნის გაკეთება, რომელიც არ საჭიროებს ბრაუზერის გამოყენების ყველა თავის ტკივილს. თქვენ შეიძლება არ გაინტერესებთ გვერდის სტრუქტურა (HTML), მაგრამ სანაცვლოდ გსურთ სუფთა მონაცემები. ვთქვათ, გსურთ მიიღოთ ყველა მომხმარებლის სია. შეგიძლიათ მოითხოვოთ მსგავსი რამ http://yourapplication.com/users , რომელიც აუცილებლად გამოიწვევს #index მოქმედებას და გამოიტანს აპის ყველა მომხმარებლის სიას.

მაგრამ რატომ უნდა შეგაწუხოთ მთელი ეს დამატებითი ინფორმაცია, თუ მხოლოდ მომხმარებლების სია გსურთ? უმარტივესი ვარიანტი იქნება მოთხოვნის გაგზავნა იმავე URL-ზე და სანაცვლოდ JSON ან XML პასუხის მოლოდინი. თუ სწორად დააკონფიგურირებთ Rails კონტროლერს, დაიბრუნებთ JSON მასივის მარტივ ობიექტს, რომელიც შეიცავს ყველა მომხმარებელს. მშვენიერია!

იგივე პრინციპი მოქმედებს გარე API-სთან კომუნიკაციისას. ვთქვათ, გსურთ მიიღოთ მომხმარებლის ბოლო ტვიტები Twitter-დან. თქვენ მხოლოდ უნდა აცნობოთ თქვენს Rails-ს აპლიკაციას, თუ როგორ უნდა დაუკავშირდეს Twitter-ის API-ს (ანუ თავად მოახდინოს ავთენტიფიკაცია), გაგზავნოთ მოთხოვნა და დაამუშავოთ "ტვიტების" ნაკრები, რომელიც დაბრუნდება.

API-ს შექმნა

შეიძლება დაგჭირდეთ თქვენი Rails აპლიკაცია სუფთა backend API-ად აქციოთ ფრონტის ვებ გვერდებისთვის, ან უბრალოდ გსურთ ისწავლოთ როგორ გაგზავნოთ JSON, როდესაც ფრონტენდი ითხოვს ამას. ეს განყოფილება არ განიხილავს, თუ როგორ უნდა შექმნათ სრულფასოვანი RESTful API ავთენტიფიკაციის ფუნქციებით. ეს არის გლუვი შესავალი თქვენი აპლიკაციის API-ად განხილვისთვის.

საფუძვლები

თუ გსურთ, რომ Rails აპლიკაციამ დააბრუნოს JSON HTML-ის ნაცვლად, თქვენ უნდა აცნობოთ თქვენს კონტროლერს ამის გაკეთება. მთავარი ის არის, რომ ერთი და იგივე კონტროლერის მოქმედებას შეუძლია დააბრუნოს სხვადასხვა ტიპები იმისდა მიხედვით, თქვენი მომხმარებელი აკეთებს რეგულარულ მოთხოვნას ბრაუზერიდან თუ წვდება API-ზე ბრძანების ხაზის მეშვეობით. ეს განსაზღვრავს, თუ რა ტიპის მოთხოვნა განხორციელდა მოთხოვნილი ფაილის გაფართოების საფუძველზე, როგორიცაა example.xml ან example.json.

შეგიძლიათ შეამოწმოთ რას ფიქრობს Rails ფაილის ტიპზე, რომელსაც ელოდებით სერვერის ჟურნალის შემოწმებით:

დაიწყო GET "/posts/new" 127.0.0.1-ისთვის 2013-12-02 15:21:08 -0800 დამუშავება PostsController#new როგორც HTML

პირველი ხაზი გიჩვენებთ რა URL იყო მოთხოვნილი, ხოლო მეორე გეტყვით სად გაიგზავნა და როგორ ამუშავებს მას Rails. თუ თქვენ იყენებდით .json გაფართოებას, ეს ასე გამოიყურება:

დაიწყო GET "/posts.json" 127.0.0.1-ისთვის 2013-12-04 12:02:01 -0800 დამუშავება PostsController#index-ის მიერ JSON-ად

თუ თქვენ გაქვთ სატესტო აპლიკაცია გაშვებული, სცადეთ მოითხოვოთ სხვადასხვა URL. თუ თქვენი კონტროლერი ვერ უმკლავდება მათ, შეიძლება მიიღოთ შეცდომა, მაგრამ მაინც უნდა გესმოდეთ რა Rails-ს ესმის თქვენი მოთხოვნები.

JSON ან XML რენდერი

მას შემდეგ რაც გადაწყვეტთ, რომ გსურთ უპასუხოთ მოთხოვნებს JSON-ის ან XML-ის გამოყენებით, თქვენ უნდა უთხრათ თქვენს კონტროლერს, გამოიტანოს JSON ან XML HTML-ის ნაცვლად. ამის გაკეთების ერთ-ერთი გზაა #respond_to მეთოდის გამოყენება:

Class UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

ამ შემთხვევაში, #respond_to გადასცემს ბლოკს ფორმატის ობიექტს, რომელსაც შეგიძლიათ დაურთოთ შესაბამისი რენდერის ზარი. თუ არაფერს გააკეთებთ, html გამოისახება სტანდარტული Rails შაბლონის გამოყენებით (ამ მაგალითში app/views/index.html.erb).

#render ფუნქცია საკმარისად ჭკვიანია იმისათვის, რომ გაიგოთ, თუ როგორ უნდა გადაიტანოთ ფორმატების ფართო სპექტრი. როდესაც მას გადასცემთ კლავიშს:json , ის გამოიძახებს #to_json მნიშვნელობაზე, ამ მაგალითში @users . ეს გადააქცევს თქვენს Ruby ობიექტ(ებ)ს JSON სტრიქონებად, რომლებიც გადაეცემა მომთხოვნ აპლიკაციას.

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

დაბრუნებული ატრიბუტების დაზუსტება

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

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

#to_json აკეთებს 2 რამეს: ის მუშაობს #as_json და იღებს ატრიბუტების ჰეშს, რომლებიც გადაიცემა JSON-ში. შემდეგ ის გადადის JSON-ზე ActiveSupport::json.encode-ის გამოყენებით. ასე რომ, #as_json-ის შეცვლით თქვენ უფრო კონკრეტულად აცხადებთ #to_json მეთოდის იმ ნაწილს, რომლის შეცვლაც ნამდვილად გსურთ.

ჩვენს შემთხვევაში, ჩვენ ამას ვაკეთებთ ჩვენს მოდელში #as_json-ის შეცვლით, რათა დავაბრუნოთ მხოლოდ ჩვენთვის საჭირო ატრიბუტები:

# app/models/user.rb კლასის მომხმარებელი< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # DO NOT მოიცავს ელფოსტის ველს ბოლოს # ვარიანტი 2: გამოიყენეთ სტანდარტული მეთოდი #as_json def as_json(options=()) super(მხოლოდ: [:name]) დასასრული

შემდეგ, ჩვენს კონტროლერს უბრალოდ დასჭირდება JSON-ის ჩვეულებისამებრ რენდირება (ქვემოთ მოცემულ მაგალითში JSON ყოველთვის დაბრუნდება, მიუხედავად იმისა, გაიგზავნა თუ არა HTML მოთხოვნა):

# app/controllers/users_controller.rb კლასი UsersController< ApplicationController def index render json: User.all end end

გაითვალისწინეთ, რომ თქვენ არ გჭირდებათ თავად დარეკოთ #to_json, როდესაც იყენებთ #render - ის ამას გააკეთებს თქვენთვის.

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

უსაფრთხოების უზრუნველყოფა გარედან

ვთქვათ, გსურთ დაუშვათ წვდომა API-ზე მხოლოდ იმ შემთხვევაში, თუ მომხმარებელი შესულია. თქვენი არსებული ავთენტიფიკაცია კონტროლერში უკვე ასრულებს ამ სამუშაოს - უბრალოდ დარწმუნდით, რომ გაქვთ სწორი ნაკრები #before_action (მაგ. before_action:require_login). შეიძლება დაგჭირდეთ ფუნქციონალობა, სადაც შესული და არაშესულ მომხმარებლებს შეუძლიათ ნახონ გვერდი, მაგრამ თითოეულმა უნდა ნახოს განსხვავებული მონაცემები. თქვენ არ გსურთ, რომ არაავთენტიფიცირებულმა მომხმარებლებს შეეძლოთ API ზარების განხორციელება მგრძნობიარე მონაცემების მისაღებად. ანალოგიურად, თქვენ არ გსურთ დაუშვათ არაავტორიზებული მომხმარებლებისთვის გარკვეული HTML გვერდების მონახულება.

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

Შემდეგი ნაბიჯები

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

• სტატია Building Awesome Rails APIs აღწერს ბევრ საუკეთესო მიდგომას სათამაშო აპლიკაციიდან სამრეწველო API სტანდარტებზე გადასვლისთვის.

სერვისზე ორიენტირებული არქიტექტურა

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

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

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

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

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

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

2) გუნდებმა უნდა დაუკავშირდნენ ერთმანეთს ამ ინტერფეისების მეშვეობით.

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

4) არ აქვს მნიშვნელობა რა ტექნოლოგიას იყენებენ. HTTP, Corba, Pubsub, საკუთრების პროტოკოლები - არანაირი განსხვავება. ბეზოსს არ აინტერესებს.

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

6) ვინც ამ მოთხოვნებს უგულებელყოფს, სამსახურიდან გაათავისუფლებენ.

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

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

შენი მიზანი

1. წაიკითხეთ Rails Controllers Guide-ის მე-7 ნაწილი, რათა შეიტყოთ JSON და XML რენდერინგის შესახებ.
2. მათი ნახვა არ არის საჭირო (რადგან ისინი ცოტა უფრო შორს მიდიან, ვიდრე ჩვენ ამჟამად მზად ვართ), მაგრამ თუ გაინტერესებთ, გადახედეთ Railscasts დამატებითი რესურსების განყოფილებაში გაკვეთილის ბოლოში, რომ გაიგოთ მეტი API-ს სარგებელი.

დასკვნა

ჩვენ უფრო მჭიდროდ ვიმუშავებთ თქვენს აპლიკაციასთან, როგორც API-ს Javascript კურსის განმავლობაში. ამ კურსში თქვენ შექმნით რამდენიმე სრული დასტას აპლიკაციას, რომლებიც იყენებენ AJAX ზარებს მომხმარებლის უკეთესი გამოცდილებისთვის, რაც არსებითად გულისხმობს XML ან JSON მონაცემების გადაცემას სრული HTML გვერდის ნაცვლად. ამის შემდეგ თქვენ შექმნით რამდენიმე ერთგვერდიან Javascript აპლიკაციებს, რომლებიც ეყრდნობიან თქვენი Rails აპლიკაციის მიერ მოწოდებულ API-ს, რათა მოიძიონ ყველა საჭირო მონაცემი მონაცემთა ბაზიდან, მაგრამ სხვაგვარად გაშვებული იქნება კლიენტის მხარეს (ბრაუზერში).

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