Reatiivi natiivi vs. alkuperäinen sovelluskehitys - suunnittelijan näkökulma.

Mikä aika elää

Tätä vuosikymmentä voidaan helposti kutsua älypuhelimen vuosikymmeneksi. Ja numerot kasvavat vain: vuoteen 2022 mennessä melkein kaikki maapallon ihmiset omistavat yhden. Mobiililaitteista on tullut loistava tilaisuus melkein jokaiselle yritykselle, mutta myös siihen liittyy paljon haasteita. Androidilla voi olla huomattavasti suurempi markkinaosuus maailmanlaajuisesti, mutta koska iOS on suosittu varakkaiden asiakkaiden keskuudessa, haluat todennäköisesti huolehtia molemmista alustoista. Ja älä unohda vanhaa hyvää verkkoa.

Tässä yhteydessä React Nativen äskettäinen esiintyminen kuulostaa tuotteen omistajan unelmien totta. Sen avulla voidaan luoda natiivisovelluksia Javascriptin avulla, käynnistää iOS- ja Android-sovelluksia yhdestä koodipohjasta ja käyttää kyseisen koodin suuria paloja uudelleen verkkoon. Tietenkin, mukana on muutama "buts". Jos olet suunnittelija, joka lähestyy RN-hanketta, on syytä oppia kaikista tämän tekniikan mahdollisuuksista ja rajoituksista, ennen kuin siirryt suunnitteluun. Tässä viestissä haluamme jakaa suunnittelutiimimme kokemuksia viimeaikaisen työskentelymme perusteella, hahmotellen prosessiamme, havaitsemiemme asioita ja kaikkia positiivisia yllätyksiä.

Miksi valitsimme reagoivan natiivi

Ollaan todellinen: React Native ei lyö alkuperäistä kehitystä suorituskyvyn, joustavuuden tai huippuluokan tietoturvan suhteen. Se on hieno vaihtoehto, kun aika on projektiisi avaintekijä. Tämä oli tapauksemme, kun meitä pyydettiin rakentamaan MVP-mobiilisovellus (iOS ja Android) päivittäistavaroiden toimituspalveluun. Määräaika: 2 kuukautta.

Asioiden vaikeuttamiseksi jouduimme myös käsittelemään vanhaa taustaohjelmaa. Sovellusliittymien valmistelu kaikille sovelluksen toiminnallisuuksille tässä aikataulussa ei ollut yksinkertaisesti mahdollista. Siksi React Native näytti vielä houkuttelevammalta, koska se antoi meille mahdollisuuden integroida asiakkaamme verkkosivunäkymät sovelluksen joihinkin osiin.

Mikä on mielenkiintoista, ennen lopullisen päätöksen tekemistä analysoimme markkinoilla olevia kilpailijasovelluksia. Vaikka siellä oli joitain puhtaita alkuperäisiä ratkaisuja, suurin osa analysoiduista sovelluksista käyttää hybridiosia - jotka liittyvät yleensä monimutkaisen, dynaamisen sisällön renderointiin, kuten tuoteluettelot tai uutissyötteet. Sovellusten ja Google Play -kauppojen arvostelujen perusteella vaikutti siltä, ​​että hybridiin siirtyminen ei vaikuta asiakastyytyväisyyteen.

Kaupan myymälässä toteutimme sekä WebView- että React Native -komponentit.

Tuotemerkkisuunnittelu

Yksi ensimmäisistä isoista päätöksistä, joita edessämme oli, oli työskennellä alusta-agnostisella suunnittelulla molemmilla alustoilla. Luopuminen tiukkojen alustan parhaiden käytäntöjen noudattamisesta saattaa aluksi kuulostaa vaaralliselta, mutta vuosien mittaan rajat iOS: n ja Android-käyttökokemuksen välillä ovat entistä epäselviä.

Ensinnäkin, monet sovellukset päättävät ns. Brändisuunnittelusta lähestyäkseen luodakseen ainutlaatuisen ja yhtenäisen tuotemerkin ulkonäön kaikilla kanavilla. Tämä lähestymistapa parantaa myös käytön helppoutta, kun käyttäjät vaihtavat käyttöympäristöjen välillä palvelua käyttäessään. Puhumattakaan siitä, että materiaalisuunnittelu on ollut menestyksen aalto, kun FAB-painikkeet ja muut Android-käyttöliittymän komponentit aukeavat monissa iOS-sovelluksissa. Alkuperäisessä kehityksessä tämän lähestymistavan noudattaminen on kallista ja aikaa vievää. Mukautettu käyttöliittymä tuo käyttöönoton suhteen paljon monimutkaisuutta, kun taas tavalliset käyttöliittymäkomponentit tulevat suoraan laatikosta.

Asiat näyttävät paljon erilaisilta React Native -maailmassa, jossa käyttöliittymä toteutetaan HTML & CSS: n avulla. Suunnittelijoille tämä tarkoittaa itse asiassa paljon luovaa vapautta pilaamatta kehittäjien elämää. Tekninen tiimimme onnistui toteuttamaan mallit melkein kokonaan omalla koodillamme yhdessä muutaman pienen kirjaston kanssa¹.

