Először szeretném tisztázni, hogy ezt a cikket Liro Krankka írta, és csak engedélyezett fordítást készítek, a cikk végén a hivatkozások lesznek az eredeti cikkhez.

tippekre

Hűvös a csapongás - ringassa.

Modern és friss API-kkal rendelkezünk komplex felhasználói interfészek (UI) kis mennyiségű kódban történő felépítéséhez. A forró újratöltés nagyszerű - 5 képernyő lehetünk a navigációs hierarchiánk mélyén, néhány módosítást végezhetünk a felhasználói felületen, nyomjuk meg a crtl + S billentyűkombinációt és a felhasználói felület kevesebb, mint egy másodperc alatt megváltozik, anélkül, hogy elveszítené az állapotot. De ami a komplex alkalmazásokat illeti, rengeteg felhasználói felület kódot kapunk.

Több kóddal nagyobb felelősség érhető el az olvashatóság érdekében. A kód olvasható tartása megkönnyíti a hosszú távú karbantartást. Nézzünk meg néhány gyors tippet arról, hogyan lehet az UI kódunkat olvashatóbbá tenni.

Alkalmazásainkban a legtöbb dizájn vízszintesen vagy függőlegesen elhelyezett tartalomra épül. Ez azt jelenti, hogy többször fogjuk használni az Oszlop vagy Sor widgeteket.

Mivel a kütyük közvetlenül egymás alá vagy mellé helyezése nem mindig tűnik jónak, szeretnénk, ha margók lennének közöttük. Az egyik legnyilvánvalóbb mód a margó elhelyezésére két kütyü között az, ha az egyiket betakarja egy Padding widgetbe.

Tekintsük a következő példát:

Az oszlopban három szövegmodul van, ezek között 8,0 margó van.

A probléma: "Rejtett widgetek"

A Padding widgetek mindenhol történő használatának problémája az, hogy kezdenek elhomályosítani a felhasználói felület kódjának "üzleti logikáját". Növelje a vizuális zajt behúzási szintek és vonalak számának hozzáadásával.

Amit meg akarunk tenni, az az, hogy a fő widgetek minél jobban kiemelkedjenek. Minden további behúzási szint számít. Ha egyszerre csökkenthetjük a sorszámot, az is nagyszerű lenne.

A megoldás: Használja a SizedBoxes alkalmazást

A rejtett kütyük problémájának leküzdése érdekében az összes Paddinget kicserélhetjük SizedBoxes kütyüre. A SizedBoxes használata a Paddings helyett lehetővé teszi számunkra a behúzási szint és a sorszám csökkentését:

Itt a SizedBox kütyük ugyanazt a funkciót látják el, amikor a Szöveget elválasztják 8,0 margóval.

Ugyanez a megközelítés használható a Row widgetekkel is, mivel a Rows vízszintesen rendezi a gyermek widgetjeit, ezért a SizedBox width tulajdonságát vízszintes margókhoz használhatjuk magasság helyett.

A rendszeres koppintások vagy csapok a leggyakoribb módja annak, hogy a felhasználó interakcióba lépjen alkalmazásainkkal.

Annak lehetővé tételéhez, hogy a felhasználó valahol az alkalmazásunkban "koppinthasson", használhatunk egy GestureDetector modult. használatához be kell csomagolnia az eredeti modult, és meg kell adnia a visszahívást az onTap tulajdonságban a GestureDetector konstruktorban.

Vizsgáljuk meg az alkalmazás példáját (amelyet az eredeti író készített) az inKino alkalmazásban:

Az inKino alkalmazás rendelkezik egy Grid filmplakátokkal. amikor a felhasználó megérinti egyiküket, akkor el kell vinni a film részleteinek oldalára.

A probléma: Felhasználói felület kódjának összekeverése a logikával

A mi összeállítási módszerünk csak az alkalmazásunk felhasználói felületének felépítéséhez szükséges minimumot tartalmazhatja. Az onTap logikája nem kapcsolódik az UI felépítéséhez, ez felesleges zajt ad a build módszerhez.

