머성이의 개인 스터디

NScash와 Dictionary의 차이

pockpock — Thu, 29 Aug 2024 00:45:08 +0900

NScash (NSCache)

정의: NSCache는 Apple의 Foundation 프레임워크에서 제공하는 클래스. 데이터를 캐싱하고 관리하며, 메모리 관리와 성능 최적화에 중점을 둔 설계. 메모리 부족 시 자동으로 캐시된 객체를 제거하는 기능을 제공.
특징:
- 캐시된 객체는 강한 참조(strong reference)를 가지지만, 메모리 부족 시 자동으로 제거될 수 있음.
- 캐시의 크기나 객체 수를 제한 가능.
- 스레드 안전(thread-safe)하며, 여러 스레드에서 동시에 접근 가능.

딕셔너리 (Dictionary)

정의: Swift의 Dictionary는 키-값 쌍으로 데이터를 저장하는 컬렉션 타입. 특정 키를 통해 값을 빠르게 검색, 추가, 삭제 가능.
특징:
- 크기가 고정되지 않으며, 필요에 따라 자동으로 확장됨.
- 각 키는 고유해야 하며, 동일한 키에 대해 여러 값을 저장할 수 없음.
- 스레드 안전하지 않으므로, 여러 스레드에서 접근할 경우 적절한 동기화 필요.

차이점 요약

용도: NSCache는 메모리 효율성을 고려한 임시 데이터 저장소로 사용되며, 메모리 부족 시 자동으로 데이터를 제거하는 기능 제공. 반면, Dictionary는 키-값 쌍을 관리하는 기본 데이터 구조로, 메모리 관리나 캐싱 관련 기능 없음.
메모리 관리: NSCache는 메모리 부족 시 데이터를 자동으로 제거하지만, Dictionary는 이런 기능이 없어 메모리 관리를 직접 신경 써야 함.
스레드 안전성: NSCache는 스레드 안전하지만, Dictionary는 스레드 안전하지 않음.

이 두 클래스는 각자의 사용 목적에 따라 활용, 캐시 데이터를 관리할 필요가 있다면 NSCache, 일반적인 키-값 데이터 구조가 필요하다면 Dictionary를 사용.

Swift RxSwift

pockpock — Thu, 1 Aug 2024 23:16:06 +0900

RXSwift

마이크로소프트에서 제공하는 ReactiveX를 적용한 스위프트 서브파티 라이브러리

ReactiveX: 비동기프로그래밍과 옵저버 패턴을 사용하기 쉽도록 돕는 라이브러리(반응형 프로그래밍)

→ 유지보수성이 좋고 가독성 높은 코드를 작성할 수 있음

안드로이드 앱 개발자와 중요한 로직 등 싱크를 맞출 수 있음

→ 왜? ReactiveX 프로그래밍 철학을 따르기 때문

많은 기업에서 RXSwift 를 사용하는 경우가 많기 때문에 배워두면 좋음

참고로 리액터킷이나 립스 사용하는 회사면 기술적으로 성장하기 좋은 회사인것 같아여

Observable

Observable = 관측 가능한 대상
- Combine의 Publisher와 동일
이벤트&데이터를 방출하는 클래스 → 구독하고 있던 구독자(=관찰자, =옵저버)가 반응하여 어떠한 로직을 수행
subscribe(구독하는 것), Observer(관찰자)
일반적으로 선언하는 변수와 다르게 스트림의 성질을 갖는다
선언한 값들은 한번 값을 가지면 그 값 자체로 의미를 갖지만 RX는 방출된 값(이벤트)에 따라서 반응한다
- onNext: 정상적인 데이터 방출
- onError: 에러 방출
- onCompleted: 옵저버블의 종료 방출
데이터 방출 사이에는 시간적인 개념과 데이터의 흐름이 포함된다
DisposeBag → 구독을 끝낸 뒤 자동으로 메모리 처리(구독 해제됨)
Disposables → 작업이 완료된 후 사용된 리소스를 정리하는 데 사용. (Observable의 생명 주기를 관리하고, 필요하지 않은 리소스를 해제하는 역할)

Single

Single → 옵저버블 중에서 값을 한번만 방출하는 옵저버블

