Syvästi yksityiskohtainen, mutta ei koskaan lopullinen opas matkapuhelimen kehitysarkkitehtuuriin

Native, Web, PWA, hybridi, Cross-Compiled… mikä on “paras” tapa kehittää Android- ja iOS-alustoille? Mikä näyttää kohtuulliselta? Ja miten sinun pitäisi valita vaihtoehdoista? Esitän tässä artikkelissa kaiken, jotta voit tehdä tietoisen päätöksen.

Ensinnäkin, annan minun tarjota sinulle vähän asiayhteyttä. Olen tietotekniikan vanhempi konsultti, ja ajatus tämän oppaan laatimisesta syntyi keskusteluista yhden asiakkaamme kanssa siitä, mikä voisi olla paras lähestymistapa heille. Kyllä, vain heille. Ja huomasimme, että meillä ei ollut tarkkaan määriteltyä strategiaa, vankkaa ja luotettavaa perustaa auttaaksemme meitä löytämään oikea vastaus.

Ja tiedätkö mitä? En myöskään löytänyt sellaista opasta helposti mistään Internetistä. Vaikka aiheesta on useita artikkeleita, mikään niistä, jotka tapasin, eivät olleet kohtuullisen täydellisiä. Valitettavasti suurin osa jättää huomiotta monia käsitteitä tai, mikä vielä pahempaa, ovat pääosin vääriä.

Nyt haluaisin katsoa laajemmin. Ja vaikka autan potentiaalisesti jotakuta tekemään omia päätöksiään, pyydän myös koko yhteisöä lisää ajatuksia aiheesta.

Tässä oppaassa on kaksi osaa:

  1. Mobiilirakennuksen arkkitehtoniset tasot (tämä)
  2. Kuinka tehdä päätöksesi

Se on saatavana myös YouTubessa 10 videosarjana ja ilmaisena kurssina Udemylle. Sieltä löydät saman kirjallisen materiaalin kuin täältä, samat videot YouTube-sarjasta, samoin kuin tietovisat kaikkien aiheiden korjaamiseksi ja lopullisen sertifikaatin.

Joten aloitetaan.

esittely

Mobiilialustojen suhteen on kiistanalaista, että on vain kaksi suurta pelaajaa: Android ja iOS. Muut tekniikat, kuten Tizen, Blackberry tai Windows Phone, ovat joko kuolleita tai olleet olemassa jo jonkin aikaa, eikä niillä ole mitään mahdollisuuksia saavuttaa merkittävää markkinaosuutta.

Nopea katsaus tähän massiiviseen duopoliin saattaa ajatella, että kehittäjillä ei ole monia vaihtoehtoja mobiilisovelluksia luotaessa. Tämä ajatus ei kuitenkaan voi olla kauempana totuudesta. Voit nopeasti havaita kymmenen ohjelmointikieltä, joita siellä käytetään: C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby, ja olen melko varma, että olen ohittanut muutaman lisää.

Sama pätee liikkuvan kehityksen puitteisiin. Ellet ole kehittäjä tai et ole jotenkin tiennyt uusista tekniikoista viimeisen 10 vuoden aikana, olet todennäköisesti kuullut Cordova / PhoneGapista, React Nativeista, Xamarinista, Ionicista, Nativescriptista tai Flutterista. alustaratkaisut mobiilisovelluksille.

Katsotaanpa siis kaikkia näitä arkkitehtuurin kappaleita ja hajotettava asiat hiukan.

TL; DR

Ei ole selkeää voittajaa. Kaikilla lähestymistavoilla on etuja ja haittoja, ja ne saattavat olla parhaiten sopivia tai pahimpia seuraavalle projektillesi. Tässä oppaassa luokittelen monia erilaisia ​​ratkaisuja eri tasoille sen etäisyyden mukaan, jonka niiden arkkitehtuurit ovat alkuperäisestä alustasta.

Alkuperäiset sovellukset

Aloitetaan, siirrytään suoraan metalliin. Ensimmäinen arkkitehtoninen tasomme on Native Apps.

Alkuperäisten sovellusten taso - Missä kehität jokaiselle tietylle alustalle (se saattaa olla vielä tarkempi, kun otetaan huomioon NDK)

Tämä on taso, jossa sinun on oltava tietoinen kunkin alustan ominaispiirteistä. Minulla ei ole aikomusta kaivaa niitä, haluan vain mainita joitain asioita vähän yhteydessä.

iOS

