Скільки заходів проти фрагментів?

Вступ:

Основний шаблон "Підручник з фрагментами" виглядає приблизно так:

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

(наприклад, API API API 3.0 для Dianne Hackborn та посібник з API Fragments )

На обох пристроях функціональність знаходиться в Fragments. (просто)

На планшеті весь додаток - 1Activity , по телефону - багатоActivities .

Запитання:

• Чи є причина розділити додаток для телефону на багато Activities?

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

• Чи не було б простіше зберегти модель 1-ї діяльності в обох випадках, використовуючи однакову логіку вмикання Fragmentsта виходу (просто використовуючи інший макет)?

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

Крім того, що я читав про те ActionBarSherlock, що це, здається, найкраще працює Fragmentsзамість цього Activities(але я з ним ще не працював).

Чи підручники надто спрощені, чи я пропустив щось важливе в цьому підході?

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

Деякі посилання на пов'язані питання:

• Дилема: коли використовувати фрагменти та види діяльності:
• Шаблони, коли використовувати перехід активності проти динамічних фрагментів
• Android - мені потрібні роз'яснення фрагментів щодо діяльності та поглядів
• Діяльність чи фрагменти в Android?
• Кілька фрагментів та дизайн взаємодії діяльності
• Отже, які точні переваги фрагментів в Android 3.0?

Оновлення

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

Також знайшла цікаву статтю хлопців на Площі, яку варто прочитати:

• Захист проти фрагментів Android

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

Я також погоджуюся, що недобре дублювати логіку програми у багатьох видах діяльності (див. Принцип DRY на wikipedia ).

Я віддаю перевагу шаблону, який використовується програмою ActionBarSherlockFragments Demo ( завантажити тут та вихідний код тут ). Демонстраційна версія, яка найбільш точно відповідає навчальному посібнику, згаданому у питанні, - це те, що в додатку називається "Макет"; або 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 є те, що ви не закінчуєтесь діями планшетного ПК, що містять багато логіки, і це означає, що ви економите пам'ять. Шаблон підручника може призвести до дуже великої основної діяльності у складнішій програмі; оскільки йому потрібно обробляти логіку всіх фрагментів, які розміщуються в ній в будь-який час.

Загалом, не думайте про це як про змушення використовувати багато заходів. Подумайте про це як про можливість розділити свій код на багато фрагментів і зберегти пам'ять при їх використанні.

Я думаю, ти на правильному шляху. (І так, підручники надто спрощені).

У макеті планшетного ПК ви можете використовувати одну Активність та поміняти фрагменти та вимкнути їх (на декількох панелях). Перебуваючи в розкладці телефону, ви можете використовувати нову активність для кожного фрагмента.

Так:

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

Щоб зменшити код, ви можете використовувати a BaseActivityі розширити його.

Тож якщо у користувача є планшет, ви б використовували MyMultiPaneFragActivityщось подібне. Ця діяльність відповідає за керування зворотними викликами з фрагментів та намірами маршрутизації до правильного фрагмента (наприклад, пошукового наміру)

Якщо у користувача є телефон, ви можете використовувати звичайну Активність з дуже невеликим кодом і розширити її MyBaseSingleFragActivityчи щось подібне. Ці дії можуть бути дуже простими, 5-10 рядків коду (можливо, навіть менше).

Хитра частина - маршрутизація намірів і чогось іншого. * (Редагувати: див. Докладніше нижче).

Я думаю, що причиною цього рекомендованого способу є збереження пам’яті та зменшення складності та зв’язки. Якщо ви заміняєте фрагменти, FragmentManagerутримує посилання на цей фрагмент для бек-стека. Це також спрощує те, що має бути "запущеним" для користувача. Ця установка також роз'єднує погляди, компонування та логіку у фрагменті з життєвого циклу діяльності. Таким чином, Фрагмент може існувати в одній активності, поряд з іншим фрагментом (двопанельним), або в трехпанельній діяльності тощо.

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

Прочитайте тут докладніше:

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

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

Ось відповідь Рето Мейєра щодо того ж, взятого з цього відео з курсу курсу Udacity Android Fundamentals .

З кількох причин вам краще розбити додаток на різні види діяльності.

• Наявність єдиної монолітної діяльності збільшує складність вашого коду, ускладнює його читання, тестування та обслуговування.
• Створює та керує фільтрами намірів набагато важче.
• Збільшує ризик щільно з'єднати незалежні компоненти.
• Значно більша ймовірність введення ризиків для безпеки, якщо одна діяльність включає як конфіденційну інформацію, так і інформацію, безпечною для обміну.

Хорошим правилом є створення нової діяльності кожного разу, коли контекст змінюється. Наприклад, відображення даних іншого типу та перехід від перегляду до введення даних.

Одна з проблем цього методу полягає в тому, що ви повторюєте багато логіки в основній діяльності планшетного ПК та в окремих телефонах.

У шаблоні деталізації майстра є дві дії. Один показує обидва фрагменти на більших екранах, а лише "головний" фрагмент на менших екранах. Інший показує фрагмент «деталей» на менших екранах.

Ваша логіка деталей повинна бути пов'язана з фрагментом деталі. Отже, не існує дублювання коду, пов'язаного з логікою деталей між видами діяльності - активність деталізації просто відображає фрагмент деталі, можливо, передаючи дані із Intentзайвих.

Крім того, що я читав про ActionBarSherlock, це те, що він, здається, найкраще працює з фрагментами замість діяльності (але я ще не працював з ним).

ActionBarSherlock не має більше нічого спільного з фрагментами, ніж рідна панель дій, оскільки ActionBarSherlock - це суто опор на рідній панелі дій.

Посилаючись на перше запитання "Чи є причина розділити додаток телефону на багато заходів?" - Так. він просто зводиться до наявного місця, планшет дає більше місця для розробників, тим самим дозволяє розробникам розміщувати більше на одному екрані. Android говорить нам, що Діяльність може забезпечити екран . Тож те, що ви можете зробити з 1 великим екраном планшета, - це те, що, можливо, доведеться рознести по декількох екранах телефону, оскільки не вистачає місця для всіх фрагментів.