What is SilentPush?- 백그라운드에서 앱 업뎃하기 즉 유저가 느끼지 못하게 앱 내에서 정보를 업뎃해야할 때 사용한다. 내가 개발하는 앱에서는 해당 날짜의 여행이 있을때 silentPush로 상태 변화를 위해 사용했다. 기존의 코드에서는 매일 24시간마다 백그라운드에서 allFetch를 통해 여행이 있는지를 체크해주었지만 이는 여행이 없더라도 매일 백그라운드에서 업뎃을 하기에 비효율적이라고 판단했다.Silent Push 페이로드에서는 3가지가 값이 추가로 있어야 가능하다고 한다. "content-available": 1, "apn-push-type": "background","apn-priority": 5apple developer에 보면 이 푸쉬는 우선순위가 낮아 짧은 시간에 노티피케이션 ..

TCA의 테스트코드 적용을 살펴보기 전에 먼저 TestCode에 대해 생각해보고 가려한다. 어디까지 짜야하고 어디까지 커버리지를 올려야하는가..에 관한 얘기가 될수 있을거같다.먼저 Unit Test와 UITest가 있다. Unit test : 특정함수, 메소드 동작 테스트(로직테스트) => 전체프로그램을 빌드하는대신 유닛단위로 빌드해 시간절약UI test : UI and UI actionUnit test1. import XCTest( Test는 XC framework를 기반으로 이루어져 있음)2. class 는 XCTestCase를  상속받음. 3. setUpwithError() 테스트 각각의 항목이 실행될 때 테스트. 테스크 클래스가 갖고있는 각각메소드가 실행될때 이게 한번씩 실행4. 위와 반대로 테스..

이전까지는 테스트코드나 프리뷰 코드 없이 오직 Dependency의 라이브밸류를 통해서만 개발을 테스트하고 진행했다. 하지만 이렇게 하다보니 계속 빌드를 해야한다는 단점이 있었고 원하는 플로우를 보기위해 과정이 커질수록 시간이 오래걸리고 임의의 값을 넣어 테스트하기도 힘들었다. 그래서 드디어 테스트 코드와 프리뷰코드를 공부해보려 한다. ㅠㅠㅠ 늦었따!https://axiomatic-fuschia-666.notion.site/Chapter-9-TCA-Testable-Code-ad3924113fbb4f89a06f30ddb8e884f7 Chapter 9. TCA와 Testable Code | Notion9.1 유닛 테스트axiomatic-fuschia-666.notion.site역시나 노션문서를 통해 참고하여..

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

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

내 기억상으로는 작년 정확히 이맘때 이 책을 읽었던 경험이 있다.  이번에 객체지향에 대해 생각할 기회가 생겨 어떤 책을 읽을까 고민하다 다시 돌아왔다. 그 이유로는 객체지향 또한 아키텍처이다. 왜 우리는 아키텍처 즉 설계에 신경을 쓰고 개발을 진행해야할까?를 먼저 고민하며 정리하는게 순서가 맞다는 생각이 들었다.  당연히 내가 글을 쓰기에 사견이 들어간다. 양이 많기에 먼저 로버트선생님이 말씀하신 벽돌까지만 만들고 그 후는 다음 글에서 쓸 예정이다.1. 설계와 아키텍처란?나: 데드라인이 코앞이다. 그러면 개발자인 나는 일단 먼저 찍어내고 추후에 리팩토링해야겠다를 머리속에 가진 사람이다. 하지만 이 책에서는 나와 같은 사람을 꾸짖고 있다. 이렇게 되면 결국 생산성의 결과로 보았을때는 더 안좋아진다고 한다..

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에 필요한 상태만 구독하고 업데이트하는 역할. 하나의 스토어에서 또 많은 작업..