Фрагменты кажутся излишними? Возможна ли архитектура MVC?

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

Например: У меня есть диалоговое окно как пользовательский ввод, после нажатия кнопки. Таким образом, я передал нажатие кнопки через прослушиватель от фрагмента к активности, а в действии я открыл диалог. В диалоге я запустил новые функции (так что реализация в Activity). Android dev дает подсказку добавить диалог предупреждения в фрагмент:

http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/FragmentAlertDialog.html

Но этот фрагмент все еще реализован и тяжел в сочетании с активностью (действие кнопки диалога находится в активности).

Таким образом, модель и вид сильно перепутаны. Я не вижу дополнительного значения в таком сложном состоянии, статический код?!

Каково ваше мнение и советы о фрагментах?

Ответ 1

При использовании Fragments вы можете думать о них как о View и Activity как о Controller. По моему личному мнению, Фрагменты были реакцией коленного сустава Google на поддержку таблеток, и теперь мы застряли с ними: (

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

Вот некоторые из ловушек, с которыми я столкнулся...

  • Не используйте onclick в макете фрагмента, так как это будут теги Activity и NOT Fragment, которые будут обрабатывать щелчок. Если вы используете этот атрибут, а позже вы используете фрагмент в другом Activity, вам придется не забывать добавлять метод onclick к этому Activity. Итак, используйте findViewById, а затем вручную присоедините обработчик кликов в фрагменте onCreateView.

  • При общении с другими фрагментами используйте Activity в качестве контроллера для направления сообщения. (Множество примеров того, как это происходит с использованием интерфейсов). Ключ здесь состоит в том, что если вы используете несколько фрагментов на устройстве, где один фрагмент будет напрямую связываться с другим фрагментом, тогда вы столкнетесь с каким-то странным, но предсказуемым поведением. Например, если Fragment A напрямую обновил представление в фрагменте B, но фрагмент B не был виден (потому что вы его заменили - рассмотрите телефон), а затем, когда отображается фрагмент B, View может не обновляться, поскольку View воссоздается. Итак, если вы обновите Fragment, обязательно обновите данные в фрагменте, затем обновите фрагменты View в onCreateView, который вызывается, когда фрагмент снова становится видимым (т.е. Вы выскочили текущий фрагмент, вы теперь показываете предыдущий)

  • Не создавайте полное приложение, используя только фрагменты. Вместо этого создавайте такие приложения, как вы, обычно, используя "Действия", а затем относитесь к Fragment с прославленным представлением (каким оно является). т.е. создать приложение таким образом, чтобы у вас было несколько фрагментов и несколько действий, а некоторые действия могут использовать более одного фрагмента.

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

Нижняя строка заключается в том, что Фрагменты великолепны, если вы используете их как View, но если вы начнете пытаться использовать их как Activities, то вы столкнетесь с проблемами:( Подумайте о ActiviyFragment как бытие ControllerView.

Я также рекомендую вам читать и понимать жизненный цикл фрагмента в дополнение к жизненному циклу активности (у Pro Android 4 есть отличная фотография для его представления), и вы сэкономите время на боль:)

Ответ 2

Фрагменты обеспечивают логику представления, поэтому они переносимы для других видов деятельности. По большей части действия больше переходят в роль истинного контроллера. В предыдущих архитектурах Android логика представления и логика контроллера были объединены друг с другом, потому что никто не подклассифицировал View для реализации большинства своих приложений. Они по сути делали компоновку в файлах макета XML, а затем вытаскивали объекты View непосредственно в Activity. Таким образом, это означало, что Activity регистрировала прослушиватели кликов, прослушиватели клавиш, логику перетаскивания и т.д., Что обычно является тем, что вы делали бы в другом подклассе View в других наборах инструментов. Поскольку они сделали это, это означало, что действительно крутой перетаскивание жестов Multi-Touch ListView, который вы только что закодировали, застрял в этом одном Управлении. Теперь вы хотите использовать это снова в другом действии. Ну, ты С.О.Л. С помощью фрагментов вы можете легко перемещать эту логику из Activity в фрагмент. Теперь технически вы можете перенести его в пользовательский компонентный вид, но Fragments предоставляют еще одно преимущество, которое позволяет Fragments писать приложения, которые могут работать на планшетах и ​​небольших устройствах, изменяя макет для каждого. Трудно понять, как это работает, но одно действие может содержать несколько фрагментов с разной компоновкой для каждого форм-фактора. То, что пользовательский компонент не может выполнить почти так же легко. Плюс пользовательские компоненты не могут использовать файлы макета. Вам нужно пройти полный Java-код, чтобы вы не отказались от фрагментов.

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

Ответ 3

Хорошо, я запустил его с mv-архитектурой...

    public AlertDialog openLocInput() {

    AlertDialog.Builder alert = new AlertDialog.Builder(getActivity());
    alert.setTitle("Login");
    alert.setMessage("Enter Pin :");

    // Set an EditText view to get user input
    final EditText input = new EditText(getActivity());
    alert.setView(input);

    alert.setPositiveButton("Ok", new DialogInterface.OnClickListener() {
        public void onClick(DialogInterface dialog, int whichButton) {
            jsonHandler.obtainMessage(1, input.getText().toString())
                    .sendToTarget();
            dialog.dismiss();
            return;
        }
    });

    alert.setNegativeButton("Cancel",
            new DialogInterface.OnClickListener() {

                public void onClick(DialogInterface dialog, int which) {
                    dialog.dismiss();
                    return;
                }
            });
    return alert.create();
}

реализованный во Фрагменте... запуск этого alertdialog из фрагмента:

        fragment_userlocation_btn_addLocation.setOnClickListener(new OnClickListener() {

        public void onClick(View v) {
            openLocInput().setOwnerActivity(getActivity());
            openLocInput().show();
        }
    });

также реализована в фрагментах.

Но я все еще верю в теорию о переполнении...

Я думаю, что 5% моего пользовательского интерфейса будут повторно использованы, поэтому рекомендуется смешивать действия, загружая фрагменты и действия, включая логику ui без фрагментов?

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