Una guida profondamente dettagliata ma mai definitiva all'architettura di sviluppo mobile

Nativo, Web, PWA, ibrido, cross-compilato ... qual è il modo "migliore" di sviluppare per piattaforme Android e iOS? Cosa sembra ragionevole? E come dovresti scegliere tra le opzioni? In questo articolo, spiegherò tutto in modo da poter prendere una decisione informata.

Per prima cosa, lascia che ti fornisca un po 'di contesto. Sono un consulente senior IT e l'idea di mettere insieme questa guida è nata dalle discussioni con uno dei nostri clienti su quale potrebbe essere l'approccio migliore per loro. Sì, solo per loro. E ci siamo resi conto che non avevamo una strategia ben definita, una base solida e affidabile, per aiutarci a trovare la risposta giusta.

E tu sai cosa? Non sono riuscito a trovare una guida del genere facilmente ovunque su Internet. Sebbene ci siano diversi articoli su questo argomento, nessuno di quelli che ho incontrato era ragionevolmente completo. Sfortunatamente la maggioranza trascura molti concetti o, peggio ancora, è sostanzialmente sbagliata.

Ora vorrei dare un'occhiata più ampia. E mentre sto potenzialmente aiutando qualcuno a prendere le proprie decisioni, sto anche chiedendo alla comunità ulteriori riflessioni sull'argomento.

Questa guida ha due parti:

  1. Livelli architettonici di sviluppo mobile (questo)
  2. Come prendere la tua decisione

È disponibile anche su YouTube come una serie di 10 video e come corso gratuito su Udemy. Lì troverai lo stesso materiale scritto di qui, gli stessi video della serie YouTube, nonché quiz per correggere tutti gli argomenti e una certificazione finale.

Quindi iniziamo.

introduzione

Quando si tratta di piattaforme mobili, è discutibile che ci siano solo due grandi giocatori: Android e iOS. Altre tecnologie come Tizen, Blackberry o Windows Phone sono morte o sono in circolazione da un po 'di tempo e non hanno prospettive di raggiungere quote di mercato significative.

Una rapida occhiata a questo enorme duopolio potrebbe farti pensare che gli sviluppatori non abbiano molte opzioni durante la creazione di app mobili. Questa idea non può essere più lontana dalla verità, però. Puoi individuare rapidamente una manciata di linguaggi di programmazione usati là fuori: C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby e sono abbastanza sicuro di aver perso alcuni Di Più.

Lo stesso vale per i framework di sviluppo mobile. A meno che tu non sia uno sviluppatore o non sia stato in qualche modo ignaro delle nuove tecnologie negli ultimi 10 anni, probabilmente hai sentito parlare di Cordova / PhoneGap, React Native, Xamarin, Ionic, Nativescript o Flutter, solo per citarne alcuni soluzioni di piattaforma per app mobili.

Diamo un'occhiata a tutti questi elementi dell'architettura e analizziamo un po 'le cose.

TL; DR

Non c'è un vincitore chiaro. Tutti gli approcci hanno pro e contro e potrebbero essere la soluzione migliore o la peggiore per il tuo prossimo progetto. In questa guida, sto classificando molte soluzioni diverse in vari livelli in base alla distanza delle loro architetture dalla piattaforma nativa.

App native

Per iniziare, andiamo direttamente al metallo. Il nostro primo livello architettonico è App native.

Livello di app native - Dove sviluppi per ciascuna piattaforma specifica (potrebbe essere ancora più specifico se si considera NDK)

Questo è il livello in cui devi essere consapevole delle idiosincrasie di ciascuna piattaforma. Non è mia intenzione scavare in loro, voglio solo menzionare alcune cose in un po 'di contesto.

iOS

A partire dal lato iOS, solo perché è più semplice, c'è solo Apple che governa il mondo. Inizialmente, gli sviluppatori dovevano imparare Objective-C, una variante proprietaria orientata agli oggetti di C con qualche ispirazione da SmallTalk (e un'API follemente chiamata).

Nel 2014, Apple ha annunciato Swift, un linguaggio multi-paradigma, che era molto più semplice del suo predecessore. È ancora possibile gestire il codice legacy Objective-C, ma Swift ha raggiunto livelli di maturità elevati. Quindi, se hai intenzione di imparare come sviluppare nativamente per iOS, Swift è sicuramente il punto di partenza.

