안녕하세요~ 👋 치콩입니다!

글을 작성하기 앞서 앞으로의 블로그 작성글의 컨셉을 이렇게 소통이다 생각하고 누군가에게 설명하듯 작성하려고 합니다! 이 전의 글들은 나만 본다는 가정하에 나만 알기쉽게 작성하였는데,, 그러면 일기장에 쓰지 블로그에 글을 쓰는 의미가 없어지지 않을까,,🤔 싶은 마음이 들더라구요ㅋㅋㅋ 누군가에게 설명하듯 작성하다보면 나도 모르는 개념들을 조금 더 파악할 수 있지 않을까 싶은,, 아무튼 잘부탁드립니다

오늘은 미뤄졌고,, 아니 미뤄왔고,, 아니 그냥 하기 싫었고,, 그냥 핑계였고,,,,

어쨋든 공부해야지 해야지 하고 미뤄왔던 Combine에 대한 기초개념을 파악해 보려구 해요 🥳

RxSwift 와 Combine을 고민하였지만 결국 Combine은 애플에서 만든 프레임워크 이고 결국 Combine으로 대체되지 않을까하여

( 물론 찾아보니 UIKit에 Combine을 적용하려면 Rxcocoa 같은 CombineCocoa(?) 서드파티 라이브러리를 적용해야 한다고 하더라구요…? 그래도 전 Combine을 공부할겁니다 그냥 제가 그러고 싶어요 )

Combine의 등장 배경?!

다음과 같은 마법학교앱의 회원가입 기능이 있다고 가정해보자구요~

1. WizardName을 입력받기 위해 Target/Action 을 이용해서 유저로부터 입력을 받겠죠?
2. Timer를 통해 유저의 입력이 종료될때까지 기다려줘요 ( 입력이 끝날때까지 네트워크 통신을 하지 않을겁니다! 매번 통신을 요청하면 너무 비효율 적이잖아요? )
3. 입력이 끝났으면 네트워크 통신이 진행되는동안 KVO(Key-Value-Observing)을 통해 입력받은 이름이 유효한지 검사할꺼에요 ( PDF에선 그림이 짤렸지만 Progress가 돌고있습니다 통신 되는동안 응답값이 올때까지 기다려라! 하는걸 알려주는거죠!! )

위 같은 방식으로 Password의 유효성도 검증하게 될거에요

우리는 Combine을 알기 전, 익숙하게도 이렇게 코드를 작성해 왔잖아여?

그래서! 들어가는 비용이 어떠냐,,,

Network 통신을 위해 URLSession도 사용하고, Timer도 사용하고,

WizardName과 Password가 모두 유효한지 판단하여 버튼도 활성화 시켜주기 위해 KVC(Key-Value-Coding) 의 개념도 들어가고,

응답도 기다리고, 뭣도 하고 뭣도하고 ..

자자 봅시다

네트워크와 통신을 하기 위해 우리는 비동기적으로 처리를 하게 될거에요 그쵸!? ( WizardName의 유효성을 기다리는동안 앱이 멈추거나 다른것을 하지 못하게 되면 사용자입장에서 너무 난처하잖아여,,, )

그리고 이 비동기와 아울어 Password의 유효성도 검증하고, 동기적으로 모두 유효한지 체크하여 MainThread 에서 UI도 업데이트를 통해 버튼을 활성화 시켜 주어야해요 - KVC(Key-Value-Coding)

이처럼 비동기를 처리하기 위해 Cocoa SDK에는 다음과 같은 비동기 인터페이스들이 있었죠!?

• Target / Action
• Notification Center
• URLSession
• Key-Value Observing ( KVO )
• Ad-hoc Callbacks

이 인터페이스들은 매우 중요합니다! 비동기 구현할때 알아야 하는 인터페이스 들이에요! 이것들이 혼합되면,,?

복잡하겠지만.. 어쩔수 있겠냐구요,, 해야지,,

그래서!! Apple에서는 이 개념들을 대체한다기 보다 공통적인 사항을 찾았다고 합니다!

시간이 지남에 따라 값을 처리하기 위한 API !!!

이게 뭐다? 이게 Combine의 등장 배경이라고 합니다!

Combine은 Swift로 작성된 프레임워크이기 때문에 다음과 같은 기능들이 포함된다고 합니다

• Generic
  • 작성해야 하는 코드의 양을 줄일수 있어요!
  • 비동기 동작에 대한 알고리즘을 작성한 후, 다른 종류의 다양한 비동기 인터페이스에도 적용할수 있어요!