Combine의 Just와 동일
방출값
- onSuccess : 옵저버블의 onNext와 동일
- onFailure : 옵저버블의 onError와 동일

Subject

Subject → 옵저버블 중에서 외부에서 값을 넣어줄 수 있는 옵저버블

BehaviorSubject
- 초기값이 있는 Subject
- Combine의 CurrentValueSubject와 동일
PublishSubject
- 초기값이 없는 Subject
- Combine의 PassThroughSubject와 동일

정리하자면

비동기 이벤트를 관찰 가능한 형태로 만든 것이 Observable,

Observable은 해당 비동기 이벤트가 발생했을 때 항목(Item)을 방출함

관찰 가능한 형태인 Observable을 관찰하는 것이 Observer,

Subscribe(onNext:...) 메서드를 통해 Observable을 구독할 수 있다.

Xcode Instruments

pockpock — Wed, 31 Jul 2024 21:06:56 +0900

혹시 다들 Xcode Instruments에 대해 알고 계신가요?

요 친구인데, Xcode에서 제공하는 앱의 성능 분석 및 디버깅 도구임.

앱 개발자라면 메모리 릭이 나지 않는 앱을 개발해야 하므로, 메모리 릭에 대한 분석을 할 때

이 친구를 활용하면 좋음.

코드를 실행하면 스택에 쌓이면서 코드를 수행하게 되며, 이를 콜 스택이라 부름

이 스택을 뒤돌아보며 코드가 수행된 기록을 훑어보는 것은 스택 트레이스임.

아니, 그래서

Xcode Instruments 사용은 언제하는건데?

앱의 사이즈가 커지고, 프로젝트에 작성한 코드량이 많아질수록, 메모리 릭이 발생하는 곳을

파악하기 어려울 수 있음

물론, 가능하다면 직접 살펴보는 것이 좋겠지만 도구가 있는데 써먹어야지!

한번 사용법을 같이 공부해 보자고요!

먼저, 써먹기 위해서는 메모리 누수가 나는 상황을 만들어야겠지?

시나리오1

자자 어때, 코드만 봐도 어지럽지?

예전 우리는 메모리 누수가 나는 상황은 순환 참조가 나는 상황이라고 배웠으므로

Class A와 B가 서로를 순환 참조하도록 설정해 봤음

자, 이제 상황이 만들어졌으니 한 번 직접 보자고

커맨드 + i 눌러서

요 창을 띄운 다음, Leaks을 골라주자

그럼 요런 창이 나올 거고,

버튼을 눌렀을 때부터 사진처럼 빨간색 X표시 가 생성됨.

그리고 아래 탭을 보면 Call Tree라는 것이 있는데, 클릭하고 하단에서

요 친구들을 체크해 주면 콜 스택을 쉽게 확인할 수 있음

콜스택 아래서부터 순서대로 읽어보면,

AppDelegate에서 앱 시작 -> 뷰컨.buttonTapped 실행 -> ClassA에서 메모리릭 발생

확인이 가능해서, Reveal in Xcode 클릭하면

Xcode상에서 메모리 릭이 발생한 부분으로 이동이 가능!

오늘 알아볼 것은 여기까지!

다음에 봐요~

다시 한 번 돌아보는 제네릭

pockpock — Tue, 30 Jul 2024 17:53:50 +0900

Rx를 들어가기 전! 제네릭에 대해서 복습 겸 한 번 정리해 보자고!

제네릭.. 이름부터 간지 철철❗️

애플 말에 따르면 Swift에서 가장 강력한 기능 중 하나가 바로 제네릭인데,

이유는 바로! Swift 표준 라이브러리의 대다수는 제네릭으로 선언되어 있기 때문임.

제네릭의 기본개념

제네릭은 코드의 중복을 줄이고, 타입에 안전한 코드를 작성할 수 있도록 도와줌.

예를 들어, 두 값을 서로 바꾸는 함수를 비교해 보자.

func swapTwoInts(_ a: inout Int, _ b: inout Int) {
    let temporaryA = a
    a = b
    b = temporaryA
}

평소에 우리가 제네릭을 쓰지 않는다면 이런 식으로 짤 것임.

