이동건의 이유있는 코드

블로그를 이전하였습니다.

군옥수수수 — Fri, 2 Nov 2018 16:18:39 +0900

블로그를 http://protocorn93.github.io 로 이전하였습니다!

많은 방문과 피드백 부탁드리겠습니다.

[Project] GitBingo

군옥수수수 — Thu, 6 Sep 2018 14:45:25 +0900

GitBingo (깃빙고)

App Icon by snowJang24, App Name by nailerHeum

1일 1커밋을 실천하려는 개발자들을 위한 어플리케이션

기능

실시간 Contribution 확인 가능
원하는 시간에 알람을 받아 금일 커밋을 진행하였는지 확인 가능
투데이 익스텐션 타겟을 사용해 위젯에서 이번주 커밋 정보와 알람 등록 시간을 확인 가능

사용한 기술

Swift4, Xcode9, UserNotifications, Error Handling, Localizing, Networking, UIApplicationShortCuts, Today Extensions, SwiftLint, Unit Test

사용한 아키텍쳐

Delegation, Singleton
시도한 아키텍쳐 : MVP

공부한 내용 정리

App Extension Programming Guide for iOS
- Essential
- Essential - Handling Common Scenarios

사용한 라이브러리

Kanna - https://github.com/users/ehdrjsdlzzzz/contributions 로부터 HTML을 파싱해오기 위해 사용
SVProgressHUD - Indicator와 함께 코멘트를 사용하기 위해 사용
SwiftLint - Swift 스타일과 컨벤션을 지키기 위해

문제점

웹 브라우저에선 00:00 이후 다음 날 컨트리뷰션 도트를 바로 확인 가능하지만 앱에선 GMT 시간 차로 오전 9시가 되어서야 그날의 도트를 받아올 수 있음.
- 이 문제를 해결하기 위해 많은 노력을 해보았으나 해결하지 못함
- 확인해본 결과 모바일 크롬이나 사파리에서도 동일한 이슈가 발생한 것으로 모바일에서 요청한 것에 대한 깃헙 서버의 응답에 이슈가 있는 것으로 판단하였음.

App Programming Guide for iOS -Introduction,Expected App Behaviors

군옥수수수 — Thu, 16 Aug 2018 12:21:31 +0900

[ios] App Programming Guide for iOS - Introduction,Expected App Behaviors

Xcode로부터 생성된 모든 프로젝트는 생성 그 즉시 시뮬레이터나 디바이스에서 실행이 가능합니다. 하지만 이렇게 단순히 실행이 된다는 이유 하나만으론 앱 스토에 배포될 준비가 되었다 할 수 없습니다. 모든 앱은 사용자에게 좋은 사용 경험을 보장할만한 어느 정도 수준의 customization이 필요합니다. 이러한 customization의 범위는 앱의 아이콘부터 앱의 설계 수준까지 다양합니다. 이번 챕터에선 모든 앱에서 처리해야하는 동작과 계획 과정 초기에 고려해야할 것들에 대해 설명합니다.

훌륭한 사용자 경험 전달을 보장하기 위해서 앱은 iOS와 함께 동작해야 합니다. 훌륭한 사용자 경험이란 단지 디자인뿐만 아니라 더 많은 요소들을 함축적으로 내포합니다. 앱의 사용자는 앱이 빠른 속도로 반응하고 적은 전력만을 사용하기를 기대합니다. 앱은 모든 최신 iOS 기기를 지원해야하며 현재 사용되고 있는 기기에서 최적화된 것처럼 보여야 합니다.

At a Glance

Apps Are Expected to Support Key Features

시스템은 모든 앱이 앱 아이콘이나 앱의 기능을 나타내는 정보와 같이 특정 리소스와 설정 데이터들을 갖고 있을 것이라고 간주합니다. Xcode를 통해 프로젝트를 생성한다면 몇몇의 정보는 기본적으로 주어지지만 추가적인 리소스 파일이나 앱의 기능의 명시는 앱이 배포되기 전에 반드시 설정해주어야 합니다.

Expected App Behaviors

Apps Follow Well-Defined Execution Paths

사용자가 앱을 실행한 시점부터 종료하는 시점까지 앱은 잘 정의된 실행 단계(경로)를 따라야 합니다. 앱의 생명주기 동안 앱은 foreground와 background를 오갈 수 있고, 종료된 후 재실행될 수 있으며, 또한 잠시 수면 상태에 돌입할 수 있습니다. 이렇게 새로운 상태로 변환될 때 마다 앱의 상태에 대한 기대는 달라집니다. foreground 상태의 앱은 거의 모든 것을 할 수 있지만 background에선 최소한의 행위만을 해야 합니다. 개발자는 이러한 상태 변화를 활용하여 앱의 동작을 적절하게 조정할 수 있습니다.

The App Life Cycle, Strategies for Handling App State Transitions

App Must Run Efficiently in a Multitasking Enviornment

사용자에게 베터리 Life는 성능, 반응 속도, 훌륭한 사용자 경험만큼 중요합니다. 앱의 베터리 사용량을 축소시킨다면 사용자는 해당 앱을 재충전 없이 하루종일 사용할 수 있겠지만, 빠른 앱 런칭 속도와 앱의 동작 속도또한 그만큼 중요합니다. iOS의 멀티태스킹 환경은 사용자가 기대하는 반응 속도나 사용자 경험을 희생시킬 필요 없이 좋은 베터리 Life를 제공합니다. 하지만 이를 위해선 앱이 시스템이 정의하고 제공하는 행위들을 수행해야 합니다.

Background Execution, Strategies for Handling App State Transitions

Communication Between Apps Follows Specific Pathways

보안성의 목적으로 iOS 앱들은 각각의 샌드박스에서 실행되며 다른 앱과의 제한된 상호작용만 허용됩니다. 시스템 상의 다른 앱들과 통신을 하고 싶다면 특별한 방법이 존재합니다.

Inter-App Communication

Performance Tuning is Important for Apps

앱에 의해 수행되는 모든 작업은 그에 맞는 에너지 비용이 따르기 마련입니다. 사용자의 베터리를 많이 잡아먹는 앱은 부정적인 사용자 경험을 제공하고 이는 앱의 삭제로 이어지기 됩니다. 그렇기 때문에 작업에 따른 비용을 항상 인지하고 있어야 하며 시스템이 제공하는 에너지 절전 기능을 활용해야 합니다.

Performance Tips

Providing the Required Resources

모든 앱은 디바이스 위에서 실행되기 위해선 다음 목록에 해당하는 리소스와 메타데이터들을 반드시 포함해야 합니다.

An information property-list file
- Info.plist는 시스템이 앱과 상호작용할 때 필요로 하는 메타데이터를 포함하고 있습니다. Xcode는 프로젝트의 생성 시 초기 설정에 맞게 자동으로 이 파일을 생성해줍니다. 이 파일은 제작하는 프로젝트의 특성에 따라 직접 수정할 수 있습니다.
- The Information Property List File
A declaration of the app's required capabilites
- 모든 앱은 앱 동작에 필요한 하드웨어 기능들을 반드시 명시해주어야 합니다. 앱스토어는 이 정보를 이용하여 해당 앱이 사용자(앱스토에서 앱을 받으려는 사람)의 디바이스에서 동작할 수 있는지 없는지를 결정합니다. 역시 제작하는 프로젝트의 특성에 따라 직접 수정할 수 있습니다.
- Declaring the Required Device Capabilities
One or more icons
- 앱의 아이콘은 시스템에 의해 사용자의 홈 화면에서 확인할 수 있습니다. 또한 설정 앱에서 다른 버전의 앱 아이콘을 설정할 수 있습니다.
- App Icons
One or more launch images
- 앱이 시작되고 앱의 UI가 준비될 때 까지 시스템은 임시로 launch image를 사용자에게 보여줍니다. launch image를 통해 사용자는 앱이 실행 중이고 곧 메인 화면으로 진입할 것이라는 것을 알 수 있습니다. 앱은 반드시 하나 이상의 launch image를 갖고 있어야 하며 다양한 시나리오에 맞춰 다양한 launch image를 사용할 수 있습니다.
- App Launch (Default) Images

The App Bundle

iOS 앱을 빌드하면 Xcode 이를 번들(bundle)이라는 것으로 포장합니다. 번들은 하나의 디렉토리로 관련된 리소스들을 한 장소에 그룹지어 놓은 것을 의미합니다. iOS 앱 번들은 앱의 실행 파일과 앱 아이콘, 이미지 파일, 지역화된 컨텐츠와 같은 리소스 파일들을 포함하고 있습니다. 다음 테이블 표는 설명을 위한 전형적인 iOS 앱인 MyApp의 앱 번들에 포함되는 컨텐츠들을 설명합니다.

이 예제는 설명을 위한 목적으로 몇몇 파일은 여러분들의 앱 번들에 없을 수 있습니다.

File	Example	Description
App executable	`MyApp`	실행 가능 파일은 앱의 컴파일 된 코드를 포함합니다. 실행 가능 파일의 이름은 앱의 이름에서 `.app` 확장자를 뺀 것과 동일합니다. [필수]
The information property list file	`Info.plist`	`Info.plist` 파일은 앱의 설정 정보를 포함하고 있으며 시스템은 이 정보를 사용하여 해당 앱과 어떻게 상호작용할지를 결정합니다. 이 파일명은 반드시 `Info.plist`이어야 합니다. [필수]
App icons	`Icon.png` `Icon@2x.png`	홈 화면에서 앱을 나타내는 아이콘 [필수]
Launch Images	`Default.png`	앱의 실행 준비동안 사용자에게 보여지는 이미지로 앱이 UI를 보여줄 준비가 되면 사라지고 UI가 나타납니다. 최소한 한 개 이상의 이미지가 요구 됩니다. [필수]
Storyboard files (or nib files)	`Main.storyboard`	스토리보드 파일은 앱이 디바이스 화면에 보여주는 뷰나 뷰 컨트롤러들을 포함합니다. 뷰 컨트롤러는 뷰들을 묶어 정렬하고 이들을 화면에 보여주는 역할을 합니다. 또한 스토리보드는 한 세트의 뷰들에서 다른 세트의 뷰들로의 전환 작업(Segue)에도 관여합니다. 메인 스토리보드 파일의 이름은 Xcode에 의해 프로젝트 생성시 자동으로 결정되는데 `Info.plist`에서 이를 변경해줄 수 있습니다. nib 파일을 사용하는 프로젝트에서도 마찬가지 입니다. 스토리보드 파일의 사용은 필수는 아니지만 권장됩니다.
Settings bundle	`Settings.bundle`	만일 디바이스의 설정 앱에서 앱의 설정이 보여지길 원한다면 설정 번들을 반드시 포함시켜야 합니다. 이 번들은 선택 사항입니다.
Nonlocalized resource files	`sun.png`	이미지, 사운드, 동영상과 같이 지역화되지 않은 파일이라 합니다. 이러한 모든 파일들은 앱 번들에 상단에 위치해야 합니다.
Subdirectories for localized resources	`en.lproj` `fr.lproj`	지역화된 리소스들은 반드시 `.lproj` 접미사를 갖는 언어 별 프로젝트 디렉토리에 위치해야 합니다. iOS 앱은 국제화되어야 하며 지원하는 언어 별 `.lproj` 디렉토리를 갖고 있어야 합니다.