• Type Safe
  • 안정성이 보장되기 때문에 런타임 아닌 컴파일시간에 오류를 찾아낼수 있어요!
• Composition First
  • 핵심 개념은 간단하고 이해하기 쉽지만(컴포지션 기반이기 때문에…?) 결합 될수록 더 많은 기능을 수행할 수 있다고 합니다! ( 그래서 Combine..? )
• Request Driven
  • 요청 기반의 프레임워크 이기 때문에 앱의 메모리 사용량과 성능을 신중하게 관리할수 있다고 합니다!

Combine의 3요소

1. Publishers
2. Subscribers
3. Operators

위 세개 알면 Combine 공부 끝나는 거임!

물론! 언제나처럼! 공감하겠지만! 세개를 알면 알수록 공부는 끝이 안날꺼임 …

세개의 세부사항에 대해서는 추후 천천히 알아가고 일단! 간단한(?) 기본 개념만 먼저 알아봅시다!

Publisher

값과 오류가 생성되는 방식을 설명한다고 합니다… 이게 무슨 소리지? 잠깐 공식문서의 개요를 봅시다,

https://developer.apple.com/documentation/combine/publisher

Declares that a type can transmit a sequence of values over time.
유형이 시간이 지남에 따라 일련의 값을 전송할 수 있다고 선언합니다.

A publisher delivers elements to one or more Subscriber instances.
Publisher는 하나 이상의 Subscriber 인스턴스에 element를 제공합니다.

The subscriber’s Input and Failure associated types must match the Output and Failure types declared by the publisher.
Subscriber의 입력(Input) 및 실패(Failure) 관련 유형은 Publisher가 선언한 출력(Output) 및 실패(Failure) 유형과 일치해야 합니다.

The publisher implements the receive(subscriber:)method to accept a subscriber.
Publisher는 Subscriber를 구독하기 위해 receive(subscriber:) 방법을 구현합니다.

오 뭔가 이해가 될듯 말듯 하네요? 그렇다면 내장된 Publisher의 프로토콜을 살펴볼까요?

public protocol Publisher<Output, Failure> {
    associatedtype Output
    associatedtype Failure : Error

    func receive<S>(subscriber: S) where S : Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

주석을 제외하고 실제로 내장에 구현되어 있던 녀석 가져옴

아하~ 그러니까 publisher 프로토콜에는 Output과 Failure의 타입이, 그리고 receive(subscriber:) 함수가 선언되어 있네요!?

receive(subscriber:) 함수에는 Self.Failure == S.Failure, Self.Output == S.Input 의 조건도 명시되어 있구요

오,, 공식문서 역시 정확하네요

다시 영상의 내용으로 돌아가서,,,

Failure 즉, Error를 생성할 수 없는 경우! ( 오류가 없는 경우,,? 다른 뜻인가 ,,,? )

암튼 이 경우에는 Never 를 할당 하면 된다고 합니다 ( 메모메모,, 왠지 제일 많이 쓸거같은 느낌이 든단말야? )

Publisher 프로토콜이 적용된 예시를 보도록 하죠! NotificationCenter입니다!

extension NotificationCenter {
    public struct Publisher : Publisher {
        public typealias Output = Notification
        public typealias Failure = Never

        public let center: NotificationCenter
        public let name: Notification.Name
        public let object: AnyObject?

        public init(center: NotificationCenter, name: Notification.Name, object: AnyObject? = nil)

