Een zeer gedetailleerde, maar nooit definitieve gids voor mobiele ontwikkelingsarchitectuur

Native, Web, PWA, hybride, Cross-Compiled ... wat is "de beste" manier om te ontwikkelen voor Android- en iOS-platforms? Wat ziet er redelijk uit? En hoe moet je kiezen tussen de opties? In dit artikel leg ik alles uit, zodat u een weloverwogen beslissing kunt nemen.

Eerst en vooral, laat me je wat context geven. Ik ben een IT-senior consultant en het idee om deze gids samen te stellen is ontstaan ​​uit gesprekken met een van onze klanten over wat voor hen de beste aanpak zou kunnen zijn. Ja, alleen voor hen. En we realiseerden ons dat we geen goed gedefinieerde strategie, een solide en betrouwbare basis hadden om ons te helpen het juiste antwoord te vinden.

En weet je wat? Ik kon zo'n gids ook nergens op internet vinden. Hoewel er verschillende artikelen over dit onderwerp zijn, was geen van deze die ik tegenkwam redelijk compleet. Helaas ziet de meerderheid veel concepten over het hoofd, of, erger nog, is het in wezen verkeerd.

Nu wil ik een bredere blik werpen. En hoewel ik mogelijk iemand help om hun eigen beslissingen te nemen, vraag ik ook in de hele gemeenschap om meer gedachten over het onderwerp.

Deze gids bestaat uit twee delen:

  1. Mobile Development Architectural Tiers (this)
  2. Hoe u uw beslissing neemt

Het is ook beschikbaar op YouTube als een serie van 10 video's en als een gratis cursus op Udemy. Daar vind je hetzelfde geschreven materiaal als hier, dezelfde video's uit de YouTube-serie, evenals quizzen om alle onderwerpen op te lossen en een definitieve certificering.

Dus laten we beginnen.

Invoering

Als het gaat om mobiele platforms, is het betwistbaar dat er slechts twee grote spelers zijn: Android en iOS. Andere technologieën zoals Tizen, Blackberry of Windows Phone zijn dood of bestaan ​​al een tijdje en hebben geen uitzicht op een significant marktaandeel.

Een snelle blik op dit enorme duopolie kan je doen denken dat ontwikkelaars niet veel opties hebben bij het maken van mobiele apps. Dit idee kan echter niet minder waar zijn. Je kunt snel zien dat er een handvol programmeertalen wordt gebruikt: C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby, en ik ben er vrij zeker van dat ik er een paar heb gemist meer.

Hetzelfde geldt voor mobiele ontwikkelkaders. Tenzij u geen ontwikkelaar bent of de laatste 10 jaar op de een of andere manier niet op de hoogte bent geweest van nieuwe technologieën, heeft u waarschijnlijk gehoord over Cordova / PhoneGap, React Native, Xamarin, Ionic, Nativescript of Flutter, om maar een paar te noemen- platformoplossingen voor mobiele apps.

Laten we dus naar al deze delen van de architectuur kijken en de zaken een beetje opsplitsen.

TL; DR

Er is geen duidelijke winnaar. Alle benaderingen hebben voor- en nadelen en zijn misschien het beste of het slechtst geschikt voor uw volgende project. In deze gids classificeer ik veel verschillende oplossingen in verschillende niveaus op basis van de afstand die hun architecturen zijn ten opzichte van het native platform.

Inheemse apps

Laten we om te beginnen meteen naar het metaal gaan. Onze eerste architecturale laag is Native Apps.

Native Apps-niveau - waar u ontwikkelt voor elk specifiek platform (het kan zelfs nog specifieker zijn als u NDK overweegt)

Dit is het niveau waarop u zich bewust moet zijn van de eigenaardigheden van elk platform. Het is niet mijn bedoeling er in te graven, ik wil alleen een paar dingen noemen in een beetje context.

iOS

