[1팀] 15. 권한 허가와 베이스 액티비티

이 글은 이것이 안드로이드다 with 코틀린(개정판)를 참고하여 작성하였습니다.

작성자 : 강현우

개발환경은 Windows, Android Studio입니다. 

 

1. 코틀린에서 권한 허가에 대한 논리 이해하기

권한 허가는 기존의 코틀린 개념들과는 다르게 위젯에 크게 영향받지 않는다. 오히려 다른 프로그램과 같이 알고리즘을 이해하는게 권한 허가를 배우는데 있어서 더 중요한 역할을 한다.

위 사진은 어플리케이션에서 유저와 앱이 권한 허가에 대해 서로 상호작용하는 것을 도표화 시킨 것이다. 이 사진을 이해한다면 허가에 관한 코드들을 이해하는데 큰 도움이 된다.

순서 1~3: 까지는 

순서 4: 허가가 이미 앱에 났는지를 확인한다. 앱을 유저가 사용을 시작했을때, 앱의 현재 허가 상태를 파악하고 허가가 없다면 허가를 신청하기 위한 과정으로 넘어가고, 허가가 있다면 앱을 계속 진행한다.

순서 5a: show a rationale이란 뜻은 간단하게는 팝업창을 보여준다는 것이다. 

순서 5b: rationale(팝업)에서 왜 추가적인 허가가 필요한지 설명.

순서 6: 허가에 대한 허가를 유저에게 신청

순서 7:  유저가 허가를 허락했나? Y/N

순서 8a: 7단계에서 허가를 받았기 때문에 유저 정보(허가 범위한에서) 접속한다.

순서 8b: 7단계에서 허가를 받지 못했기 때문에 유저 정보(허가 범위한에서) 접속하지 못한다.

 

2. 권한 허가 코드 알아보기

권한은 일단 일반과 위험으로 나뉜다. 일반과 위험의 차이점은 개인정보에 접근 권한이다. 일반은 manifest에서 한번만 선언하면 괜찮지만, 위험은 그렇게 처리할 수 없다. 

android 6.0 마시멜로부터 런타임 권한 처리가 추가되었다. 예를 들어서 카메라를 호출하기 위해서는 접근 권한이 필요한데, 6.0 이전까지는 AndroidManifest에 사용할 permission만 추가하면 되었지만 이제는 앱 사용 중 실제로 접근하는 시점에 권한을 허용했는지 체크하여 처리를 해야한다.

fun checkPermission(){
        val cameraPermission = ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
        if(cameraPermission == PackageManager.PERMISSION_GRANTED){
            startProcess()
        }else{
            requestPermission()

checkPermission() 함수는 위 논리 단계에서는 "순서4"에 해당한다. 즉, 현재 앱에 권한상태가 어떤지를 확인하는 코드이다. 여기서 cameraPermission == PackageManager.PERMISSION_GRANTED상태이면 바로 "순서 8a"로 가고 아니라면 "순서 6"으로 넘어간다. 

fun requestPermission() {
        ActivityCompat.requestPermissions(this, arrayOf(Manifest.permission.CAMERA), 99)

위 코드가 바로 실제로 유저에게 권한을 청하는 코드이다.("순서 6"에 해당한다.)

override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<out String>,
        grantResults: IntArray
    ) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults)
        when(requestCode){
            99 -> {
                if(grantResults[0]== PackageManager.PERMISSION_GRANTED){
                    startProcess()
                }
            }   else{
                    Toast.makeText(this, "권한을 승인하지 않으면 앱이 종료됩니다.",Toast.LENGTH_SHORT).show()
                    finish()
            }
        }
    }

위 코드는 권한요청 처리결과 수신에 대한 코드이다. 

 

3. BaseActivity

baseactivity의 필요성은 보다 프로젝트를 깔끔하고 간결하게 하기 위해서 있는것이다. 즉, baseactivity는 있을 수도 없을 수도 있지만, 프로젝트의 뼈대로 활용하기 위한 class를 만들어 놓는 곳이다. 해당 강의에서는 Baseactivity에 권한 요청에 대해서 class를 만들어 사용했다. 

상속에서의 확장성과 설계는 매우 주의해야 한다. 상속에서 기존과 달라지고 새로운 코드로 이동하도록 하고 싶다면 Deprecated를 걸어두고 새로운 함수로 이동할 수 있는 구조 역시 만들어야 한다. 이런 설계를 잘 할 수 있어야 하는데, AppCompatActivity을 포함하는 상위 상속은 구글이 책임지고 있으니 구글이 알아서 잘 해줘야 한다.

해당 강의에서는 BaseActivity에서 abstract으로 선언해서 사용했다. 이 부분은 final,abstract, open을 함께보면서 이야기해보겠다. 

4. final, abstract, open의 차이점.

위 3가지는 상속 변경자들이다. java에서는 기본적으로 class는 상속이 가능했다. 혹시 상속을 불가능하게 만드려면 final을 붙여서 선언했어야했다. 하지만, 무분별하게 클래스를 상속하게 된다면, 취약한 기반 클래스 문제에 직면하게 되어 어느 부분에 문제가 생길지 모른다는 위험이 있었다. Kotlin은 위와 같은 문제점을 해결하기 위해서 class의 기본 상속 변경자로 final을 설정해놓았다.

• Final : 상속이 불가능한 변경자

코틀린에서는 생략가능하다.(디폴트값이기 때문에)

• Abstract: 상속이 이루어져야만 하는 변경자

Abstract class는 상속을 해야만 인스턴스화가 가능한 변경자이다. 또한 보통 공통적인 method나 property를 정의하기 위해 사용한다.

• Open: 상속이 이루어 질 수 있는 변경자