하지만, 요 func는 Int밖에 들어가지 않지?

그럼, Double, String, 등등 다른 타입이 올 경우엔 어떡하지?

제네릭이 없다면 하나하나 파라미터 값을 변경하여 메서드를 생성해 주어야 함..

하지만! 우리에겐 제네릭이 있지. 후후

func swapTwoValues<T>(_ a: inout T, _ b: inout T) {
    let temporaryA = a
    a = b
    b = temporaryA
}

요렇게! 타입에 제한을 두지 않고 쓸 수 있다!

여기서 <T>는 너 T야!? 할 때 그 T가 아니라,

타입 파라미터(Type parameter)라고 부름.

타입 파라미터는 임의의 타입을 지정하고 이름을 지정하여 꺾쇠괄호 사이에 기록하고,

함수의 이름 바로 뒤에 작성함

아무튼, 이렇게 swapTwoValues라는 제네릭으로 선언해 주면,

var testNumA = 1
var tsetNumB = 2
swapTwoValues(&testnumA, &testnumB)	// int type

var testStringA = "Hi"
var testStringB = "Hello"
swapTwoValues(&testStringA, &testStringB) // string type

이렇게 실제 함수를 호출할 때

제네릭의 타입 파라미터 <T>의 값이 정해지는 거고,

만약 서로 다른 타입을 전달하게 되면,

swapTwoValues(&testNumA, &testStringA)

Cannot convert value of type 'String' to expected argument type 'Int'

요런 에러가 뜨게 되는 거지.

제네릭 타입

다음으로 위에서 배운 개념을 이용한 함수를 제네릭 함수 라고 하는데,

이 제네릭은 함수뿐만 아니라 구조체, 클래스, 열거형 타입에도 선언이 가능함.

이를 제네릭 타입이라고 한다.

첫 번째로 제네릭 구조체에 대해서 알아보자.

struct Stack<Element> {
	var items: [Element] = []
    
    mutating func push(_ item: Element) {
    	items.append(item)
    }
    
    mutating func pop() -> Element? {
    	return items.popLast()
    }
}

이렇게 제네릭 타입으로 스택을 선언할 수 있다.

++++++

여기에서, mutating func가 뭘까?

struct or enumeration 내에서 인스턴스 메서드가 해당 인스턴스의 프로퍼티 수정을

가능하게 만들어 줌.

그러면 왜 'mutating' 키워드를 쓰는 건데?

구조체와 열거형은 값 타입임. 기본적으로 값 타입의 인스턴스 메서드는

인스턴스 프로퍼티를 변경할 수 없음.

하지만, mutating을 사용하면 메서드 내에서 인스턴스의 프로퍼티 변경이 가능해짐!

다음으로, 제네릭 클래스에 대해서 알아보자.

public class Box<T> {
    private T item;
    
    public void set(T item) {
        this.item = item;
    }
    
    public T get() {
        return item;
    }
}

요건 자바코드긴 한데,

예시로 보여주기 너무 좋아서 가지고 와봄.

이런 식으로 'Box'클래스는 'T'라는 제네릭 타입 매개변수를 가지고,

이렇게 박스가 다양한 타입의 아이템을 가질 수 있도록 선언이 가능함.

마지막으로, 제네릭 열거형 타입임

enum Result<Value> {
    case success(Value)
    case failure(Error)
}

이렇게 Value라는 제네릭 타입 매개변수를 쥐어주면, 성공 케이스가

다양한 타입의 값을 가질 수 있어짐

제네릭 타입 제약

이번에 제네릭을 찾아보면서 좀 중요할 것 같은데? 싶은 부분이었음.

(어렵다 -> 중요하다) ㅋㅋ

이제, 제네릭을 사용할 때 타입제약을 추가하여 안전하고 의도에 맞는

타입을 사용할 수 있도록 제약을 두는 것임!

구조체에서의 타입제약

struct Stack<Element: Equatable> {
    var items: [Element] = []

    mutating func push(_ item: Element) {
        items.append(item)
    }

    mutating func pop() -> Element? {
        return items.popLast()
    }
    
