Фрагменты кажутся излишними? Возможна ли архитектура 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, то вы столкнетесь с проблемами:( Подумайте о Activiy
→ Fragment
как бытие Controller
→ View
.
Я также рекомендую вам читать и понимать жизненный цикл фрагмента в дополнение к жизненному циклу активности (у 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 без фрагментов?
Я думаю, что реальное преимущество Фрагментов - оптимизация планшета, но использование таблеток по сравнению с использованием мобильных устройств в настоящее время очень мало. В дополнение к тому, что планшеты не являются "мобильными", а затем мобильными устройствами, и не находятся в фокусе для развития контекстно-зависимых...