Сколько действий против фрагментов?

Вступление:

Базовый паттерн "Учебник по фрагментам" выглядит примерно так:

  1. На планшете есть список слева, подробности справа.
  2. Оба Fragments и оба проживают в одном и том же Activity,
  3. На телефоне есть список Fragment в одной Activity,
  4. Запустить новый Activity с деталями Fragment,

(Например, API 3.0 Фрагментов Android 3.0 от Дайан Хэкборн и Руководство по API Фрагментов)

На обоих устройствах функциональность Fragments, (просто)

На планшете все приложение 1 Activity по телефону их много Activities,

Вопросы:

  • Есть ли причина разделять приложение телефона на множество Activities ?

Одна из проблем этого метода заключается в том, что вы дублируете много логики в основном планшете. Activity и в отдельном телефоне Activities,

  • Не будет ли проще сохранить модель 1 Activity в обоих случаях, используя одну и ту же логику переключения? Fragments вход и выход (только с использованием другого макета)?

Таким образом, большая часть логики находится в Fragments сами по себе, и есть только один Activity меньше дублирования кода.

Также то, что я прочитал о ActionBarSherlock является то, что, кажется, лучше всего работает с Fragments вместо Activities (но я еще не работал с этим).

Упрощены ли учебники, или я упустил что-то важное в этом подходе?

Мы успешно испробовали оба подхода в офисе, но я собираюсь начать более крупный проект и хочу сделать все как можно проще для себя.

Некоторые ссылки на связанные вопросы:

Обновления

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

Также найдена интересная статья ребят на площади, которую стоит прочитать:

Источник

5 ответов

Решение

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

Я также согласен с тем, что не стоит дублировать логику вашего приложения во многих видах деятельности (см. " Принцип СУХО" в Википедии).

Я предпочитаю шаблон, используемый ActionBarSherlock Фрагменты демонстрационного приложения ( скачать здесь и исходный код здесь). Демонстрация, которая наиболее соответствует учебнику, упомянутому в вопросе, называется "Макет" в приложении; или же FragmentLayoutSupport в исходном коде.

В этой демонстрации логика была удалена из Activity и в Fragment, TitlesFragment на самом деле содержит логику для изменения фрагментов. Таким образом, каждое действие очень просто. Дублировать многие очень простые действия, в которых нет логики внутри действий, сделать это очень просто.

Поместив логику во фрагменты, нет необходимости писать код более одного раза; он доступен независимо от того, в какую деятельность помещен фрагмент. Это делает его более мощным паттерном, чем тот, который предлагается в базовом уроке.

    /**
    * Helper function to show the details of a selected item, either by
    * displaying a fragment in-place in the current UI, or starting a
    * whole new activity in which it is displayed.
    */
    void showDetails(int index)
    {
        mCurCheckPosition = index;

        if (mDualPane)
        {
            // We can display everything in-place with fragments, so update
            // the list to highlight the selected item and show the data.
            getListView().setItemChecked(index, true);

            // Check what fragment is currently shown, replace if needed.
            DetailsFragment details = (DetailsFragment) getFragmentManager()
                .findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index)
            {
                // Make new fragment to show this selection.
                details = DetailsFragment.newInstance(index);

                // Execute a transaction, replacing any existing fragment
                // with this one inside the frame.
                FragmentTransaction ft = getFragmentManager()
                    .beginTransaction();
                ft.replace(R.id.details, details);
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        }
        else
        {
            // Otherwise we need to launch a new activity to display
            // the dialog fragment with selected text.
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }

Другое преимущество шаблона ABS заключается в том, что вы не получаете планшетную активность, содержащую много логики, а это означает, что вы экономите память. Шаблон учебника может привести к очень большой основной деятельности в более сложном приложении; поскольку он должен обрабатывать логику всех фрагментов, которые в него помещаются в любое время.

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

Источник

Я думаю, что вы на правильном пути. (И да, учебники слишком упрощены).

В макете планшета вы можете использовать одну операцию и менять или вставлять фрагменты (в нескольких "панелях"). В макете телефона вы можете использовать новую активность для каждого фрагмента.

Вот так:

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

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

Так что, если у пользователя есть планшет, вы бы использовали MyMultiPaneFragActivity или что-то подобное. Это действие отвечает за управление обратными вызовами от фрагментов и маршрутизацией намерений к правильному фрагменту (например, поисковое намерение)

Если у пользователя есть телефон, вы можете использовать обычную активность с очень небольшим кодом и расширять его. MyBaseSingleFragActivity или что-то подобное. Эти действия могут быть очень простыми, 5-10 строк кода (может быть, даже меньше).

Сложная часть заключается в маршрутизации намерений и еще много чего. *(Изменить: см. Ниже).

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

* Одним из преимуществ регулярной намеренной маршрутизации является то, что вы можете явно запускать Activity из любого места в бэк-стеке. Один пример может быть в случае результатов поиска. (MySearchResults.class).

Прочитайте здесь для получения дополнительной информации:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

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

Источник

Вот ответ Рето Мейера относительно того же самого, взятый из этого видео курса Основы Android Udacity.

Есть ряд причин, по которым вам лучше разбить свое приложение на различные действия.

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

Хорошее практическое правило - создавать новые действия всякий раз, когда меняется контекст. Например, отображение другого типа данных и при переходе от просмотра к вводу данных.

Источник

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

В шаблоне master-detail есть два действия. Один показывает оба фрагмента на больших экранах и только "главный" фрагмент на меньших экранах. Другой показывает фрагмент "детализации" на экранах меньшего размера.

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

Также, что я прочитал о ActionBarSherlock, так это то, что он лучше всего работает с фрагментами, а не с действиями (но я еще не работал с ним).

ActionBarSherlock не имеет ничего общего с фрагментами, чем встроенная панель действий, так как ActionBarSherlock является чисто задним портом встроенной панели действий.

Источник

Ссылаясь на 1-й вопрос "Есть ли причина разделить приложение телефона на множество видов деятельности?" - Да. это просто сводится к доступному пространству, планшет предоставляет больше возможностей для разработчиков, что позволяет разработчикам размещать больше на одном экране. Android сообщает нам, что деятельность может предоставить экран. Итак, то, что вы можете сделать с одним большим экраном на планшете, это то, что, возможно, придется распределить по нескольким экранам телефона, потому что не хватает места для всех фрагментов.

Источник
Другие вопросы по тегам