Alkaen iOS-puolelta, koska se on yksinkertaisempaa, maailmaa hallitsee vain Apple. Alun perin kehittäjien piti oppia Objective-C, C: n omaisuuteen suuntautunut objektiorientoitu variaatio, josta oli saatu inspiraatiota SmallTalk (ja mieletöntä pitkään nimeltään API).

Vuonna 2014 Apple julkaisi Swift-monikanavan kielen, joka oli paljon helpompi kuin edeltäjänsä. On edelleen mahdollista käsitellä Objective-C-vanhaa koodia, mutta Swift on saavuttanut korkean kypsyysasteen. Joten, jos aiot oppia kehittämään luonnollisesti iOS: lle, Swift on ehdottomasti minne sinun pitäisi aloittaa.

Android

Android-puolella on useita erilaisia ​​valmistajia. Suurin osa heistä luottaa ARM-prosessoreihin. Mutta yleisesti ottaen, Android-sovellukset sijoittuvat virtuaalikoneen ilmentymiin (ART-esiintymät) auttamaan käsittelemään mahdollisia taustalla olevia erityispiirteitä (ei ilman monia uskomattomia temppuja).

Siksi alun perin valittu kieli oli Java. Se ei ole vain ollut suosituin kieli maailmassa melkein kahden vuosikymmenen ajan (muutamalla asemanvaihtovaihtoehdolla C: n kanssa), mutta se on huomattava myös Java-virtuaalikoneellaan (JVM). Tämä antoi kehittäjille valtuudet koota koodinsa välitavukoodiksi, jota JVM voi lukea ja käyttää.

Android Native Development Kit: n (NDK) avulla on myös mahdollista kehittää sovelluksen tärkeitä osia suoraan alkuperäisessä koodissa, kirjoittamalla C / C ++. Tällöin sinun on oltava tietoinen taustalla olevista alustoista.

Kotlin on kieli, jonka JetBrains paljasti vuonna 2011. Kun se ilmestyi ensimmäisen kerran, joustavuudestaan ​​ja tiivisyydestään huolimatta, se oli vain yksi uusi JVM-kieli, jolla oli menestyneempiä kilpailijoita, kuten Scala, Clojure tai Groovy. Ensimmäisen merkittävän julkaisunsa jälkeen vuonna 2016 se kuitenkin alkoi nopeasti erottua joukosta, varsinkin kun Google ilmoitti tukevansa sitä virallisesti Android-alustalla Google I / O 2017 -palvelussa.

Kotlinista on tulossa Googlen ensiluokkainen kieli (tällä hetkellä Kotlinia ja Javaa käytetään tässä järjestyksessä koko Androidin virallisessa dokumentaatiossa). Java-taudin täydellisen korvaamisen odotetaan olevan entistäkin tärkeämpää nyt, kun Yhdysvaltain liittovaltion muutoksenhakutuomioistuin on antanut ratkaisun loputtomasta oikeusjutusta, jonka Oracle on nostanut syyttäen Googlea Java-tekijänoikeuksien loukkaamisesta.

Alkuperäiset komponentit

Kehittäessään tätä tasoa voit hyödyntää myös kaikkia alkuperäisiä sovellusliittymiä ja erityisesti alkuperäisiä komponentteja. Tämä säästää sovellustasi joutumasta keksimään pyörä uudelleen.

Olen julkaissut videoteston siitä, kuinka luodaan yksinkertainen projekti Xcode (iOS): lle ja Android Studiossa. Jos haluat tarkistaa sen:

Natiivisovellusten edut

  • Paras suorituskyky ja huippukäyttäjien sitoutuminen
  • Verenvuotoreunan natiiviominaisuudet
  • Erityisen hyvät IDE: t Android Studio / Xcode
  • Nykyaikaiset korkean tason kielet Kotlin / Swift
  • Erittäin matalan tason lähestymistapa NDK: lla

Natiivisovellusten haitat

  • Kaksi ylläpidettävää tietokantaa
  • Vaadi asennus (paitsi Android Instant Apps)
  • Vaikea analysoida SEO
  • Erittäin kallista saada käyttäjät lataamaan sovellus

Web-sovellukset

Spektrin toisella puolella on Web-sovelluksia. Web-sovellukset ovat lähinnä selaimen käyttämiä sovelluksia. Et kirjoita alustaan ​​kohdistavaa koodia, vaan pikemminkin mitä tahansa selainta, joka toimii sen päällä.

Web Apps Tier - selvästi selainpalkin päällä, joka kohdistuu Androidin ja iOS: n välillä istuvaan petoon.

