Kuidas maksimeerida Androidi kasutajaliidese korduvkasutatavust - 5 levinumat viga

Viimase paari kuu jooksul oli mul võimalus vaadata mõnda meie Grouponi olemasolevat kasutajaliidest. Selle protsessi osana asusime kõigepealt välja selgitama, mis on meie kasutajaliideses head ja millised on meie kõige levinumad vead, lootusega viia Grouponi kasutajaliides järgmisele tasemele.

Mis teeb kasutajaliidese heaks? Hea on suhteline, kuid oli lihtne kokku leppida kolmes peamises põhimõttes, mida saab kasutada mis tahes tarkvara puhul:

  • Loetav. Häid kasutajaliidese komponente on lihtne lugeda. Teil pole vaja külastada Android Stuudio kujunduse vahekaarti, xml on iseenesestmõistetav.
  • Testitav. Iga kasutajaliidese komponenti saab hõlpsalt testida ilma sõltuvate või väliste komponentideta.
  • Korduvkasutatav. Kasutajaliidese komponente saab uuesti kasutada ja laiendada, muutmata nende algset käitumist.

Selles artiklis käsitleme mõningaid levinud vigu, mis mõjutavad meie kasutajaliidese korduvkasutatavust, ja näeme, kuidas korduvkasutatavad kasutajaliidesed saavad muuta meie koodi loetavamaks ja kontrollitavamaks.

1. Ärimudel on kohandatud vaadetes

Mõnikord aja säästmiseks ja dubleeritud koodi vältimiseks otsustame oma vaadetes kasutada samu mudeleid, mida kasutame oma võrgu- ja andmebaasimudelites. Võtame näite:

Kasutaja UserApiClient abil tõmmame oma kasutaja teabe taustaprogrammist:

Edu korral saame mudeli:

Ja edastame selle sama mudeli ka meie kohandatud vaatega UserView, mis näitab kasutaja nime ja aadressi. See võib tunduda kerge võit, kuid ei ole. See läheb vastuollu meie korduvkasutatavuse põhimõttega ja võib pikas perspektiivis põhjustada tõsiseid probleeme. Vaatame, miks.

Miks see halb on?

  • Kõige olulisem põhjus, miks me ei peaks oma taustamudeleid uuesti kasutama, on see, et me ei saa oma vaadet rakenduse teises osas uuesti kasutada. Ühendame oma kasutajaliidese lõpp-punkti vastusega ja nüüd on seda lõpp-punkti vaja meie liidese muutmiseks.
  • Taustaprogrammi mudelis on tõenäoliselt rohkem teavet, kui meie vaade vajab. Lisateave - täiendav keerukus. Mida rohkem teavet mudel sisaldab, seda lihtsam on valet välja kasutada. Ülaltoodud näites oleksime võinud kasutada lihtsustatud mudelit:
  • Mis juhtub, kui taustprogramm muutub? Me kipume eeldama, et meie rakendust toetavad taustateenused ei muutu kunagi. See ei ole kindlasti tõsi, meie taustprogramm muutub ja peame olema selleks valmis. Me ei peaks oma kasutajaliidest muutma ainult seetõttu, et taustprogrammis on midagi muutunud.

Kuidas seda parandada?

Selle probleemi lahendamine on lihtne, kuid see nõuab lisakoodi. Peame looma kasutajaliidese mudeli ja meetodi, et muuta taustaprogrammi mudel kasutajaliidese mudeliks.

Meie näites teisendame UserModeli UserUIModeliks ja edastame selle parameetrina UserView-le:

Meie uus juurutamine nõuab natuke täiendavat torustikku ja lisab uue ümberkujundamise keerukust, kuid see on väike hind, mida maksate kasutajaliidese ja meie taustaprogrammi lahutamiseks. Meie uus kujundus takistab meil saatma oma vaadetele tarbetuid andmeid ja võimaldab meil oma vaateid uuesti kasutada kõikjal, kus neid vajame.

2. Monoliitsed vaated

Kas olete kunagi avanud paigutusfaili ja näinud tohutut dokumenti, mis sisaldab kogu tegevuse kasutajaliidest? See on Androidis kahjuks väga levinud muster, mis põhjustab meile palju probleeme.

Miks see halb on?

