ერთი კოდი – სხვადასხვა პლატფორმა: NativeScript და React Native

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

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

მაშ ასე: ჰიბრიდები თავიდანვე გამოვრიცხეთ. ჰიბრიდია მობილურის ისეთი აპლიკაცია, რომელიც html/css/javascript-ით იწერება და შემდეგ web view კომპონენტით იტვირთება აპლიკაციაში. ჩვეულებრივი საიტისგან განსხვავებით რაღაც დონეზე ხელმისაწვდომია მობილურის ოპერაციულის API, თუმცა ჩვეულებრივი საიტივით რენდერდება. Native აპლიკაცია მასთან შედარებით გაცილებით გლუვი და სწრაფია, user experience მაინც განსხვავდება, ამიტომ ჰიბრიდებს ძირითადად პატარა აპლიკაციების ან პროტოტიპებისთვის ირჩევენ ხოლმე.

ჰიბრიდის შესაქმნელი ფრეიმვორკები მრავლად არსებობს: Cordova (ყოფილი PhoneGap), Ionic, Sencha Touch, Mobile Angular UI, ა.შ.

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

 

NativeScript

კომპანია Telerik-მა, რომელსაც შეიძლება ჰიბრიდის ბიბლიოთეკით იცნობთ, შექმნა NativeScript – ფრეიმვორკი, სადაც ანგულარის, typescript-ის ან ჯავასკრიპტის გამოყენებით შეგვიძლია შევქმნათ მობილურის native აპლიკაციები.

ტელეფონზე ეშვება ჯავასკრიპტის ვირტუალური მანქანა და reflection-ის, C++-ის და OS-ის აპის გამოყენებით ხიდს ქმნის native კომპონენტებთან. მეტი background დეტალებისთვის შეგიძლიათ ეს გვერდი ნახოთ: How NativeScript Works
თუმცა, ამ ხიდის მიუხედავად, ნამდვილი native-ის წარმადობასთან სხვაობას ვერ შეამჩნევთ.

ფრეიმვორკის ძირითადი ღირსებები ესენია:
– Native UI
– Extensible (Easily reuse existing plugins from npm, CocoaPods (iOS) and Gradle (Android) directly in NativeScript projects)
– Cross-Platform: Write and deploy native mobile apps for iOS, Android and (soon) Windows from a single code base
– Open source: Apache 2 license.

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

საიტისგან განსხვავებით NativeScript-შიც და React Native-შიც view-ებს html-ით არ ვწერთ, არამედ xml-ით, რომელიც ანდროიდის ვიუებს ჰგავს.

<StackLayout>
	<Button ios:text="foo" android:text="bar"></Button>
</StackLayout>

შეგვიძლია კონკრეტული პლატფორმისთვის სხვა ლოგიკა ჩავდოთ. ერთი მაგალითი ზევით მოცემული ღილაკის ტექსტია. ჯავასკრიპტში შეგვიძლია დავწეროთ if (page.ios) { … }

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

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

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

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

 

React Native

ამას გაცილებით შთამბეჭდავი გალერეა აქვს. ათასობით აპლიკაციაში ყოფილა გამოყენებული. React Native ფრეიმვორკი Facebook-ისგან მოდის და React-ს ჰგავს. ეს რომ ვცადე, ნამდვილად დავეთანხმე რამდენიმე სტატიას – NativeScript-თან შედარებით გაცილებით მეტი კონტროლი გაქვს UI-ზე, ამიტომ დიზაინში უფრო თავისუფალი ხარ, მაგრამ, სამაგიეროდ, მეტ კონტროლს მეტი კოდი მოჰყვება თან.

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

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

 

დასკვნა

