2014-02-13 4 views
8

В компании Google developer documentation для фрагментов они упоминают следующее:Что не делать в Фрагментах?

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

Звучит очень хорошо. Однако они не затрагивают более подробно, чем:

Всеобложение фрагмента-фрагмента осуществляется через связанную с ним деятельность. Два фрагмента никогда не должны связываться напрямую.

Есть ли какие-либо вещи, которые я должен избегать использовать/звонить/делать в своих Фрагментах?

Я полагаю, что использование Singleton нарушило бы повторное использование, введя внешние зависимости/ожидания?

Можно ли назвать Log.*, SharedPreferences, Toast и AlertDialog из внутри Fragment, или что-то вы должны избегать делать?

Можно ли назвать getActionBar() или было бы глупо предположить, что у хостинга Activity есть ActionBar?

Если Fragment должен выдавать что-то пользователю, будь то ошибка или что-то еще, должен ли он сам решить, как вывести это (Log, Toast, AlertDialog и т. Д.), Или он должен отправить строку в обратный вызов и пусть хостинг-мероприятие решает, как/что он должен делать?

A ListFragment Необходимо заполнить данные, которые необходимо предоставить пользователю. Должен ли он извлекать данные самостоятельно (по сетевому запросу в внутреннем классе AsyncTask) или он должен запросить хостинг Activity для извлечения данных для него?

+0

Это было бы лучше для программистов.se – Daenyth

ответ

1

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

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

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

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

Я бы предложил изучить на примере. Особенно оформляйте образцы из официальной документации на Android.Они должны получить это право :)

EDIT

Просто убедитесь, что вы всегда использовать обратные вызовы при навигации корыта фрагментов. Например, если вы выберете элемент «Список» из фрагмента, и вы хотите увидеть подробности в другом.

Следующий код из официальной документации на http://developer.android.com/training/basics/fragments/index.html

@Override 
public void onAttach(Activity activity) { 
    super.onAttach(activity); 

    // This makes sure that the container activity has implemented 
    // the callback interface. If not, it throws an exception. 
    try { 
     mCallback = (OnHeadlineSelectedListener) activity; 
    } catch (ClassCastException e) { 
     throw new ClassCastException(activity.toString() 
       + " must implement OnHeadlineSelectedListener"); 
    } 
} 

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

+1

Обратный вызов является только элегантным и простым в обслуживании - если ваша деятельность управляет несколькими различными типами фрагментов, то она начинает становиться запахом кода - см. Здесь: http: //stackoverflow.com/questions/21418614/do-fragments-cause-fat-activities –

+0

@John J Smith - Вы правы. У меня тоже была эта проблема, и я просто немного разделил свой код и создал менеджера, который немного походил на тот, который указан в вашей ссылке. Спасибо за добавление. Это что-то очень полезное, и я рассмотрю его больше. – Bandreid

Смежные вопросы