[Swift] App Lifecycle & ViewController LifeCycle

simoniful·2021년 10월 17일

Swift

목록 보기

6/9

Enumeration(열거형)

enum은 타입이므로 대문자 카멜케이스를 사용하여 이름을 정의, 각 case는 소문자 카멜케이스로 정의합니다.
각 case는 그 자체가 고유의 값입니다. 한 줄에 개별로도, 한 줄에 여러개도 정의할 수 있습니다.
switch 구문을 활용하여 열거형을 매칭하여 값을 매칭할 수 있습니다. 모든 경우(cases), 기본값(default)를 포함해야 합니다.

enum CompassPoint {
    case north
    case south
    case east
    case west
}

var directionToHead = CompassPoint.west
directionToHead = .east

directionToHead = .south
switch directionToHead {
case .north:
    print("Lots of planets have a north")
case .south:
    print("Watch out for penguins")
case .east:
    print("Where the sun rises")
case .west:
    print("Where the skies are blue")
}
// Prints "Watch out for penguins"


enum Planet {
    case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune
}

let somePlanet = Planet.earth
switch somePlanet {
case .earth:
    print("Mostly harmless")
default:
    print("Not a safe place for humans")
}

무작위로 값이 입력되는 것을 방지해 입력값의 오류 발생 가능성을 줄이고 코드의 안정성을 높여줍니다.
문자열, 정수 등 입력 받아야 할 정보를 입력하는 대신, 선택할 수 있도록 만듭니다.
열거형은 연관된 데이터가 멤버로 구성되어 있는 자료형 객체입니다.

자료형과의 차이점

배열, 집합, 딕셔너리 등의 요소는 삭제나 변경이 가능합니다. 하지만 열거형이 가진 멤버에 대해서는 enum의 정의를 수정하지 않는 이상 삭제나 변경이 불가능합니다.

열겨형의 멤버들은 정의 시점에서 컴파일러가 미리 알 수 있습니다. 따라서 오타나 실수가 발생할 경우 컴파일 시점에 오류를 인지할 수 있습니다. 따라서 버그를 수정하기가 훨씬 편리합니다. 반면, 집단 자료형이라면 런타임 과정에서 확인이 가능합니다.

필요성

입력 받을 값을 특정하여 원하지 않는 값이 잘못 되는 것을 막고 싶을 때
제한된 값 중에서만 선택할 수 있도록 미리 규칙을 정하고 싶을 때

원시값(RawValue)

멤버와 값의 분리
숫자, 문자열 등의 전달이 필요한 경우, 데이터 만으로는 의미 전달에 한계가 있습니다. Enum의 Case는 그 자체로도 독입적인 값이지만, 내부에 또 다른 값을 저장하는 것이 가능합니다.

enum AppleDevice: String {
    case iPhone = "아이폰"
    case iPad = "아이패드"
    case watch = "애플워치"
    case mac = "맥킨토시"
    case airPods = "에어팟"
}

일부 항목에만 값을 주는 것이 가능하며, 이 경우에는 caseName과 동일한 값을 가지게 됩니다.
정수 타입을 경우 값이 할당된 첫 항목을 기준으로 +1씩 늘어난 값을 차례대로 가지게 됩니다.

Alert

앱을 사용하다보면 개발을 하는 입장에서 어떤 이벤트에 대한 UI를 구성하면서 사용자에게 확인하고 진행하기 위한 알람을 통해서 전달할 필요가 있습니다. 알람은 모두 Alert Controller로 시작합니다. 알람은 타이틀, 메시지와 각각의 동작을 취합니다.

@IBAction func showAlert(_ sender: UIButton) {
    // 1. UIAlertController 생성: 밑바탕 + 타이틀 + 본문
    let alert = UIAlertController(title: nil, message: nil, preferredStyle: .alert)
        
    // 2. UIAlertAction 생성: 버튼들..
    let ok = UIAlertAction(title: "아이폰이 왔다!", style: .default)
    let ok2 = UIAlertAction(title: "아이폰 Max가 왔다!", style: .default)
    let ipad = UIAlertAction(title: "아이패드가 왔다!", style: .destructive)
    let watch = UIAlertAction(title: "애플와치가 왔다!", style: .cancel)
        
    // 3. 1+2
    alert.addAction(ok2)
    alert.addAction(ok)
    alert.addAction(ipad)
    alert.addAction(watch)
        
    // 4. Present
    present(alert, animated: true, completion: nil)
}

Alert Controller의 preferredStyle
시스템에서 제공하는 띄워지는 형식을 설정할 수 있습니다. 기본적인 팝업 형태의 알람인 .alert과 아래에서 위로 올라오는 형식인 .actionSheet이 있습니다. 스타일 변경에 제약사항이 많기에 직접 커스텀을 하거나 라이브러리를 활용하기도 합니다.
UIAlertAction의 style
기본형식인 .default, 볼드체로 강조되는 .cancel, 붉은 색으로 바뀌는 .destructive가 있습니다.

이 외에도 사용자에게 확인하는 UI를 활용하는 것으로 아래 요소들이 있습니다.

UIImagePickerController(앨범 사진 선택)
UIActivityViewcontroller(파일 공유에 대한 패널)
UIMenuController(특정 텍스트/이미지 등 요소 블록에 대한 복사, 붙여넣기 등 추가적인 작업 메뉴)
UIDocumentPickerViewController(기기 내장 파일 활용)
UIFontPickerViewController(폰트 설정)
UIColorPickerViewController(색상 선택)

Storyboard Reference