Tästä tasosta löydät hullu joukon kilpailijoita hyppäämässä toistensa kurkkuun. Mutta he kaikki käyttävät arsenaalia, joka koostuu samoista aseista: HTML, CSS ja Javascript.

Verkkokehykset ja kirjastot, jopa hyödyntämällä CSS-esikääntäjiä, kuten LESS tai SASS, jopa Javascriptin esikääntämiä kieliä, kuten TypeScript, CoffeeScript tai Flow, jopa symbioosia, kuten JSX tai Elm, jättäen yksin työkalut, kuten Babel, jota käytetään kaiken siirtämiseen Javascriptiin erilaisilla määritettävissä olevat tasot ECMAScriptin vuotuisten eritelmien (ES6 / ES7 / ES8 tai jos pidät parempana ES2015 / ES2016 / ES2017 / ES2018) mukaisuudesta.

Päivän lopussa ne kaikki ovat HTML, CSS ja JavaScript selaimen tarjoamia ja ylläpitämiä. Natiiviin sovellusliittymiin, kuten kameraan, värähtelyyn, akun tilaan tai tiedostojärjestelmään, ei ole suoraa pääsyä, mutta osa niistä voidaan saavuttaa Web-sovellusliittymien kautta:

Voinko luottaa sovellukseni luomiseen verkkoympäristön ominaisuuksiin?

Web API -sovellusten suuri ongelma on niiden kypsyysaste. Jotkut selaimet eivät tue monia niistä. Toteutuksissa on eroja, etenkin mobiiliselaimissa.

Web-sovelluksen edut

  • Jaettu koodi alustojen ja työpöytäselainten välillä
  • Älä vaadi aiempia asennuksia, vain navigoi ja käytä
  • Tonnia kehyksiä ja kirjastoja, jotka tulevat mukaan
  • Paras hakukoneoptimoinnille

Web-sovelluksen haitat

  • Matala suorituskyky
  • Vaikea saada alkuperäistä käyttökokemusta
  • Vaadi Internet-yhteys
  • Ei saatavissa virallisista sovellusliikkeistä
  • API ei ole yhtä kypsä ja luotettava kuin alkuperäinen API

Kehykset ja Web-komponentit

Angular, React ja Vue ovat luultavasti suosituimpia verkkokehyksiä vuodesta 2018 lähtien. Tarkemmin sanottuna Reaktia pidetään vain kirjastona joustavan ja vähemmän arvioidun luonteensa takia. Kulma, toisaalta, on vahvasti arvioitu kehys. Vue asuu jossain vaiheessa heidän välissä.

Kulma vs reagoi vs vue

Google esitteli maailmalle Angular, alun perin nimeltään AngularJS, vuonna 2010. Se alkoi paistaa nopeasti paradigmien kääntymisen vuoksi verrattuna muihin tuon ajan kirjastoihin (kuten tuolloin suosituin jQuery). Sen sijaan, että puhutaan suoraan HTML-elementteistä käyttöliittymän tilan manipuloimiseksi AngularJS: n kanssa, malleja päivitettiin taianomaisesti aina, kun JavaScript-malli päivitettiin.

Kun AngularJS tuli yhä suositummaksi, myös sen tarkoitus kasvoi. Siitä tuli täydellinen ja arvostettu kehys, joka oli yksi ensimmäisistä, joka otti SPA: t (yhden sivun sovellukset) vakavasti. Tämä kasvu (molemmissa näkökohdissa) oli vastuussa joistakin API: n paisutuksista ja suorituskykyongelmista.

Facebook on luonut Reaktin ratkaisemaan omat tarpeet esityskerroksessa. Se esitteli monia näkökohtia, joista tuli yhtäkkiä erittäin suosittuja, kuten virtuaalinen DOM, yksisuuntainen tiedonkulku (alun perin nimeltään Flux, erityisen suosittu Redux-nimisen käyttöönottokirjaston kautta) sekä HTML- ja JavaScript-seos nimeltään JSX.

Vain vuonna 2016 pitkien keskustelujen ja odottamattomien suurten muutosten jälkeen Google julkaisi suositun verkkokehyksensä toisen version. He kutsuivat sitä AngularJS: n sijasta. Mutta koska monet ihmiset jo kutsuivat ensimmäistä versiota "Angular" (ilman "JS" -liitettä), ihmiset alkoivat kutsua uutta versiota Angular 2. Se muuttui nimeämisongelmaksi, koska Google ilmoitti myös, että se julkaisee uudet suuret versiot jokaisena 6 kuukautta.

