Компонент архитектуры навигации - подробный вид с CollapsingToolbar

Ответ 1

пытаться

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


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

Здесь отключена ссылка usufal link на CollapsingToolbarLayout для определенных фрагментов

также для других людей, стремящихся изменить некоторые части своего инструментария, вы должны написать свой собственный вид панели инструментов в отдельном XML и попытаться раздуть пользовательский вид в своих деталях. Фрагмент грамматически затем скрыть неиспользуемые элементы старой панели инструментов, если таковые имеются.

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

и вот как вы можете скрывать нежелательные взгляды

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 );
        }
    }

этот способ намного лучше, чем писать два действия

Ответ 2

Предположим, что мы имеем

1. Одна активность для приложения
2. Действие содержит панель инструментов и нижнюю панель навигации

Все возможные виды панели инструментов, которые вам нужны для вашего приложения, должны быть реализованы на этой единственной панели инструментов и быть управляемыми в данный момент активным фрагментом. Чтобы не нарушать принцип инверсии зависимостей, все фрагменты, которым требуется функция с панели инструментов действий, должны реализовывать интерфейс. Вы можете использовать OnBackStackChangedListener для проверки обновлений представления

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

Возможно, вы помните этот принцип, когда для фрагмента требуется меню параметров.

Как правило, я бы рекомендовал иметь только одну нижнюю панель навигации, контролируемую действием, и несколько панелей инструментов во фрагментах. Это уменьшает сложность и делает компоненты приложения более независимыми.

Ответ 3

Типичное приложение часто имеет детальное представление с CollapsingToolbar. Как можно построить это под эту архитектуру?

Отличный вопрос! Я тоже немного поборолся с этим и пришел к выводу, что должен быть один Activity с NavHostFragment и, в идеале, больше ничего. Это дает вам максимальную гибкость для отображения (или не отображения) того, что вам нужно для каждого экрана. Важно отметить, что ваша тема удаляет панель действий:

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

Что приводит к вашему следующему вопросу...

Переместить панель инструментов в каждый фрагмент XML?

На мой взгляд, да! Все, что вы обычно используете ActionBar, может быть сделано через панель инструментов. Вот краткий фрагмент, показывающий, как можно использовать панель инструментов для выполнения самых важных задач, которые вы использовали в ActionBar в прошлом (навигация вверх, заголовок, меню параметров и т.д.):

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

Реализовать сворачивающуюся панель инструментов программно?

Это зависит от того, что именно вы пытаетесь сделать, но, скорее всего, в этом нет необходимости. Вы можете добавить AppBarLayout, CollapsingToolbarLayout и панель инструментов в свой макет и использовать их как обычно. Дайте вашему AppBarLayout наложение темы ActionBar. Вот пример:

<?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"/>

            ...

Переместить фрагмент детали в его собственное действие (оно может использовать свою собственную ссылку в любом случае) и "сломать" философию?

Нет необходимости в этом выше, верно? Это достаточно гибкий подход, позволяющий легко разместить несколько уровней на одном навигационном графе и при этом иметь возможность настраивать внешний вид и поведение каждого пункта назначения на графике (включая функциональность, подобную ActionBar).