Ebben az esetben gyorsan megállapíthatjuk, hogy a Navigator.push új útvonalat ír-e be, és ez az EventDetailsPage, ezért a Rács egyik elemére koppintva megnyílik annak részletei oldala. Ha azonban az onTap hívás szerepel, akkor ehhez szükség lehet még egy kis olvasásra a build módszer megértéséhez.

A megoldás: Bontsa ki a logikát egy privát módszerre

Ez a probléma megoldható az onTap hívás kibontásával egy jól megnevezett helyre magán módszer. Ebben az esetben létrehozunk egy _openEventDetails nevű metódust:

Ez jobb.

Mivel az onTap hívást egy jól megnevezett módszerrel bontották ki, nem kell elolvasnunk a teljes kódot. Most már egyszerűen a metódus nevének elolvasásával könnyen megérthető, hogy mi történik az onTap hívás meghívásakor.

Most csökkentjük a drága építési módszerünk sorainak számát, és csak a felhasználói felület kódjának olvasására koncentrálunk.

Néha az Oszlop vagy Sor gyermekmoduljai nem lehetnek láthatóak. Például az inKino példáját követve, ha egy filmnek valamilyen oknál fogva nincsenek cselekmény részletei, akkor nincs értelme üres szöveget megjeleníteni a felhasználói felületünkön.

Az oszlop vagy sor gyermekeinek kondicionálásának általános módja így néz ki:

Az elemek feltételes hozzáadása az oszlophoz lényegében egyszerű: inicializáljuk a helyi kütyü listát, és ha az megfelel annak feltételeinek, akkor hozzáadjuk a listához. Végül átadjuk ezt a listát az Oszlop gyermekparaméterének.

Ebben az esetben a Finnkino API (az inKino alkalmazásban használt API) nem mindig adja vissza a film vagy a film szereplőinek részleteit.

A probléma: ha mindenhol

Bár ez működik, ezek a fiatalok nagyon gyorsan megöregednek.

Bár könnyen érthetőek, felesleges helyet foglalnak el az építési módszerünkben. Különösen, ha három vagy több van.

A megoldás: globális módszer az utilson belül.

A probléma leküzdése érdekében létrehozhatunk egy globális hasznos módszert, amely feltételezi a hozzáadandó widgeteket. Az alábbiakban bemutatjuk a Flutter Framework fő kódjában használt mintát.

Ahelyett, hogy megismételnénk a widgetek gyermeklistára történő felvételének feltételes logikáját, létrehozunk egy hasznos globális módszert, amely tartalmazza.

Miután meghatároztuk a módszert, csak importálja a fájlt, és használja a globális módszert.

Itt azt tettük, hogy a _buildMywidget () metódusunk most egy widgetet vagy nullat ad vissza, attól függően, hogy a feltétel igaz-e vagy sem. Ez lehetővé teszi számunkra, hogy helyet takarítsunk meg az építési módszerünkben, különösen, ha sok feltételes widgetünk van.

A legjobbat hagyd legutoljára.

Ez talán az egyik legelterjedtebb probléma tervezési kódunkban. A Flutter felhasználói felületének általános panasza az, hogy a behúzási szintek őrülten nőnek, sok zárójelet eredményezve.

Tekintsük a következő példát:

A fenti példa az inKino alkalmazásból származik, és tartalmazza a kódot a filmek listájának összeállításához az ütemezésükkel együtt. Szándékosan csúnyává tettem (az eredeti író). Sok minden csökkent, hidd el, amikor azt mondom, hogy a teljes példa valami nagyszerű lett volna.

Lényegében ez a kód a rossz fiúk megjelenítésére:

Ha mobileszközön olvassa ezt, sajnálom. A felső kód még nagy képernyőkön sem szép. Miért? Biztos vagyok benne, hogy a legtöbben már tudják.

A probléma: Használta-e valaha a Lisp-t?

