240919 TIL

① 배운 것

android file provider authority

안드로이드에서 File Provider와 Authority 쉽게 이해하기

안드로이드 앱을 개발하다 보면, 한 앱에서 만든 파일을 다른 앱에서 사용해야 하는 경우가 종종 있어요. 예를 들어, 카메라 앱에서 사진을 찍고, 다른 앱에서 그 사진을 불러와야 할 때처럼요. 그런데 안드로이드는 보안 때문에 앱끼리 파일을 그냥 주고받는 걸 허용하지 않아요. 그래서 등장하는 기능이 바로 File Provider입니다.

이번 글에서는 File Provider가 무엇인지, 그리고 그 과정에서 중요한 역할을 하는 authority에 대해 쉽게 설명해볼게요.

---

1. File Provider가 뭐야?

간단하게 말하자면, File Provider는 앱들이 서로 파일을 안전하게 공유할 수 있게 도와주는 중간 다리 역할을 해요. 안드로이드의 보안 정책 때문에 앱 간에 파일을 직접 주고받는 게 불가능하지만, File Provider를 이용하면 특정 파일에 안전하게 접근할 수 있게 되는 거죠.

예를 들어:

• 앱 A에서 사진을 찍었다고 해봐요.
• 앱 B가 그 사진을 사용하려고 할 때, 바로 접근하는 게 아니라 File Provider를 통해 "앱 B야, 이 파일을 사용해도 돼!"라고 허락해주는 거예요.

2. authority는 또 뭐야?

자, 이제 중요한 부분! File Provider가 중간에서 파일을 안전하게 공유해주긴 하지만, 무조건 아무 앱에나 파일을 공유하는 건 아니에요. 각 앱을 구분할 수 있는 고유한 이름, 즉 authority가 필요해요.

쉽게 말하자면, authority는 그 앱이 인증된 앱이라는 걸 확인하는 신분증 같은 역할을 해요. 그래서 File Provider는 "이 앱은 신뢰할 수 있으니 파일을 주자!"라고 판단할 수 있게 되는 거죠.

3. authority가 왜 중요한가?

authority는 각 앱마다 고유해야 해요. 만약 두 개의 앱이 같은 authority를 가지고 있다면, 안드로이드는 두 앱을 구분할 수 없어요. 마치 두 사람이 똑같은 신분증을 가지고 있는 상황이 되는 거죠.

특히, 개발 단계(예: dev 환경)와 실제 배포 단계(예: prod 환경)에서 같은 authority를 사용하면 문제가 생길 수 있어요. 두 환경에서 빌드한 앱을 동시에 설치하려고 하면 안드로이드는 "이미 이 authority를 가진 앱이 설치되어 있습니다"라는 에러 메시지를 띄우고, 앱 설치가 안 될 거예요.

4. File Provider는 어떻게 authority를 확인하고 파일을 전달할까?

File Provider는 authority를 통해 인증된 앱만 파일에 접근할 수 있도록 해요. 예를 들어, 앱 A가 찍은 사진을 다른 앱에서 사용하려면 그 앱이 File Provider로부터 인증된 앱이어야 해요. 올바른 authority를 가진 앱만이 파일을 받을 수 있는 거죠.

그러니까 File Provider는 "이 앱이 내가 신뢰하는 앱인가?"를 authority로 확인한 다음, 맞으면 파일을 안전하게 전달해주는 역할을 해요. 그렇지 않으면 파일에 접근할 수 없어요.

5. authority를 어떻게 설정해야 할까?

authority는 보통 AndroidManifest.xml 파일에서 설정하게 돼요. 여기에서 앱의 고유한 이름을 설정해주면 되는데, 이를 applicationId와 함께 사용해요. 아래는 그 예시예요:

<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths" />
</provider>

여기서 android:authorities="${applicationId}.fileprovider" 부분이 바로 authority를 설정하는 부분이에요. applicationId는 앱의 고유한 패키지 이름을 나타내고, 이걸 기반으로 authority가 설정돼요.

6. 개발 환경과 배포 환경에서 서로 다른 authority 설정하기

앱을 개발할 때, dev와 prod 환경에서 각각 다른 authority를 설정해줘야 해요. 그렇지 않으면 앱을 동시에 설치할 때 충돌이 발생할 수 있어요.

이 문제를 해결하려면, applicationIdSuffix를 사용해 환경별로 authority를 다르게 설정할 수 있어요. 예를 들어:

android {
    ...
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
        release {
            // no suffix for release
        }
    }
}

이렇게 하면 개발용 앱은 com.example.myapp.debug.fileprovider로, 배포용 앱은 com.example.myapp.fileprovider로 서로 다른 authority를 가지게 돼서 충돌을 피할 수 있어요.