Beginnend met de iOS-kant, alleen omdat het eenvoudiger is, regeert alleen Apple de wereld. Oorspronkelijk moesten ontwikkelaars Objective-C leren, een eigen objectgeoriënteerde variatie van C met enige inspiratie van SmallTalk (en een waanzinnig lange API).

In 2014 kondigde Apple Swift aan, een taal met meerdere paradigma's, die een stuk eenvoudiger was dan zijn voorganger. Het is nog steeds mogelijk om met oude Objective-C-code om te gaan, maar Swift heeft een hoog volwassenheidsniveau bereikt. Dus als je van plan bent om te leren hoe je native voor iOS kunt ontwikkelen, is Swift zeker waar je moet beginnen.

Android

Aan de Android-kant zijn er een aantal verschillende fabrikanten. De overgrote meerderheid van hen vertrouwt op ARM-processors. Maar over het algemeen zijn Android-apps gebaseerd op instanties van virtuele machines (instanties van ART) om te helpen omgaan met mogelijke onderliggende specificiteiten (niet zonder veel geweldige trucs).

Dat is de reden waarom oorspronkelijk de taal van keuze Java was. Het is niet alleen de meest populaire taal ter wereld sinds bijna twee decennia (met een paar positie-swaps met C), maar het is ook opmerkelijk voor zijn Java Virtual Machine (JVM). Dit stelde ontwikkelaars in staat om hun code te compileren tot een tussenliggende bytecode die door de JVM kon worden gelezen en uitgevoerd.

Met de Android Native Development Kit (NDK) is het ook mogelijk om kritieke delen van de app direct in native code te ontwikkelen, schrijven in C / C ++. In dit geval moet u zich bewust zijn van onderliggende platform eigenaardigheden.

Kotlin is een taal onthuld door JetBrains in 2011. Toen het voor het eerst uitkwam, ondanks zijn flexibiliteit en beknoptheid, was het niet meer dan nog een andere JVM-taal met meer succesvolle concurrenten zoals Scala, Clojure of Groovy. Na de eerste grote release in 2016 begon het echter snel op te vallen, vooral nadat Google had aangekondigd dat het officieel zou worden ondersteund op het Android-platform op Google I / O 2017.

Kotlin wordt de eerste klas taal van Google (momenteel worden Kotlin en Java - in deze volgorde - gebruikt in de officiële documentatie van Android). Een totale vervanging van Java wordt zelfs nog meer verwacht, nu het Amerikaanse Federale Hof van Beroep uitspraak heeft gedaan over de eindeloze rechtszaak aangespannen door Oracle die Google ervan beschuldigt Java-auteursrechten te hebben geschonden.

Inheemse componenten

Als u zich in deze laag ontwikkelt, kunt u ook gebruikmaken van alle native API's en met name de native componenten. Hierdoor hoeft uw app het wiel niet opnieuw uit te vinden.

Ik heb een videodemo gepubliceerd over het maken van een eenvoudig project op Xcode (iOS) en Android Studio. Als je het wilt bekijken:

Native Apps-voordelen

  • Beste prestaties en maximale gebruikersbetrokkenheid
  • Bloedende rand native functies
  • Met name goede IDE's Android Studio / Xcode
  • Moderne talen op hoog niveau Kotlin / Swift
  • Nadere benadering op zeer laag niveau met NDK

Native Apps-nadelen

  • Twee codebases om te onderhouden
  • Installatie vereist (behalve Android Instant Apps)
  • Moeilijk te analyseren SEO
  • Erg duur om gebruikers de app te laten downloaden

Web-apps

Aan de andere kant van het spectrum hebben we webapps. Web-apps zijn in wezen apps die door de browser worden uitgevoerd. U schrijft geen code die gericht is op het platform, maar eerder elke browser die erop draait.

Web Apps Tier - duidelijk bovenop een browserbalk gericht op een beest dat tussen Android en iOS zit.

In deze laag vind je een waanzinnig aantal kanshebbers die naar elkaars keel springen. Maar ze gebruiken allemaal een arsenaal dat bestaat uit dezelfde wapens: HTML, CSS en Javascript.

