WWDC23에서 새로 나온 API로 사용자의 위치나 비컨을 모니터링하는 새로운 방식이다.  이 글에서는 실제 내가 볼레또 프로젝트에 어떻게 적용했는지를 자연스럽게 작성할 예정입니다.사실상 너무 간단하다. 1. 원하는 이름으로 CLMonitor 인스턴스를 생성하고2. 모니터링할 조건(지리적위치, 비컨)을 정의하고3. 이벤트대기: 조건이 충족되면 이벤트를 비동기적으로 수신하고4. 동작 수행: 이벤트가 발생하면 원하는 로직을 실행한다.즉 조건에 의해 조건이 충족될때 이벤트를 비동기적으로 처리할 수 잇게 해준다.하지만 어떻게 구현되어있는지를 살펴보자  CLMonitor 인스턴스는 각각 하나의 모니터링 작업에 대한 "게이트웨이" 역할을 한다. CLMonitor는 액터로서 설계되었기 때문에, 여러 스레드가 동시에 ..

이번에 사이드 볼레또를 나의 욕심으로 프로젝트 규모를 더 키워 백엔드 개발자 총 2명 디자이너 4, 프론트는 나혼자..이렇게 팀을 구성하였다. 사실 노션으로 일정관리를 하고 백로그도 관리하여도 된다. 하지만 대부분의 기업에서 협업 툴로 JIRA를 선택하고 있고, 이슈관리, 확장성, 깃과의 연동성, 누가 일하나 감시(?)까지...ㅎ 농담이고 결국 협업을 진행할때 현상관리, 상태관리에 더 용이해 시간을 절약할 수 있을 거 같아 선택하게 되었다.  생각하는 시간과 실행하는 시간을 분리하자 지라를 이해하기 위해서 알아야 하는 개념을 먼저 보자애자일 & 스크럼결국 이걸 위해 지라를 사용한다. 프로젝트를 진행하다보면 중간에 요구사항이 바뀔수 있다. 이 요구사항들을 빠르게 대응하기 위해 애자일 방법론을 사용한다.  ..

왜 설계와 아키텍처를 고민해야 할까?작년 이맘때 처음 클린 아키텍처 책을 읽었는데, 이번에 다시 펼쳐본 이유는 명확했습니다.객체지향 설계에 대해 생각하는 기회가 생겼거든요 🤔로버트 C. 마틴(Uncle Bob)이 강조하는 핵심은 간단합니다. "빨리 가는 유일한 방법은 제대로 가는 것이다"저도 데드라인이 코앞이면 "일단 찍어내고 나중에 리팩토링하자!"라고 생각하는 개발자입니다. 하지만 현실은 어떤가요?그 '나중'은 절대 오지 않아요 😅 기능 구현 끝나자마자 바로 새로운 요구사항이 들어오죠. 그렇게 악순환이 시작됩니다.결국 처음부터 깨끗한 아키텍처로 설계하는 것이 실제로는 더 빠르고 효율적이라는걸 깨달았습니다. 기능 VS 아키텍처소프트웨어의 어원을 생각해보세요. Soft + ware = 부드러운 제품이죠..

https://www.acmicpc.net/problem/17298문제 해석먼저 문제이다. 음..? 문제 이해는 굉장히 쉽다. 그냥 나보다 오른쪽에 있는 것들중에 큰것중에 나랑 가장 가까운 놈을 찾아서 찍어주면 된다.단순히 생각할 수 있는 방법은 포인터를 이용한 방법이였다.  2중 For문을 통해 현재 내껏보다 오른쪽으로 하나씩 가면서 큰것을 발견하면 Break를 걸어주고 정답 Array에 추가해주는 방식이다. 하지만 문제를 잘 읽어보면 1,000,000까지도 가능하다. 최악의 경우 O(n제곱)인 기존의 방법으로는 시간초과가 뜰것이 분명하다. 그래서 다른 방식을 생각해보아야 했다.문제 풀이Stack을 활용하여 풀이를 한다. 먼저 가장 앞의 인덱스와 해당 넘버를 스택에 넣어준다. 그 후 한칸씩 뒤로 가며 ..

이전까지 글을 쓰고 글을 토대로 뷰와 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..

https://www.youtube.com/watch?v=nb3bRQa0iGQ&t=3s 1. Swift에서 말하는 성능이란?WWDC 2024에서 Apple의 John McCall이 발표한 "Explore Swift performance" 세션을 보면서 정말 많은 것을 배웠습니다.성능이라는 게 단순히 "빠르다/느리다"로 나눌 수 있는 게 아니더라고요.성능은 다차원적이고 상황적입니다. 여러 측면에서 성능을 평가할 수 있어요:지연 시간: 작업이 시작되고 완료될 때까지 걸리는 시간에너지 소모: 앱이 배터리를 얼마나 효율적으로 사용하는지메모리 사용: 앱이 얼마나 많은 메모리를 점유하고 어떻게 관리하는지보통 성능 문제를 조사할 때는 거시적인 관점에서 시작합니다. Instruments 같은 도구로 측정하고, 대부분은..