Todd Anglin on Progressin tuotestrategian ja kehittäjäsuhteiden johtaja.
Lähes vuosikymmenen ajan PhoneGap on tarjonnut verkkokehittäjille pienikitkaista polkua sellaisten mobiilisovellusten luomiseen, joilla on pääsy natiivilaitteiden ominaisuuksiin. PhoneGap antaa monille kehittäjille mahdollisuuden luoda sovelluksia iOS: lle ja Androidille (ja jopa Windows Phone ja BlackBerry, hetkeksi) käyttämällä jo tuntemiaan ja rakastamiaan taitoja ja JavaScript-kirjastoja. Tämä yhdistelmä verkkotaitoja ja natiivilaitteiden käyttöoikeuksia (tunnetaan yleisesti nimellä "hybridi") on vakiintunut yhtenä ensisijaisista lähestymistavoista mobiilisovellusten kehittämiseen.
Nyt, kun kehittyvän PhoneGap-sovelluksen (ja siihen liittyvän avoimen lähdekoodin Apache Cordova -projektin) työ hidastuu, mitä seuraavaksi hybridi-mobiilikehitykselle?
Apache Cordova ei selvästikään ole avoimen lähdekoodin projektina lähiaikoina. Monilla yrityksillä on suuria investointeja Cordovaan, ja Cordova-yhteisö jatkaa aukkojen täyttämistä, kun yrityssitoumuksen tekijät laskevat ja virtaavat.
Mutta PhoneGap oli projekti, joka luotiin nimenomaisella aikomuksella lopulta vanhentua, ja se hetki saattaa olla meille.
Viimeisen 10 vuoden aikana on syntynyt kaksi epäilemättä ylivoimaisinta vaihtoehtoa, jotka ovat valmiita siirtymään PhoneGapin ja “hybrid 1.0”: n tilalle. Nämä ovat progressiivisia verkkosovelluksia ja JavaScript-pohjaisia natiivisovelluksia.
Progressiiviset verkkosovellukset
PhoneGapin tarkoituksena oli aina auttaa web-kehittäjiä tekemään enemmän mobiililaitteilla, kun he saavuttavat mobiiliselaimien rajat. PhoneGap käyttää uudelleen kaikkea verkosta - HTML: ää, CSS: ää, JavaScriptiä - ja luottaa natiivikoodiin kirjoitettuihin laajennuksiin (Objective-C, Swift, Java) päästäksesi tiettyihin natiivilaitteiden ominaisuuksiin JavaScriptin kautta. Ajan myötä tämä on osoittautunut sekä siunaukseksi että kiroukseksi. Oppimiskäyrä on hyvin matala, mutta PhoneGap-sovellusten upotetut verkkoselaimet kamppailevat usein suorituskyvyn kanssa (ei kiitos Applelle ja pitkään oletusarvoiselle Android-verkkonäkymälle). Silti PhoneGap oli toimiva ratkaisu, joka tuotti "tarpeeksi hyviä" tuloksia monille.
Samaan aikaan verkkostandardit ovat kehittyneet jatkuvasti, ja viimeisten kolmen tai neljän vuoden aikana pyrkimys parantaa verkkostandardeja, jotka ovat tarpeen tehokkaampien, offline-valmiiden mobiilisovellusten luomiseksi, on katalysoinut termin "progressiiviset verkkosovellukset" alla.
Progressiivisten verkkosovellusten avulla verkkoalusta ottaa uuden jättimäisen askeleen eteenpäin. Nyt verkkosovelluksilla on täysi hallinta verkkopinosta, mikä mahdollistaa edistyneiden välimuistitoimintojen ja offline-toimintojen suorittamisen. On myös uusia sovellusliittymiä, jotka auttavat verkkosovelluksia tekemään muita asioita, jotka liittyvät usein alkuperäisiin mobiilisovelluksiin, kuten käynnistämään tilaruudun, lähettämään push-ilmoituksia tai pyytämään käyttäjiltä maksutietoja. Lisää tämä kaikkiin muihin HTML5-sovellusliittymiin, jotka ovat laskeutuneet selaimiin - kuten kiihtyvyysmittareiden, kameroiden jne. Käyttöoikeudet - ja sinulla on erittäin kykenevä verkkoalusta monenlaisille sovelluksille.
Kaikki nämä ominaisuudet olisivat edellyttäneet natiivisovellusta, kun PhoneGap luotiin, mutta nyt selaimet ovat kiinni. Voimme ottaa pois hybridiharjoittelupyörät.
Silti verkossa on edelleen rajoituksia. Se on vain hitaasti liikkuvan, standardeihin perustuvan alustan luonne. progressiiviset verkkosovellukset ovat valtava edistysaskel, mutta ne eivät ole täydellinen korvike kaikille sovelluksille. Joten mitä web-kehittäjät tekevät hybridin jälkeen, jos he tarvitsevat edelleen täyden pääsyn natiivilaitteiden sovellusliittymiin? Anna JavaScript-pohjaiset natiivisovellukset.
JavaScript-pohjaiset natiivisovellukset
Noin viisi vuotta sitten useat yritykset alkoivat yrittää löytää ratkaisun hybridi-mobiilisovelluksia vaivaaviin usein esiintyviin suorituskykyongelmiin. Tavoite: Luo kehyksiä, jotka voisivat tuottaa "aidosti alkuperäistä" suorituskykyä ja käyttöliittymärikkautta samalla, kun ne ovat edelleen alustojen välisiä ja tuttuja web-kehittäjille. Tästä työstä syntyi kaksi suosittua vaihtoehtoa: React Native (Facebookista) ja NativeScript (Progressista).
Nämä uudet kehykset antavat kehittäjille mahdollisuuden jatkaa verkkotaitojensa uudelleenkäyttöä, mutta sen sijaan, että yksinkertaisesti kääritään selain natiivisovelluksen kuoreen (kuten PhoneGap tekee), nämä uudet lähestymistavat tuottavat natiivin käyttöliittymän. Tuloksena on mobiilisovellukset, jotka tuntevat ja toimivat enemmän kuin "raaka" yhden alustan natiivisovellukset, samalla kun ne tuottavat edelleen alustojen välistä tuottavuutta.
Tätä lähestymistapaa on kuvattu muutamalla nimellä: muun muassa ”hybrid 2.0”, “native hybrid” ja “cross platform-native”. Forrester esitteli termin "JavaScriptiä ohjaavat natiivisovellukset", ja vaikka se ei käy aivan kielestä, se on ainakin tarkka ja kuvaava nimi.
JavaScriptiä ohjaavien natiivisovelluskehysten avulla web-kehittäjillä on suurin osa siitä, mitä he rakastivat PhoneGapista, mutta entistäkin tehokkaammin ja tehokkaammin. Esimerkiksi NativeScript, joka on syvästi integroitu sekä Angular- että Vue-ohjelmistoon, antaa kehittäjille täydellisen pääsyn kaikkiin natiiviin sovellusliittymiin JavaScriptin kautta. Jokainen heistä. Jos se voidaan tehdä natiivisovelluksessa, se voidaan tehdä NativeScriptissä, ja alustojen väliset moduulit mahdollistavat useimpien asioiden koodaamisen kerran ja toimivat sekä iOS: lla että Androidilla. Se on kuin steroidien PhoneGap-laajennukset.
React Native ja NativeScript ovat molemmat kukoistavia avoimen lähdekoodin projekteja, ja molemmat ovat valmiita olemaan "hybrid 1.0": n luonnollinen kehitys tilanteissa, joissa progressiiviset verkkosovellukset eivät sovi laskulle.
Kumpi valitset?
Vaikka PhoneGap ei ole poissa, on vaikea kuvitella, miksi uusi projekti aloitettaisiin PhoneGapilla tänään, kun vaihtoehtoja, kuten progressiiviset verkkosovellukset ja JavaScript-pohjaiset natiivisovellukset, on olemassa. Molemmat vaihtoehdot edustavat tulevaisuuteen rakennettuja polkuja, ja ne ovat suhteellisen triviaalia hyväksyä web-kehittäjille, jotka ovat jo perehtyneet hybridisovellusten kehittämiseen.
Vaihtoehtojen välillä tulisi olla myös yksinkertaista:
- Jos sovelluksesi ei tarvitse paljon laitteen sovellusliittymän käyttöä, sen ei tarvitse olla sovelluskaupoissa ja se voi elää iOS: n ylimääräisten rajoitusten kanssa (toistaiseksi), rakenna progressiivinen verkkosovellus.
- Jos sovelluksesi vaatimukset ylittävät progressiivisten verkkosovellusten rajat, valitse jokin JavaScriptiä ohjaavista natiivisovellusalustoista:
- Jos olet React-kauppa, valitse React Native.
- Jos olet kulma- tai Vue-kauppa, valitse NativeScript.
Monet yritykset, jotka suunnittelevat nämä avoimen lähdekoodin kehykset, ovat erittäin halukkaita auttamaan, ja useimmat tarjoavat teknisiä ohjeita siirtymiseen PhoneGapista niiden kehyksiin. Jos etsit paikkaa siirtolaismatkan aloittamiseen, asiantuntijan kuuleminen on aina hyvä idea.
Ja jos juutut tai haluat vain keskustella kolmannen osapuolen asiantuntijan kanssa, kehittäjäyhteisölle on tarjolla useita upeita resursseja - ilmeinen ja suosituin valinta on GitHub. Kuitenkin on ollut monia muita foorumeita, jotka on luotu auttamaan kehittäjiä siirtymään PhoneGapista ja hybridistä progressiivisiin verkkosovelluksiin jonkin aikaa, ja ne tarjoavat upeita viitteitä.
Viime kädessä PhoneGap vastasi nimeään. Se auttoi web-kehittäjiä kattamaan mobiilisovellusten kehityksen aukon lähes vuosikymmenen ajan. Se on vaikuttava ajaa millä tahansa standardilla. Nyt on aika edistyksellisille verkkosovelluksille ja JavaScript-pohjaisille natiivisovelluskehyksille poimia vaippa ja johtaa kehittäjät tulevaisuuteen.
Hybridi (1.0) on kuollut. Eläköön hybridi (2.0).
Todd Anglin on Progressin tuotestrategian ja kehittäjäsuhteiden johtaja.
—
New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen[email protected].