        public func receive<S>(subscriber: S) where S : Subscriber, S.Failure == Never, S.Input == Notification
    }
}

이것도 Swift에 내장된 그대로 가져옴 ㅎㅎ ( 주석만 제거하고! )

NotificationCenter는 실패를 생성할 수 없는 경우인 Never 가 선언되어 있네요!?

그리고 해당 NotificationCenter를 초기화할때 NotificationCenter 와 Notification.Name 을 이용해 초기화 하는것을 볼수 있네요!

이처럼 NotificationCenter 자체가 Combine 등장과 함께 무언가로 대체 되는것이 아니고 Combine에 맞게 확장하여 사용하는것을 볼수 있습니다!

정리하면 Apple 에서는

Combine의 등장으로 기존의 Notification, URLSession 등 위에서 소개한 비동기 처리 인터페이스들을 새로운것으로 대체 하는게 아니라 Combine을 적용시키는 거임 OK? Right?

의 뜻이네요!!

너무 길어지는것 같아 다음 글에서는 Subscriber 와 Operator에 대한 간략한 설명을 살펴보겠습니다!

공식문서

A view that presents data using rows in a single column.

⇒ 단일 열에 배열된 행을 표시하는 뷰

• 단일 열에 수직 스크롤을 제공하는 콘텐츠 행을 표시
• 예를 들어 연락처 앱과 설정 앱이 있음
• 연락처 앱은 일반적인 TableView 를 표시하며, 설정 앱은 Group화 된 TableView를 표시
• 여러개의 행은 하나의 섹션으로 포함할수 있으며, 섹션은 헤더 와 푸터로 구성

구현해보기

1. Storyboard 에서 TableView와 TableViewCell 을 ViewController에 끌어다 놓자

2. 이렇게 끌어다 놓아 ViewController에 포함시키고 Cell에 대한 고유 값을 설정해 준다

3. cell을 선택한 상태로 오른쪽의 인스펙터 창에서 identifier에 구분할수 있는 이름으로 셀이름을 설정한다

( 예시에서는 "myCell" )

4. 해당 viewController 코드 파일에 TableView를 연결한다 ( IBOutlet )

[ storyboard 파일에서 control 을 누르고 코드쪽으로 끌어 당기면 연결된다 ]

5. datasource 프로토콜을 채택하고 내용을 구현해 준다

//
//  ViewController.swift
//  tableViewPrac
//
//  Created by Hong jeongmin on 2022/05/19.
//

import UIKit

struct myTableCell {
    var name: String
}

var nameArr = [
    myTableCell(name: "홍길동"),
    myTableCell(name: "이선비"),
    myTableCell(name: "개똥이"),
    myTableCell(name: "새이름"),
    myTableCell(name: "김하나"),
]

class ViewController: UIViewController {
    @IBOutlet weak var myTable: UITableView!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
        
        // 위임
        myTable.dataSource = self
    }
}

// DataSource => 각 테이블 행의 어떤 내용을 표시할지
extension ViewController: UITableViewDataSource {
    // 몇개의 행을 리턴할지
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return nameArr.count
    }
    
    // 각 행에는 어떤 내용을 포함 할지
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "mycell") else {
            fatalError("셀이 존재하지 않습니다.")
        }
        
        cell.textLabel?.text = nameArr[indexPath.row].name
        return cell
    }
    
    // 헤더의 이름 표시
    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return "헤더입니다"
    }
    
    // 푸터의 이름 표시
    func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? {
        return "푸터입니다"
    }
    
    // 몇개의 섹션을 구성할 것인지 표시
    func numberOfSections(in tableView: UITableView) -> Int {
        return 2
    }
}

6. 결과확인

datasource 를 반드시 설정해 주어야 해당 내용이 나타나니 코드를 잘 살펴보자~!

테이블뷰 기초 끝!

• 사진 세트와 같은 정렬된 콘텐츠 세트를 관리하고 커스텀 가능하고 시각적인 레이아웃으로 제공
• 컬렉션은 엄격하게 선형 형식을 시행하지 않기 때문에 크기가 다른 항목을 표시하는 데 적합
• 컬렉션은 이미지 기반 콘텐츠를 과시하는 데 이상적
• 배경과 같은 부수적인 뷰는 항목의 하위 집합을 시각적으로 구별하기 위해 선택적으로 구현

• 컬렉션은 상호 작용과 애니메이션을 모두 지원한다
• 기본적으로 탭하여 선택하고, 길게 터치하여 편집하고, 스와이프하여 스크롤할 수 있다
• 필요한 경우, 커스텀된 작업을 수행하기 위해 더 많은 제스처를 추가할 수 있다
• 컬렉션 내에서 항목을 삽입, 삭제 또는 재정렬할 때마다 애니메이션을 활성화할 수 있으며 커스텀 애니메이션도 지원한다

고려사항

• 행이나 그리드 레이아웃이 충분할 때 새로운 디자인을 만들지 마세요.
  • 컬렉션은 사용자 경험을 향상시켜야 합니다.
  • 항목을 쉽게 선택할 수 있도록 하세요. 컬렉션에서 항목을 탭하는 것이 어렵다면, 유저입장에서 앱에대한 불편한 인식을 남길수 있습니다.
  • 레이아웃을 깨끗하게 유지하고 콘텐츠가 겹치지 않도록 콘텐츠 주위에 적절한 패딩을 사용하세요.
