[TIL] 2022 / 08 / 27

Repository Pattern

 

 

 

이번에 다이어리 프로젝트를 진행하면서 처음에는 뷰컨트롤러마다 localRealm을 선언해서 작성하였음.

 

이렇게 구조를 짠다면 하나의 컬럼이 추가되는 등의 업데이트가 생긴다면 모든 뷰컨트롤러에서 각각 대응해야함.

 

그래서 Repository Pattern이라는 것을 적용해봄.

 

 

장점

 

-> 데이터 저장소와 데이터를 표현하는 곳이 결합된 문제를 해결할 수 있음.

-> 데이터 구조를 변경하더라도 모든 뷰컨트롤러에서 대응하지 않아도 됨.

 

단점

 

-> Repository 구조체와 각 뷰컨트롤러를 매핑하는 것은 피할 수 없음.

-> 코드가 많아짐.

 

https://devming.medium.com/repository-pattern에-대해서-255731577927

Repository Pattern에 대해서

 

다이어리에 적용

 

 

아래처럼 Repository를 만들고, 뷰컨트롤러에서는 인스턴스를 만들어 메서드를 사용.

 

 

 

.toggle()

 

 

Bool값을 다룰 때 사용할 수 있는데, 반대값으로 바꿔줌.

 

 

 

Optimization(최적화)

 

 

스위프트에는 세 가지 최적화 수준을 제공하고 있음.

 

- Onone: 최소한의 최적화를 수행. 모든 디버그 정보를 보존하기때문에 주로 디버그 모드에서 사용.

- O: 적극적으로 최적화를 수행. 디버그 정보를 보존하지않으므로 release모드에서 주로 사용.

- Osize: 코드의 사이즈를 최소화.

 

 

WMO(Whole - Module - Optimization)

 

 

일반적으로 스위프트는 각 파일을 개별적으로 컴파일함.

 

하지만 WMO가 설정되어있다면 전체 프로그램을 하나의 파일인 것처럼 컴파일함.

-> 단일 컴파일 단위인 것처럼 최적화 가능.

 

컴파일 할 규모가 커져서 컴파일하는 시간은 길어지지만, 실행은 더 빨리 이루어질거임.

 

따로 설정해주지않으면 항상 설정되어 있음.

 

 

 

Method Dispatch

 

 

 

프로그램이 어떤 연산을 통해 어떻게 해당 메서드를 실행할지 정하는 매커니즘을 Method Dispatch라고함.

(동기 비동기에서의 dispatch와는 다름)

 

Method Dispatch에는 Static Dispatch와 Dynamic Dispatch가 있음.

 

코드 실행에 대한 결정이 컴파일 타임에 이루어지는지, 런타임에 이루어지는지에 따라 최적화가 결정되고 이에 따라 Static Dispatch인지 Dynamic Dispatch인지 결정됨.

 

Static Dispatch

 

-> 컴파일 타임에 호출되는 함수가 무엇인지 결정되므로 런타임때는 정해진 함수가 그대로 실행

-> 값 타입과 참조 타입 모두 지원

-> 열거형과 구조체는 기본적으로 Static Dispatch지원

 

Dynamic Dispatch

 

-> Static Dispatch와 달리 런타임에 호출되는 함수가 무엇인지 결정되므로 성능 상 오버헤드 발생

-> 부모 클래스를 상속받아 메서드를 재정의해서 사용하기때문에 컴파일 타임에 호출되는 메서드를 결정할 수 없음.

-> 오버라이딩이 될 수 있는 가능성이 있기 때문에, 런타임때 다른 클래스의 메서드를 참조해야하는지 확인하는 작업이 진행됨.

-> 참조 타입만 지원

-> 클래스는 기본적으로 Dynamic Dispatch지원

 

이 Dynamic Dispatch를 줄임으로써 성능을 향상시킬 수 있음.

-> 참조 여부를 확인하는 등의 작업을 접근 제어 등을 이용해 줄인다면 성능이 향상될 것임.

 

아래의 링크를 보면 애플에서 알려주는 최적화 팁이 있음.

