Дълбоко подробно, но никога окончателно ръководство за архитектурата на мобилното развитие

Native, Web, PWA, хибрид, Cross-Compiled ... какъв е "най-добрият" начин за развитие за Android и iOS платформи? Какво изглежда разумно? И как трябва да изберете сред опциите? В тази статия ще изложа всичко, за да можете да вземете информирано решение.

Първо, първо, нека ви дам малко контекст. Аз съм старши консултант по ИТ и идеята да се състави това ръководство се роди от дискусии с един от нашите клиенти за това, какво може да бъде най-добрият подход за тях. Да, само за тях. И разбрахме, че нямаме добре дефинирана стратегия, солидна и надеждна основа, която да ни помогне да изберем правилния отговор.

И знаеш ли какво? Не можах лесно да намеря подобно ръководство навсякъде в Интернет. Въпреки че има няколко статии по тази тема, нито една от тези, на които попаднах, не беше разумно пълна. За съжаление мнозинството пренебрегва много концепции или, още по-лошо, по същество греши.

Сега бих искал да разгледам по-широко. И докато аз потенциално помагам на някой да взема свои собствени решения, също моля за общността повече мисли по темата.

Това ръководство има две части:

  1. Архитектурни нива за мобилно развитие (това)
  2. Как да вземете своето решение

Той е достъпен и в YouTube като серия от 10 видеоклипа и като безплатен курс за Udemy. Там ще намерите същите писмени материали като тук, същите видеоклипове от поредицата в YouTube, както и тестове, за да коригирате всички теми и окончателно сертифициране.

Така че нека започнем

Въведение

Що се отнася до мобилните платформи, спорно е, че има само два големи играча: Android и iOS. Други технологии като Tizen, Blackberry или Windows Phone или са мъртви, или са съществували от известно време и нямат перспективи да достигнат до значителен пазарен дял.

Един бърз поглед върху този масивен дуопол може да ви накара да мислите, че разработчиците нямат много възможности при създаването на мобилни приложения. Тази идея обаче не може да бъде по-далеч от истината. Можете бързо да забележите шест програмни езика, които се използват там: C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby, и съм почти сигурен, че съм пропуснал няколко Повече ▼.

Същото се отнася и за мобилните рамки за развитие. Освен ако не сте разработчик или по някакъв начин не сте знаели за новите технологии през последните 10 години, вероятно сте чували за Cordova / PhoneGap, React Native, Xamarin, Ionic, Nativescript или Flutter, само за да назовете няколко кръстосани решения за платформа за мобилни приложения.

Затова нека разгледаме всички тези части от архитектурата и да разчупим нещата малко.

TL; DR

Няма ясен победител. Всички подходи имат плюсове и минуси и може да са или най-добрите или най-лошите за вашия следващ проект. В това ръководство класифицирам много различни решения на различни нива според разстоянието, което архитектурата им е от родната платформа.

Родни приложения

За начало, нека отидем направо към метала. Първият ни архитектурен слой е Native Apps.

Native Apps Tier - където разработвате за всяка конкретна платформа (може да е още по-конкретна, когато обмисляте NDK)

Това е ниво, в което трябва да сте запознати с особеностите на всяка платформа. Не ми е намерение да ровя в тях, просто искам да спомена няколко неща в малко контекст.

IOS

Започвайки от страна на iOS, само защото е по-просто, светът управлява само Apple. Първоначално разработчиците трябваше да научат Objective-C, собствена обектно-ориентирана вариация на C с малко вдъхновение от SmallTalk (и безумно дълго име API).

През 2014 г. Apple обяви Swift, многопарадигмен език, който беше много по-лесен от предшественика си. Все още е възможно да се справите с наследствения код на Objective-C, но Swift достигна високи нива на зрялост. Така че, ако планирате да научите как да се развивате за iOS, Swift определено е мястото, където трябва да започнете.

андроид

