Tori의 개발 공부

문제 상황CheckButton을 포함한 UITableViewCell에서 다음과 같은 개선 요구사항이 있었습니다:현재는 체크 버튼을 눌러야만 셀 아이템이 선택되는 구조.체크 버튼의 크기가 작아 사용자 입장에서 누르기 불편하며, 체크 버튼 외의 영역(title 등)을 클릭해도 셀 아이템이 선택되도록 개선이 필요.이에 따라 Cell의 contentView를 클릭해도 checkButton을 클릭한 것과 동일한 로직이 실행되도록 연결하는 작업을 진행했습니다.기존 문제기존에는 contentView의 클릭 이벤트와 checkButton.rx.tap 이벤트를 별도로 관리했기 때문에 코드 중복이 발생했습니다.또한, 선택된 Cell을 직접 찾아야 하는 로직이 추가되어 비효율적이고 복잡했습니다.두 이벤트를 동일하게 처리하는..

문제 상황서버에서 임시 저장 로직 구현 시 특정 파라미터에 값이 없을 경우 null 값을 전달해야 한다는 요청을 받았습니다.하지만 [String: Any] 딕셔너리로 파라미터를 전달하고 있었으며, Swift에서는 [String: Any] 딕셔너리에 nil을 직접 추가할 수 없습니다. 예를 들어, 아래와 같은 파라미터를 서버에 전달해야 한다고 가정해 봅시다:{ "username": "example", "profilePicture": null} 여기서 profilePicture는 null로 명시적으로 보내야 한다면, Swift에서 다음과 같이 작성하면 에러가 발생합니다:var parameters: [String: Any] = [:]parameters["username"] = "example"paramet..

에러 핸들링은 소프트웨어 개발에서 피할 수 없는 과제입니다.하지만 이전 프로젝트들에서는 에러 처리 방식은 단순히 “에러 발생 시 메시지를 출력하고 멈춘다”는 수준에 머무르는 경우가 많았습니다.이렇게 단순화된 접근은 문제 해결에 필요한 정보를 제공하지 못하거나, 사용자 경험(UX)을 저해하는 결과를 초래할 수 있습니다.이번 글에서는 클린아키텍처 구조에서 맥락(Contextual) 에러와 프레젠테이션(Presentation) 에러를 도입하여 에러 핸들링 체계를 개선한 사례와 그로 인한 효과를 공유합니다.단순한 에러 처리의 한계처음 프로젝트를 시작했을 때 저희는 DataError만을 사용해 에러를 처리했습니다.예를 들어 네트워크 통신 에러, 디코딩 인코딩 에러 등 Data Layer에서 발생하는 에러들에 관해..

문제 상황프로젝트를 진행하면서 팀원들의 개발 일정 상 앱의 디자인을 어느 정도 진행 된 뒤 API 연결에 들어가게 되었다.그러다 보니 연결이 제대로 되었는지, 데이터는 제대로 받아오는지 확인하기 위해 클린아키텍처 구조 상 DataSource (API 연결부)부터 Repository, UseCase를 지나 Presentation 레이어의 뷰모델, 뷰 까지 모두 연결되어야지만 테스팅이 가능했다.그런데 이 때, 앱의 구현이 진행됨에 따라 프레젠테이션 레이어 연결 시 변경해줘야 하는 부분들이 점차 늘어났고, 테스팅 실패 시 최악의 경우 전체 구조를 변경해야 하는 경우도 있었다.따라서 이 부분에서 불편함을 느껴 단계별로 DataSource 의 API 테스트, Repository의 DTO -> Entity 변환 테..