NamS의 iOS일기

서버에서 이미지를 불러올때 이미지 URL을 받고 다시 해당 URL로 통신을 하는 식으로 이미지를 받아온다면 비효율적이겠죠?? 또한 이미지크기도 크다고하면 더욱 좋지 않을거같아요..! 그래서!! 효율적인 캐시처리에 대해서 알아볼거에요 캐시란 기기 안의 임시 저장소를 뜻하는거에요 임시 저장소를 통해서 이미지를 넣어두고 빠르게 보여줄 수 있고 효율적인 통신을 할 수 있어요 캐시에는 두 가지 종류가 있어요 memory cache - 기기를 끄면 사라져요 이 캐시기능을 스위프트에서 지원을 해주죠 NSCache 를 사용해서 구현 할 수 있어요 disk cache - 기기안에 저장 되어있고 껐다 켜도 남아 있어요 이 부분은 경로에 따라서 앱을 삭제할때 사라지게할수도, 앱을 삭제해도 남아있게할수도 있을거같아요 User..

COW 처음 들어보는 분들도 있을거에요 정의를 먼저 말하자면 수정(쓰기)가 일어날때 복사한다 라는 뜻이에요 스위프트의 CollectionType인 Array, Dictionary, Set에 적용되는 개념이에요 참조를 통해서 불필요한 복사를 줄여서 메모리를 좀 더 아껴쓸 수 있어요 예시로 알아볼까요?? let a = [1...30] let b = a 이런 코드가 있어요 그럼 일반적으로 생각해보면 a도 30개의 배열을 할당 받고 b도 30개의 배열을 할당 받을 거에요 그쵸?? 배열 인덱스당 하나의 메모리를 할당 받아요 자료구조 배울 때 배열 처음[0]과 다음[1]인덱스의 주소값이 달랐던게 새록새록 기억나시나요..? 인덱스하나당 메모리를 할당받아요 만약 1000개, 10000개, 100000....0개 라면?..

요즘 정신이 없어서 글을 못 올렸네요... 반성... 이번에는 디버그용앱과 릴리즈용 앱을 구분해서 폰에 같은 앱이지만 두 개의 앱(?)이 나타날 수 있도록 하는 작업을 해볼 거예요 이걸 왜 해요 굳이 불편하게...?? 음... 제가 생각하기에는 우선 xcode 디폴트로 debug용 앱이 설치가 돼요 근데 뭐 마켓에서 다운로드하거나, 테스트플라이트로 다운받거나하면 release용 앱이 다운받아지거나 뭐 그런... 다운하면서 겹쳐져서 기존 개발하던 앱이 사라지고 받아지는 경우가 있어서... 개발용으로만 따로 빼고 싶어서 하는 거 같아요 Xcode위에를 보면 Edit Scheme를 누르면 미리 만들고 게시글을 써서.. 여기에 있는 WiTH_Dev는 이 글을 보면서 곧 만드실 거예요...! 이렇게 빌드 설정이 ..

Subject란 Observable에 값을 추가하고 방출할 수 있도록해주는 기능이에요 즉, Observable(방출자)이자 Observer(구독자)의 역할을 모두할 수 있다고 생각하면되요 Cold Observable을 Hot하게 만들어 줄 수 있다고 해요 Hot Observable 생성과 동시에 이벤트를 방출 처음생성된 이벤트 부터 받지못하고 중간부터 나온 이벤트부터 구독가능 여러 Observer가 하나의 Observable을 공유 가능 publish, replay ... 등 Subject타입 (이벤트 방출시작) 1 2 3 4 (구독시작) 5 6 7 이런식으로 스트림이 존재하고 구독시작시 1 2 3 4의 이벤트는 받지 못하는거에요 Cold Observable 구독되는 시점부터 이벤트를 방출 처음부터 방출..

