전체 글

뿅아리 갭알자 젠아 Github @dayo2n
🖤 iOS, Swift

[Swift] LiveActivity에 애니메이션이 넣고 싶(었)던 것..

작년 여름에 드팔이를 개발하면서 라이브액티비티에 애니메이션을 넣어달라는 요구사항이 있었다. 당시 레퍼런스를 찾아보다가 유튜브나 음악 앱에서 플레이하면 오디오 구성에 따라 움직이는 것과, 동물들로 위젯과 다이나믹아일랜드를 꾸밀 수 있는 앱으로 pixel pals를 보게 되었다. 특히 Youtube 더신자에서 위 pixel pals 소개 영상을 보고서 가능할 것이라 생각하고 디자인을 받았었다. 근데 오잉.. 애니메이션 적용이 안되더라. gif 파일을 넣는 것도 불가능했다. 드팔이는 주행 중에 실시간으로 주행습관을 트래킹하는 앱이었기 때문에 정적인 라이브액티비티는 그 의미를 주기 어려웠다. 가능한 모든 공식 자료를 뒤져보고 서치해서 나오는 모든 글을 다 찾아봤던 것 같다.. 그런데도 해결책을 못찾았고, 애니메..

🖤 iOS, Swift

[TCA] State의 변화가 정상적으로 반영되지 않을 때

10월 중반 작성된 글입니다. 열심히 써놨다가 날라간줄 알았는데 지금 보니 살아있는 🥹 지금 작업하고 있는 그리디 프로젝트에서는 아키텍처로 TCA(The Composable Architecture)를 채택하여 개발하고 있다. 그리드 시스템 기반의 macOS앱인데, shift와 클릭을 통해 여러 셀을 한번에 홀드할 수 있는 기능을 개발하던 중 발생한 이슈와 해결과정을 기록한다. 문제 상황은 gif와 같다. 녹화된 화면에서는 기록되지 않았지만 shift를 누른 상태에서 그리드를 드래그하면 현재 커서 위치까지 셀이 홀드되어야 하는데, 클릭하거나 shift 키에서 손을 떼어야 적용이 되었다. 클릭 제스처와 드래그 제스처, 키보드 제스처가 모두 각각 다르게 선언되는데, 이 문제상황에서는 드래그 제스처에 대한 처리..

🔖 독서왕 제나

[Clean Architecture] 12-14. 컴포넌트 원칙

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 12장. 컴포넌트 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 컴포넌트가 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 13장. 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다. REP(Reuse/Release Equivalence Principle): 재사용/ 릴리스 등가 원칙 CCP(Common..

🔖 독서왕 제나

[Clean Architecture] 7-11. 설계 원칙: SOLID 원칙

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이된다. SRP(Single Responsibility Principle) 단일 책임 원칙 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다. 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다. 이 원칙을 이해하는 가장 좋은 방법은 이 원칙을 위반하는 징후들을 살펴보는 일일 게다. 징후 1: 우발적 중복 Employee 클래스는 단..

🔖 독서왕 제나

[Clean Architecture] 6. 함수형 프로그래밍

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 자바 프로그램은 가변 변수 mutable variable를 사용하는데, 가변 변수는 프로그램 실행 중에 상태가 변할 수 있다. 앞의 예제에서 반복문을 제어하는 변수인 i가 가변 변수다. 클로저 프로그램에서는 이러한 가변 변수가 전혀 없다. 클로저에서는 x와 같은 변수가 한 번 초기화되면 절대로 변하지 않는다. 이는 우리에게 놀라운 사실을 알려준다. 함수형 언어에서 변수는 변경되지 않는다. # 불변성과 아키텍처 아키테거를 고려할 때 이러한 내용이 왜 중요한가? 아키텍트는 왜 변수의 가변성을 염려하는가? 경합 race..

🔖 독서왕 제나

[Clean Architecture] 5. 객체 지향 프로그래밍

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 좋은 아키텍처를 만드는 일은 객체 지향 Object-Oriented, OO 설계 원칙을 이해하고 응용하는 데서 출발한다. 그렇다면 객체 지향이란 무엇인가? 객체 지향의 본질을 설명하기 위해 캡슐화 encapsulation, 상속 inheritance, 다형성 polymorphism 세 가지 주문에 기대는 부류도 있는데, 이들은 객체 지향이 이 세 가지 개념을 적절하게 조합한 것이거나, 또는 객체 지향 언어는 최소한 세 가지 요소를 반드시 지원해야 한다고 말한다. # 캡슐화 객체 지향을 정의하는 요소 중 하나로 캡슐..

🔖 독서왕 제나

[Clean Architecture] 4. 구조적 프로그래밍

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 데이크스트라는 진공관 시대에 자신의 경력을 시작했는데, 이 시대는 컴퓨터가 거대하고, 쉽게 손상되며, 느린 데다가 결과마저 믿을 수 없는, 그래서 오늘날의 기준으로 보면 극도로 제한적으로만 사용될 때 였다.이 초창기에는 프로그램을 바이너리 또는 매우 투박한 기계어를 사용해서 작성했고, 입력은 종이테이프나 천공카드와 같은 물리적인 형태를 띠었다. 수정·컴파일테스트를 반복하는 일은 최소 몇 시간에서 며칠이 걸렸다. 데이크스트라는 이처럼 원시적인 환경에서 위대한 발견을 해냈다. # 증명 데이크스트라가 초기에 인식한 문제..

🔖 독서왕 제나

[Clean Architecture] 3. 패러다임 개요

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 최초로 적용된 패러다임은 구조적 프로그래밍으로, 1968년 데이크스트라가 발견했다. 데이크스트라는 무분별한 점프(goto 문장)는 프로그램 구조에 해롭다는 사실을 제시했다. 이에 데이크스트라는 이러한 점프들을 if/then/else와 do/while/until과 같은 구조로 대체했다. 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 두 번째로 도입된 패러다임은 구조적 프로그래밍보다 2년 앞선 1966년에 등장했다. 알골 ..

🔖 독서왕 제나

[Clean Architecture] 2. 두 가지 가치에 대한 이야기

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위 behavior와 구조structure가 바로 그것이다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다. 불행하게도 개발자는 한가지 가치에만 집중하고 나머지 가치는 배제하곤 한다. 더 안타까운 일은 대체로 개발자가 둘 중 덜 중요한 가치에 집중하여 결국에는 소프트웨어 시스템이 쓸모없게 된다는 사실이다. # 행위 behavior 소프트웨어의 첫 번째 가치는 바로 행위다. 프로그래머를 고용하는 이유는 이해관..

🔖 독서왕 제나

[Clean Architecture] 1. 설계와 아키텍처

로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. '아키텍처'는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면, '설계'는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만 실제로 이러한 구분은 무의미하다. 모든 고수준의 결정사항에는 그를 지탱하는 세부사항이 존재한다. 저수준의 세부사항과 고수준의 결정사항은 전체 설계의 구성 요소가 된다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향..

iOS MOON
다여닙니다