Webframes en bibliotheken, zelfs wanneer gebruik wordt gemaakt van CSS-voorcompilers zoals MINDER of SASS, zelfs Javascript-vooraf gecompileerde talen zoals TypeScript, CoffeeScript of Flow, zelfs symbiose zoals JSX of Elm, waardoor alleen tools zoals Babel werden gebruikt om alles naar Javascript te transpileren met verschillende configureerbare niveaus van overeenstemming met de jaarlijkse specificaties van ECMAScript (ES6 / ES7 / ES8, of als u de voorkeur geeft aan ES2015 / ES2016 / ES2017 / ES2018).

Aan het einde van de dag zijn ze allemaal HTML, CSS en JavaScript, gerenderd en uitgevoerd door de browser. Er is geen directe toegang tot native API's zoals camera, vibratie, batterijstatus of bestandssysteem, maar sommige kunnen worden bereikt via Web API's:

Kan ik vertrouwen op de functies van het webplatform om mijn app te bouwen?

Het grote probleem met web-API's is hun volwassenheidsniveau. Velen van hen worden niet ondersteund door sommige browsers. Er zijn verschillen in implementaties, vooral tussen mobiele browsers.

Web App voordelen

  • Gedeelde code tussen platforms en desktopbrowsers
  • Geen eerdere installaties vereist, gewoon navigeren en gebruiken
  • Tal van frameworks en bibliotheken die daarbij horen
  • Het beste voor SEO

Web App nadelen

  • Lagere prestaties
  • Moeilijk om een ​​native gebruikerservaring te krijgen
  • Vereist een internetverbinding
  • Niet beschikbaar in officiële app-winkels
  • API niet zo volwassen en betrouwbaar als native API

Frameworks en webcomponenten

Angular, React en Vue zijn waarschijnlijk de meest populaire webframes vanaf 2018. Om precies te zijn, React wordt echter beschouwd als slechts een bibliotheek vanwege zijn flexibele en minder eigenzinnige karakter. Angular daarentegen is een sterk eigenzinnig raamwerk. Vue leeft ergens tussen hen in.

Angular vs React vs Vue

Angular, oorspronkelijk AngularJS genoemd, werd in 2010 door Google aan de wereld gepresenteerd. Het begon snel te schitteren, vanwege zijn inversie van paradigma's in vergelijking met andere bibliotheken uit die tijd (zoals jQuery, de meest populaire destijds). In plaats van rechtstreeks met HTML-elementen te praten om de UI-status te manipuleren, werden met AngularJS sjablonen op magische wijze bijgewerkt telkens wanneer het JavaScript-model werd bijgewerkt.

Naarmate AngularJS steeds populairder werd, groeide het ook in doel. Het werd een compleet en eigenzinnig raamwerk dat een van de eerste was die SPA's (Single Page Apps) serieus nam. Deze groei (in beide aspecten) was verantwoordelijk voor enkele API-bloats en prestatieproblemen.

React is gemaakt door Facebook om hun eigen behoeften op de presentatielaag op te lossen. Het introduceerde vele aspecten die plotseling erg populair werden, zoals virtuele DOM, eenrichtingsgegevensstroom (oorspronkelijk Flux genoemd, vooral populair via een implementatiebibliotheek genaamd Redux), en een combinatie van HTML en JavaScript genaamd JSX.

Pas in 2016, na lange debatten en onverwachte grote veranderingen, lanceerde Google versie twee van zijn populaire webframework. Ze noemden het Angular, in plaats van AngularJS. Maar, zoals veel mensen de eerste versie al "Angular" noemden (zonder het "JS" achtervoegsel), begonnen mensen de nieuwe versie Angular 2 te noemen. 6 maanden.

