Clean architecture
DOMAIN - слой
- содержит всю бизнес логику приложения
- ни от чего не зависит
- работает с интерфейсом репозитория
- не должен знать как происходит обработка данных
DATA слой
ViewModel занимается взаимодействием с DOMAIN
MVVM
View - содержат
- экраны
- activity
- адаптеры
Подписываются на изменения LiveData, но не должны изменять его
Model - работает с данными.
- не знает откуда приходят данные
- не знает кто данные запросил
- задача - получить запрос, отправить на сервер, получить ответ и отправить результат.
- содержит repository (в том числе и shared pref)
USECASE
Небольшая функция, которая выполняет конкретную вещь.
Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.
Use Case - каждое действие бизнес-логики, которое может быть вызвано пользователем.
Если тебе есть что описать для этого действия, задачу, то - да. А так, зачем делать класс, который ничего не будет делать? UseCase - это действие, и на действие надо прописывать реакцию.
если говорить просто, то в MVC и MVVM всё что внутри квадратов - не юзкейсы всё что "стрелочки" между квадратами - юзкейсы UI это view, клик не юзкейс преференсы это модель, из вью к модели по юзкейсу это если уж очень упрощенно
я так понял что useCase будет в том случае если какието данные проходят из presentation в data. В случае с переходом между экранами параметры передаются для нового экрана чтобы определить чтото что этот экран должен показать. Если эти данные будут связаны с presentation слоем, то в этом же слое они и останутся, к примеру если вам надо чтобы при открытия нового экрана какойто элемент в нем был видимым, а какойто другой невидимым. Если же там передаются какието бизнес данные, которые, к примеру, надо записать в базу данных или которые влияют на логику работы приложения/изменяют чтото, то тогда уже они пойдут в useCase и дальше. Конкретно в случае с sharedPrefs не знаю, возможно стоит также все это протащить через useCase до data слоя. На мое мнение не опирайтесь, я учусь)
Usecases usually relates to data layer . all the cases you have added they have only UI stuff except the preference part . this all can be in UI layer no usecase needed IMO . How r you loading the data to show on RecyclerView can be one Usecase but its not in your question . – Like fetching data from a network or reading data from database, preferences, etc can be referred to as use cases. Usecases are the business logic executors that fetch data from data source either remote or local and gives it back to the requester in our case it would be the app layer.