androide

Sul lato Android, ci sono diversi produttori. La stragrande maggioranza di essi si affida a processori ARM. Ma in generale, le app Android si basano su istanze di macchine virtuali (istanze di ART) per aiutare a gestire potenziali specificità sottostanti (non senza molti trucchi sorprendenti).

Ecco perché, in origine, la lingua scelta era Java. Non è stata solo la lingua più popolare al mondo per quasi due decenni (con alcuni scambi di posizione con C), ma è anche nota per la sua Java Virtual Machine (JVM). Ciò ha consentito agli sviluppatori di compilare il loro codice fino a un bytecode intermedio che poteva essere letto ed eseguito dalla JVM.

Con Android Native Development Kit (NDK), è anche possibile sviluppare parti critiche dell'app direttamente nel codice nativo, scrivendo in C / C ++. In questo caso, devi essere consapevole delle stranezze della piattaforma sottostante.

Kotlin è un linguaggio svelato da JetBrains nel 2011. Quando è uscito per la prima volta, nonostante la sua flessibilità e concisione, non era altro che un altro linguaggio JVM con concorrenti di maggior successo come Scala, Clojure o Groovy. Tuttavia, dopo la sua prima importante uscita nel 2016, ha rapidamente iniziato a distinguersi dalla massa, soprattutto dopo che Google ha annunciato che sarebbe stato ufficialmente supportato sulla piattaforma Android a Google I / O 2017.

Kotlin sta diventando il linguaggio di prima classe di Google (attualmente Kotlin e Java - in questo ordine - sono utilizzati nella documentazione ufficiale di Android). Una sostituzione totale di Java è prevista ancora di più ora che la Corte d'appello federale degli Stati Uniti ha deciso sull'infinita causa intentata da Oracle accusando Google di violare i diritti d'autore di Java.

Componenti nativi

Sviluppando in questo livello, puoi anche sfruttare tutte le API native e, in particolare, i componenti nativi. Questo evita che la tua app debba reinventare la ruota.

Ho pubblicato una demo video su come creare un semplice progetto su Xcode (iOS) e Android Studio. Se vuoi verificarlo:

Vantaggi delle app native

  • Migliori prestazioni e massimo coinvolgimento degli utenti
  • Caratteristiche native all'avanguardia
  • In particolare buoni IDE Android Studio / Xcode
  • Lingue moderne di alto livello Kotlin / Swift
  • Approccio di livello molto basso con NDK

Svantaggi delle app native

  • Due basi di codice da mantenere
  • Richiedi installazione (tranne Android Instant Apps)
  • SEO difficile da analizzare
  • Molto costoso per convincere gli utenti a scaricare l'app

App Web

Dall'altro lato dello spettro, abbiamo le app Web. Le app Web sono essenzialmente app gestite dal browser. Non scrivi codice indirizzato alla piattaforma, ma piuttosto a qualsiasi browser in esecuzione su di essa.

Livello di app Web: chiaramente sulla parte superiore di una barra del browser rivolta a una bestia seduta tra Android e iOS.

In questo livello troverai un numero folle di contendenti che si saltano alla gola. Ma usano tutti un arsenale composto dalle stesse armi: HTML, CSS e Javascript.

Web framework e librerie, anche quando sfruttano i precompilatori CSS come LESS o SASS, anche linguaggi precompilati Javascript come TypeScript, CoffeeScript o Flow, persino simbiosi come JSX o Elm, lasciando da soli strumenti come Babel che traspilavano tutto in Javascript con differenti livelli configurabili di conformità alle specifiche annuali ECMAScript (ES6 / ES7 / ES8, o se si preferisce ES2015 / ES2016 / ES2017 / ES2018).

Alla fine, sono tutti HTML, CSS e JavaScript resi ed eseguiti dal browser. Non esiste un accesso diretto alle API native come fotocamera, vibrazione, stato della batteria o file system, ma alcune di esse possono essere raggiunte tramite le API Web:

Posso fare affidamento sulle funzionalità della piattaforma Web per creare la mia app?