Suunnitteluvaihto

Kun olet työskennellyt useissa monialustaprojekteissa aiemmin, tämä tarkoittaa yleensä PALJON työtä suunnittelijoille, varsinkin jos välität johdonmukaisuudesta. Aina kun teimme pienimpiä muutoksia malleihimme, useita tiedostoja oli päivitettävä, sitten ladattava useisiin Zeplinin projekteihin ja useiden dev-tiimien lyhyisiin jäseniin. Työnkulku tässä projektissa oli paljon helpompaa! Suunnittelimme vain yhdessä Sketch-tiedostossa (plus symbolikirjastot). Koska käyttöliittymä koodattiin suhteellisia yksiköitä käyttämällä, meidän piti ylläpitää vain yhtä Zeplin-projektia. Laitteidemme ei käytännössä käyttänyt Zepliniä omaisuuden hankkimiseen, sen sijaan vietimme kaikki kuvakkeet fonttikirjastoon niiden käyttöä varten. Zeplin oli kuitenkin silti erittäin hyödyllinen heille, koska se tuotti reaaliaikaisen koodinpätkät.

Odotukset vs. todellisuus

Koska React Native on lupaava, mutta silti suhteellisen uusi tekniikka, asiat eivät aina toimi odotetulla tavalla. Tämä voidaan yleensä ratkaista injektoimalla natiivikoodi Reaktoriin, joka tunnetaan myös silloina. Airbnb² käytti tätä hybridi-lähestymistapaa, ja RN-koodiin jää vain 20% toiminnallisuutta.

Airbnb kutsui siltaprosessia "vaivalloiseksi", ja jopa virallisessa React Native -dokumentaatiossa kuvataan sitä "edistyneemmäksi ominaisuudeksi, emmekä odota sen olevan osa tavallista kehitysprosessia, mutta on kuitenkin välttämätöntä, että se on olemassa". Projektimme yhteydessä (toimivan MVP: n lähettäminen vain 3 kuukaudessa) natiivikoodin syöttämisellä ei ollut järkeä, koska se olisi tapannut prosessin nopeuttamisen ja yksinkertaistamisen kaikki näkökohdat.

suunnistus

Näyttöjen välillä navigoinnin järjestämiseen ei ole yhtä standardoitua tapaa. Ainoat kaksi käytettävissä olevaa navigointikirjastoa ovat edelleen melko paljon keskeneräistä työtä, ja niihin on lisätty virheitä. Mikä on vaivatonta alkuperäisillä alustoilla, tulee todella vaikeaksi saada oikein Reaktin kanssa. Erityisesti näyttösiirtymät tulevat näyttämään erittäin luontaisilta verrattuna alkuperäisiin kokemuksiin.

varjot

Toistaiseksi on parasta luopua ideasta lisätä varjoja malleihisi.

Androidissa React Native voi mukauttaa vain varjojen korkeusparametria, koska voit kuvitella, että tulokset eivät ole kaukana täydellisistä. Asiat alkavat näyttää paremmalta iOS-laitteissa, joissa kehittäjillä on enemmän hallintaa ja jotka voivat säätää väriä, opasiteettia tai kulmaa. Mikä vie meidät seuraavaan kohtaan…

Huomaa ero - voit lähentää varjoja iOS: lla ja Androidilla

Android on jäljessä

Vaikka React Native -koodi on kirjoitettu vain kerran, alustat tuottavat sen toisin. Valitettavasti toistaiseksi Android-sovellusten renderointi on paljon vähemmän kehittynyttä ja sitovaa. Suunnittelijoille suurin vastuu on: muista aina tarkistaa ja testata suunnittelun toteutusta eri laitteilla, koska iOS: ssä hyvin toimiva saattaa osoittautua kokonaan sotkuksi Androidilla.

liukuvärit

Toinen tekniikka, varjojen vieressä, on suunnittelijoiden laajalti käytössä, mutta React ei tue sitä laatikosta. Alkuvaiheen taistelun jälkeen onnistuimme toteuttamaan joitain perusgradienteja. Mikään ei ole hienoa, mutta riittävä antamaan sovelluksellemme lisää kiiltoa ja syvyyttä.

Tilapalkit

Suunnittelijat ja kehittäjät eivät yleensä vie paljon aikaa tilarivien pohtimiseen. Me teimme. Asiakkaamme tärkein tuotemerkki on erittäin kirkas vihreä sävy, jota päätimme käyttää valitun näytön navigointipalkin valitsemana värinä. Toiminnallisempiin näkymiin (kuten kassalle) levitettiin kevyempi, vähemmän häiritsevä otsikko. Tämä tarkoitti, että joillakin näytöillä oli tumma tilarivi, kun taas toisilla näytöillä oli vaalea. Sujuvien siirtymien toteuttaminen niiden välillä osoittautui erittäin hankalaksi. Havaitsimme myös ongelmia näytettäessä valintaikkunoita puoliläpinäkyvällä taustalla, koska ne olisivat päällekkäisiä ja piilottavat tilarivin. Yleisesti ottaen on tehtävä paljon koodin säätämistä, jotta tilarivit käyttäytyvät luontaisesti. Olemme todistaneet itsellemme, että se on toteutettavissa, mutta se vaati kuitenkin huomattavia ponnistuksia.

