Android自定义视图库的体系结构 [英] Architecture for a Custom View library Android

问题描述

我正在构建一个库，该库每30秒显示一个问题(从REST Api获取)，并允许用户选择一个可能的答案.

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.

所需结果

所有业务和UI逻辑都应在库中处理.

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

在库中使用存储库模式使用MVVM方法有意义吗?具有这种包装结构吗?

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

可能的包结构

推荐答案

您正在创建库，与应用程序相比，它是完全不同的上下文和创建代码库的方式.

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

首先，您需要对依赖项做出决策.当然，将改造，mvvm和其他依赖项放入应用程序并进一步进行管理非常简单.

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.

使用库并不是那么容易.首先，我希望从库中获得的依赖关系越少越好.如果要提供aar文件，则开发人员将必须在项目中包括这些依赖项.另一方面，如果要将库发布到Maven存储库，则gradle将处理库的依赖项.但是，这里最大的挑战是维护库并解决使用该库的实际应用程序中的冲突.这可能会导致挫败感，最终有人会把您的图书馆扔掉，这从图书馆创建者的角度来看是最糟糕的事情.

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.

对于这个小型库(调用api并向自定义视图提供数据)，我的建议是:

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

1. 仅使用OkHttp而不进行改造，以提供来自REST api的数据.
2. 如果是这种情况，请使用公共函数/方法在OkHttp客户端上创建一些抽象，以便开发人员可以自己获取数据.创建此类界面的一种很酷的方法是使用 Fluent接口(例如，如果您想要库的客户端将其访问令牌/秘密密钥用于REST api，以检测谁在调用该api，调用该API的次数，限制其请求等)
3. 如果您还想提供Custom View，我建议您三思而行，将REST客户端和Custom View本身分开，让开发人员自己放置数据.另一方面，如果您想自己处理它，则必须考虑错误处理，状态管理，用于取消请求的生命周期回调等.您可以为开发人员提供一些Listener接口，以便他们知道自定义中发生了什么视图.

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.

构造库的方式由您决定，如果只有一个依赖项(其余客户端)，则只需通过构造函数传递对象，这样就无需添加另一个依赖项.或者只是简单地使用ServiceLocator模式，但是在设置库时也应该将其连接到Application/Activity本身，以便正确销毁对象

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

这篇关于Android自定义视图库的体系结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！