Navigation Drawer + Fragments: допиливаем гугловский гайд

[serso]

Если вы добавили 3 фрагмента в back stack, то вам нужно будет нажать 3 раза кнопку back, чтобы их оттуда убрать. Четвёртое нажатие закроет activity, т.к. back stack будет пустым. Чтобы правильно решить проблему создавайте первый фрагмент без добавления в back stack.

[Oksumoron]

О! Спасибо! Попробую.

[Bolloky]

В качестве айдишников фрагмента прекрасно подходят строковые ресурсы.

@Override
public void onFragmentChanged(int id) {
    switch (fragmentType) {
    case R.string.title1: mDrawerList.setItemChecked(0, true);
        break;
    case R.string.title2: mDrawerList.setItemChecked(1, true);
        break;
    }
    setTitle(id);
}

[Oksumoron]

При разделении айдишника и заголовка появляется возможность генерить заголовки динамически в зависимости от содержания фрагмента, что мне важно. Как я писала — то же ФИО автора или заголовок текущего рассказа.

[mairos]

Вы предлагаете по кнопке Back открывать предыдущий экран верхнего уровня Navigation Drawer? Это очень похоже на «анти-паттерн навигации в Android № 6». Гайдлайны Google это явным образом не рекомендуют (System Back at the top level of the app).

[Oksumoron]

Читайте внимательнее. Я предлагаю по кнопке Back открывать предыдущий открытый пользователем фрагмент, как это рекомендует гугл. При таком возврате в Экшнбаре и в самом навигаторе информация должна обновиться, но сама она не обновляется — об этом приходится заботиться разработчику.

[Zeliret]

Казалось бы – можно поручить обновление заголовка самому фрагменту, но, во-первых, это не тривиально, т.к. из FragmentActivity нет прямого доступа к getSupportActionBar()
Не совсем понял. Из фрагмента есть же доступ к ActionBar через хост-активити.

[Oksumoron]

getActivity() возвращает FragmentActivity, у которой доступа нет. Делать насильственное преобразование типов — плохо. Лучше через слушатели связку реализовать.

[withoutuniverse]

Что за глупости. Если я наверняка знаю, что все мои фрагменты лежат в BaseActivity, то всегда могу вызвать ее метод.

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);
    mActivityContract = (ActivityContract) activity;
}

Ваши слова себе же противоречат:

Сами фрагменты в onAttach регистрируют Activity как слушатель

Не понимаю, как будет реализована связка через слушателей без того же преобразования типов — приведите пример, пожалуйста.

Соглашусь в том, что Activity должен руководить изменениями в ActionBar, а не фрагмент, так как в таком случае проще будет добавлять поддержку планшетов и прочих модернизаций, касающихся функционала.

[Oksumoron]

Не совсем корректно выразилась ранее. Я считаю, что делать насильственное преобразование типа к конкретной реализации активити — плохо, а к интерфейсу, который она имплементит — правильно. При этом зашивать в каждый фрагмент код обновления каких-то кусков, которыми рулит активити — плохо, передавать ей полномочия на управление и данные для этого управления — правильно. Вопросы сугубо архитектуры приложения.

[withoutuniverse]

Теперь я вас понял.
Поддержу вас в том, что для расширяемости приложения удобнее логику работы с ActionBar хранить в Activity (ну если только архитектура это позволяет, ведь какой-нибудь ToolBar может быть прямо внутри фрагмента, и стучать колбэками из Activity в него плохой стиль, имхо).
И все же не вижу существенной разницы в приведении типа между Object и IObject. Можете обосновать этот момент — почему это вам не нравится?

[Oksumoron]

По поводу интерфейсов я согласна с одним из основных принципов проектирования: «Программируйте на уровне интерфейсов, а не на уровне реализации». Такой подход обеспечивает гораздо большую гибкость в очень многих случаях. Конечно, далеко не везде его имеет смысл применять — например, для крошечных задач создавать отдельный интерфейс нелепо. Но для подобных — вполне оправданно.

Возвращаясь к данному частному случаю — а захотите вы добавить еще одну активити с подобным же функционалом. Вот у меня их уже две. Чтобы реализовать преобразование типов на уровне объектов, нужен будет общий предок и изменение кода, завязанного на ранее использованный класс. В случае использования интерфейсов в уже написанный код лезть не придется.

[andkulikov]

а можно еще и от интерфейсов и приведения к ним отказаться и перейти на логику ивентов с помощью либы
github.com/greenrobot/EventBus
или подобной. активити регистрируется как слушатель ивента смены фрагмента. а фрагмент посылает эти ивенты, в которые вкладывает нужную информацию с айдишником и текстом для экшнбара. так еще гибче получается

[Oksumoron]

Может быть. Но стоит и соблюдать баланс между гибкостью и объемом кода. Если задачу можно решить несколькими строками — зачем цеплять либу?

Но себе запомнила, спасибо. Вдруг, когда пригодится :)

[andkulikov]

хотя бы потому что это лишь одна из задач, которые можно решить этим подходом, вариантов на большой проект кучи) и либа сама по себе очень легкая и компактная по объему кода. еще можно использовать для тех же целей LocalBroadcastReceiver из support библиотеки, но он не такой удобный.

[Oksumoron]

Если в приложении есть куча задач, которые требуют такого решения — да, обосновано. Если нет — я предпочитаю более легкие решения. Мне пока Броадкаст ресивер и иже с ним без надобности, поэтому обхожусь слушателями для связки активити с фрагментами. Но на заметку взяла — не последнее приложение, надеюсь, пишу.

[danikula]

«Большая сила порождает большую ответственность» (с): )
EventBus и им подобные решения — очень мощные, но опасные, т.к. уменьшают очевидность хода выполнения приложения.