Comments 8
Даже если вы добавляете фрагмент через replace, то это не значит, что он полностью заменяется.
Это не совсем верно. Если заменяемый фрагмент был предварительно положен в бэкстэк — да, произойдет все как вы описали. Если же заменяемый фрагмент не лежит в бекстеке и нигде более во фрагмент менеджере не содержится ссылок на этот фрагмент — он благополучно удалится.
А чем, позвольте, вам не угодил ViewPager?
Да, вы правы про фрагмент. Ситуация именно про поведение с добавлением в бекстэк
А насчет ViewPager по следующим причинам:
1) RecycleView гибче — можно экспериментировать со свободным или постраничным скроллом, с вертикальной лентой или горизонтальной, с элементами, которые наезжают друг на друга контролами; экспериментировать с анимациями и расположением элементов.
2) Иерархия вью в этих элементах очень сложная и хочется все это переиспользовать, настраивать пул для разных типов элементов, также можно прогревать RecycledPool еще до начала использования самой ленты
3) Из-за наших особенностей хранения данных и структуры этих данных мы хотим очищать списки при уходе в глубину — с ViewPager с такой логикой возникает куча проблем, так как у него фрагменты жестко привязаны к элементам списка и логика восстановления фрагментов очень неочевидная и размазанная между нашей бизнес-логикой хранения данных, методами жизненного цикла и состояниями FragmentManager. Например у ViewPager после onDestroyView могут приходить запросы на создание фрагментов.
4) Ну и просто лишний слой в виде фрагментов и их жизненного цикла нам показался лишним и без каких-либо преимуществ использования перед RecycleView
RecyclerView больше для реализации view-логики на ячейку\холдер. И сам по себе предполагает, что контент будет структурно повторяться, для чего и (в дефолтных вариантах) кеширует вьюхи.
View Pager же- именно страничный механизм и предполагает реализацию подобия presentation-логики на страницу. В основном тяжелой логики или хранения в памяти большого количества данных на страницу. FragmentStatePagerAdapter позволяет осуществлять, по факту, менеджмент памяти из коробки благодаря ЖЦ фрагментов. В некоторых случаях можно вообще взять базовый адаптер и реализовывать прямо на вьюхах (без фрагментов) и брать менеджмент на себя.
Да, я понимаю, что бизнес-требования не всегда просты и не всегда адекватны. И что, иногда, проще «отверткой отковырять гвоздь». Но я бы поостерегся называть ViewPager неэффективными и сложным- он не сложнее ListView и много проще RecyclerView.
Поймите правильно, в Вашей статье много полезного. Но не все решения стоит рекомендовать на повседневное использование.
Если вы знаете красивое решение, то напишите в комментариях.Взять ViewModel из Android Architecture Components, использовать в качестве презентера, и bind производить на старте, а unbind в onCleared? Если честно, не пробовал конкретно с bindService, но первое, что приходит в голову- сделать презентер независимым от поворота и коммуникацию с сервисом производить именно там. В итоге чище и более предсказуемо.
Можно еще через moxy это реализовать, но, на мой взгляд, AAC гибче и стабильнее
Нестыдные вопросы про жизненный цикл