Where should backend API be called - in use case or in repository?

Question

We are doing architecture for our new android application that requires offline mode also and have a dilemma about one detail.

General recommended architecture is shown in this picture:

Now, this makes pressure on repository doing 2 things: communication with API and SQLite which can easily get very complicated + harder to test. At the same time, we have Use Case in between ViewModel and Repository to orchestrate jobs done across multiple things: services, multiple repositories, etc...

The question is:

Should backend API be called from Repository or maybe better to do it in Use Case? And why?

Answer 1

IMO neither. Generally I prefer this kind of architecture layering:

• RemoteSource - Communicates with your networking or bluetooth API. It essentially wraps the retrofit interfaces, and does mapping & thread switching to IO
• LocalSource - Communicates with your DB api (Room, SqlDelight). Also mapping & thread switching
• Repository - Handles the logistics, whether something should be fetched, cached, etc...
• UseCase - Combines multiple type of entity operations between repositories

So TL;DR: you can create a RemoteSource abstraction over your Retrofit interfaces