Naar mijn mening was dat een gigantische fout. Ik heb dit eerder gezien (bijvoorbeeld met Struts vs Struts 2 / WebWork). Ze hebben een enorm populair product dat zijn plateau lijkt te hebben bereikt en het wordt meer bekritiseerd dan geprezen. Als Google besluit het vanaf de grond opnieuw op te bouwen, mogen ze nooit de belangrijkste versie wijzigen. Hoe zullen mensen erop vertrouwen dat ze het niet elke nieuwe belangrijke versie zullen herhalen? Versie twee wordt verondersteld brekende veranderingen te presenteren, maar het betekent niet dat het volledig kan worden vernieuwd.

Angular is een spectaculair webframework en ik heb er echt een passie voor. Het is echter een volledig nieuw beest. Het heeft niet veel te maken met AngularJS. Zelfs Vue, wat een ander verbazingwekkend kader is (waarschijnlijk een van de meest prettige om mee te werken, trouwens) lijkt vanuit vogelperspectief meer op AngularJS. Ik geloof dat dit een significante beweging van Angular veroorzaakte en substantieel heeft bijgedragen aan de populariteit van React.

Vue is de enige van de drie meest populaire webframes die niet door een groot bedrijf wordt ondersteund. Het is eigenlijk gestart door een voormalige Google-ontwikkelaar. Vanwege zijn formidabele eenvoud en kleine voetafdruk, kreeg het aandacht van een enorme en enthousiaste gemeenschap.

Hoewel er meer complete oplossingen zijn, werken ze allemaal bovenop het concept van webcomponenten. Er is momenteel een open specificatie over hen aan de gang in W3C, en enkele interessante implementaties zoals Polymer, Stencil en X-Tag.

In de derde video van de serie besteed ik niet te veel tijd aan het bespreken van frameworks, maar aan het bespreken van webcomponentbibliotheken:

Mobiele apps versus webapps

Ik weet niet zeker of je het hebt gemerkt, maar de volgorde van de lagen die ik hier presenteer, volgt wat ik denk dat het gemakkelijkste pad is om alle benaderingen te leren. Ik begon met de Native Tier, de meest echt mobiele ontwikkeling. Toen besloot ik om direct naar het andere uiterste te vliegen om de weblaag te presenteren, de laag die sinds de eerste smartphones beschikbaar is.

Pas nu, na een vergelijking tussen de twee randen van mijn diagram te hebben gemaakt, zal ik beginnen te praten over veel van de platformonafhankelijke benaderingen om mobiele apps te bouwen.

Er is een lang debat tussen mobiele apps en web-apps. Alles wat ik over mobiele apps zeg, is niet exclusief voor de Native Tier. Het is ook van toepassing op alle platformoverschrijdende niveaus die ik later presenteer.

Het dilemma van gebruikersgedrag

Gebruikers brengen meer tijd door op mobiele apps (87%) dan op mobiele websites (13%)

Volgens een Comscore-enquête in 2017 is de trouw van een gebruiker aan een mobiele app veel relevanter dan aan mobiele websites. Volgens een uitgelijnd artikel op Forbes is dit meestal vanwege het gemak (bijvoorbeeld knoppen op het startscherm, widgets, topmeldingen), snelheid (bijvoorbeeld vloeiendere interfaces, bijna onmiddellijk opstarten) en opgeslagen instellingen (bijvoorbeeld offline inhoud).

Mobiele websites bereiken meer mensen (8,9 miljoen maandelijkse unieke bezoekers tegen 3,3 miljoen mobiele apps)

Aan de andere kant leren we in dezelfde Comscore-gegevens dat klanten gemakkelijker bereikbaar zijn via mobiele websites, omdat ze niet zozeer gebonden zijn aan hun paar voorkeursapps. Als u de populairste websites vergelijkt met de meest gedownloade apps, wordt geschat dat gemiddeld 8,9 miljoen unieke webbezoekers per maand toegang hebben tot de top 1000 websites. Dat is bijna drie keer meer dan de gemiddelde unieke gebruikers van de top 1000 meest gedownloade apps.

