Одна Activity и множество Fragment, best practices?

Question

[robert_n]

Здравствуйте! Посоветуйте пожалуйста хорошее решение для построения правильной архитектуры приложения с использованием одной activity и множества фрагментов. Сейчас у меня есть приложение с 20 экранами. Каждый экран реализован с помощью фрагмента. Все фрагменты находятся в одной активити. К сожалению, код в этой activity стало трудно поддерживать, т.к. количество строк уже превышает 4000. В основном код отвечает за работу с фрагментами, UI, работу с простыми данными. Я прекрасно понимаю что такого быть не должно, но пока не представляю как это можно все декомпозировать.

Подскажите best practices в решении данного вопроса.

Comments

[automatik]

best practices нет. Но нужно знать, что много фрагментов -- это тоже плохо, как и много активити.

[robert_n]

automatik: и все же, как например, поступаете вы?

[automatik]

robert_n: интуитивно. В процессе проектирования на бумаге схематически разделяю приложения на активити, а активити на фрагменты.

[Сергей Семенко]

Это в одной Acitivity, которая по сути является контейнером, столько строк? Лично я выношу повторяющиеся методы в отдельные классы, наследуемые от Fragment, а потом реальные фрагменты наследую от них, обычно получается не более 3-х уровней наследования. Если честно, даже не знаю что ещё можно сделать.

[robert_n]

automatik: т.е. ваше предложение часть функционала одной активити вынести в другие активити?

[robert_n]

Сергей Семенко: да у меня activity по сути контейнер. Сейчас вот читаю https://habrahabr.ru/post/276189/ . И у меня как раз activity получается God object. Видимо надо лучше разобраться с MVP. Что касается фрагментов, адаптеров я тоже создаю родительские классы с одинаковыми методами. Но вот что сделать с активити?

Answer 1

[Алексей Ершов]

Я бы на вашем месте отказался от архитектуры "Одно Activity на всё приложение", и сделал всё на обычных Activity.
Проблема у вас, судя по всему, в разбиении функций приложения на слабо связанные модули. Разрисуйте и распишите ваши экраны и функции, которые принадлежат каждому из них, и подумайте, какие из функций зависят друг от друга, а какие нет.
Почитайте про принципы SOLID, которые помогут понять, как лучше разделять ответственность классов между друг другом: https://realm.io/news/donn-felker-solid-part-1/
Отделите бизнес-логику от UI-логики и логики хранения данных с помощью архитектуры Clean: fernandocejas.com/2014/09/03/architecting-android-...
Организуйте связь UI и бизнес-логики с помощью подхода MVP, где Model - это UseCases (они же Interactors) из Clean: antonioleiva.com/mvp-android
Попробуйте Moxy (https://github.com/Arello-Mobile/Moxy) в качестве библиотеки для реализации MVP, она избавит вас от написания большого количества boilerplate-кода и части проблем с переворотом экрана.

Answer 2

[z0rgoyok]

Странно, у меня в активити практически ничего кроме метода pushFragment(BaseFragment fragment).
Все фрагменты наследуются от BaseFragment, в котором есть метод getMainActivity.

И можно делать так из любого фрагмента getMainActivity().pushFragment(SomeFragment.newInstance())

Подход в целом как в iOS (почитайте про uinavigationcontroller)

Answer 3

[Вадим Ракша]

Для каждого фрагмента создать свой клас.
И можешь использовать строение архитектуры - MVC (Model-View-Controller)
https://ru.m.wikipedia.org/wiki/Model-View-Controller

Comments

[robert_n]

У каждого фрагмента у меня есть свой класс. Если часть методов у некоторых фрагментов повторяется, то я их выношу в отдельный класс, послу чего другие фрагменты от него наследуются. Это я понимаю как сделать, но вот как вынести часть функционала из активити пока не пойму. Сейчас вот читаю эту статью https://habrahabr.ru/post/276189/ и видимо надо лучше разобраться в архитектуре MVP. Как вы относитесь к предложенному в статье решению проблемы?

[Вадим Ракша]

robert_n:
Я пару месяцев назад читал эту статью. В принципе подход мне нравиться, и я пробую все это на своих проэктах. Но пока что у меня ни один поход не прижился из-за моей дурацкой привычки оформления кода))

Answer 4

[mitaichik]

Ого!! 4000 строк - тут явно что то не то. Вам срочно нужно разбивать. Логика UI должна быть во фрагментах, классах вьюх, адаптерах и пр.. В хостовой активити у вас должна быть логика смены фрагментов (хотя тут можно тоже выделить отдельные классы). Бизнес логику выделяйте в отдельный слой. 4000 строк - это ужас!