Ага, читал, и в первую очередь "Advocating Against Android Fragments", когда архитектуру для проекта разрабатывал. Сейчас просканировал, и до сих пор суть сводится к одному "фргаменты плохо, давайте выдели вью, которое будет только показывать, а логика отдельно" Вот только, считаю, это не инструментальный вопрос, а архитектурный - отделение бизнес-логики от представления 😉 В таком случае вообще не важно, что там будет - фрагмент, вью, активити или что-то еще. Но вот зависимость от сторонних либ лучше сводить к минимуму. Поэтому решил остановиться на фрагментах, но отвести им минимальную роль, не требующую тестирования. И все прекрасно, и даже лучше: я на паузе отделяю экземпляр с логикой, а на резюме прикрепляю. Таким образом один и тот же кусок бизнес-логики у меня легко путешествует между фрагментами и активити без лишних уничтожений-созданий-инициализаций. И когда дошли до выделения бизнес-логики в отдельный поток, то решилось это на раз ) В этом отношении примеры в документации андроида выполняют медвежую услугу - они не применимы в жизни для проектов сложнее будильника/компаса/калькулятора. Это именно примеры, а начинающие android-кодеры воспринимают их как best practice (что было и со мной когда-то =)
Обсуждают сегодня