오늘은 제가 이전에 북마크를 해뒀던 <Swift: Alternative to struct>이라는 글을 번역하여 포스팅하도록 하겠습니다.

작성자에게 허가를 받았으며 원문은 https://blog.devgenius.io/swift-alternative-to-struct-a4ace0678673 에서 확인하실 수 있습니다.

그럼 번역한 글입니다.

Swift: Alternative to struct

분석 이벤트를 추적해야 하는 앱을 만들고 있다고 합시다. 이를 위해 파이어베이스 등의 이벤트 추적 시스템을 선택해야 합니다.

첫 번째로 할 일은 AnalyticsEvent를 모델링하는 구조를 만드는 것입니다.

이 상황은 가상의 사례이지만, 문제를 드러냅니다. struct는 여러 값을 포함할 수 있기 때문에 한 명령어에 여러 이벤트(예: hasFeedback 및 hasAdditionalData)가 포함되면 버그가 발생할 수 있습니다. 이는 상호 배타적인 속성이 없기 때문에, 이벤트가 동시에 두 가지 다른 상태에 있을 수 있다는 문제를 보여줍니다.

속성을 케이스로 그룹화하기 위해 enum을 사용하면 데이터가 훨씬 더 깔끔해집니다. Swift는 연관 값을 사용하여 더 복잡한 데이터 구조를 구성할 수 있는 기능을 제공합니다.

각 경우에 연관 값을 추가하면 어떤 속성이 함께 속해야 하는지 더 명확해집니다. 이제 잘못된 값을 혼합하거나 조합하는 걱정 없이 적절한 이벤트를 구성할 수 있습니다.

이 유형의 구조체에서는 스위치문을 사용하여 내부 값을 추출할 수 있습니다.

스위치를 사용할 때는 AnalyticsEvent의 모든 경우를 모두 처리해야 합니다. 특정 경우에 관심이 있다면 if-case-let 구문을 활용할 수 있습니다. 또한 특정 속성에 대한 일치 조건을 와일드카드 연산자를 사용하여 설정할 수 있으며 이외의 속성에 대해 신경 쓰지 않는다는 것을 의미합니다.

열거형(enum)에서 다형성

다형성의 형태로 유연성이 필요한 경우가 있습니다. 이는 어떤 유형이라도 혼합할 수 있다는 의미이지만 종종 이상적인 방법은 아닙니다. 컴파일 시점에 유형을 알 수 없기 때문에, 런타임 시점에 유형이 무엇인지 확인하기 위해 Any 유형에 대한 검사가 수행되어야 합니다.

예상하는 데이터 유형을 모르더라도 switch 문을 사용하여 유형을 확인할 수 있지만, 관심 없는 유형에 대한 기본 경우를 반드시 처리해야 합니다. 서버에서 받는 데이터의 유형이 불확실할 때는 Any를 사용하는 것이 좋습니다. 하지만 데이터 유형을 사전에 알고 있다면 enum을 컴파일 시 안전 장치로 사용할 수 있습니다.

서버로부터 Date 또는 Range<Date> 중 하나를 받는다고 가정해 보겠습니다. 이 경우 DateType을 모델링하여 이 두 가지 옵션 중 하나를 나타낼 수 있습니다.

이 유형의 모델링을 통해 이제 단일 DateType 또는 DateType 배열을 받을 수 있습니다! 배열의 각 값은 여러 유형 중 하나를 포함할 수 있으며, 컴파일 시 안전성을 유지합니다. 값을 처리하려면 이전 예제와 마찬가지로 switch 문을 사용하면 됩니다.

이 기능을 사용하면 안전하게 작업할 수 있습니다. DateType을 수정하려는 경우 컴파일러는 새로운 경우나 누락된 경우에 대해 경고합니다.

열거형(enum)에서 서브클래싱