Distributie (web-app) x betrokkenheid (mobiele app)

Dat draait allemaal om distributie versus betrokkenheid. Uw web-app heeft een grotere kans om te worden benaderd, omdat gebruikers eerder nieuwe dingen proberen tijdens het navigeren door hun mobiele browsers. Maar het is bewezen dat mobiele apps aantrekkelijker zijn en de aandacht van gebruikers voor veel langere periodes trekken.

Nu u het dilemma begrijpt, gaan we eens kijken naar Progressive Web Apps. Dit is een benadering die zo verbonden is met de laag Web Apps dat ik deze classificeer als een addendum bij Web Apps. Maar het is een grote disruptor en een serieuze kandidaat voor het meest prominente nieuwe en coole ding in web- en mobiele ontwikkeling.

Progressive Web Apps

Progressive Web Apps (PWA's) zijn een set tools die worden gebruikt om Web App-gebruikers dezelfde ervaring te bieden als ze gewend zijn wanneer ze mobiele apps uitvoeren. Dit betekent dat Web Apps de potentieel hogere distributieniveaus kan benutten met meer fatsoenlijke niveaus van betrokkenheid.

Progressive Web Apps-addendum bij Web Apps-laag

Google heeft drie hoofdkwalificaties voor PWA's gedefinieerd: deze moeten betrouwbaar, snel en aantrekkelijk zijn.

Functies genaamd Service Workers en de App Shell vormen de basis van Progressive Web Apps. Ze zijn gemaakt om de betrouwbaarheid van apps te bevorderen, omdat ze nu zijn ontworpen om te werken, ongeacht de verbindingsstatus van het apparaat. Dat omvat de offline modus, evenals slechte verbindingen. Ze bieden ook een aanzienlijke waargenomen prestatieverbetering, aangezien apps worden gestart met behulp van lokaal in de cache opgeslagen gegevens, waardoor vertragingen voor het downloaden van synchrone inhoud worden geëlimineerd.

Je zou betrouwbaarheid kunnen beschouwen als een indirecte vector van betrokkenheid. Gebruikers worden bijvoorbeeld niet getroffen tijdens het woon-werkverkeer per trein. Ze kunnen verloofd blijven.

Hetzelfde geldt voor snelheid. Volgens Google:

53% van de gebruikers verlaat een site als het langer dan 3 seconden duurt om te laden!

Exclusief betrouwbaar en snel bij het laden garandeert echter niet noodzakelijk een hoge betrokkenheid. PWA's maken gebruik van aan mobiel gerelateerde functies die voorheen exclusief waren voor mobiele apps, zoals een optie 'Toevoegen aan startscherm' en pushmeldingen.

Als het gaat om de functie "Toevoegen aan startscherm", merkt u misschien dat Apple een soortgelijke functie heeft sinds de allereerste iPhone. Sommige mensen beweren zelfs dat Progressive Web Apps de mooie nieuwe naam van Google is voor een origineel idee van Apple.

En je kunt het echt niet helemaal oneens zijn. Sommige ideeën zijn eigenlijk fietsen. Ze komen, gaan weg en komen dan terug met een nieuwe naam en enkele verbeteringen (bijvoorbeeld Service Workers), zodat ze eindelijk kunnen blijven.

Aan de andere kant is het moeilijk om het volledig eens te zijn. De toespraak van Steve Jobs over Web 2.0 + AJAX en de gedenkwaardige aankondiging van de iPhone in WWDC 2007 zijn niet overtuigend genoeg om hem als de vader of zelfs de profeet van PWA's te noemen.

Om eerlijk te zijn, de functie Toevoegen aan startscherm op iPhone was niets meer dan een subtiele, bijna verborgen functie om bureaubladpictogrammen te genereren die net Web Apps in volledig scherm opstarten. Het heeft alle last van HTTP-verzoek-antwoordcycli en geen duidelijk pad rond caches.

PWA's beginnen vanaf het juiste punt. Ze onderzoeken hoe eerdere installaties van web-apps niet nodig zijn zonder de bootstrap aan clientzijde van mobiele apps te verliezen. Dit betekent dat alles wat een gebruiker nodig heeft voor hun eerste interactie na het opstarten lokaal in de cache kan worden opgeslagen (lees: App Shell) en beschikbaar wordt gehouden zodra ze op 'Toevoegen aan startscherm' klikken.

Laten we verder gaan met een ander bekend kenmerk van PWA's, laten we het hebben over de super boeiende (of opnieuw boeiende) functie van de mobiele apps-wereld: pushmeldingen. Het zijn berichten in waarschuwingsstijl die op de bovenste meldingenbalk / gebied verschijnen, evenals op vergrendelingsschermen. Ze hebben de mogelijkheid om gebruikers terug te trekken naar uw app zodra ze de melding hebben ontvangen.

Om de aantrekkingskracht van PWA's te vergroten, heeft Google alle moderne web-API's onder de paraplu van PWA geplaatst. Dus verwacht dingen als Betalingsverzoeken, Referentiebeheer, WebVR, Sensoren, WebAssembly en WebRTC te zien in de context van Progressive Web Apps. Maar deze functie is niet noodzakelijkerwijs gekoppeld aan PWA's, en sommige werden zelfs geboren voordat de term PWA werd bedacht.

PWA en Apple

Apple heeft daarentegen pas in maart 2018 hun eerste solide mijlpalen voor PWA's aangekondigd. Hoewel er nog enkele beperkingen zijn, is de vooruitgang merkbaar. Sommige beperkingen kunnen verband houden met het feit dat Safari achterop is geraakt bij zijn concurrenten. Anderen kunnen worden toegeschreven aan Apple's filosofie van strakke controle.

Toch heeft Apple een meer winstgevende App Store dan Google. Apple beweert dat meer criteria voor app-publicaties voor meer algemene betrouwbaarheid zorgen en dat PWA's de inkomsten van de App Store ongetwijfeld zullen schaden. Dit suggereert dat sommige beperkingen die opzettelijk zijn opgelegd (zoals 50 MB PWA maximale cachegrootte) meer zullen kosten om te worden ingetrokken.

Helaas zijn PWA's niet perfect

Weboplossingen en, op verschillende niveaus, alle platformonafhankelijke oplossingen worstelen om de excellentie en volledigheid van native apps te bereiken. Elke nieuwe functie en elk detail specifiek voor Android of iOS zorgt ervoor dat die native moeilijker en moeilijker toegankelijk is wanneer u uw app van de native laag verwijdert.

Over het algemeen lossen PWA's enkele problemen op in de laag Web Apps. Maar er zijn andere problemen die niet kunnen worden opgelost door een oplossing die boven op een browser werkt.

Wat PWA's oplossen

  • Meer "native" ervaring
  • Snellere laadtijden
  • Geen internetverbinding vereist
  • Dwing webontwikkelaars om zich bewust te zijn van situaties waarin er geen verbinding is of een slechte verbinding
  • Gebruik functies van mobiele apps zoals pushmeldingen, geolocatie of spraakherkenning

Wat ze niet doen

  • Inherente traagheid
  • Nog niet beschikbaar in app-winkels
  • Nog steeds niet volledig ondersteund door alle browsers
  • Ontbreekt nog steeds aan mobiele functies zoals NFC, Ambient Light, Geofencing
  • Ook ontbreekt ondersteuning voor eigenaardigheden van Android of iOS zoals PiP, slimme app-banners, startschermwidgets en 3D-aanraking

In de onderstaande video geef ik een kort overzicht van PWA's.

Hybride apps

Op dit niveau beginnen we in de wereld van de mobiele app te duiken. We gaan uit van de meest verre laag: hybride apps.

De term hybride wordt ook vaak toegepast op alle platformonafhankelijke oplossingen. Hier beperk ik het echter tot apps die werken binnen mobiele componenten, WebViews genoemd.

De laag Hybride apps. Onder de regel van de browser maar bovenop WebViews

In de demo's in de tweede video was mijn doel om WebView toe te voegen als het Hello World-voorbeeld om duidelijk te maken dat er voor elk platform een ​​native component is die kan werken als een echte browser.

Cordova / PhoneGap

Oplossingen zoals Cordova / PhoneGap dichten het gat (sorry voor de ongeïnspireerde woordspeling) tussen web- en mobiele apps. Ze bieden tools om HTML, JavaScript en CSS-code van ontwikkelaars te verpakken (evenals eventuele extra middelen zoals afbeeldingen of video's) en deze om te zetten in mobiele apps (ja, echte Android- of iOS-apps). Deze apps hebben hun WebView exclusief om de originele webcode te interpreteren en uit te voeren, beginnend met het "index.html" -bestand in de hoofdmap van de app (normaal "www" genoemd). Ze overbruggen de JavaScript-code ook naar native API's via plug-ins die gedeeltelijk zijn geïmplementeerd in JavaScript en gedeeltelijk in een moedertaal.

Laten we het dus duidelijker maken. Hybride apps hebben toegang tot native API's (in plaats van web-API's), maar ze zijn ingesloten door de WebView. Een knop met Cordova moet een HTML-knop zijn die wordt weergegeven door een WebView in plaats van een native mobiele knop.

Dit is het magische niveau waarmee bedrijven hun web-apps kunnen overzetten naar mobiele apps die door app-winkels kunnen worden verzonden. Dus elk webframework is hier toegestaan.

ionisch

Frameworks zoals Ionische wikkel Cordova in hun eigen oplossingen. Met Ionic hoeft u de opdrachtregelinterface (CLI) van Cordova niet te gebruiken, omdat alle opdrachten door de Ionic CLI worden verpakt.

Onlangs besloot het Ionische team de teugels van de hele stapel hybride apps te nemen. Dus lanceerden ze een voorgestelde vervanging voor Cordova genaamd Capacitor. Condensator ondersteunt Cordova-plug-ins en kan ook worden gebruikt door een niet-Ionisch project.

Je kunt me door een Cordova Hello World-sample zien gaan in de vijfde video van de serie:

Voordelen van hybride apps

  • Het zijn in wezen web-apps die kunnen worden verzonden naar officiële app-winkels
  • Kan samen met elk JavaScript-framework / bibliotheek worden gebruikt
  • De code is nog steeds zeer deelbaar op verschillende platforms
  • Toegang tot native functies (bijvoorbeeld camera, versnellingsmeter, contactenlijst)

Nadelen van hybride apps

  • Worstel met prestatieproblemen en geheugenverbruik, omdat webweergaven verantwoordelijk zijn voor het weergeven van alles op het scherm
  • Moet alle native UI-componenten nabootsen bovenop een enkele webweergave
  • Moeilijker te worden geaccepteerd en gepubliceerd in de App Store
  • Meestal duurt het langer om native functies beschikbaar te hebben voor deze omgevingen

Web native

Web Native is een relatief nieuwe en vaak verkeerd begrepen laag. Dat is waar Web Apps native componenten ontmoeten. Hoewel Appcelerator (Axway) Titanium al heel lang bestaat, zijn er een aantal relatief nieuwe concurrenten die rechtvaardigen dat dit een volledig aparte categorie mobiele apps is.

Web Native Apps hebben geen WebView nodig omdat ze rechtstreeks met andere native componenten praten

Zoals u hierboven kunt zien, is er geen webweergave om uw toepassing te renderen en uit te voeren. Dus, hoe wordt uw JavaScript uitgevoerd? Is het gecompileerd? Nou, als je transpilatie (compilatie van de ene taal naar de andere - bijvoorbeeld TypeScript naar JavaScript), bundeling, minification, mangling en obfuscation allemaal samen als een compilatie beschouwt, ja JavaScript is gecompileerd.

Maar het probleem is dat uw JavaScript hierdoor niet direct wordt begrepen door operationele besturingssystemen van Android of iOS. En in theorie is er geen native component die alleen als JavaScript-engine fungeert zonder de bloat van de HTML-layout-engine.

De strategie is om JavaScript-motoren (normaal V8 voor Android en JavaScriptCore voor iOS) samen met uw code te verzenden. Hoewel ze kleine voetafdrukken hebben en erg snel zijn, zijn ze iets externs dat door uw app moet worden geleverd.

Aan de andere kant heeft deze aanpak de neiging om betere UI-prestaties te hebben, omdat alle componenten hetzelfde zijn (of bijvoorbeeld gebaseerd zijn op hetzelfde voor React Native) als die welke worden gebruikt door Native Apps.

Voordelen van Web Native Apps

  • Bereik beide platforms met één enkele codebasis
  • Ongeveer dezelfde prestaties als native apps, omdat ze ook omgaan met native UI-componenten
  • Tweaks zijn noodzakelijk, maar de code kan nog steeds worden gedeeld met webontwikkeling

Web Native Apps nadelen

  • Zelfs met één enkele codebase, moet de ontwikkelaar op de hoogte zijn van native componenten
  • Steilere leercurve dan hybride / web-apps voor webontwikkelaars, vooral als het gaat om de lay-out

Reageer native

In deel 6 van de serie doe ik een snelle Hello World in React Native. Dit toont in Layout Inspector van Android Studio welke componenten in de emulator zijn weergegeven. Ik vergelijk met de vorige voorbeelden en zorg ervoor dat er geen enkele WebView is.

Nativescript

Een ander geweldig kader waar ik de afgelopen twee jaar bijzonder in geïnteresseerd ben (ik heb er een cursus over Udemy over - in het Portugees), is Nativescript. Het lijkt op React Native maar is niet gebonden aan de React-wereld (er is echter een onofficiële integratie, Nativescript-Preact).

Met Nativescript kunt u ontwikkelen met behulp van vanille JavaScript, TypeScript, Angular en, meer recent, Vue. Natuurlijk kunt u andere frameworks gebruiken, maar dat zijn degenen die officieel worden ondersteund. Het is trouwens ook redelijk goed gedocumenteerd.

Nativescript heeft tools zoals Nativescript Sidekick en Nativescript Playground, evenals projectstructuren op basis van sjablonen die door de community kunnen worden geleverd. Dit zou u moeten helpen bij het maken van projecten, zodat u simulators op de cloud en iPhone-apparaten kunt starten, implementeren, testen en uitvoeren, zelfs wanneer u niet bezig bent met het ontwikkelen van een Mac.

In het zevende deel van de serie doe ik een Hello World met behulp van Sidekick samen met een ander project dat is gestart vanuit de CLI en een WhatsApp-kloon-sjabloon die ik heb gemaakt voor leerdoeleinden.

Het is belangrijk om eens naar de Layout Inspector te kijken wanneer uw app op een Android-emulator draait. Met Nativescript toont het de native componenten (alweer geen WebView) en directe instanties van veelgebruikte Android-klassen zoals TextView. Dit is anders dan React Native, dat zijn eigen klassen heeft om de native componenten te verpakken.

Dat is waarschijnlijk de reden waarom Nativescript beweert dat er geen vertraging is tussen het moment waarop een nieuwe functie beschikbaar is op iOS en Android en wanneer je het kunt gebruiken in een Nativescript-project. Ze plaatsten bijvoorbeeld op hun blog een AR-project op dezelfde dag dat iOS 11 officieel werd vrijgegeven met de nieuwe ARKit API.

weex

Een ander vermeldenswaardig kader in deze categorie is Weex. Het is een project ontwikkeld door Alibaba en wordt momenteel geïncubeerd bij Apache Sofware Foundation (ASF). Het gebruikt algemene HTML-tags zoals

en CSS-opdrachten in