Mielestäni se oli mammutti virhe. Olen nähnyt tämän aikaisemmin (esimerkiksi Struts vs Struts 2 / WebWork). Heillä on valtavan suosittu tuote, joka näyttää saavuttaneen tasangonsa, ja sitä on alistettu kritisoida enemmän kuin kehua. Jos Google päättää rakentaa sen alusta alkaen, heidän ei pitäisi missään tapauksessa muuttaa vain sen pääversiota. Kuinka ihmiset luottavat siihen, että he eivät toista sitä jokaisessa uudessa pääversiossa? Versio 2: n on tarkoitus tuoda rikkovia muutoksia, mutta se ei tarkoita, että sitä voidaan uudistaa kokonaan.

Angular on näyttävä verkkokehys, ja olen siitä todella intohimoinen. Se on kuitenkin täysin uusi peto. Sillä ei ole paljon tekemistä AngularJS: n kanssa. Jopa Vue, joka on toinen hämmästyttävä kehys (luultavasti yksi miellyttävimmistä työskennellä, muuten), näyttää lintuperspektiivistä enemmän kuin AngularJS. Uskon, että tämä aiheutti merkittävän liikkeen pois Angularista ja vaikutti merkittävästi Reaktin suosioon.

Vue on ainoa kolmesta suosituimmasta verkkokehyksestä, jota iso yritys ei tue. Sen tosiasiallisesti aloitti entinen Google-kehittäjä. Valtavan yksinkertaisuuden ja pienen jalanjäljen vuoksi se sai huomion massiiviselta ja innostuneelta yhteisöltä.

Vaikka ratkaisuja onkin täydellisempiä, ne kaikki toimivat verkkokomponenttien käsityksen päällä. Niistä on avoin määritys parhaillaan käynnissä W3C: ssä ja mielenkiintoisissa toteutuksissa, kuten Polymer, Stencil ja X-Tag.

Sarjan kolmannessa videossa en viettää liikaa aikaa puitteiden keskusteluun, vaan keskustelen web-komponenttikirjastoihin:

Mobiilisovellukset vs. Web-sovellukset

En ole varma, oletko huomannut, mutta esittelen täällä porrastuksen järjestys, joka on mielestäni helpoin polku oppia kaikki lähestymistavat. Aloitin alkuperäisestä tasosta, joka on aidosti mobiili kehitys. Sitten päätin lentää suoraan toiseen ääriosaan esitelläksesi Web-tason, joka on taso, joka on ollut käytettävissä ensimmäisistä älypuhelimista lähtien.

Vasta nyt, kun olen läpikäynyt vertailun kaavioni kahden reunan välillä, aloitan puhumisen monista alustojenvälisistä lähestymistavoista mobiilisovellusten rakentamiseksi.

Mobiilisovellusten ja Web-sovellusten välillä käydään pitkää keskustelua. Kaikki, mitä sanon mobiilisovelluksista, ei ole yksinomainen alkuperäiskansalle. Sitä voidaan soveltaa myös kaikkiin alustanvälisiin tasoihin, joita esitän myöhemmin.

Käyttäjän käyttäytymisen ongelma

Käyttäjät viettävät enemmän aikaa mobiilisovelluksiin (87%) kuin mobiilisivustoihin (13%)

Vuonna 2017 tehdyn Comscore-tutkimuksen mukaan käyttäjän uskollisuus mobiilisovellukseen on paljon merkityksellisempi kuin mobiilisivustoille. Forbesia koskevan yhdenmukaistetun artikkelin mukaan tämä johtuu yleensä mukavuudesta (esimerkiksi aloitusnäytön painikkeet, widgetit, tärkeimmät ilmoitukset), nopeudesta (esimerkiksi tasaisemmat rajapinnat, melkein välittömät käynnistykset) ja tallennetuista asetuksista (esimerkiksi offline-tilassa) sisältöä).

Mobiilisivustot tavoittavat enemmän ihmisiä (8,9 miljoonaa kuukausittaista kävijää vastaan ​​3,3 miljoonaa mobiilisovellusta)

Toisaalta samoissa Comscore-tiedoissa opimme, että asiakkaita voidaan tavoittaa helpommin mobiilisivustoilla, koska he eivät ole niin sidoksissa heidän harvoihin ensisijaisiin sovelluksiinsa. Jos vertaat suosituimpia verkkosivustoja eniten ladattuihin sovelluksiin, arvioidaan, että keskimäärin 8,9 miljoonaa ainutlaatuista verkkokävijää kuukaudessa käyttää 1000 suosituinta verkkosivustoa. Se on melkein kolme kertaa enemmän kuin 1000 eniten ladatun sovelluksen keskimääräisiä ainutlaatuisia käyttäjiä.