Il grosso problema con le API Web è il loro livello di maturità. Molti di essi non sono supportati da alcuni browser. Esistono differenze nelle implementazioni, in particolare tra i browser mobili.

Vantaggi dell'app Web

  • Codice condiviso tra piattaforme e browser desktop
  • Non richiedono installazioni precedenti, basta navigare e utilizzare
  • Tonnellate di quadri e librerie da accompagnare
  • Il meglio per il SEO

Svantaggi dell'app Web

  • Prestazioni inferiori
  • Difficile ottenere un'esperienza utente nativa
  • Richiedi una connessione a Internet
  • Non disponibile negli app store ufficiali
  • API non così mature e affidabili come API native

Frameworks e componenti Web

Angular, React e Vue sono probabilmente i framework web più popolari a partire dal 2018. Per essere precisi, tuttavia, React è considerato solo una libreria a causa della sua natura flessibile e meno ponderata. Angolare, d'altra parte, è un quadro fortemente supponente. Vue vive ad un certo punto tra di loro.

Angolare vs React vs Vue

Angular, originariamente chiamato AngularJS, è stato presentato al mondo nel 2010 da Google. Ha rapidamente iniziato a brillare, a causa della sua inversione di paradigmi rispetto ad altre librerie di allora (come jQuery, la più popolare di allora). Invece di parlare direttamente con elementi HTML per manipolare lo stato dell'interfaccia utente, con AngularJS, i modelli venivano magicamente aggiornati ogni volta che veniva aggiornato il modello JavaScript.

Quando AngularJS divenne sempre più popolare, crebbe anche di proposito. Si è trasformato in un quadro completo e supponente che è stato uno dei primi che ha preso sul serio le SPA (app a pagina singola). Questa crescita (in entrambi gli aspetti) è stata responsabile di alcuni gonfiori delle API e problemi di prestazioni.

React è stato creato da Facebook per risolvere le proprie esigenze a livello di presentazione. Ha introdotto molti aspetti che sono diventati improvvisamente molto popolari, come DOM virtuale, flusso di dati unidirezionale (originariamente chiamato Flux, particolarmente popolare attraverso una libreria di implementazione chiamata Redux) e una miscela di HTML e JavaScript chiamata JSX.

Solo nel 2016, dopo lunghi dibattiti e grandi cambiamenti inaspettati, Google ha lanciato la versione due del suo popolare framework web. Lo chiamavano Angular, invece di AngularJS. Ma, come molte persone hanno già chiamato la prima versione "Angular" (senza il suffisso "JS"), la gente ha iniziato a chiamare la nuova versione Angular 2. Ciò si è trasformato in un problema di denominazione, poiché Google ha anche annunciato che avrebbe rilasciato nuove versioni principali ogni 6 mesi.

Secondo me, è stato un errore gigantesco. L'ho già visto prima (con Struts vs Struts 2 / WebWork, per esempio). Hanno un prodotto estremamente popolare che sembra aver raggiunto il suo altopiano e ha iniziato a essere più criticato che elogiato. Se Google decide di ricostruirlo da zero, non dovrebbe mai, in alcun modo, cambiare la sua versione principale. In che modo le persone si fideranno di non ripeterlo ogni nuova versione principale? La versione due dovrebbe presentare cambiamenti radicali, ma ciò non significa che possa essere completamente rinnovato.