iOS 앱은 Resource라는 이름의 사용자 정의 디렉토리는 생성할 수 없습니다.

Supporting User Privacy

사용자의 개인정보를 다루기 위한 설계는 매우 중요합니다. 대부분의 iOS 디바이스에는 사용자가 외부나 다른 앱에 노출시키고 싶지 않은 민감한 데이터들을 갖고 있습니다. 만일 앱이 사용자 정보에 부적절한 방식으로 접근하거나 사용한다면 사용자는 해당 앱을 그 즉시 삭제할 것입니다.

이러한 사용자나 디바이스의 정보에 접근 사용자의 승낙하에 이루어져야 합니다. 게다가 사용자와 디바이스의 정보를 보호하는데 적당한 단계를 거쳐야 하며 데이터의 사용은 투명하게 이루어져야 합니다. 다음은 이러한 민간한 데이터에 접근할 때 취할 수 있는 행동의 좋은 예제들입니다.

정부나 산업계의 가이드라인을 따른다.
iOS 시스템 허가 설정에 의해 보호되고 있는 민감한 데이터에 접근 허가 요청은 앱이 해당 데이터를 필요로 하는 그 순간에 이루어져야 합니다. 이렇게 민감한 데이터에 접근을 요청할 때는 왜 필요하며 어떻게 사용할지에 대한 적절한 문구를 Info.plist에 해당 데이터 사용 요청 권한 문구에 명시해주어야 합니다. iOS 시스템 허가 설정에 해당하는 데이터는 위치, 연락처, 캘린더, 추억, 사진, 미디어 등이 있습니다. 사용자가 데이터의 접근을 허가하지 않는 상황에서도 합당한 대체 행위를 제공해야 합니다.
데이터가 어떻게 사용되는지에 대해 투명하게 공개되어야 합니다. 예를 들어 앱스토에 앱을 배포할 때 데이터 사용 정책에 대한 URL을 메타데이터에 포함시킬 수 있습니다. 또한 앱의 설명에서 이러한 민감한 데이터 사용 정책에 대해 기술할 수도 있습니다.
사용자나 디바이스에 정보에 대한 권한은 전적으로 사용자에게 있어야 합니다. 사용자가 언제든지 데이터 접근에 대해 거부할 수 있어야 합니다.
작업을 수행하기 위한 최소한의 데이터만을 요청하고 사용해야 합니다. 불필요하거나 추후에 사용할 것 같다는 이유와 같이 명백한 이유 없는 불필요한 데이터의 요청이나 수집은 하지 말아야 합니다.
앱에서 수집하려는 사용자나 디바이스 데이터는 적절한 단계를 거쳐 보호되어야 합니다. 앱 자체에서 이러한 정보들을 저장하려면 iOS의 데이터 보호 기능들을 사용하여 암호화된 데이터들을 저장해야 합니다. 사용자나 디바이스의 정보를 네트워크를 통해 전송하기 위해서는 App Transport Security를 사용해야 합니다.
앱이 오디오 입력을 지원하는 경우 실제로 녹음을 시작하는 시점에 녹음을 위한 오디오 세션을 구성해야 합니다. 녹음을 시작할 때 사용자에게 이를 알리고 녹음을 중지할 수 있는 옵션도 제공해야 합니다.

참고자료

App Programming Guide for iOS

[Swift] Swift에서 정규표현식 사용하기

군옥수수수 — Sat, 11 Aug 2018 07:31:52 +0900

[Swift] Swift에서 정규표현식 사용하기

저는 지금까지 텍스트 필드 위에 입력되는 사용자의 입력이나 텍스트 덩어리에서 원하는 패턴의 값을 뽑아내거나 검증을 할 때 항상 모든 경우에 대해 if-else 와 같은 조건문을 이용하였습니다.

하지만 이렇게 조건문으로 모든 것을 해결하려하니 코드의 가독성, 효율성이 떨어질 뿐만 아니라 시간도 꽤나 소모되는 경우가 허다했습니다. 그러던 와중 매번 나랑은 관계없다고 생각한 정규표현식을 사용하고 느낀 편리함을 기록해보고자 이렇게 글을 작성하게 되었습니다. 그럼 바로 시작해보도록 하겠습니다.

NSRegularExpression

먼저 Swift에서 정규표현식을 사용하여 패턴을 검증하기 위해선 NSRegularExpression을 사용해야 합니다. 앞에 NS-가 붙어있다는 사실만으로도 NSRegularExpression이 Objective-C로 작성되어 있다는 것을 알 수 있습니다.

먼저 이를 직접 사용해보면서 어떤 식으로 사용하는지에 대해 알아보도록 하겠습니다.

예제의 상황은 이렇습니다. 사용자가 입력한 다음의 텍스트로부터 #가 접두어로 있는, 즉 해시태그에 해당하는 문자들을 뽑아보도록 하겠습니다.

"I made this wonderful pic last #christmas... #instagram #nofilter #snow #fun"

Pattern

우리가 뽑아낼 단어는 접두어로 #를 갖는 단어들입니다. 이러한 단어들을 뽑아내기 위한 정규표현식은 #[a-z0-9]+ 입니다. 이게 무엇을 의미할까요?

[] 안에 특정 패턴이 어떠한 종류의 값을 갖는지에 대해 값의 범위(range)를 표현해주어야 합니다. 해시태그로 # 뒤에 알파벳과 숫자를 갖는 패턴으로는 #[a-z0-9]가 됩니다.
그렇다면 +는 무엇일까요? 이는 바로 특정 범위에 해당하는 문자들이 한개 혹은 그 이상 존재한다는 의미입니다. 만일 + 가 붙지 않았다면 #5 와 같이 # 뒤 한개의 문자만 있는 해시태그만 찾아낼 것입니다.

NSRegularExpression

그럼 이제 본격적으로 NSRegularExpression을 사용해보도록 하겠습니다. 위에서 정의한 #[a-z0-9]+ 의 패턴을 갖는 인스턴스는 다음과 같이 생성할 수 있습니다.

let regex = try? NSRegularExpression(pattern: "#[a-z0-9]+", options: .caseInsensitive)

.caseInsenstive 란 단어 그대로 case, 즉 uppsercase, lowercase에 둔감하다는 의미로 대소문자를 구분하지 않는다는 옵션입니다.

이렇게 우리는 하나의 정규 표현식 패턴을 갖는 거름망을 만든 것이라고 보면 됩니다. 그럼 이제 텍스트를 이 거름망에 통과시켜 보도록 하겠습니다.

let text = "I made this wonderful pic last #christmas... #instagram #nofilter #snow #fun"

let textToNS = text as NSString 
regex.matches(in: text, options: [], range: NSRange(location: 0, length: textToNS.length))

in: 에는 검사할 텍스트를 넣어줍니다.
range: 에는 검사할 텍스트의 범위를 정해줍니다. 하지만 코드에서 String 을 NSString 으로 캐스팅하여 넣어준 것을 확인할 수 있습니다. 이는 NSRegularExpression이 NSRange를 인자로 받기 때문인데 NSRange를 받는 이유는 기본적으로 Objective-C와 Swift에서 문자열을 처리하는 방법이 다르기 때문입니다.

이렇게 matches를 통해 우리는 거름망을 통과시킨 결과를 얻을 수 있는데 그 결과 타입은 [NSTextCheckingResult]입니다. 그리고 NSTextCheckResult는 검사를 원하는 텍스트에서 거름망의 패턴과 일치하는 부분 텍스트가 있다면 해당 부분 텍스트의 범위를 NSRange의 형태로 반환하고 NSTextCheckResult는 이를 range 프로퍼티로 갖고 있습니다.

regex.matches(in: self, options: [], range: NSRange(location: 0, length: string.length)).map {
    string.substring(with: $0.range)
}

그렇다면 우리는 그렇게 나온 일치하는 부분 텍스트의 범위(NSRange)를 통해 부분 텍스트들을 원본에서 뽑아낼 수 있습니다. 그렇게 결과로는 ["christmas", "instagram", "nofilter", "snow", "fun"]가 나오게 됩니다.

이렇게 정규 표현식을 사용한다면 보다 쉽게 텍스트로부터 원하는 패턴의 값들을 뽑아낼 수 있습니다. 다음은 제가 사용하기 위해 공부해 본 정규 표현식입니다.

"[a-z0-9]+"(?=:) : json 키-값 쌍에서 키를 찾아주는 정규 표현식입니다.
1. (?, ... ) : 이는 전방 탐색 문법으로 ...에 오는 패턴 앞을 검사합니다. 저는 이 부분에 : 를 넣었으니. 모든 텍스트에서 : 앞을 검사하게 됩니다.
2. "[a-z0-9]+" : : 앞에 "" 안에 들어있는 즉 문자나 숫자를 포함하는 문자열이 존재하는지 검사하기 위한 조건입니다. 이렇게 되면 우리는 json 키-값 쌍에서 키를 찾아낼 수 있습니다.
3. NSRegularExpression에서 사용할 때 주의할 점은 "" 안에 위의 표현식이 들어가기 때문에 반드시 \"처리를 해주어야 합니다. in: "\"[a-z0-9]+\"(?=)"
[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,20} : 이메일의 형식 검사
1. 사용자가 이메일을 입력했을 때 유효한 이메일인지 검사하는 패턴입니다.

