Expo Go

ანალიზის ავტორი: AppCompare

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

არჩევანისას მთავარი კითხვა: სწრაფი ტესტი გჭირდებათ თუ სრული გარემო?

Expo Go Expo Project-ის უფასო აპია ბიბლიოთეკებისა და დემონსტრაციების კატეგორიაში. მისი დანიშნულება React Native-სა და JavaScript-ზე მომუშავე პროექტების ტელეფონზე გაშვება და შემოწმებაა. ეს განსხვავდება ისეთი ინსტრუმენტებისგან, რომლებიც მხოლოდ კოდის წერას ემსახურება: აქ მთავარი ისაა, რომ მიმდინარე ნამუშევარი რეალურ მოწყობილობაზე ნახოთ.

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

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

სად არის Expo Go-ს ძლიერი მხარე

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

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

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

არჩევამდე წაკითხვა ღირს

---

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

როცა რიტმი წყდება, რამდენად საიმედოა Tiles Hop

Spotify მუსიკას არჩევს ჩვენთან ერთად და ჩვენს ნაცვლად

Xiaomi-ის ამინდის აპზე გადასვლა: როდის ღირს და რას დაკარგავთ

ფერების შევსების მშვიდი რიტუალი: რატომ გვიზიდავს Coloring Games

eBay-ის აპი: იშვიათი ნივთების ძიება და გაყიდვა მოთმინებას მოითხოვს

---

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

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

გუნდურ მუშაობაშიც შეიძლება გამოგადგეთ, თუ უკუკავშირი კონკრეტულად არის ორგანიზებული. ყველასთვის ერთდროულად ზოგადი შეკითხვის დასმის ნაცვლად, სთხოვეთ ადამიანს ერთი რამ შეამოწმოს — მაგალითად, იპოვის თუ არა მთავარ ღილაკს ან მიხვდება თუ არა ეკრანიდან შემდეგ ნაბიჯს. ასე ტელეფონზე ნაჩვენები პროტოტიპი რეალურ საუბარს იწყებს და კომენტარები ნაკლებად ბუნდოვანი ხდება. ამ გზით ստացված դիտարկումները მაინც նախնական են, რადგან დემონстраცია აპის საბოლოო որակի ან կայმედეგობის მტკიცებულება არ არის.

სად მთავრდება მისი მოხერხებულობა

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

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

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

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

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

როდის ჯობს სხვა გზა

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

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

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

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

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

დაწყება და სამუშაო პროცესის შეცვლის ფასი

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

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

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

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

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

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

ვის ვურჩევდი და ვის — არა

Expo Go-ს ვურჩევდი React Native-ის შემსწავლელს, მცირე პროტოტიპზე მომუშავე ადამიანს ან დეველოპერს, რომელსაც მხარდაჭერილ Expo-პროექტში ცვლილებების ტელეფონზე სწრაფად ნახვა უნდა. ის ასევე გამოგადგებათ, თუ გუნდში ადრეული ეკრანების ჩვენება და განხილვა გსურთ, ოღონდ მონაწილეებს უნდა ესმოდეთ, რომ დემონსტრაცია ჯერ გამოშვებული პროდუქტი არ არის.

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

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

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

აპი უფასოა და მის გვერდზე საშუალო შეფასება 4,3-ია, დაახლოებით 32 ათასი შეფასებითა და 5 მილიონზე მეტი ინსტალაციით. ის 2015 წლის 8 დეკემბერს გამოვიდა; მიმდინარე ვერსია 57.0.9-ია, მინიმალური მოთხოვნა კი Android 7.0. ასაკობრივი ნიშანი 3+ არის. ეს ცნობები პოპულარობისა და თავსებადობის შესახებ წარმოდგენას ქმნის, მაგრამ გადაწყვეტილების მთავარი საფუძველი მაინც თქვენი პროექტის Expo-სთან შესაბამისობა უნდა იყოს.

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

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

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

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