본질의 중요성

결론
iOS는 디바이스 크기 별로 할당되는 content area의 Size classes의 값을 토대로 다이나믹하게 layout 조정을 한다.
- Size classes: 디바이스 별로 시스템이 두개로 정의함 (compact, regular)

Adaptivity and Layout

• In iOS, interface elements and layouts can be configured to automatically change shape and size on different devices, during multitasking on iPad, in split view, when the screen is rotated, and more.
• It’s essential that you design an adaptable interface that provides a great experience in any environment.

Auto Layout

• Auto Layout is a development tool for constructing adaptive interfaces.
• Using Auto Layout, you can define rules (known as constraints) that govern the content in your app.
• Auto Layout automatically readjusts layouts according to the specified constraints when certain environmental variations (known as traits) are detected. 

Layout Guides and Safe Area

Layout guides define rectangular regions that don’t actually appear visibly onscreen, but aid with the positioning, alignment, and spacing of content. The system includes predefined layout guides that make it easy to apply standard margins around content and restrict the width of text for optimal readability. You can also define custom layout guides.

Size Classes

• In iOS, Size Classes are groups of screen sizes that are applied to the width and height of the device screen. 
• The system defines two size classes. The two Size Classes that exist currently are Compact and Regular.
  - The Compact Size Class refers to a constrained space. It is denoted in Xcode as wC (Compact width) and hC (Compact height).
  - The Regular Size Class refers to a non-constrained space. It is denoted in Xcode as wR (Regular width) and hR (Regular height).
  
• As with other environmental variations, iOS dynamically makes layout adjustments based on the size classes of a content area.
  (For example, when the vertical size class changes from compact height to regular height, perhaps because the user rotated the device from landscape to portrait orientation, tab bars may become taller.)

Ref.

https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/

https://www.bignerdranch.com/blog/designing-for-size-classes-in-ios/

용어 정리

Stateless 서버

• Stateful 서버
  Client의 상태를 유지하여 이 정보를 서비스 제공에 이용
  Stateful 서버의 예: 세션을 유지하는 웹서버 ex) 유저가 로그인 시, 세션에 로그인이 되었다는 정보 저장
  메모리 또는 데이터베이스 시스템에 담을 수도 있음.
• Stateless 서버
  Client 상태를 유지하지 않는 것.
  상태 정보를 저장하지 않으면, 서버는 클라이언트측에서 들어오는 요청만으로 작업 처리
  확장성(Scalability)이 높아짐

모바일 어플리케이션에 적합

안전한 API를 만들기 위해 쿠키와 같은 인증 시스템은 이상적이지 않음.

인증정보를 다른 어플리케이션으로 전달

ex) OAuth token: 소셜 계정들을 이용하여 다른 웹서비스에서도 로그인 가능

보안

토큰 기반 인증 시스템은 어플리케이션의 보안을 높힐 수 있음.

왜 사용할까? - 서버 기반 인증의 문제점

• 세션: 유저가 인증을 할 때, 서버는 이 기록을 서버에 저장
  로그인 중인 유저의 수가 늘어난다 => 서버의 램 과부화
  
• 확장성
  (확장? 단순히 서버의 사양을 업그레이드 하는것이 아니라, 더 많은 트래픽을 감당하기 위하여 여러개의 프로세스를 돌리거나, 여러대의 서버 컴퓨터를 추가 하는것)
  세션을 사용하면서 분산된 시스템을 설계하는건 불가능한것은 아니지만 과정이 매우 복잡해집
• CORS(Cross-Origin Resource Sharing)
  세션을 사용하면서 분산된 시스템을 설계하는건 불가능한것은 아니지만 과정이 매우 복잡해짐

토큰 기반 시스템의 작동 원리