마무리

이외에도 우리는 수 많은 정규 표현식을 사용할 수 있습니다. 그 문법은 굉장히 무궁무진합니다. 그렇기 때문에 이들을 적절히 사용한다면 왠만한 패턴의 텍스트들을 모두 뽑아낼 수 있을 것입니다.

오늘은 이렇게 Swift에서 정규 표현식을 사용하는 방법에 대해 공부했습니다. 정규 표현식의 문법을 마음대로 사용할 수준은 아직은 아니지만 기회가 있을 때마다 적극적으로 사용하며 이를 익힐 수 있도록 해야겠습니다.

이런 정규 표현식은 구글에 검색해보면 일종의 치트 시트 형식으로 많이 사용하는 문법들을 정리해 놓은 pdf 파일이나 블로그 글들을 쉽게 접할 수 있습니다. 이들과 정규 표현식을 사용해 볼 수 있는 각종 사이트들을 활용한다면 왠만한 패턴들은 뽑아내실 수 있을 겁니다. 감사합니다.

참고자료

[ios] Xcode에서 Unit Test를 해보다

군옥수수수 — Sat, 21 Jul 2018 22:46:12 +0900

[ios] Xcode에서 Unit Test를 해보다

안녕하세요. 오늘은 프로그래밍 공부를 시작하면서 처음으로 테스팅이라는 것을 해본 경험을 기록해보고자 이렇게 글을 작성하게 되었습니다.

사실 TDD, 유닛 테스트 등 여러 테스팅에 관련된 이야기를 들어만 봤을 뿐 이것을 해볼 시도도 하지 않았고 그렇게 중요하게 생각도 하지 않았습니다.

하지만 Let us: Go! 2018 밋업에서도 주제로 언급이 되었었고 연사분께서 하신 말씀 중 새로운 것을 두려워하고, 낯선 것을 두려워하기 때문에 TDD를 팀에 도입하기 힘들다는 말씀에 저 스스로 너무나 부끄러웠습니다.

하지만 다행히 저또한 해볼 수 있는 기회가 생겨서 굉장히 초보적이고 거창한 테스팅 코드는 아니지만 이를 통해 나름 뿌듯한 경험을 하게 되어 이렇게 글까지 작성하게 되었습니다.

물론 어느정도 찾아보고 공부를 한 후 글을 작성하는 것이지만 이는 저의 단순한 경험기이고 명확하지 않은 의미 전달과 잘못된 정보가 내포되어 있을 수 있습니다. 이점 양해 부탁드리며 많은 피드백 역시 부탁드리겠습니다.

Testing with Xcode

먼저 저는 개발자 문서를 가장 먼저 찾아보았습니다. 그리고 이곳에서 설명하는 내용 중 제가 이해하게 된 부분을 먼저 간략하게 정리해보려 합니다.

이 부분에서는 테스팅의 방법론이나, 좋은 테스팅 코드를 작성하는 법 등이 아닌 단순히 테스팅의 목적, Xcode에서 테스트 코드를 작성하는 방법과 각 메뉴, 메소드들의 역할들에 대해서만 이해하였습니다.

테스팅 준비하기

먼저 유닛 테스트를 진행하기 위해서는 테스트 타겟을 생성해야 하고 현재 프로젝트와 연결시켜주어야 합니다. 이를 위해서는 두 가지 방법이 존재합니다.

1. 프로젝트 생성시 함께 만들기

프로젝트를 생성하실 때 Include Unit Test와 Include UI Tests 항목을 선택하시게 되면 테스트 코드의 뼈대가 포함된 프로젝트를 함께 생성하실 수 있습니다.

2. 추후에 만들어 포함시키기

만일 항목을 선택하지 않고 프로젝트를 생성하였다면 다음과 같은 방법으로 테스트 코드를 만들어 포함시킬 수 있습니다.

먼저 Navigator의 왼쪽에서 여섯 번째 항목으로 들어간 후 하단의 + 버튼을 눌러 추가할 수 있습니다.

만일 유닛 테스트 타겟을 생성한다면 다음과 같이 Target to be Tested 항목에서 테스트할 프로젝트를 선택해주어야 합니다. 이것이 끝이 아니라 마지막으로 테스트의 대상이 되는 프로젝트의 파일들에서 테스트 타겟을 타겟 맴버쉽으로 포함시켜야 합니다. 그래야 테스트 타겟에서 테스트의 대상이 되는 모듈에 접근이 가능하기 때문입니다.

부끄러운 사실이지만 저는 이것조차 하지 못해 굉장히 해맸습니다....!!

간단한 테스트 코드 작성해보기

이렇게 테스트 타겟을 생성하게 되면 이와 함께 테스트 클래스가 생성됩니다.

먼저 setUp 메소드부터 살펴보면 이 메소드에서는 이 테스트 클래스에서 진행되는 모든 테스트 케이스에서 공통으로 필요로 하는 행위들을 정의해줍니다. 즉 클래스 안에 속하는 테스트 메소드들이 호출되기 전 항상 setUp 메소드가 호출되는 것입니다.

예를 들자면 각 테스트 케이스에서 필요한 객체를 이곳에서 생성해줄 수 있습니다.

그 다음으로는 tearDown 메소드입니다. setUp 메소드와 유사하지만 그 반대로 모든 테스트 케이스 메소드들이 종료된 후 호출되는 메소드로 setUp에서 생성되고 테스트 메소드에서 사용된 것들을 정리해주고 해제할 필요가 있을 때 해당 내용들을 tearDown에 작성해주면 됩니다.

그럼 테스트 메소드를 작성해볼까요?

테스트 메소드는 test 접두어를 붙인 메소드로 이런 접두어가 붙은 메소드 옆에는 다이아몬드 모양이 생기고 우리는 그 버튼을 눌러 테스팅을 진행할 수 있습니다. 그리고 각 케이스는 하나의 메소드로 분리하여 작성해야 합니다. 테스트 메소드도 메소드로 하나의 기능만을 수행해야하기 때문에 하나의 테스트 메소드 안에 여러 케이스를 넣는 것은 올바른 방법이 아닙니다.

그리고 우리는 XCTAssert... 계열 메소드를 사용하여 기대 값과 실제 결과 값을 비교하여 테스트 수행 결과를 확인할 수 있습니다.

XCTAsset 계열 메소드는 공식 문서에서 확인해보실 수 있습니다.

만일 pow(3) 의 결과가 9가 아니라면, 즉 기대 값과 테스트의 대상이 되는 메소드의 결과 값이 같다면 XCTAssertEqual 메소드를 무사히 통과하겠지만 그렇지 않다면 테스트에 fail 했다는 안내와 함께 결과 값이 올바르지 않습니다.라는 문구가 함께 출력될 것입니다.

저는 이러한 테스팅을 하는 방법도 방법이지만 좋은 테스팅, 올바른 테스팅에 대해 궁금하였습니다. 여러 글들을 보아도 테스팅에 대한 경험이 전무하기 때문에 와닿지는 않았지만 "이런거구나~" 정도의 감만 익히는 수준으로 글들을 빠르게 읽어갔습니다.

그리고 제가 이해한 것들을 바탕으로 좋은 테스팅과 올바른 테스팅에 대해 간략하게 정리해보았습니다.

FIRST

Fast - 테스팅은 빠르게 동작해야 한다.
Independent / Isolated - 독립적이어야 한다.
Repeatable - 동일한 인풋의 테스팅의 결과는 항상 동일해야 한다.
Self-Validating - 테스트는 완벽히 자동화되어야 한다. 그 결과 자체로 성공과 실패를 알 수 있어야 한다.
Timely - 이상적인 테스트 코드는 테스트할 코드를 작성하기 전 작성되어야 한다.

Given, When, Then

Given, When, Then으로 섹션을 나누어 작성하는 습관을 기르자

Given - 입력 값을 제공
When - 입력 값을 사용해 테스트의 대상이 되는 메소드를 실행
Then - 결과 값을 증명 (기대값과 비교)

위의 예시에 이를 적용한다면 다음과 같습니다.

Asynchronous Test

비동기 코드에 대한 테스팅은 대체로 느리기 때문에 보다 빠른 테스트 코드와 분리시켜야 한다.

Fail Faster

테스트를 진행하다보면 당연히 실패하는 케이스도 있습니다. 하지만 그 실패하는 케이스는 되도록 빠르게 결과를 내뱉어야 합니다. 이게 무슨 뜻인지는 코드를 통해 살펴보도록 하겠습니다.

여기서 요청(request)에 대한 기대 응답을 5초동안 기다리는 것이 아닌 그 결과가 나오는 즉시 실패에 대한 결과를 보여주는 것입니다.

마무리

테스팅에 대한 많은 얘기들이 오고가는 글들이 존재합니다. 하지만 이제 막 테스트를 처음 해본 저에게는 아직 와닿지 않는다거나 하는 글들이 많았습니다. 하지만 확실히 왜 테스트 코드를 작성하고 이를 적극 도입하려는 움직임이 생기는지는 조금씩 이해가 가기 시작하였습니다.

미래에 이 글을 보게 된다면 웃음이 날 정도로 기초적이고 당연하며 올바르지 않은 내용이 담겨있을 수 있는 글이지만 이 글을 시작으로 테스트에 보다 더 적극적이고 열린 마음으로 임해야겠습니다. 감사합니다.

굉장히 두서 없는 글이지만 혹여나 틀린 정보가 있다면 많은 피드백 부탁드리겠습니다.

[iOS Boostcourse] 동시성과 병렬성 그리고 비동기 프로그래밍

군옥수수수 — Wed, 18 Jul 2018 14:52:37 +0900

[iOS Boostcourse] 동시성과 병렬성 그리고 비동기 프로그래밍