https://github.com/apple/swift/blob/main/docs/OptimizationTips.rst#reducing-dynamic-dispatch

 

• 클래스에서 재정의, 오버라이딩이 필요없는 경우에 final을 붙여 상속을 방지함.
  -> 상속을 방지한다면 컴파일 시점에 어떤 메서드가 실행이 되는지 명확하게 결정할 수 있으므로 성능 이점이 있음.
  -> Dynamic Dispatch로 실행되는 클래스를 Static Dispatch로 사용하게 하는 방법임.
  -> 프로퍼티와 메서드에도 사용가능(상속이 가능하게 class func으로 선언한 메서드에 final을 추가하면 static func을 사용한 것과 동일.
• 스위프트 파일 외부에서 접근할 필요가 없는 경우, private과 fileprivate를 사용.
  -> 선언된 파일에 대한 가시성을 명확하게 확인 가능하므로, 특정 파일에 제한되는 것을 컴파일러가 확인할 수 있어 재정의 여부를 확인할 수 있어, final 키워드를 유추할 수 있음.
• 만약 WMO가 설정되어있다면, 모듈 외부에서 접근할 필요가 없는 파일에 대해 Internal로 선언.
  -> Internal로 선언되어있으면, 모듈 외부에서 확인할 수 없기 때문에 final을 내부적으로 유추할 수 있음.

 

 

Date()

 

UTC를 Date형태로 반환.

 

.formatted()를 사용하면 사용자 위치의 시간을 String형태로 반환

 

 

 

Locale

 

 

디바이스에서 Locale.current.languageCode를 출력해보면 en이 출력됨.

 

디바이스가 한국어로 설정되어 있어도, Xcode내의 Localization쪽에서 base로 영어만 되어있어 그런 것 같음.

 

Localization에서 한국을 추가해준 뒤, 출력해보면 ko가 뜸.

 

FSCalendar를 사용할때, locale을 따로 지정해주지않고 디바이스에서 빌드하면 이 localization에 따라서 영어로 표시되는 것 같음.

 

 

 

백업 / 복구

 

 

다이어리 과제에서 백업 / 복구를 구현했음.

 

근데 복구를 하고 window의 루트뷰컨트롤러를 바꿔줌으로써 앱을 다시 실행하도록했는데 적용이 되지 않았음.

 

이유는 실제 앱 첫 시작 로직과 단순히 window의 루트뷰컨트롤러를 바꿔주는 로직은 같지 않기 때문임.

 

메모리에 기존의 realm이 올라가있는데 복구를 하더라도 기존의 것이 메모리에 남아있음.

-> 복구 파일을 다른 폴더에 압축 풀고, 기존 realm파일을 지우고 복구한 파일을 원래의 document폴더로 옮겨주면 해결가능

-> 하지만 굳이?싶음. 주로 JSON파일로 만들어서 백업 복구를 구현한다고 함.

 

 

 

Document에 폴더 생성

 

 

파일을 생성하는 것과 동일함.

 

우선 documentDirectory을 구해서 폴더 경로를 정한 뒤, 같은 이름의 폴더가 존재하지않는다면 폴더 생성

 

즉, 위의 코드는 images라는 폴더를 document폴더 내에 생성하는 코드.

 

 

 

코드로 TabBarController

 

 

 

탭바컨트롤러도 Base를 따로 만드려고했었음.

 

근데 재사용되지않고 탭바 컨트롤러는 한 번만 호출되므로 만들 이유가 없음.

 

처음에 뷰컨트롤러들의 탭바아이템 이미지 설정하는 코드를 setUpAppearance에 작성했었음.

 

근데 앱이 처음에 실행됐을때 분명 0번째 인덱스 뷰가 보여졌지만 탭바 아이템은 선택되지 않은 것처럼 나왔음.

 

setUpView쪽으로 코드를 옮겨주니 해결됐음.

 

내 생각엔 setUpAppearance코드가 더 나중에 실행되는데 탭바 아이템을 마지막에 정해주면 탭바 컨트롤러가 set된 이후에 설정되어서 그런게 아닐까 싶음.