问题描述
我正在构建一个库，该库每30秒显示一个问题（从REST Api获取），并允许用户选择一个可能的答案。
此外，我需要在应用程序中使用该库，并在问题下方显示视频。
所有业务和UI逻辑都应在库中处理。
使用带有库模式的MVVM方法有意义吗？ 具有这种包装结构吗？
解决方法
您正在创建库，与应用程序相比，它是完全不同的上下文和创建代码库的方式。
首先，您需要对依赖项做出决策。当然，将改造，mvvm和其他依赖项放入应用程序并进一步管理它们非常容易。
使用库并不是那么容易。首先，我希望从库中获得尽可能少的依赖关系。如果要提供aar文件，则开发人员将必须在项目中包括这些依赖项。另一方面，如果要将库发布到Maven存储库，则gradle将处理库的依赖项。但是，这里最大的挑战是维护库并解决使用该库的实际应用中的冲突。这可能会导致挫败感，最终有人会把您的图书馆扔掉，从图书馆创建者的角度来看，这是最糟糕的事情。
对于这个小型库（调用api并向自定义视图提供数据），我的建议是：
- 仅使用OkHttp而不进行改造以提供来自REST api的数据。
- 如果是这种情况，请使用公共函数/方法在OkHttp客户端上创建一些抽象，以便开发人员可以自己获取数据。创建此类接口的一种很酷的方法是使用Fluent Interface（例如，如果您希望库的客户端为REST api放置其访问令牌/秘密密钥，以检测谁在调用该api，多少，限制他们的要求，等等）
- 如果您还想提供Custom View，我建议您三思而行，将REST客户端和Custom View本身分开，让开发人员自己放置数据。另一方面，如果您想自己处理它，则必须考虑错误处理，状态管理，用于取消请求的生命周期回调等。您可以为开发人员提供一些Listener接口，以便他们知道自定义中发生了什么视图。
构造库的方式由您决定，如果只有一个依赖项（其余客户端），则只需通过构造函数传递对象，这样就无需添加另一个依赖项。或者只是简单地使用ServiceLocator模式，但是在设置库时也应该将其连接到Application / Activity本身，以便正确销毁对象