이전에 운영체제 과목을 수강하면서 공부했던 내용입니다. 당시에도 굉장히 비중있게 공부했던 부분이라 이번 부스트코스를 통해 다시 공부를 하게 되어 이를 간단하게 요약하고 정리해보는 시간을 갖게 되었습니다.

iOS에서 동시성 프로그래밍에 대해 살펴보기 전 먼저 알아야할 개념들부터 정리해보도록 하겠습니다.

프로세스

하나의 프로그램이 메모리 상에서 실행되는 작업 단위입니다.

스레드

하나의 프로세스 내에서 실행되는 작업흐름의 단위로 프로세스가 시작하는 동시에 동작하는 스레드를 메인 스레드라하고 이외의 추가로 생성되는 스레드를 서브 스레드라 부릅니다. 보통 하나의 프로세스는 하나의 스레드를 갖지만 둘 이상의 스레드를 동시에 실행할 수도 있고 이를 우리는 멀티스레딩이라고 합니다.

그럼 이제 비동기, 동시성 그리고 병렬성에 대해 정리해보도록 하겠습니다.

비동기 프로그래밍

비동기 프로그래밍이란 프로그램의 주 실행 흐름에서 특정 작업을 위해 프로그램이 멈추고 해당 작업이 끝날 때까지 기다리는 것이 아니라 해당 작업은 별도의 공간에 맡겨둔 뒤 결과를 기다리지 않고 주 실행 흐름을 방해하지 않고 그대로 흐름을 이어가도록 가능케 하는 병렬처리 방식입니다.

동시성 프로그래밍

말 그대로 동시에 여러 프로그램을 돌리는 것이 아닌 그렇게 보이게끔 하는 기법으로 시간을 분할하여 스레드들에게 서로 번갈아가며 제공하여 실행되게끔 하는 방식입니다. 코어에 상관 없이 실행 가능한 기법으로 싱글 코어에서도 멀티스레딩을 가능케 합니다.

병렬성 프로그래밍

동시성 프로그래밍과 다르게 동시에 돌아가는 것처럼 보이는 것이 아닌 실제로 동시에 실행되는 것을 의미합니다! 멀티 코어에서 멀티 스레드를 동작시키는 방식으로 데이터 병렬성과 작업 병렬성으로 나뉘게 됩니다.

데이터 병렬성 - 처리해야 할 데이터를 나누어 나누어진 데이터들을 병렬 처리하여 작업을 빠르게 수행하는 기법
작업 병렬성 - 서로 다른 작업을 병렬 처리하는 기법

동시성과 병렬성 차이

동시성 프로그래밍과 병렬성 프로그래밍 모두 비동기적으로 구현할 수 있습니다. 하지만 둘은 다음과 같은 차이가 존재합니다.

	동시성	병렬성
개념	논리적	물리적
동작 가능 환경	싱글코어, 멀티 코어	멀티 코어

병렬성 프로그래밍은 멀티 코어 환경에서만 동작 가능합니다.

이젠 iOS에서 동시성 프로그래밍을 어떻게 지원하는지에 대해 알아보도록 하겠습니다.

OperationQueue? DispatchQueue ?

저는 사실 iOS 공부를 하면서 Concurrency한 작업을 진행할 때 DispatchQueue만을 사용해왔습니다. 사실 어떠한 이유가 있어서 이것을 사용했다기보단 제가 독학을 하면서 보고 공부한 유투버들이나 예제에서 모두 DispatchQueue를 사용했었기 때문입니다.

하지만 이번에 부스트코스를 통해 학습을 진행하면서 OperationQueue에 대해 알게 되었고 이 둘에 어떠한 차이점이 있는지 궁금하였습니다.

그래서 이 둘의 차이점에 대해 공부를 해보았고 이 둘의 차이점에 대해 보다 확실히 이해하게 되었습니다.

이 둘의 차이점에 대해 쉽게 설명된 글이 있어 해당 글을 인용해 둘의 차이점을 간략하게 소개하겠습니다.

Operation과 OperationQueue는 NSOperation과 NSOperationQueue로 iOS2에서 처음으로 소개되었고, Grand Central Dispatch 줄여서 GCD는 iOS4에서 처음으로 소개되었습니다. 이 둘은 동시성을 지원하기 위해 작업 단위를 캡슐화하여 실행에 넘기는 동작을 하도록 설계되었습니다. 이렇게 두 api의 목적이 같기 때문에 개발자들은 종종 어느 것을 사용해야 하는지 헷갈려 하기도 합니다.

언제 어떤 api를 사용해야 하는지 설명하기 전에 이 둘의 주요 차이점에 대해 먼저 이야기 해보도록 하겠습니다.

What Sets Them Apart

애플은 Operation이 GCD 위에서 동작하게끔 설계하였습니다. 그러므로 Operation은 GCD를 상위 수준으로 추상화한 api라고 할 수 있습니다. 즉 Operation을 사용하는 것은 은연중에 GCD를 사용하는 것과 같습니다.

GCD는 시스템의 유닉스 레벨의 수준에서 직접적으로 상호작용하는 저수준의 C api입니다. 반면 Operation은 Objective-C api입니다. 그렇기 때문에 Operation은 보다 저수준에서 동작하는 GCD보다 상대적으로 느릴 수 밖에 없습니다.

Benefits of Operation

Operation이 GCD 위에서 만들어졌다는 사실에 Operation만이 제공하는 것이 무엇이 있는지 궁금하실 겁니다. 이러한 몇 가지 차이점으로 인한 이점은 Opertation을 선택하도록 하는 요소가 되기도 합니다.

Dependencies

Operation은 의존성을 제공합니다. 의존성을 제공한다는 것은 개발자가 일련의 작업에 순서를 정할수 있다는 것을 의미하고 하나의 작업이 다른 작업에 의존성을 갖고 있다면 이 작업은 해당 작업들이 모두 끝난 후에 작업을 시작할 수 있습니다.

Observable

Operation과 OperationQueue 클래스는 KVO를 통해 관찰될 수 있는 프로퍼티를 제공합니다. 이러한 사실로 우리는 작업들의 상태를 모니터링할 수 있습니다.

Pause, Cancel, Resume

Operation들은 정지,취소 그리고 재시작될 수 있습니다. GCD에 작업을 할당한다면 해당 작업에 대한 어떠한 통제권도 갖지 못합니다. 이러한 관점에서 Operation이 보다 작업의 Life cycle에 대한 유연함을 제공한다는 것을 알 수 있습니다.

단 작업을 대기열에 추가한 것 자체는 되돌릴 수 없습니다.

Control

OperationQueue 역시 DispatchQueue에 비해 몇 가지 이점을 갖고 있는데요. 그 예로는 대기열에 들어갈 수 있는 작업의 숫자를 지정함으로써 동시에 수행될 수 있는 작업의 수를 지정할 수 있습니다. 이를 통해 동시에 실행되는 작업의 갯수와 이들의 순서를 조작할 수 있습니다.

When to Use Which

일반적으로 애플은 개발자들에게 보다 고수준의 추상화된 api를 사용할 것을 권장합니다. 즉 Operation을 보다 권장하는 것이죠.

그렇다면 애플은 왜 보다 고수준의 api를 사용할 것을 권장하는 것일까요? 애플은 새로운 iOS 버전의 출시마다 운영체제의 효율을 증가시키기 위해 프레임워크와 라이브러리를 최적화하는 작업을 수행합니다. 이러한 작업은 보통 저수준의 api의 영향을 주곤 합니다. 심지어 이러한 저수준의 api 위에 존재하는 고수준의 api도 이러한 작업에 영향을 받곤 합니다.

그렇다면 GCD의 사용을 지양햐야 하는 것일까요? 이는 개발자의 선택에 따릅니다. 많은 개발자들이 GCD를 사용하기도 하고 Operation과 GCD를 같이 사용하기도 합니다.

When to Use `Operation`

위에서 언급한 의존성을 이용한 작업의 순서를 결정할 수 있는 점이 GCD에게는 없는 강력한 이점 중 하나입니다. 즉 어떠한 작업들의 순서를 지정해줄 필요가 있다면 Operation을 사용하는 것이 바람직합니다. 하지만 짧은 시간안에 수십개의 작업을 생성하야할 경우에는 Operation의 내재된 오버헤드로 인한 성능 문제로 이어질 수 있습니다.

When to Use GCD

GCD는 Operation을 사용하여 일련의 작업들을 수행하기 위한 코드에 비해 적은 양의 코드로도 같은 행위를 할 수 있습니다. GCD가 순서가 아예 없는 것은 아닙니다. 기본적으로 GCD는 FIFO 형태의 하나의 작업 대기열을 갖고 있기 때문에 들어온 순서대로 작업을 처리할 수 있습니다. 또한 이들을 들어온 순서에 상관없이 Concurrent하게 작업을 진행할 수도 있습니다. 이렇게 특정 작업의 순서를 지정해주는 것처럼 Operation이 갖고 있는 이점을 사용하는 것이 아니라면 GCD를 사용해도 무방합니다.

마무리

오늘은 이렇게 iOS에서 동시성 프로그래밍을 지원하는 api에 대해 살펴보았고 그들의 차이점도 같이 살펴보았습니다. 오늘은 간략하게 다른 블로그의 글을 번역하고 이를 요약한 것이어서 내용을 가볍게 훑어보기에는 좋았습니다. 하지만 가볍게 이해하는 것은 잘못된 지식으로 이어질 수 있기 때문에 다음에는 Concurrency Programming Guide 문서를 정독해보고 이를 통해 보다 개념을 확실히 하고 학습한 내용을 정리해보는 시간을 갖도록 하겠습니다. 감사합니다.

참고자료

[Swift] 프로토콜과 제네릭 그리고 열거형

군옥수수수 — Fri, 13 Jul 2018 12:00:34 +0900

[Swift] 프로토콜과 제네릭 그리고 열거형

Swift를 활용한 프로그램 설계 규칙에 있어서 메소드 인터페이스가 동일하면 프로토콜을 활용하고 로직은 동일하나 타입만 다르다면 제네릭을 활용하는 것이 좋은 설계 규칙 중 하나로 뽑힙니다. 오늘은 프로토콜(Protocol)과 제네릭(Generics)을 같이 사용해보고 이를 통해 배운점을 기록해보고자 합니다.