Jakelu (Web-sovellus) x sitoutuminen (mobiilisovellus)

Siinä kaikki koskee jakelua ja sitoutumista. Verkkosovelluksellasi on suurempi mahdollisuus päästä käyttämään, koska käyttäjät kokeilevat todennäköisemmin uusia asioita liikkuessasi selaimissa. Mutta mobiilisovellusten on osoitettu olevan houkuttelevammat ja kiinnittävät käyttäjien huomion paljon pidemmäksi ajaksi.

Nyt kun ymmärrät ongelman, katsotaanpa Progressive Web -sovelluksia. Tämä on lähestymistapa, joka on niin sidottu Web-sovellusten tasoon, että luokittelen sen vain lisäykseksi Web-sovelluksiin. Mutta se on suuri häiriötekijä ja vakava ehdokas näkyvimmälle uudelle ja hienommalle asialle verkko- ja mobiilikehityksessä.

Progressiiviset Web-sovellukset

Progressiiviset Web-sovellukset (PWA) ovat joukko työkaluja, joita käytetään antamaan Web-sovelluksen käyttäjille sama kokemus, johon he ovat tottuneet käyttäessään Mobiilisovelluksia. Tämä tarkoittaa, että Web-sovellukset voivat hyödyntää mahdollisesti korkeampaa levitystasoa kunnollisemmalla sitoutumisasteella.

Progressiivinen Web-sovellusten lisäys Web-sovellusten tasoon

Google määritteli kolme pääasiallista pätevyyttä PWA: lle: niiden on oltava luotettavia, nopeita ja sitoutuvia.

Palvelualan työntekijöiksi kutsutut ominaisuudet ja App Shell ovat progressiivisten Web-sovellusten perusta. Ne on luotu edistämään sovellusten luotettavuutta, koska ne on nyt suunniteltu toimimaan laitteen yhteystilasta riippumatta. Tämä sisältää offline-tilan ja huonot yhteydet. Ne tarjoavat myös merkittävän havaitun suorituskyvyn paranemisen, kun sovellukset käynnistävät paikallisesti välimuistilla tallennetun datan avulla, mikä eliminoi synkronisen sisällön lataamisen viivästykset.

Luotettavuutta voitaisiin pitää epäsuorina sitoutumisen vektoreina. Esimerkiksi junamatkalla liikkuminen ei vaikuta käyttäjiin. He voivat pitää kiinni.

Sama pätee nopeuteen. Googlen mukaan:

53% käyttäjistä luopuu sivustosta, jos lataus vie yli 3 sekuntia!

Erityisesti luotettavuus ja nopea kuormitus eivät kuitenkaan välttämättä takaa suurta sitoutumista. PWA: t hyödyntävät mobiililaitteisiin liittyviä ominaisuuksia, jotka käyttivät yksinoikeudella mobiilisovelluksiin, kuten ”Lisää aloitusnäyttöön” -vaihtoehto ja Push-ilmoitukset.

Lisää-aloitusnäyttöön -ominaisuuden suhteen saatat huomata, että Applella on ollut samanlainen ominaisuus jo ensimmäisestä iPhonesta lähtien. Jotkut ihmiset jopa väittävät, että Progressiiviset Web-sovellukset ovat Googlen hieno uusi nimi alkuperäiselle Apple-idealle.

Ja et todellakaan voi olla täysin eri mieltä. Jotkut ideat todella pyöräilevät. He tulevat, menevät pois ja tulevat takaisin uudella nimellä ja joillakin lisälaitteilla (esimerkiksi huoltotyöntekijät), jotta he voivat lopulta pysyä kiinni.

Toisaalta on vaikea olla täysin samaa mieltä. Steve Jobsin puhe Web 2.0 + AJAX: stä ja ikimuistoinen ilmoitus iPhonesta takaisin WWDC 2007: ssä eivät ole riittävän vakuuttavia kutsuakseen häntä PWA: n isäksi tai edes profeettoksi.

Oikeudenmukaisuuden vuoksi iPhonen Lisää kotinäyttöön -ominaisuus on ollut vain hienovarainen, melkein piilotettu ominaisuus, jolla luodaan työpöydän kuvakkeet, jotka vain käynnistävät Web-sovellukset koko näytön tilassa. Sillä on kaikki HTTP-pyyntö-vastaus -syklien taakka eikä selkeää polkua välimuistien ympärillä.