See läheb vastuollu meie kolme põhimõttega:

  • Neid faile on tõesti raske lugeda, liiga palju teavet ja liiga palju koos elavaid komponentide kihte.
  • Xml-i iga osa eraldi pole võimalik testida. Me kipume oma kasutajaliidest testima ainult osana espressos teostatavatest integratsioonitestidest. Integratsioonitestid on suurepärased, kuid need segavad kasutajaliidest ja äriloogikat, muutes raskeks teada, mis on vea algpõhjus. Jagades meie monoliitsed xmlid väikesteks kohandatud vaadeteks ja eemaldades kogu äriloogika meie kasutajaliidesest, lubame ainult kasutajaliidese testid. Need testid võimaldavad tuvastada probleeme meie kasutajaliideses peenema detailsuse tasemel kui tavalised integratsioonitestid.
  • Me ei saa oma xml-i üksikuid osi uuesti kasutada, see sunnib neid üksikuid komponente kopeerima ja kleepima, et neid teises ekraanis uuesti kasutada. Aja jooksul hakkavad dubleeritud komponendid lahknema, põhjustades meie rakenduses vastuolusid.

Kuidas seda parandada?

Kogu meie kasutajaliidese loogika üles ehitamine ühte xml-faili on samaväärne kogu meie äriloogika loomisega tegevusklassis. Peaksime oma kasutajaliidese väiksemateks tükkideks murdma, moodustades DAO-sid, mudeleid ja taustkliente oma äriloogika jaoks.

Kohandatud vaated ning sildid ja on meie parimad sõbrad. Peaksime neid alati uute funktsioonide alguses kasutajaliidese katkestamiseks kasutama. UI-komponendi taaskasutamise ootamine monoliitsest xml-st lahti saamiseks võib põhjustada tõsiseid probleeme. Sel ajal on meie kasutajaliides tihedalt seotud meie tegevuse / fragmendiga, muutes reflektori raskemaks ja seades ohtu meie rakenduse olemasolevad funktsioonid.

Vaatame näidet, mis on inspireeritud avatud lähtekoodiga projekti tegelikust paigutusest. Eemaldasin atribuudid ja lisasin kommentaare, et paigutust oleks hõlpsam lugeda:

Isegi pärast atribuutide eemaldamist ja kommentaaride lisamist on sellist xml-i lugeda raske. Pesastatud paigutusi on mitu kihti, mistõttu on raske mõista, kuhu iga komponent paigutatakse. Ilma kommentaarideta on raske öelda, kuidas erinevad sildid on omavahel seotud ja mida nad esindavad.

Xml-is saame tuvastada vähemalt 6 täpselt määratletud kasutajaliidese komponenti. Vaatame, kuidas see paigutus välja näeb, kui loome nendele komponentidele kohandatud vaate:

Luues igale vaatele kohandatud vaate, lihtsustasime oma koodi, muutsime vaateid taaskasutatavaks ja hoidsime ära tulevaste refaktorite kõrvalmõjusid. Selles uues rakenduses pole kommentaarid enam vajalikud, kuna meie kood on ise kirjeldav.

Mõelge, kui lihtne on uue progressianimatsiooni rakendamine, kui kõik meie tegevused kasutavad programmi ProgressOverlay. Selleks on vaja muuta ainult ühte klassi ja kõiki meie tegevusi, kasutades monoliitset lähenemist.

Grouponi lähenemisviis väikeste kasutajaliidese komponentide eelistamisele monoliitsete xml-ide asemel on inspireeritud Brad Frosti raamatust „Aatomikujundus“. Soovitan seda raamatut lähemalt uurida, eriti kui suhtute kirglikult KÜ-sse.

3. Äriloogika kohandatud vaadetes

Eelmises punktis rääkisime kohandatud vaadete kasutamise eelistest. Kohandatud vaated on hämmastav tööriist, kuid kui me neid hoolikalt ei kasuta, võivad need olla kahe teraga mõõk. Ühendada meie äriloogika kohandatud vaatega on üllatavalt lihtne. Logide, AB-testide ja otsustusloogika lisamine võib tunduda suurepärane viis meie koodi lahutamiseks, kuid see pole nii.

Miks see halb on?

  • Meie vaadete loogika raskendab nende taaskasutamist, kuna loogika ühendab meie vaate meie praeguse kasutuse juhtumiga. Selleks, et meie vaated oleksid täielikult korduvkasutatavad, peaksid need jääma lihtsaks ja äriloogika jaoks agnostiliseks. Hästi rakendatud vaate peaks saama ainult riik ja see tuleks edastada ilma mingisuguseid otsuseid vastu võtmata.
  • Äriloogika lisamine meie vaadetele raskendab meie vaadete testimist. Hästi rakendatud vaated sõltuvad ainult väiksematest kasutajaliidese komponentidest. Neid saab automatiseerimistesti osana hõlpsasti isoleerida. Hea automaatika katvus vaate tasemel aitab meil tuvastada meie kasutajaliideses reaktorite ja koodimuutuste varasemaid soovimatuid kõrvalmõjusid.

