금일 활동 요약

  • 한 주를 시작하는 Kahoot!
  • 만국박람회 프로젝트 착수 (개인 프로젝트)
  • 만국박람회 프로그램 Class Diagram 초안 작성
  • 만국박람회 프로젝트 JSON 디코딩 모델 타입 작성
    • Decodable 프로토콜을 활용하여 디코딩 가능한 타입으로 지정
    • CodingKeys 열거형과 CodingKey 프로토콜을 활용하여 JSON 키 값을 커스터마이징하여 활용
  • JSON, TableView 학습 @활동학습
    • 학습 내용 참고
  • JSON 데이터를 디코딩하기 위한 모델 구현 방법 학습
    • 학습 내용 참고

활동 내용 상세

한 주를 시작하는 Kahoot!

만국박람회 프로그램 Class Diagram 초안 작성


학습 내용

활동학습 중 조언

  • 2주 간 개인 프로젝트 수행 예정 (만국박람회)
    • 금번 프로젝트 필수 학습 내용
      • Delegation Pattern
      • Table View
      • JSON
  • 일정 관리 연습을 지금부터 꼭 해야한다. 실전에서는 막연히 때를 정해서는 기한을 맞추기 어렵다.
  • 기한이 되면 끊고 내용을 보낼줄 알아야 한다.

Kahoot 퀴즈

딜리게이션 디자인 패턴을 구현하기 위해 필요한 스위프트 언어의 기능은?

  • 프로토콜

다음 그림에서 괄호에 들어갈 알맞은 표현은?

  • A: Attribute, B: Relationship, C: Multiplier, D: Constant

크기 조절에 불리한 배열을 대신해 고안한 자료구조로, 삽입/삭제/추가가 비교적 자유로운 선형 자료 구조는?

  • Linked List

알고리즘의 효율을 나타내는 방법 중 하나로, 문제 해결에 소요되는 시간을 개략적으로 나타내는 것은?

  • 시간 복잡도
  • 공간 복잡도: 알고리즘을 수행하며 차지할 메모리 공간 (복잡도)

JSON 디코딩 모델 타입 구성 방법

  1. JSON 데이터의 구조 (객체, 키, 값)에 맞게 타입을 정의한다. JSON으로부터 입력을 받지 못할 수 있는 프로퍼티의 타입은 ?형 옵셔널로 정의한다.
  2. 정의한 타입이 JSON으로 표현된 데이터를 형식에 맞게 디코딩할 수 있도록 Decodable 프로토콜을 채택한다.
    • 타입에 선언된 프로퍼티가 Decodable을 준수하는 기본 자료형(String, Int, Double 등)인 경우에는 별도 작업 없이 프로토콜 준수함
    • 선언된 프로퍼티 중 사용자 정의 타입이 있을 경우 해당 타입 또한 Decodable 프로토콜을 준수하도록 init(from decoder: Decoder) 이니셜라이저를 별도로 작성한다.
  3. JSON 데이터에 정의된 의 이름을 변경하고자 할 경우에는 모델 타입 내에 CodingKeys 열거형을 작성한다. CodingKeys 타입이 String 타입과 CodingKey 프로토콜을 따르도록 하여 변경하고자 하는 이름을 case에, JSON 데이터에 기록된 키 값을 rawValue에 작성한다.

예시1

