 Apple Lover Developer & Artist

영속적인 디자인에 현대의 공감을 채워넣는 공방입니다

반응형

computer science 18

Lecture 6 Review Part 2: Protocols Shapes

이전 강좌에서 배운 사항을 실제로 Demo를 통해 이해해보는 시간이다. 가장 좋은 방법은 SwiftUI에서 사용되는 ScrollView나 LazyVGrid의 인자로 View가 들어가는 원리에 대해 파악해보는 것이다. 구현 목표는 화면 크기에 맞추기 위해 모든 카드를 올바른 크기로 유지하는 View Combiner를 정의하는 것이다. 새로 구현할 Combiner가 이미 구현되었다고 가정하고 사용하고 있다. 주석처리한 코드의 역할을 수행하는 Combiner이며 아직 정의되지 않았기 때문에 오류가 뜨고 있음을 확인할 수 있다. 지금바로 새로운 AspectVGrid를 만들어보도록 하자! AspectVGrid라는 새로운 Swift 파일을 생성하였다. 우측에 정의한 것처럼 이 View Combiner를 사용할 때 ..

Lecture 6 Review Part 1: Protocols Shapes

Protocol 프로토콜은 구현 내용이 제거된 struct 혹은 class이다. 함수나 변수가 정의되었지만 내용이 없는 코드는 다음과 같이 생겼다. protocol Moveable { func move(by: Int) var hasMoved: Bool { get } var distanceFromStart: Int { get set } } 프로토콜을 정의해두면 다른 struct나 class가 해당 프로토콜을 포함하여 명세에 대한 구현을 할 수 있다. struct PortableThing: Moveable { // must implement move(by:), hasMoved and distanceFromStart here } 결국 어느 struct나 class가 어느 프로토콜을 포함하여 정의된다는 것은 다..

Lecture 5 Review Part3: Properties Layout @ViewBuilder

Property Observers "Watching" a var and reacting to changes 이전 데모 영상에서 computed property 개념을 다루었는데 많은 사람들이 property observer와 computed property의 개념을 혼동하는 경우가 많다고 한다. 이번 기회에 두 개념을 양옆에 두고 차이점을 이해해보는 시간을 가져보자! 두 개념은 완전히 다른 개념이기 때문이다. 이전에 우리는 Swift가 struct의 변동 여부를 알 수 있다는 점을 여러 측면에서 봐왔다. 그중 가장 중요한 두 지점이 있는데 ViewModel에서 struct로 선언된 model이 연결될 때 @Published 키워드를 선언함으로써 model이 변경될때마다 @Published는 자동으로 세계..

Lecture 5 Review Part2: Properties Layout @ViewBuilder

Code Refactoring 지난 강좌에 이어서 기존에 작성된 Code 들을 Review 해보는 시간을 가져보도록 하자! 기존에 작성된 Model 코드를 살펴보면 다음과 같은 게임 logic 구현부를 찾을 수 있다. struct MemoryGame where CardContent: Equatable { private(set) var cards: Array private var indexOfTheOneAndOnlyFaceUpCard: Int? mutating func choose(_ card: Card) { if let chosenIndex = cards.firstIndex(where: { $0.id == card.id }), !cards[chosenIndex].isFaceUp, !cards[chosen..

Lecture 5 Review Part1: Properties Layout @ViewBuilder

@State 이전에도 보았드시 SwiftUI에서 모든 View struct는 읽기전용이다. 따라서 View를 처리할 때 let이나 computed var를 사용하는 것만이 유의미하다. 다만 @ObservedObject와 같이 property wrapper가 사용되는 경우에는 var을 사용한다. 왜 View는 Read-Only 일까? View는 매번 생성되고 버려진다. View의 body는 주변에 붙어있다. View의 body가 화면에 있다면 당연히 어딘가에 존재한다. 하지만 그 body를 만든 View는 아마도 오래전에 버려졌을 것이다. 여튼 View 구조체는 mutable한 var을 가질만큼 오래 살아있지 않는다. 하지만 걱정할 필요없다. 우리의 View는 Stateless하기 때문에 자신의 상태는 필..

반응형