PWA: t alkavat oikeasta kohdasta. He tutkivat, kuinka Web-sovellusten aikaisemmat asennukset eivät ole välttämättömiä menettämättä Mobiilisovellusten asiakaspuolen käynnistysruutua. Tämä tarkoittaa, että kaikki käyttäjän tarvitsema ensimmäiseen vuorovaikutukseen käynnistyksen jälkeen saattaa olla paikallisesti välimuisti (lue: Sovelluskuori) ja pitää saatavilla saatavana heti, kun he napsauttavat ”Lisää aloitusnäyttöön”.

Siirrytään PWA: n toiseen tunnettuun ominaisuuteen ja puhutaan mobiilisovellusten maailman erittäin kiinnostavasta (tai uudelleen kiinnittyvästä) ominaisuudesta: Push Notifications. Ne ovat hälytystyyppisiä viestejä, jotka näkyvät ylimmällä ilmoituspalkilla / -alueella sekä lukitusnäytöillä. Heillä on valta vetää käyttäjiä takaisin sovellukseesi, kun he ovat saaneet ilmoituksen.

Vahvistaakseen PWA: n vetovoimaa Google on vetänyt kaikki nykyaikaiset Web-sovellusliittymät PWA: n alle. Joten odota näkeväsi asioita kuten maksupyynnöt, käyttöoikeuksien hallinta, WebVR, anturit, WebAssembly ja WebRTC progressiivisten Web-sovellusten yhteydessä. Mutta nämä piirteet eivät välttämättä ole sidoksissa PWA: hon, ja jotkut ovat jopa syntyneet ennen termin PWA perustamista.

PWA ja Apple

Apple puolestaan ​​ilmoitti ensimmäisistä vankista virstanpylväästään kohti PWA: ta vasta maaliskuussa 2018. Vaikka rajoituksia on vielä, edistyminen on tuntuvaa. Jotkut rajoitukset saattavat liittyä siihen, että Safari on jäänyt kilpailijoista jäljessä. Muiden voidaan katsoa johtuvan Applen tiukasta valvonnasta.

Applella on silti kannattavampi App Store kuin Google. Applen mukaan useammat sovellusjulkaisujen kriteerit lisäävät yleistä luotettavuutta ja PWA: t ovat omiaan vahingoittamaan App Storen tuloja. Tämä viittaa siihen, että eräät rajoitukset, jotka näyttävät asettavan tahallisesti (kuten 50 Mt PWA-välimuistin enimmäiskokoa), maksavat enemmän.

Valitettavasti PWA: t eivät ole täydellisiä

Verkkoratkaisut ja eri tasoilla kaikki käyttöympäristöjen väliset ratkaisut pyrkivät saavuttamaan Natiivisovellusten huippuosaamisen ja kattavuuden. Jokainen uusi ominaisuus ja kaikki Androidille tai iOS: lle ominaiset yksityiskohdat tekevät alkuperäiskansasta tuntemaan olonsa entistä vaikeammaksi, kun etää sovelluksesi alkuperäisestä tasosta.

Kaiken kaikkiaan PWA: t korjaavat joitain Web-sovellusten tason ongelmia. Mutta on muitakin ongelmia, joita selaimen päällä toimiva ratkaisu ei voi korjata.

Mitä PWA: t korjaavat

  • Lisää "alkuperäiskansojen" kokemusta
  • Nopeammat latausajat
  • Älä vaadi Internet-yhteyttä
  • Pakota web-kehittäjiä olemaan tietoisia tilanteista, joissa ei ole yhteyttä, ja huono yhteys
  • Sisällytä mobiilisovellusten ominaisuudet, kuten Push Notifications, Geolocation tai Puheentunnistus

Mitä he eivät

  • Luontainen hitaus
  • Ei saatavilla sovellusliikkeissä (juuri vielä)
  • Kaikki selaimet eivät vieläkään tue niitä täysin
  • Silti puuttuvat mobiiliominaisuudet, kuten NFC, Ambient Light, Geofencing
  • Puute myös tuesta Androidin tai iOS: n erityispiirteille, kuten PiP, älysovellusten bannerit, käynnistysnäytön widgetit ja 3D touch

Alla olevassa videossa teen lyhyen katsauksen PWA: ista.

Hybridi-sovellukset

Tällä tasolla alamme sukeltaa mobiilisovellusten maailmaan. Aloitamme kaukaimmasta tasosta: Hybridi-sovellukset.

Termiä hybridiä käytetään myös yleisesti kaikissa alustojen välisissä ratkaisuissa. Rajoitan kuitenkin sen sovelluksiin, jotka toimivat mobiililaitteiden sisällä, nimeltään WebViews.