서브클래싱은 데이터의 계층 구조를 구축하는 개념입니다. 예를 들어, 피자집에서 제공하는 모든 종류의 피자를 나타내는 ‘피자’ 클래스를 만들 수 있습니다. 이제 다양한 종류의 피자를 가질 수 있습니다: 나폴리 피자, 캘리포니아 피자, 시카고 피자 등.

이상적인 세계에서는 데이터를 계층적으로 모델링하는 것이 의미가 있지만, 현실에서는 그렇지 않은 경우가 많습니다. 때로는 계층의 규칙에 맞지 않는 예외나 특수 사례를 처리해야 할 때가 있습니다.

예를 들어 게임을 모델링해 보겠습니다. 단일 플레이어 게임을 시작으로 할 수 있습니다.

만약 이제 멀티플레이어 게임을 추가하고 싶다면, 많은 속성이 유사하기 때문에 쉽게 할 수 있습니다.

소개된 게임 슈퍼클래스는 SinglePlayerGame과 MultiPlayerGame이 공통으로 사용하는 속성을 포함합니다. 이러한 방식으로 모델링을 할 경우 클래스를 사용해야 합니다. 하지만 이 것이 가장 큰 문제는 아닙니다. 만약 동일한 속성을 공유하지 않는 새로운 게임 유형 AIGame을 추가하려면 전체 데이터 모델을 리팩토링해야 합니다.

enums를 사용하면 계층적 모델을 우회할 수 있지만 여전히 단일 게임 유형을 전달하는 옵션을 유지할 수 있습니다. 또한 새로운 게임 유형을 추가하더라도 기존 게임들과 충돌하지 않습니다.

이 유형의 서브클래싱은 유사한 유형이 서로 달라지기 시작하거나, 클래스 대신 구조체(struct)를 사용하려는 경우 가장 적합합니다. 이 접근 방식의 단점은 응용 프로그램 전체에서 모든 경우를 일치시켜야 한다는 점입니다. 추가 작업이 필요하지만, 만약 무언가를 잊어버리면 컴파일러 경고가 발생하기 때문에 안전 장치 역할을 합니다. 또 다른 단점은 모델을 고정시키는 것입니다. 즉, 제3자 라이브러리에서 열거형을 제공하거나 사용할 경우 사용자가 이를 확장할 수 없습니다.

문자열의 안전한 사용

열거형은 종종 문자열과 함께 사용됩니다. 열거형이 원시 값 유형으로 정의되면, 정의된 모든 경우에 내부적으로 어떤 값이 포함됩니다. 원시 값을 가진 열거형은 열거형 선언에 타입을 추가하여 정의됩니다.

원한다면 각 경우에 원시 값을 추가할 수 있지만, 이처럼 열거형을 선언하면 각 경우에 해당 경우의 이름이 값으로 할당됩니다.

때로는 열거형의 값을 서버로 전송될 매개변수로 사용하고자 할 수 있습니다. 이 경우 열거형의 원시 값 속성에 접근하여 원시 값을 읽어 매개변수를 설정합니다.

버그는 원시 값을 케이스에 할당함으로써 발생할 수 있습니다. 컴파일러는 계속 작동하지만, 불행히도 API는 작동하지 않을 것입니다.

문제를 해결하는 두 가지 방법이 있습니다:

안전하게 처리하려면 열거형의 원시 값을 무시하고 각 열거형 경우에 따라 일치시키세요

유닛 테스트로 코드를 커버하여 올바른 동작을 보장하세요

하지만 서버에서 값을 받고 해당 값이 변경된 경우 어떻게 될까요? 이 경우 사용자 정의 초기화를 사용하여 처리할 수 있습니다

요약

enum은 때로는 서브클래싱보다 더 나은 대안이 될 수 있습니다.

enum은 컴파일 시점에 문제를 탐지할 수 있는 기능을 제공합니다.

문자열 처리를 enum으로 변환함으로써 더 안전하게 만들 수 있습니다.

오늘은 연산 프로퍼티에 대해서 알아보겠습니다.

연산 프로퍼티란?

