Composant d'architecture de navigation - Vue détaillée avec CollapsingToolbar

Question

Le projet de s'exercer pour les nouveaux composants de navigation ont été présentés lors de l'I/O avec le modèle suivant et proposé la philosophie:

1. Une Activité pour une Application
2. L'activité contient la Barre d'outils et Barre de Navigation Inférieure

Une application classique a souvent une vue de détail avec un CollapsingToolbar en elle. Comment pourrait-on construire qu'en vertu de ce que l'architecture?

• Déplacer la Barre d'outils de chaque Fragment XML?
• Mettre en œuvre l'effondrement de la barre d'outils par programmation?
• Déplacer le détail fragment de sa propre activité (il peut utiliser son propre deeplink de toute façon) et de "casser" la philosophie?

Answer 1

Une application classique a souvent une vue de détail avec un CollapsingToolbar en elle. Comment pourrait-on construire qu'en vertu de ce que l'architecture?

Excellente question! J'ai du mal avec ce pour un peu ainsi et est venu à la conclusion qu'il doit y avoir une Activité avec un NavHostFragment et, idéalement, rien d'autre. Cela vous donne plus de flexibilité pour afficher (ou pas d'affichage) tout ce dont vous avez besoin pour chaque écran. Surtout, assurez-vous que votre thème supprime l'ActionBar:

<item name="windowActionBar">false</item>
<item name="windowNoTitle">true</item>

Ce qui conduit à votre prochaine question...

Déplacer la Barre d'outils de chaque Fragment XML?

À mon avis, yup! Tout ce que vous pouvez généralement utiliser l'ActionBar pour peut être fait via une Barre d'outils. Voici un petit extrait de code qui montre comment une Barre d'outils peut être utilisé pour faire les choses les plus importantes que vous avez utilisé ActionBar dans le passé (la navigation, le titre, le menu des options, etc...):

toolbar.apply {
    setNavigationOnClickListener { findNavController().navigateUp() }
    setTitle(R.string.toolbar_title)
    inflateMenu(R.menu.fragment_menu)
    setOnMenuItemClickListener(::onMenuItemClick)
}

Mettre en œuvre l'effondrement de la barre d'outils par programmation?

Cela dépend exactement ce que vous êtes en train de faire, mais plus probablement, il n'y a pas besoin de cela. Vous pouvez déposer une AppBarLayout, CollapsingToolbarLayout, et la Barre d'outils dans votre mise en page et les utiliser comme normal. Donner votre AppBarLayout une ActionBar thème de superposition. Voici un exemple:

<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/coordinatorLayout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.AppBarLayout
        android:id="@+id/appBarLayout"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:theme="@style/ThemeOverlay.MaterialComponents.Dark.ActionBar">

        <com.google.android.material.appbar.CollapsingToolbarLayout
            android:id="@+id/collapsingToolbarLayout"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            app:contentScrim="@color/primary"
            app:layout_scrollFlags="scroll|exitUntilCollapsed">

            <androidx.appcompat.widget.Toolbar
                android:id="@+id/toolbar"
                android:layout_width="match_parent"
                android:layout_height="?attr/actionBarSize"
                app:layout_collapseMode="pin"
                app:navigationIcon="@drawable/ic_up_white"/>

            ...

Déplacer le détail fragment de sa propre activité (il peut utiliser son propre deeplink de toute façon) et de "casser" la philosophie?

Pas besoin avec le haut, à droite? C'est une approche qui est suffisamment souple pour s'adapter à plusieurs niveaux facilement dans une nav graphique et toujours être en mesure de personnaliser l'apparence et le comportement de chaque destination dans le graphe (y compris ActionBar les fonctionnalités).

Answer 2

essayez

appBarLayout = (AppBarLayout) findViewById(R.id.appbar);


if(expandToolbar){
                appBarLayout.setExpanded(true,true);
            }else{
                appBarLayout.setExpanded(false,true);
            }

Voici un lien usufal désactiver étendre sur CollapsingToolbarLayout pour certains fragments

aussi pour d'autres personnes inteasing de la modification de certaines parties de leur barre d'outils vous devez écrire votre barre d'outils personnalisée à afficher dans le XML séparé et d'essayer de gonfler la vue personnalisée dans les détails de votre Fragment sur le plan grammatical, puis masquer les éléments non utilisés de l'ancienne barre d'outils si il y a de tout.

setSupportActionBar(toolbar);
View logo = getLayoutInflater().inflate(R.layout.view_logo, null);
toolbar.addView(logo);

et voici comment u peut masquer les Vues non désirées

for (int i = 0; i < toolbar.getChildCount(); ++i) {
        View child = toolbar.getChildAt(i);

        // here u can hide all text views for example.
        if (child instanceof TextView) {
            child.setVisibility(View.GONE );
        }
    }

de cette façon, c'est beaucoup mieux que d'écrire deux activités

Answer 3

Supposons que nous avons

1. Une Activité pour une Application
2. L'activité contient la Barre d'outils et Barre de Navigation Inférieure

Possible toutes les apparences de la barre d'outils que vous avez besoin pour votre application doit être mis en place dans cette barre d'outils unique et contrôlable être le fragment. De ne pas violer le principe d'inversion des Dépendances tous les Fragments qui ont besoin d'une fonction à partir de la barre d'outils doit implémenter une interface. Vous pouvez utiliser le OnBackStackChangedListener pour vérifier les mises à jour de la vue

getFragmentManager().addOnBackStackChangedListener(
    new FragmentManager.OnBackStackChangedListener() {
        @Override
        public void onBackStackChanged() {
            Fragment visibleFragment = ...
            if(visibleFragment instanceof ToolbarControlFragment) {
                if(visibleFragment.shouldExpandToolbar()) {
                    // set AppBarLayout expanded state
                }
                // ...
            }
        }
    }
);

Vous avez peut-être rappeler ce principe lorsqu'un Fragment implique un OptionsMenu.

Je voudrais généralement vous recommandons d'avoir une seule Barre de Navigation Inférieure contrôlé par une activité et plusieurs Barres d'outils dans les Fragments. Cela réduit la complexité et rend les composants de l'application de plus en plus indépendante.