7. 정리

• File Provider는 안드로이드에서 앱 간 파일을 안전하게 공유할 수 있도록 돕는 기능이에요.
• authority는 앱의 고유한 이름으로, 이 이름을 통해 File Provider는 인증된 앱에게만 파일을 공유해요.
• 개발 환경과 배포 환경에서 authority가 겹치지 않도록 서로 다른 이름을 지정해야 충돌을 방지할 수 있어요.

핵심 정리:

• File Provider는 앱들이 파일을 안전하게 주고받을 수 있도록 해주는 중간 다리 역할을 한다.
• authority는 앱을 인증하는 신분증 같은 고유한 이름이다.
• 개발 환경(dev)과 배포 환경(prod)에서 각각 다른 authority를 설정해야 설치 충돌을 방지할 수 있다.

이제 안드로이드에서 File Provider와 authority가 어떻게 작동하는지 좀 더 쉽게 이해할 수 있겠죠? 😊

---

iOS에서 UNNotificationServiceExtension 환경별 설정하기: 빌드 설정 활용법

iOS 앱 개발 시 푸시 알림을 다룰 때 UNNotificationServiceExtension을 사용하는 경우가 많습니다. 개발 환경과 프로덕션 환경에서 서로 다른 설정을 사용해야 할 때, 빌드 설정을 활용하면 효과적으로 환경을 구분할 수 있습니다. 이 글에서는 UNNotificationServiceExtension에서 환경별로 다른 App Group 이름을 사용하는 방법에 대해 설명하겠습니다.

1. Xcode에서 빌드 설정 구성하기

먼저 Xcode에서 프로젝트의 빌드 설정을 구성해야 합니다.

1. Xcode 프로젝트를 엽니다.
2. 프로젝트 네비게이터에서 프로젝트를 선택합니다.
3. 타겟 목록에서 UNNotificationServiceExtension 타겟을 선택합니다.
4. 'Build Settings' 탭을 클릭합니다.
5. 검색 필드에 "Other Swift Flags"를 입력하여 해당 설정을 찾습니다.
6. "Other Swift Flags" 행을 더블 클릭하여 편집 모드로 들어갑니다.
7. Debug 구성에 -DDEV를, Release 구성에 -DPROD를 추가합니다.

이렇게 설정하면 Debug 빌드에서는 DEV 플래그가, Release 빌드에서는 PROD 플래그가 정의됩니다.

2. 코드에서 조건부 컴파일 사용하기

이제 UNNotificationServiceExtension의 코드에서 다음과 같이 조건부 컴파일을 사용할 수 있습니다:

#if DEV
let appGroupName: String = "group.co.example.dev"
#else
let appGroupName: String = "group.co.example.prod"
#endif

이 코드는 컴파일 시간에 평가됩니다. Debug 빌드에서는 DEV 플래그가 정의되어 있으므로 "group.co.example.dev"가 사용되고, Release 빌드에서는 그 외의 경우이므로 "group.co.example.prod"가 사용됩니다.

3. 실제 사용 예시

다음은 UNNotificationServiceExtension 클래스에서 이 설정을 사용하는 예시입니다:

class NotificationService: UNNotificationServiceExtension {
//didRecieve안에서 하는것이 중요 
    override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) {
        #if DEV
        let appGroupName: String = "group.co.hiing.hiing.dev"
        #else
        let appGroupName: String = "group.co.hiing.hiing.prod"
        #endif

        // appGroupName을 사용하여 공유 데이터에 접근
        if let sharedDefaults = UserDefaults(suiteName: appGroupName) {
            // 공유 데이터를 사용하여 작업 수행
        }

        // 나머지 알림 처리 로직...
    }
}

장점

1. 컴파일 시간에 결정되므로 런타임 오버헤드가 없습니다.
2. 코드가 간단하고 직관적입니다.
3. 실수로 잘못된 값을 사용할 가능성이 낮습니다.
4. Xcode의 빌드 구성(Debug/Release)에 자동으로 연동됩니다.

주의사항

• 새로운 빌드 구성을 추가할 경우, 해당 구성에 대한 플래그도 적절히 설정해야 합니다.
• 코드 내의 조건문(#if DEV 등)이 빌드 설정과 항상 일치하는지 확인해야 합니다.

결론

이 방법을 사용하면 UNNotificationServiceExtension에서 개발 환경과 프로덕션 환경에 따라 다른 App Group 이름을 쉽고 안정적으로 사용할 수 있습니다. 빌드 설정을 활용함으로써 코드의 가독성을 높이고 환경별 설정 관리를 효율적으로 할 수 있습니다.

② 회고 (restropective)

③ 개선을 위한 방법