연산 프로퍼티하면 어떤 것이 생각나시나요?

보통 프로퍼티는 클래스, 구조체의 특성저장을 하기 위해 사용합니다.

하지만 연산 프로퍼티는 저장을 하지 않습니다.

단지 저장 프로퍼티에 값을 연산할 때 사용합니다

프로퍼티를 읽는 연산을 수행하는 것을 getter, 프로퍼티를 바꾸는 연산을 할 때는 setter 라고 합니다.

연산 프로퍼티는 두가지 종류가 있습니다.

getter 와 setter 두가지를 다 갖고 있는 Computed Property(연산 프로퍼티)가 있고요.
getter 만 갖고 있는 Read-Only Computed Properties(읽기 전용 연산 프로퍼티) 가 있습니다.

연산 프로퍼티의 사용 방법은?

우선 연산 프로퍼티를 사용하기 위해서는 대체로 “저장소” 가 필요합니다.

연산 프로퍼티는 값을 연산만 할 뿐 저장을 하지 않기 때문입니다.

그렇기 때문에 이런 연산을 수행할 저장소가 별도로 필요한 것이죠.

tempName 라는 저장 프로퍼티가 저장소 역할을 합니다.

name 은 연산 프로퍼티이며 get 과 set 이 지정되어 있습니다.

name 이 별도의 값을 저장하지는 않습니다.

name 의 getter, setter 는 tempName 이라는 저장소를 연산에 활용합니다.

읽기 전용 연산 프로퍼티의 사용 방법은?

읽기 전용 연산 프로퍼티는 저장소가 꼭 필요하지는 않습니다.

만약 어떤 정해진 값만을 리턴해준다면 저장소가 필요하지는 않습니다.

name 은 읽을 수만 있으며 다른 값으로 변경하지 못합니다.

name 을 읽으면 정해진 문자열만 리턴됩니다.

읽기 전용(get only)인 경우에는 아래와 같이 get 을 생략할 수 있습니다.

정리

오늘은 연산 프로퍼티에 대해서 알아봤습니다.

궁금하거나 잘못된 점 있으면 댓글 부탁해요.

읽어주셔서 감사합니다~

참고 : https://zeddios.tistory.com/245

안녕하세요. 도미닉입니다.

오늘은 iOS 테이블뷰에서 셀의 재사용에 대해서 정리해보겠습니다.

dequeueReusableCell(withIdentifier:for:)

일반적으로 테이블뷰에서 셀을 리턴하는 함수에서 셀을 재사용하도록 습관적으로 아래와 같이 코드를 작성하고 있습니다.

이 dequeueReusableCell(withIdentifier:for:) 메소드는 무엇일까요?

지정된 재사용 식별자(indexPath)에 대해 재사용이 가능한 테이블 뷰 셀 객체를 반환하고 테이블뷰에 추가한다.

라고 공식 문서에 나와있습니다.

파라미터와 리턴되는 값이 대해 정리해보겠습니다.

파라미터

identifier

• 재사용할 셀 객체를 식별하기 위한 문자열입니다. 이 매개 변수는 nil이 아니어야합니다.

indexPath

• 셀의 위치를 특정하는 식별자입니다. 항상 데이터 원본 객체에서 제공하는 index path를 지정하십시오. 이 메소드는 index path를 사용하여 테이블뷰에서 셀의 위치를 기반으로 추가 구성을 수행합니다.

리턴 타입

UITableViewCell

• 재사용 식별자와 연관된 UITableViewCell 개체입니다. 이 메서드는 항상 유효한 셀을 반환합니다.

dequeueReusableCell(withIdentifier:for:) 메서드는 UITableViewDataSource 역할을 하는 객체의

tableView (_: cellForeRowAt :) 메서드 내에서만 호출이 가능합니다.

이 메서드는 아래 3가지 방법으로 셀을 리턴합니다.

• 기존 셀 타입
• 직접 만든 ITableViewCell 클래스
• 스토리 보드를 사용하여 만든 새로운 셀