Hybridi-sovellusten taso. Selaimen rivin alapuolella, mutta WebView-tiedostojen yläosassa

Toisen videon demoissa tarkoituksenani lisätä WebView Hello World -esimerkkiin oli tehdä selväksi, että jokaisella alustalla on oma komponentti, joka pystyy toimimaan kuin todellinen selain.

Cordova / PhoneGap

Cordova / PhoneGap -ratkaisut, kuten Web-mobiilisovellusten välinen aukko (anteeksi tuntemattomasta punista), täyttävät aukon. Ne tarjoavat työkaluja kehittäjän HTML, JavaScriptin ja CSS-koodin (samoin kuin minkä tahansa ylimääräisen omaisuuden, kuten kuvan tai videon) paketointiin ja muuntamiseen mobiilisovelluksiksi (kyllä, oikeita Android- tai iOS-sovelluksia). Näiden sovellusten WebView on tarkoitettu yksinomaan alkuperäisen verkkokoodin tulkitsemiseen ja suorittamiseen, alkaen sovelluksen pääkansiossa olevasta ”index.html” -tiedostosta (normaalisti nimeltään “www”). Ne myös yhdistävät JavaScriptin koodin natiiviin sovellusliittymiin laajennusten kautta, jotka on osittain toteutettu JavaScript ja osittain äidinkielellä.

Joten tehkäämme asiat selkeämmiksi. Hybridi-sovellukset pääsevät natiiviin sovellusliittymiin (Web-sovellusliittymien sijasta), mutta WebView sulkee ne. Cordova-painikkeen on oltava WebView: n tarjoama HTML-painike mobiililaitteen natiivipainikkeen sijasta.

Tämä on maaginen taso, jonka avulla yritykset voivat siirtää Web-sovelluksensa mobiilisovelluksiin sovelluskaupoissa. Joten kaikki verkkokehykset ovat sallittuja täällä.

joonialainen

Ionicin kaltaiset kehykset kääritään Cordovan omiin ratkaisuihinsa. Ionicin kanssa sinun ei tarvitse käyttää Cordovan komentoriviliittymää (CLI), koska kaikki sen komennot on kääntänyt Ionic CLI.

Äskettäin Ionic-joukkue päätti ottaa ohjat koko Hybridi-sovellusten pinoon. Joten he käynnistivät ehdotetun korvauksen Cordovalle nimeltä Capacitor. Kondensaattorilla on tuki Cordova-laajennuksille, ja sitä voi käyttää myös ei-ioninen projekti.

Voit seurata minua Cordova Hello World -näytteen läpi sarjan viidennessä videossa:

Hybridi-sovellusten edut

  • Ne ovat pääosin verkkosovelluksia, jotka voidaan toimittaa virallisiin sovellusliikkeisiin
  • Voidaan käyttää minkä tahansa JavaScript-kehyksen / kirjaston kanssa
  • Koodi on edelleen hyvin jaettavissa eri alustoille
  • Pääsy natiivitoimintoihin (esimerkiksi kamera, kiihtyvyysanturi, yhteystietoluettelo)

Hybridi-sovellusten haitat

  • Kamppaile suorituskykyongelmien ja muistin kulutuksen kanssa, koska web-näkymät ovat vastuussa kaiken näytöllä näkymisestä
  • Joidenkin alkuperäisten käyttöliittymäkomponenttien on jäljiteltävä yhden web-näkymän päällä
  • Vaikeampi hyväksyä ja julkaista App Store -sivustolla
  • Natiivien ominaisuuksien saatavuus näissä ympäristöissä kestää yleensä kauemmin

Verkkosivut

Web Native on suhteellisen uusi ja usein väärin ymmärretty taso. Siellä Web-sovellukset kohtaavat alkuperäisiä komponentteja. Vaikka Appcelerator (Axway) Titanium on ollut olemassa jo pitkään, on joitain suhteellisen uusia kilpailijoita, jotka oikeuttavat tekemään tästä täysin erillisen luokan mobiilisovelluksia.

Web Native -sovellukset eivät tarvitse WebView-sovellusta, koska ne puhuvat suoraan muihin alkuperäisiin komponentteihin

Kuten yllä näet, sovelluksen hahmottamiseen ja suorittamiseen ei ole web-näkymää. Joten miten JavaScript suoritetaan? Onko se koottu? No, jos pidät transpilaatiota (kokoaminen yhdestä kielestä toiseen - esimerkiksi TypeScriptiin JavaScriptiin), niputtamista, minimointia, manglingointia ja hämärtämistä kaikki yhdessä kokoomateoksena, kyllä, Java on koottu.

