Share
Sign In
Swift | 학습 내용 정리
[Swift - UIKit, CoreLocation] iOS에서 사용자 정보 권한과 위치 권한 획득
한결
👍
iOS, iPadOS와 같이 애플 기기에서 돌아가는 운영체제는 사용자의 개인정보 보호에 아주 민감하다는 것을 많은 기사와 사례를 통해서 알 수 있다. 애플은, 어떤 기기에서 돌아가는 앱이든, 사용자의 앱 사용 경험을 헤치지 않으면서 유저가 권한 부여에 동의한 정보에 대해서만 앱이 활용할 수 있는 강력한 통제 시스템을 구축하고 있다.
사용자 > 기술 이라는 기본적인 모토에서 앱이 사용자의 정보 통제권을 쉽게 가질 수 없도록 만든다. iOS의 메이저 버전이 올라가면서 사용자가 앱에 줄 수 있는 개인 정보 통제권 유형을 *더 세분화 하고 있다.
💡
* 위치 정보를 허용한다고 했을 때,
어느 순간부터 아래와 같은 선택지를 사용자에게 제공해주었다. (iOS13+)
- 허용하지 않음
- 한 번만 허용
- 앱을 사용할 때만 허용
- 항상 허용
정리하면, 앱을 만들 때 사용자가 부여한 권한의 정도가 어떻게 되는지를 계속 신경써야 한다는 것이고, 사용자가 갑자기 해당 정보에 대한 권한을 차단하지는 않았는지를 계속 인앱 상황에서 모니터링 하고 있어야 한다는 점이다.
위치 정보에 대한 권한을 획득하고 획득한 위치 기반으로 현재 날씨를 보여주는 간단한 앱을 만들어 보면서 위치 서비스에 대한 권한 획득을 경험해봤다. 순서대로 기록해본다.
간단히 위치 정보 활용 동의받고 이용하기
1.
info.plist에서 Privacy 항목 활성화하고 사용자 위치 정보를 수집하는 이유가 담긴 문구 수정하기
해당 항목에 작성하는 문구가 추후에 권한을 획득하는 Alert의 메시지에 반영된다.
위치 정보를 왜 수집하고, 어떻게 사용되는지 등에 대해 최대한 자세히 작성해야 앱 출시에 제한이 없다.
2.
사용자가 애플 기기 시스템에서 위치 서비스에 대한 권한을 켜뒀는지 확인하기
// ViewController import CoreLocation extension ViewController: CLLocationManagerDelegate { private func configureLocation() { manager.delegate = self validateIsTurnedOnSystemAuthorization() } private func validateIsTurnedOnSystemAuthorization() { if CLLocationManager.locationServicesEnabled() { // 위치 서비스가 활성화 되어 있다면 이 분기로 빠진다. getUserLocationAuth() } else { print("유저가 시스템상 위치 서비스를 활성화 해야 합니다.") } } }
CoreLocation 패키지를 가져오고 CLLocationManager 클래스의 인스턴스를 생성하여 CLLocationManagerDelegate 로 위치 권한을 획득하는 역할을 VC에 위임해준다.
.locationServicesEnabled 라는 타입 메서드로 유저가 시스템 상에서 위치 서비스를 활성화했는지 확인한다.
else 구문으로 빠지면, 보통 alert 등을 통해서 시스템 설정에서 위치 서비스를 켜달라는 식으로 사용자의 선제 액션을 유도할 수 있다. (혹은 이동시킬 수도 있겠다.)
3.
사용자가 승인해준 우리 앱에 대한 위치 정보 활용 권한에 따라 위치 데이터를 사용한다.
private func getUserLocationAuth() { switch manager.authorizationStatus { case .notDetermined: // 여기서 위치 정보 획득 권한을 얻는 alert를 띄워준다. // 반드시 info.plist에서 설정한 권한 형식으로 간다. manager.requestWhenInUseAuthorization() case .denied: print("권한을 확보해야 함") case .authorizedWhenInUse: manager.desiredAccuracy = kCLLocationAccuracyBest manager.startUpdatingLocation() default: print("") } }
CLLocationManager가 가지고 있는 authorizationStatus 열거형을 통해 유저가 승인한 권한에 따른 분기를 처리해준다.
.notDetermined : 뜻 그대로 '정해진 것이 없는' 상태다. 권한 획득 모달에서 유저가 권한을 선택하기 전의 상태다. 즉, 앱에서 아직 유저의 위치 정보를 전혀 사용할 수 있는 상태가 아니다.
.denied : 권한 부여에 '거절'당한 상태다. 유저가 설정 앱에서 우리 앱에 대한 위치 서비스를 다시 부여하거나 모달에서 다시 권한을 부여하기 전까지 유저 위치 정보에 대한 서비스는 제공할 수 없다.
.authorizedWhenInUse : 앱을 사용하는 동안 위치 정보를 사용할 수 있는 권한이 부여됐다. 임시적으로 한 번 할 수도 있고, 앱을 사용하는 동안 부여받을 수도 있다.
.authorizedAlways : 앱이 백그라운드 상태여도 위치 정보를 사용할 수 있는 권한을 부여한다.
*내가 위치 기반 서비스를 이용해본 경험상, 앱이 사용되는 동안 허용으로 설정한 다음 일정 기간이 지난 다음 백그라운드 상황에서 '항상 허용' 권한을 요청하는 모달이 뜨곤했다.
.notDetermined 상태에서 매니저의 .requestWhenInUseAuthorization 메서드를 호출해서 모달을 띄워준다.
4.
authorizationStatus에 따라 권한 변화를 감지하고, 권한 획득 후 정보 사용이 시작된 순간 앱 서비스를 위한 로직이 돌아간다.
func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) { validateIsTurnedOnSystemAuthorization() } func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { guard let locate = locations.last?.coordinate else { return } AF.request(url).responseDecodable(of: WeatherModel.self) { res in switch res.result { case .success(let v): // API 통신 성공에 따른 비즈니스 로직이 온다. // 현재 위치를 한 번만 사용하는 앱이라면 위치 정보 업데이트를 멈출 수도 있다. self.manager.stopUpdatingLocation() case .failure(let e): print(e) } } }
locationManagerDidChangeAuthorization 메서드가 권한이 변경되는 순간을 감지한다.
이 메서드 내부에서는 처음부터 권한에 대한 검증이 필요하다. 개발자는 유저가 어떤 권한을 부여했는지 알 수 없기 때문이다.
didUpdateLocations 값은 .startUpdatingLocation 메서드가 동작하는 순간에 위치 정보를 업데이트 하기 시작한다.
.desiredAccuracy 속성에 부여한 정확성 값에 따라 위치가 어떻게 변경되었는지를 알아서 감지해서 위치 정보를 업데이트하여 배열로 돌려준다.
위치 정보를 한 번만 사용하고 추후에 업데이트 하지 않는 앱이라면, .stopUpdatingLocation 메서드로 위치 정보 업데이트를 종료할 수도 있겠다.
위치 권한 부여 로직 단계도를 간단하게 그려보면 이렇게 될 수 있겠다. (나만 이해하는 그림인가..)
정리해보면,
유저 Privacy 정보를 획득하기 위해서는
1.
시스템 상으로 우리가 사용하고자 하는 개인 정보 서비스를 유저가 활성화 해뒀는지 확인해야 한다.
비활성화 상태라면, 우리는 권한 자체를 요청할 수도 없다.
2.
1에 대한 서비스를 활성화한 상태라면, 어느정도 권한을 줄 수 있는지 물어봐야 한다.
이 단계에서 유저가 거부(.denied)한다면 우리는 정보를 활용할 수 없다. 설정에서 유저가 권한을 활성화 해주길 기다려야 한다.
3.
2에서 유저가 특정 상태로 권한을 부여해줬다면 그 권한 범위내에서 정보를 활용할 수 있다.
Ha
Subscribe to 'hankyeol'
Welcome to 'hankyeol'!
By subscribing to my site, you'll be the first to receive notifications and emails about the latest updates, including new posts.
Join SlashPage and subscribe to 'hankyeol'!
Subscribe
👍
Other posts in 'Swift | 학습 내용 정리'See all
한결
[Swift - UIKit] Swift 프로젝트에서 VC간에 데이터를 전달하는 4가지 방법
모바일 앱의 특성상, 작은 화면에서 한 번에 많은 데이터를 보여주는 것이 쉽지 않다. 그래서 하나의 앱에서도 다양한 형태의 데이터를 다양한 페이지에서 보여주고 있다. 그런 이유로 페이지간 데이터 전달이 중요한데, 지금까지 내가 학습한 4가지의 데이터 전달 방식에 대해 기록해두고 기억해보고자 한다. Swift는 기본적으로 클래스, 구조체로 화면에 대한 구조(=인스턴스)를 만든다. 구조의 멤버들은 뷰의 객체로서(아닌 경우도 있지만) 짜여진 구조에 맞게 데이터를 그려낸다. 인스턴스를 만드는 것이기 때문에 그 인스턴스가 생성되는 시점 + 생성되어 활용되는 그 구조의 공간이 무엇보다 중요하다. 전환하고자 하는 페이지(거의 VC)의 인스턴스를 생성하면, 내부의 멤버에 직접/간접적으로 접근해서 값을 할당해주는 것이 값 전달의 기본이다. 인스턴스의 멤버에 값 할당하기 해당 방법으로는, 넘어가고자 하는 VC의 인스턴스를 생성하고 해당 VC의 생명주기가 활성화되기 전에 인스턴스 멤버나 인스턴스 메서드를 실행시키는 형태로 다른 VC에 값을 전달한다. 넘어가고자 하는 VC에 대한 명확한 공간(=인스턴스)를 하나의 스코프 내에서 컨트롤 할 수 있기 때문에, 어떻게보면 가장 쉬운 데이터 전달 방식이 될 수 있다. '이전 VC에 대한 인스턴스를 생성하여 값을 넘겨주는 방식으로 넘어오기 전 VC로 접근할 수 있겠구나!' 라고 생각할 수 있겠지만, (어떻게 보면 당연하지만) 그렇지 않다. 넘어온 VC 환경에서 이전 VC에 대한 인스턴스를 생성한다는 것은 (아래 그림처럼) 완전히 새로운 VC의 인스턴스 환경을 구축하는 것과 같다. (⇒ 평행 세계에 이름만 같은 공간을 찾아가는 느낌이랄까) 그렇기 때문에, 넘어오기 전의 환경으로 컨택스트를 넘겨줄 수 없다는 의미가 된다. 클로저 활용하기 해당 방법으로는, 넘어가거나, 넘어온 VC에 값을 전달하는 간단한 익명함수(클로저)를 선언하고 (멤버 변수) VC 인스턴스에 접근하는 곳에서 해당 익명함수(클로저)의 내부 로직을 구현해주고 필요한 시점에 클로저를 호출시켜 컨택스트를 해당 시점으로 가져오는 형태로 다른 VC에 값을 전달한다.
한결
[Swift - UIKit] BaseView, APIService 싱글턴 패턴, DispatchGroup 등을 활용한 간단한 영화 평점 매기기 서비스를 구현해보았다.
영화 앱에서는 TMDB API를 활용하여 다음과 같은 페이지를 구현했습니다. 자세한 코드는 아래 깃헙에서 확인 가능합니다. 메인페이지 - 현재 상영작 / 요즘 주목받는 작품 / 역대 최고의 평가를 받은 작품 리스트를 테이블뷰 + 가로 컬랙션뷰 형태로 노출 영화 상세 페이지 - 컬랙션 아이템 터치시 해당 영화 id값을 기반으로 내가 매긴 별점, 줄거리, 출연진, 유사한 영화 리스트가 한 페이지에서 노출 영화 검색 페이지 - 텍스트 필드에서 키워드로 영화를 검색한 결과를 테이블뷰로 노출 (검색 결과가 없을 경우 핸들링) BaseView를 만들어 뷰의 상속 관계 이용하기 UIView를 상속받는 기본적인 BaseView를 만들어서 해당 뷰를 상속받는 뷰 객체들이 미리 정의된 메서드를 오버라이딩하여 UI와 기능을 보다 빠르고 편하게 구축할 수 있게 코드를 작성했다. 프로젝트 코드에서 UI의 레이아웃을 잡거나 서브뷰를 구성한다던지, UI와 관련된 코드를 작성하는 경우에서 반복이 많다. 위의 코드처럼 베이스가 되는 뷰 클래스를 하나 만들어두면, 어떤 메서드에서 레이아웃을 잡고, 어떤 메서드에서 UI 코드를 잡을지 따로 신경쓰지 않아도 된다. (제약을 미리 하나 만들어두는 느낌이라 Protocol을 활용하는 것과 비슷하다.) 자주 사용되는 UI 객체 역시 BaseView를 만들어서 활용했다. 특히, 라벨이라던지 박스 형태의 컴포넌트는 프로젝트 페이지별로 많이 활용되기 때문에(=인스턴스를 생성할 때가 많음) 베이스가 되는 클래스를 만들어 두는 것이 정말 유용했다. 인스턴스로 생성된 뷰 객체들은 외부에서 되도록이면 속성을 직접 건드리지 않고, 내부에 구현된 메서드를 이용할 수 있도록 제어자를 만드는 것에 집중했다. BaseLabel.swift BaseBoxItem.swift ViewController에서 컨트롤할 뷰 객체 전체를 감싸는 mainView를 분리하였다. VC에서는 해당 전체 뷰 객체의 인스턴스를 만들어서 loadView 메서드 내부에서 기존의 root view를 mainView로 대치하여 사용했다. 즉, 커스텀한 뷰로 nil 상태의 root view를 대체해주는 것이 loadView의 역할인 것이다. loadView 메서드를 오버라이드 할 때 주의해야 할 점은 (어떻게 보면 당연한 이야기 일 수 있는데) super의 loadView 구현부를 상속받지 않는 것이다. ViewController에서 View의 레이아웃이나 UI 코드에 대한 관심사를 분리시킬 수 있어 아주 유용해 보인다. 다만, 뷰 컴포넌트들의 구조가 복잡해지거나, 한 페이지에 정말 다양한 뷰 요소들이 들어가는 앱이라면 클래스의 뎁스를 많이 두는 것이 코드를 유지보수 하는 관점에서 좋을지는 계속 고민해볼 필요가 있을 것 같다.
한결
[Swift - UIKit] do - try - catch 구문을 이용해서 UITextField의 입력값 조건에 맞게 검증하기
회원가입을 한다던지, 맞춤형 서비스에서 네이밍을 하는 형태에서는 유저가 입력하는 값을 특정한 조건에 맞게 제한할 수 있다. 서비스 코드에서 '조건에 따른 제한'을 가한다는 것은 데이터에 대한 '조건별 제어'가 가능해야 한다는 것이고, 조건을 충족하지 못 한 경우에는 에러가 발생할 수 있다는 의미이기도 하다. do~try - catch 구문을 활용하면 특정 코드의 액션의 결과를 try로 기다린다. 성공할 경우 do 스코프 이내에서 try 이후의 구문이 실행된다. 실패할 경우 catch 스코프에서 실패에 따른 로직이 실행된다. 에러 케이스별로 실패 구문을 관리할 수 있다는 점이 좋다. 유저의 닉네임을 아래 조건에 따라 검증한다고 할 때, do~try - catch 구문으로 어떻게 에러에 따른 처리를 할 수 있을지 한 번 살펴보자. ValidationService 클래스를 구성해서 검증하는 로직과 에러 여부에 따라 문구를 보여주는 영역을 구분해보았다. 닉네임은 빈 문자열로 저장될 수 없다. 닉네임은 공백 포함 2자 이상 10자 이하로 구성되어야 한다. 닉네임에는 숫자가 들어갈 수 없다. 닉네임에는 @, % 라는 특수문자가 들어갈 수 없다. 1. ValidationService 클래스 생성하기 클래스 내부에 에러 조건에 대한 케이스 관리를 할 Errors 열거형을 만들었다. validateNickname 이라는 타입 메서드에서 각각의 조건을 검증하는 private 함수들을 실행시키다. 각각의 검증 함수에서 true 값을 확인 할 경우, 해당하는 에러 케이스로 쉽게 throw 해줄 수 있다. 외부에서는 이 메서드만 호출해서 입력 받은 값을 검증하고, 열거형 케이스에 따라 분기처리 할 수 있다. 2. UITextFieldDelegate 내부에서 do~try - catch 구문으로 에러 핸들링하기 TextField가 있는 VC에 UITextFieldDelegate를 위임해주면 textFieldDidChangeSelection 이라는 메서드 내부 로직을 구성해줄 수 있다. (꼭 이 메서드가 아니어도 괜찮다.) 해당 메서드 내부에서 do 구문으로 ValidateService 클래스의 validateNickname 타입 메서드를 호출한다. (textfield에 입력되는 글을 인자로 넣어준다.) 만약 조건에 충족되는 텍스트가 입력될 경우 성공 문구 보여주고, 확인 버튼이 터치할 수 있는 상태가 된다. 조건을 충족하지 않는 텍스트가 입력될 경우, 각 에러 케이스에 맞는 catch 구문으로 빠진다. 각각의 에러 케이스를 굳이 만들지 않고 catch 스코프 하나로 모든 에러 케이스를 핸들링 할 수도 있다.