• Dynamic Library와 Static Library의 차이를 이해한다.
• Library와 Framework의 차이를 이해한다.

직접 작성한 소스 이외에 다른 사람이 작성한 코드를 사용하고 싶을 때 우리는 라이브러리 또는 프레임워크를 추가한다.

라이브러리 / 프레임워크 코드 및 리소스의 번들이다. (라이브러리에 리소스를 추가한 것을 프레임워크라고 설명하는 글도 있다.) 라이브러리와 프레임워크는 소스 코드의 제어권이 어디에 있냐의 차이이다. 라이브러리는 제어권이 나(개발자)에게, 프레임워크는 내가 아닌 프레임워크(ex. UIKit)가 갖는다.

이렇게 추가한 라이브러리를 내 소스 코드에 연결(Link) 하는 방식에 따라 static과 dynamic으로 구분한다.

Static Library

static library는 .a

소스 코드 + 라이브러리 코드를 merge 한 executable file을 만들어낸다. 이 때, 소스 코드와 라이브러리 코드가 copy 된다.

앱이 실행되면 복사된 이 executable file이 메모리에 로드된다.

많은 static lib를 사용할수록 executable file의 용량이 커짐 → 앱 실행 시 더 많은 메모리가 사용됨 → launch time이 길어짐

Dynamic Library

dynamic library는 .dylib

컴파일 시 static lib처럼 코드를 copy 하는 것이 아니라 dynamic lib에 대한 참조(references)만 executable file에 포함한다. (executable file이 Static Library에 비해 조금 더 가볍다)

앱이 실행되면(=런타임에) 참조에 따라 lib의 코드를 메모리에 load 한다. (.dylib를 로드 하는 로더를 Dynamic Loader라고 부르고 .dyld)

dynamic lib가 많아질수록 executable file을 실행할 때(런타임에) 많은 메모리가 사용됨 → launch time 길어짐

WWDC17 에서 앱의 시작 시간을 개선하기 위해서 dylib를 줄일 것을 권장했기 때문에, dylib를 많이 사용하는 것이 static lib을 사용하는 것보다 앱 실행속도가 더 느리다고 볼 수 있다.

또한, copy 이냐 reference 이냐 linking 방식의 차이이기 때문에 static은 라이브러리의 코드가 업데이트 되면 내 소스코드에서는 반영되지 않지만, dylib의 경우에는 다시 컴파일 하지 않아도 업데이트 된 기능을 사용할 수 있다.

결론

Static vs Dynamic은 Linking 방식의 차이이다.

https://zeddios.tistory.com/1308 Overview of Dynamic Libraries ⬇️ about Swift modules, libraries, packages, closed source frameworks, command line tools and more. https://theswiftdev.com/deep-dive-into-swift-frameworks/

객체 지향 언어의 특징인 다형성을 Overloading과 Overriding을 통해 구현할 수 있다. 다음과 같이 override한 경우, 실제 호출될 method를 스위프트는 어떻게 결정할까?

class Parent {
  func someMethod() {
    print("Parent method")
  }
}

class Child: Parent {
  override func someMethod() {
    print("Child method")
  }
}

let object: Parent = Child()
object.someMethod() // ?

스위프트는 class(참조 타입)의 경우 dynamic dispatch 방식을 채택하고 있다. 컴파일 시점이 아닌, 런타임에 호출될 타입을 결정하는 dynamic dispatch가 이루어진다. 따라서 위의 예제에서는 실제 타입인 Child의 method가 호출된다.

Static vs Dynamic Dispatch

Dynamic Dispatch가 아닌 Static Dispatch 방식으로 타입을 결정할 수도 있다. Static Dispatch는 컴파일 시점에 호출할 타입을 결정한다. 따라서, Dynamic Dispatch보다 성능상 이점이 있지만 다형성을 활용할 수 없다는 단점이 있다.

Increasing Performance by Reducing Dynamic Dispatch

Increasing Performance by Reducing Dynamic Dispatch

공식 블로그에서 Static Dispatch를 유도하기 위한 방법으로 다음 3가지를 제시하고 있다.

• 오버라이드가 필요 없다면 final 키워드 사용
• private 키워드 사용
• WMO(Whole Module Optimization)을 사용

오버라이드가 필요 없다면 final 키워드 사용 : final 키워드를 붙인 class, method, property는 오버라이딩이 불가능하므로, Static Dispatch가 일어난다.

private을 사용하는 경우에도, 한 파일 안에서만 참조(접근)되는 것이 보장되므로, 컴파일러가 Static Dispatch로 타입을 결정 할 수 있다.

WMO(Whole Module Optimization) 옵션을 활성화한다면 모듈의 파일을 개별적으로 컴파일 하지 않고 모듈 전체를 하나의 덩어리로 취급해서 컴파일 하기 때문에, internal 키워드만으로 다른 모듈에서 override 되지 않음을 보장(final 추론 가능)할 수 있다. (xcode 8부터 default가 활성화)

읽어보면 좋은 레퍼런스들 https://brunch.co.kr/@joonwonlee/14 https://swift.org/blog/whole-module-optimizations/

앱은 responder object를 통해 event를 받고 핸들링합니다. 여기서 responder object는 UIResponder의 인스턴스를 말하는데, UIView, UIViewController, UIApplication의 subsclass들이 일반적으로 responder object가 됩니다.

Responder object는 raw event data를 받고 처리하거나 다른 responder object에게 전달(forwarding) 해야 합니다. app이 event를 받으면 UIKit이 자동으로 적절한 responder object(first respnder)에게 전달합니다.

iOS → App(UIApplication) → (First) Responder object

처리되지 않은 이벤트는 유효한 responder chain 내에서 responder에서 responder로 전달됩니다.

which is the dynamic configuration of your app’s responder objects.

Figure 1 Responder chains in an app

다이어그램은 responder chain에 따라 하나의 responder에서 다른 responder로 어떻게 이벤트가 이동하는지를 나타냅니다.

• text field가 이벤트를 처리하지 못하면, UIKit가 text field의 parent UIView 객체로 이벤트를 보냅니다. = background view
• background view가 window의 root view이면 responder chain이 view가 속한 view controller에게로 전환됩니다(divert). view controller가 window에게 이벤트를 전달합니다.
• window가 이벤트를 처리하지 못하면 UIKit는 이벤트를 UIApplication에 전달합니다.
• 가능하다면, UIApplication은 UIApplicationDelegate에게 이벤트를 전달합니다.
  • UIApplicationDelegate가 UIResponder의 instance 이면서 responder chain이 일어나지 않았을 경우에만

Determining an Event's First Responder

UIKit는 이벤트 타입에 따라 first responder object를 지정합니다.

• touch event — 터치를 받은 view
• press event — focus된 object
• shake motion event — 개발자 (or UIKit)가 지정한 object
• remote control event — 개발자 (or UIKit)가 지정한 object
• editing menu message — 개발자 (or UIKit)가 지정한 object

accelerometers, gyroscopes, magnetometer와 관련된 motion event들은 responder chain를 따르지 않습니다. 대신 Core Motion이 이벤트를 지정된 object에게 directly 전달합니다.

accelerometers : shake gyroscopes : 회전 magnetometer : ?

Controls은 관련된 target object와 action message를 사용해서 직접적으로 커뮤니케이션 합니다. (target- action)

user가 control을 사용해서 상호작용하면 control은 action message를 target object에 보냅니다.

action message는 event가 아니지만, responder chain을 이용합니다.

target object가 nil 이면, UIKit는 action method를 구현한 객체부터 responder chain으로 target을 탐색(traverse)합니다.

UIControl은 action message를 전달할 target을 찾기 위해 responder chain을 이용하기도 한다.

예를 들면, UIKit editing menu가 cut, copy, paste 와 같은 동작을 구현할 responder object를 찾기 위해 responder chain이 일어납니다.

Gesture recognizer가 view보다 먼저 touch and press 이벤트를 받습니다. 뷰의 gesture recognizer가 이벤트를 인식하는데 실패하면 UIKit가 이벤트를 뷰에게 보냅니다.

view가 이벤트를 처리하지 못하면, UIKit는 responder chain에 따라 전달합니다.

Determining Which Responder Contained a Touch Event