Mutta ongelma on, että tämä ei tee JavaScriptista jotain selkeää Android- tai iOS-käyttöjärjestelmien ymmärtämästä. Ja teoriassa ei ole mitään natiivikomponenttia, joka toimii vain JavaScript-moottorina ilman HTML-pohjaisen moottorin paisumista.

Strategia on lähettää JavaScript-moottorit (yleensä V8 Androidille ja JavaScriptCore iOSille) koodin mukana. Vaikka niillä on pieniä jalanjälkiä ja ne ovat erittäin nopeita, ne ovat jotain ulkoista, jonka sovelluksesi on toimitettava.

Toisaalta tällä lähestymistavalla on yleensä parempi käyttöliittymäsuorituskyky, koska kaikki komponentit ovat samoja (tai perustuvat esimerkiksi samaan asiaan esimerkiksi React Native -sovelluksessa) kuin ne, joita Native-sovellukset käyttävät.

Native Web -sovellusten edut

  • Tavoita molemmat alustat yhdellä kooditietokannalla
  • Lähes sama suorituskyky kuin natiivisovelluksissa, koska ne käsittelevät myös alkuperäisiä käyttöliittymäkomponentteja
  • Parannukset ovat välttämättömiä, mutta koodi on edelleen jaettavissa verkkokehityksen kanssa

Native Web -sovellusten haitat

  • Jopa yhdellä koodikoodilla kehittäjän on oltava tietoinen alkuperäisistä komponenteista
  • Verkkokehittäjille hitaampi oppimiskäyrä kuin Hybridi / Web-sovellukset, etenkin kun on kyse ulkoasusta

Reagoi omaperäinen

Sarjan osassa 6 teen nopean Hello Worldin React Native -versiossa. Tämä osoittaa Android Studio -sovelluksen tarkastajassa, mitkä komponentit renderoitiin emulaattorissa. Vertaa edellisiin esimerkkeihin varmistaen, ettei WebView-lainkaan ole.

Nativescript

Toinen hämmästyttävä kehys, josta olen erityisen kiinnostunut viimeisen kahden vuoden aikana (minulla on siitä Udemy-kurssi - portugaliksi), on Nativescript. Se on samanlainen kuin React Native, mutta ei ole sidottu React-maailmaan (siellä on epävirallinen integraatio, kuitenkin Nativescript-Preact).

Nativescriptin avulla voit kehittää vanilja JavaScriptiä, TypeScriptiä, kulmikasa ja viime aikoina Vue-ohjelmaa. Voit tietysti käyttää myös muita kehyksiä, mutta niitä tuetaan virallisesti. Se on muutenkin dokumentoitu melko hyvin.

Nativescriptillä on työkaluja, kuten Nativescript Sidekick ja Nativescript Playground, sekä projektirakenteita, jotka perustuvat malleihin, jotka yhteisö voi tarjota. Tämän pitäisi auttaa sinua projektin luomisessa, antaa sinulle mahdollisuuden käynnistää, ottaa käyttöön, testata ja käyttää simulaattoreita pilvi- ja iPhone-laitteissa, vaikka et kehittäisikään Macia.

Sarjan seitsemännessä osassa teen Hello World -sovelluksen Sidekickin avulla yhdessä toisen projektin kanssa, joka aloitettiin CLI: ltä ja oppimista varten luomallani WhatsApp-kloonimallilla.

On tärkeää tarkastella Asettelutarkastajaa, kun sovelluksesi toimii Android-emulaattorilla. Nativescriptin avulla se näyttää alkuperäiset komponentit (jälleen ei WebView: ta) ja ohjaa tavallisten Android-luokkien, kuten TextView, esiintymät. Tämä on erilainen kuin React Native, jolla on omat luokat kietoa alkuperäiset komponentit.

Siksi Nativescript väittää, että ei ole viivettä siitä, kun uutta ominaisuutta on saatavana iOS: ssä ja Androidissa, ja siihen, kun voit käyttää sitä Nativescript-projektissa. Esimerkiksi, he lähettivät blogiinsa AR-projektin samana päivänä. IOS 11 julkaistiin virallisesti uuden ARKit-sovellusliittymän avulla.

Weex

Toinen mainitsemisen arvoinen kehys tässä kategoriassa on Weex. Se on Alibaban kehittämä projekti, jota inkuboidaan tällä hetkellä Apache Sofware Foundationissa (ASF). Se käyttää tavallisia HTML-tunnisteita, kuten

, ja CSS-komentoja