От страна на Android има редица различни производители. По-голямата част от тях разчитат на ARM процесори. Но най-общо казано приложенията за Android лежат на екземпляри на виртуална машина (случаи на ART), за да се справят с потенциалните основни специфики (не без много невероятни трикове).

Ето защо първоначално езикът на избор беше Java. Това е не само най-популярният език в света в продължение на почти две десетилетия (с няколко размяна на позиции с C), но е забележителен и за неговата виртуална машина (JVM). Това дава възможност на разработчиците да компилират кода си до междинен байт код, който може да бъде прочетен и управляван от JVM.

С Android Native Development Kit (NDK) също е възможно да се разработят критични части от приложението директно в родния код, като се пише в C / C ++. В този случай трябва да сте наясно с основните странности на платформата.

Kotlin е език, разкрит от JetBrains през 2011 г. Когато за пръв път излезе, въпреки своята гъвкавост и сбитост, той не беше нещо повече от друг JVM език с по-успешни конкуренти като Scala, Clojure или Groovy. Въпреки това, след първото си голямо издание през 2016 г., той бързо започна да се откроява от тълпата, особено след като Google обяви, че ще бъде официално поддържана на платформата Android на Google I / O 2017.

Kotlin се превръща в първокласен език на Google (в момента Kotlin и Java - в този ред - се използват в официалната документация на Android). Тоталната подмяна на Java се очаква още повече, тъй като сега Федералният апелативен съд на САЩ се произнесе по безкрайния иск, заведен от Oracle, обвиняващ Google в нарушаване на авторските права на Java.

Родни компоненти

Развивайки се в този слой, можете също да използвате всички местни API и по-специално родните компоненти. Това спестява на приложението ви да не се налага да преоткривате колелото.

Публикувах видео демонстрация за това как да създадете прост проект за Xcode (iOS) и Android Studio. Ако искате да го проверите:

Предимства на Native Apps

  • Най-добро представяне и ангажираност на най-добрите потребители
  • Народни функции на кървене
  • Забележително добри IDEs Android Studio / Xcode
  • Модерни езици на високо ниво Kotlin / Swift
  • Подход на много ниско ниво с NDK

Недостатъци на Native Apps

  • Две кодови бази за поддържане
  • Изисквайте инсталиране (с изключение на незабавните приложения за Android)
  • Трудно за анализиране на SEO
  • Много скъпо да накарате потребителите да изтеглят приложението

Уеб приложения

От другата страна на спектъра имаме уеб приложения. Web Apps са по същество приложения, управлявани от браузъра. Вие не пишете код, насочен към платформата, а по-скоро всеки браузър, работещ над нея.

Подреждане на уеб приложения - ясно отгоре на лентата на браузъра, насочена към звяр, който седи между Android и iOS.

В този ред ще намерите безумен брой претенденти, които скачат един на друг на гърлото. Всички те обаче използват арсенал, състоящ се от едни и същи оръжия: HTML, CSS и Javascript.

Уеб рамки и библиотеки, дори когато се използват CSS предварителни компилатори като LESS или SASS, дори Javascript предварително компилирани езици като TypeScript, CoffeeScript или Flow, дори симбиоза като JSX или Elm, оставяйки сам инструменти като Babel, използвани за прехвърляне на всичко в Javascript с различни конфигурируеми нива на съответствие с годишните спецификации на ECMAScript (ES6 / ES7 / ES8 или ако предпочитате ES2015 / ES2016 / ES2017 / ES2018).

В края на деня всички те са HTML, CSS и JavaScript, представени и управлявани от браузъра. Няма директен достъп до родните API, като камера, вибрация, състояние на батерията или файлова система, но някои от тях могат да бъдат постигнати чрез Web API:

Мога ли да разчитам на функциите на уеб платформата, за да изградя приложението си?

Големият проблем при уеб API е тяхното ниво на зрялост. Много от тях не се поддържат от някои браузъри. Има различия в реализациите, особено в мобилните браузъри.