UIKit은 view를 기반으로 한 hit-testing으로 touch event가 발생한 뷰를 결정합니다. 특히 view 계층 구조 내 view 객체의 가장자리를 비교해서 결정합니다. hitTest(_:with:) 메소드는 뷰의 hierarchy를 돌면서 가장 깊은 subview를 찾고, 그 객체가 touch event를 받을 first responder가 됩니다.

view를 기반으로 한 hit-testing으로 touch event를 처리할 뷰를 결정한다. hit-testing은 UIView 안에 정의된 hitTest(_:with:) 를 통해 이루어진다.

touch가 발생하면, UIKit은 UITouch object를 생성하고, 뷰와 연결시킵니다. touch 위치 또는 다른 parameters 변화에 따라 UIKit는 동일한 UITouch object를 새로운 정보와 함께 업데이트합니다. 하지만 touch 객체의 view property는 변하지 않습니다. touch가 끝나면 UIKit이 UITouch object를 release 합니다.

touch event가 발생하면 UIKit가 UITouch 객체를 생성해서 (hit-testing을 통해 찾은) view와 연결한다. touch 객체의 view property에 assign. touch 위치가 변하더라도, view 속성 값은 변하지 않는다. touch가 끝나면(touchesEnded()가 호출되면) UIKit가 touch object를 release(메모리에서 해제) 한다.

// UIResponder
func touchesBegan()
func touchesMoved()
func touchesEnded()
func touchesCancelled() // 전화, 문자 등으로 터치 이벤트가 interrupte 된 경우

Altering the Responder Chain

responder object의 next property를 오버라이딩해서 responder chain을 변경할 수 있습니다.

이미 많은 UIKit class들이 next property를 오버라이딩해서 특정 객체를 리턴하고 있습니다. 가령:

• UIView : view가 view controller의 root view라면, next responder는 view controller가 됩니다. 그렇지 않은 경우, next responder는 view의 super view가 됩니다.
• UIViewController : view controller가 window의 root view라면, next responder는 window 객체가 됩니다.
• view controller가 다른 view controller에 의해 present 된 경우에는, next responder는 presenting view controller가 됩니다.
• UIWindow : window 객체의 next responder는 UIApplication 객체입니다.
• UIApplication : next responder는 app delegate가 됩니다. 단, app delegate가 UIResponder의 인스턴스이면서 view, view controller, app 객체 자체가 아닌 경우에만 해당됩니다.

@available(iOS 2.0, *)
open class UIResponder : NSObject, UIResponderStandardEditActions {

  open var next: UIResponder? { get }

  open var canBecomeFirstResponder: Bool { get } // default is NO
  open func becomeFirstResponder() -> Bool

  open var canResignFirstResponder: Bool { get } // default is YES
  open func resignFirstResponder() -> Bool

  open var isFirstResponder: Bool { get }
  // ...
}

Struct, Enum, Class에서 Wrapping 하고 싶은 property 앞에 @State 같은 attribute를 명시해서 사용한다.

Example

WWDC 19 예제 코드, UserDefaults에 값을 저장하고 가져오기 위한 코드가 중복된다.

class UserManager {
  static var useTouchID: Bool {
    get { UserDefaults.standard.bool(forKey: "useTouchID") }
    set { UserDefaults.standard.set(newValue, forKey: "useTouchID") }
  }

  static var userEmail: String? {
    get { UserDefaults.standard.string(forKey: "userEmail") }
    set { UserDefaults.standard.set(newValue, forKey: "userEmail") }
  }

  static var isLoggedIn: Bool {
    get { UserDefaults.standard.bool(forKey: "isLoggedIn") }
    set { UserDefaults.standard.set(newValue, forKey: "isLoggedIn") }
  }
}

Property Wrapper를 이용해 중복 코드를 wrapping 해보면 아래와 같고,

@propertyWrapper
struct UserDefault<T> {

  let key: String
  let defaultValue: T

  var wrappedValue: T {
    get { UserDefaults.standard.object(forKey: key) as? T ?? defaultValue }
    set { UserDefaults.standard.set(newValue, forKey: key) }
  }
}

이를 다음과 같이 사용할 수 있다.

class UserManager {
  @UserDefault(key: "useTouchID", defaultValue: false)
  static var useTouchID: Bool

  @UserDefault(key: "userEmail", defaultValue: nil)
  static var userEmail: String?

  @UserDefault(key: "isLoggedIn", defaultValue: false)
  static var isLoggedIn: Bool
}

➕

DI에 활용

• DIContainer 객체로부터 인스턴스를 get 하는 로직을 Property wrapper로 감싼 예제이다.
• ViewController 안에서 View Model를 생성하지 않고 주입받을 수 있다.

@propertyWrapper
struct Dependency<T> {
  var wrappedValue: T {
    DIContainer.shared.resolve()
  }
}

// in ViewController
@Dependency var moviesViewModel: MoviesViewModel

정리

property 앞에 attribute가 붙으면, Property Wrapper의 wrappedValue로 사용하겠다는 의미이다. Property Wrapper를 사용해서 코드의 중복을 줄일 수 있다.

Property Wrapper [DI] DI Container, IOC Container 개념과 예제

Class

• 클래스는 단일 상속만 가능하다.
• instance / type method, instance / type property를 갖는다.
• reference 타입이다.
  • 클래스의 인스턴스는 전달될 때 포인터를 전달한다 = 전달되는 곳 어디서든 원본에 접근이 가능함

class Point {
    var x = 0.0
    var y = 0.0
}

let point = Point()
var comparePoint = point // 인스턴스를 복사
comparePoint.x = 5
print(comparePoint.x, point.x) // 5.0, 5.0

Struct

• 구조체는 상속이 불가능하다.
• instance / type method, instance / type property를 갖는다.
• value 타입이다.
  • 구조체의 인스턴스는 복사된다.(쓰기 시 복사 방식, 값이 실제로 변경(set)될 때 실제 복사가 이뤄짐, 원본이 변경되지 않음)
  • 상속은 불가능하지만, 프로토콜 채택은 가능하다.

    struct Point {
    var x = 0.0
    var y = 0.0
    }
    

let point = Point() var comparePoint = point // 인스턴스를 복사 comparePoint.x = 5 print(comparePoint.x, point.x) // 5.0, 0.0

### Class and Struct
-  서로 다른 자료형을 하나로 묶는다.
-  이렇게 묶은 자료형들을 새로운 type으로 사용할 수 있다.
-  클래스와 구조체 안에서 함수와 프로퍼티를 정의할 수 있다.
-  extension이 가능하다.