პროექტის გადაწერის მაგივრად, ნოლიდან რომ ვიწყებდე ახლა რაიმეს ცოტა კომპლექსური ინტერფეისით, ალბათ React Native-ს ავირჩევდი. თუმცა ესეც არ არის, რომ მეორე დღესვე მარტივად დაიწყებ წერას. იმ რამდენიმე გვერდისთვისაც კი ბევრი trial and error დამჭირდა – ცალკე გარემოს ვერსიების შეთავსებაში ინსტალაციისას და ცალკე უცხო ფრეიმვორკის ალღოს აღებაში. ამ ორივე ფრეიმვორკს ანდროიდის სქილები ეხმარება, რადგან ანდროიდშიც ანალოგიურად ხდება UI-ის აწყობა.

არსებობს კიდევ ერთი – Xamarin, სადაც C#-ზე წერ, უბრალოდ ეს ვინდოუსის სამყაროა და საჩვენო არ იყო. ისე Xamarin ცოტა განსხვავებულად იქცევა. მაგალითად, iOS-ის პროექტს პირდაპირ დივაისის ასემბლერში აკომპილირებს, ანდროიდისთვის კი Mono .Net ფრეიმვორკს იყენებს. დეტალები შეგიძლიათ საიტზე ნახოთ: Understanding the Xamarin mobile platform

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

გამოხმაურება

comments

7 thoughts on “ერთი კოდი – სხვადასხვა პლატფორმა: NativeScript და React Native

  • 10 მარტი, 2017 at 21:40
    Permalink

    არ არის აუცილებელი მთლიანად ReactNative-ში გადაწერა, ერთი view-ით შეგიძლია დაიწყო. ინსტაგრამის მაგალითი დაგეხმარება, თუარ გინახავს:
    https://engineering.instagram.com/react-native-at-instagram-dd828a9a90c7

    Reply
    • 11 მარტი, 2017 at 22:19
      Permalink

      მადლობა 🙂 წავიკითხე ახლა ეს სტატია. პლიუსია რომ მიგრაცია შეიძლება ნელნელა, თუმცა თუ სრულად ვაპირებ დამიგრირებას (რადგან ზედ უნდა დაშენდეს ახალი რამეები), მაინც იგივე რესურსი და დრო დაიხარჯება. გამოდის, თან პარალელურად უნდა გაგრძელდეს ნეითივებზე მუშაობა და თან ვიღაცამ react native უნდა ისწავლოს და გადაიტანოს.

      Reply
  • 12 მარტი, 2017 at 18:04
    Permalink

    API driven აპლიკაციები რომელშიდაც ძირითადად ფიდებია და მათი ვიზუალიზაცია React Native-ით საკმაოდ კარგები გამოდის. Atrsy-მ ახლახანს გადაიყვანეს თავიანთი აპი (რომელიც ასევე ოფენ სორსია და ჩახედვა შეგიძლია) და საკმაოდ წარმატებით, განსაკუთრებით დეველოპმენტის დროის შემცირების მხრივ. ბლოგზე კარგაფ აქვთ პროცესი აღწერილი. http://artsy.github.io/series/react-native-at-artsy/

    მე პირადად ნეითივის მომხრე ვარ, მარა ამ სოციალური აპების წერა ყველაზე ნაკლებად მომწონს. So, I’m not target audience either.

    წარმატებები!

    Reply
    • 14 მარტი, 2017 at 23:05
      Permalink

      მადლობა ტოტო 🙂 წავიკითხავ აუცილებლად

      Reply
  • 01 აპრილი, 2017 at 04:31
    Permalink

    https://ionicframework.com/

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

    Reply
    • 01 აპრილი, 2017 at 04:36
      Permalink

      ხო სტატიის ის ნაწილი გამომრჩა სადაც ჰიბრიდებზე საუბრობდი ასე რომ ჩემი კომენტარი უკომენტაროდ დავტოვოთ

      Reply
      • 01 აპრილი, 2017 at 14:30
        Permalink

        კარგი :))

        Reply

კომენტარის დატოვება

თქვენი ელფოსტის მისამართი გამოქვეყნებული არ იყო. აუცილებელი ველები მონიშნულია *