Как фрагменты влияют на деятельность "единая, целенаправленная вещь, которую пользователь может делать"?

В документации на Android говорится: "Активность - это единственная, целенаправленная вещь, которую пользователь может сделать".

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

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

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

Должен ли я иметь одно действие для управления всеми фрагментами приложения и транзакциями фрагментов? Как и Ретро Мейер, предположим выше. Это рекомендуемый путь? Таким образом, разрыв с принципом "единого, целенаправленного, что пользователь может сделать" для деятельности?

Или я что-то упускаю? Надеюсь;)

Кстати, я думаю, что Фрагменты выглядят великолепно, но из того, что я видел до сих пор, только если вы создаете приложение с нуля. Поскольку приложения, совместимые с телефоном и планшетами, выглядят немного утомительно. Надеюсь, что ошибаюсь:)


Диана Хакборн уже ответила (спасибо для ссылки mgv):

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

Итак, Activity становится своего рода контейнером, где вы сможете подключать Fragments. Мне нравится этот подход, но... в моем приложении доступно около 30 различных операций, каждый из которых требует от 2 до 4 экранов, которые должны выполняться (формы и списки выбора), все они отличаются и существуют ограничения на навигацию. Он отлично работает с действиями, каждый из которых управляет одним действием на экране/шаге.

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

Текущее определение активности должно немного изменить бит.:)

Ответ 1

Должен ли я иметь одно действие для управления всеми фрагментами приложения и транзакциями фрагментов?

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

Таким образом, нарушая принцип "единственного, сфокусированного, что пользователь может делать" для деятельности?

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

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

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

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

Или я что-то не хватает?

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