2관왕에 성공했어요 🚀 따끈따끈한 회고 # 주제를 선정하게 된 계기 이번 주제는 작년에 아카데미에서 아이작의 '혼자서 앱 만들기' 세션을 하면서부터 구상한 내용이다. iOS 개발을 시작하면 무조건 접하게 되는 SF Symbols에 대해 다루었다. SF Symbol은 애플이 제공하는 심볼 이미지이고, 스위프트로 개발할 때 시스템명만 잘 적어주면 이미지를 따로 넣거나 가져오지 않고 코드 한 줄만으로 쉽게 사용할 수 있다. 2019년 첫 발표된 SF Symbols의 가짓 수는 2,300여 개 정도였고, 점점 늘어나 현재는 그 개수만 5천개가 넘는다. 그런데 여기서 쓰고 싶은 아이콘의 이름을 모르면 어떻게 찾을까? 비슷한 단어로 계속 검색해본다 카테고리를 이용해 찾는다 일일이 찾는다 3단계까지 가면 눈알빠진다...
Error: Process completed with exit code 65. 릴리즈 스킴을 쓰려고 DontForget-Release로 설정했는데 확인이 안됐다. 기본 스킴인 DontForget으로 수정해서 해결했다. 코드가 진짜 잘못됐었다. 이미지 사용할 때 오타날까봐 String+Extension으로 static 상수를 정의해서 사용하는데 anniversaryDelete라는 상수는 없었다. 이미지 이름도 아마 이전에 사용하던 것에서 바꾸는 걸 까먹은 듯한데, 빌드 캐시에 남은게 있었는지 빌드나 배포할 때는 문제없이 동작했다.... + 24.04.15. 오류나 캐시때문에 발생한 일이 아니고 Xcode 15에서 업데이트된 내용이었다. 당시에도 에셋 이름이 anniversary_delete라서 혹시..?하..
보통 아요에서는 이미지를 다룰 때 메모리 캐시로 관리한다. 근데 이번에 다룬건 이미지는 아님 넥스터즈에서 만든 음력기념일 서비스에서 등록된 기념일의 상세 정보를 볼 수 있는 뷰가 있는데, 이 뷰가 나타날(onAppear) 때마다 서버에 이 정보를 요청한다. 그리고 연필모양의 편집 버튼을 누르면 나오는 뷰가 나타날 때나 편집을 취소하고 나올때나 편집을 완료하고 이 화면으로 돌아올 때도 매번 요청한다. 매번 네트워크 기반의 api를 주고받는 것보다, 한 번 받아온 정보는 메모리 캐시에 담아두고 정보가 수정되지 않는 이상은 캐시에 있는 값을 확인하는 게 효율적일 것 같아서 수정해봤다. import Foundation final class CacheManager { static let shared = Cache..
나는 스위프트 이전에 자바로 개발을 해왔기 때문에 .. 자바의 메모리 관리 방식을 생각해보면 가비지 컬렉션을 먼저 떠올릴 수 있다. GC(Garbage Collection) 런타임 중 더 이상 필요가 없는 garbage라고 판단되면 메모리에서 해제 반면 스위프트는 ARC라는 메모리 관리 기법이 적용된다. ARC(Automatic Reference Counting) 컴파일시 자동으로 retain, release 코드를 생성 참조 횟수를 세어 더 이상 참조되지 않는 인스턴스를 메모리에서 알아서 해제 두 기법의 가장 큰 공통점은 개발자가 따로 메모리 해제에 대해 관리할 필요가 없다는 점이며, 가장 큰 차이점은 메모리의 해제가 결정되는 시점이다. GC는 런타임 중 객체를 계속 감시하기 때문에 추가적인 오버헤드가..
넥스터즈에서 챙겨챙겨를 개발하면서 서버에 계속 접근하면서 데이터를 조회했는데, 네트워크가 조금이라도 불안정하거나 잠시라도 끊기면 기존 기념일이 화면에서 전부 사라지고 기념일 상세 조회를 하려고 하면 UI가 무너지기도 했다. 사용자 입장에서 너무 당황스러운 경험일 것 같아 네트워크 연결 상태를 확인해서 UI에 반영해주어야겠다고 생각했다. import Foundation import Network final class NetworkMonitor: ObservableObject { static let shared = NetworkMonitor() private let networkMonitor = NWPathMonitor() private let workerQueue = DispatchQueue(label: ..
내 두번째 넥스터즈 24기 이수와 함께 수료하게 되어 넥스터즈의 시니어 회원이 되었다. 작년만큼 회식이나 네트워킹에 많이 참여하지는 못했지만 어느 팀보다 실력있고 돈독한 팀을 만나게 되어서 굉장히 기쁘다 =) 1주차 24.01.06. #OT #팀빌딩 #모임모임 #자기소개 팀 빌딩이 있었던 날, 내 동기 송이가 24기 단톡방에 있는걸 보고 너무 놀래서 첫 날 같이 점심먹고 들어갔따. 넥터인들은 다들 바쁜 사람들인데, 꾸준히 대외활동에 참여하는 걸 보면 꽤 놀랍다. 몇 기수를 연속으로 참여하는 사람들도 많다. 내가 하고 싶었던 프로젝트는 딱 한 팀이라, 팀빌딩할 때 어필할 수 있는 티켓인지 명함인지가 4장 주어지는데 딱 한 팀에만 냈었다. 다들 엄청 열정적이어서 1지망에서 떨어질까봐 걱정했는데, 관상 + M..
작년 여름에 드팔이를 개발하면서 라이브액티비티에 애니메이션을 넣어달라는 요구사항이 있었다. 당시 레퍼런스를 찾아보다가 유튜브나 음악 앱에서 플레이하면 오디오 구성에 따라 움직이는 것과, 동물들로 위젯과 다이나믹아일랜드를 꾸밀 수 있는 앱으로 pixel pals를 보게 되었다. 특히 Youtube 더신자에서 위 pixel pals 소개 영상을 보고서 가능할 것이라 생각하고 디자인을 받았었다. 근데 오잉.. 애니메이션 적용이 안되더라. gif 파일을 넣는 것도 불가능했다. 드팔이는 주행 중에 실시간으로 주행습관을 트래킹하는 앱이었기 때문에 정적인 라이브액티비티는 그 의미를 주기 어려웠다. 가능한 모든 공식 자료를 뒤져보고 서치해서 나오는 모든 글을 다 찾아봤던 것 같다.. 그런데도 해결책을 못찾았고, 애니메..
10월 중반 작성된 글입니다. 열심히 써놨다가 날라간줄 알았는데 지금 보니 살아있는 🥹 지금 작업하고 있는 그리디 프로젝트에서는 아키텍처로 TCA(The Composable Architecture)를 채택하여 개발하고 있다. 그리드 시스템 기반의 macOS앱인데, shift와 클릭을 통해 여러 셀을 한번에 홀드할 수 있는 기능을 개발하던 중 발생한 이슈와 해결과정을 기록한다. 문제 상황은 gif와 같다. 녹화된 화면에서는 기록되지 않았지만 shift를 누른 상태에서 그리드를 드래그하면 현재 커서 위치까지 셀이 홀드되어야 하는데, 클릭하거나 shift 키에서 손을 떼어야 적용이 되었다. 클릭 제스처와 드래그 제스처, 키보드 제스처가 모두 각각 다르게 선언되는데, 이 문제상황에서는 드래그 제스처에 대한 처리..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 12장. 컴포넌트 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 컴포넌트가 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 13장. 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다. REP(Reuse/Release Equivalence Principle): 재사용/ 릴리스 등가 원칙 CCP(Common..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이된다. SRP(Single Responsibility Principle) 단일 책임 원칙 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다. 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다. 이 원칙을 이해하는 가장 좋은 방법은 이 원칙을 위반하는 징후들을 살펴보는 일일 게다. 징후 1: 우발적 중복 Employee 클래스는 단..