### Example code
```swift
/* struct */
struct Sample {
    // 가변 프로퍼티(값 변경 가능)
    var mutableProperty: Int = 100

    // 불변 프로퍼티(값 변경 불가능)
    let immutableProperty: Int = 100

    // 타입 프로퍼티(static 키워드 사용: 타입 자체가 사용하는 프로퍼티)
    static var typeProperty: Int = 100

    // 인스턴스 메서드(인스턴스가 사용하는 메서드)
    func instanceMethod(){
        print("instance method")
    }

    // 타입 메서드(static 키워드 사용: 타입 자체가 사용하는 메서드)
    static func typeMethod(){
        print("type method")
    }
}

var mutable: Sample = Sample() // 가변 인스턴스 생성
//인스턴스에서는 타입 프로퍼티나 타입 메서드를 사용할 수 없음
//mutable.typeProperty = 400 // 컴파일 오류
//mutable.typeMethod() // 컴파일 오류

Sample.typeProperty = 300 //구조체의 타입 프로퍼티 사용(새로운 value 할당)
Sample.typeMethod // type method //구조체의 타입 메서드 호출

let immutable: Sample = Sample() // 불변 인스턴스 생성
//immutable.mutableProperty = 200 // 불변 인스턴스는 가변 프로퍼티라도 인스턴스 생성 후 수정 불가 // 컴파일 오류

/* note */
// 타입(static) or 인스턴스 분류할 수 있고, 
// 타입은 그 자체로, 인스턴스는 생성 후 사용 가능함을 의미한다.

/* class */
// class의 type method는 상속 시 override 할 수 없다.

class SuperClass {
    // 인스턴스 메서드
    func instanceMethod(){
        print("instance method")
    }

    // 타입 메서드(상속 시 override 불가능)
    static func typeMethod(){
        print("type method")
    }
}

class SubClass: SuperClass {
    override func instanceMethod() {
        print("override instance method")
    }  
}

var superClass: SuperClass = SuperClass()
superClass.instanceMethod() // prints "instance method"

var subClass: SubClass = SubClass()
subClass.instanceMethod() // prints "override instance method"

Conclusion

• 구조체는 클래스에 비해 시스템 리소스를 적게 사용한다.
• 자료형을 캡슐화하는 것이 주목적이라면 구조체를 사용하는 것을 권장
• 상속이 필요없고, 인스턴스 전달 시 참조보다는 복사가 예상될 경우 구조체 사용을 권장
• 그 외의 경우 클래스를 사용 - 대부분의 사용자 데이터는 클래스로 정의되어야 한다.

References

https://zeddios.tistory.com/12 https://developer.apple.com/documentation/swift/choosing_between_structures_and_classes

Declaration

class URLSession : NSObject

Overview

URLSession class와 관련 class들은 URL을 통해 데이터를 다운로드, 업로드하기 위한 API를 제공합니다. 또한, App이 실행(running) 중이 아니거나, 중지되더라도 background에서 다운로드할 수 있도록 지원합니다.

URLSessionDelegate, URLSessionTaskDelegate를 사용해서 authentication을 지원하거나 redirection, task completion 같은 이벤트를 받도록 할 수 있습니다.

Note The URLSession API involves many different classes that work together in a fairly complex way which may not be obvious if you read the reference documentation by itself. Before using the API, read the overview in the URL Loading System topic. The articles in the Essentials, Uploading, and Downloading sections offer examples of performing common tasks with URLSession.

URLSession API는 다양한 class들과 함께 작업하기 때문에, API를 사용하기 전에 URL Loading System topic에 대한 overview를 먼저 읽어보십시오.

Your app creates one or more URLSession instances, each of which coordinates a group of related data-transfer tasks. For example, if you’re creating a web browser, your app might create one session per tab or window, or one session for interactive use and another for background downloads. Within each session, your app adds a series of tasks, each of which represents a request for a specific URL (following HTTP redirects, if necessary).

Types of URL Sessions

The tasks within a given URL session share a common session configuration object, which defines connection behavior, like the maximum number of simultaneous connections to make to a single host, whether connections can use the cellular network, and so on.

URLSession에 추가된 task는 common session co nfiguration를 공유하는데, 연결 동작을 정의합니다.(connection behavior) 예를 들면, 하나의 호스트에 동시에 연결될 수 있는 최대 개수나 연결이 cellular network를 사용할 수 있는지 등이 있습니다.

URLSession은 singleton 세션인 shared를 제공하는데, 이것은 configuration object가 없습니다. 세션을 만들 때, 커스터마이징이 가능하지 않지만 basic request와 같은 제한적인 요청을 할 때 사용하기 좋습니다. shared가 아닌 다른 세션을 만들 때는 다음 세 가지 중 하나의 configuration을 지정해야 합니다:

• default : shared 세션과 비슷하게 동작하지만, delegate를 지정할 수 있습니다. (to obtain data incrementally)
• Ephemeral : 캐시, 쿠기, credential 정보를 디스크에 쓰지(write)하지 않습니다.
• Background : app이 실행 중이 아닐 때, background에서 업로드, 다운로드 task를 수행합니다.

Using a Session Delegate

Session Delegate를 구현해서 다양한 이벤트가 발생했을 때 정보를 얻을 수 있습니다. 예를 들면:

• Authentication fails. -- 인증에 실패할 때
• Data arrives from the server. -- 서버로부터 데이터가 내려왔을 때
• Data becomes available for caching. -- 데이터를 캐싱해야 할 때

만약 delegate로 부터 제공되는 기능이 필요 없다면, 세션을 생성할 때 nil을 넘겨서 delegate 없이 API를 사용할 수 있습니다.

Important session 객체는 delegate와 강한 참조 관계이므로, session을 invalidate 하지 않으면 app이 종료되게 전까지 memory leak이 발생할 것입니다.

Each task you create with the session calls back to the session’s delegate, using the methods defined in URLSessionTaskDelegate. You can also intercept these callbacks before they reach the session delegate by populating a separate delegate that’s specific to the task.

Asynchronicity and URL Sessions

URLSession API는 비동기로 동작합니다.

• In Swift or Objective-C, completion handler block를 제공해서 task가 완료되었을 때 실행할 작업을 전달할 수 있습니다.
• In Swift or Objective-C, delegate method를 사용해서 전송이 진행 중이거나 완료된 직후 callbacks을 받을 수 있습니다.

Thread Safety

URLSession은 thread-safe 하기 때문에, 어떤 thread context 에서도 session을 생성할 수 있습니다. 만약, delegate method가 completion handlers를 호출한다면, 작업은 자동으로 알맞은 delegate queue에 스케줄링될 것입니다. When your delegate methods call the provided completion handlers, the work is automatically scheduled on the correct delegate queue.

Dependency

의존성이란 하나의 객체가 다른 객체에 강하게 결합(coupling)되어 있는 것을 의미한다. 다음 예제에서 Vehicle class의 init 안에서 RaceCarEngine class를 생성하고 있기 때문에, Vehicle class는 RaceCarEngine class와 강하게 결합하고 있는 구조이다.

class Vehicle
{
    var engine: Propulsion

    init() {
        engine = RaceCarEngine()
    }

    func forward() {
        engine.move()
    }
}

Dependency Injection

이렇게 객체 간 강하게 결합되어 있는 구조는 모듈화 되지 않으므로, 코드의 유지보수에 좋지 않다. 결합도를 낮출 수 있게 개선해보면 다음과 같다:

class Vehicle
{
    var engine: Propulsion

    init(engine: Propulsion) {
        self.engine = engine
    }

    func forward() {
        engine.move()
    }
}

init 안에서 파라미터로 Propulsion 타입을 주입(Injection)받음으로써, Vehicle class가 더 이상 RaceCarEngine class를 알지 않도록 바뀌었다!

이제, 아래와 같이 Vehicle class의 engine으로 RaceCarEngine 외에 다른 class를 주입할 수 있게 되었다:

let rocket = RocketEngine()

var car = Vehicle(engine: rocket)
car.forward()

이처럼 _Protocol_과 _init_을 이용해 의존성을 주입하게 되면...

• (when rocket engine class isn’t ready yet) 테스트 목적으로 fake class를 만들어 사용할 수 있고,
• 객체 간 결합도가 낮아졌으므로, Protocol을 따르는 어떤 class든 주입할 수 있다(unit testing).

의존성 주입을 위해 반드시 Protocol을 사용해야 하는 것은 아니다. subclassing이나, generic, opaque type을 활용할 수도 있다.

정리하면🙂

• 의존성 주입은 객체 간 강한 결합(coupling)을 피하기 위해 사용한다.
• 의존성을 주입함으로써 unit test가 용이해진다.

• https://learnappmaking.com/dependency-injection-swift/

.xib .nib

.xib는 XML(태그 형태의 마크업 언어)로 이루어진 파일로, XCode가 인터페이스 빌더를 통해 시각적으로 제어 가능하도록 제공하고 있다. .xib 파일을 컴파일한 것이 .nib 파일이다.

UINib

UINib class는 nib 파일의 컨텐츠를 래핑하는 객체다. An object that contains Interface Builder nib files.

UINib 객체는 nib 파일의 컨텐츠(view)를 메모리에 캐시하고 있다가, instantiate할 때(.instantiate) 언아카이빙한다. A UINib object caches the contents of a nib file in memory, ready for unarchiving and instantiation.

let nib = UINib(named: "Name", bundle: nil)
let contents = nib.instantiate(withOwner: self, options: nil)

loadNibNamed

UINib class로 nib 파일을 로드하는 방법말고도, Bundle class에 정의된 loadNibNamed 메서드를 통해 로드할 수 있다.

func loadFromNib() -> UIView? {
        guard let view = Bundle.main.loadNibNamed(name, owner: nil, options: nil)?.first as? UIView else {
            return nil
        }
        return view
    }

File's Owner

모든 nib 파일에는 File's Owner 객체가 정의되어 있는데, File's Owner로 지정한 객체는 nib 파일 내 뷰와 연결될 수 있다. 즉, outlet과 IBAction으로 연결할 수 있다. 주로 View Controller 객체가 File's Owner가 된다.

storyboard

storyboard는 xib의 번들(여러 xib가 모인 것)이다.

references

• docs
• blog

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

}

UIWindow 객체는 UIView를 상속하는데, 공식 문서에서는 다음 두 가지 상황에서만 windows 사용해야 한다고 설명하고 있다.

@MainActor class UIWindow : UIView

• app의 컨텐츠를 표시하기 위해 mian window를 제공해야 하거나
• 추가적인 컨텐츠를 표시하기 위해 추가 window를 생성해야 할 때

You use windows only when you need to do the following: Provide a main window to display your app’s content. Create additional windows (as needed) to display additional content.

app의 컨텐츠를 표시하기 위한 mian window는 Xcode 템플릿이 스토리보드를 이용해 자동으로 제공해주고 있다. 따라서, Main 스토리보드를 사용하지 않는다면 직접 window 객체를 생성해야 한다.

그 외에 iOS 13부터 지원하는 멀티 윈도우를 구현하려면 window 객체를 추가로 생성해야 한다. 멀티 윈도우는 주로 또 따른 스크린에 컨텐츠를 표시하기 위해 사용된다. (extra windows are commonly used to display content on an external screen, as described in Displaying Content on a Connected Screen.)

UIWindow 객체를 다음과 같은 작업을 할 때 사용할 수도 있다.

• window의 z축을 설정해서 다른 윈도우들 사이에서 보이기(visibility)를 조정할 때
• window를 표시해서 키보드의 타겟이 되도록 할 때
• window 좌표를 바꾸거나, window의 좌표계를 기준으로 다른 좌표를 설정할 때
• window의 root view controller를 변경할 때
• window가 표시되고 있는 스크린은 변경할 때

• Setting the z-axis level of your window, which affects the visibility of the window relative to other windows.

• Showing windows and making them the target of keyboard events.
• Converting coordinate values to and from the window’s coordinate system.
• Changing the root view controller of a window.
• Changing the screen on which the window is displayed.

한 줄 요약.😉 UIWindow는 UIView를 상속받는 app의 컨테이너 뷰로, app의 컨텐츠를 표시하거나 연결된 다른 스크린에 표시하기 위한 추가 window가 필요할 때 사용된다.

application life cycle은 app의 시작부터 종료까지 발생하는 event의 연속이다.

Steps involved from device reboot to app launch:

phone을 켜고 app icon을 터치하면 SpringBoard가 app을 실행한다(launch).

SpringBoard is the standard application that manages the iPhone’s home screen. Other tasks include starting WindowServer, launching and bootstrapping applications and setting some of the device’s settings on startup

SpringBoard가 app의 launch screen을 보여주는 동안, 우리의 앱은 필요한 라이브러리들을 로드에서 메모리 위로 올린다. 그리고 app이 실행되고 application delegate가 notifications을 받게된다.

AppDelegate가 application delegate이다. AppDelegate는 UIResponder class를 상속받고, UIApplicationDelegate 프로토콜을 구현하고 있다.

class AppDelegate: UIResponder, UIApplicationDelegate { ... }

_UIApplicationDelegate_를 구현해서 user events(such as app launch, app goes into background or foreground, app is terminated, a push notification was opened etc.)에 대한 알림을 받도록 한다.

_UIResponder_를 상속받아서 AppDelegate가 user events에 반응할 수 있게 하고, UIApplicationDelegate의 delegate가 AppDelegate이 되도록 한다.

Summary

• SpringBoard라는 기본 앱이 app icon을 터치하면 app을 실행하고(@main 호출)
• @main(entry point into app)이 실행되며 AppDelegate object가 생성되고, application의 delegate가 되며,
• (app) event cycle을 manage 한다.

Execution States for Apps:

• Not Running state : The app has not been launched or terminated by the system.
• Inactive state : The app is entering the foreground state but not receiving events.
• Active state: The app enters the foreground state and can process event.
• Background state : In this state, if there is executable code, it will execute and if there is no executable code or the execution is complete, the application will be suspended immediately.
• Suspended state : The app is in the background(in memory) but is not executing code and if system does not have enough memory, it will terminate the app.

AppDelegate가 app의 실행 상태(State)에 따라 cycle을 돌면서 manage 한다.

Not Running : app이 실행되지 않았거나 시스템에 의해 종료된 상태 Inactive : app이 foreground 상태에 진입했지만, (user) event를 받지는 못하는 상태 Active: pp이 foreground 상태에 진입했지만, (user) event를 처리할 수 있는 상태 Background : 이 상태에서는 실행 가능한 코드가 있더라도 즉시 중지된다. Suspended : app이 background 상태에 있으면서 실행 가능한 코드가 없을 때, 시스템이 충분한 메모리가 없으면 app을 중지시킨다.

Interview Questions on App life cycle:

• 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있는가? background 상태에서는 코드가 실행되지 않고 즉시 중지된다. foreground 상태이더라도 Active 상태여야 event를 처리할 수 있다.

• 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오. 앱의 상태는 Not Running, Inactive, active, background, Suspended로 구분할 수 있는데, UIApplicationDelegate 프로토콜을 채택하여 AppDelegate가 구현한 메서드 안에서 상태에 따른 동작을 처리할 수 있다.

• SceneDelegate에 대해 설명하시오. iOS 13부터 추가된 객체로, iOS가 멀티 윈도우를 지원하게 되면서 AppDelegate의 역할 일부를 SceneDelegate가 하도록 변경되었다. SceneDelegate는 UISceneDelegate의 subclass인 UIWindowSceneDelegate를 채택하며, app life cycle에 따른 동작을 관리할 수 있다.

struct Room: Decodable {
    let hotelID: Int
    let title: String
    let price: Double
    let wishlist: Bool
    let longitude: Double
    let latitude: Double
    let rate: Int
    let options: [String]
    let img: String
}

json data를 모델 객체로 decoding 할 때 해당하는 key가 없는 경우, init(from decoder: Decoder)을 직접 구현해서 처리할 수 있다.

// 다음과 같이 데이터가 내려올 경우
[
    {
        "hotelId": 1,
        "title": "title",
        "price": 100,
        "wishlist": false,
    }
]

init(from decoder: Decoder) throws {
  // 구현부를 작성.
}

CodingKeys를 정의하고, decodeIfPresent를 이용해 key가 없을 경우에 기본 값을 정의한다.

enum CodingKeys: String, CodingKey {
        case hotelID = "hotelId"
        case title, price, wishlist, longitude, latitude, rate, options, img
    }

init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    hotelID = try container.decode(Int.self, forKey: .hotelID)
    title = try container.decode(String.self, forKey: .title)
    price = try container.decode(Double.self, forKey: .price)
    wishlist = try container.decode(Bool.self, forKey: .wishlist)
    longitude = try container.decodeIfPresent(Double.self, forKey: .longitude) ?? 0
    latitude = try container.decodeIfPresent(Double.self, forKey: .longitude) ?? 0
    rate = try container.decodeIfPresent(Int.self, forKey: .longitude) ?? 0
    options = try container.decodeIfPresent([String].self, forKey: .options) ?? []
    img = try container.decodeIfPresent(String.self, forKey: .options) ?? ""
}

decodeIfPresent 대신 decode를 사용할 수도 있다.

longitude = (try? container.decode(Double.self, forKey: .longitude)) ?? 0

decodeIfPresent는 optional, decode은 non-optional 타입을 리턴한다.

decodeIfPresent Return Value: A decoded value of the requested type, or nil if the Decoder does not have an entry associated with the given key, or if the value is a null value.

정리🙃. model(struct, class)의 속성을 optional로 정의하고 싶지 않으면서, decoding 시 keyNotFound error를 핸들링하기 위해 init(decoder:) 구현부를 직접 작성할 수 있다.

ref. https://jinnify.tistory.com/71 https://zeddios.tistory.com/577

1️⃣ TargetApp - Info - URL Scheme(Authorization callback URL) 설정하기

2️⃣ UIApplication.shared.open(url:)으로 url 열기

let clientID = "a1b2c3d4"
let scope = "repo gist user" 
let urlString = "https://github.com/login/oauth/authorize" 
var components = URLComponents(string: urlString)! 
components.queryItems = [URLQueryItem(name: "client_id", value: self.clientID),
             URLQueryItem(name: "scope", value: self.scope)] 
UIApplication.shared.open(url)

3️⃣ login 성공 후 redirect, Github으로 부터 리턴받은 code를 가지고 access token 얻기

// SceneDelegate.swift

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        if let url = URLContexts.first?.url {
            print(url)
            let code = url.absoluteString.components(separatedBy: "code=").last ?? ""
            print(code)
            requestAccessToken(with: code)
        }
    }

    func requestAccessToken(with code: String) {
        let url = "https://github.com/login/oauth/access_token"
        let parameters = ["client_id": APIRequestManager.clientID,
                          "client_secret": APIRequestManager.clientSecret,
                          "code": code]
        var request = URLRequest(url: URL(string: url)!)
        request.httpMethod = "POST"
        request.addValue("application/json", forHTTPHeaderField: "Content-Type")
        request.addValue("application/json", forHTTPHeaderField: "Accept")
        guard let bodyData = try? JSONSerialization.data(withJSONObject: parameters, options: .prettyPrinted) else { return }
        request.httpBody = bodyData

        URLSession.shared.dataTask(with: request, completionHandler: { (data, response, error) in
            guard let data = data else { return }
            guard let json = try? JSONSerialization.jsonObject(with: data, options: []) else { return }
            print(json)
            if let data = json as? [String: Any] {
                // handle data
            }
        }).resume()
    }

방법2 - ASWebAuthenticationSession

• ASWebAuthenticationSession 객체 생성하기
• ASWebAuthenticationPresentationContextProviding 프로토콜 채택해서 presentationAnchor 함수 구현하기

class LoginViewController: UIViewController {

    var authenticationSession: ASWebAuthenticationSession?
    let authURL = URL(string: "https://github.com/login/oauth/authorize?client_id=\(APIRequestManager.clientID)")
    let callbackUrlScheme = "baseballapp"

    override func viewDidLoad() {
        super.viewDidLoad()
    }

    private func auth() {
        authenticationSession = ASWebAuthenticationSession.init(url: authURL!, callbackURLScheme: callbackUrlScheme, completionHandler: { (callbackURL:URL?, error:Error?) in
                print(callbackURL)
                guard error == nil,
                    let callbackURL = callbackURL,
                    let queryItems = URLComponents(string: callbackURL.absoluteString)?.queryItems,
                    let code = queryItems.first(where: { $0.name == "code" })?.value else {
                    print("An error occurred when attempting to sign in.")
                    return
                }
            self.requestAccessToken(with: code)
        })
        authenticationSession?.presentationContextProvider = self
        authenticationSession?.start()
    }

    func requestAccessToken(with code: String) {
        let url = "https://github.com/login/oauth/access_token"
        let parameters = ["client_id": APIRequestManager.clientID,
                          "client_secret": APIRequestManager.clientSecret,
                          "code": code]
        var request = URLRequest(url: URL(string: url)!)
        request.httpMethod = "POST"
        request.addValue("application/json", forHTTPHeaderField: "Content-Type")
        request.addValue("application/json", forHTTPHeaderField: "Accept")
        guard let bodyData = try? JSONSerialization.data(withJSONObject: parameters, options: .prettyPrinted) else { return }
        request.httpBody = bodyData

        URLSession.shared.dataTask(with: request, completionHandler: { (data, response, error) in
            guard let data = data else { return }
            guard let json = try? JSONSerialization.jsonObject(with: data, options: []) else { return }
            print(json)
            if let data = json as? [String: Any] {
                // handle data
            }
        }).resume()
    }

    @IBAction func login() {
        auth()
    }
}

extension LoginViewController: ASWebAuthenticationPresentationContextProviding {

    func presentationAnchor(for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
        return self.view.window ?? ASPresentationAnchor()
    }
}

https://d2.naver.com/helloworld/24942 https://medium.com/@jungkim/앱에서-oauth2-연동하기-dadcce91e921 https://www.raywenderlich.com/19364429-implementing-oauth-with-aswebauthenticationsession https://zeddios.tistory.com/1102 and... https://deptno.github.io/posts/2018/Github-OAuth-404/

iOS 13+ 부터 UITableViewDataSource을 대신해 table view에 어떤 cell을, 얼마나(how many), 어느 section에 display 할 지 등을 configure 할 수 있는 UITableViewDiffableDataSource가 지원됩니다. (UICollectionViewDiffableDataSource도 마찬가지)

기존 UITableViewDataSource를 사용하는 방식과 가장 큰 차이점은 reloadData, performBatchUpdates가 없다는 것입니다.

UITableViewDiffableDataSource은 data에 변화가 생길 경우, update 이전과 이후를 비교해서 animate 합니다.

The diffable part of UICollectionViewDiffableDataSource means that whenever you update the items you’re displaying, the collection view will automatically calculate the difference between the updated collection and the one previously shown. This will in turn cause the collection view to animate the changes, such as updates, insertions and deletions.

Benefits

UITableViewDiffableDataSource를 사용해서 얻는 이점은

• data 변화를 사용자가 인지할 수 있는 애니메이션이 지원됩니다.
• 자동으로 데이터가 동기화(synchronization) 됩니다.
• 전체적으로 작성하는 코드의 양을 줄일 수 있습니다.

• Automatic data change animations: Whenever you add, update or delete data, you can get the data change animation automatically.

• Automatic data synchronization: To utilize collection view’s standard animation without UICollectionViewDiffableDataSource, you’d have to manually manage and synchronize data changes between the collection view and the data source. If you have a misalignment in one of the synchronization operations, you’d see an error like this: Assertion error because the collection view update is invalid
• Reduced code: Overall, you can write less code and benefit from the collection view’s data change animations and data synchronization.

Using Diffable Data Source

• Hashable section, item

• UICollectionViewDiffableDataSource
• NSDiffableDataSourceSnapshot

1️⃣ Hashable Section type, Item type 선언

UITableViewDiffableDataSource<SectionIdentifierType, ItemIdentifierType> : NSObject where SectionIdentifierType : Hashable, ItemIdentifierType : Hashable

UITableViewDiffableDataSource은 위와 같은 형태의 generic class이므로, section과 item이 될 Hashable한 객체를 선언해야 합니다. UITableViewDiffableDataSource은 Snapshot 객체를 이용해 data의 변화를 감지하는데, Snapshot이 indexPath 대신 unique identifiers에 의존하기 때문에 section과 item type은 Hashable protocol을 준수하는 타입이어야 합니다.

class Section: Hashable {
    var id = UUID()
    var title: String
    var item: [Dish]

    init(title: String, item: [Dish]) {
        self.title = title
        self.item = item
    }

    func hash(into hasher: inout Hasher) {
       hasher.combine(id)
     }

     static func == (lhs: Section, rhs: Section) -> Bool {
       lhs.id == rhs.id
     }
}


class Dish: Decodable {
    let detailHash: String
    let title: String
}

extension Dish: Hashable {
    static func == (lhs: Dish, rhs: Dish) -> Bool {
        return lhs.detailHash == rhs.detailHash
    }

    func hash(into hasher: inout Hasher) {
        hasher.combine(detailHash)
    }
}

2️⃣ UITableViewDiffableDataSource 생성 UITableViewDiffableDataSource의 initializer로

• dataSource와 연결할 tableView와,

• cellProvider(escaping closure 형태)를 제공해야 합니다. UITableViewDataSource의 cellForRowAt: 메서드를 구현하는 것과 유사합니다.

  func makeDataSource() -> UITableViewDiffableDataSource<Section, Dish> {
    let reuseIdentifier = cellReuseIdentifier
    return UITableViewDiffableDataSource(
        tableView: tableView,
        cellProvider: { tableView, indexPath, dish in
            let cell = tableView.dequeueReusableCell(
                withIdentifier: reuseIdentifier,
                for: indexPath)
  
            cell.textLabel?.text = dish.title
  
            return cell
        }
    )
  }

  3️⃣ NSDiffableDataSourceSnapshot 생성 NSDiffableDataSourceSnapshot 객체를 통해 dataSource가 data의 변화를 감지합니다.

  func updateSnapshot(animatingChange: Bool = false) {
    var snapshot = NSDiffableDataSourceSnapshot<Section, Dish>()
  
    snapshot.appendSections(sections)
    sections.forEach { section in
      snapshot.appendItems(section.item, toSection: section)
    }
    dataSource.apply(snapshot, animatingDifferences: animatingChange)
  }

https://www.appcoda.com/diffable-data-source/ https://www.raywenderlich.com/8241072-ios-tutorial-collection-view-and-diffable-data-source

논리적으로 동시에 여러 일을 하는 것. 멀티스레딩 하는 것을 의미한다. 이에 비해 병렬성(Parallelism) 프로그래밍은 물리적으로(멀티 코어) 동시에 일을 하는 것을 말한다.

Multithread

하나의 프로세스(프로그램이 실행되어 메모리 위로 올라온 것)에는 하나 이상의 스레드가 존재한다(main thread). thread는 코드 실행을 위한 하나의 흐름으로 생각하면 된다. thread를 하나 이상(main) 사용하는 것이 멀티스레딩이다.

Dispatch Queue

iOS는 멀티스레딩을 Queue로 관리하는데 serial, concurrent 2종류가 있다.

• serial queue: 한 번에 하나의 클로저 실행 - main
• concurrent queue: 여러 개의 스레드를 사용해서 동시 실행 - global

Queue(FIFO)를 기반으로 동작하기 때문에 항상 순차적으로 (큐에 먼저 추가된 것부터) task가 실행된다.

Sync, Async

큐에 closure를 추가할 때 두 가지 방법이 있다.

• sync: 클로저가 종료될 때까지 current queue의 실행을 중지한다.(blocking)
• async: current queue의 실행 흐름을 방해하지 않으면서 클로저를 실행한다.

DispatchQueue.main.async {
    // code
}

DispatchQueue.global().sync {
    // code
}

여기서 current queue는 dispatch main queue가 될 수도 있고 background queue가 될 수도 있다.

Current queue? It may not be obvious what the source, or current, queue is, because it’s not always explicitly defined in the code. For example, if you call your sync statement inside viewDidLoad, your current queue will be the Main dispatch queue. If you call the same function inside a URLSession completion handler, your current queue will be a background queue.

DispatchQoS

main queue와 달리 global queue에 접근할 때는 DispatchQoS를 파라미터로 넘길 수 있는데, DispatchQoS는 실행 우선 순위를 의미한다.

The quality of service, or the execution priority, to apply to tasks.

• DispatchQoS.userInteractive : high priority, only do something short and quick
• DispatchQoS.userInitiated : high priority, but might take a little bit of time
• DispatchQoS.default : default quality-of-service class
• DispatchQoS.utility : long-running background processes, low priority
• DispatchQoS.background : not directly initiated by user, so can run as slow as needed

GCD, Dispatch

OS X, iOS는 개발자가 직접 스레드 관리하지 않고도 비동기식으로 작업을 수행할 수 있도록 기술(framework)을 제공한다. GCD는 앱의 스레드와 관련된 코드를 시스템 수준으로 이동시켜서, 필요한 만큼 스레드를 생성하고 작업을 스케줄링한다. GCD는 iOS가 제공하는 멀티스레딩을 위한 Framework 이다.

Dispatch Queue는 GCD의 일부이다. 프로그래머가 실행할 task를 Dispatch Queue에 추가하면 GCD는 task에 맞는 스레드를 자동으로 생성해서 실행하고 작업이 종료되면 스레드를 제거한다.

Operation Queues

동시성 프로그래밍을 위해 Operation Queue를 사용하는 방법도 있다. Dispatch Queue는 항상 FIFO로 작업을 실행하지만, Operation Queue는 작업의 실행 순서를 결정할 때 다른 요인을 고려한다. 이러한 요소 중 가장 중요한 것은 주어진 작업이 다른 작업의 완료 여부에 의존(depends on)하는지 여부이다. task를 정의할 때, 종속성을 구성하고 이를 사용하여 task에 대한 복잡한 실행 순서 그래프를 만들 수 있다. operation queue는 항상 동시(concurrent)에 operation을 실행하지만, 필요에 따라 종속성을 이용해 순차 실행하도록 할 수 있다.

let firstOperation = BlockOperation {
            for i in 1...10 {
                print("👻\(i)")
            }
        }

let secondOperation = BlockOperation {
           for i in 1...10 {
                print("💜\(i)")
            }
        }

let queue = OperationQueue()

// options

// 동시 작업할 operation 개수 지정
// 1로 설정할 경우 하나의 operation이 실행 및 완료된 이후 다음 operation이 실행된다.
queue.maxConcurrentOperationCount = 1

// 의존성 추가
// secondOperation이 끝나고 firstOperation을 수행
firstrOperation.addDependency(secondOperation)

// add queue
queue.addOperation(firstOperation)
queue.addOperation(secondOperation)

// 의존성을 추가한 경우 다음과 같이 출력된다.
💜1
💜2
💜3
💜4
💜5
💜6
💜7
💜8
💜9
💜10
👻1
👻2
👻3
👻4
👻5
👻6
👻7
👻8
👻9
👻10

Dispatch Queue vs. Operation Queue

• Operation Queue에서는 동시에 실행할 수 있는 Operation의 최대 수를 지정할 수 있다.
• Operation Queue에서는 KVO(Key Value Observing)을 사용할 수 있는 많은 프로퍼티들이 있다.
• Operation Queue에서는 Operation을 일시 중지, 다시 시작 및 취소를 할 수 있다.
• Operation Queue는 KVO를 사용해 작업 진행 상황을 감시해야 할 경우 적합하다.
• Dispatch Queue는 작업이 복잡하지 않고 간단한 이벤트를 비동기적으로 처리할 때 적합하다.

Concurrency Programming Operation sync vs async See also... Combine

Codable

Codable typealias Codable = Encodable & Decodable

• Encodable -- 객체를 원하는 데이터 형태로 변환(encoding)
• Decodable -- 데이터를 모델 객체로 변환(decoding)

class, struct, enum에 모두 Codable protocol을 채택할 수 있다.

CodingKey Protocol

CodingKey 프로토콜을 채택해서 json 데이터의 key와, 속성의 이름과 다르게 지정할 수 있다.

Decodable

decoder를 이용해서 init()을 구현할 수 있다. (JSON으로부터 데이터 빼내기)

extension User: Decodable {
    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        id = try container.decode(Int.self, forKey: .id)
        name = try container.decode(String.self, forKey: .name)
        birth = try container.decode(String.self, forKey: .birth)
        phoneNum = try container.decode(String.self, forKey: .phoneNum)
    }
}

Encodable

decode와 반대로 encode 함수를 작성한다.

// encode 함수 직접 구현
func encode(to encoder: Encoder) throws {
    var container = encoder.container(keyedBy: Codingkeys.self)
    try contrainer.encode(someDate, forKey: .someDate)
}

Codable은 속성의 타입이 지정되어 있는(Int, String...) 경우에만 사용할 수 있다. struct 안의 struct를 갖고 있거나, Any 타입을 속성으로 갖고 있는 타입은 Codable을 채택할 수 없다.

Read Data from Arrays

배열 형태로부터 Data를 얻는 예제는 다음과 같다.

let json = """
[
    {
        "name": "Banana",
        "points": 200,
        "description": "A banana grown in Ecuador."
    },
    {
        "name": "Orange",
        "points": 100
    }
]
""".data(using: .utf8)!

struct GroceryProduct: Codable {
    var name: String
    var points: Int
    var description: String?
}

let decoder = JSONDecoder()
let products = try decoder.decode([GroceryProduct].self, from: json)

See Also

• Article

NSCoding

다이나믹하게 다형성으로 동작하는 방식이 필요한 경우에는 NSCoding 프로토콜을 사용하는 것이 권장된다. (Codable과 동시에 채택도 가능하다)

class NBeverage : NSObject, NSCoding {
    private var brand : String = ""
    required init?(coder: NSCoder) {
        self.brand = coder.decodeObject(forKey: "brand") as! String
    }

    func encode(with coder: NSCoder) {
        coder.encode(brand, forKey: "brand")
    }
}

required init과 encode 메서드 구현이 필요하다.

NSKeyedArchiver

NSCoding 프로토콜을 채택한 객체는 NSKeyedArchiver로 인코딩, NSKeyedUnarchiver로 디코딩한다. 아카이브 한 결과는 Data 타입이 되고, json 형식은 불가능하다. (json 형식으로 데이터를 전송하려면 UserDefault or Plist 파일을 이용해서 저장하는 방법이 있다)

static func unarchive(with text: Data) -> Any? {
        do {
            let object = try NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(text)
            return object
        }
        catch {
            print(error)
        }
        return nil
    }

    static func archive<T>(with things: T) -> Data {
        do {
            let archived = try NSKeyedArchiver.archivedData(withRootObject: things, requiringSecureCoding: false)
            return archived
        }
        catch {
            print(error)
        }
        return Data()
    }

Codable과 NSCoding의 차이는 다음 블로그 글을 참고😉

• https://codesquad-yoda.medium.com/codable-vs-nscoding-차이점-4b47e240c0b8

https://shark-sea.kr/entry/Swift-Codable-알아보기

Metatype Type

_-meta_는 추상화를 의미하는 접두어. 어떤 class, struct, enum에 .Type을 붙여 타입을 타입으로 추상화한 것이 metatype 이다.

_결국 Metatype도 Type이다. _

• class의 metatype : SomeClass.Type
• protocol의 metatype : SomeProtocol.Protocol

metatype을 구하고 싶다면 타입 뒤에 .self를 붙이면 된다. SomeClass.self

type(of:)

Generic Function type(of:) Returns the dynamic type of a value.

스위프트 표준 라이브러리에서 제공하는 type(of:) 함수를 이용해서 Metatype을 구할 수도 있다.

func type<T, Metatype>(of value: T) -> Metatype

간단한 예제.

var number = 5
type(of: number) // Int.Type
// 값에 대한 메타 타입을 알려준다.

instance from metatype

Use an initializer expression to construct an instance of a type from that type’s metatype value. For class instances, the initializer that’s called must be marked with the required keyword or the entire class marked with the final keyword.

class AnotherSubClass: SomeBaseClass {
    let string: String
    required init(string: String) {
        self.string = string
    }
    override class func printClassName() {
        print("AnotherSubClass")
    }
}
let metatype: AnotherSubClass.Type = AnotherSubClass.self
let anotherInstance = metatype.init(string: "some string")

ObjectIdentifier

Structure ObjectIdentifier A unique identifier for a class instance or metatype.

class 인스턴스와 metatype만 있는 unique identifier다. struct, enum, function에는 identifier라는 개념이 없다.

식별값을 나타내는 구조체로, .init(AnyObject)로 생성할 수 있다. hashValue를 instance property로 갖고 있다.

This unique identifier is only valid for comparisons during the lifetime of the instance.

In Swift, only class instances and metatypes have unique identities. There is no notion of identity for structs, enums, functions, or tuples.

✔️ 인스턴스의 값을 비교 할 것인지, 타입을 비교할 것인지에 따라 적절히 활용할 것

docs-metatype-type medium-metatype

Protocol Equatable A type that can be compared for value equality.

Equatable 프로토콜을 채택한 타입(class, value, enum)은 ==, != 연산자로 값의 같음, 같지 않음을 비교할 수 있다. 스위프트 표준 라이브러리의 대부분의 기본 데이터 타입은 Equatable 프로토콜을 따르고 있다.

class StreetAddress {
    let number: String
    let street: String
    let unit: String?

    init(_ number: String, _ street: String, unit: String? = nil) {
        self.number = number
        self.street = street
        self.unit = unit
    }
}

extension StreetAddress: Equatable {
    static func == (lhs: StreetAddress, rhs: StreetAddress) -> Bool {
        return
            lhs.number == rhs.number &&
            lhs.street == rhs.street &&
            lhs.unit == rhs.unit
    }
}

Equatable 프로토콜을 준수하기 위해서는 static func == (lhs: StreetAddress, rhs: StreetAddress) -> Bool 함수의 구현부를 작성해야 한다. == 함수 정의에 따라 타입을 비교(같은지, 같지 않은지)할 수 있다.

Hashable

Protocol Hashable A type that can be hashed into a Hasher to produce an integer hash value.

integer 해쉬 값을 가질 수 있는 타입을 의미한다. Hashable Protocol을 준수한 타입은 Dictionary나, Set의 key가 될 수 있다. 다음 hash 메서드를 필수로 구현해야 한다. hash 메서드를 구현해서 hash value를 얻을 수 있다.

func hash(into: inout Hasher)
// Hashes the essential components of this value by feeding them into the given hasher.

Hashable은 Equatable 상속하고 있으므로, == 함수도 필수로 구현해야 한다. == 으로 비교할 때와 HashValue를 사용하는 경우를 이해하고, 비교할 속성을 잘 정의할 수 있어야 한다.

See Also

• Comparable
• Sequence
• defer

https://zeddios.tistory.com/equatable https://velog.io/@dev-lena/Hashable

인터페이스의 layout을 결정하는 것. layout을 설정하는 방법으로 크게 3가지가 있다.

• Frame-Based
• Autoresizing masks
• Auto Layout

Frame Based

• 모든 뷰에 대해 개별적인 설정이 필요하다는 단점이 있다.

  let myView = UIView()
  override func viewDidLoad() {
    myView.frame = CGRect(x: 0, y: 0, width: 200, height: 200)
  }

  Autolayout

  객체 간의 제약 조건으로 layout을 결정하는 것. 스토리보드에서 작업하는 것과 코드로 구현하는 방법이 있는데, 다음은 layout anchor를 이용하여 코드로 autolayout을 잡아준 예제이다.

let myView = UIView()

override func viewDidLoad() {
    super.viewDidLoad()

    myView.translatesAutoresizingMaskIntoConstraints = false
    view.addSubview(myView) // 반드시 오토레이아웃 잡기 전에 서브뷰 해줘야 한다.

    // constraint
    myView.topAnchor.constraint(equalTo: numberOfPlayersSegmentedControl.bottomAnchor,
                                                         constant: 20).isActive = true
    myView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor,
                                                             constant: 20).isActive = true
    myView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor,
                                                              constant: -20).isActive = true
}

Instance Property translatesAutoresizingMaskIntoConstraints A Boolean value that determines whether the view’s autoresizing mask is translated into Auto Layout constraints.

코드로 제약조건을 주기 전에 translatesAutoresizingMaskIntoConstraints를 false로 설정해야 하는데, 그 이유는 코드로 view를 생성했을 경우 기본 true로 설정되어 있고, 그럴 경우에는 view에 제약조건을 추가로 줄 수 없기 때문이다. 따라서, view에 동적으로 autolayout을 주고 싶다면 이 프로퍼티의 값을 반드시 false로 설정해야 한다.

Constraint

오토레이아웃은 기본적으로 선형방정식의 형태로 제약사항을 설정한다.

FirstItem.Attribute = SecondItem.Attribute + Constant

Attribute

• top
• bottom
• leading
• trailing

safeAreaLayoutGuide

위의 코드 예제에서 사용된 safeAreaLayoutGuide는 iOS 11 부터 사용 가능하다. iOS 11 미만의 버전에서는 top/bottomLayoutGuide를 사용한다. safeAreaLayoutGuide는 navigation 또는 status bars 아래에 표시되는 content area의 크기를 알려준다.

UILayoutPriority

UILayoutPriority로 제약조건의 우선순위를 설정할 수 있다. 1에서 1000까지의 값을 가질 수 있지만 Required는 1000, DefaultHigh는 750, DefaultLow는 250의 값으로 사용하는 것이 권장된다. 세 가지 우선순위로 제약조건이 걸려있는 경우 가장 높은 1000부터 우선순위를 가지며, 1000이 없어진 경우 750, 750이 없어진 경우 250, 순차적으로 제약조건이 연결된다.

isActive

Constraint에 isActive 프로퍼티 값으로 제약조건을 활성/비활성화 할 수 있다.

IntrinsicContentSize

UILabel, UIButton, UIImageView 등 대부분의 뷰에는 컨텐츠 고유의 사이즈가 있다. 그래서 레이블을 만들 때 직접 너비와 높이를 지정하지 않아도 고유 사이즈(Intrinsic size)가 있어 자동으로 설정된다. but, 컨테이너 역할을 하는 일부 뷰들은 고유 사이즈가 없기 때문에 가령, UIView를 넣고 오토 레이아웃을 중앙으로 잡으면 오류가 발생한다.

Content Hugging & Compression Resistance

Content Hugging은 고유 사이즈의 최대 크기에 제한을 두는 것. 반면, Compression Resistance는 최소 크기에 제한을 두는 것이다. 즉 Content Hugging와 Compression Resistance에 우선순위를 주어서 고유 사이즈보다 작아질수도, 커질 수도 있다.

✔️예제

+) Scroll View Autolayout

Scroll View에 오토레이아웃을 줄 때에는 contentSize가 반드시 지정되어야 정상적으로 레이아웃을 잡을 수 있다.

https://zeddios.tistory.com/translatesAutoresizingMaskIntoConstraints https://academy.realm.io/kr/posts/ios-autolayout/

커밋은 git 저장소에 작업 디렉토리에 있는 파일의 스냅샷을 기록하는 것. 디렉토리 전체를 복사 붙여넣기 하는 것과 유사하지만 훨씬 유용하다.

git은 커밋을 가능한 가볍게 유지하기 위해 커밋할 때마다 이전 버전과 현재 버전의 변경내역을 저장하고, 이전 커밋을 가리킨다.

$ git commit -m "commit message"

Branch

브랜치는 특정 커밋을 가리키는 포인터다. 따라서 브랜치를 많이 만들어도 메모리나 디스크 공간에 부담이 되지 않는다.

다음 명령어로 브랜치를 생성하면, 현재 작업 중이던 브랜치의 마지막 커밋을 가리키는 브랜치가 생성된다.

$ git branch feature

HEAD

HEAD는 현재 작업 중인 로컬 브랜치를 가리킨다. 위의 브랜치를 만드는 명령어는 브랜치를 새로 만들기만 할 뿐, 현재 작업 중인 브랜치(HEAD의 포인터)를 변경하지는 않는다.

작업할 브랜치를 변경하는 것은 checkout 명령으로 가능하다.

$ git checkout feature

Merge

브랜치 간 병합.

• Fast-forward
• 3-way merge

Fast-forward는 현재 브랜치가 가리키는 커밋이 merge 할 브랜치가 가리키는 커밋의 조상일 경우의 merge 방식이고, 3-way merge는 그렇지 않을 경우이다.

Fast-forward merge는 단순히 머지할 브랜치가 가리키는 커밋으로 포인터를 이동시키는 것 뿐인 반면, 3-way merge는 각 브랜치의 마지막 커밋과 공통 조상의 마지막 커밋을 비교해서 새로운 커밋을 만들고, 브랜치가 그 커밋을 가리키도록 이동시킨다.

Merge Conflict

merge 하려는 두 브랜치에서 동일한 위치의 코드를 수정했을 때, merge conflict가 발생할 수 있다.

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

이 경우, git status로 어떤 파일을 merge 할 수 없었는지 확인할 수 있다.

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

충돌을 해결하기 위해 코드를 수동으로 수정해주어야 하며(올바르지 않은 쪽 코드를 제거하는 등), 수정된 내용을 커밋할 때 merge에 대한 내용으로 자세히 작성해야 한다.

Rebase

브랜치 간 작업을 합치는 또 다른 방법. 리베이스는 기본적으로 커밋들을 모아 복사한 뒤, 다른 곳에 떨궈 놓는다. 리베이스를 하면 커밋의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있다. (rebase는 말그대로 base를 재설정한다는 의미로, 커밋 흐름을 조작하는 것이다)

git rebase 동작 원리 이해하기

Fetch

로컬에는 없지만 remote 저장소에는 있는 데이터(커밋)을 모두 가져오기.

$ git fetch origin

git fetch는 데이터를 로컬로 가져오기만 할 뿐, merge는 하지 않는다. merge 까지 한 번에 하려면 git pull을 사용할 수 있다.

Pull

git fetch + git merge origin main = git pull

https://learngitbranching.js.org/?locale=ko https://git-scm.com/book/ko/v2

• UIKit, UIView API ✔️
• Core Animation API

UIView.animate

• Closure 기반
• 애니메이션이 동작하는 동안 user interface disable

UIView.animate(withDuration: 0.5,
               delay: 0.4,
               options: [.curveEaseOut],
               animations: { [weak self] in
                 self?.view.layoutIfNeeded()
      }, completion: nil)

• options: UIView.AnimationOptions

  • .allowUserInteraction : 애니메이션 중에 user interface를 활성화
  • .repeat : 애니메이션 무한 반복
  • .curveEaseInOut : 빨라졌다가 다시 느려지는 애니메이션 옵션
  • .curveEaseIn : 점점 빨라짐
  • .curveEaseOut : 점점 느려짐
  • .transitionFlipFromLeft : 왼쪽에서부터 뒤집히는 애니메이션
  • .transition~ 시작하는 옵션들은 UIView.transition() 으로 호출해야 한다.

• 애니메이션이 가능한 뷰 속성(animatable property)

  • frame, bounds, center, transform, background, alpha
  • layoutSubviews() 없이 애니메이션 효과가 나타나는, 뷰의 built-in animation 속성들을 의미한다.

View Life Cycle

view의 라이프 사이클을 돌면서 적절하게 animate 함수를 실행한다.

• viewDidLoad : view가 메모리에 올라온 상태 —prepareAnimation()
• viewWillAppear : prepareAnimation()
• viewDidAppear : view가 스크린에 나타난 뒤에 호출, 이 때 애니메이션을 실행 — showAnimation()

func prepareAnimation() {
    nameLabelCenterX.constant -= self.view.bound.width
}

func showAnimation() {
    nameLabelCenterX.constant = 0 // constraint 변경해도 레이아웃을 업데이트하지 않으면 애니메이션 효과가 보이지 않음

    UIView.animate(withDuration: 0.5,
                   delay: 0.3,
                   usingSpringWithDamping: 0.6, // 0 ~ 1.0, 0에 가까울수록 세게
                   initialSpringVelocity: 1.0, // 0 ~ 1.0,  0에 가까울수록 빠르게
                   options: .allowUserInteraction,
                   animations: { self.view.layoutIfNeeded() },
                   completion: nil)

    UIView.transition(with: imageView,
                      duration: 0.3,
                      options: .transitionFlipFromLeft,
                      animations: nil,
                      completion: nil)
}

layoutIfNeeded

UIView의 instance method Lays out the subviews immediately, if layout updates are pending.

layoutIfNeeded는 subview의 레이아웃을 즉시 갱신한다. = layoutSubviews() 호출

layoutSubviews

• 서브뷰의 레이아웃을 즉시 업데이트 시켜주는 메소드
• 호출되면 해당 뷰의 모든 서브뷰들이 layoutSubViews()를 연달아 호출한다.
• 따라서 비용이 많이 드는 메서드. 직접 호출하는 것이 지양된다.
• 이 메소드는 시스템에 의해서 뷰의 값이 다시 계산되어야 하는 시점(update cycle)에 자동으로 호출된다. ✔️
• layoutSubviews를 유도할 수 있는 여러 방법이 존재한다(일종의 layoutSubviews() 호출을 예약하는 행위). ✔️✔️
• layoutSubviews()가 호출되고나면 viewDidLayoutSubviews()가 호출된다.

The update cycle is the point at which control returns to the main run loop after the app finishes running all your event handling code.

아래와 같이 뷰의 레이아웃이 변경될 경우, update cycle에 레이아웃이 업데이트될 수 있도록 시스템이 자동으로 뷰의 업데이트를 예약한다.

• 뷰의 크기를 변경하거나
• 뷰에 서브뷰를 추가하거나
• 사용자가 스크롤뷰를 스크롤 하거나
• 디바이스를 회전시키거나
• 뷰의 오토레이아웃 constraint 값을 변경시켰을 때

시스템이 자동으로 뷰의 업데이트를 예약하는 것 말고, 수동으로 예약하는 방법도 있다.

• setNeedsLayout()
• layoutIfNeeded()

setNeedsLayout

비용이 가장 적게 드는 방법. 이 메서드를 호출한 뷰는 재계산되어야 하는 뷰라고 수동으로 체크되며, update cycle에 layoutSubviews() 호출한다.

layoutIfNeeded

setNeedsLayout과 마찬가지로 수동으로 layoutSubviews를 예약하는 메서드지만, 차이점은 update cycle이 돌 때까지 기다리지 않고 즉시 layoutSubviews()를 호출한다.

https://jinnify.tistory.com/66 https://developer.apple.com/documentation/uikit/uiview/animationoptions https://baked-corn.tistory.com/105