Предимства на уеб приложението

  • Споделен код между платформи и настолни браузъри
  • Не изисквайте предишни инсталации, просто се придвижвайте и използвайте
  • Тонове рамки и библиотеки да вървят с тях
  • Най-добро за SEO

Недостатъци на уеб приложението

  • По-ниска производителност
  • Трудно е да придобиеш родно потребителско изживяване
  • Изисквайте интернет връзка
  • Не се предлага в официалните магазини за приложения
  • API не е толкова зрял и надежден като родния API

Рамки и уеб компоненти

Angular, React и Vue са може би най-популярните уеб рамки от 2018 г. За да бъдем точни обаче, React се счита само за библиотека поради своя гъвкав и по-малко изразен характер. Ъгловата, от друга страна, е силно убедена рамка. Vue живее в някакъв момент между тях.

Angular vs React срещу Vue

Angular, първоначално наричан AngularJS, беше представен на света през 2010 г. от Google. Той бързо започна да свети, поради инверсията си от парадигми в сравнение с други библиотеки от онова време (като jQuery, най-популярната тогава). Вместо директно да се говори с HTML елементи, за да се манипулира състоянието на потребителския интерфейс, с AngularJS шаблоните бяха магически актуализирани всеки път, когато се актуализираше моделът на JavaScript.

Тъй като AngularJS става все по-популярен, той също нараства нарочно. Тя се превърна в цялостна и самонадеяна рамка, която беше една от първите, които взеха сериозно SPA-тата (Single Page Apps). Този растеж (и в двата аспекта) беше отговорен за някои различия в API и проблеми с производителността.

React е създаден от Facebook, за да реши собствените си нужди на презентационния слой. Той въведе много аспекти, които изведнъж станаха много популярни, като виртуален DOM, еднопосочен поток от данни (първоначално име Flux, особено популярен чрез библиотека за внедряване, наречен Redux), и смес от HTML и JavaScript, наречени JSX.

Едва през 2016 г., след дълги дебати и неочаквани големи промени, Google стартира версия 2 на своята популярна уеб рамка. Наричаха го Angular, вместо AngularJS. Но тъй като много хора вече нарекоха първата версия „Angular“ (без суфикса „JS“), хората започнаха да наричат ​​новата версия Angular 2. Това се превърна в проблем при именуването, тъй като Google също обяви, че ще пуска нови основни версии всяка 6 месеца.

Според мен това беше мамутова грешка. Виждал съм това и преди (например с Struts vs Struts 2 / WebWork). Те имат масово популярен продукт, който изглежда е достигнал своето плато и е започнал да бъде по-критикуван, отколкото хвален. Ако Google реши да го изгради от основата, те никога не трябва да променят основната си версия. Как хората ще се доверят, че няма да го повторят при всяко ново издание на голяма версия? Версия втора трябва да представя променливи промени, но това не означава, че може да бъде напълно преработена.

Angular е зрелищна уеб рамка и наистина се чувствам страстна от това. Това обаче е напълно нов звяр. Няма много общо с AngularJS. Дори Vue, която е друга невероятна рамка (вероятно една от най-приятните за работа, между другото) изглежда по-подобна на AngularJS от птичи поглед. Вярвам, че това предизвика значително отдалечаване от Angular и допринесе съществено за популярността на React.

Vue е единствената от трите най-популярни уеб рамки, която не е подкрепена от голяма компания. Той всъщност беше стартиран от бивш разработчик на Google. Поради огромната си простота и дребен отпечатък, тя привлече вниманието от масивна и ентусиазирана общност.

Въпреки че има по-пълни решения, всички те работят върху концепцията за уеб компоненти. В момента има отворена спецификация за тях в W3C и някои интересни реализации като Polymer, Stencil и X-Tag.

В третото видео от поредицата не отделям много време за обсъждане на рамки, но обсъждам библиотеки на уеб компоненти:

Мобилни приложения срещу уеб приложения

Не съм сигурен дали сте забелязали, но редът на нивата, които представям тук, следва това, което според мен е най-лесният път за научаване на всички подходи. Започнах от Native Tier, най-истински мобилната разработка. Тогава реших да летя директно до другата крайност, за да представя Web Tier, който е подреждането, което се предлага от първите смартфони.

Едва сега, след като се спра на сравнение между двата края на моята диаграма, ще започна да говоря за много от подходите на много платформа за изграждане на мобилни приложения.

Има дълъг дебат между Mobile Apps vs Web Apps. Всичко, което казвам за Mobile Apps, не е изключително за Native Tier. Той е приложим и за всички междуплатформени нива, които представям по-късно.

Дилемата в поведението на потребителя

Потребителите прекарват повече време в мобилни приложения (87%), отколкото в мобилни уебсайтове (13%)

Според проучване на Comscore през 2017 г., верността на потребителя към мобилното приложение е много по-подходяща, отколкото е за мобилните уебсайтове. Според подравнена статия за Forbes, това обикновено се дължи на удобството (например бутони на началния екран, джаджи, топ известия), скоростта (например по-гладки интерфейси, почти моментални стартирания) и запаметените настройки (например офлайн съдържание).

Мобилните уебсайтове достигат до повече хора (8.9M месечно уникални посетители срещу 3.3M мобилни приложения)

От друга страна, в същите данни на Comscore научаваме, че клиентите могат да бъдат достигнати по-лесно от мобилните уебсайтове, тъй като не са толкова обвързани с техните няколко приложения за предпочитания. Ако сравните най-популярните уебсайтове с най-изтеглените приложения, се изчислява, че средно 8,9 милиона уникални посетители на месец достъпват до най-добрите 1000 уебсайта. Това е почти три пъти повече от средните уникални потребители на първите 1000 най-изтеглени приложения.

Разпространение (Уеб приложение) x Ангажиране (Мобилно приложение)

Това е всичко за разпределението срещу ангажираността. Уеб приложението ви има по-голям шанс за достъп, тъй като по-вероятно е потребителите да изпробват нови неща, когато навигират през мобилните си браузъри. Но мобилните приложения се оказаха по-ангажиращи и привличат вниманието на потребителите за много по-дълги периоди.

Сега, когато разбирате дилемата, нека да разгледаме Прогресивните уеб приложения. Това е подход, толкова обвързан с подреждането на уеб приложенията, че го класифицирам като просто допълнение към уеб приложенията. Но това е голям разрушител и сериозен кандидат за най-видното ново и готино нещо в уеб и мобилните разработки.

Прогресивни уеб приложения

Прогресивните уеб приложения (PWA) са набор от инструменти, използвани за да дадат на потребителите на уеб приложения същото изживяване, на което са свикнали, когато стартират мобилни приложения. Това означава, че Web Apps могат да използват потенциално по-високите нива на дистрибуция с по-прилични нива на ангажираност.

Прогресивно допълнение на уеб приложения към ниво на уеб приложения

Google определи три основни квалификации за PWA: те трябва да бъдат надеждни, бързи и ангажирани.

Функции, наречени Service Workers и App Shell, са основата на прогресивните уеб приложения. Те са създадени, за да насърчават надеждността на приложенията, тъй като сега са проектирани да работят независимо от състоянието на връзката на устройството. Това включва офлайн режим, както и лоши връзки. Те също така осигуряват значително повишено възприемане на производителността, тъй като приложенията стартират с локално кеширани данни, което елиминира забавянията при синхронно изтегляне на съдържание.

Бихте могли да считате надеждността за косвен вектор на ангажираност. Например, потребителите не са засегнати, докато пътуват с влак. Те могат да останат ангажирани.

Същото важи и за скоростта. Според Google:

53% от потребителите ще изоставят сайт, ако това отнема повече от 3 секунди!

Това обаче, че е изключително надежден и бърз при натоварване, не гарантира непременно висока ангажираност. PWA използват функции, свързани с мобилни устройства, които преди са били изключителни за мобилни приложения, като опция „Добавяне към началния екран“ и Push Notifications.

Когато става въпрос за функцията „Добавяне към началния екран“, може да забележите, че Apple има подобна функция още от първия iPhone. Някои хора дори твърдят, че Progressive Web Apps са фантастичното ново име на Google за оригинална идея на Apple.

И наистина не можете да не се съгласите напълно. Някои идеи всъщност са велосипедни. Те идват, си отиват и след това се връщат с ново име и някои подобрения (например сервизни работници), за да могат най-накрая да се придържат.

От друга страна, е трудно да се съгласим напълно. Речта на Стив Джобс за Web 2.0 + AJAX и запомнящото се съобщение за iPhone през WWDC 2007 не са достатъчно убедителни, за да го нарекат като баща или дори пророк на PWA.

За да бъдем справедливи, възможностите за добавяне към началния екран на iPhone не са нищо повече от едва доловима, почти скрита функция за генериране на икони на работния плот, които просто стартират уеб приложения в режим на цял екран. Той има цялата тежест на HTTP цикли на отговор на заявката и няма ясен път около кешовете.

PWA започват от правилната точка. Те проучват как не са необходими предишни инсталации на уеб приложения, без да се губи клиентската начална програма за мобилни приложения. Това означава, че всичко, което потребителят се нуждае за първото си взаимодействие след стартиране, може да бъде локално кеширано (четете: Shell на приложението) и да бъде достъпно веднага щом натисне „Добавяне към началния екран“.

Преминавайки към друга добре позната характеристика на PWA, нека поговорим за супер ангажиращата (или отново ангажиращата) функция на света на мобилните приложения: Push Notifications. Те са съобщения в стил на предупреждение, които се появяват в горната лента / зона за уведомяване, както и на заключените екрани. Те имат силата да изтеглят потребителите обратно към приложението ви, след като получат известието.

За да засили привлекателността на PWA, Google дърпа всички съвременни уеб API под PWA чадъра. Така че очаквайте да видите неща като Заявки за плащане, Управление на поверителност, WebVR, Сензори, WebAssembly и WebRTC в контекста на прогресивните уеб приложения. Но тези характеристики не са задължително свързани с PWA, а някои дори са родени преди въвеждането на термина PWA.

PWA и Apple

Apple, от друга страна, обяви първите си основни етапи към PWAs едва през март 2018 г. Въпреки че все още има някои ограничения, напредъкът е забележим. Някои от ограниченията може да са свързани с факта, че Safari изостава от своите конкуренти. Други могат да бъдат причислени към философията на Apple за строг контрол.

Все пак Apple има по-изгоден App Store от Google. Apple твърди, че повече критерии за публикации на приложения носят по-голяма обща надеждност и PWAs са длъжни да навредят на приходите на App Store. Това предполага, че някои ограничения, които изглеждат умишлено наложени (като 50Mb от максималния размер на кеша на PWA), ще струват повече, за да бъдат отменени.

За съжаление PWA не са перфектни

Уеб решенията и на различни нива всички кросплатформени решения се борят за постигане на съвършенство и всеобхватност на Native Apps. Всяка нова функция и всеки детайл, специфичен за Android или iOS, правят, че родните се чувстват все по-трудно и по-трудно, докато отдалечавате приложението си от родния ред.

Като цяло PWA отстраняват някои проблеми в подреждането на уеб приложенията. Но има и други проблеми, които не могат да бъдат отстранени от решение, работещо над браузъра.

