NamS의 iOS일기

순환참조가 일어날것 같은 상황에 대해서 알아볼건데요! alert의 handler를 추가할 때 보면... alert의 action은 클로저인데 이 상황에서 self를 참조하면 개념상 순환참조가 일어날거 같잖아요? 우선 결론부터 말씀드리면 순환참조는 일어나지않아요!! 아무리 alert를 켯다껏다해도 메모리가 쌓여서 앱이 죽은 적이 없잖아요?? 한 번 생각해 볼까요!! let alert = UIAlertController(...) let action = UIAlertAction(...) { self.view = ... } alert.addAction(action) present(alert, animated: false, completion: nil) VC에서 alert를 생성해주고, action도 구현해서 a..

설정에 관련된 화면을 만들어서 테스트할 때 유용하게 사용할 수 있는 환경을 만들어볼거에요 UserDefault를 변경하여 테스트해보고 싶은경우 유용하기도해요 파일을 하나 만들어볼게요 Settings Bundle파일을 만들어주고 plist가 하나 생길거에요 이상태에서 바로 앱을 빌드하고 저 정보는 설정창에 있어요!! 설정창으로 들어가볼게요!! 들어가서 자신이 만든 앱의 설정을 들어가면 아래와 같이보여요 타입은 여러가지가 있어요 자세한건 아래 개발자문서를 참고하구요 developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UserDefaults/Preferences/Preferences.html#//apple_ref/doc/uid/10000059..

앱의 생명주기에 대해서 알아볼거에요 우선 iOS13을 기준으로 최신버전에는 SceneDelegate라는 파일이 생성되는게 보일거에요 새로운 개념이죠 다음에 알아보도록하구요! 지금은 AppDelegate 위주의 단순한 App의 생명주기에 대해서 알아보려고해요 아래그림은 왼쪽은 AppDelegate 오른쪽은 SceneDelegate가 있는상태일때 생명주기에요 예전그림이 변경어서 살짝 헷갈리지만 기본적인 개념은 같아요 예전그림은 이런 모습을 하고 있엇구요... 아무튼! 당연히 변경된 최신거를 참고해야겟죠??! 각 상태를 정리해볼게요 Active - 이벤트를받고, 일반적으로 앱이 실행되는 상태에요 Inactive - 앱의 상태변화시에 거치게되구요, 이벤트는 받지않는 상태에요 (Background로 전환시 거치는..

스위프트에는 여러종류의 init이 있다는거 알고계셧나요? 객체를 생성할 때 제공되는 함수를 말하구요 생성자를 통해서 객체를 생성할 때 원하는 값을 설정해서 만들 수가 있어요 designated init custom init default init convenience init required init failable init memberwise init 이제부터 하나하나 위에서 언급한 init을 알아볼게요 designated init 지정된 초기화라는 뜻이에요 보통 지금까지 많이 봤던 init이에요 모든 class는 적어도 1개이상 가지고 있어야해요 선언되지않으면 default init함수가 제공되요 하지만 이때 저장프로퍼티가 있는데 초기화가 안되어있다면 불가능해요 class를 만들때 변수초기화를 꼭 해..

서버에서 이미지를 불러올때 이미지 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..