    func contains(_ item: Element) -> Bool {
        return items.contains(item)
    }
}

보면 'Element'옆에 'Equatable'이라는 것이 추가되었음

이게 뭐냐 하면 예를 들어, 우리가 파라미터로 두 개의 값을 받아서

두 값이 같으면 ture, 아니면 false를 반환하는 함수를 제네릭으로 선언하려고 할 때 어떻게 할 수 있을까?

func isSameValues<T>(_ a: T, _ b: T) -> Bool {
    return a == b
}

이런 식으로 쓰겠지?

하지만 이렇게 쓰면 다음과 같은 오류가 발생함.

Binary operator '==' cannot be applied to two 'T' operands

왜냐하면, == 이란 연산자는 a와 b의 타입이 Equatable이란 프로토콜을 준수할 때만 사용이 가능하기 때문임.

그렇기 때문에? <Element: Equatable> 이런식으로 제약을 주는 것이다!

클래스에서의 타입제약

class Animal { }
class Cat { }
class Dog: Animal { }

func animalShelter<T: Animal>(_ a: T) { }

이렇게 T: Animal처럼 클래스 이름을 생성한 뒤에

let animal = Animal.init()
let dog = Dog.init()
let cat = Cat.init()

animalShelter(animal)
animalShelter(dog)
animalShelter(cat)

요런 식으로 호출하면, Animal클래스 인스턴스인 animal과 Dog는

animalShelter이란 제네릭 함수를 실행시킬 수 있지만,

cat은 불가능해짐.

마지막으로 열거형에 타입제약은

enum Result<Value: Decodable> {
    case success(Value)
    case failure(Error)
}

이런 식으로 Value가 Decodable 프로토콜을 준수하는 타입이어야 한다 라는

제약을 걸 수도 있음

이렇게 제약조건까지 알아봤슴미당!

다음에 봐요~

킥보드 앱 KPT 회고

pockpock — Tue, 30 Jul 2024 01:01:16 +0900

Keep (유지할 점)

몰랐던 점이나 새로 알게 된 점을 공유하고 함께 문제를 해결해 나가는 시간
이론 개념들을 정립하고 이해할 수 있는 시간이 되었고, 팀원들과 함께 고민하고 공유하면서 성장할 수 있었음.
문제를 하나하나 해결해 나갈 때마다 느껴지는 성취감
주말 새벽까지도 열정적으로 오류를 찾고 수정했던 우리의 의지!

Problem (문제점)

ReturnViewController 부분에서 초기 계획이 부족해서 개발이 지연되고 예상치 못한 버그가 발생했음.
화면별 태스크와 필수 요구사항 정리를 대충 넘어가고 일정 관리가 제대로 되지 않아 학습과 코드 작성의 부담이 증가했음.

Try (시도할 점)

앞으로는 더 철저한 설계와 계획으로 작업을 진행해야 함.
시간이 많이 걸리더라도 초기 설계를 제대로 하고, 필수 요구사항을 꼼꼼히 확인해야 함.
배운 이론과 문법을 더 다양하게 활용하고 시도해보아야 함.
코드 병합 과정에 대해 더 많이 배우고 고민할 수 있도록 노력해야 함.
패턴에 익숙해지고 구조를 세우는 작업에 중점을 두어야 함.

Swift Kickboard Project 5일차

pockpock — Fri, 26 Jul 2024 23:58:59 +0900

우히히

내 페이지 완성했음!

9 to N..?

진짜 일주일 내내 밤 샌듯.. 너무 피곤해요

후후 광고도 넣었지롱

UI 나름 깔끔하게 짠 듯?

팀원 분들도 진짜 다들 다같이 열심히 해주셔서

좋은 결과가 나온 것 같음

마지막으로 느낀점은,

프로젝트를 진행하면서 설계의 중요성을 다시금 깊이 깨달았습니다. ReturnViewController 부분에 초기 계획이 미흡하여 개발 시간이 지체되고, 기능 구현 과정에서 예상치 못한 버그가 발생하는 등 많은 시행착오가 있었습니다. 하지만, 문제를 하나하나 해결해 나갈 때마다 느끼는 성취감 덕분에 견딜 수 있었던 것 같습니다. 앞으로는 더 철저한 설계와 계획으로 guard let 해야 할 것 같습니다.

