Implementering af BottomAppBar III: Adfærd til Android

En af de nye Android-materialekomponenter, der er introduceret i Google I / O 2018, er BottomAppBar. Flytning af navigationsskuffekontrol og handlingsmenu til bunden af ​​appskærmen, BottomAppBar bringer et nyt nyt look til Android-apps.

I de to første dele af vores BottomAppBar-serie har vi introduceret BottomAppBar og diskuteret dens attributter. Vi har også forklaret, hvordan man håndterer navigationsskuffekontrol og -handlingsmenu med BottomAppBar. Hvis du ikke har læst dem endnu, kan du finde den første to del af denne serie nedenfor.

Én ting er sikker, at komponenter ikke er statiske i en app. De kan flytte, transformere eller udløse en handling, dvs. de har adfærd. Materialedesign sigter også mod at danne en ramme for disse opførsler. I denne artikel diskuterer vi implementeringsdetaljerne for opførselsforslag til BottomAppBar, der er præsenteret på siden SideAppBar Material Guidelines.

BottomAppBar-layout til sekundære skærme

Opførsel

Layout

Første opførselsretningslinje er på opstillingen af ​​BottomAppBar. Her er hvad der foreslås:

For at understøtte hensigten fra forskellige sektioner i en app kan layout og handlinger i en bund-appbjælke ændres, så de passer til hver skærm.
For eksempel kan skærme vise flere eller færre handlinger, alt efter hvad der passer bedst til skærmindholdet.
Retningslinje for layoutadfærd for BottomAppBar

Baseret på denne retningslinje foreslås det at bruge et BottomAppBar-layout, der viser nogle få handlinger i handlingsmenuen med et centreret FAB i primære skærme. I sekundære skærme, der udløses af de primære skærmbilleder, bør BottomAppBar-layout bestå af en slut-FAB og nogle yderligere handling-menupunkter. Layoutovergange til disse to sager skal håndteres korrekt. Gif'en til venstre er en demonstration af disse retningslinjer.

Lad os se, hvordan vi har implementeret denne opførsel. Vi har to xml-filer under res / menu til handlingsmenuen på hver skærm.

Når skærmovergangsaktion udløses, f.eks. Knappen TOGGLE SCREEN klikkes i vores tilfælde, skal BottomAppBar-layoutet inklusive handlingsmenuen og FAB ændres. Her er den grundlæggende kode for opførsel af BottomAppBar-layout, der går fra den primære skærm til den sekundære skærm.

// Skjul ikon for navigationsskuffe
bottom_app_bar.navigationIcon = null
// Flyt FAB fra midten af ​​BottomAppBar til slutningen af ​​det
bottom_app_bar.fabAlignmentMode = BottomAppBar.FAB_ALIGNMENT_MODE_END
// Udskift handlingsmenuen
bottom_app_bar.replaceMenu (bottomappbar_menu_secondary)
// Skift FAB-ikon
fab? .setImageDrawable (baseline_reply_white_24)

Hvis du vil foretage overgange med animation, kræves en vis yderligere kode. Du kan undersøge kildekoden, der er knyttet til slutningen af ​​dette indlæg, for forbedringer.

Rulning

Rulning er en vigtig opførselstrigger for komponenter som BottomAppBar. På siden Retningslinjer for materialedesign angives den foreslåede adfærd for denne sag som:

Ved rulle kan den nederste applinje vises eller forsvinde:
Rulning nedad skjuler den nederste appbjælke. Hvis der findes en FAB, løsnes den fra linjen og forbliver på skærmen.
Rulning opad afslører den nederste appbjælke og forbindes igen til en FAB, hvis en er til stede.

Nedenfor er demonstrationen sammen med implementeringen af ​​skjul på rulleopførsel i BottomAppBar.

BundAppBar skjul på rulleopførsel

For at aktivere denne opførsel skal BottomAppBar og FAB være direkte børn af CoordinatorLayout i layoutfilen. Derefter aktiverer vi hideOnScroll og sætter rulleflag til BottomAppBar som følger.

Det vil være tilstrækkeligt til at skjule på rulningsadfærd for BottomAppBar.

Elevation

Hver komponent i Material Design verden har en højde, der er analog med vores fysiske verden. BottomAppBar har en højde på 8 dp, hvor indholdet har 0 dp og FAB har en højde på 12 dp i hviletilstand. To komponenter, som vi vil nævne i denne artikel, som er nederste navigationsskuffe og snackbar, har højder på henholdsvis 16dp og 6dp.

Normalt er en snackbar en komponent til at underrette brugeren dukke op fra bunden af ​​skærmen. Hvis skærmen imidlertid har bundenAppBar eller bundnavigeringslinjen, skal snackbarens opførsel ændres. I disse tilfælde skal Snackbar vises over bundkomponenterne, f.eks. BottomAppBar. Her er en demonstration og den relaterede kode til implementeringen.

Snackbar med BottomAppBar

Som nævnt har Navigation Drawer en højde på 16 dp, hvilket betyder - med retningslinjens egne ord -

“Menuer, der genereres af den nederste appbjælke (f.eks. En nederste navigationsskuffe eller overstrømmenu) åbnes som bundplader i en højere højde end linjen. ”

Nedenfor er vores nederste implementering af navigationsskuffen.

Nederste navigationsskuffers opførsel

Selve bundnavigeringsskuffen er et modalt bundark og følger de samme implementeringsregler med det.

Implementationsdetaljerne for denne opførsel er som følger. En xml-menufil til navigationsvisning, der vil inkluderes i skuffen, skal oprettes under res / menu.

Der skal oprettes en layoutfil for det nederste navigationsskufferfragment.

Denne layoutfil indeholder navigationsvisning og de andre komponenter, der danner layout for navigationsskuffen. For at oppustere dette layout har vi brug for en fragmentklasse, der udvider BottomSheetDialogFragment som angivet nedenfor.

Når der klikkes på kontrolikonet for navigationsskuffen, oprettes en instans af dette fragment og vises som angivet i koden herunder.

Når der klikkes på kontrolikonet for navigationsskuffen, åbnes menuen for den nederste navigationsskuffe som et modalt bundark.

Dette afslutter vores BottomAppBar-artikelserie. Du kan finde kildekoden til denne artikel på Github. Skriv gerne kommentarer og still spørgsmål.