1. 유저가 아이디와 비밀번호로 로그인을 합니다
2. 서버측에서 해당 계정정보를 검증합니다.
3. 계정정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급해줍니다.
   여기서 signed 의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature 를 지니고 있다는 것입니다
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때 마다, 해당 토큰을 함께 서버에 전달합니다.
5. 서버는 토큰을 검증하고, 요청에 응답합니다.

웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달합니다.

토큰의 장점

무상태, 확장성, 보안성, 여러 플랫폼 및 도메인, 웹 표준 기반

Ref.

https://velopert.com/2350

세 가지 패턴이 나오게 된 배경

하나의 객체가 다른 객체와 소통은 하지만 묶이기(coupled)는 싫을 때

세 패턴 모두 특정 이벤트가 일어나면 원하는 객체에 알려주어 해당되는 처리를 하는 방법을 가지고 있다. 

하지만, 다른 객체와 종속되어 동작하는 것은 '재사용성'과 '독립된 기능 요소' 측면에서 바람직하지 않다.

그러므로, Delegateion, Notification, KVO를 사용한다.

Delegate vs. Notification vs. KVO 장단점 비교

Delegate

• Protocol로 정의 (java의 interface => 규약)
• Delegate 역할을 하려는 객체는 이 Protocol을 따르며 원형만 있던 메소드들의 구현을 함
• 이렇게 세팅 후 이전 객체(SomeView)는 어떤 이벤트가 일어났을 시 delegate로 지정한 객체(SomeController)에 알려줄 수 있다.
  => 종속되어 동작하는 것이 아님. 독립적으로 떨어져 있음.

// 1) Delegate 프로토콜 선언
protocol SomeDelegate {
    func someFunction(someProperty: Int)
}

class SomeView: UIView {
    // 2) 순환 참조를 막기 위해 weak으로 delegate 프로퍼티를 가지고 있음
    weak var delegate: SomeDelegate?
    
    func someTapped(num: Int) {
        // 3) 이벤트가 일어날 시 delegate가 동작하게끔 함
        delegate?.someFunction(someProperty: num)
    }
}
// 4) Delegate 프로토콜을 따르도록 함
class SomeController: SomeDelegate {
    var view: SomeView?
    
    init() {
        view = SomeView()
        // 6) delegate를 자신으로 설정
        view?.delegate = self
        someFunction(someProperty: 0)
    }
    
    // 5) Delegate 프로토콜에 적힌 메소드 구현
    func someFunction(someProperty: Int) {
        print(someProperty)
    }
}

let someController = SomeController()
// prints 0

Notification

Notification Center라는 싱글턴 객체를 통해서 이벤트들의 발생 여부를 옵저버를 등록한 객체들에게 Notification을 post하는 방식으로 사용

// 1) Notification을 보내는 ViewController
class PostViewController: UIViewController {
    @IBOutlet var sendNotificationButton: UIButton!
    
    @IBAction func sendNotificationTapped(_ sender: UIButton) {
        guard let backgroundColor = view.backgroundColor else { return }
      
        // Notification에 object와 dictionary 형태의 userInfo를 같이 실어서 보낸다.
        NotificationCenter.default.post(name: Notification.Name("notification"), object: sendNotificationButton, userInfo: ["backgroundColor": backgroundColor])
    }
}

// 2) Notification을 받는 ViewController
class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 옵저버를 추가해 구독이 가능하게끔 함
        NotificationCenter.default.addObserver(self, selector: #selector(notificationReceived(notification:)), name: Notification.Name("notification"), object: nil)
    }
    
    // iOS 9 이상이 아닐 경우에는 removeObserver를 해줘야 함
    deinit {
        NotificationCetner.default.removeObserver(self)
    }
    
    @objc func notificationReceived(notification: Notification) {
        // Notification에 담겨진 object와 userInfo를 얻어 처리 가능
        guard let notificationObject = notification.object as? UIButton else { return }
        print(notificationObject.titleLabel?.text ?? "Text is Empty")
        
        guard let notificationUserInfo = notification.userInfo as? [String: UIColor],
            let postViewBackgroundColor = notificationUserInfo["backgroundColor"] else { return }
        print(postViewBackgroundColor)
    }
}