Ennek a régi programozási nyelvnek, Lisp-nek hívják a szintaxist, amely sok zárójelet használ. A Flutter interfészeket elég sokszor láttam összehasonlítani a Lisp-vel, és hogy őszinte legyek, látom a hasonlóságot.

Elképesztő, hogy ezt még senki nem tette meg, így tessék.

"Hogyan lehet megmenteni a hercegnőt a csapkodással"

Annak ellenére, hogy a fenti kód működik, elég csúnya ránézni. A behúzási szintek meglehetősen messzire mennek, sok a függőleges rendetlenség, a zárójel, és nehéz követni mindent, ami történik, és ahol történik.

Csak nézze meg a zárójeleket a végén:

Az ilyen mély fészkelés miatt, még jó IDE esetén is nehéz új elemeket hozzáadni a tervezésünkhöz. Nem beszélve a felhasználói felület kódjának elolvasásáról.

Javítás: az UI különböző részeit refrakterezzük külön widgetekké

A fordító megjegyzése: A cikk eredeti verziója megemlítette a módszerek alkalmazását osztályok helyett, de mivel Wm Leler felhasználó az eredeti cikk megjegyzésében megemlítette, hogy a módszerek használata anti-minta A Flutter alkalmazások előadásában az eredeti szerző frissítette cikkét, és létrehozott egy másik témát, amelyet ennek a témának szenteltek (a fordításon dolgozom). A következő a már frissített cikk fordítása.

A listánknak két különböző része van: a bal és a jobb.

A bal rész a most kezdődő és befejező filmekről tartalmaz információkat. A jobb oldalon olyan információk találhatók, mint a cím, és ha 2D vagy 3D formátumban vannak. Annak érdekében, hogy a kód olvashatóbb legyen, kezdjük azzal, hogy szétválasztjuk azt két _LeftPart és _RightPart nevű widgetre.

Mivel a bemutatótípust bemutató widget a jobb oldalon sok függőleges rendetlenséget és mély fészkelést fog bevezetni, ezért egy másik _PresentationMethod nevű widgetben szétválasztjuk. Eredeti szerzői megjegyzés: ne válassza szét a build metódust különböző módszerekre, amelyek anti-performance minták, és megérdemlik a saját cikkét.

Ezekkel a változásokkal a behúzási szint felére csökkent. Most könnyű beolvasni a felhasználói felület kódját, és megnézni, mi történik.

Nem tartom ezt a felettesekhez hasonló problémának, de mégis valami nagyon fontos. Miért? meglátjuk.

A probléma bemutatásához nézzük meg a következő kódot:

Valahogy furcsa, nem? Természetesen nem olyasmi, amit jó kódban lát.

A probléma: a dartfmt használata nem lehetséges

A fenti kód nem tart be semmilyen általános formázási konvenciót a Dartban - úgy tűnik, hogy a kód készítője saját stílusát találta ki. Ez nem jó, mivel a kód elolvasása különös figyelmet igényel - nem kezeli a megszokott konvenciókat.

A közösen elfogadott kódstílus elengedhetetlen. Ez lehetővé teszi számunkra, hogy elkerüljük a furcsa stílushoz való szoktatás mentális tornáját.

A megoldás: csak a dartfmt-t használja

Szerencsére van hivatalos dartfmt nevű „formázónk”, amely gondoskodik a formázásról számunkra. Továbbá, mivel létezik „formátummonopólium”, elkerülhetjük a vitát arról, hogy melyik formátum a jobb, és inkább a kódunkra koncentrálunk.

Fő szabály, hogy mindig vesszőt tegyél az összes zárójel után, és futtasd a dartfmt-t.

Az előző, már formázott kód sokkal olvashatóbb.

Jobb. A kódunk formázását mindig emlékezni kell vesszőire, és formázni kell a kódot a dartfmt használatával.

Nagyon szépen köszönöm az eredeti szerzőnek, aki lehetővé tette számomra a cikk lefordítását, és remélem, hogy ez az információ a spanyol ajkú közösséget szolgálja.

Link az eredeti cikkre, a szerző twitter profiljára és oldalára.