带有活动的图书馆项目的最佳实践/策略，路由回主办活动？

Question

我正在开展一个包含一些活动的图书馆项目。这些活动需要根据输入重定向回宿主应用程序中的活动。

例如：

[host activity#1] -> [library activity] -> [host activity#1]
                                        -> [host activity#2]
                                        -> [host activity#3]

我面临的问题是为主机应用程序提供一个简单的 api，以定义在每个场景中路由到哪个活动。我考虑只允许他们在 onActivtyResult 中处理它，但是库中的某些场景可能如下所示：

[host activity#1] -> [lib activity#1] -> [lib activity#2] -> [host activity#1]
                                                          -> [host activity#2]

在我的库中创建一个静态类是否正常/正确，宿主应用程序可以定义哪些活动是用来处理每个场景的？

让他们在某个静态类中扩展一个接口是否合适，该接口定义在每种情况下要做什么（接口迫使他们定义每种可能情况下会发生什么）？

我不太确定如何表达这个问题，我的假设是这个问题有更好的术语可以帮助我通过搜索找到我正在寻找的东西。

Answer 1

我面临的问题是为主机应用程序提供一个简单的 api，以定义在每个场景中路由到哪个活动。我考虑只允许他们在 onActivtyResult 中处理它，但是库中的某些场景可能看起来像这样......

我认为onActivityResult 方法没有任何问题，您可以简单地链接这些调用并仍然返回到[host activity#1]，这将决定下一步导航的位置。

如果您害怕编写太多代码（我认为您不应该这样做），您可以考虑以下解决方法：创建一个覆盖 onActivityResult() 的基本活动类。它将所有导航逻辑放在一个地方，因此所有其他活动将通过扩展基本活动自动获取它。是的，你将不得不像这样写一些难看的代码：

if (this instanceof Activity1) {
    ...
} else if (this instanceof Activity2) {
    ...
}

确实，它看起来确实有点难看，但它也解决了代码分散在多个活动中的问题。从可维护性的角度来看，将这段代码包含在一种方法中对我来说完全没问题。

在我的库中创建一个静态类是否正常/正确，宿主应用程序可以定义哪些活动是处理每个场景的意思？

不，我认为这不好。该库不应该对主机应用程序一无所知，这只是一个糟糕的设计。它还要求宿主应用在使用之前将活动设置到库中，这会降低库的使用方便性。

让他们在某个静态类中扩展一个接口是否合适，该接口定义在每种情况下要做什么（接口迫使他们定义每种可能情况下会发生什么）？

是的，我认为这很好，实际上是最好的方法。在这种情况下，该库仅通过其自己的界面工作，它对主机应用程序一无所知。接口不必在类中定义，我更喜欢在单独的文件中定义它。这样客户就不一定需要看到封闭类。

我希望这会有所帮助。如果我没有回答这个问题，请提供更多详细信息以及您到目前为止所做的尝试。谢谢，祝您好运！