Tilapalkit tumma ja vaalea tila

Viimeisenä, mutta ei vähäisimpänä: WebViews

Yksi suunnittelussa esiintyneistä haasteista oli kuinka sisällyttää useita säätimiä sovelluksen navigointikehykseen. Iso otsikko, joka näyttää kaikki vaihtoehdot selvästi, mutta romahtaa vierittäessä, näytti täydelliseltä ratkaisulta tähän. Valitettavasti se aiheutti paljon ongelmia WebView-näyttöjen toteuttamisessa. Koska WebView-vieritysjuomaa ei ole mahdollista seurata tarkasti, otsikon animaatio olisi poissa synkronoinnista vierityksen kanssa. Lopulta päätimme kiinni kodinäkymien isoista otsikoista ja toteutamme ne natiivisti. Muissa näkymissä piti vaihtaa otsikko tavalliseksi.

Meidän piti luopua ideasta laajennettavasta otsikosta ja keksiä sen sijaan pakattu sovelluspalkki

Kaikki hyvin, se pättyy hyvin

Tässä viestissä olen yrittänyt kartoittaa haasteet, joita suunnittelutiimimme kohtasi työskennellessään React Nativen kanssa. Jotkut heistä olivat hyvin odottamattomia, toiset vaativat muutaman pitkän päivän ja runsaasti aivoriihiä ratkaisemiseksi. Silti koko hankkeen yhteydessä mikään niistä ei estä tiimiämme saavuttamasta tavoitteitamme. Meillä on myös paljon positiivista palautetta tästä tekniikasta:

  • Erittäin lyhyessä ajassa pystyimme rakentamaan täysin toimivan MVP: n alusta alkaen. Suunnittelijalle ei ole suurempi ilo kuin nähdä mallisi toteutettuna ja toiminnassa.
  • React Native on todella hieno tällaisiin hankkeisiin: rakenna MVP, testaa se todellisessa maailmassa, toista ja siirry eteenpäin. Se mahdollistaa myös React-elementtien asteittaisen korvaamisen alkuperäisellä koodilla ja parantaa sovelluksen toimintoja entisestään.
  • Toimme yhdenmukaisen kokemuksen sekä iOS- että Android-käyttäjille. Mutta tämän saavuttamiseksi tarvitaan tiivistä yhteistyötä dev-tiimimme kanssa ja huolellista testausta.
  • React native on nuori, mutta nopeasti etenevä alusta. Sen vahva dev-yhteisö, jota tukee Facebook, parantaa jatkuvasti sitä. Joten vaikka olemme kohdanneet joitain ongelmia, ne saatetaan ratkaista pian.
  • Viimeinen mutta ei vähäisimpänä: React Native tarjoaa loistavan sillan suunnittelun ja kehityksen välillä. Haluatko päästä oman suunnittelijan ajattelutapaan? Vie muutamia tunteja RN: n koodauksen perusteiden oppimiseen, etenkin että oppimiskäyrä on paljon vähemmän jyrkkä kuin muilla etusivulla. Haluatko laittaa tämän tiedon toimintaan? Kassikehys X
Suuri kiitos Lukasz Czarneckille, Illia Lukanowille ja Alex Myronoville siitä, että he jakoivat heidän kanssakäymisensä Reactin kanssa ja selittivät kaikki tämän viestin tekniset yksityiskohdat.

[1]: React Native UI -paketteja on tietysti paljon, mutta niiden tyylivaihtoehdot ovat hyvin rajalliset. Joten mukautetun koodin kirjoittaminen on siis järkevämpää kuin sen uudelleenkäyttö.

[2]: Airbnb oli yksi ensimmäisistä React Native -sovelluksen käyttöönottajista, joka on sen tekniikan suuri puolustaja ja kehittäjäyhteisön avustaja. He ilmoittivat äskettäin RN: n auringonlaskusta ja muuttamisesta takaisin alkuperäiseen. Suosittelemme täysin heidän Medium-viestisarjojaan, jotka antavat yksityiskohtaisen yleiskuvan kokemuksistaan ​​Reaktin kanssa.

Tämän viestin on kirjoittanut Agnieszka Bratek, yksi YND: n vanhemmista tuotesuunnittelijoista. YND: n suunnittelutiimin kanssa hän on auttanut yrityksiä menestyksekkäästi käynnistämään sovelluksia eri toimialoilla: mobiilimaksuista, varainhoidosta, matkavarauksista sähköiseen kauppaan. Tarvitsetko aivovoimaa? Ota meihin yhteyttä osoitteessa [email protected] kysymällä projektejasi.