Kuidas seda parandada?

Äriloogika meie vaadetest väljavõtmiseks on palju võimalusi. Selle teostamise viis sõltub teie eelistatud arhitektuurist. Kui kasutate MVP-d, kuulub saatejuht igasugune loogika. Kui eelistate MVVM-i, peaks teie loogika kuuluma teie ViewModeli.

Grouponis oleme leidnud, et MVI ja ühesuunalised andmevood on suurepärane viis selle probleemi lahendamiseks. Äriloogika peaks olema osa meie kavatsusest, mis loob muutumatu riigiobjekti, mille muudab meie vaade.

Kui olete huvitatud ühesuunalistest andmevoogudest ja korduvkasutatavate kasutajaliidese komponentide rakendamisest. Soovitan tungivalt lugeda Pratyush Kshirsagari ja Yichen WU artiklit Ristivaateline suhtlus Groxi abil. Nad teevad ära suure töö selgitades, kuidas ühesuunalised andmevood võivad aidata meil luua meie kasutajaliidest.

4. Liiga optimeerimine

Sel hetkel võisite aru saada, et me pole jõudlusest rääkinud. Võite isegi olla üllatunud, et me isegi ei pidanud jõudlust oma heade kasutajaliideste üheks põhimõtteks.

Ehkki usume, et jõudlus on oluline, on optimeeritud koodist veelgi olulisem loetav, korduvkasutatav ja kontrollitav kood. Lõppude lõpuks on see põhjus, miks me kasutame tõhusama monteerijakoodi kirjutamise asemel kõrgetasemelisi programmeerimiskeeli.

Androidis on pesastatud paigutused ja topeltmaksustamine kaks suurt probleemi, mis mõjutavad meie kasutajaliidese toimimist. Seetõttu pommitatakse meid pidevalt artiklite, taskuhäälingusaadete ja vestluste kaudu, mis käsivad meil kasutada ConstrainLayout ja vältida pesastatud paigutusi. ConstrainLayout on hämmastav tööriist, võimsam kui RelativeLayout ja sellega ei kaasne topeltmaksustamist. Nagu tavaliselt, ilmneb probleem siis, kui võtame selle äärmusesse.

Kõigi kuuldud artiklite ja vestluste põhjal võime otsustada, et rakendame oma tegevuse kasutajaliidese ainult ühe ConstraintLayout abil.

Miks see halb on?

  • Ehitades kogu oma kasutajaliidese ühte ConstraintLayout, loome monoliitse kasutajaliidese. Mis, nagu me eespool arutasime, on raskesti loetav, seda on raske testida ja see loob ühekordselt kasutatava koodi.
  • Me ei käsitle oma UI-d esimese klassi kodanikuna. Me ei mõtle kunagi kogu oma äriloogika loomist tegevus- / killuklassi. Täpselt samad põhjused kehtivad ka meie kasutajaliidese mitte ühe xml-faili ehitamisel.

Kuidas seda parandada?

Esituse jaoks hea koodi ohverdamine on raske valik ja see peaks alati olema meie viimane võimalus. Ülemäärase optimeerimise vältimiseks peame jõudlustestid muutma oma arendusprotsessi osaks. Meie test peaks meile teada andma, kui meil on mõni probleem, ja me peaksime monoliitse vaate looma alles siis, kui muu lahendus pole võimalik. Teid üllatab, mitu korda kasutajaliidese toimivusprobleeme põhjustab meie siduv loogika liiga palju või see, et meie kood värskendab kasutajaliidest rohkem kui vaja.

5. Meie kasutajaliidese tähelepanuta jätmine koodide ülevaadetes

Koodi ülevaatamine on keeruline, aeganõudev ja selle halvimaks muutmiseks pole xml-faile kerge mõista (eriti monoliitsed xmls). Neil põhjustel kipume koodi ülevaatamisel meie kasutajaliidest unarusse jätma.

