1. 첫 번째 학습 내용: 뷰의 재사용 / 셀 이미지의 지연 로딩
iOS 14부터는 cell.backgroundColor = .systemRed 이런 식으로 셀에 바로 적용안해 줌!!
cell.defaultContentConfiguration() 써줘야 함!
Instance Method
defaultContentConfiguration()
Retrieves a default list content configuration for the cell’s style.
var content = cell.defaultContentConfiguration()
// Configure content.
content.image = UIImage(systemName: "star")
content.text = "Favorites"
// Customize appearance.
content.imageProperties.tintColor = .purple
cell.contentConfiguration = content**Instance Property
contentConfiguration**
The current content configuration of the cell.
Instance Method
prepareForReuse()
Prepares a reusable cell for reuse by the table view's delegate.
셀이 저 reuse queue에 들어가 있을 때
알아서 자르륵 준비함
→ 컨베이어 벨트 뒤로 넘어갔을 때
알아서 준비
cellForRowAt은 급박한 상황
빨리 내놔! 하는거
지금 예제는 단순해서 버벅거리지 않겠지만
미리 준비해 놓는 것과
갑자기 꺼내놓는 것은
로직이 무거워지고 커지면
당연히 차이가 생김
prepareForReuse 잘 사용할 줄 알아야함!
그럼 실수할 일도 적어짐
셀이 재사용되고 있다
재사용되면서 우리가 어떤 준비를 해둬야 한다
이미지는 백그라운드로 돌렸을 거임
download나 network 통신 등
참고 자료
역시 갓제드..
정리해놓으셨다 👏
iOS 14 ) Modern Cell Configuration (1)
iOS ) TableView에서 dequeueReusableCell?
셀이 요청을 했음
(이미지 다운로드 해줘 !)
이미지 다 다운로드 받았어
그러면 한번 더 확인해주기
원래 인덱스랑 같은지?
셀에 이미지뷰에 필요한 이미지 다운로드 하겠다!
일으키는 문제
(오래 걸림)
몇 십초가 걸릴수도 있고
백그라운드에서
화면에 보이는 것과는 별개로
이미지를 다운로드 받고 있다
그동안에는 네프 이미지가 보이는거임
(몇 초가 걸림)
로드가 되기 전에 화면 밖으로 벗어나 버림
그럼 어떤 일이 벌어지냐면
맨 위에 있던 셀은
화면 밖으로 벗어나있다가
셀에 엉뚱한 이미지가 불러와짐 ?!!
결론: 이미지를 다운로드받은 시점에
0번쨰 이미지가 맞아?
맞으면 꽂아주고 아니면 버림 !!
유저가 스크롤 안하고 기다렸으면
이미지 로딩해주세요 기다리면서
셀의 인덱스가 바뀌지 않았는지
확인해보겠다 !
Closure capture list ⭐️
클로저가 비동기 프로그래밍을 위해서
나중에 지금의 상태를 저장해두게 됨
지금의 상태를 캡쳐함
indexPath는 지금의 상태
클로저는 나는 나중에 실행될거야를 알고 있음!
그래서 지금의 상태를 기억해둬야 함
나중에 실행된다고 하더라도
지금의 상태를 알고 실행해야 함
다른 방법)
Image data prepatch도 있음
참고 자료
Closure - Capture List by delmasong
Asynchronously Loading Images into Table and Collection Views
[iOS]Thread의 이해(1) - Main Thread와 Background Thread by yongchul
비동기 프로그래밍이 뭔가요? by 얄팍한 코딩사전
2. 두 번째 학습 내용: git remote 연동
git remote랑 연동시키는 법
-
git remote update
From https://github.com/unme88/ios-open-market
[new branch] Step1_James -> origin/Step1_James
해당 repository에 새로운 브랜치가 생성된 걸 알 수 있음 -
git branch -a
모든 브랜치를 보여주라
실행해보면 제임스꺼 새로 생성된 브랜치 보임 -
git checkout -t origin/Step1_James
Branch 'Step1_James' set up to track remote branch 'Step1_James' from 'origin'.
Switched to a new branch 'Step1_James'
→ 이렇게 하면 한 번에 두개를 처리함
- 제임스 브랜치명 생성
- 업데이트된 파일 pull해옴
- git merge Step1_James
내 브랜치로 이동한 후에 제임스 브랜치 merge 함
참고 자료
리모트 브랜치 참조와 업데이트
[Git] 6. Xcode에서 Git 사용하기
홀.. Xcode에서 바로 Github에 커밋 푸쉬할 수 있다니 @_@
Thanks to 제임스 👍
3. 세 번째 학습 내용: MVVM(Model - View - ViewModel)
iOS/Swift:: MVVM 정리 및 예제 by ChoiKanghun
Design Patterns by Tutorials: MVVM by raywenderlich.com
문제점/고민한점 → 해결방안
Q. 테스트에서 unknown error 생긴 이유
→ Items에서 descriptions는 필요한 거지만
json mock data에는 없음
해결 방법)
나중에 써야하는 건데
json이랑 안 맞으면 에러가 나니까
주석 처리를 하거나
or
주석 처리 안하고 다 남겨두고
extension Items 해가지고
init을 해줌
이렇게 할 필요 없고
그냥 옵셔널로 선언해주면 됨
그럼 해당 json 파일에 키값이 없어도 nil이 될 가능성을 내포한거니까!
올라프한테 물어볼 것
json 파일 받은게 Item과 Items가 있는데
구성되는 키 항목이 다름
이거를 모델을 2개로 나눠서 구현해야 할지?
아니면 하나의 struct 타입으로 재사용하는게 좋을지?
-> 결론: 나누는게 낫다.
억지로 재사용했다가 다른 사람이 봤을 때 이해못할 바엔!
10시 만남 with 올라프 !!
Sunny
- 설계에서부터 조언을 얻고 싶음!
- PR 중간에 종종 디스코드에서 직접 대화 하면서 커뮤니케이션이 원활하게 됐으면 좋겠음!
James
- 공부할 수 있는 포인트, 키워드, 힌트 찝어주면 → 다음 PR에 반영해보고 싶음
- 문법 뿐만 아니라 SOLID, 객체지향적인 측면에서 피드백 받고 싶음
올라프
- 리뷰를 해줘도 바로 반영하지는 않았으면 함
→ 올라프의 생각이 꼭 정답이라고 할수는 없음 - 음성으로 하는걸 더 선호함!
→ 그렇지만 글로도! 본인을 위해서 기록하길
맨 처음에 설계를 잘한다고 해도 바뀔 수 밖에 없다고 생각함
모든 경우를 예측할 순 없으니까!
어디서 문제가 생겼는지를 UML을 보면 파악할 수 있음
설계를 너무 완벽하게 처음에 하려고 하지 말고
각 객체의 역할을 명확하게 하고 그러면
어느정도 기능이 뽑힘
그때 메소드를 인터페이스를 정해놓고 함
객체관의 관계 정도만!
UML을 안 그릴때는
테스트 먼저 짤때
why? 테스트에 기능이 다 명세되어 있으니까
p.s. 꼭 정답이라고 생각하진 말기 !!
- UML을 그리기 전에 클래스의 역할 파악하기!
공식 문서를 읽어보면
얘는 어떤 기능을 한다 → summary 읽고
어느 정도 역할을 나눌 수 있음
트러블슈팅 그런게 필요하다 그러면 더 자세히 읽어보는 거
UML을 할때의 장점
손가는 데로 짤때보다
그때그때 수정해야 할게 덜할 수 있음!
Q. MVVM을 지금 한다는게 걱정스러움 .. !
MVC를 하다가 막히면
막힌 부분을 해소하면서
더 깊게? 와닿게 배울 수 있음
일단은 MVC부터!
Q. MVC vs. 클린코드
현업에서 느끼는 클린코드는
이름을 얼마나 잘 짜느냐,
메소드는 얼마나 역할을 잘 하느냐,
모든 역할을 하는 클래스가 없고 얼마나 분리가 잘 돼있느냐?
협업할 때 정말 좋음!
예전에 짠 코드 보면 뭔소린지 모르겠고
한참 봐야함
→ 아! 이래서 클린 코드가 필요한거구나 깨달음
클린코드가 추구하는 공통적인 부분, 맥락이 있음
그런 부분에선 MVC든, MVVM이든 상관없음
MVC로 유닛 테스트를 해보면
비는 부분이 있을거임
그럼 MVVM으로 커버할 수 있다!
객체지향 vs. 프로토콜 지향
객체지향 = 캡슐화, 은닉화 추구
프로토콜은 그렇지 않음
프로토콜이 왜 필요한지?
테스트랑 관련돼있음
Q. 프로토콜의 기본 구현이
객체지향의 상속이랑 뭐가 다른지 비교해보기!
객체지향을 먼저 하면
프로토콜이 나중에 나온 이유?
이전에 있던 개념 문제가 뭐였을까?
모든 접근을 그런 식으로 함
왜 RX를 해야할까?
이전엔 어떻게 했지?
아 이렇게 다르구나!
자기 경험이 이유가 되니까
면접 때도 좋음!
블로그는 남의 경험을 외워야 하니까