데이터 소스의 tableView (_: cellForeRowAt :) 외부에서 셀을 만들어야하는 경우에는 이 메서드 대신에 dequeueReusableCell(withIdentifier :)를 사용할 수 있습니다.

스토리보드에서 셀을 만들은 경우 식별자로 셀을 지정해야합니다. 
register (_ : forCellReuseIdentifier :) 또는 register (_ : forCellReuseIdentifier :) 메서드를 사용하여 클래스 또는 nib 파일을 등록 할 수 있으며 dequeueReusableCell(withIdentifier:for:) 메서드를 호출하기 전에 등록해야합니다.

이와 같이 dequeueReusableCell(withIdentifier:for:) 메서드만을 호출하면 셀의 재사용에 문제가 없을까요?

첫번째 row의 셀의 배경색을 바꿔야한다고 칠 때 아래와 같이 코드를 작성할 수 있을 것입니다.

실제로 이렇게 코드를 작성하면 처음에는 잘 동작하지만 테이블뷰를 위아래로 내리면 셀이 큐에 들어갔다가 다른 indexPath.row로 재사용되면서 점점 주황색 셀이 늘어나는 현상을 발견할 수 있습니다.

이럴 때 간단하게 if 문에 else 구문을 추가해서 cell.backgroundColor = .clear 라는 식으로 색상 변경을 원하지 않는 row의 색상을 흰색으로 할 수 있을 것입니다.

하지만 저는 prepareForReuse() 메소드를 활용하는 것을 더 선호합니다.

큐에 들어가서 셀이 다시 처음처럼 비어져서 나오는 방식이 더 맞다고 생각해서 입니다.

prepareForReuse()

공식 문서를 보면 아래와 같이 설명이 나옵니다.

tableview 의 delegate가 셀을 재사용하도록 준비합니다.

UITableViewCell 객체가 재사용 가능한 경우 이 메서드는 UITableView 에 dequeueReusableCell (withIdentifier :) 메서드에서 객체가 반환되기 직전에 호출됩니다.

성능 상의 이유로 콘텐츠와 관련이 없는 셀 속성(예 : alpha, eiditing, 셀 선택 상태)만 reset해야합니다.

tableView (_ : cellForRowAt :)에 있는 테이블 뷰의 델리게이트는 셀을 재사용 할 때 항상 모든 콘텐츠를 reset해야합니다.

셀 객체와 관련된 재사용 식별자가 없으면 이 메서드는 호출되지 않습니다. 이 메서드를 재정의하는 경우 슈퍼 클래스의 같은 메서드를 호출해야 합니다.

설명을 보면 성능 상의 이유로 콘텐츠와 관련이 없는 셀 속성만 reset 해야 한다고 하고 tableView 에 있는 셀은 모든 콘텐츠를 reset해야 한다고 하는데 이 부분은 한번 확인해봐야겠습니다.

저는 커스텀 테이블 뷰 셀 안에 아래와 같이 코드를 작성하여 모든 콘텐츠를 reset 해주고 있습니다.

정리

테이블 뷰를 사용할 때 가장 위에 보여드린 코드와 같이 루틴을 가지고 사용하고 있었습니다.

dequeueReusableCell(withIdentifier:for:) 와 prepareForReuse() 메서드의 공식 문서를 살펴보면서 조금 더 알게 되는 내용도 있었고 머릿 속이 정리되는 느낌이 들었습니다.

대부분의 내용은 아래 참고의 공식 문서 링크를 번역한 것입니다.

조금 번역이 어색한 부분이 있거나 자세히 알고 싶으시면 참고 문서 확인해주시면 좋을 것 같습니다.

글 읽어주셔서 감사합니다.

참고 :

• Apple Developer Documentation
• prepareForReuse() | Apple Developer Documentation

오늘은 UIView 의 모서리를 깍아서 둥글게 만드는 방법을 알아보겠습니다.