다음은 프로토콜에 관해 제가 작성한 포스팅들입니다.

다음은 제네릭을 사용해 iOS에서 코드를 줄여본 경험을 작성한 포스팅입니다.

[ios] 제네릭을 이용해 코드 중복 제거하기

프로토콜과 제너릭에 대한 기본적인 지식이 필요로 하는 포스팅입니다.

프로토콜(Protocol) 과 제네릭(Generics)

인터페이스가 동일하다면 프로토콜로 이를 묶어서 추후에 같은 인터페이스를 필요로 하는 타입에 통일된 인터페이스를 제공할 수 있습니다. 그 안의 로직은 다양할 수 있습니다.

그리고 구현 로직은 완전 동일하지만 타입만 다르다면 우리는 이것을 제네릭을 이용해 코드의 중복을 방지할 수 있습니다. 프로토콜에 대한 지식이 있으신 분들은 프로토콜도 하나의 타입이라는 것도 알고 계실 겁니다. 그래서 저는 이 둘을 활용한다면 보다 코드를 추상화할 수 있고 중복을 제거할 수 있을 것이라고 생각하여 이 둘을 함께 사용해보았습니다.

저는 같은 분류에 속하나 서로 다른 성격(타입)을 갖는 두 enum을 하나의 분류라는 의미에서 동일한 프로토콜을 준수하도록 하였습니다. 그리고 같은 분류 속에서 속하는 이 둘은 동일한 로직을 갖기 때문에 이 둘을 제네릭을 활용하여 코드의 중복을 제거해보고자 하였습니다.

Implementation

enum 타입을 추후에 제네릭으로 묶어 사용하기 위해 GroupProtocol은 RawReresentable을 체택합니다. 그리고 GroupProtocol을 준수하는 두 enum 타입은 RawRepresentable을 이미 준수하고 있는 타입이기 때문에 따로 RawRepresentable 프로토콜을 추가로 구현해주지 않아도 됩니다.

RawRepresentable

그리고 이 enum들의 동일한 로직을 제네릭으로 묶어 놓은 구조체를 다음과 같이 작성하였습니다.

AEntity와 BEntity 모두 RawValue가 String 이므로 이들의 로직을 묶어준 ConmonLogic 에서 사용하게 될 T 는 RawValue가 String 인 타입에 한정해야 합니다. 이렇게 구조체를 정의할 때 타입이 한정된 T는 구조체 안에서 따로 어떠한 제한을 걸어 사용할 필요 없이 바로 사용할 수 있게 됩니다.

이렇게 T는 RawRepresentable을 체택한 GroupProtocol을 체택하였으므로 T를 반환하는 메소드를 다음과 같이 작성할 수 있습니다.

여기서 T를 생성할 때 사용되는 rawValue인 something은 무슨 타입이 될까요? 바로 String 입니다. 다른 타입이 될 순 없습니다. 왜냐하면 CommonLogic 구조체를 정의할 때 T의 RawValue 타입을 String으로 한정해주었기 때문입니다.

그리고 만일 프로토콜 내부에서 associatedtype이 선언되어 있거나 Self가 사용된다면 그 프로토콜은 제네릭의 한정 프로토콜으로만 사용할 수 있습니다. 그 뜻이 무엇인지 코드로 살펴보도록 하겠습니다.

위와 같이 GroupProtocol을 준수하는 타입 그 자체를 의미하는 Self가 GroupProtocol 안에서 사용된다면 다음과 같은 상황에서 에러 메시지를 볼 수 있을 것입니다.

Self 키워드는 공식 문서에서 다음과 같이 설명하고 있습니다.

In that context, Self refers to the eventual type that conforms to the protocol.

이렇게 GroupProtocol을 직접적으로 사용할 수 없기 때문에 우리는 코드를 다음과 같이 수정해주어야 합니다.

마무리

제네릭을 사용하는 것은 아직 많이 낯섭니다. 그렇기 때문에 사용할 때마다 에러 메시지와 마주치게 되지만 이러한 에러들을 수정해나가게 되면서 제네릭의 강력함에 매번 놀라곤 합니다. 제네릭을 보다 적극적으로 활용하여 코드를 깨끗하게 유지하는 습관을 들여야 할 것 같습니다. 감사합니다.

참고자료

[ios] UIViewController LifeCycle - 추가

군옥수수수 — Fri, 6 Jul 2018 21:13:22 +0900

[ios] UIViewController LifeCycle - 추가

안녕하세요. 오늘은 다시 기본으로 돌아가 개념을 확실히 다잡기 위해 이전에 다루었 UIViewController LifeCycle 글에 내용을 조금 더 추가해보았습니다.

기존의 글에서는 단순히 UIViewController의 Life Cycle 관련 메소드들을 소개하는 수준이었습니다. 오늘은 UINavigationController 위에서 UIViewController들을 호출해가며 실제로 서로 다른 UIViewController들의 메소드들이 어떠한 순서로 호출되는지 살펴보도록 하겠습니다.

먼저 UINavigationController는 루트 뷰 컨트롤러를 하나 갖고 있습니다. UINavigationController에서 뷰 컨트롤러들의 Life Cycle은 어떻게 돌아갈까요?

루트 뷰 컨트롤러에서는 viewWillDisappear가 호출될 것 같고...! 올라오는 뷰 컨트롤러에서는 나타나는 viewWillAppear가 호출될 것 같은데 정확한 이들 메소드의 호출 순서는 어떻게 될까요?

이를 이해하기 위해서는 UINavigationController는 기본적으로 스택 (Stack)의 자료구조로 뷰 컨트롤러를 관리한다는 사실을 알고 있어야 합니다.

이렇게 UINavigationController 안의 뷰 컨트롤러들은 팝(Pop)되기 전까지 메모리에서 사라지지 않습니다. 그 말인즉슨 팝이 되야 메모리에서 사라진다는 것이고 그제서야 deinit 메소드가 호출됩니다.

그럼 이제 본격적으로 푸시되고 팝 될때 두 뷰 컨트롤러는 어떤 단계를 어떤 순서로 서로 충돌되지 않게끔 자신들의 뷰를 화면에 띄우고 사라지는지 직접 다이어그램으로 살펴보도록 하겠습니다.

직접 메소드들을 호출해가며 확인하시는게 이해하는데 도움이 되실 것입니다.

먼저 푸시되는 상황을 살펴보겠습니다.

push

UIViewController-1이 먼저 보이는 뷰 컨트롤러고 이는 init 부터 viewDidAppear까지 위에 나열된 순서대로 메소드들을 호출해가며 화면에 나타납니다. 그리고 여기서 푸시를 하게 되면 그 위로 UIViewController-2가 올라오게 됩니다. 이때 푸시 될 UIViewController-2를 메모리에서 불러오는 작업을 먼저 수행합니다. 그 과정이 바로 init 부터 viewDidLoad까지입니다.

지금까지는 단순히 메모리로부터 불러오고 이들을 조합하고 위치를 조정하는 단계였고 아직 화면에 보이는 상태는 아닙니다. 그리고 사라질 UIViewController-1가 "사라질 것이다"라는 메소드를 호출하고 UIViewController-2는 "나타날 것이다"라는 메소드를 호출합니다.

마지막으로 UIViewController-1이 "사라졌다" 라는 메소드를 호출하고 이를 확인 후 UIViewController-2도 "나타났다"라는 메소드를 호출할 것입니다.

이렇게 서로 메소드를 교차하며 호출하여 충돌을 피해서 화면에서 사라지고 화면에서 나타나게 되는 것입니다. 여기서 주목해야할 것은 UIViewController-1의 deinit 메소드가 호출되지 않는다는 것입니다. 왜냐하면 단순히 가려진 것이지 메모리에서 사라진 것은 아니기 때문입니다.

그렇다면 팝이 될 때는 어떨까요?

pop

역시 사라지는 쪽에서 "사라질 것" 이라고 의사를 내비치는 것입니다. 그리고 위와 같은 순서로 메소드들이 호출되며 역시 팝이 되는 상황도 충돌을 피하며 사라지고 나타나는 것입니다.

여기서 주목해야할 점은 UIViewController-2는 UINavigationController의 스택 안에서 벗어나는 팝 연산이고 메모리에서 사라지기 때문에 deinit 메소드가 호출된다는 점입니다.

그리고 이전 포스팅에서 loadView가 호출되는 시점에서 IBOutlet과 IBAction들이 생성되고 연결된다고 언급했습니다.이 역시 직접 메소드들을 호출해가며 확인해보았습니다. 그 결과는 다음과 같습니다.

마무리

오늘은 이렇게 예전에 학습했고 포스팅까지 했던 UIViewController의 LifeCycle을 다시 살펴보고 직접 호출해가며 개념을 다잡는 시간을 가졌습니다. 감사합니다.

[Swift] Functor and Monad in Swift

군옥수수수 — Thu, 5 Jul 2018 15:23:40 +0900

[Swift] Functor and Monad in Swift

Swift의 Monad를 소개하기 위해 작성된 포스팅으로 Monad를 단독으로 다루는 것보다 Functor와 함께 이야기하는 것이 이해에 도움이 된다고 생각하여 Functor와 Monad를 이해하기 위한 몇몇 개념과 함께 이들을 알아보도록 하겠습니다.

Context

컨텍스트(Context)와 컨텐트(Content)의 관계는 다음과 같습니다.

컨텍스트는 컨텐트를 담고있는 형태로 옵셔널(Optional)을 예로 들면 Optional(2)에서 Optional은 컨텍스트가 2 는 컨텐트가 됩니다. 만일 옵셔널안에 값이 존재하지 않는다면 컨텍스트만 존재하는 꼴이 되겠죠.

이렇게 컨텍스트는 무언가를 담고있는 것을 의미합니다. 이렇게 무엇을 담고있다는 의미에서 컨테이너(Container) 역시 컨텍스트의 일종으로 볼 수 있습니다. 그럼 그 컨테이너를 살펴보도록 하겠습니다.

