일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- IOS
- combine
- 쏙쏙 들어오는 함수형 코딩
- LGTM
- ChatGPT
- auto_assign
- github
- SwiftUI
- 하드디스크 삭제 원리
- flutter
- print 단점
- CI
- Swift
- os_log
- swift github action
- Swift thread
- 오픈소스
- 함수형 프로그래밍
- Apple Developer Academy @ POSTECH
- 액션과 계산 데이터
- xcode
- unittest
- Firebase
- SwiftUI VStack
- 함수형 코딩
- firestore
- swift CI 적용
- XCTest
- 2기화이팅
- MVVM
- Today
- Total
목록Swift/UIKit (6)
개발공방
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/q1UBt/btsnEjPE0Ra/1CDKBjJOYskpGuORSDRUx0/img.png)
노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다 https://mingwan.notion.site/MVVM-Combine-Input-Output-2-3ad9c58dc84c4d0c9a14a34c52b25370?pvs=4 https://dev-workplace.tistory.com/23 [애니또] MVVM + Combine - 리팩토링 (3) 노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다. https://www.notion.so/MVVM-Combine-323ab64639374213b1b1734fcea257e7?pvs=4 [애니또] ViewController와 View의 분리 - 리팩토링 (1) [애니또] View dev-workplace.tistory.co..
노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다. https://www.notion.so/MVVM-Combine-323ab64639374213b1b1734fcea257e7?pvs=4 [애니또] ViewController와 View의 분리 - 리팩토링 (1) [애니또] ViewController와 View의 분리 - 리팩토링 (1) 현재 애니또 iOS팀이 직면한 문제 현재까지 개발하면서 많은 문제와 버그들을 만났다. 첫 문제들을 해결하는데는 어려움이 없었지만, 앱의 규모가 조금씩 커지면서 문제들이 서로 엮이기 시작했 dev-workplace.tistory.com 앞전에 작성한 글을 보면, UIViewController에서 View를 분리한 과정을 볼 수 있다. Delegate 패턴..
애니또 팀에서 아키텍쳐 패턴을 고민하던중 MVVM을 선택하게 되었다. 어떤 이유로 선택하게 되었는지 알아보겠다. 애니또 iOS 팀에서 MVVM을 선택한 이유 1. 테스트 가능성 우리의 목표는 테스트 가능한 코드였다. MVC에서는 테스트가 물론 가능할지 몰라도, 번거롭다. 왜냐하면 UIViewController에서 테스트가 필요한 함수들이 UI 코드와 엮여있기 때문이다. 테스트를 하기위해 UI관련 코드까지 작성해야하는 문제가 발생한다. 이런 문제들을 MVVM으로 해결할 수 있다. 비즈니스 로직들을 ViewModel이 소유하고 ViewModel은 View에 관해 일절 모른다. 그러기에 테스트 가능한 코드를 만들기 유리하다. 사실 1번의 이유만으로 충분하다. 2. 기능을 추가하기 힘든 기존의 아키텍처 패턴 M..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dTdQpm/btsbjjifgYA/XYZ8CkVtNJdkG3C7cKEKg1/img.png)
현재 애니또 iOS팀이 직면한 문제 현재까지 개발하면서 많은 문제와 버그들을 만났다. 첫 문제들을 해결하는데는 어려움이 없었지만, 앱의 규모가 조금씩 커지면서 문제들이 서로 엮이기 시작했다. 그래서 A라는 문제를 해결하면 B라는 문제가 다시 발생하는 상황이 생겼다. 이렇게 우당탕탕 앱을 만드는 것이 아니라 정형화된 틀이 필요했다. 그리고 각자가 만드는 기능들을 다른 팀원이 테스트하는데 굉장한 어려움이 있었다. 각자가 해당 브랜치로 가서 그 상황을 똑같이 만들어야 테스트가 가능했다. (그래서 PR에 테스트 방법을 상세히 적기도 했다) 애니또 팀에서 리팩토링을 진행한 이유 이젠 그 방식이 아니라 테스트 코드가 포함된 코드를 만들고 싶었고, 팀원끼리 상의한 결과 차근차근 리팩토링을 진행하자! 였다. 현재는 그..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/wIStG/btrUuGtJvk2/VzF3xY4d7LVMk6G0XRrkE0/img.gif)
크리스마스를 맞아 평소 해보고 싶었던 UIBezierPath를 끄적여 보기로 했다. 다들 즐거워하는 크리스마스이기 때문에 그냥 그림을 그리기 보단 의미있는 것을 그리고 싶었다. 그래서 크리스마스 트리를 그리기로 결정했다. UIBezierPath가 어떤건지 대충 알긴하지만 직접 사용해본적은 없었기에, 꽤나 흥미로웠다. 참고 : https://zeddios.tistory.com/814 zedd님의 정리를 참고했다. 정리가 매우 완벽하기 때문에 다른 글을 필요없이 저 시리즈를 쭉 훑어보면 이해가 될 것 같다. zedd님의 글엔 사람들의 이해를 돕기위해 viewDidLoad나 draw 함수에 다 정의되어 있는데, 난 내 방식대로 코드를 짰다. (property를 미리 만들고, 그리는 함수를 분리하는 식) (보시..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bkeCoB/btrHlzeVtlP/cWSMGYpLoKjl2m5KAacf6K/img.png)
제가 이해한 내용을 이해하기 쉽게 정리합니다. 혼잣말하는 느낌으로 작성해서 반말로 작성했습니다 ! DispatchQueue를 사용해야하는 이유는 도대체 뭘까?? -> 비동기적으로 처리해야할 데이터(API 통신) 가 있을 때 사용한다. (우리가 어떤 앱을 실행했을때 바로 뭔가가 뜨지않고 1~2초후에 뜨는게 API통신으로 어떤 데이터를 불러오기 때문이다.) 비동기적이란 ?? 순차적(직렬적)으로 진행되는 작업이 아닌 병렬적으로 진행되는 작업 이게 무슨 말이지 ?? 1번(2초 걸리는 작업) 2번(3초 걸리는 작업) 3번(1초 걸리는 작업) 4번(2초 걸리는 작업) 으로 수행되어야할 작업이 있을 때 동기(Sync) : 1번이 끝나야 2번이 실행되고, 2번이 끝나야 3번이 실행되고 ... 그럼 총 8초가 걸릴것이다..