깃 허브 : https://github.com/qockqock/KickboardApp?tab=readme-ov-file

시연 영상: https://www.youtube.com/watch?v=TsSXJ0TOU6o

Swift Kickboard Project 4일차

pockpock — Thu, 25 Jul 2024 20:34:24 +0900

오늘은 버그 잡는 날~

버그와 예외처리를 전부 잡아 보자고~

팀원이 도움요청해서 호다닥 고쳐주러 갔음

[Bug]

이미 가입된 이메일이 있었으나, 회원가입 버튼 이벤트 부분에

예외처리가 없어서 가입되는 현상 발생

[Fix]

재사용성을 위해 얼럿 생성 관련 메서드를 따로 뺏음

(여긴 내가 짠 코드가 아니어서 일단 오류 잡아주는 느낌으로만..)

[Bug]

이후에! 데이터 정보 받아오는 과정에서 또 오류가 났다기에

호다닥 달려가서 코드 뜯어봄

Model에 있는 코어데이터와 비교해 보니

이상한 점이 있어 또 수정!

음음 제대로 가지고 오는군!

[Bug]

마이페이지에서 로그아웃 눌렀을 때 회원가입 버튼이 안 눌리는 오류 발생

[Fix]

인스턴스 재정의가 되지 않았음.

여기까지는! 팀원들 오류 해결 부분이었음

그러다 내 예외처리 부분에서 버그가 생김...

버그내용은 다음과 같음

[Bug]

결제금액이 0원이고, 타이머가 작동하지 않을 때 쿠폰 적용이 불가능해야 함.

하지만 적용됨

[Fix]

그래서 조건을 걸어줬음.

어떻게 하지.. 고민하다가

요기서 isEnabled 가 Bool타입으로 타입이 두 개로 나뉘니까 이거 이용하면 될 것 같은데?

싶어 가지고 바로 적용해 봄

하지만 실패...

근데... 아무리 봐도 로직상의 오류를 찾지 못하겠음

아... 뭐지?

브레이크 포인트 걸어도 true가 작동을 안 함 ㅠㅠㅠ

처음에는 라이프 사이클 문제인가? 싶었는데

아무리 봐도 아님.

어쩔 수 없이 이 문제는 튜터님한테 찾아가 보기로 함.

같은 인스턴스를 사용하지 않아서 그랬던 거임!

그렇게 델리게이트 패턴으로 가져와가지고 했더니 해결됐음

Swift Kickboard Project 3일차

pockpock — Wed, 24 Jul 2024 23:58:20 +0900

오늘은 기능구현에 몰두했음.

나는 로직을 짜기 전 시나리오를 미리 세우는 타입임.

예를 들어, 이번 ReturnViewController의 기능을 구현하기 위해 로직을 굴러보는거지.

요런 느낌으로!

근데 확실히 이번조는 조원이랑 소통이 잘 돼서 너무 재미있었던 것 같음

깃 허브 규칙도 다들 잘 지켜주셔서 컴플릭도 덜 나고 만약 나더라도 담당 하시는 분과

소통하면서 문제 해결해 나가는게 너무 재미있었음

코딩 재밌당!!

으음..

SA피드백

아침에 팀 노션을 확인해보니 매니저님이 SA피드백을 해주셨다.

그 중 앱이 백그라운드에 진입하더라도 스톱워치가 동작하도록 구현..!?

음.. 어떻게 하는거지?

방법은 생각보다 간단했음.

Project -> Signing & Capabilities -> + 버튼 클릭 후

Background 검색해서 Background fetch선택하면 됨.

처음에 타이머 코드를 짤 때 slepp(1)을 사용하여 구현하였는데, 백그라운드 상태일 때

정상적으로 작동하지 않는다는 것을 깨달았다.

[Why?]

검색해서 찾아 본 결과 slepp(1)을 사용하는 경우 정확항 타이머 작동을 보장하지 않으며

실제 시간과 불일치가 발생할 수 있다는 사실..

[Fix]

