Юрий321если бы понял, я бы и не спрашивал :)
ну так я и объяснил. фрагмент это не только гуй, это еще логика + lifecycle. для того чтобы покрыть вышеописанный сценарий с master-details нам нужно 2 фрагмента, в них логика списка и детали причем в каждом своя, т.е. списку не надо всей той байды, что нужна в детали и наоборот. после этого мы делаем
1.
2.
3.
4.
5.
раз) layout ->
<fragment list/>
два) layout-land ->
<fragment list/>
<fragment detail/>
и вот у нас уже на разную ориентацию есть два разных поведения без единой строчки кода. при этом ни лист ни вьюха, ни тем более активность в которой они живут не заморачиваются видимостями, переключениями между вьюхами, ориентациями и прочим. а если у нас еще где-то есть другая активность, но в ней нужно точно ту же detail показать (ну например мы редактируем элемент и нам нужно preview перед сохранением) - то вообще профит.
Юрий321chpasha а потом я попрошу тебя ту же самую деталь с ее логикой отобразить еще в одном месте приложения.
include, нет?это ты только разметку всунешь, а ведь там еще байндинг данных, валидация какая-то возможно, вызов диалогов/активностей и обработка результатов. чтоб было понятней, для реализации подобного без фрагмента тебе нужен компонент - т.е. класс с некоей логикой подгружающий еще по ходу дела гуй. а include он полезен, но он чисто для комбинирования кусочков интерфейса. без логики. на это весь упор - фрагмент это маленький, но полностью автономный кубик конструктора, который будет одинаково функционировать в любом месте приложения.