Какво определя PWA

  • Повече „роден“ опит
  • По-бързо време за зареждане
  • Не изисквайте интернет връзка
  • Принуждавайте уеб разработчиците да са наясно със ситуации, при които няма връзка, както и лоша връзка
  • Включете функции от мобилни приложения като Push Известия, Геолокация или Разпознаване на реч

Това, което нямат

  • Присъща бавност
  • Не се предлага в магазините за приложения (все още)
  • Все още не се поддържа напълно от всички браузъри
  • Все още липсват мобилни функции като NFC, Ambient Light, Geofencing
  • Също така липсва поддръжка за особености на Android или iOS като PiP, банери за интелигентни приложения, джаджи за стартиране на екрана и 3D докосване

Във видеото по-долу правя кратък преглед на PWA.

Хибридни приложения

На това ниво започваме да се гмуркаме в света на мобилните приложения. Ще започнем от най-отдалечения ред: Hybrid Apps.

Терминът Hybrid също често се прилага за всички кросплатформени решения. Тук обаче го ограничавам до приложения, които работят в мобилни компоненти, наречени WebViews.

Подреждането на хибридните приложения. Под линията на браузъра, но отгоре на WebViews

Във демонстрациите във второто видео, моята цел да добавя WebView като привет Hello World беше да изясня, че има естествен компонент за всяка платформа, който може да се изпълнява като действителен браузър.

Cordova / PhoneGap

Решения като Cordova / PhoneGap преодоляват пропастта (съжалявам за неинспирираното каре) между Web и Mobile Apps. Те предоставят инструменти за пакетиране на HTML, JavaScript и CSS код на разработчика (както и всякакви допълнителни активи като изображения или видеоклипове) и ги трансформират в мобилни приложения (да, истински приложения за Android или iOS). Тези приложения имат своя WebView изключително за интерпретация и стартиране на оригиналния уеб код, като се започне с файла „index.html“ в основната папка на приложението (обикновено наричано „www“). Те също прехвърлят JavaScript кода към родния API, чрез плъгини, които са частично внедрени в JavaScript и частично на родния език.

Така че, нека да направим нещата по-ясни. Хибридните приложения имат достъп до собствени API (вместо уеб API), но те са затворени от WebView. Бутон с Кордова трябва да бъде HTML бутон, изобразен от WebView, вместо от мобилен нативен бутон.

Това е вълшебното ниво, което позволява на компаниите да приставят своите уеб приложения към мобилни приложения, за да бъдат доставяни от магазини за приложения. Така че всяка уеб рамка е позволена тук.

йонийски

Рамки като йонски обвиват Кордова в свои собствени решения. С Ionic не е необходимо да използвате интерфейса на командния ред на Cordova (CLI), защото всичките му команди са обвити от Ionic CLI.

Наскоро екипът на Ionic реши да вземе юздите на целия стек от Hybrid Apps. Така те пуснаха предложена замяна на Кордова, наречена Capacitor. Кондензаторът има поддръжка за Cordova плъгини и може да се използва и от не-йонски проект.

Можете да ме гледате как преминавам през проба от Hello World в Кордова в петото видео от поредицата:

Предимства на хибридните приложения

  • Те са по същество уеб приложения, които могат да се доставят до официални магазини за приложения
  • Може да се използва заедно с всяка JavaScript рамка / библиотека
  • Кодът все още е много споделен за всички платформи
  • Достъп до естествени функции (например, камера, акселерометър, списък с контакти)

Недостатъци на хибридните приложения

  • Борвайте се с проблеми с производителността и потреблението на памет, тъй като уеб изгледите са отговорни за изобразяването на всичко на екрана
  • Трябва да имитирате всички естествени компоненти на потребителския интерфейс върху една уеб изглед
  • По-трудно е да бъдеш приет и публикуван в App Store
  • Обикновено отнема повече време, за да има налични функции за тези среди

Web Native

Web Native е сравнително нов и често неразбран слой. Именно там Web Apps се срещат с местни компоненти. Въпреки че Appcelerator (Axway) Titanium съществува отдавна, има някои сравнително нови конкуренти, които оправдават това да стане напълно отделна категория мобилни приложения.