UIView 를 상속받는 UIImageView, UIButton 등도 아래의 방법으로 모서리를 둥글게 할 수 있습니다.

모서리 둥글게 만드는 방법

UIView 에는 CALayer 객체인 layer 프로퍼티가 있습니다.

layer 에는 cornerRadius 와 masksToBounds 값이 있습니다.

이 값들을 변경해서 모서리를 둥글게 만들 수 있습니다.

모양을 원으로 싶다면 UIView 의 길이의 반만큼 cornerRadius 를 설정하시면 됩니다.

정리

간단히 뷰의 모서리를 둥글게 만드는 방법을 알아봤습니다.

질문있다면 남겨주세요.

감사합니다.

참고 : http://blog.naver.com/PostView.nhn?blogId=hjleesm&logNo=221298790719&redirect=Dlog&widgetTypeCall=true&directAccess=false

안녕하세요. 도미닉입니다.

아이폰을 맥북에 꽂고 엑스코드에서 아이폰으로 실행시키려고 하면 아래 오류가 뜰 경우가 있습니다.

이 경우 해결 방안을 공유합니다.

• 아이폰에서 실행했던 앱을 제거합니다.
• 빌드 폴더를 청소합니다. ⌘ + shift + K
• 아이폰 페어링을 해제합니다.(from ⌘ + shift + 2 window)
• 아이폰 연결을 끊습니다.
• 아이폰을 재시작합니다.
• 맥을 재시작합니다.
• 연결합니다.

이렇게 해서 저는 문제를 해결할 수 있었습니다.

잘 안되시거나 문의사항은 댓글 달아주세요.

읽어주셔서 감사합니다.

참고 : https://stackoverflow.com/questions/64974291/xcode-12-3-beta-failed-to-prepare-device-for-development

ajax 를 사용하려고 보면 uncaught referenceerror $ is not defined 이라는 오류가 발생할 때가 있습니다.

jquery 가 추가되어있지 않아서 발생하는 오류입니다.

헤더에 오류가 뜨는 코드 위에 jquery 를 추가해주면 오류가 해결됩니다.

<script src="https://code.jquery.com/jquery-1.12.4.js"></script>

감사합니다.

클로저는 기능을 갖는 독립적인 코드 블록입니다.

말이 조금 어려운데요.

기능을 갖는 코드 블록을 우리는 이미 알고 있습니다.

맞습니다. 함수입니다.

그렇다면 함수와 클로저의 차이는 무엇일까요?

아래 설명을 보시면 이해하실 수 있으실 겁니다.

클로저를 선언하는 방법은?

클로저는 선언하는 부분에서부터 함수와 차이점을 보입니다.

클로저는 함수와 달리 이름을 적지않습니다.

이름을 적지 않음으로써 아래와 같은 사실을 알 수 있습니다.

클로저는 선언해놓고 호출하는 방식이 아니라 필요할 때마다 코드 블록을 작성해야한다.

자주 사용하는 코드 블록을 선언해놓는 함수와 달리 매번 다른 코드 블록을 사용할 때 필요할 것 같다.

그렇다면 클로저를 사용하려면 매번 긴 코드 블록을 직접 작성해야할까요?

이러한 문제를 해결하기 위해 클로저는 축약형을 제공합니다.

아래 nameSorted1부터 nameSorted8 까지의 상수들은 모두 같은 순서의 배열을 갖습니다.

다만 애플은 축약형보다 풀어서 쓰는 것을 선호한다고 합니다.

클로저의 활용 방안은?

map 의 전달인자로 사용할 수 있습니다.

map 고차함수는 배열의 전체 요소들에 대해 동시에 더하기, 곱하기, 형변환 등의 작업을 할 때 사용할 수 있습니다.

만약 numbers 라는 배열이 있는데 각 요소에 3을 곱한 배열이 필요하다고 합시다.

아래처럼 배열을 초기화하고 for 문을 돌려서 threeTimesNumbers 배열을 채울 수 있을 것입니다.