이번 게시글에서 구현할 기능은 파티클 효과입니다! 어떤 효과냐구요..? 우선 영상으로 예시부터 볼게요 카톡에서 겨울에 눈올때 나타나는 효과같은거에요 오늘은 이 타입을 사용해서 구현할건데요 파티클 시스템을 render해주고 애니메이션도 넣어서 방출해준데요! 이거와 같이 사용하는게 이 타입이에요 CAEmitterLayer로 방출될 파티클을 지칭하는 것같죠? 따라서 CAEmitterLayer라는 컨테이너에서 CAEmitterCell이라는 파티클을 뿌려주는 느낌이에요 엄청 다양한 프로퍼티들이 많이있어서 하나하나 모두 보진않고 사용한것 위주로 봐볼게요 CAEmitterLayer 정의 func createParticles() { let particleEmitter = CAEmitterLayer() particleE..

RxSwift를 이용해서 TableView 혹은 CollectionView를 구현하는 방법에는 여러가지가 있지만 제가 자주사용하는 방법을 정리해봤어요 2가지의 방법이있어요 reuseIdentifier을 미리 입력해서 코드를 간결하게 하는방법 reuseIdentifier을 구분해서 cell을 구현하는 방법 아래는 하나의 reuseIdentifier만 쓸 때의 코드에요 같은 cell을 쓰기 때문에 미리 넣어주고 내부코드는 간결해져요 bind(to: tableView.rx.item(cellIdentifier: )){ (indexPath, cellViewModel(cell의 모델), cell(셀) } 여기서 cell의 모델은 boardList를 사용했으니까 그 타입의 모델이 반환돼요 viewModel .boar..

Rx를 이용해서 개발하면서 Combine할때 유용한 Operator를 소개할게요 제 주관적으로 자주쓰이는것을 골라봤어요 Combine Operator는 말그대로 서로다른 스트림을 하나의 스트림으로 합쳐서 사용할 때 유용하게 쓰일거에요 CombineLatest 최초 두개의 스트림에서 각각 하나씩 이벤트를 받아온 뒤부터 두개의 스트림중 한쪽에서만 이벤트가 발생해도 새로운 스트림에 이벤트를 받아올 수 있음 그림이 이해가시나요? 처음보면 어려울수도있어요 숫자스트림과 알파벳스트림 이렇게 2개의 스트림이 존재하구요 숫자스트림은 1, 2, 3, 5 이벤트를 알파벳스트림은 A, B, C, D이벤트를 발생하죠? 처음에는 두스트림에 모든 이벤트가 있어야 새로운 스트림에 이벤트가 들어와요 1과 A가 차례대로들어오면 그때 새..

2020/05/17 - [iyOmSd/Title: Swift] - [Swift] Coordinator Pattern (1/2) - 기본원리 [Swift] Coordinator Pattern (1/2) - 기본원리 iOS 아키텍쳐의 종류는 다양해요 MVC, MVP, MVVM, VIPER, RIBs... 등등 많은데 MVC-C, MVVM-C 이러한 표현을 보신적도 있지않나요?? 여기서 C는 Coordinator를 의미해요 Coordinator란?? 화면의 흐름을 제어해주는.. nsios.tistory.com 전게시글에서 Coordinator가 어떤 원리로 돌아가는지 느낌을 살펴봤구요 이제 써먹을 수 있도록(?) 구현해볼게요 제가 생각한 Coordinator는 Navigation을 각 하나씩 가지고있어요 따라..

2019/10/27 - [iyOmSd/Title: Swift] - [Swift] Alamofire를 사용하여 API JSON 데이터 받기 (1/2) 예전에 Alamofire을 사용해서 통신했었는데요!! Swift버전도 올라가고, 더좋은 방향으로 발전해나가기 때문에 변경사항이 좀 있어요!! 사용법은 거의 비슷한데 살짝 바꼈더라구요 글작성시 사용한 Alamofire 버전은 5.1 이구요! struct LoginServiceImp: LoginServiceProtocol { func requestSignUp(form: SignUpForm) { var urlComponent = URLComponents(string: BaseURL.shared.getBaseString()) urlComponent?.path = R..

iOS 아키텍쳐의 종류는 다양해요 MVC, MVP, MVVM, VIPER, RIBs... 등등 많은데 MVC-C, MVVM-C 이러한 표현을 보신적도 있지않나요?? 여기서 C는 Coordinator를 의미해요 Coordinator란?? 화면의 흐름을 제어해주는 역할 라우팅 VC관리 이런 단어들이 어울리겟네요 말이 좀 어렵지만.. 위 그림처럼 이런 원리라고 생각하면 쉽게 접근할 수 있어요 VC에 ViewModel를 의존성주입(DI)하듯 VC를 생성하고 필요한 의존성주입을 할 수 있어요 기존에는 Storyboard에서 VC를 관리하고 이동시켰어요 라우팅관리를 모두 Storyboard에서 했었죠 혹은 ViewController가 담당했죠 Coordinator를 사용하면 Coordinator가 VC의 이벤트도 ..