Container

우리가 흔히 사용하는 자료구조인 Array, Set 그리고 Dictionary와 같은 자료구조들도 일종의 컨테이너라고 할 수 있습니다. 이들은 한 개 이상의 원소를 가질 수 있는 컨테이너들로 쉽게 컨테이너라는 개념이 연상될 것입니다. 하지만 이들만이 컨테이너라고 할 수 있을까요?

위에서 언급했던 옵셔널도 컨텍스트의 일종이라고 하였습니다. 그렇다면 옵셔널은 컨테이너이기도 할까요? 그렇습니다. 옵셔널도 컨테이너의 한 종류로 그 컨테이너 안에는 값이 존재할 수도 존재하지 않을 수도 있습니다. 즉 두 가지의 경우를 담고 있는 컨테이너라고 이해할 수 있습니다.

Map

우리는 컨테이너에 매핑(Mapping)이라는 연산을 수행할 수 있습니다. 매핑을 굳이 직역하자면 사상이라 할 수 있습니다.

컨테이너의 원소 값 각각에 특정한 변형을 적용하는 것을 변형을 사상한다고 표현할 수 있습니다.

다음은 이러한 매핑 연산의 예시입니다.

[1, 2, 3, 4] --- [2,4,6,8]
["1", "2", "3"] --- [1, 2, 3]
["Harry", "Joe", "David"] --- ["My name is Harry", "My name is Joe", "My name is David"]

이런 매핑은 내부 원소의 값의 변형만 일어납니다. 그 원소를 담고있는 컨테이너의 변형은 일어나지 않습니다. 그말인즉슨 Array에 매핑 연산을 진행하였다고 Array가 Dictionary가 되는 컨테이너의 변형은 일어나지 않는다는 것입니다.

이렇게 값에 변형을 매핑할 수 있는 모든 것들을 Functor라고 합니다. 그렇다면 Functor는 컨테이너와 같은 의미일까요? 이에 대해서는 같다는 것이 지배적인 의견인 것 같으나 완전히 같지는 않다는 의견도 존재합니다.

Functor

Functor는 위에서 언급했듯이 변형을 사상할 수 있는 모든 것들을 말합니다. 이렇게 Functor에서 매핑 연산이 일어나는 과정을 다이어그램으로 표현하자면 다음과 같습니다.

여기서 주목해야 할 점은 매핑으로 변형된 값은 다시 Functor로 감싼 후 반환된다는 것입니다. 그리고 Swift에서 매핑의 대표적인 메소드가 바로 map 입니다.

그리고 저는 Functor로써의 옵셔널에 주목해보려 합니다. 옵셔널 역시 내장 메소드로 map을 갖고 있습니다. 옵셔널에서 map 메소드를 지원하지 않는다고 가정해보도록 하겠습니다. 그리고 서버로부터 데이터를 받아와 이를 UILabel에 출력해주고자 할 때 우리는 다음과 비슷한 코드로 이를 구현할 것입니다.

단순히 이름을 출력해주는 것인데 if-let 이나 guard-let 과 같은 코드 때문에 코드가 길어지게 되죠. 하지만 옵셔널도 Functor로써 map 메소드를 지원하기 때문에 우리는 다음과 같이 코드를 길이를 줄일 수 있습니다.

그럼 대체 map 메소드가 어떻게 구현되어 있기에 이러한 코드가 가능한 것일까요? 이를 이해하기 위해선 옵셔널이 어떻게 동작하는지 알고 있어야 합니다. 옵셔널은 다음과 같이 enum을 사용하여 구현되어 있습니다.

값이 있는 경우와 없는 경우로 나뉘어 있죠. 옵셔널의 map 메소드도 역시 enum을 활용하였습니다. 코드로 살펴보겠습니다.

옵셔널의 map 메소드는 Wrapped 타입을 파라미터로 받고 U 타입을 반환하는 함수 transform을 파라미터로 받습니다. 그리고 map 메소드 자체는 U? 타입을 반환합니다.

그리고 switch 문에서 self, 즉 map 메소드를 호출한 옵셔널 타입의 값을 검사하므로 map 메소드를 호출한 옵셔널 컨텍스트 안에 값이 존재한다면 해당 값을 컨텍스트로부터 추출하여 파라미터로 받아온 transform 함수에 넘겨 값을 처리합니다. transform 메소드의 반환 결과는 U 타입이지만 옵셔널 map의 반환 타입이 U? 이므로 컴파일러가 자동으로 U?로 감싸 반환합니다. 반면에 map 메소드를 호출한 옵셔널 타입의 변수에 값이 존재하지 않는다면 nil 값을 반환하는 것입니다.

그렇기 때문에 위의 예제에서 userName이 map 메소드를 호출하게 되면 다음과 같은 과정을 거치게 됩니다.

userName에 값이 존재하는지 switch 문을 통해 검사
값이 존재하므로 이를 추출하여 파리미터로 넘어온 함수 greeting(_:) 함수에 파라미터로 추출한 값을 넣는다.
함수의 실행 결과로 "안녕하세요 \(name)님"을 반환하고 map 메소드는 이 결과를 Optional("안녕하세요 \(name)님") 으로 반환
결과가 label.text에 담김. (label.text의 타입은 String?)

그럼 위의 과정과 Functor에서 매핑이 진행되는 과정을 다시 한번 살펴보고 다음 코드를 봐주시기 바랍니다.

number의 타입은 무엇일까요?

Int? 라고 예상하셨나요? 틀렸습니다!

정답은 바로 Int??로 Optional<Optional<Int>>입니다. 이러한 과정이 나오게 된 과정을 살펴보기 전 명심해야할 것은 위에서 언급했던 "여기서 주목해야 할 점은 매핑으로 변형된 값은 다시 Functor로 감싼 후 반환된다는 것입니다." 문장입니다.

예제에서 Functor는 옵셔널입니다. 그리고 Int($0)의 반환 결과 역시 옵셔널 타입입니다. 즉 위의 다이어그램에서 Apply Function의 결과로 옵셔널 타입의 값이 반환되고 그 값을 옵셔널 Functor안에 넣어 반환하기 때문에 최종 결과가 Optional<Optional<Int>>가 되는 것입니다.

이를 코드로 옵셔널 map의 코드와 함께 살펴보면 Wrapped 타입은 String이 됩니다. 그리고 Int(_:) 의 반환 타입은 Optional<Int> 타입이죠. 그리고 코드의 transform 반환 타입이 U 이므로 U == Optional<Int> 관계를 갖는 것입니다. 그리고 map 메소드의 최종 반환 타입이 U? 이기 때문에 U? == Optional<Optional<Int>>이므로 최종 반환 결과 값의 타입은 Optional<Optional<Int>>가 되는 것입니다.

그렇다면 모나드(Monad)란 무엇일까요?

Monad

모나드는 Functor의 일종입니다. 모나드를 쉽게 설명하자면 flatMap 연산이 가능한 모든 것들을 우리는 모나드라고 부를 수 있습니다.

모나드를 값이 있을 수도 있고 없을 수도 있는 상태의 컨텍스트를 갖는 Functor의 일종이라고 설명되곤 하는데 이 부분에 대해서는 아직 저 스스로 이해가 조금 더 필요한 것 같습니다.

하지만 단순하게 생각해서 값이 있을 수도 없을 수도 있는 컨텍스트라하면 옵셔널은 단번에 따오릅니다. 맞습니다! 옵셔널도 모나드에 속합니다. 그리고 모나드를 다음과 같이 설명하기도 합니다.

" Monads apply a function that returns a wrapped value to a wrapped value. "

저는 이를 " 모나드는 포장된 값에 포장된 값을 반환하는 함수를 적용시킨다. " 라 이해를 하였습니다.

그렇다면 먼저 옵셔널에서의 flatMap과 map의 코드를 함께 살펴보도록 하겠습니다.

map in Optional

flatMap in Optional

둘의 차이점이 보이시나요? 바로 transform 메소드의 반환 타입입니다.

그렇다면 다음의 코드에서 mapResult와 flatMapResult의 타입은 어떻게 될까요?

결과는 다음과 같습니다.

Optional<Optional<Int>>
Optional<Int>

mapResult의 타입이 Optional<Optional<Int>>인 이유는 위에서 살펴보았습니다. 그렇다면 flatMapResult의 타입은 왜 Optional<Int>일까요? map과 flatMap의 차이점은 transform 메소드의 반환 타입이 다르다고 말씀드렸습니다.

예제의 Int(_:) 의 반환 타입은 Optional<Int> 입니다.그리고 transform 의 반환 타입은 U? 이기 때문에 U? == Optional<Int>가 되는 것입니다. 마지막으로 flatMap의 최종 결과 반환 타입은 U?이기 때문에 Optional<Int>가 되는 것입니다. 이렇게 " 모나드는 포장된 값에 포장된 값을 반환하는 함수를 적용시킨다. " 라는 뜻을 코드로써 어떻게 구현되어 있는지를 확인할 수 있었습니다.

한 번 더 예를 들어 다음과 같이 짝수라면 반으로 나누는 메소드와 이를 연속으로 호출한다면 그 모습은 다음과 같을 것입니다.

Swift 4.1부터 Array과 같이 Sequence한 원소를 갖는 컨테이너에서 flatMap은 deprecated 되었고 compactMap으로 대체되었습니다.

옵셔널이 아닌 모나드, 즉 Array과 같이 여러 원소를 갖는 컨테이너에서 compactMap은 내부 컨텍스트의 값도 추출할 수 있습니다. 이를 위해 Array에서 적용되는 compactMap에 대해 알아보도록 하겠습니다.

결과를 보시면 내부 컨텍스트의 값을 추출한다는 것을 단번에 이해하실 수 있으실 겁니다.

이를 이해하기 위해서는 Array 에서의 compactMap이 내부적으로 어떤 원리로 작동하는지 이해하고 있어야 합니다.

여러 원소를 갖는 모나드에서 map은 단순히 클로저를 수행하고 결과를 그대로 반환하지만 위의 코드에서와 같이 compactMap은 내부 컨텍스트 (예제에선 옵셔널)의 값을 추출하여 담아 반환합니다.