이러한 상황에서 map 을 사용하면 한번에 그리고 상수 타입으로 배열을 저장할 수 있습니다.

스위프트는 변수보다 상수의 활용을 권장하기 때문에 이러한 점은 굉장한 메리트가 될 수 있습니다.

공식문서에 있는 예제입니다.

map 함수를 이용해 숫자를 문자열로 나타내도록 실행됩니다.

기준에 따라 합격 불합격을 저장할 수도 있습니다.

filter 의 전달인자로 사용할 수 있습니다.

filter 고차함수는 조건에 따라 배열의 요소를 추출하는데 사용합니다.

예를 들어 점수가 80점 초과인 요소들만 뽑아낼 수 있습니다.

짝수만 뽑아낼 수도 있습니다.

reduce 의 전달인자로 사용할 수 있습니다.

reduce 고차함수는 배열 요소의 총합, 전체 요소 빼기, 전체 요소 곱하기 등 전체 요소를 종합하는데 사용할 수 있습니다.

정리

이상으로 클로저에 대한 설명을 마치도록 하겠습니다.

클로저와 고차함수를 활용하면 for 문과 append, 변수의 사용을 줄일 수 있을 것입니다.

설명 중 틀린 점이나 궁금하신 점은 댓글로 남겨주시면 답변 드리도록 하겠습니다.

읽어주셔서 감사합니다.

참고

https://docs.swift.org/swift-book/LanguageGuide/Closures.html

안녕하세요. 도미닉입니다.

제가 개발하다가 겪었던 일에 대해 말씀드리려고 합니다.

오늘 아이폰에서 개발한 앱을 실행해보려고 USB를 연결했습니다.

연결이 끊어졌다가 다시 붙었다가, 연결 됐다 안됐다가 반복되었습니다.

엑스코드에서도 아이폰을 인식하지 못했습니다.

이럴 때 터미널에서 아래 명령어를 실행하니 안정적으로 연결이 되었습니다.

sudo killall -STOP -c usbd

맥 os 상에 백그라운드로 돌고 있는 usb 서비스를 종료하고 재시작하는 명령어입니다.

저와 비슷한 일을 겪으시면 이 명령어로 해결하셨으면 합니다.

감사합니다.

참고 : https://www.clien.net/service/board/lecture/11804930

오늘은 iOS 앱에 네이버지도를 띄우는 방법을 공유하도록 하겠습니다.

클라이언트 ID 발급받기

네이버 클라우드 플랫폼 콘솔 페이지에 로그인하면 아래와 같이 대시보드가 나타납니다.

하늘색 박스로 표시한 Products & Services 를 클릭합니다.

아래와 같이 서비스들이 보여집니다.

하늘색 박스로 표시한 AI·Application Service > AI·NAVER API 를 클릭합니다.

+ Application 을 클릭합니다.

Application 에 앱 이름을 입력하고 Mobile Dynamic Map 에 체크합니다.

xcode 로 프로젝트를 생성하면 아래와 같이 Bundle Identifier 가 주어집니다.

아래 프로젝트의 Bundle Identifier 을 입력한 뒤에 +추가를 눌러서 아래와 같이 추가해주고 등록을 눌러줍니다.

라이브러리 설치

라이브러리를 설치하기에 앞서 필요한 프로그램들을 설치해줍니다.

cocoapod 이 설치되어 있지 않다면 아래 명령어로 설치

sudo gem install cocoapods

homebrew 가 설치되어 있지 않다면 아래 명령어로 설치

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

git-lfs 가 설치되어 있지 않다면 아래 명령어로 설치

brew install git-lfs

이제 라이브러리를 설치할 준비가 끝났습니다.

터미널로 프로젝트 경로에 이동해서 아래의 작업들을 수행합니다.

아래 명령어로 코코아팟을 초기화합니다.

pod init

git-lfs 도 초기화해줍니다.

git-lfs install

Podfile 에 아래 코드를 추가합니다.

pod 'NMapsMap'

