请求代码不会自动传递给已启动的活动,因为它不需要(也不应该)知道这个值。它只需要知道要做什么而不是从哪里开始。
启动一个活动实际上只是调用方法的另一种形式。当您调用一个方法时,您会同步接收结果(就在您进行调用的地方)。在这种情况下,您只传递了该方法完成其工作所需的信息。你没有告诉它你从哪里调用它。
启动活动是调用方法的异步模拟,在这种情况下,您会在特殊方法 onActivityResult() 中接收结果。在这种方法中,您需要知道如何处理刚刚收到的结果,并且您有此请求代码。
为了更清楚为什么将请求代码作为参数传递不是一个好主意,请考虑显示您可以购买的产品的示例活动。在此活动中,有两个标记为“购买”和“登录”的按钮(因为您当前尚未登录)。按“登录”将启动一个名为“登录”的活动,该活动将尝试使用提供的信息登录用户。按“购买”将首先启动相同的“登录”活动,如果登录成功,则开始购买活动。
现在,“登录”按钮使用请求代码 1 来启动登录活动,但“购买”按钮不能使用相同的请求代码,因为如果登录成功,它必须执行不同的操作。因此,“购买”按钮使用请求代码 2。
在“登录”活动中,您可能会收到两个不同的请求代码,具体取决于调用它的位置,但您需要执行相同的过程。
因此,如果您将请求代码作为参数传递,您最终会得到需要为几个不同的请求代码执行相同操作的代码,例如:
if (requestCode == LOGIN || requestCode == BUY) {
// ...
} else ...
您还将最终将请求代码常量存储在中央位置,例如名为 RequestCodes 的类。
简而言之,请求代码应该只用于决定如何处理接收到的结果。这样,您最终将获得更模块化、更易于维护和更易于扩展的代码。