• 컬렉션에 텍스트만 표시한다면, 테이블 뷰를 고려하세요.
  • 스크롤 가능한 목록에 표시될 때 텍스트 정보를 테이블 뷰로 구성하는 것이 더 간단하고 효율적입니다.
• 동적 레이아웃을 변경할 때 주의하세요.
  • 컬렉션의 레이아웃은 언제든지 변경할 수 있습니다.
  • 사람들이 레이아웃을 보고 상호 작용하는 동안 레이아웃을 동적으로 변경한다면, 변경 사항이 합리적이고 추적하기 쉬운지 확인하십시오.
  • 동기 부여되지 않은 레이아웃 변경은 앱을 예측할 수 없고 사용하기 어렵게 만들 수 있습니다.
  • 레이아웃 변경으로 인해 컨텍스트가 손실되면, 유저 입장에서 불편한 앱으로 인식될 수 있습니다.

⇒ 참고 문서

TableView를 기준으로 설명 , (아마도) 동일한 프로토콜이 있다면 같은 기능을 수행할 것입니다.

Delegate

• TableCell을 탭(클릭) 했을때 어떠한 기능을 수행하는 권한을 위임하는 프로토콜

func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: IndexPath) 
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: IndexPath)

• 외울필요? X 자동완성을 사용하자 ( 우리 신세대임..ㅋ )
• 메서드의 인자만 봐도 어떤 기능을 수행 할 지 짐작이 가능하다
• didSelectRowAtIndexPath → 이름부터가 선택 됐을때, 어떠한 동작을 수행할 것인지 에 대한 정의를 내리면 될것 같다
• willBeginEditingRowAtIndexPath ⇒ 공식문서 의 내용을 보니 행의 삭제와 같은 기능을 수행 할 때 어떤 동작을 결정할 지를 정의하면 된다

⇒ 물론 Delegate의 func들은 Optional이기 때문에 반드시 정의 할 필요는 없다.

DataSource

• TableView의 Cell을 어떻게 보여줄가 에 대한 권한을 위임(?) 하는 프로토콜
• 몇개의 행을 표시할 것인지? 각 행에는 어떤 내용을 보여줄 것인지등등 간단히 말해 View를 그리는 역할을 수행한다고 생각하면 된다

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: IndexPath) -> UITableViewCell
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int

• 위 두가지 메서드는 Datasource 프로토콜을 채택 할 때 반드시 정의해 줘야 하는 메서드!
• 외우지 말자.. ( Datasource 채택하면 빨간줄 뜨면서 자동으로 채워진다! )
• numberOfRowsInSection ⇒ 이름만 봐도 몇개의 섹션을 나눌것 인지 정의하면 된다. 말 그대로 몇개의 행을 테이블 뷰에 표시 해 줄것인지 정의해 주면 된다 ( 정수를 반환하면 반환된 값 만큼 테이블뷰의 행이 생성된다 )
• cellForRowAtIndexPath ⇒ 각 행(cell)에 어떤 내용을 보여 줄 것인지 정의해 주면 된다. 말 그대로 어떤 내용을 표시해 줄지에 대한 정의를 내리면 되고, indecPath 를 통해 각 행이 for 구문 처럼 순차적으로 정의된다 ( 이해가 안가면 직접 구현해 보자 )
• 두개의 메서드 말고 추가적인 메서드들도 있으나, 모두 외울 필요없다, 필요하면 그때 그때 찾아 사용하자

⇒ 한줄 정리 : Delegate는 어떠한 동작 을 수행, DataSource는 어떠한 내용 을 표시

• 테이블은 데이터를 섹션이나 그룹으로 나눌 수 있는 행의 스크롤, 단일 열 목록으로 표시
• 일반적으로 테이블은 텍스트 기반 콘텐츠에 이상적이다
• 테이블 뷰는 일반적으로 3가지 스타일로 제공 - Plain, Group, inset Group

Plain

• 행은 라벨이 지정된 섹션으로 분리될 수 있으며, 인덱스는 테이블의 오른쪽 가장자리를 따라 수직 표시
• 섹션의 첫 번째 항목 앞에 헤더가 나타날 수 있으며, 마지막 항목 뒤에 푸터가 나타남

Group

• 행은 그룹으로 표시
• 헤더 앞에 푸터가 뒤따를 수 있음
• 항상 적어도 하나의 그룹을 포함하며 각 그룹은 항상 적어도 하나의 행을 포함
• 그룹화된 테이블에는 인덱스가 포함되어 있지 않음