pod install 로 라이브러리를 설치해줍니다.

pod install --repo-update

클라이언트 ID 설정

pod install 을 하면 xcworkspace 파일이 생성됩니다.

프로젝트명.xcworkspace 로 프로젝트를 엽니다.

Info.plist 를 열고 Information Property List 에 마우스를 클릭하면 + 버튼이 보입니다.

플러스 버튼을 누르고 Key 에 NMFClientId 를 입력합니다.

Value 에는 발급받은 네이버 API 클라이언트ID 를 복사해서 붙여넣기 합니다.

추가한 내용은 아래와 같습니다.

지도 표시

ViewController.swift 파일 상단에 아래 코드를 추가해 NMapsMap 를 임포트 시킵니다.

import NMapsMap

ViewDidLoad 함수에 아래 코드를 추가해 네이버 지도를 화면에 표시합니다.

let mapView = NMFMapView(frame: view.frame)
view.addSubview(mapView)

이제 지도가 띄어집니다.

오류 해결 방법

이런 오류가 발생할 수 있는데요.

저는 git-lfs 를 제대로 셋팅하지 않고 pod install 을 한 뒤에 이런 오류가 발생했습니다.

해결 방법은 아래 명령어로 Pods 폴더를 제거해줍니다.

rm -rf Pods

네이버맵 에 대한 캐시를 비워줍니다.

pod cache clean NMapsMap

or

pod cache clean --all

다시 git-fls 를 초기화해줍니다.

git-lfs install

팟을 다시 설치합니다.

pod install --repo-update

정리

오늘은 네이버지도를 iOS 에 띄우는 방법을 공유해봤습니다.

혹시 안되거나 잘못된 내용 있으면 댓글 달아주세요.

도움이 되셨으면 박수 버튼과 Follow 부탁드립니다.

감사합니다.

참고 :

https://navermaps.github.io/ios-map-sdk/guide-ko/1.html

설명서

https://github.com/navermaps/ios-map-sdk

오늘은 뷰컨트롤러 라이프사이클에 대해서 알아보겠습니다.

ViewController Life Cycle 이란?

프로젝트를 처음 생성하거나 UIViewController 의 subclass 를 생성하면 아래와 같이 viewDidLoad() 가 있다.

이 viewDidLoad 와 같이 ViewController 의 상태 변화에 따라 호출되는 메서드들은 아래 사진과 같다.

이미지 출처 : https://developer.apple.com/documentation/uikit/uiviewcontroller

이 메서드에 대해 하나씩 알아보자.

ViewController Life Cycle 메서드 종류

viewDidLoad

• 뷰 컨트롤러가 뷰 계층을 메모리에 로드한 뒤에 호출된다.
• 메모리에 처음 로드될 때 한 번만 호출된다. (메모리 경고로 뷰가 사라질 경우 제외)
• 뷰와 관련된 추가적인 초기화 작업

viewWillAppear

• 뷰 컨트롤러의 뷰가 뷰 계층에 추가되기 전(뷰가 나타나기 전)에 호출된다.
• 다른 뷰로 이동했다가 돌아오면 재호출된다.
• 뷰와 관련된 추가적인 초기화 작업
• viewDidLoad와 viewWillAppear의 차이?

viewDidLoad에서는 한 번 초기화된 후 변하지 않는 내용에 관한 작업을,

viewWillAppear에서는 화면이 나타날 때마다 업데이트 해야 하는 내용에 관한 작업을 수행

viewDidAppear

• 뷰 컨트롤러의 뷰가 뷰 계층에 추가된 후(뷰가 나타난 뒤)에 호출된다.
• 뷰를 나타낼 때 필요한 추가 작업, 애니메이션을 시작하는 작업

viewWillDisappear

• 뷰 컨트롤러의 뷰가 뷰 계층에서 사라지기 전(뷰가 사라지기 전)에 호출된다.
• 뷰가 생성된 뒤 작업한 내용을 되돌리는 작업, 최종 데이터 저장 작업

