일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- rxswift
- nodeJS
- 웹크롤링
- Python3
- 인프런파이썬강의
- 토플공부수기
- 카카오톡채팅봇
- 파이썬중급
- 파이썬중급강의
- 인프런강의
- uikit
- 인프런
- 노드JS
- swift
- 유학토플
- 프로그래머스
- 우리를위한프로그래밍
- 토플
- IOS
- 자바스크립트
- 스위프트
- 교환학생토플
- 파이썬
- 인프런파이썬
- IOS프로그래밍
- 인프런오리지널
- 리프2기
- 파이썬웹크롤링
- JS
- SwiftUI
- Today
- Total
목록앱/Swift (45)
먹고 기도하고 코딩하라
결론부터 얘기하면 있다. ReactorKit의 Reactor 파일을 살펴보면 extension에서 disposeBag을 찾을 수 있다. extension Reactor { fileprivate var disposeBag: DisposeBag { return MapTables.disposeBag.value(forKey: self, default: DisposeBag()) } } 하지만 fileprivate 레벨로 선언된 변수이기 때문에 커스텀해서 만드는 Reactor 내에서 직접 접근할 수는 없다. disposeBag의 존재 의의가 궁금해진다. 기원을 찾아 올라가기 위해 MapTables.disposeBag으로 이동한다. MapTables는 enum 타입이고, disposeBag 변수가 포함되어 있다. p..
한 줄 요약 iOS 17 이상에서 UIGraphicsBeginImageContext()를 시도할 때, 이미지 사이즈가 (0, 0)인 경우 강제종료될 수 있으므로 UIGraphicsImageRenderer를 쓰는 것이 권장된다. 메이저 앱 배포 후 갑자기 ImageContext 관련해서 크래시리틱스에 이슈가 많이 나왔다. **NSInternalInconsistencyException - UIGraphicsBeginImageContext() failed to allocate CGBitampContext: size={0, 0}, scale=1.000000, bitmapInfo=. Use UIGraphicsImageRenderer to avoid this assert.** 이런 에러 메시지가 포함되어 있었는데,..
iOS 17에서 기존과 같이 위젯을 만들었을 때, 크게 2가지 문제점이 있다. 위젯 위아래의 마진으로 레이아웃 깨짐 디버그 모드에서 설치 안됨 1. 위젯 위아래의 마진으로 레이아웃 깨짐 대응을 하지 않은 경우, iOS 17에서의 위젯은 위아래로 마진이 생긴다. 그래서 기존에 설정해둔 레이아웃이 깨지게 된다. 다행히 iOS 17 이상에서 이 마진을 무시할 수 있다. Widget의 body, WidgetConfiguration에서 다음과 같이 .contentMarginDisabled()를 적용해주면 마진을 무시하게 된다. var body: some WidgetConfiguration { let configuration = StaticConfiguration(kind: kind, provider: Provid..
큰 업데이트 전에는 사내 배포 및 외부 고객센터에 앱 배포가 필요한 경우가 있다. iOS의 경우, 앱스토어에 등록되지 않은 개발용 앱인 경우 프로파일에 등록된 기기들만 앱을 설치할 수 있다. 사무실 상근 임직원분들 외에도 직접 만날 수 없는 고객센터 근무자 분들의 폰을 등록해야 하는 경우가 발생한다. 또한 폰을 등록한 후에도 프로비저닝 업데이트 후 사내 배포를 위해 따로 빌드가 필요하다. 이번 주는 사내 배포용 앱을 빌드하고, 외부 고객센터 기기 등록하는 작업을 하다가 난항을 겪었다. 사내 컨플에 공유한 문서인데 좀 더 일반적으로 수정해서 블로그에도 올린다. 오라.. 달콤한 프로비저닝 업데이트여.. 🤯 사무실 외부의 기기 등록 프로파일에 등록되지 않은 iOS 기기들을 등록하는 일은 내가 도맡아 했는데, ..
Observable 구독하는 클로저에서 이벤트가 발생하면 UI를 업데이트해주는 코드가 있었다. 그런데 observe를 메인 스레드가 아니라 다른 스레드에서 하고 있어서 이벤트를 받아 onNext 하면 메인 스레드가 아닌 데서 UI 조작한다고 앱이 강제종료되는 이슈가 생겼다. .observe(on: MainScheduler.Instance)를 체이닝에 추가해서 메인 스레드에서 관찰하도록 변경해줌으로써 이슈는 해결했다. 그런데 문득 궁금해졌다. 그러니까, onNext에서 할 행동을 DispatchQueue.main.async { } 블록으로 감싸줘도 되는 게 아닌가? 이 둘은 퍼포먼스상으로 유의미한 차이가 있을까? 먼저 .observe(on: MainScheduler.Instance) 메소드부터 살펴보자. ..
MVC가 Massive View Controller라는 농담이 있다. 코코아 MVC에서는 뷰컨이 뷰의 역할도 하고 컨트롤러의 역할도 하기 때문에 뷰컨이 하는 일이 너무 많아지기 때문이다. 전통적인 MVC에서 모델, 뷰, 컨트롤러 3가지는 다음과 같은 일을 한다. Model : 비즈니스 로직 수행에 필요한 데이터 구조를 정의하고 담는 역할 View : 유저에게 보일 뷰를 구성하고, 사용자 인풋을 받고 컨트롤러가 주는대로 아웃풋을 그리는 역할 Controller : 뷰와 모델의 중간 다리 역할로, 뷰에서 일어나는 사용자 인풋은 컨트롤러에 전달. 컨트롤러는 인풋으로부터 모델에 반영하고, 모델 변화에 따른 아웃풋을 뷰를 업데이트하는 역할. MVVM은 뷰컨이 뷰의 역할만 할 수 있도록 하고, 뷰모델이 MVC에서 ..
iOS 앱의 아키텍처를 잡는 문제는 아니고, 프로젝트가 있으면 파일을 어떻게 그룹별로 관리하는 게 좋은지에 대한 글이다. 사실 회사 코드의 경우 이미 쓰임새에 맞춰 그룹별로 잘 나눠져 있어 크게 고민할 건 없는데, 개인 프로젝트를 할 때면 고민이 생긴다. 뷰 컨트롤러끼리는 같은 그룹에 둬야 하나? 아니면 같은 화면을 구성하는 것들을 같은 그룹에 둬야 하나? 그룹 구조 잡는 일은 별 거 아니라고 생각할 수도 있지만 화면이 많아지고 파일이 많이 생기다 보니 미리부터 고민을 좀 해둘걸 하는 생각이 들어서 지금이라도 쓴다. 실은 미래의 내가 참고하라고 쓰는 글에 더 가깝다. 서로 연관되어 있거나, 공통점이 있는 것들을 같은 그룹에 넣는다. 예를 들면, 같은 모듈이나 화면 등을 이루는 모델, 뷰모델, 뷰컨트롤러는..
노치 있는 status bar나 home indicator 부분까지 색상이 깔린 디자인을 받을 때가 종종 있다. 폰마다 status bar, home indicator 영역이 조금 다르다. 예를 들어, 홈 버튼이 있는 아이폰 SE 2, 3세대 등의 폰은 아예 home indicator 영역이 잡히지 않는다. 무조건 화면 아래에 constraint를 깔고 constant 34 주는 게 능사가 아닐 수 있다는 이야기다. 우선 status bar 배경색을 주는 방법부터 살펴보자. 2가지 방법이 있다. (1) statusBarManager 사용 첫 번째는 windowScene의 statusBarManager를 사용하는 것이다. UIApplication의 windows 중 첫 번째 window의 windowSce..