Aastate jooksul olen näinud Androidi navigeerimismustri erinevaid rakendusi. Mõnes rakenduses kasutati ainult tegevusi, samas kui muud tegevused olid segatud lõikude ja / või kohandatud vaadetega ( Kohandatud vaated ).
Üks minu lemmikfragmentmustrite rakendusi põhineb filosoofial “One-Activity-Multiple-Fragments” (“ Ühekordne tegevus - mitu fragmenti Või lihtsalt fragmendi navigeerimismuster ( Fragmenti navigeerimismuster ), kus rakenduse iga ekraan on täisekraani fragment ja kõik või enamik neist fragmentidest asuvad tegevuses.
See lähenemisviis mitte ainult ei lihtsusta navigeerimise rakendamist, vaid on ka parema jõudlusega ja pakub seetõttu paremat kasutuskogemust.
Selles artiklis uurime mõningaid levinumaid navigeerimismustreid Androidis, seejärel tutvustame katkenditel põhinevat navigeerimismustrit. Selle mustri rakendava näidisrakenduse leiate aadressilt GitHub .
Tegevuste maailm
Tüüpiline Androidi rakendus, mis kasutab ainult tegevusi, on korraldatud Puu tüüpi struktuuris (täpselt suunatud graafikus), kus põhitegevuse algatab kanderakett . Rakenduse sirvimise ajal kuvatakse tagumine virn ”Tegevusest, mida säilitatakse tänu opsüsteemile.
Järgmisel diagrammil on esitatud lihtne näide:
Tegevus A1 on meie rakenduse sisenemispunkt (näiteks see tähistab esialgset ekraani või peamenüüd) ja sellest hetkest saab kasutaja navigeerida punktidele A2 või A3. Kui teil on vaja suhelda tegevuste vahel, mida saate kasutada startActivityForResult () Või võite jagada globaalselt ligipääsetavat äriloogilist objekti mõlema tegevuse vahel.
Kui peate lisama uue tegevuse, peate järgima järgmisi samme:
- Määratlege uus tegevus
- Registreerige see saidil AndroidManifest.xml
- Avage see a-ga startActivity () teisest tegevusest
Kuigi see navigeerimisskeem on üsna lihtsustatud lähenemine; kuid see võib vajadusel väga keeruliseks muutuda manipuleerida tagumine virn või kui peate sama tegevust mitu korda uuesti kasutama, näiteks kui soovite, et kasutaja liiguks läbi erinevate õpetusekraanide, kuid igal ekraanil kasutatakse baasina sama tegevust.
Õnneks on meil nende juhtumite jaoks tööriistu majapidamistööd ja mõned juhendid a navigeerimine tagumine virn asjakohane .
kevadpartii koos vedrusaapaga
Siis saabusid fragmendid API tasemega 11 ...
Killude maailm
Android tutvustab juppe Android 3.0-s (API tase 11), peamiselt selleks, et toetada dünaamilisemat ja paindlikumat kasutajaliidese paigutust suurtel ekraanidel, näiteks tahvelarvutitel. Kuna tahvelarvuti ekraan on palju suurem kui telefoni oma, on kasutajaliidese komponentide segamiseks ja sobitamiseks rohkem ruumi. Katkendid toetavad neid paigutusi ilma, et peaksite vaate hierarhias keerulisi muudatusi haldama. Tükeldades tegevuse paigutuse tükkideks, saate muuta tegevuse välimust jooksmise ajal ja hoida need muudatused tegevuse hallatavas tegevuste korstnas. - tsitaat Google'i juhendist Fragmentide API .
See uus mänguasi võimaldas arendajatel luua mitme paneeliga kasutajaliidese ja osata komponente teistes tegevustes uuesti kasutada. Mõni arendaja armastab seda, teine aga Mitte nii palju . Juppide kasutamine või mitte, on populaarne arutelu, kuid arvan, et kõik nõustuvad, et jupid tõid täiendavat keerukust ja arendajad peavad neist kasutamiseks õigesti aru saama.
Täisekraanilõigu košmaar Androidis
Hakkasin nägema üha uusi näiteid, kus fragmendid ei kujutanud mitte ainult osa ekraanist, vaid kogu ekraan oli fragment ühe tegevuse sees. Kunagi nägin paigutust, kus igal tegevusel oli täpselt üks täisekraanilõik ja mitte midagi muud ning ainus põhjus, miks need tegevused olid, oli juppide salvestamine. Peale disainivea on selle lähenemisega veel üks probleem. Heitke pilk allolevale skeemile:
Kuidas saab A1 F1-ga suhelda? Mis juhtub, on see, et A1-l on täielik kontroll F1 üle, sest see lõi F1. A1 võib paketi läbida näiteks F1 loomisel või kasutada oma avalikke meetodeid. Kuidas saab F1 A1-ga suhelda? Noh, see on keerulisem, seda saab lahendada mustriga tagasihelistamine / vaatleja kus A1 liitub F1-ga ja F1 teatab A1-st.
Kuidas saavad aga A1 ja A2 suhelda? Nagu eespool selgitatud, said nad suhelda startActivityForResult () .
Ja nüüd tõeline küsimus: kuidas saavad F1 ja F2 suhelda? Isegi sel juhul võib meil olla äriloogika komponent, mis on ülemaailmselt juurdepääsetav ja mida saab kasutada andmete edastamiseks. Kuid see komponent ei võrdu alati uhke kujundusega. Mis siis, kui F2 peab teabe otse F1-le edastama? Sellisel juhul mustriga helista tagasi F2 saab A2-le teatada, siis lõpeb A2 tulemusega ja selle tulemuse saab salvestada A1, kes saab F1-st teavitada.
See lähenemine nõuab palju koodi katlakivi ja muutub kiiresti selle allikaks vigu , valu ja viha.
Mis oleks, kui saaksime vabaneda kõigist tegevustest ja jätta alles vaid üks neist, mis hoiab alles ülejäänud killud?
c++ õppematerjalid
Fragmenti navigeerimismuster
Aja jooksul hakkasin enamikus oma rakendustes kasutama mustrit 'Üks tegevus-mitu fragmenti' ja kasutan seda siiani. Seal on palju arutelusid näiteks selle lähenemise või filosoofia üle siin Y siin . Igatsesin konkreetset näidet, mida näen ja saan ise proovile panna.
Vaatame hetkeks järgmist skeemi:
Nüüd on meil ainult üks konteinerite tegevus ja meil on mitu fragmenti, mis on jälle puu tüüpi struktuuris. Nendevahelist navigeerimist haldab FragmentManager , sellel on oma tagumine virn .
5 parimat tutvumissaiti 2015
Saate aru, et nüüd pole meil seda startActivityForResult () kuid me saame rakendada mustrit tagasihelistamine / vaatleja . Vaatame nüüd selle lähenemise mõningaid plusse ja miinuseid:
Plussid:
1. Puhtam ja hooldatavam AndroidManifest.xml
Nüüd, kui meil on ainult üks tegevus, ei pea me enam iga kord uue ekraani lisamisel manifesti värskendama. Erinevalt tegevustest ei pea me fragmente deklareerima.
See võib tunduda väike asi, kuid suuremate rakenduste puhul, kus on rohkem kui 50 tegevust, võib see märkimisväärselt parandada AndroidManifest.xml faili.
Vaadake näidisrakenduse manifestifaili, millel on mitu ekraani. Manifesti fail on ülilihtne.
package='com.exarlabs.android.fragmentnavigationdemo.ui' > 2. Tsentraliseeritud navigatsioonihaldus
Minu näidiskoodis märkate, et ma kasutan NavigationManager mis minu puhul süstitakse igasse fragmenti. Seda haldurit saab kasutada keskuse jaoks metsaraie , juhtimine tagumine virn muu hulgas nii, et sirvimiskäitumine on ülejäänud äriloogikast lahti ühendatud ega levinud erinevate ekraanide rakenduste vahel.
Kujutame ette olukorda, kus me tahame käivitada ekraani, kus kasutaja saab valida inimeste nimekirjast mõned üksused. Samuti peaksite edastama mõned filtreerivad argumendid, näiteks vanus, amet ja sugu.
Tegevuste puhul kirjutaksite:
Intent intent = new Intent(); intent.putExtra('age', 40); intent.putExtra('occupation', 'developer'); intent.putExtra('gender', 'female'); startActivityForResult(intent, 100); Siis peate määratlema onActivityResult kusagil all ja tulemusega hakkama saada.
@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); } Minu isiklik probleem selle lähenemisviisi juures on see, et need argumendid on 'lisad' ja neid ei nõuta, nii et ma pean veenduma, et vastuvõttev tegevus tegeleb erinevate juhtumitega, kui mõni lisa puudub. Hiljem, kui on tehtud refaktoreerimine ja kui lisatasu, näiteks 'vanust' pole enam vaja, pean ma läbi vaatama kogu koodi, kust see tegevus algas, ja veenduma, et kõik lisad oleksid õiged.
Kas poleks parem, kui tulemus (inimeste nimekiri) saabuks kui _List_ ja mitte jadavormis, mis tuleb seejärel deserialiseerida?
Katkendipõhise sirvimise korral on kõik sirgjoonelisem. Kõik, mida peate tegema, on meetodi kirjutamine NavigationManager helistas startPersonSelectorFragment () vajalike argumentide ja teostusega helista tagasi .
mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', new PersonSelectorFragment.OnPersonSelectedListener() { @Override public boolean onPersonsSelected(List selection) { [do something] return false; } }); Või koos RetroLambda
mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', selection -> [do something]); 3. Paremad suhtlusviisid ekraanide vahel
Tegevuste vahel saame jagada ainult paketti, mis sisaldab primitiivseid või jadastatud andmeid. Nüüd saame fragmentidega rakendada mustrit helista tagasi kus näiteks F1 saab kuulata suvalistest objektidest mööduvat F2. Vaadake palun varasemaid rakenduse näiteid helista tagasi , mis tagastab _List_.
4. Fragmentide loomine on odavam kui Tegevuste loomine
See saab ilmseks, kui kasutate sahtlit, millel on näiteks 5 menüüpunkti ja igal lehel peaks sahtlit uuesti näitama.
Puhta tegevuse sirvimise korral peaks iga leht täituma ja sahtli käivitama, kuid see on muidugi kallis.
Näidatud diagrammil näete mitut root või fragmenti juurfragmendid (FR *), mis on ekraanilõigud, millele pääseb ligi otse sahtlist, ja ka sahtlile pääseb juurde ainult siis, kui neid juppe kuvatakse. Kõik diagrammil märgitud joonest paremal on suvalise navigeerimisskeemi näiteks.
Kuna sisaldav tegevus sisaldab sahtlit, on meil ainult üks sahtli eksemplar, seega peaks iga navigeerimisetapp, kus sahtel peaks olema nähtav te ei pea seda uuesti alustama . Kas pole ikka veel veendunud, kuidas kõik töötab? Vaadake minu näidisrakendust, kus demonstreeritakse sahtlite kasutamist.
Miinused
Minu suur hirm on alati olnud see, et kui kasutan projektis fragmentide navigeerimismustrit, siis mingil hetkel puutun kokku mõne tundmatu probleemiga, mida on keeruline lahendada fragmentide, kolmandate osapoolte teekide ja süsteemi erinevate versioonide keerukuse ümber. Operatiivne. Mis oleks, kui ma peaksin murdma kõik, mida olen seni teinud?
tehisintellekt äriintellektis
Tegelikult peaksite probleemid lahendama pesastatud fragmendid , kolmandate osapoolte raamatukogud, mis kasutavad juppe ShinobiControls , ViewPagers Y FragmentStatePagerAdapterid .
Tunnistan, et nende probleemide lahendamiseks oli fragmentidega piisavalt kogemusi saada pikk protsess. Kuid mõlemal juhul ei olnud probleem selles, et filosoofia oleks halb, vaid selles, et ta ei mõistnud piisavalt fragmente. Aga kui sa mõistad fragmente paremini kui mina tol ajal, siis pole sul probleemi.
Ainus miinus, mida ma nüüd mainin, on see, et leiame probleeme, mille lahendamine pole triviaalne, sest pole küpset raamatukogu, mis näitaks fragmentide põhise navigeerimisega keerulise rakenduse kõiki keerukaid stsenaariume.
järeldus
Selles artiklis oleme näinud alternatiivi navigeerimise rakendamiseks rakenduses Android . Mustrit võrreldi traditsioonilise navigeerimisfilosoofiaga, mis kasutab tegevusi ja nägime väga häid põhjuseid, miks on traditsioonilise lähenemise asemel kasulik kasutada fragmente.
Kui te pole seda veel üle vaadanud, vaadake juurutuses olevat demorakendust GitHub . Ärge kartke anda häid näiteid, mis võiksid selle kasutamist paremini näidata.
Seotud: Kümme kõige levinumat viga, mida Androidi arendajad teevad