viewDidDisappear

• 뷰 컨트롤러의 뷰가 뷰 계층에서 사라진 뒤(뷰가 사라진 뒤)에 호출된다.
• 뷰가 사라지는 것과 관련된 추가 작업, 마무리 작업(리소스 해제 등)

출처 : https://yagom.net/groups/ios-%EA%B8%B0%EC%B4%88-%EC%8A%A4%ED%84%B0%EB%94%94-1367957547/forum/topic/viewcontroller-life-cycle/

ViewController Life Cycle 메서드 호출 순서

FirstViewController(이하 A 뷰컨트롤러)가 있고 “두번째 뷰컨트롤러로 이동” 버튼을 눌렀을 때 SecondViewController(이하 B 뷰컨트롤러) 로 이동하고 B 뷰컨트롤러의 “닫기” 버튼을 눌러 A 뷰컨트롤러로 이동할 때 ViewController Life Cycle 메서드 호출 순서를 살펴보자.

처음 앱을 실행했을 때 :

1. A 뷰컨트롤러의 ViewDidLoad
2. A 뷰컨트롤러의 ViewWillAppear
3. A 뷰컨트롤러의 ViewDidAppear

두번째 뷰컨트롤러로 이동 버튼을 누른 후 :

1. B 뷰컨트롤러의 ViewDidLoad
2. A 뷰컨트롤러의 ViewWillDisappear
3. B 뷰컨트롤러의 ViewWillAppear
4. B 뷰컨트롤러의 ViewDidAppear
5. A 뷰컨트롤러의 ViewDidDisappear

B 뷰컨트롤러에 닫기 버튼을 누른 후 :

1. B 뷰컨트롤러의 ViewWillDisappear
2. A 뷰컨트롤러의 ViewWillAppear
3. A 뷰컨트롤러의 ViewDidAppear
4. B 뷰컨트롤러의 ViewDidDisappear

NavigationController 가 있을 때 ViewController Life Cycle 메서드 호출 순서

NavigationController 에 RootViewController 가 있고 TableView 에 cell 을 눌러서 DetailViewController 로 이동하고 NavigationBar 의 “Root View Controller” 버튼을 눌러 RootViewController 로 이동할 때의 ViewController Life Cycle 메서드 호출 순서를 살펴보자.

처음 앱을 실행했을 때 :

1. NavigationController 의 ViewDidLoad
2. NavigationController 의 ViewWillAppear
3. RootViewController 의 ViewDidLoad
4. RootViewController 의 ViewWillAppear
5. RootViewController 의 ViewDidAppear
6. NavigationController 의 ViewDidAppear

RootViewController 에 셀을 눌렀을 때 :

1. DetailViewController 의 ViewDidLoad
2. RootViewController 의 ViewWillDisappear
3. DetailViewController 의 ViewWillAppear
4. RootViewController 의 ViewDidDisappear
5. DetailViewController 의 ViewDidAppear

DetailViewController 의 뒤로가기 버튼을 눌렀을 때 :

1. DetailViewController 의 ViewWillDisappear
2. RootViewController 의 ViewWillAppear
3. DetailViewController 의 ViewDidDisappear
4. RootViewController 의 ViewDidAppear

네비게이션 컨트롤러가 있을 때는 네비게이션 컨트롤러가 없을 때와 다르게 사라질 뷰가 먼저 ViewDidDisappear 가 호출되고 그 뒤에 나타날 뷰의 ViewDidAppear 가 호출되었다.

이 부분은 조금 더 연구해봐야겠다.

정리

뷰컨트롤러 라이프 사이클에 대해서 알아봤습니다.

직접 예제를 돌려보면서 정리해보니 더 와닿고 도움이 된 포스팅이었습니다.

앞으로 다시 미디엄에 포스팅을 하고자 합니다.

구독과 많은 박수 부탁드립니다.

AppleCEO/ViewControllerLifeCycle

사용한 예제입니다.

감사합니다.