Architecture for a Custom View library Android

Question

I am building a library that every 30 seconds displays a question (obtained from a REST Api) and allows the user to select one of the possible answers.

Also, I need to make use of that library in an app, displaying a video underneath the question.

Desired result

All the business and UI logic should be handled in the library.

Does it make sense to use an MVVM approach, with repository pattern in the library? With this package structure?

Possible package structure

Answer 1

You're creating the library, which is totally different context and way of creating the codebase comparing to the app.

First of all you need to make decisions about the dependencies. Of course it is super easy to put retrofit, mvvm and other dependencies into the app and manage them further.

With library it's not that easy. What I would expect from library in the first place is to have as little dependencies as possible. If you're going to provide aar file, then the developer would have to include those dependencies in the project. On the other hand, if you're publishing the library to maven repo, the gradle will take care of the library's dependencies. However the biggest challenge here is maintaining the library and resolving conflicts in actual app that uses the library. It can lead to frustration and eventually someone can throw your library away, which is the worst thing from library creator's perspective.

What I would suggest for this small library (calling api and providing data to custom view) is to:

1. Use only OkHttp without retrofit to provide the data from the REST api.
2. If it's the case for the library, create some abstraction over the OkHttp client with public functions/methods so the developers can get the data by themselves. Cool approach for creating this kind of interface is to use Fluent Interface (for example if you want the client of the library to put their access token/secret key for the REST api to detect who is calling the api, how much, limit their requests etc)
3. If you want to also provide the Custom View I would suggest to think twice about separating the REST client and Custom View itself and let the developer put the data by themselves. On the other hand if you want to handle it by yourself, you have to consider error handling, state management, lifecycle callbacks for cancelling the requests etc. You can provide some Listener interfaces for the developers so they know what is going on in the custom view.

The way you structure the library is up to you, if you have only one dependency (the rest client) just pass the objects via constructor so you won't need to add another dependency. Or just simply use ServiceLocator pattern, however it should also be connected to the Application/Activity itself when setting up the library so the objects are destroyed properly