更符合逻辑、更规范的获取权限 | Android

前段时间开始阅读郭霖大神的《第一行代码》,跟着书上的代码开发了一款天气App。因为认为手动获取地址实在不够方便,于是开始尝试写一个自动获取定位的feature。

随着现在用户对于隐私的重视不断提升,Android也在 6.0(M/API23) 开始对应用的权限进行了进一步的规范。从以前在安装时告知用户应用将会使用的权限,到如今运行时权限。对于用户来说这是个好消息,但是对于开发者来说,这意味着需要针对不同的权限向用户进行申请,这自然是一个头疼的问题。

这篇文章就以我自己对应用的一个需求 —— 获取“模糊定位”权限 为例,向大家展示一下如何让申请权限更加符合用户的逻辑,更加符合开发要求,更加符合Android开发规范。

关于当前Android的权限分类,请参考 Android Developer Guides

对于权限的申请,我们也需要思考是否做到了权限需求最小化,具体可以参考 Android开发团队的建议

提示:此文仅讲述如何更好的申请权限,关于权限的详细介绍,还请各位移步 这篇文章 进行阅读


STEP0:梳理 权限使用/申请 的流程

根据Android Developer Guides的这篇文章,我们可以发现请求权限的全流程主要分为以下几个步骤:

  1. 判断在没有权限的情况下是否能提供功能。如果可以,跳至5
  2. 判断是否声明权限
  3. 判断权限是否为运行时权限 (Runtime Permission)。如果不是,跳至5
  4. 向用户发出权限申请
  5. 完成权限申请流程。继续使用应用功能无法提供对应功能

a6h3h-zqeoq.png

虽然从流程上看起来,应用只有一次向用户获取权限的机会。但是Android其实还是给予了开发者机会再次向用户解释权限用途并再次申请权限的机会。

我们可以通过Activity.shouldShowRequestPermission方法判断用户是否已选择 “拒绝并不再询问” 选项。当返回值为true时,我们可以使用Toast/Snackbar/Dialog向用户解释权限用途,并引导用户再次授予权限。

STEP1:在Manifest中注册权限

因为对于天气应用而言,并不需要过于精确的地理信息。对于用户而言,通过粗略的坐标获取天气信息已经足够,所以考虑在注册权限时使用android.permission.ACCESS_COARSE_LOCATION

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

    ...
</manifest>

注意,如果在编写完代码后Build&Run时发现申请权限闪退,可以检查一下是否忘记申明权限。当然,如果观察Logcat,系统也会打印error信息并提示去Manifest声明权限。 (不会吧不会真的有人忘记吧)

STEP2:判断应用是否拥有权限

在整体的流程中,我们先需要考虑用户是否已经授予应用对应的权限。当我们获得权限时,则直接执行对应的业务逻辑(在本例中是获取定位);若没有获取用户授予的权限,则进行权限授权流程。

// set a button to use auto position feature
val getLocationBtn: Button = findViewById(R.id.request_location_btn)

// set button listener to determine whether user granted the permission
getLocationBtn.setOnClickListener {
    // check permission here
    if (ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.ACCESS_COARSE_LOCATION
        ) == PackageManager.PERMISSION_GRANTED
    ) {
        // permission granted -> do get position feature here
        doGetPosition()
    } else {
        // permission denied -> use this to request location permission,
        //                      and we will expaine this later in artical
        permissionRequestLauncher.launch("android.permission.ACCESS_COARSE_LOCATION")
    }
}

这里使用到了一个permissionRequestLauncher变量。很明显,我们在此处使用了它的lunch方法,并传入了对应的 权限名称(String) 来进行权限的申请,关于它的具体介绍,下面就将提到。

STEP3:使用Acitivity Result API申请权限

在之前,我们请求权限需要使用ActivityCompat.requestPermission方法来申请权限,并手动重写onRequestPermissionResult方法完成请求回调。而在请求和回调之间需要使用requestCode来保持请求和回调处理一一对应。

// this is java code, not kotlin
// source url here: https://zhuanlan.zhihu.com/p/76599492

private void callPermission(){
    if(ActivityCompat.checkSelfPermission(MainActivity.this, Manifest.permission.CALL_PHONE) != PackageManager.PERMISSION_GRANTED){
            ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.CALL_PHONE}, 1);
    } else {
        callPhone();
    }
}
    
@Override
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
    super.onRequestPermissionsResult(requestCode, permissions, grantResults);
    if(requestCode == 1){
        if(grantResults[0] == PackageManager.PERMISSION_GRANTED){
            callPhone();
        }else {
            Toast.makeText(this, "权限未授权!", Toast.LENGTH_SHORT).show();
        }
    }
}