Key Value Observing

메소드나 다른 액션에서 나타나는 것이 아니라 프로퍼티의 상태에 반응하는 형태

(Swift 4 전까지는 NSObject의 메소드인 observeValue(forKeyPath:change:context:)를 오버라이드하여 옵저버를 추가했으나 Swift4부터는 구독하고 싶은 프로퍼티에 observe()를 추가하여 클로저로 사용할 수 있게 하였다. 그러나 Swift 상에서는 didSet이나 willSet 같은 것으로 충분히 대체가 가능할 것 같아(동감) 굳이 써야하나 싶은 패턴인 것 같다.)

Ref.

https://medium.com/@Alpaca_iOSStudy/delegation-notification-%EA%B7%B8%EB%A6%AC%EA%B3%A0-kvo-82de909bd29

iOS7 - UIViewController의 topLayoutGuide, bottomLayoutGudie property

어떤 content(status bar, navigation bar, toolbar, tab bar, etc) 에도 덮이지 않는 뷰를 그리기 위해서 제공

iOS 11에서 해당 property deprecated => Safe Area 소개함. (iPhoneX 대응으로 인해 left, right 정보도 필요해짐)

UIView

In iOS 11 the UIViewController topLayoutGuide and the bottomLayoutGuide properties have been replaced by the new safe area properties in UIView: => safeAreaInserts, safeAreaLayoutGuide

@available(iOS 11.0, *)
open var safeAreaInsets: UIEdgeInsets { get }
 // UIEdgeInserts - top, left, bottm, right : edge 크기

@available(iOS 11.0, *)
open var safeAreaLayoutGuide: UILayoutGuide { get }
// UILayoutGuide: A rectangular area that can interact with Auto Layout.
// bottomAnchor, heightAnchor, centerXAnchor, ...

방법 1: 뷰의 frame을 safe area에 맞추는 방법

topSubview.frame.origin.x = view.safeAreaInsets.left
topSubview.frame.origin.y = view.safeAreaInsets.top
topSubview.frame.size.width = view.bounds.width - view.safeAreaInsets.left - view.safeAreaInsets.right
topSubview.frame.size.height = 300
// or
bottomSubview.leftAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leftAnchor).isActive = true
bottomSubview.rightAnchor.constraint(equalTo: view.safeAreaLayoutGuide.rightAnchor).isActive = true
bottomSubview.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor).isActive = true
bottomSubview.heightAnchor.constraint(equalToConstant: 300).isActive = true

방법 2 - View안의 label frame을 맞추는 방법

label.frame = safeAreaLayoutGuide.layoutFrame
// or
label.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor).isActive = true
label.bottomAnchor.constraint(equalTo: safeAreaLayoutGuide.bottomAnchor).isActive = true
label.leftAnchor.constraint(equalTo: safeAreaLayoutGuide.leftAnchor).isActive = true
label.rightAnchor.constraint(equalTo: safeAreaLayoutGuide.rightAnchor).isActive = true

https://medium.com/rosberryapps/ios-safe-area-ca10e919526f

https://devmjun.github.io/archive/SafeArea_1

Frame, Bounds는 CGRect 타입인 View의 Instance Property이다.
둘의 차이점에 대해 알아보자.

CGRect

- 사각형의 위치와 크기를 포함하는 구조체

- CGPoint - x, y 좌표, CGSize - width, height

Frame

The frame rectangle, which describes the view's location and size in its superview's coordinate system.

• 상위뷰의 좌표 시스템
• frame을 변경하면?
  자식 뷰의 위치도 변경된다 -> 자식 뷰의 frame은 변경되지 않았으므로
• 언제 사용?
  UIView 위치나 크기를 설정하는 경우

Bounds