스토리보드를 통해 UI를 작업하게 되면 코드로 작성하는 것보다 계층과의 관계를 판단하기 쉽고 시각적으로 쉽게 정보를 얻을 수 있지만 뷰 컨트롤러가 늘어날 수록 스토리보드 로딩 시간이 오래 걸리고 앱의 Scene 구조를 이해하기에도 복잡해집니다. 그리고, 협업을 할 때 Storyboard 소유자가 달라지거나 하면서 충돌이 발생할 수 있기도 합니다.

따라서, 스토리보드를 사용하지 않고 100% 코드로만 작업할 수도 있고, 스토리보드 안에 하나의 뷰 컨트롤러를 두어 스토리보드 자체를 나누어서 작업합니다. 스토리보드를 나누어서 작업할 때, 스토리보드 레퍼런스를 활용합니다.

다중 스토리 보드

새로운 스토리 보드 파일을 추가입니다.
표현하고자 하는 Scene을 스토리 보드에 구성하고 해당 스토리 보드에도 엔트리 포인트를 설정합니다.
기존에 있던 스토리 보드에서 Storyboard Reference 요소를 만들고, 관계를 생성하여 화면전환이 가능하도록 만듭니다.
프로젝트 전체 설정을 활용하여 실제 앱 구동시 가장 먼저 실행되어야 하는 스토리 보드를 설정합니다.
info.plist에서 Application Scene Manifest 을 변경합니다.

Swift Package Manager

패키지를 찾고 관리할 수 있도록 해주는 의존성 관리 도구입니다. 애플에서 공식적으로 지원합니다. XCode 11부터 GUI 환경이 좋아지면서 보다 지원 환경이 안정화되고 있으며, File - Add Package, 에서 깃헙 주소를 넣는 것으로 패키지를 손쉽게 가져올 수 있습니다.

웹 개발에서 Node Package Manager와 유사한 기능을 하는 도구로 다른 의존성 관리 도구로 코코아팟과 카르타고가 있습니다.
코코아팟은 의존성을 추적하여 자동으로 관리해주기 떄문에 사용의 편리성은 있지만, 빌드 속도가 무겁고 느리다는 단점이 있습니다. 카르타고는 경량이지만 지원 라이브러리가 상대적으로 적기에 제한 점이 있습니다.

Dependency Rule

라이브러리 버전에 따른 지원되는 기능이 달라지기도 하며, 개발 환경의 상황(iOS의 버전)에 따라서 해당 라이브러리가 적용이 불가능한 경우도 있습니다. 때문에 버전 사용에 있어서 해당 git-hub 공식 설명을 통하여 이를 주의하고 사용해야 합니다. 버전 규칙의 범위를 통하여 관리하는 것도 가능합니다.

0.3.2

0: Major - 기존 버전과 호환이 되지 않고, API가 바뀌는 경우

3: Minor - 기존 버전과 호환이 되며, 새로운 기능 추가

2: Patch - 기존 버전에서 버그 수정

라이브러리 / 프레임워크

공통점: 모두 활용가능한 기능을 위한 클래스, 컴포넌트로 구성되어 있습니다.

라이브러리: 필요한 기능들이 묶인 코드의 묶음, 효율적인 코드 작성을 위해 언제든지 필요한 곳에서 호출하여 사용할 수 있도록 Class, Function으로 구성되어 있습니다. 보다 단순한 의미에서 활용가능한 도구의 집합을 말합니다.
주도성이 개발자 측에 있으며 개발자가 필요에 따라 사용하고 직접 코드를 제어하여 커스텀이 가능합니다.
프레임워크: 뼈대나 기반구조를 뜻하며, 제어의 역전의 개념이 적용된 대표 기술입니다. 특정 개념의 추상화를 제공하는 Class, Componant 등으로 구성되어 있습니다.
주도성이 프레임워크 측에 있기에 프레임 워크에 맞춰서 작업이 진행됩니다.

현재는 라이브러리와 프레임워크의 경계가 모호하여 혼용하여 사용하는 경우가 많습니다.

프레임워크와 라이브러리의 차이점

UserDefaults

일반적으로 프로그램을 실행하여 프로세스가 메모리 스택에 올라가면 내부에서 구동되는 코드를 통한 동작들은 메모리 상에서만 유지 됩니다. 따라서 화면이 전환 되면서 해당 코드가 메모리에서 제거된다면, 이는 가비지 컬렉팅 되어 사라집니다.

하지만, UserDefaults를 활용하여 영속적인 데이터 활용이 가능합니다. Apple에서 제공해주는 Key-Value 형태의 기본 저장소로 웹 개발에서 웹 스토리지 객체인 localStorage와 유사합니다. 앱 내에서 데이터를 반영구적으로 저장하여 앱이 꺼졌다 켜져도 해당 데이터를 유지하고 가지고 있습니다.

내부에 보호된 샌드박스 시스템을 통하여 앱 마다 가지게 되는 plist 파일을 생성하여 데이터를 관리합니다. 그렇다고 모든 데이터를 User Defaults를 통해 저장을 하지는 않고 간단한 설정값, 환경값, 매우 적은 수준의 단일 데이터 값 등을 저장합니다.

ex. 자동 로그인 여부, 알림 수신 여부, 인앱 결제 여부, 이메일, 닉네임 등 사용자 기본 설정, 앱 테마, 팝업 여부 등

데이터가 영구적으로 남아있어도 앱을 삭제하게 된다면 사라지기에, 삭제 유무와 관계없이 데이터를 보존하고 싶은 경우에는 백업/복구 기능을 지원하거나, Keychain, iCloud 동기화 등을 통하여 보완이 가능합니다.