열거형은 저장 프로퍼티를 사용할 수 없다
→ 인스턴스 생성 불가
static이 붙어있다면 상관 없다. 사용 가능 → 데이터 영역에 저장
연산 프로퍼티 static var photo → static 제거하면?
인스턴스 연산 프로퍼티 → 값을 저장하고 있지는 않고, 값을 사용할 수 있는 통로로서의 역할만 담당
인스턴스 연산 프로퍼티는 인스턴스 연산 프로퍼티만 사용 가능
타입 연산 프로퍼티를 사용할 수 없어서 오류가 난다.
타입 명시가 된다면 타입 프로퍼티 사용 가능하다.
→ 런타임 시 api 체크 요청을 했기 때문에 보라색 오류가 나타난다.
→ 동기, 순서대로 실행, 끝나는 지점 알 수 있음
버튼이 눌려있는 상태로 끝나길 기다린다.
async
이미지는 메인 스레드에서 동작해야 한다.
global async로 일 맡겨 놓고 이후 코드 먼저 실행
호출 순서와 결과의 순서가 다르다.
비동기 특성
일단 다른 알바생에게 작업을 보내고 나머지 실행
작업이 언제 끝나는 지 정확한 시점을 알기 어렵다.
UI는 메인 스레드에서 해야한다!
main.sync
메인 → 매니저에게 맡김
매니저 → 메인에게 시킴 ⇒ 무한루프!
메인이 해당 코드를 실행해야 하지만 메인은 작업이 끝나기를 기다리게 되어 무한 대기 상태에 들어가게 된다.
⇒ 교착상태, Dead Lock
Serial Async
일 맡겨놓고 다음 작업 바로 실행
그 작업이 끝나면 async 작업을 수행한다.
global sync
메인이 일을 맡겨놓고 글로벌이 일을 수행
그 일을 다 수행할 동안 메인이 기다림
메인의 일이 줄긴 했지만 메인은 그 동안 기다려야함 → sync이기 때문에
⇒ main과 다를 바가 없음 → 실제로 main에서 실행함
global async
다른 알바생과 동시에 작업 → 작업이 빨리 끝남
global async에서 주로 네트워크 작업을 한다.
상호작용 요소는 메인이 맡는다. 사용자 입장에서는 네트워크보다 버튼 눌렀을 때의 상호작용이 더 중요하기 때문에!
반복문 내에서 global().async 수행 ⇒ 반복문 하나하나의 수행을 다른 알바생에게 시키는 것
1은 너가.. 2는 쟤가..
async니까 메인은 기다리지 않고 다음 작업 수행
여러 스레드를 생성하여 빠르게 작업 수행을 완료한다.
alamofire responseJSON → responseDecodable 이제는 바꿔 사용
API
서로 만들어 놓은 규칙
REST API
네트워크를 통해서 핵심 컨텐츠와 기능을 활용할 수 있도록 제공되는 인터페이스, 아키텍쳐 스타일
자원을 중심으로 end point(URI)를 생성하고,
언어에 종속되지 않음
목적지가 있는 리소스 하나하나
고유한 주소를 가지고 있음
REST API 6원칙
uniform interface
- 자원에 대한 식별이 가능해야 한다.(고유한 주소를 갖고 있어야 구분 가능)
- HTTP Method를 통해 자원을 조작해야 함(get, post,..)
Stateless
- REST는 HTTP 위에서 구현되기 때문에 REST또한 무상태성 가짐
- 여러 번 요청했을 때 요청한 사용자가 같은 사람인지 알 수 없음
Cacheable
- 캐싱되어 있어서 같은 데이터를 여러번 요청할 때 로딩의 시간이 줄어든다.
- HTTP에 구현되어 있음
Self-Desctiptiveness
- 링크 정보를 보고도 직관적으로 무슨 내용이 담겨있는지 파악할 수 있어야 한다.
Client - Server
계층형 구조
REST API의 단점
Overfetching
필요한 정보값보다 더 많은 정보값이 로딩될 수 있다.
내가 필요한 정보는 3개인데 수십개의 정보를 가져와야 한다.
필요한 정보보다 부족한 정보 로딩으로 추가 api를 요청해야하는 순간도 필요함
영화의 모든 정보를 가져오고 싶지만 영화의 배우 정보 등은 따로 api를 요청해야 함
Endpoint
서비스 규모가 커질 수록 엔드포인트가 늘어나 관리하기 어려워짐
기존 api 엔드포인트가 삭제되거나 변경될 수 있음
💡 Codable
Decoding(Deserialization) ↔ Encoding(Serialization)
JSON과 같은 외부 표현과의 호환성을 위해 데이터 유형을 인코딩 및 디코딩 할 수 있는 프로토콜
API 통신 작업에서는 인코딩 디코딩 작업이 필요하다. Alamofire에서 JSON을 받을 때 인코딩 디코딩 과정이 모두 구현되어 있어서 사용할 수 있었다.
Swift 표준 라이브러리에서 Codable을 통해 인코딩 및 디코딩에 대한 표준화된 접근 방식을 제공한다.
✅ String → Data → Quote (Decoding, 역 직렬화)
- string → data
구조체를 외부에서도 사용할 수 있도록
구조체에 담겨있는 데이터를 담기 위해 decodable로 자격 부여
⇒ from 데이터를 quote 구조체에 담았다
Error handling, Do Try Catch, Meta Type (수요일 쯤에 설명..)
❓ 서버에서 들어온 데이터를 구조체에 넣을 때 키 값이 다르다면?
→ 자기 자리를 찾지 못함
키 값이 같지 않다면 디코딩 실패
옵셔널을 통해 런타임 오류를 방지할 수는 있다..
옵셔널 해제 때문에 귀찮아짐
런타임 오류가 나지는 않지만 원하는 데이터가 들어가지 않는다.
snake case → aaa**_**aaa
camel case → aaAaa
json decoder에서 해결 가능함
snake-case → camel-case
제약이 있기는 하지만 snake-case 정도는 해결 가능함
✅ 키 값이 다르지만 넣고 싶다?
CodingKeys
애플이 만들어 놓은 것
사용하지 않으면 키 값이 똑같다라고 알고 있을 것..
커스텀 키를 사용하고 싶다면 CodingKeys를 사용하여 지정해준다.
✅ 만약 값이 없다면 임의의 값을 넣게 하고싶다
forkey를 string으로 디코딩해서 content에 담기
.like 값을 int로 디코딩 해서 like에 담기
name → 서버에서 받은 키로 string으로 바꾸는데
decodeIfPresent → 옵셔널로 설정된 키를 받을 때 사용
비어있으면 unknown으로 설정해라!
json의 계층 구조가 복잡할 때
가져다가 사용하자
✳︎ dump
계층 구조를 파악하기 쉬움!
'iOS > 🌱 SeSAC' 카테고리의 다른 글
23.08.24 목 (0) | 2023.08.31 |
---|---|
23.08.23 수 (0) | 2023.08.31 |
23.08.22 화 (0) | 2023.08.31 |
23.08.21 월 (1) | 2023.08.27 |
23.08.18 금 (0) | 2023.08.27 |