Какая архитектура должна быть у простого апп для показа данных, полученных из json?

Question

[Антон Покачалов]

Здравствуйте!
Как-то давно я делал простое приложение под Android для запроса json данных с сервера, отображение списка на первом экране.
Если кликнуть на элемент, отобразится детальная информация по этому элементу.
Посмотреть можно тут.

Сейчас я очень хочу продолжить изучение андроид и реализовать ее "правильно". Сделать правильную архитектуру(MVP? MVI?, MVVM? LifeData), использовать оптимальные библиотечки(Dagger? для внедрения зависимостей, RxJava? вместо AsyncTask, возможно какое-то кеширование, чтобы каждый раз не запрашивать, если данные не изменились(где, кстати, его хранить, в памяти weakreference или в бд?) Возможно, вместо двух "активити" следует использовать два "фрагмента" или один? По clean architecture с разными слоями, читал и на русском и на английском статьи, но понимание только очень общее.

Может ли кто дать совет, как сделать правильную архитектуру такого приложения? Возможно кто делал подобное?
Я был бы очень рад получить советы, какие проблемы у моего апп и как их лучше решать, как они сейчас решаются в реальном мире.

Буду так же рад ссылке на материал/книгу, где все это вместе разбирается, особенно про архитектуру.

Я представляю себе (скорее всего примерно), зачем и как каждый из компонентов андроид нужен и даже использовал их для разных задач в моих приложениях (hi to stack overflow driven development), но не очень понятно, какое же решение будет оптимальным, какое будет устойчивым, легко изменяемым. Для этого хочу сделать рефакторинг, своих приложений, начиная с самого простого.

Answer 1

[Евгений Ромашкан]

По сути функционала там - Gateway к апишке и Presenter какой-нибудь. Это можно явно и выразить. Среди кучи кучи хуков(protected onSomethingHappened()) и статических вызовов Utils сложновато проследить поток выполнения. (Utils выпилить).

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

Comments

[Антон Покачалов]

Спасибо за ответ!
Только я не нашел у себя в коде каких-то лишних onSomethingHappened(), все что есть, относится к жизненному циклу activity, adapter и asynctask-у, может что-то пропустил?
Про нейминги тоже не понял, старался придерживаться единому стилю, то есть show.., get.., set...,

[Евгений Ромашкан]

Антон Покачалов, По идее Activity это ближе уже к представлению/инфраструктуре. Всё что к ним не относится напрямую или может реюзаться стоит стараться выносить отдельно. То есть в одном месте обращаемся к гейтвею за данными, отдаём их в представление(Activity), там уже юзер что-то делает. Но это ближе к MVP/MVA, говорить что это лучше чем какой-нибудь MVVM не возьмусь никак.
Про нейминги - сначала показалось что вы camel case и snake смешиваете. Сейчас пересмотрел и это вроде только обращения к R, тогда не буду заострять внимание.
Хотелось бы концептуальных изменение вроде выпиливания "jsonRawData", потому что с сырым json должен только гейтвей работать.
P.s get/set не очень нейминг, но то такое.

Answer 2

[Богдан Столяров]

По архитектуре посоветовал бы посмотреть сюда https://telegra.ph/Android-Architecture-06-02
Любая архитектура нужна для того, чтобы упрощать, если у вас 2 экрана без намеков на расширение - то я не уверен, что там нужна какая-то архитектура, а если вы хотите просто "попробовать" как имплементить каждую из них, то лучше на 2х артихектурах и сделать (в разных ветках например) и "почувствовать разницу", как говориться :)