Miks see halb on?

  • Meie rakenduse kasutajaliides on selle kasutajatele tutvustav kiri. Järjepidev, puhas ja hästi struktureeritud kasutajaliides võib olla erinevus meie kasutajate vahel, kes jäävad meie rakendusse või lahkuvad sellest.
  • Me ei käsitle oma UI-d esimese klassi kodanikuna. Meie kasutajaliides on pool meie rakendusest, xmlside ja vaadete ülevaatamiseks aega kulutamine on vähemalt sama oluline kui meie äriloogika ülevaatamine.

Kuidas seda parandada?

Oma ülevaatusprotsessi parandamiseks saame teha mõned asjad.

Ülevaatajana:

  • On täiesti hea tõdeda, et me ei saa xml-st aru. Tõenäoliselt pole teil õiget konteksti või kasutajaliides on liiga keeruline. Küsi abi koodi autorilt.
  • Ärge tundke end halvasti, kui palute autoril jagada xml väiksemateks vaadeteks. Sama teete suure klassi või suure meetodi korral.
  • Alustage koodi ülevaatamist kasutajaliidesega. Nagu ma ütlesin, on xml-faile kõige raskem üle vaadata, ärge oodake, et olete väsinud, et neid lugema hakata.
  • Olge tuttav materjalide kujundamise juhistega. Mõned lihtsad asjad, mida ma alati kontrollin, on järgmised: Kas meil on pulseerivat efekti osana meie “pressitud” olekust? Kas meil on / on vaja oma nuppe tõsta? või kas meie animatsioonidel on õige kestus?

Ülevaatajana:

  • Lisage oma pull-taotlusele oma kasutajaliidese ekraanipildid. See aitab teie meeskonnal koodi kiiremini üle vaadata.
  • Paluge oma disaineril teie rakendamine üle vaadata. Teie disainer on teie suurim liitlane. Paluge neil teie kasutajaliides üle vaadata võimalikult arendustsükli alguses.
  • Vältige monoliitseid xml-faile. Ma ei saa seda piisavalt öelda, väikesed kasutajaliidese komponendid on paremad ja hõlpsamini ülevaatatavad.
  • Alustage oma UI-st. Mis tahes uue funktsiooni loomiseks looge kasutajaliidesele pühendatud tõmbetaotlus. Nii saate teada, et teie kasutajaliides saab 100% arvustuse koostaja tähelepanu.

Järeldused

Korduvkasutatavate kasutajaliideste komponentide ehitamine pole keeruline, kuid nõuab distsipliini. See nõuab, et me lõpetaksime ekraanide mõtlemise ja hakkaksime mõtlema komponentide ja nende suhete osas.

UI taaskasutamine aitab meil uusi funktsioone kiiremini üles ehitada. Olemasolevate kasutajaliidese komponentide komponeerimise ja täieliku kasutajaliidese nullist ehitamise vahel on kiiruse ja kvaliteedi osas suur erinevus. Samuti sisaldavad korduvkasutatud komponendid veaparandusi ja arvestavad juhtumitega, millele me pole võib-olla kunagi mõelnud.

Võtab kokku mõned arutatud näpunäited:

  • Ärimudelite kasutamine vaadete jaoks on halb mõte. Lahutage vaated alati taustast ja ettevõtte loogikast.
  • Vältige monoliitseid xmls. Need muudavad teie koodi raskesti loetavaks, raskesti testitavaks ja need on rakenduses ebakõlade peamised põhjused. Aatomikujundus aitab teil jagada kasutajaliidese korduvkasutatavateks komponentideks.
  • Äriloogika ei kuulu kasutajaliidesesse. Logimine, AB-testimine või otsustusloogika ei kuulu vaatesse. Vaated peaksid saama ainult muutumatu oleku ja selle renderdama. MVI omaksvõtmisel on abiks muutmatus ja ühesuunalised andmevood.
  • Koodikvaliteedi arvelt optimeerimine peaks olema erand, mitte kunagi reegel. Pestud paigutuste karistuste vältimiseks peaksime looma ainult monoliitseid vaateid, kui muid võimalusi pole. Ehitage oma kasutajaliides õigesti ja lahendage jõudlusprobleeme ainult siis, kui need tegelikult aset leiavad.
  • Kohelge oma UI-koodi esimese klassi kodanikuna. Alustage mis tahes funktsiooni, ehitades kõigepealt selle kasutajaliidese, paluge disaineril see võimalikult kiiresti üle vaadata ja paluge oma meeskonnal see iseseisvalt üle vaadata.

Loodan, et need näpunäited aitavad teil teie järgmise Androidi seikluse juures. Koos los Carlos Palacin Rubioga Grouponi Androidi meeskonnast.