나의 앱 볼레또는 여행 날짜가 되면 CLMointior인스턴스에 해당하는 지역의 위도 경도를 넣어 모너터링을 키고 유저가 해당 지역에 가면 푸쉬 알람을 보내주는 기능이 핵심이다. 이전에는 모니터링 이외의 메모리 릭을 살펴봤는데 이번에는 모니터링에서 발생하는 Memory Leak을 살펴볼 예정이다.저번에 했던 Memory  debugger Graph를 다시 열어보자. 막 거미줄마냥 엮여있다.총 16개로 저번에 1개 고치는데에도 하루종일 사용했는데 이번엔 얼마나 걸릴지 막막하다. 나의 과거를 욕해야지..일단 이번에는 Command Line Tool사용하여 더 살펴보려 한다. 메모리 그래프 디버거 킨 상태에서 File > Export Memory Graph를 선택하여 스냅샷을 파일로 저장하고 해당하는 것을vm..

이전까지 글을 쓰고 글을 토대로 뷰와 Feature들에 대해 개발을 진행을 하였다. 규모가 점차 커졌고 나의 앱에서는 내가 여행중인 상태일때 coreLocation을 이용하여 특정한 위치에 갓을때 어떠한 이벤트를 주어야하기에 DI, DIP에 신경을 써야했다. 현재는 얼렁뚱땅 기존처럼 manager파일로 관리를 하였지만 TCA에서는 client라는 이름을 붙혀 외부 의존성을 추상화하고 관리하는 역할을 한다고 한다. Dependency?- 먼저 의존성이 뭔지를 알아야 한다 . 한 객체에서 다른 객체의 기능을 필요로 할때 -> 그 객체에 의존하고 있다. ex) 어떠한 뷰모델에서 다른 뷰모델의 기능이 필요할때가 있다. 그래서 다른 뷰모델을 해당 뷰모델에서 생성하고 기능을 사용할 수 있다. 이를 의존하고 있다고 ..

Dependency?= 의존성네트워크 통신, 유저디펄트, 키체인 등 의존성에 대한 관리 -> app 개발 전반에 영향을 미침을 우리는 알고 있다.스유의 프리뷰를 사용해보면 알겠지만 프리뷰에도 의존성을 주입해주어야 프리뷰를 사용할 수 있다. TCA Dependency는 개발에서 더 쉽게 관리할수 있도록 도와주는 라이브러리가 있다.먼저 요즘껏들을 알기 위해서는 역사를 알야아한다.ReducerProtocol 이전Environment라는 구조체에서 의존성 관리를 하였다. 우리가 아는 흔한 하나의 구조체에 사용해야되는 기능들을 다 넣어놓고 의존해주는 형식. 문제점: 어떤 뷰에서는 사용하지 않고 어떤 하위뷰에서 사용하더라도 여기 안에 넣어놔야한다. ㅏㅗ 귀차나.새로운 의존성을 추가할때도 선언부터 초기화까지 수정하고..

이전의 글에서 Store는 런타임동안 Reducer의 인스턴스를 관리하는 참조타입의 객체라고 하였다. 결국 상태, 액션에 대한 반응까지 모두 포함한 역할을 한다. 그렇다면 이 Store를 뷰에서는 어떻게 사용해야할까?Storelet store: StoreOfScope : 하위 State 및 Action을 다루는 스토어로 변환 ㄱㄴ. 2가지 인자를 받는다. 1. State: 상태 추출할 keypath 2. Action: 액션 추출할 Keypath. -> 즉 전체의 상태에서 너 필요한거만 Store로 줄께. => View는 필요한 상태와 액션만 접근할 수 있게된다. 모듈화, 유연성 굿(자연스럽게 유닛테스트도)ViewStoreView에 필요한 상태만 구독하고 업데이트하는 역할. 하나의 스토어에서 또 많은 작업..

처음에 UIkit을 했을때는 MVC 패턴이였다. 하지만 점점 ViewController가 하는게 많아지고 양방향이기에 유지보수도 힘들어지고 테스트도 어려웠다. 그래서 점차 MVVM 패턴으로 바뀌고 실제로 나의 사이드 거닐다 프로젝트에서는 MVVM + Combine으로 프로젝트를 하였다. ViewModel에서 input과 ouput을 View와 binding하여 뷰를 업데이트하기에 코드의 양도 줄일 수 있고, 뷰모델이 뷰와 독립적인 코드의 구조로(뷰모델이 뷰에 대한 의존성이 없다), 자체 테스트도 용이해진다. 하지만 SwiftUI를 MVVM으로 했을때는 항상 팀원하고 이야기하던게 있었다. 우리가 하는 것이 진짜 MVVM이 맞는가..?ViewModel은 State-binding을 통해 관리를 해주었지만 sw..