//JSON
[
  {
    "name": "Ryan",
    "image_name": "Ryan-Profile-Photo" ,
    "age: 10,
    "short_desc": "Enthusiastic iOS Developer, I'M ON FIRE!"
  },
  {
    "name": "Kio",
    "image_name": "Kio-Profile-Photo",
    "age: 10,
    "short_desc": "Hey, are you interested in Swift? Join us!"
}

// Model Type
struct Person: Decodable {
  let name: String
  let imageName: String
  let age: Int
  let shortDescription: String
  
  private enum CodingKeys: String, CodingKey {
    case name
    case imageName = "image_name"
    case shortDescription = "short_desc"
  }
}

예시2


JavaScript Object Notation (JSON)

통신을 통해 컴퓨터 간 데이터를 주고 받을 때 규칙이 있어야 송신자와 수신자가 동일한 내용을 볼 수 있습니다. JSON은 이름과 마찬가지로 JavaScript의 객체 표기법으로, 합리적인 표기법으로 인정 받아 표준처럼 JavaScript 형식을 차용해서 쓰고 있습니다. 표현 방법은 아래와 같습니다.

{ }: 객체 (딕셔너리, 키와 값으로 이루어져 있음)
[]: 배열
" ": 문자열
123: 수
true/false: Boolean
null: 빈 값 (nil)

// 예시 객체
{
  "이름": "홍길동":,
  "나이": 150,
  "성별", "남"
}
  • JSON 이전에는 Extensible Markup Language (XML)을 사용하였습니다. 실제 성능은 XML이 더 좋았으나 JSON이 더 가독성이 좋다는 이유로 변경하였으나, 근래 컴퓨터 성능이 좋아져 큰 차이는 없다고 알려져 있습니다. 아래는 XML 예시입니다.

    Source: Wikipedia Korea

"그렇게 인간 친화적이지도 않고 기계 친화적이지도 않은 XML을 버리고 차라리 인간 친화적인 JSON을 쓰자."

활용 예시

서비스에 회원가입하는 경우 앱에서 만든 사용자 정보를 서버로 보내주어야 합니다. 이 과정에서 앞서 언급한 이유로 인해 약속된 형태로 서버로 보내주어야 하는데, 이 때 JSON 방식으로 인코딩해서 보냅니다.


Table View

환경설정, 연락처, 친구 목록 등에 사용하고 있는 하나의 열 (column)에 여러 행 (row)이 있는 리스트 형식의 View입니다. TableView 자신과 함께 delegatedataSourceTableView 작동에 주요한 역할을 수행합니다.

Source: Apple Developer

delegate

Table View의 모양과 동작을 관리하는 컨트롤러와 관련된 요소로, 다음 기능들을 관리하기 위해 UITableViewDelegate 프로토콜의 메서드들을 사용합니다.

  • 사용자 지정 header, footer view 생성 및 관리
  • row, header, footer들에 대한 높이 지정
  • 더 나은 스크롤링을 지원하기 위한 높이 측정치 제공
  • row 컨텐츠 들여쓰기 (indent)
  • row 선택에 대한 반응
  • table row들에 대한 스와이프 및 기타 동작에 대한 반응
  • table의 컨텐츠 편집 지원


Source: Apple Developer

dataSource

애플리케이션의 데이터 모델과 관련된 요소입니다. Table View는 자신의 데이터를 보여주는 것만 관리하고, 데이터 자체는 dataSource가 관리합니다. 이외에 dataSource가 수행하는 역할은 아래와 같습니다.

  • Table의 sectionrow들의 개수를 알려줍니다.
  • Table의 각 row에 대해 cell들을 제공해줍니다.
  • Section header, footer에 제목을 제공해줍니다.
  • 만약 Table에 index가 있다면 index 대로 구성해줍니다.
  • 기저 데이터 변경이 필요한 사용자 또는 테이블로부터의 업데이트에 반응합니다.

활동학습 결과물

  • User : 앱을 켜야지~
  • Table View -> Table View Datasource: 보여줘야 하는 Section의 수는 몇 개입니까?
  • Table View -> Table View Datasource: Section 0은(는) 몇 개의 Row를 보여줘야 합니까?

...중략...

  • Table View -> Table View Datasource: Section 9은(는) 몇 개의 Row를 보여줘야 합니까?
  • Table View -> Table View Datasource: (0, 0) IndexPath에 보여줄 Cell을 주십시오!!!
  • Table View Data source -> Cell Reuse Queue: (0, 0) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오!!!
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중 대기중인 Cell이 없어 새로 만들어 드릴게요.
  • Table View Data source -> Cell Reuse Queue: (0, 1) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중 대기중인 Cell이 없어 새로 만들어 드릴게요.
  • Table View Data source -> Cell Reuse Queue: (0, 2) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중 대기중인 Cell이 없어 새로 만들어 드릴게요.
  • User: 아래로 스크롤 해야지 스크롤
  • Table View -> Table View Data source: (1, 0) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중 대기중인 Cell이 없어 새로 만들어 드릴게요.

...중략...

  • Table View -> Table View Data source: (9, 0) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중 대기중인 Cell이 없어 새로 만들어 드릴게요.
  • User: 위로 스크롤 해야지 스크롤
  • Table View -> Table View Data source: (7, 2) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중에 대기중인 Cell이 있어요. 드릴게요.

...중략...

  • Table View -> Table View Delegate: Section 5은(는) 몇 개의 Row를 보여줘야 합니까?
  • Table View -> Table View Data source: (5, 1) IndexPath에 보여줄 셀인데, Cell Reuse Identifier에 해당하는 Cell을 주십시오
  • Cell Reuse Queue -> Table View Data source: Cell Reuse Identifier에 해당하는 Cell 중에 대기중인 Cell이 있어요. 드릴게요.
  • User : 5, 2 셀 터치!!
  • Table View -> Table View Delegate: 사용자가 5, 2의 row를 선택했다구!
  • Table View Delegate: 얼럿을 띄워야지

추가로 공부해야할 개념

Reusable Cell Queue:

  • cell을 필요할 때마다 만들면 리소스 낭비가 커짐.
  • view를 만들고 그리는 일이 가장 힘든 일이다. 이왕 만들어둔거 없애지 말고 대기열에 놨다가 필요하면 가져오자.
  • 애초에 필요한건 prototype cell을 복사해와서 만든다.
  • 화면 밖으로 벗어날 때 queue에 넣는다.
  • 밑에서 올라오는 아이는 위에서 사라지는 아이를 재사용해서 만든다.

오늘 나온 질문

Cell Reuse가 Queue로 구현된 이유가 있나요?

  • 대기열 구현 시 자주 사용되는데, Stack으로도 구현 가능할 것으로 예상. 하지만 데이터의 진행 방향이 queue와는 달라 병목 현상이 예상된다.

테이블 뷰가 앱이 시작하자마자 처음 뷰에 나타날때 뷰 라이프 사이클에서 어떤 시점에 나타나는지 궁금합니다. 예를 들어 JSON 데이터를 받아와서 뷰가 나타나자마자 테이블 뷰에 뿌려주려면 어느시점에서 통신을 요청해야할까요?

  • 사정에 따라 다름. 로컬로 JSON 데이터를 받으면 viewDidLoad 시점에 알아야 함. 엄밀히 말하면, awakeFromNib에서 . 네트워크를 통해 받아와야 한다면 내용이 달라짐. 네트워크에 통신 요청은 최대한 빨리하는게 좋음. 받으면 바로 보여주면 되니까. 보통 통신 요청은 viewWillAppear 또는 viewDidLoad 시점에 자주 함.
profile
합리적인 해법 찾기를 좋아합니다.

0개의 댓글