Angular è un framework web spettacolare, e mi sento davvero appassionato. Tuttavia, è una bestia completamente nuova. Non ha molto a che fare con AngularJS. Anche Vue, che è un altro fantastico framework (probabilmente uno dei più piacevoli con cui lavorare, tra l'altro) sembra più simile ad AngularJS da una prospettiva a volo d'uccello. Credo che ciò abbia causato un significativo allontanamento da Angular e abbia contribuito in modo sostanziale alla popolarità di React.

Vue è l'unico dei tre framework Web più popolari che non è supportato da una grande azienda. In realtà è stato avviato da un ex sviluppatore di Google. Grazie alla sua formidabile semplicità e al suo ingombro ridotto, ha attirato l'attenzione di una comunità massiccia ed entusiasta.

Sebbene esistano soluzioni più complete, funzionano tutte al di sopra del concetto di componenti Web. C'è una specifica aperta su di loro attualmente in corso nel W3C e alcune implementazioni interessanti come Polymer, Stencil e X-Tag.

Nel terzo video della serie, non passo troppo tempo a discutere di framework ma a discutere di librerie di componenti Web:

App mobili vs app Web

Non sono sicuro che tu l'abbia notato, ma l'ordine dei livelli che sto presentando qui segue quello che penso sia il percorso più semplice per imparare tutti gli approcci. Ho iniziato dal livello nativo, lo sviluppo più realmente mobile. Quindi ho deciso di volare direttamente all'altro estremo per presentare il Web Tier, che è il livello disponibile sin dai primi smartphone.

Solo ora, dopo aver elaborato un confronto tra i due bordi del mio diagramma, inizierò a parlare di molti degli approcci multipiattaforma per creare app mobili.

C'è un lungo dibattito tra app mobili e app Web. Tutto ciò che dico sulle app mobili non è esclusivo del livello nativo. È applicabile anche a tutti i livelli multipiattaforma che presenterò in seguito.

Il dilemma del comportamento dell'utente

Gli utenti trascorrono più tempo sulle app mobili (87%) che sui siti Web mobili (13%)

Secondo un sondaggio Comscore nel 2017, la fedeltà di un utente a un'app mobile è molto più rilevante di quanto non lo sia ai siti Web mobili. Secondo un articolo allineato su Forbes, ciò è generalmente dovuto alla comodità (ad esempio pulsanti della schermata iniziale, widget, notifiche principali), velocità (ad esempio, interfacce più fluide, avviamenti quasi istantanei) e impostazioni memorizzate (ad esempio offline soddisfare).

I siti Web mobili raggiungono più persone (8,9 milioni di visitatori unici mensili contro 3,3 milioni di app mobili)

D'altra parte, negli stessi dati Comscore, apprendiamo che i clienti possono essere raggiunti più facilmente dai siti Web mobili, poiché non sono così legati alle loro poche app preferite. Se si confrontano i siti Web più popolari con le app più scaricate, si stima che una media di 8,9 milioni di visitatori Web unici al mese acceda ai primi 1000 siti Web. È quasi tre volte più degli utenti unici medi delle prime 1000 app più scaricate.

Distribuzione (app Web) x Coinvolgimento (app mobile)

Questo è tutto sulla distribuzione contro l'impegno. La tua app web ha maggiori possibilità di accesso, in quanto gli utenti hanno maggiori probabilità di provare nuove cose quando navigano attraverso i loro browser mobili. Ma le app mobili hanno dimostrato di essere più coinvolgenti e catturano l'attenzione degli utenti per periodi molto più lunghi.

Ora che hai capito il dilemma, diamo un'occhiata a Progressive Web Apps. Questo è un approccio così legato al livello delle app Web che lo classifico come solo un addendum alle app Web. Ma è un grosso disgregatore e un serio candidato per la novità più importante e interessante nello sviluppo web e mobile.

App Web progressive

Le app Web progressive (PWA) sono un insieme di strumenti utilizzati per offrire agli utenti dell'app Web la stessa esperienza a cui sono abituati quando eseguono app mobili. Ciò significa che le app Web possono sfruttare livelli di distribuzione potenzialmente più elevati con livelli di coinvolgimento più decenti.

Aggiunta progressiva di app Web al livello App Web

Google ha definito tre principali qualifiche per i PWA: devono essere affidabili, veloci e coinvolgenti.

Le funzionalità denominate Service Workers e App Shell sono alla base di Progressive Web Apps. Sono stati creati per promuovere l'affidabilità delle app in quanto ora sono progettati per funzionare indipendentemente dallo stato della connessione del dispositivo. Ciò include la modalità offline e connessioni scadenti. Forniscono inoltre un significativo aumento delle prestazioni percepite, poiché le app si avviano utilizzando dati memorizzati nella cache locale, il che elimina i ritardi per i download di contenuti sincroni.

Potresti considerare l'affidabilità un vettore indiretto di coinvolgimento. Gli utenti non sono interessati durante il viaggio in treno, ad esempio. Possono rimanere fidanzati.

Lo stesso vale per la velocità. Secondo Google:

Il 53% degli utenti abbandonerà un sito se il caricamento richiede più di 3 secondi!

Tuttavia, essere esclusivamente affidabili e veloci sul carico non garantisce necessariamente un elevato impegno. Le PWA sfruttano le funzionalità relative ai dispositivi mobili che erano esclusive delle app mobili, come un'opzione "Aggiungi alla schermata principale" e Notifiche push.

Quando si tratta della funzione "Aggiungi alla schermata principale", potresti notare che Apple ha avuto una funzione simile dal primo iPhone. Alcune persone sostengono addirittura che le app Web progressive sono il nuovo nome di Google per un'idea originale di Apple.

E davvero non puoi essere completamente in disaccordo. Alcune idee in realtà sono in bicicletta. Vengono, vanno via e poi tornano con un nuovo nome e alcuni miglioramenti (ad esempio, i lavoratori del servizio), in modo che possano finalmente rimanere in giro.

D'altra parte, è difficile essere completamente d'accordo. Il discorso di Steve Jobs sul Web 2.0 + AJAX e l'annuncio memorabile dell'iPhone nel WWDC 2007 non sono abbastanza convincenti da chiamarlo come il padre, o anche il profeta, dei PWA.

Ad essere onesti, la funzionalità Aggiungi alla schermata principale su iPhone non è stata altro che una sottile, quasi nascosta, funzione per generare icone desktop che avviano appena le app Web in modalità a schermo intero. Ha tutto l'onere dei cicli di richiesta-risposta HTTP e nessun percorso chiaro attorno alle cache.

Le PWA iniziano dal punto giusto. Esplorano come le installazioni precedenti di app Web non sono necessarie senza perdere il bootstrap lato client di app mobili. Ciò significa che tutto ciò di cui un utente ha bisogno per la sua prima interazione dopo l'avvio potrebbe essere memorizzato nella cache locale (leggi: App Shell) e reso disponibile non appena preme "Aggiungi alla schermata principale".

Passando a un'altra caratteristica ben nota dei PWA, parliamo della funzionalità super coinvolgente (o di nuovo coinvolgimento) del mondo delle app mobili: Notifiche push. Sono messaggi in stile avviso che vengono visualizzati nella barra / area di notifica in alto, nonché nelle schermate di blocco. Hanno il potere di riportare gli utenti alla tua app una volta ricevuta la notifica.

Per rafforzare il fascino dei PWA, Google ha inserito tutte le moderne API Web sotto l'ombrello PWA. Quindi aspettati di vedere cose come Richieste di pagamento, Gestione delle credenziali, WebVR, Sensori, WebAssembly e WebRTC nel contesto di Progressive Web Apps. Ma queste funzionalità non sono necessariamente legate ai PWA e alcuni sono nati anche prima che il termine PWA fosse coniato.

PWA e Apple

Apple, d'altra parte, ha annunciato le sue prime pietre miliari solide verso le PWA solo a marzo 2018. Sebbene ci siano ancora alcune limitazioni, i progressi sono apprezzabili. Alcune delle limitazioni potrebbero essere legate al fatto che Safari è rimasto indietro rispetto ai suoi concorrenti. Altri potrebbero essere attribuiti alla filosofia di Apple di stretto controllo.

Tuttavia, Apple ha un App Store più redditizio di Google. La Apple afferma che più criteri sulle pubblicazioni delle app portano una maggiore affidabilità complessiva e che i PWA sono destinati a danneggiare le entrate dell'App Store. Ciò suggerisce che alcune limitazioni che sembrano essere imposte intenzionalmente (come 50 MB di dimensione massima della cache PWA) costeranno di più per essere revocate.

Purtroppo i PWA non sono perfetti

Le soluzioni Web e, a diversi livelli, tutte le soluzioni multipiattaforma fanno fatica a raggiungere l'eccellenza e la completezza delle App native. Ogni nuova funzionalità e ogni dettaglio particolare di Android o iOS rende sempre più difficile l'accesso a quello nativo man mano che allontani l'app dal livello nativo.

Nel complesso, i PWA risolvono alcuni problemi nel livello App Web. Ma ci sono altri problemi che non possono essere risolti da una soluzione che funziona su un browser.

Cosa risolvono i PWA

  • Più esperienza "nativa"
  • Tempi di caricamento più rapidi
  • Non richiede una connessione a Internet
  • Forzare gli sviluppatori Web a essere consapevoli delle situazioni in cui non esiste una connessione e una connessione non valida
  • Incorporare funzionalità di app mobili come notifiche push, geolocalizzazione o riconoscimento vocale

Quello che non fanno

  • Lentezza inerente
  • Non disponibile sugli app store (ancora)
  • Ancora non completamente supportato da tutti i browser
  • Mancano ancora funzionalità mobili come NFC, Ambient Light, Geofencing
  • Manca anche il supporto per le peculiarità di Android o iOS come PiP, banner per app intelligenti, widget di schermata di avvio e tocco 3D

Nel video qui sotto, faccio una breve panoramica dei PWA.

App ibride

A questo livello, iniziamo a immergerci nel mondo delle app mobili. Partiamo dal livello più distante: le app ibride.

Il termine ibrido viene anche comunemente applicato a tutte le soluzioni multipiattaforma. Qui, tuttavia, lo sto limitando alle app che funzionano all'interno di componenti mobili, chiamate WebViews.

Livello delle app ibride. Sotto la riga del browser ma in cima a WebViews

Nelle demo del secondo video, il mio scopo di aggiungere WebView come esempio Hello World era chiarire che esiste un componente nativo per ogni piattaforma in grado di funzionare come un vero browser.

Cordova / PhoneGap

Soluzioni come Cordova / PhoneGap colmano il divario (scusate per il gioco di parole non ispirato) tra Web e app mobili. Forniscono strumenti per impacchettare codice HTML, JavaScript e CSS dello sviluppatore (così come eventuali risorse extra come immagini o video) e trasformarli in app mobili (sì, app Android o iOS reali). Queste app hanno il loro WebView esclusivamente per interpretare ed eseguire il codice Web originale, a partire dal file "index.html" nella cartella principale dell'app (normalmente chiamata "www"). Inoltre, collegano il codice JavaScript alle API native tramite plugin che sono parzialmente implementati in JavaScript e in parte in una lingua nativa.

Quindi, chiariamo le cose. Le app ibride sono in grado di accedere alle API native (anziché alle API Web), ma sono racchiuse da WebView. Un pulsante con Cordova deve essere un pulsante HTML reso da un WebView invece di un pulsante nativo mobile.

Questo è il livello magico che consente alle aziende di trasferire le proprie app Web su app mobili per essere spedite dagli app store. Quindi è consentito qualsiasi framework Web qui.

Ionico

Strutture come Ionic avvolgono Cordova nelle proprie soluzioni. Con Ionic, non è necessario utilizzare l'interfaccia della riga di comando (CLI) di Cordova, poiché tutti i suoi comandi sono racchiusi nella CLI Ionica.

Di recente, il team Ionic ha deciso di prendere le redini dell'intero stack di app ibride. Così hanno lanciato un sostituto proposto per Cordova chiamato Condensatore. Il condensatore supporta i plug-in Cordova e può essere utilizzato anche da un progetto non ionico.

Puoi guardarmi mentre guardo un campione di Cordova Hello World nel quinto video della serie:

Vantaggi delle app ibride

  • Sono essenzialmente app Web che possono essere spedite agli app store ufficiali
  • Può essere utilizzato con qualsiasi framework / libreria JavaScript
  • Il codice è ancora altamente condivisibile su tutte le piattaforme
  • Accesso a funzioni native (ad esempio, fotocamera, accelerometro, elenco contatti)

Svantaggi delle app ibride

  • Lotta con problemi di prestazioni e consumo di memoria, poiché le visualizzazioni Web sono responsabili del rendering di tutto sullo schermo
  • Devono imitare tutti i componenti dell'interfaccia utente nativi nella parte superiore di una singola visualizzazione Web
  • Più difficile da accettare e pubblicato su App Store
  • Di solito impiega più tempo a disporre di funzionalità native per questi ambienti

Web nativo

Web Native è un livello relativamente nuovo e spesso frainteso. Ecco dove le app Web incontrano i componenti nativi. Sebbene Appcelerator (Axway) Titanium sia in circolazione da molto tempo, ci sono alcuni concorrenti relativamente nuovi che giustificano il fatto di renderlo una categoria completamente separata di app mobili.

Le app native Web non necessitano di WebView poiché parlano direttamente con altri componenti nativi

Come puoi vedere sopra, non esiste una visualizzazione Web per il rendering e l'esecuzione dell'applicazione. Quindi, come viene eseguito JavaScript? È compilato? Bene, se consideri la transpilazione (compilazione da una lingua all'altra - ad esempio da TypeScript a JavaScript), raggruppamento, minimizzazione, manipolazione e offuscamento tutti insieme come una compilazione, sì, viene compilato JavaScript.

Ma il problema è che questo non rende il tuo JavaScript qualcosa di direttamente compreso dai sistemi operativi Android o iOS. E, in teoria, non esiste un componente nativo che funge solo da motore JavaScript senza il gonfiamento del motore di layout HTML.

La strategia è quella di spedire motori JavaScript (normalmente V8 per Android e JavaScriptCore per iOS) insieme al tuo codice. Sebbene abbiano piccole impronte e siano molto veloci, sono qualcosa di esterno che deve essere fornito dalla tua app.

D'altra parte, questo approccio tende ad avere migliori prestazioni dell'interfaccia utente, poiché tutti i componenti sono gli stessi (o sono basati sulla stessa cosa per React Native, ad esempio) di quelli utilizzati dalle app native.

Vantaggi delle app native per il Web

  • Raggiungi entrambe le piattaforme con un unico codebase
  • Quasi le stesse prestazioni delle app native, poiché gestiscono anche i componenti dell'interfaccia utente nativa
  • Sono necessarie modifiche, ma il codice è ancora condivisibile con lo sviluppo web

Svantaggi delle app native per il Web

  • Anche con una singola base di codice, lo sviluppatore deve essere consapevole dei componenti nativi
  • Curva di apprendimento più intensa rispetto alle applicazioni ibride / Web per gli sviluppatori Web, soprattutto quando si tratta di layout

Reagisci nativo

Nella parte 6 della serie, faccio un rapido Hello World in React Native. Questo mostra, su Inspector Layout di Android Studio, quali componenti sono stati renderizzati nell'emulatore. Confronto con gli esempi precedenti, assicurandomi che WebView non sia presente.

Nativescript

Un altro fantastico quadro a cui sono stato particolarmente interessato negli ultimi due anni (ho un corso su Udemy al riguardo - in portoghese), è Nativescript. È simile a React Native ma non è legato al mondo React (c'è comunque un'integrazione non ufficiale, Nativescript-Preact).

Con Nativescript, puoi sviluppare utilizzando JavaScript vanilla, TypeScript, Angular e, più recentemente, Vue. Ovviamente puoi usare altri framework, ma quelli sono quelli ufficialmente supportati. A proposito, è anche abbastanza ben documentato.

Nativescript ha strumenti come Nativescript Sidekick e Nativescript Playground, nonché strutture di progetto basate su modelli che possono essere forniti dalla comunità. Ciò dovrebbe aiutarti nella creazione del progetto, dandoti la possibilità di avviare, distribuire, testare ed eseguire simulatori su dispositivi cloud e iPhone anche quando non stai sviluppando utilizzando un Mac.

Nella settima parte della serie, faccio un Hello World usando Sidekick insieme a un altro progetto iniziato dalla CLI e un modello di clone di WhatsApp che ho creato a scopo di apprendimento.

È importante dare un'occhiata a Inspector layout quando l'app è in esecuzione su un emulatore Android. Con Nativescript, mostra i componenti nativi (di nuovo, senza WebView) e le istanze dirette di classi Android comuni come TextView. Questo è diverso da React Native, che ha le sue classi per avvolgere i componenti nativi.

Questo è probabilmente il motivo per cui Nativescript afferma che non c'è alcun ritardo tra quando una nuova funzionalità è disponibile su iOS e Android e quando puoi usarla in un progetto Nativescript. Ad esempio, hanno pubblicato sul loro blog un progetto AR lo stesso giorno in cui iOS 11 è stato ufficialmente rilasciato con la nuova API ARKit.

weex

Un altro framework degno di nota in questa categoria è Weex. È un progetto sviluppato da Alibaba ed è attualmente incubato presso la Apache Sofware Foundation (ASF). Utilizza invece tag HTML comuni come

e comandi CSS all'interno di tag