自定义视图库 Android 的架构答案

【问题标题】：Architecture for a Custom View library Android自定义视图库 Android 的架构
【发布时间】：2021-01-12 17:33:56
【问题描述】：

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

另外，我需要在应用程序中使用该库，在问题下方显示视频。

Desired result

所有的业务和 UI 逻辑都应该在库中处理。

在库中使用带有存储库模式的 MVVM 方法是否有意义？用这个包结构？

Possible package structure

【问题讨论】：

这个问题的答案将完全基于意见，我们不在这里处理关于 SO 的意见。架构不会向项目添加功能，因此没有理由说明 mvvm 会或不会有意义。这取决于你

标签： android architecture android-view

【解决方案1】：

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

首先，您需要对依赖项做出决定。当然，将retrofit、mvvm 和其他依赖项放入应用程序并进一步管理它们是非常容易的。

使用库并不容易。首先，我对库的期望是尽可能少地依赖。如果您要提供 aar 文件，则开发人员必须在项目中包含这些依赖项。另一方面，如果您将库发布到 maven repo，则 gradle 将处理库的依赖项。然而，这里最大的挑战是维护库并解决使用该库的实际应用程序中的冲突。这可能会导致挫败感，最终有人会扔掉你的图书馆，从图书馆创建者的角度来看，这是最糟糕的事情。

我对这个小型库（调用 api 并向自定义视图提供数据）的建议是：

仅使用未经改造的 OkHttp 来提供来自 REST api 的数据。
如果库是这种情况，请使用公共函数/方法在 OkHttp 客户端上创建一些抽象，以便开发人员可以自己获取数据。创建这种接口的酷方法是使用Fluent Interface（例如，如果您希望库的客户端将他们的访问令牌/密钥放入 REST api 以检测谁在调用 api，多少，限制他们请求等）
如果您还想提供自定义视图，我建议您三思而后行，将 REST 客户端和自定义视图本身分开，让开发人员自己放置数据。另一方面，如果您想自己处理它，则必须考虑错误处理、状态管理、取消请求的生命周期回调等。您可以为开发人员提供一些 Listener 接口，以便他们知道自定义中发生了什么查看。

构建库的方式取决于您，如果您只有一个依赖项（其余客户端），只需通过构造函数传递对象，这样您就不需要添加另一个依赖项。或者只是简单地使用 ServiceLocator 模式，但是在设置库时它也应该连接到应用程序/活动本身，以便正确销毁对象

【讨论】：