Építési módszerek bevezetése egy diéta tippekre és trükkökre a tisztább felhasználói felület kódja érdekében a Flutter by oldalon
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.
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.