마무리

사실 한 기업의 면접에서 "모나드는 무엇인가요?" 라는 질문을 받았었습니다. 하지만 스위프트를 처음 공부할 때 이해하기 힘들어 덮어두고 넘어갔던 내용이었던지라 식은땀을 한 바가지 흘렸었죠. 물론 면접의 결과는 물 보듯 뻔했습니다.

그래서 "제대로 이해하보자" 라고 생각하고 이렇게 공부를 하고 기록을 해보았습니다. 사실 지금도 100% 이해했다고 하기는 힘들 것 같습니다. 하지만 어렴풋이 감이 생겼고 이를 지속적으로 발전시켜가도록 노력해야겠습니다. 감사합니다.

참고자료

[ios] Handling UIKit Gestures

군옥수수수 — Thu, 28 Jun 2018 15:53:46 +0900

Handling UIKit Gestures

Gesture recognizer를 사용하는 것은 뷰에서 발생하는 Touch나 Press 이벤트를 다룰수 있는 가장 간단한 방법입니다. 어떤 뷰든간에 한 개 혹은 복수 개의 Gesture에 대한 recognizer를 붙일 수 있습니다. Gesture recognizer는 뷰 위에서 발생하는 일련의 패턴이 존재하는 이벤트들 ( Double-Tap, Swipe, Pinch 등등 )을 처리하기 위해 Target-Action 패턴을 사용하고 이벤트가 발생하면 Target 객체에 이러한 사실을 전달하여 해당 이벤트를 처리할 수 있는 액션 메소드를 호출합니다.

Gesture Recognizer에는 두 종류가 있습니다.

불연속 gesture recognizer
- 이벤트를 인식한 후 액션 메소드를 한번만 호출
- UITapGestureRecognizer
연속 gesture recognizer
- 최초 이벤트 인식 후 이벤트의 변화를 추적하며 액션 메소드를 변화에 맞춰 호출
- UIPanGestureRecognizer

Configuring a gesture recognizer

Gesture recognizer를 구성하기 위해서는

스토리보드에서 Gesture recognizer를 뷰 위에 드래그하여 올려 놓습니다.
액션 메소드를 구현합니다.
액션 메소드와 Gesture recognizer를 연결합니다.

코드로 이를 구현할 때는 addGestureRecognizer(_:)를 사용합니다.

Responding to Gestures

액션 메소드를 통해 gesture를 적절히 처리해줍니다. 위에서 언급했듯이 불연속적 gesture는 버튼과 같이 한 번의 gesture에 대해 액션 메소드는 한번만 호출됩니다. 연속적 gesture에 대해서는 이벤트를 추적하고 이에 맞게 액션 메소드 역시 여러번 호출됩니다.

UIGestureRecognizer에는 state라는 프로퍼티가 있고 이를 활용하여 액션 메소드를 구성할 수 있습니다. 연속 Gesture recognzier에선 .began, .changed, .ended 그리고 .cancelled 를 사용할 수 있습니다. 예를 들어 .changed 상태에선 뷰의 속성을 임의로 변경시키고 .ended에서는 이를 확정 짓는 등의 행위를 할 수 있습니다.

UIGestureRecognizer

Gesture recognizer는 gesture를 인식하는 로직과 그에 따른 행위를 분리시켜 놓습니다. 그리고 gesture를 인식하거나 인식하고 있는 gesture의 변화가 감지되면 해당 사실을 지정된 객체(Target Object)에 전달합니다.

UIGestureRecognizer의 서브 클래스들로는 다음 클래스들이 있습니다.

UITapGestureRecognizer
UIPinchGestureRecognizer
UIRotationGestureRecognizer
UISwipeGestureRecognizer
UIPanGestureRecognizer
UIScreenEdgePanGestureRecognizer
UILongPressGestureRecognizer

UIGestureRecognizer 클래스는 위의 서브 클래스들에서 정의되는 공통되는 행위에 대해 정의하고 있습니다. 또한 UIGestureRecognizerDelegate 프로토콜을 준수하고 있는 객체와도 상호작용이 가능하기 때문에 이들을 활용하여 보다 섬세한 행위들을 정의해줄 수 있습니다.

또한 액션 메소드로는 두 가지 유형을 사용할 수 있습니다.

@IBAction func myActionMethod()
@IBAction func myActionMethod(_ gesture: UIGestureRecognizer)

두 번째 유형처럼 UIGestureRecognizer나 그의 서브 클래스를 인자로 받는다면 gesture의 보다 상세한 정보들을 사용할 수 있습니다. 예를들어 UIRotationGestureRecognizer에 대한 액션 메소드로 인자를 받는다면 회전 각도에 대한 정보를 알 수 있습니다.

이제 Gesture recognizer에서 중요한 부분에 대해 살펴보도록 하겠습니다. 그것은 바로 addGestureRecognizer(_:) 메소드로 뷰와 관계를 갖는 Gesture recognizer는 뷰의 Responder chain에 속하지 않는다는 것입니다.

터치 이벤트를 예를들어 설명하자면 만일 UITapGestureRecognizer의 지정 객체인 뷰 위에서 터치가 발생하면 윈도우는 터치 이벤트를 해당 뷰로 전달하기 전에 먼저 Gesture recognizer로 전달합니다.

만일 등록한 Gesture recognizer와 맞지 않은 이벤트라면 해당 이벤트는 온전히 터치가 발생한 뷰로 전달됩니다. 하지만 Gesture recognizer에 맞는 gesture라면 해당 이벤트는 recognizer에 의해 처리가 되고 뷰로는 전달되지 않습니다. 이를 테스트해보기 위해 직접 코드를 작성해보았습니다.

버튼에 더블 탭 Gesture recognizer를 등록했을 경우입니다.

버튼을 한번만 클릭하면 결과물은 다음과 같습니다.

UIRESPONDER : Button Touch Began
UIRESPONDER : Button Touch Ended

당연한 결과물이죠? 터치 이벤트는 등록된 Gesture recognizer의 패턴과 일치하지 않으므로 터치 이벤트는 온전하게 뷰로 전달이 됩니다. 하지만 더블 클릭을 하면 어떻게 될까요?

UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer
UIRESPONDER : Button Touch Cancelld

터치가 일어나면 우선 손가락이 화면에 처음 접촉한 순간에 대한 이벤트는 정상적으로 전달이 됩니다. 그렇기 때문에 touchesBegan 메소드는 정상적으로 호출이 되는 것입니다. 하지만 그 후 더블 클릭이 일어나면 (빠르게 같은 좌표에 대한 손가락의 접촉과 때어짐이 두번 발생) 이에 대한 이벤트는 doubleTapGesture로 전달이 되어 처리가 되고 UIResponder로 전달되어야 하는 이벤트는 취소 처리가 되는 것입니다.

이런 이벤트 전달의 흐름은 UIGestureRecognizer의 프로피티인 cancelsTouchesInView, delaysTouchesBegan 그리고 delaysTouchesEnded 값에 의해 결정됩니다.

cancelsTouchesInView - Bool 타입의 프로퍼티로 default 값은 true입니다. Gesture Recognizer가 gesture를 인식하면 나머지 터치 정보들을 뷰로 전달하지 않고 이전에 전달된 터치들은 취소됩니다. (touchesCancelled) 하지만 만일 이 값을 false로 할당한다면 gesture를 인신한 후에도 터치 정보를 뷰에 전달하게 됩니다. 이를 코드와 출력 결과물로 살펴보도록 하겠습니다.

UIGestureRecognizer 의 cancelsTouchesInView 프로퍼티는 기본적으로 true이기 때문에 이에 대한 출력 결과물은 다음과 같습니다.

UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer
UIRESPONDER : Button Touch Cancelld

하지만 singleTapGesture.cancelsTouchesInView = false 코드를 작성하면 결과물은 다음과 같습니다.

UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer
UIRESPONDER : Button Touch Ended

터치가 끝났다는 정보가 뷰로 전달되었다는 것을 확인할 수 있습니다.

delaysTouchesBegan - Bool 타입의 프로퍼티로 직역하자면 터치 최초 발생 이벤트 전달을 늦춘다는 의미입니다. defatult 값은 false입니다. default 값이 false이기 때문에 터치가 최초 발생한 순간 해당 gesture가 recognizer의 패턴과 하는 것과 무관하게 터치 시작 이벤트가 뷰로 전달되고 touchesBegan 메소드가 호출됩니다.

UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer
UIRESPONDER : Button Touch Cancelld

하지만 값이 true라면 recognizer가 패턴을 검사하는 동안에는 터치의 최초 발생 이벤트를 뷰로 전달하지 않고 보류합니다. 그리고 gesture가 recognizer의 패턴과 일치된다고 판단되면 해당 이벤트는 버려지고 (discard) 뷰로 전달되지 않습니다. 이렇게 애초에 최초 터치 이벤트조차 뷰로 전달되지 않으니 touchesCancelled도 호출되지 않는 것입니다.

UIGestureRecognizer : UITapGestureRecognizer

하지만 어디까지나 delay (지연)이기 때문에 singleTapGesture가 올라가있는 뷰 위에서 손가락을 최초 터치 후 때지 않고 기다리면 터치의 시작 이벤트는 뷰로 전달되고 touchesBegan 메소드는 호출됩니다.

delaysTouchesEnded - delaysTouchesBegan과 유사한 역할의 프로퍼티로 터치가 끝난 순간의 이벤트 전달을 지연시킬 것인지를 결정하는 프로퍼티입니다. 하지만 delaysTouchesBegan과 다르게 default 값은 true입니다. 이 프로퍼티를 사용해보기 위해 저는 더블 탭을 인지하는 doubleTapGesture를 사용하였습니다. 결과는 제가 기대한 것과는 약간 달랐습니다.

이와 같이 코드를 작성하면 저는 singleTapGesture 와 마찬가지로 touchesEnded 가 정상적으로 호출될 것으로 예상하였으나 결과물은 다음과 같았습니다.

UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer

그리고 버튼은 눌려진 상태를 유지하고 있었습니다. 즉 터치 종료 이벤트가 전달되지 않았다는 것입니다. 물론 그렇다고 취소된 것도 아닌 것이죠. 하지만 delaysTouchesEnded의 공식 문서에는 다음과 같이 설명되어 있었습니다.

Set this property to false to have touch objects in the UITouch.Phase.ended delivered to the view while the gesture recognizer is analyzing the same touches.

저는 더블 탭이 문서에서 언급하는 same touches 라고 이해를 하고 delaysTouchesEnded = false 코드를 추가로 작성해주었고 그제서야 원하는 출력 결과물을 얻을 수 있었습니다.

UIRESPONDER : Button Touch Began
UIRESPONDER : Button Touch Ended
UIRESPONDER : Button Touch Began
UIGestureRecognizer : UITapGestureRecognizer
UIRESPONDER : Button Touch Ended

Subclassing Notes

UIGestureRecognizer 를 상속받아 자신만의 Gesture recognizer를 만들 수 있습니다. 기본적으로 Gesture recognizer는 상태(UIGestureRecognizer.State)에 따른 행동을 취하는데 이러한 상태는 State machine에 의해 결정됩니다. 그렇기 때문에 UIGestureRecognizer를 상속받아 무엇을 만들 때 이런 상태 변화에 대한 정의를 명확히 해주어야 합니다. State machine에 대해서는 밑에서 보다 자세히 다루어볼 것이기 때문에 간단히만 살펴보도록 하겠습니다.

일단 연속적 gesture와 비연속적 gesture의 상태 변화 과정에는 차이가 있습니다. 우선 연속적, 비연속적 gesture와 상관없이 모든 gesture는 이벤트를 처리할 준비가 되었다는 UIGestureRecognizer.State.possible 상태로부터 시작합니다.

그리고 비연속적 gesture는 gesture 인식 성공 여부(recognized)에 따라 UIGestureRecognizer.State.ended인지 UIGestureRecognizer.State.failed 나뉘고 인식에 성공하면 Target object에 액션 메시지를 보냅니다.

연속적 gesture는 조금 더 다양한 상태의 변화를 가질 수 있습니다.

Possible ——> Began ——> [Changed] ——> Cancelled
Possible ——> Began ——> [Changed] ——> Ended

[Changed] 상태는 일어나지 않을 수도 있으며 Cancelled 혹은 Ended 상태 전에 여러번 발생할 수도 있습니다. 그리고 매 상태 변화마다 Target object에 액션 메시지를 보냅니다.

이렇게 UIGestureRecognizer를 사용하고 이해하며 이를 상속받아 자신만의 Gesture recognizer를 만들어 사용하기 위해서는 위에서 언급했던 State machine에 대한 이해가 필요합니다.

그리고 이외에도 UIGestureRecognizer 서브 클래스에서 반드시 재정의해주어야 하는 메소드는 공식 문서에 명시되어 있습니다.

About the Gesture Recognizer State Machine

Gesture recognizer는 기본적으로 State machine에 의해 동작합니다. 이런 State machine은 몇몇 중요한 행위에 대해 결정을 하는 역할을 합니다.

연속적 Gesture recognizer가 UIGestureRecognizer.State.began 상태로 들어갈 수 있는지 여부
비연속적 Gesture recognizer가 UIGestureRecognizer.State.ended 상태로 들어갈 수 있는지 여부
Gesture recognizer와 연결된 액션 메소드를 언제 호출할 것인지

UIGestureRecognizer 를 상속받아 직접 클래스를 작성한다면 적절한 시점에 State machine을 갱신해주어야 합니다. 그리고 최종 상태인 UIGestureRecognizer.State.ended , UIGestureRecognizer.State.failed, UIGestureRecognizer.State.cancelled에 다다른 이후 UIKit은 Gesture recognizer를 초기화하고 상태를초기 상태인 UIGestureRecognizer.State.possible 상태로 되돌립니다.

Managing State Transitions for a Discrete Gesture Recognizer

비연속적 Gesture recognizer를 구현한다면 state 프로퍼티의 값의 선택지는 UIGestureRecognizer.State.ended 와 UIGestureRecognizer.State.failed 두 가지가 됩니다. 만일 직접 만든 recognizer의 gesture와 들어온 gesture가 일치한다면 .ended로 그렇지 않다면 .failed로 변경시켜주어야 합니다.

인식에 성공하여 .ended 상태로 변경한다면 UIKit은 연결된 객체의 액션 메소드를 호출합니다. .failed라면 어느 것도 호출하지 않습니다.

비연속적 gesture recognizer를 구현해보는 공식 문서입니다.
Implementing a Discrete Gesture Recognizer

Managing State Transitions for a Continuous Gesture Recognizer

연속적 gesture recognizer에서 상태의 변화에는 크게 세 가지 종류로 나눠볼 수 있습니다.

최초 이벤트에 따라 UIGestureRecognizer.State.began 이나 UIGestureRecognizer.State.failed로의 상태 변화
그 이후 이벤트에 따라 UIGestureRecognizer.State.began 에서 UIGestureRecognizer.State.changed나 UIGestureRecognizer.State.failed로의 상태 변화
마지막 이벤트에 따라 UIGestureRecognizer.State.ended로의 상태 변화

흐름대로 따라가면서 살펴보도록 하겠습니다.

먼저 .possible 상태에서 gesture가 들어오고 recognizer의 패턴과 일치하는지 검사를 합니다. 일치한다면 .began 으로 상태를 갱신합니다. 만일 패턴과 일치하지 않는다면 즉시 .failed 상태로 변경해야합니다. UIKit은 한번에 하나의 Gesture recognizer만 메시지를 보내도록 허용하기 때문에 .failed 상태로 보내야 다른 Gesture recognizer들에게 그들의 gesture를 처리할 수 있는 기회가 돌아갑니다.

이렇게 초기 패턴이 일치하여 .began 상태로 들어가면 이후의 이벤트들은 .changed로 상태를 갱신합니다. 이미 .changed 상태여도 상태의 변화를 같은 값으로 갱신시키는데 이는 .changed 상태와 연관된 액션 메소드를 지속적으로 호출시키기 위함입니다.

그리고 정상적으로 gesture의 일련의 과정이 정상적으로 종료되면 .ended 상태로 갱신되고 그렇지 않으면 .cancelled 상태로 갱신됩니다.

연속적 gesture recognizer를 구현해보는 공식 문서입니다.
Implementing a Continuous Gesture Recognizer

Handling Cancellation

gesture의 취소 행위는 전화가 걸려오는 상황과 같은 시스템 이벤트에 의해 방해되었을 때 자동으로 발생합니다. 또한 이러한 취소 행위를 직접 코드로 구현할 수도 있습니다. 이러한 취소 행위는 recognizer를 만든 사람이 의도하지 않은 작업들이 발생하는 것을 막아주는 역할을 합니다.

시스템이 gesture를 취소하고나면 UIKit은 touchesCancelled 나 pressesCancelled 메소드를 호출합니다. 이러한 gesture 취소 행위가 일어나면 위에서 언급했듯이 UIGestureRecognizer.State.cancelled로 즉시 상태를 갱신시켜야 하며 이렇게 상태를 변경시켜야 UIKit이 액션 메소드를 호출할 수 있습니다.

Resetting the Gesture Recognizer State Machine

reset() 메소드를 구현하고 사용함으로써 구현한 Gesture recognizer의 상태를 초기 상태로 되돌릴 수 있습니다. 새로운 제스처가 발생하고 해당 이벤트를 전달하기 전이나 State machine의 상태가 .cancelled, .failed, ended 일 경우 UIKit은 reset() 를 호출하여 Gesture recognizer의 상태를 초기화할 뿐만 아니라 State machine을 .possible 상태로 되돌리기도 합니다. 이렇게 .possible 상태로 되돌려 놔야 새로운 이벤트를 받을 수 있기 때문입니다.

마무리

지난 시간 Responder Chain and Touch Event 포스팅에 이어 오늘은 이벤트를 다루는 다른 방법 중 하나인 UIGestureRecognizer에 대해 전반적으로 공부해보았습니다. 가끔 UIGestureRecognizer의 서브 클래스들을 사용하면서 원하는대로 동작을 안하는 경우가 있었는데 그 이유를 알게되는 계기가 되었습니다.

추후에는 UIGestureRecognizer 를 직접 구현해보는 공식 문서를 공부해보고 이를 기록해보도록 하겠습니다. 감사합니다.

참고자료

Apple Developer Documentation

이동건의 이유있는 코드

블로그를 이전하였습니다.

블로그를 http://protocorn93.github.io 로 이전하였습니다!

많은 방문과 피드백 부탁드리겠습니다.

[Project] GitBingo

GitBingo (깃빙고)

기능

사용한 기술

사용한 아키텍쳐

공부한 내용 정리

사용한 라이브러리

문제점

App Programming Guide for iOS -Introduction,Expected App Behaviors

At a Glance

Providing the Required Resources

The App Bundle

Supporting User Privacy

[Swift] Swift에서 정규표현식 사용하기

NSRegularExpression

마무리

[ios] Xcode에서 Unit Test를 해보다

Testing with Xcode

테스팅 준비하기

간단한 테스트 코드 작성해보기

마무리

[iOS Boostcourse] 동시성과 병렬성 그리고 비동기 프로그래밍

OperationQueue? DispatchQueue ?

What Sets Them Apart

Benefits of Operation

When to Use Which

When to Use Operation

When to Use GCD

마무리

[Swift] 프로토콜과 제네릭 그리고 열거형

프로토콜(Protocol) 과 제네릭(Generics)

Implementation

마무리

[ios] UIViewController LifeCycle - 추가

마무리

[Swift] Functor and Monad in Swift

Context

Container

Map

Functor

Monad

마무리

[ios] Handling UIKit Gestures

Configuring a gesture recognizer

Responding to Gestures

UIGestureRecognizer

Subclassing Notes

About the Gesture Recognizer State Machine

Managing State Transitions for a Discrete Gesture Recognizer

Managing State Transitions for a Continuous Gesture Recognizer

Handling Cancellation

Resetting the Gesture Recognizer State Machine

마무리

When to Use `Operation`