Web Native Apps не се нуждаят от WebView, тъй като те говорят директно с други местни компоненти

Както можете да видите по-горе, няма уеб изглед, който да изобразява и стартира приложението ви. И така, как се изпълнява вашият JavaScript? Съставен ли е? Е, ако смятате транспилация (компилация от един език на друг - например TypeScript към JavaScript), групиране, минимизация, мангинг и обфускация всички заедно като компилация, да, JavaScript се компилира.

Проблемът е, че това не прави вашия JavaScript нещо директно разбрано от операционните системи Android или iOS. И на теория няма нативен компонент, който да служи само като двигател на JavaScript без размаха на механизма за оформление на HTML.

Стратегията е да изпращате JavaScript двигатели (обикновено V8 за Android и JavaScriptCore за iOS) заедно с вашия код. Въпреки че имат малки отпечатъци и са много бързи, те са нещо външно, което трябва да бъде осигурено от приложението ви.

От друга страна, този подход има по-добра производителност на потребителския интерфейс, тъй като всички компоненти са същите (или са базирани на едно и също нещо за React Native, например) като тези, използвани от Native Apps.

Предимства на Web Native Apps

  • Достигнете до двете платформи с една единствена кодова база
  • Приблизително същата производителност като родните приложения, тъй като те също се справят с нативните компоненти на потребителския интерфейс
  • Настройките са необходими, но кодът все още може да се споделя с уеб разработка

Недостатъци на уеб приложенията

  • Дори и с една единствена кодова база, разработчикът трябва да е запознат с родните компоненти
  • По-стръмна крива на обучение от Hybrid / Web Apps за уеб разработчици, особено що се отнася до оформлението

Реагирайте Native

В част 6 от поредицата правя бърз Hello World in React Native. Това показва в инспектора за оформление на Android Studio, какви компоненти са били представени в емулатора. Сравнявам с предишните примери, като се уверя, че няма никакъв WebView.

Nativescript

Друга невероятна рамка, която ме интересува особено през последните две години (имам курс по Udemy за това - на португалски), е Nativescript. Тя е подобна на React Native, но не е обвързана със света на React (все пак има неофициална интеграция, Nativescript-Preact).

С Nativescript можете да разработвате с помощта на ванилов JavaScript, TypeScript, Angular и наскоро Vue. Разбира се, можете да използвате други рамки, но това са официално поддържаните. Между другото, той също е доста добре документиран.

Nativescript разполага с инструменти като Nativescript Sidekick и Nativescript Playground, както и структури на проекти, базирани на шаблони, които могат да бъдат предоставени от общността. Това трябва да ви помогне в създаването на проекти, като ви дава възможност да стартирате, внедрявате, тествате и стартирате на симулатори на облачните и iPhone устройства, дори когато не се разработвате с Mac.

В седмата част на поредицата правя Hello World, използвайки Sidekick, заедно с друг проект, стартиран от CLI и шаблон за клониране на WhatsApp, който създадох за целите на обучението.

Важно е да разгледате инспектора на оформлението, когато приложението ви работи на емулатор за Android. С Nativescript той показва родните компоненти (отново няма WebView) и директни случаи на общи класове Android като TextView. Това е различно от React Native, който има собствени класове за увиване на родните компоненти.

Вероятно затова Nativescript твърди, че няма забавяне между това, когато е налична нова функция на iOS и Android и когато можете да я използвате в проект Nativescript. Например те публикуваха в своя блог AR проект в същия ден iOS 11 беше официално пуснат с новия ARKit API.

Weex

Друга рамка, която си струва да се спомене в тази категория, е Weex. Това е проект, разработен от Alibaba и в момента се инкубира в Apache Sofware Foundation (ASF). Той използва общи HTML маркери като

и CSS команди вътре в