백그라운드에서 타이머를 정확하게 유지하려면, 앱이 백그라운드에서 실행 중일 때

시간을 기록하고, 포그라운드로 돌아왔을 때의 시간을 비교하여 정확한 경과 시간을 계산하는 것이 좋음!

이외에도 이용시간에 따른 결제금액 상승, 쿠폰사용 버튼 클릭 이벤트 등 내부기능은 1차로 완료함.

이제 맵뷰에서 정보 받아오고, 마이페이지랑 연동하면 될 듯?

Swift Kickboard Project 2일차

pockpock — Wed, 24 Jul 2024 00:10:23 +0900

첫 째날 작성한 요구사항과 와이어프레임이 뭔가 이상함.

???

긴급회의..

이후 팀원들과 UI피드백과 로직에 대해 이야기를 나눈 뒤 어느정도 해야할 것들이 정리되었음.

하.... 이미 UI 다 짜놨는데 수정해야겠고만 ㅠㅠ

암튼 바뀐 UI를 봤는데

피그마

전 후 차이 실화냐?

와...

아무튼 UI 개편하고 코딩할맛이 난다고 해야할까..? ㅋㅋ

갑자기 코딩이 엄청 하고싶어짐.

그렇게 뚝딱뚝딱 만들어 결제수단과 쿠폰 함 하프모달 을 완성시켰음

새로 안 사실인데 이번 킥보드 앱은 iOS 버전 15로 통일했단말임?

근데, 하프모달 높이를 커스텀 하려고 보니까 iOS 16버전부터 가능하다고... 해서.. ㅠㅠㅠㅠ

팀원과 회의끝에 중간사이즈로 타협봄

ㅋㅋ 배X 아님

아무튼 아님.

큼큼

근데, 이 페이지를 구현하다보니 Label을 많이써서 코드가 많이 더러워 지더라구요?

그래서 어떻게 코드를 짜야 이쁘게 짤 수 있을까 고민을 많이 해봤는데..

(실제로 3번 정도 갈아 엎은듯?)

너무 깔끔하지 않나요?

이거 짜고 너무 뿌듯했음 (아니 Label 하나 갖고..)

아무튼!

만족스러운 하루였다 :)

Swift Kickboard Project 1일차

pockpock — Mon, 22 Jul 2024 19:45:37 +0900

이번주차는 팀프로젝트 주차이므로 포스팅은 요걸로 대체하겠음.

벌써 네 번째 팀프로젝트이다. 예전 프로젝트에서 느꼈지만, 초반 설계의 중요성을 느껴 이전보다

조금 더 빡빡하게 짜볼 예정이다.

요구사항명세서

처음 과제를 내주셨을 때 킥보드앱의 필수 구현사항을 따로 정리해서 보기 쉽게 정리했음.

이후에 조원들과 의견을 모아, 페이지별로 추가 할 기능을 정리해서 자료화 한 뒤 깃허브 이슈에 등록하여

작업진행 할 준비를 마침.

+++ 나중에 4편에서 이야기 하겠지만 이래도 초반 설계가 많이 많이 부족했음 ㅠㅠㅠ

프로젝트 기간이 짧아서 어쩔 수 없는건가..?

일단!

요구사항을 정리한 뒤 와이어프레임을 짜기 시작해서

와이어프레임

이런 느낌..?으로 짜서 먼저 구현한 뒤 시간이 남으면 추가구현 하는 느낌으로

작업을 진행했다.

그렇게 이제 역할을 나눠 진행을 했는데,

내가 담당하는 부분은 ReturnViewController이다.

Q: ReturnViewController는 무슨 페이지인데?

-> 쉽게 말해, 결제창임. MapViewController에서 마커를 누른 뒤 대여하기 버튼을 클릭했을 때,

타이머가 작동하고(백그라운드 상태일 때도 시간이 지나감) 일정 시간이 지날 때마다 가격이 올라감.

필수 구현 사항은 금방 구현할 것 같아서 결제수단과 프로모션 부분을 추가했고, 버튼 클릭 시

하프모달을 띄워 탭을 만들 예정임.

이번 팀 프로젝트는 역할분담이 잘 나눠져서 좋은 결과가 나올 것 같다!