Develop Reference

Can a use case be called in data layer in context of Clean Architecture?

I have read a couple articles about clean architecture concepts here and here and others.
I think I understand what is going on but they didn't solve the question that I have.
I wonder if a use case can be called from data layer. if so, how? if not why?
UPDATE:
what I am trying to do is to track what is happening during each usecase with a event usecase. Sometimes, I need to collect those info in data layer as well.
Let's say I have
CollectEventUseCase
for that event usecase. I want to track if a person data lookup from network was fail but successful from database during the LookupPersonUsecase and I want to collect that information that lookup was failed from network but successful from database, is this a bad idea to call CollectEventUseCase in data layer? is this okay solution to this case? or whatelse should be the right approach?

Short Answer - No, in a CLEAN architecture the data layer should not be calling through to a use case as it would be breaking the separation of concerns. Data layer should only be concerned with data, not business logic which lives in a use case.
Long Answer
One main reason for implementing a CLEAN architecture is for implementing separation of concerns, meaning each layer addresses a specific concern in your app. Expanding on the photo in domain layer Android documentation, an app architecture might look like the picture below.
Where the domain layer would contain all of the business logic for presentation and use cases which can communicate with different sources in the data layer.
The data layer exists to serve as an abstraction over where data is coming from and that should be its only responsibility. Most apps data layers are fetching data from the network and then caching that data in a local database. So to best separate the concerns, a use case should only be concerned about interacting with different sources from the data layer and any business logic.

ANDROID MVP Interactor vs MVVM Repository

I understand MVVM has View - Viemodel -> Repository flow in which repository is in charge of taking care of api calls, database calls...
On the other hand in MVP we have View - Presenter - Interactor.
From my opinion Interactor in MVP is very similar to repository in MVVM. They both do network and database calls with service and they send the results to Viewmodel/Presenter.
I would like to know a little bit more about this Interactor - Repository correlation.
Is it true that if we have Interactor in MVP architecture, we don't need Repository class since the network layer is already separated in Interactor class?
Also can we say that Interactor in MVP is almost the same thing as repository in MVVM?
What are their differencies?

The Interactor represents a logical use case. The interactor is more like bridging the gap between the View layer (by communicating with the presenter) on one hand, and the implementation environment, or repositories, on the other. The interactor is used to have a clear picture of the use cases you want to develop in your application.
Repositories, as you mentioned provides us with clean API to access the data layer and pass on the data to the domain layer(interactor/use cases).
Is it true that if we have Interactor in MVP architecture, we don't need Repository class since the network layer is already separated in Interactor class?
Answer-- No Because we want to avoid objects that deals with both presentation logic and dataflow logic. We also want the dataflow logic to be reusable across different ViewModels. Thus its better not to call the repository directly from the ViewModel/Presenter and have an additional interactor/usecase to handle that.
For reference - https://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576

Clean Architecture and authentication. Correct way?

I'm working on an Android app based on Clean Architecture pattern and I have doubts how to implement user authentication in a clean way. Is the following solution clean in terms of clean architecture?
I would create use cases like below (executed from presentation layer):
LoginUseCase (for provided login and password fetches api token via remote service and saves in local token source)
LogoutUseCase (clears token from LocalTokenSource)
(LocalTokenSource interface would be stored in domain layer and its implementation in data layer - kind of repository)
And in order to perform token refresh at each app launch (it's not a use case from the user perspective, right?) I would create SessionManager component in domain layer. SessionManager would be responsible for refreshing token and saving it in LocalTokenSource. Each time activity is started, from its presenter I would execute refreshToken() on injected SessionManager. What do you think about the solution?
If it's clean, then how to handle passing token to the remote service to execute other API methods which require token? Lets say I have PostsRepository which fetches posts data from remote service. Should I pass token from a use case to the repository method like repo.getPosts(token)? Or inject LocalTokenSource to the repository, so it could read the token on its own? Wouldn't the second option violate Clean Architecture rules, because LocalTokenSource would be used in 2 layers?

The central question you would have to decide is: Do you want to model authorization (and so the usage of the token) as an aspect of your business logic OR do you want to consider it as an "implementation detail".
If you decide for the first, having dedicated use cases for it, adding the SessionManager to the domain layer and passing the token to the repositories would be a consistent modeling.
If you decide for the later, login/logout/refresh as well as the existence of the token is probably best kept "behind the scenes", so in the framework or gateway layer.
Both approaches would follow the rules of the Clean Architecture (as long as you do not violate the dependency rule).

Structure classes in Android project with Retrofit2 and MVP

I have difficulties knowing how to structure the classes in an MVP Android project that uses retrofit2 for calls to the API. I need to make a login and a registration. The requests for both of these are different but the response is the same. How can I create&structure the model classes in the best way?

As the matter of fact in MVP design pattern, there is a View(mostly a fragment), a presenter (has a duty to do logical things) and we have no an actual model there!
instead, there is a data part of your application that contains your database and internet connection that we can call it model.
I searched all the internet but I found the best example in below link:
https://github.com/googlesamples/android-architecture/tree/todo-mvp/

Client Architecture - Data Layer, MV* and coupling

I've been researching best practices for client architectures for a while now, including mvvm and the latest additions such as flux...
I'm considering the architecture for an android app, which will probably use a combination of mvvm and mvp for presentational purposes.
The thing that troubles me is coupling between components (mv* related classes),
for example:
I have a SlimStockItem model used in StockListView, which enables navigation to a StockItem used in a StockItemView, StockItem has more data.
I could use the same StockItem with null values for both views - this would introduce coupling between the controllers and views of the list and item details components or using a different approach which results in a couple of implementation choices:
Have a "domain" entity called Stock which has all the data and construct the relevant StockItem from it's "repository"
Don't implement a domain layer at all and query the server for StockItem (implement caching if appropriate at a technical layer)
Keep the coupling and pass StockItem to the stock item view.
The second scenario is receiving an update (push/pull) for a Stock from the server.
(Flux) Events are really good as a pub/sub implementation to inform multiple view of new state changes originating from user interactions/server push/pull interactions.
When considering the implementation, I have couple of choices:
1. Update the "domain" layer and publish a downstream event "StockUpdated" with the "domain" model Stock as payload for the mv* components to update SlimStockItem and StockItem.
2. Don't implement a domain layer at all and publish an event "StockUpdated" with a StockDataPayload for the mv* components to update SlimStockItem and StockItem.
Which approach do you use and what are the potential tradeoffs? (If you use a different approach then please describe it!)
P.S i'm quoting "domain" model, because the actual domain model resides at the server and is out of scope when discussing client architecture.
Best regards,
Erik.