Android运行时权限api "requestPermission()"设计

Question

由于 Android 去年添加，Android API 版本 23 及更高版本中的运行时权限问题，我有一个关于

ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

和

   ActivityCompat.requestPermissions(new String[]Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

用于请求权限的 API。在上面的库中，我们必须提供 Activity 实例，它应该已经实现了 ActivityCompat.OnRequestPermissionsResultCallback 接口(interface)。 fragment和AppcompatActivity的支持版本，FragmentActivity默认实现了这个。

为什么我们只需要以 Activity 或 Fragment 的形式提供回调引用？我们可以将此 API 设计为

ActivityCompat.requestPermissions(context,
                    new String[]{Manifest.permission.READ_CONTACTS},
                    MY_PERMISSIONS_REQUEST_READ_CONTACTS,ActivityCompat.OnRequestPermissionsResultCallback callback);

我的意思是我们必须提供 Activity 或 Fragment 的支持版本。如果我们想检查任何其他简单类中的外部 Activity 怎么办？举个例子，我有一个 GeofenceManager 类需要位置权限，许多 Activity 或类需要来自这个 GeofenceManager 单例类的一些信息。

我是否必须在每个 Activity 中实现 OnRequestPermissionsResultCallback？我认为如果 Api 在上面建议的设计中会好得多。以这种方式设计 API 一定有一些重要的原因。我的一点经验是搞不出来。

Answer 1

所有 AppCompat API 都旨在尽可能容易地被其原生对应 API 替换。

表示 API 23 实现上的原生 android.app.Activity 是一个 public final void requestPermissions 方法和一个 public void onRequestPermissionsResult 回调.

以便将它们转换为 AppCompat。将它们作为单独的实体肯定会带来更灵活的方法，但也会导致将来无法在设备更新时弃用 AppCompat。

您可能会争论为什么 API23 Activity 不做同样的事情，但这只是一般情况下 Android 一直以来的方式，并且是他们处理一切的方法，例如 onActivityResult

此外，这些必须附加到 Activity，因为只有在前台时才应该请求权限。

编辑:

仔细一想，还有一个原因。回转!由于 Activity 在轮换期间被销毁和重建，基于 interface 的回调可能非常棘手。

回调方法需要某种类型的上下文或执行进一步的操作(转到下一个 Activity ，或从新授予的权限中加载/读取某些内容)。因此，如果编码人员将接口(interface)作为匿名内部类传递或使其 Activity 扩展该接口(interface)并发生轮换，它将泄漏 Activity 。或者回调方法需要接收上下文参数，但框架必须跟踪哪个 Activity 是当前上下文以发送回回调。所有这些都会很快变得非常复杂。因此，一种简单直接的方法是使其成为 Activity 的实际方法。