Inset Group

• 행은 모서리가 둥글고 부모 뷰의 가장자리에 삽입된 그룹으로 표시
• 항상 적어도 하나의 그룹을 포함하며 각 그룹은 항상 적어도 하나의 행을 포함
• 헤더 앞에 푸터가 뒤따를 수 있음
• Inset Group 된 테이블에는 인덱스가 포함되어 있지 않음
• 컴팩트한 환경에서 공간이 적기 때문에, 큰 화면의 ( iPad 같은 ) 환경에 적합

고려사항

• 테이블의 너비를 생각할 것
  • 테이블의 너비가 너무 얇거나 너무 두꺼우면 콘텐츠를 읽는데 오히려 방해 요소가 된다
• 테이블 내용을 빠르게 표시할 것
  • 이미지나 복잡한 데이터를 포함해야 한다면 텍스트를 먼저 보여주고, 이후에 데이터를 표시
  • 유저에게 즉시 유용한 정보를 제공하고 앱의 반응성을 높일 수 있음
• 콘텐츠가 로드될 때 진행 상황을 전달할 것
  • 테이블의 데이터를 로드하는 데 시간이 걸린다면, 진행률 표시줄이나 progress 등을 이용하여 앱이 실행 중이라는 것을 사람들에게 인식 시켜야 한다
• 콘텐츠를 최신화 할것
  • 새로운 데이터를 반영하기 위해 테이블의 콘텐츠를 정기적으로 업데이트하는 것을 고려
  • 스크롤 위치를 변경하지 마세요. ( 수직 스크롤 고정 ) 내용을 테이블의 시작이나 끝에 추가하고, 사람들이 준비가 되면 스크롤하도록 하세요.
  • 일부 앱은 새 데이터가 추가되었을 때 표시기를 표시하고 바로 점프할 수 있는 컨트롤을 제공해야 함.
  • 유저들이 언제든지 수동으로 업데이트를 수행할 수 있도록 새로 고침 컨트롤을 포함하는 것을 권장
  • ⇒ 참고 문서
• 인덱스를 오른쪽 정렬된 요소가 포함된 테이블 행과 결합하지 마세요.
  • 테이블 행의 오른쪽에 다른 요소가 있다면 예상하지 못한 제스쳐가 발생하여 유저에게 혼란을 줄 수 있습니다.
  • ⇒ 참고 문서

Table Rows

표준 테이블 셀 스타일을 사용하여 테이블 행에 콘텐츠가 어떻게 나타나는지 정의

Basic (Default)

행의 왼쪽에 이미지와 왼쪽 정렬된 텍스트가 표시

추가 정보가 필요하지 않은 항목을 표시하는 데 좋음

참고 문서

Subtitle

첫번째 줄에는 왼쪽 정렬된 제목을, 다음 줄에는 왼쪽 정렬된 Subtitle을 정의

행의 구분이 잘 되지않는 항목의 경우 subtitle은 행을 구분하는 데 도움이 된다.

참고 문서

Right Detail (Value 1)

행의 왼쪽에는 Title을, 오른쪽에는 subTitle을 배치

참고 문서

Left Detail (Value 2).

행의 오른쪽에는 Title을, 왼쪽에는 subTitle을 배치

참고 문서

고려 사항

• 클리핑을 피하기 위해 텍스트를 간결하게 유지할 것
  • 단어나 문장이 잘리면 유저에게 가독성을 낮출수 있다
• 삭제 버튼에 커스텀 제목을 사용하는 것을 고려할 것
  • 행이 삭제를 지원하고 명확성을 제공하는 데 도움이 된다면, 시스템에서 제공하는 삭제 제목을 커스텀하여 사용하세요
• 선택 시 피드백을 제공할 것
  • 사람들은 콘텐츠를 탭할 때 행이 짧게 강조되기를 기대한다.
  • 사람들은 새로운 뷰가 나타나거나 체크 표시가 나타나는 것과 같은 무언가가 바뀔 것으로 예상한다
• 비표준 테이블 행을 위한 커스텀 테이블 셀 스타일을 디자인할 것
  • 표준 스타일은 다양한 일반적인 시나리오에서 사용하기에 적합하지만, 일부 콘텐츠나 전반적인 앱 디자인은 크게 맞춤화된 테이블 모양을 필요로 할 수 있다.
  • 자신만의 셀을 만드는 방법을 배우려면, 참고 문서 를 참고하세요

⇒ 참고 문서