The bounds rectange, which describes the view's location and size in its own coordinate system.

• 자신만의 좌표 시스템
• 기본 좌표: (0, 0)
• bounds의 origin을 변경한다는 것은?  곧, subView들이 화면상에서 drawing 되는 위치가 변경됨을 의미
  
  => subView들의 frame 값을 변화시키는 것이 아니다. 부모뷰 좌표축이 변하면서 subView가 그려져야 하는 위치가 달라졌기 때문
  ScrollView/TableView 등을 스크롤할 때, scrollView.bounds가 변하고, 그리하여 subView들이 그려지는 위치가 대표적인 예
  (subView들의 frame이 달라지는 게 아님)
  
  ex ) targetView.bounds.origin.x = 60; 
         targetView.bounds.origin.y = 50; 
         이라고 하면 targetView가 x축-> 60, y축-> 50으로 이동된 자식 뷰가 그려짐.!!!!!!!!!! 
  
• 언제 사용?
  - View 내부에 그림을 그릴 때 (drawRect)
  - transformation 후, View의 크기를 알고 싶을 때
  - 하위 View를 정렬하는 것과 같이 내부적으로 변경하는 경우

Ref.

Frame과 bound의 차이(2/2) : https://zeddios.tistory.com/231

Frame과 bound의 차이(1/2) : https://zeddios.tistory.com/203

CGRect와 CGSize의 차이, 그리고 CGPoint: https://zeddios.tistory.com/201

볼때마다 헷갈려서 적어두고, Swift에서의 Integer의 개념에 대해서도 함께 살펴보자

세 가지는 모두 숫자를 나타내기 위한 데이터 타입이다!

즉, int와 NSInteger는 둘다 객체가 아니다!

'객체가 아니다' 란?

- 미리 정의된 사이즈가 있기 때문에 힙에 동적 메모리 할당을 하지 않는다.

- 스택에 생성되므로 포인터로 변수의 값을 접근하지 않아도 된다.

유사한 데이터타입
int, NSInteger, CGFloat, CGPoint, CGRect, 등

NSNumber를 사용하는 이유는?
객체를 만드는 데 꼭 다른 객체를 사용하는 몇몇의 Cocoa 클래스들이 있기 때문(primitive type들은 사용할 수 없음)

ex) NSArray

Swift에서의 Integer

- Integers는 signed(positive, zero, negative)이거나 unsigned(positive, zero)임

- Swift provides signed and unsigned integers in 8, 16, 32, and 64 bit forms.

- UInt8, Int32, ...

NOTE
Use UInt only when you specifically need an unsigned integer type with the same size as the platform’s native word size. If this isn’t the case, Int is preferred, even when the values to be stored are known to be nonnegative. => This aids code consistency and interoperability.

Ref.

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

https://beankhan.tistory.com/18

GCD is a low-level C-based API.
NSOperation and NSOperationQueue are Objective-C classes.
NSOperationQueue is objective C wrapper over GCD. If you are using NSOperation, then you are implicitly using Grand Central Dispatch.

GCD advantage over NSOperation:

1. implementation
   For GCD implementation is very light-weight
   NSOperationQueue is complex and heavy-weight

NSOperation advantages over GCD:

1. Control On Operation
   you can Pause, Cancel, Resume an NSOperation
2. Dependencies
   you can set up a dependency between two NSOperations operation will not started until all of its dependencies return true for finished.
3. State of Operation
   can monitor the state of an operation or operation queue. ready ,executing or finished
4. Max Number of Operation
   you can specify the maximum number of queued operations that can run simultaneously

When to Go for GCD or NSOperation

when you want more control over queue (all above mentioned) use NSOperation and for simple cases where you want less overhead (you just want to do some work "into the background" with very little additional work) use GCD

Ref. 

https://stackoverflow.com/questions/10373331/nsoperation-vs-grand-central-dispatch

특히 UIView 클래스 계층 중요!