很明显,这样的代码非常混乱、不清晰,而且如果在请求权限较少的时候,这样的代码还会显得非常不简洁。这时候不妨考虑一下使用Activity Result API来解决这个问题。

我们首先需要声明一个ActivityResultLauncher<I>变量。在API中,此泛型用于表示输入进去用于创建Intent的类型,此处我使用String类型,传入android.permission.ACCESS_COARSE_LOCATION(见STEP2,具体原因后面讲解)

lateinit var permissionRequestLauncher: ActivityResultLauncher<String>

接下来,我们在onCreate方法中对permissionRequestLauncher进行初始化:使用ComponentActivity.registerForActivityResult方法返回一个ActivityResultLauncher<I>对象。

override fun onCreate(savedInstanceState: Bundle?) {
   ...
    permissionRequestLauncher =
        registerForActivityResult(RequestPermission()) { isGranted: Boolean ->
            if (isGranted) {
                doGetPosition()
            } else {
                doPermisionDenied()
            }
        }
}

这里让我们来看一下registerForActivityResult的参数,以便我们理解它的用法。

@NonNull
@Override
public final <I, O> ActivityResultLauncher<I> registerForActivityResult(
        @NonNull ActivityResultContract<I, O> contract,
        @NonNull ActivityResultCallback<O> callback) {
    return registerForActivityResult(contract, mActivityResultRegistry, callback);
}

对于contract变量,而上面我们使用的RequestPermission()生成并返回的的RequestPermission类对象,就是Activity Result API中定义好的用于请求权限Contract类,所以我们只需要直接使用即可。同样的,ActivityResultContract.java文件中也存在许多其他已经被实现好的(extands)的类,当我们在其他场景下使用Activity Result API时就可以使用这些其他的类。

注意,RequestPermission类实现的是ActivityResultContract<String, Boolean>。所以对应的Launch中的InputOutput类型就是StringBoolean类型了。(不记得了?回去看看STEP2吧)

对于callback变量,就比较明显了,这就是一个callback函数。当我们RTFSC的时候,发现它其实只有一个onActivityResult方法,而它的返回值类型就是刚刚我们提到的Output类型。OK,一切都明了了。所以我们只需要一个返回值为用Boolean表示授权结果的lambda函数就好了。

OK了,现在再回去看看,是不是明白了呢?(如果还不明白,建议再回去看一遍)

注意:ActivityResultLacuncher<I>变量的创建时期需要在ActivityonCreate方法中,或者是FragmentonAttach/onCreate方法中

为什么我会知道呢,给大家看看我当时犯的错x

java.lang.IllegalStateException: Fragment is attempting to registerForActivityResult after being created. Fragments must call registerForActivityResult() before they are created (i.e. initialization, onAttach(), or onCreate()).

STEP4:完善拒绝权限逻辑

STEP0的流程梳理中提到了,在用户没有选择“拒绝且不再询问”之前,应用仍有机会向用户进行权限用途说明并再次请求权限。那么我们接下来就利用前面所提到的Activity.shouldShowRequestPermission方法来判断一下是否仍然存在请求权限的机会,并向用户解释权限用途。

fun doPermisionDenied(): Unit {
        // determine whether still can request permission & explain
        if (shouldShowRequestPermissionRationale(Manifest.permission.ACCESS_COARSE_LOCATION)) {
            Toast.makeText(this, "permission denied!(still can get permission)", Toast.LENGTH_SHORT)
                .show()
            // request permission again
            permissionRequestLauncher.launch("android.permission.ACCESS_COARSE_LOCATION")
        } else
            Toast.makeText(this, "permission denied!(go to settings)", Toast.LENGTH_SHORT).show()
    }

这里我偷了个懒,没有写引导用户解释权限用途。各位可以根据自己的需求和业务场景选择合适的方案。(才不是想不到什么样比较好呢)


在经过了四个简单的步骤后,我们就已经完成了一个简单的权限获取的功能。相比于RequestPermission,它更简洁明了,更加清晰;同时还甩开了RequestCode这个大包袱,让我们的代码更加清晰。

当然,对于一次性申请多个权限,步骤也是和上面的代码十分相似的,可以参考一下Android Developer Guide

在看完整篇文章后,相信你也对Activity Result API有了更多的好奇。希望掘金上的另一篇文章能解答你更深层的疑问

希望这篇文章能够帮到你。第一次写长文,不足之处还各位请不吝赐教

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值