건우의 개발 일기

https://rjsdnqkr0.tistory.com/18 Mobile CleanArchitecture Error Handling Clean Architecture 구조에 맞게 오류를 처리하는 방법에 대한 생각 👍 Domain Error 에러는 최종적으로 사용자에게 보이게 된다. 그렇기 때문에 개발자 혼자 생각하는 것이 아닌 기획자, 디자이너와의 rjsdnqkr0.tistory.com Domain Error 개념으로 에러를 핸들링하는 방법에 대한 생각 정리 글이다 여기의 확장형으로 공통적으로 발생될 수 있는 에러를 RIBs를 통해 Scope을 지정하여 핸들링하는 방법에 대한 생각이다 🤔 Common Error Handling 시 발생될 문제점 앱에서는 공통적으로 발생 될 수 있는 에러가 존재한다. 대표적..

UIViewController 생명주기에서 loadView는 view를 맨 처음 호출하였을 때 발생된다. 그리고 viewDidLoad는 loadView 직후에 발생된다. GitHub의 여러 코드를 보았을 때, UIViewController init 타이밍에서 view의 backgroundColor를 설정하거나 addSubView를 하는 등의 코드를 적지 않게 볼 수 있었다. 하지만 앞서 말한 대로 viewDidLoad는 view를 처음 호출한 시기에 불린다. 만약에 TabBar 형태의 화면에서 ViewController를 인스턴스화 시켜 배열로 들고 있고, 이를 이용하여 화면 이동을 한다고 해보자. init 타이밍에서 view를 호출하였다면 인스턴화 시키는 과정에서 이미 viewDidLoad 까지 호출될..

Clean Architecture 구조에 맞게 오류를 처리하는 방법에 대한 생각 👍 Domain Error 에러는 최종적으로 사용자에게 보이게 된다. 그렇기 때문에 개발자 혼자 생각하는 것이 아닌 기획자, 디자이너와의 커뮤니케이션을 통해 적합한 처리를 해주어야 한다. 이때 필요한 것이 보편 언어 (Ubiquitous language)이다. 예를 들어서 기획자에게 "Decode 에러는 어떤 식으로 처리할까요?"라고 말한다면 기획자는 쉽게 알 수 없을 것이다. 사용자도 마찬가지이다. Decode, Encode Error 등은 사용자에게도 불필요한 정보이다. Clean Architecture 3 계층 중 비즈니스 로직을 포함하고 있는 Domain 계층은 Ubiquitous language를 담고 있다. Dom..

1. framework 위치 이동 simulator, device framework 분리하여 한 폴더에 위치 2. 명령어 실행 xcodebuild -create-xcframework \ -framework iphoneos/SHBDeviceInfo.framework/ \ -framework iphonesimulator/SHBDeviceInfo.framework/ \ -output SHBDeviceInfo.xcframework 해당 폴더에서 명령어 실행 3. 결과 확인 xcframework successfully written out to: /Users/a60117282/Documents/SHBDeviceInfo/SHBDeviceInfo.xcframework

😑 오늘의 삽질 🤷‍♀️ 이게 뭐지? 2월 4일 심상치 않은 메시지 하나가 날아왔습니다. 권한이 다 허용되어 있는데 Permission denied 가 뜬다는 것이었습니다 (?) 당시에는 별 큰 이슈는 아니라고 생각했습니다. 😭 🤬 아니 ㅡㅡ 이게 뭐지?? 때마침 잠시 쉬는 동안 사이드 프로젝트를 하나 해보고 있는중이였는데 저장공간에서 Permission denied 가 뜨기 시작한 것이었습니다. 제 사이드 프로젝트 특성상 저장 공간을 사용하지 못하면 단 하나의 작업도 진행할 수 없는 상황이었습니다. 아니 분명 어제까진 됐는데;; ( 구글링 → 퍼미션 확인하세요 → 돼있음 → 그럼 이 방법으로 확인하셈 → 돼있음 → ;; ) 결국 그날 작업한 코드가 문제인 건가 싶어 눈물을 머금고 Discard all ..

방학을 시작하고 도담도담 V2 작업을 진행하였습니다. 이번 포스트에서는 어떻게 V2 작업을 진행하였는지 포스팅하겠습니다. 🙄 어떻게 바꿔야 하나 저는 도담도담 코드의 리팩토링 필요성을 느껴 어떻게 리팩토링을 할까 늘 고민하였습니다. 처음 계획 처음 계획은 도담도담 코드가 발전된 순서대로 1단계부터 4단계까지 리팩토링을 하는 것이었습니다. 팀원들과 함께 이때까지 공부하며 배웠던 기술들을 차례대로 익힐 수 있게 하기 위함이었습니다. 문제점 하지만 해당 작업은 수정이 너무 잦고 많기 때문에 방학 도중 메세지로 팀원들과 리팩토링을 하기엔 시간적인 문제가 많았습니다 3월 시작하며 바로 배포 하여야 하는데 언제 어디서 오류를 뿜어낼지 모르고 변화와 확장에 민감한 V1 코드를 끌고 가긴엔 문제가 있다고 생각했습니다...