다음으로 작성한 테마 View 구조체. 처음엔 3가지 버튼을 따로 작성하였다가 코드가 지저분해져서 Theme 구조체를 따로 만들었다.
title에는 화면에 보일 테마 이름, symbol은 화면에 보일 테마 이미지를 SF Symbol에 해당하는 이름을 입력받았다.
Extra Credit
첫 번째 조건은 테마선택 시 카드의 개수를 랜덤으로 배치하는 것이다.
이때 Int 타입에 정의된 Random(in: ) 타입 메서드를 사용하라고 명시되어 있다.
random(in:)
Returns a random value within the specified range.
범위를 입력받는 인자를 통해서 명시된 범위 내의 랜덤한 Int를 반환하게 된다.
명시된 조건은 최소 4개의 카드를 보이는 것이기에 4.. <배열크기를 넘겨주었다.
두 번째 조건은 바로 화면 크기에 맞추어 카드의 크기를 결정하는 것.
중요한 점은 모든 카드가 배치되었을 때 화면 범위를 벗어나지 않게 끔 적절한 카드 크기를 찾아내는 것이다. (화면이 portrait 상태)
여기서 이번 Memorize 앱을 작성하는 데에 가장 긴 시간을 고민했다.
Lecture 2에서 작성된 코드는 LazyVgrid를 통해 고정된 크기의 카드를 나열하였다. 여기서 카드의 수량이 추가되면 카드목록이 화면에 한 번에 잘릴 수 있으니 스크롤 뷰를 통해 카드목록을 탐색할 수 있게 구현하였다.
이번에는 카드의 수량에 맞춰 카드의 크기를 조절해 스크롤 없이 카드목록을 볼 수 있게끔 카드의 크기를 계산하는 widthThatBestFits(cardCount: Int) -> CGFloat 함수를 작성하는 것이 두 번째 조건이었다.
기기가 portrait(세로 방향) 상태일 경우에만 맞추면 된다고 명시되어 있길래 여기서 큰 힌트를 얻었다.
카드의 비율은 2:3, 여태 출시된 모든 아이폰의 화면 비율은 카드의 비율보다 세로비율이 더 길게 되어있다. 즉 상단의 제목과 하단의 테마버튼 영역을 제외하고서라도 카드를 정방 배열 형태(2*2, 3*3, 4*4)로 그리드 뷰를 구성한다면 카드와 동일한 2:3의 비율의 그리드뷰를 얻을 수 있고, 해당 뷰를 화면에 넘치지 않게끔 배치가 가능할 것이라 생각하였다.
따라서 LazyVgird의 너비를 랜덤 하게 주어지는 (카드목록의 수의 제곱근)으로 나눈 값을 LazyVgird에 들어갈 GridItem의 최소 크기로 지정한다면 SwiftUI는 정방배열의 LazyVgird를 그려내게 된다.
swift의 변수 및 상수는 초기화 없이 선언만 이루어진 경우, 사용할 수 없다. 따라서 객체 생성 시, 초기값이 주어지지 않은 속성의 경우 반드시 생성자의 인자를 통해 초기값을 할당해주어야 한다.
초기값 vs 생성자
그렇다면 초기값이 있는 속성의 경우 생성자를 통해 값을 넘겨주면 어떻게 될까?
당연하게도 생성자로 넘겨준 값으로 할당이 된다.
onTapGesture()
func onTapGesture(
count: Int = 1,
perform action: @escaping () -> Void
) -> some View
View의 탭 제스처 감지 함수이다. action에 동작할 클로저를 작성하고, count의 경우 action이 수행될 탭 횟수를 적으면 된다. 기본값은 1이다.
@State
A property wrapper type that can read and write a value managed by SwiftUI.
한번 생성된 View는 수정이 불가하다. View가 나타내는 정보를 수정하고 싶을 때는 수정된 정보를 가지고 있는 View를 새로 생성하여 대체하는 것이다. 이때 사용하는 키워드가 @State이다. 변수를 가리키는 포인터로 동작하며, 해당 포인터가 가리키는 변수 값에 변동이 감지된다면, 해당 변수를 참조 중인 View는 새로 그려지게 된다. rxSwift에서 Observable의 역할을 수행하는 키워드이다.
버튼으로 동작하는 View를 생성. action과 label 두 개의 클로저를 입력받으며,
action에는 버튼이 탭 될 경우 수행될 동작을 정의한다.
label은 ViewBuilder로 동작하여 View를 나열하는 것으로 버튼의 외형을 정의하면 된다.
ForEach
A structure that computes views on demand from an underlying collection of identified data.
struct ForEach<Data, ID, Content> where Data : RandomAccessCollection, ID : Hashable
View 구성시 for문을 사용할 수 없다. 따라서 Collection 타입에 담겨있는 자료들을 표현하기 위해 ForEach를 사용한다.
ForEach()는 자료가 담겨있는 Data, 식별자 역할을 하는 ID, ViewBuilder로 동작하는 Content로 구성된다.
순서대로 가져오고 싶은 Collection 타입의 데이터와 해당 자료를 어떤 기준으로 식별할지 나타내는 ID를 지정, 이후 반환될 View를 구성해 주면 된다. Content의 경우 CombinerView와 마찬가지로 ViewBuilder 형태로 동작하기에 단순히 View를 나열하는 것만으로 View를 구성할 수 있게 된다.
LazyVgrid
A container view that arranges its child views in a grid that grows vertically, creating items only as needed.
UI구성의 내용이 담긴 ContentView는 결국 View 구조체이며, 이러한 구조체 안에는 여러 가지 변수, 메서드를 담아낼 수 있다.
눈여겨볼 것은 body 변수인데, 해당 변수는 View도 아닌, some View라고 정의되어 있다.
강의에서는 "something that behave like a View"라고 설명했다. 즉 "View처럼 행동하는 무언가" 정도로 해석이 가능하다.
그렇다면 왜 View가 아니라 View처럼 행동하는 무언가일까?
교수님은 해당 부분을 레고에 비유하였다.
우리가 레고로 집을 만든다고 하였을 때, 작은 단위의 레고를 모아 의자, 소파, 테이블과 같은 작은 단위의 레고를 만들고, 그것들이 모여 거실, 방, 지붕과 같은 큰 단위로 결합하게 된다. SwiftUI 또한 작은 단위의 View가 결합되어 하나의 View를 구성하게끔 동작한다는 것이다. 즉 수많은 종류의 View 중에 어떤 형태의 View가 반환될지 모르기에 some View라는 키워드로 치환된 것이다.
조금 더 해당 표현에 대해 자세한 설명을 하자면, 화면상에 단 하나의 View만 존재하게 될 경우, 위와 같은 코드로 작성하게 된다. 하지만 해당 코드는 swiftUI에 의해 몇 가지 키워드가 치환된 형태이다. 조금 더 명시적인 형태로 작성하게 되면 아래의 코드로 적을 수 있다.
import SwiftUI
struct ContentView: View {
var body: Text {
return Text("Hello!")
}
}
ContentView의 body는 Text라는 View구조체이며, 이는 곧 "Hello"라 적힌 Text View를 반환한다는 것. 하지만 예시보다 복잡한 여러 형태의 View가 조합되면 개발자는 이에 대한 명시를 하기 어려워지므로 some View라는 형태로 적게 된 것이며, 해당 부분에 대한 치환은 컴파일러가 알아서 처리하게 하는 것이다.
이처럼 body와 같이 여러 가지 View를 결합하는 View를 Combiner View라고 소개하였으며, 해당 부분의 some View는 대부분 Combiner View를 의미한다고 한다.
함수형 프로그래밍
ContentView의 body는 변수로 선언이 되어있지만, 메모리에 저장되지 않는다고 한다. body에 접근할 때마다 body 뒤에 이어진 { ... } 블록의 해당 함수 내용을 수행하고 반환되는 결과를 받아 오는 것이다. 이는 swift의 큰 특징 중 하나인 함수형 프로그래밍에 의한 표현이다.
결론
some View라는 표현은 개발자가 편하기 UI 작성하기 위한 표현이며, 이는 최종적으로 컴파일러가 body의 closure에 정의된 함수 내용을 수행하여 반환되는 특정한 View로 치환하게 된다는 이야기이다.
Zstack
View에는 여러 가지 종류의 View가 있으며 이들 중 다른 View를 결합하는 combiner View가 있다 했다. Zstack 또한 강력한 기능을 가진 Combiner View라고 소개되었는데, content { ... } 인자 내에 단순히 View를 나열하기만 하면 스크린 - 사용자 방향 순서로 view를 결합하는 기능을 수행한다. 강의에서는 이렇게 나열을 통해 View를 결합하는 것을 View Builder Machanism이라는 표현으로 소개하였다.
Zstack을 통해 생성한 View
Zstack에는 나열한 것을 View로 생성하는 것 이외에도 또 다른 강력한 기능이 있는데, 바로 ZStack에 적용한 속성들이 Zstack 하위의 View에 상속된다는 점이다.
View의 공통 속성인 padding()을 Zstack에 적용한 모습
예시의 padding 이외에도 foregroundColor 등 View가 가진 공통 속성들의 적용이 가능하며, 당연하게도 하위 View에 직접 속성을 적용하게 된다면 오버라이딩과 같은 효과를 줄 수 있다.
iOS 관련 유명한 강의인 스탠포드 대학의 cs193p Developing Applicaitons for iOS 강의다.
해당 강의는 누구나 스탠포드 유튜브 채널에서 시청이 가능하다.
기존의 2017버전 강의에서는 실시간 강의영상이었다면 이번에는 코로나 팬데믹으로 인한 온라인 강의 영상이므로 교수님이 작성하는 코드나 제공되는 시청자료들을 더 좋은 환경에서 볼 수 있다.
기존 2017버전에서는 UIKit 프레임워크를 이용한 MVC 패턴의 앱개발이 주 내용이었다면, 2021 버전에서는 이제 현업에서 적극적으로 사용되는 MVVM 패턴과 이에 맞게 애플에서 개발한 swiftUI 프레임워크를 이용한 앱개발이 주 내용이 될 것이다.
지난번 2017강의를 들으면서 내용들을 전부 옮겨 적으려 해서 학습에도, 기록에도 힘이 들었기에 이번에는 강의 내용을 모두 옮겨적는다기보단 내가 보았을 때 흥미로운 내용 위주로, 하나의 강의 내에 여러 흐름으로 나누어서 작성하는 것을 통해 빠르게 학습하고 빠르게 기록하는 것에 초점을 두고 글을 적으려고 한다.
이번 첫강의에서는 swiftUI로 작성된 프로젝트를 전반적으로 훑어보면서 swiftUI 프레임워크의 구성을 간략하게 알아보았다.
swiftUI project File Hierarchy
가장 먼저 swiftUI로 프로젝트를 생성하게 되면 다음과 같은 파일이 자동으로 생성된다.
(프로젝트명)App.swift 파일과 ContetnView.swift 파일이 이번 swiftUI 프레임워크의 주요 파일이다.
import SwiftUI
@main
struct MemoriesApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
App.swift 파일은 다음과 같이 작성이 되어있으며, 주의깊게 봐야할 부분이 @main 어노테이션이다.
해당 어노테이션은 UIKit으로 생성한 프로젝트에서 AppDelegate 파일에 있던 어노테이션으로 앱의 진입지점(entry point)를 나타낸다. 즉 swiftUI의 진입지점(entry point)은 App.swift 파일이며 해당 App 객체의 생성으로 앱의 실행으로 이어진다는 얘기이다.
다음으로 주목해야 할 부분은 App 객체의 body 부분에 할당된 ContentView() 객체이다.
ContentView() 객체를 생성하는 것을 볼 수 있고, 해당 객체는 ContentView.swift 파일에 선언되있는 것을 확인할 수 있다.
ContentView.swift 파일을 살펴보게면 xcode에서 3개의 영역를 제공한다.
코드를 작성하는 textEditor 영역
앱의 UI가 어떻게 보이게 될지 미리 보여주는 preView 영역
사용자에게 보여질 UI를 구성하는 각 개별의 View를 설정 할 수 있는 inspector 영역
흥미로운 점은 이 3개의 영역이 실시간으로 연동이 된다는 점이다. 강의에서는 sync 되어있다는 표현을 사용했는데 즉, 사용자가 마주하는 Text, Image와 같은 UI뷰의 설정을 3개의 영역 모두에서 접근이 가능하며 해당 수정사항이 실시간으로 일어난다는 것.
기존의 UIKit 프레임워크의 XML 형태와 달리 xcode가 코드로 짜여진 UI를 실시간으로 처리하는 것처럼 와닿았다.
해당 부분이 반가운 점은 UIKit을 사용할 때에는 기존의 UI를 IBAction, IBOutlet을 통해 연결했는데, 가끔씩 라인을 이동한다던지, 이름을 변경하게 되었을 때 싱크가 끊어지는 경우가 종종 생긴다는 점이었다.
애플도 해당 문제점을 정확히 파악하고 있었을 것이고 확실한 것은 아니지만 SwiftUI를 통해 해당 문제점을 해결하기 위래 노력을 많이 한 것으로 느껴졌다.
import SwiftUI
struct ContentView: View {
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
Text("Hello!")
.padding(.all)
}
.padding()
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
ContentView.swift의 내용을 살펴보면 View 구조체와 PreViewProvider 구조체가 보인다.
PreViewProvider의 경우 이름에서 알 수 있듯이 UI의 실시간 반영을 위한 preView를 위한 코드부분이다.
결국 개발자가 UI를 구성하는 코드를 작성하는 곳은 ContentView라는 이름의 View 구조체인 것이다.
코드를 작성하다 보면 에러를 마주치게 되는데 에러에 대한 처리방법에는 크게 3가지가 있다.
do {
try something.method()
} catch let error {
throw error
}
우선 do - catch 문법이다. try를 통해 수행된 함수가 error를 발생할 시, error라는 지역 변수에 담기게 되고 우리는 throw 를 통해 해당 에러가 무엇인지 확인하게 된다. 지역변수 error는 NSError 클래스 타입이며 여기에는 에러를 다룰 수 있는 여러가지 메소드가 정의되어 있다. 우리는 error변수에 접근하여 해당하는 조치를 취해주면 되는 것이다.
try! something.method()
something.method()의 강제실행 구문이다. 훨씬 간결하게 적을 수 있지만, 에러가 발생할 경우 앱의 강제종료로 이어진다. 현재 환경에서 에러가 발생하지 않는 다는 확신이 있을 때만 사용해야 한다. 안전하게 사용하고 싶다면 최대한 사용을 피해야하는 표현이다.
try? something.method()
if let data = try? getData(){
return getData()
}
가장 이상적인 방법으로는 try? 구문이 있다. 에러가 발생하면 nil을 반환하고 리턴값이 있는 메소드라면 optional 타입을 반환하게 된다. 예시와 같이 에러없이 수행된다면 nonOptional타입을 반환할 수 도 있다.
Any, AnyObject
Any 타입은 어느타입이든 될 수 있는 특징을 가진 타입이다. 자료형을 꼭 명시해줘야 하는 swift에게는 어울리지 않는 타입인데, Any타입은 objc와의 호환성을 위해 존재하는 타입이라고 볼 수 있다.
화면전환을 위한 함수 prepare함수를 보면 sender가 Any? 타입으로 되어있는 것을 볼 수 있다. 버튼을 눌렀을 경우 전환이 된다면 버튼이 sender가 될 수 있는 것이고, 테이블 뷰의 행을 클릭했을 때 변환이 되는 경우는 tableViewCell이 sender가 될수도 있는 것이다. 이때 어떤 자료형이 올 수 있는지 알 수 없으니 Any를 사용한다.
as?
Any의 단점은 swift의 엄격한 타입 관리로 인해 Any타입은 메세지나 변수를 보낼 수 없다는 것이다. 따라서 Any타입을 사용하려면 타입의 변환이 이루어져야 하는데, 이때 사용하는 키워드가 as?이다. 타입변환에 실패할 시 nil이 반환된다.
if let unknow:Any = ...
if let foo = unknown as? myType{
//myType으로의 변환이 성공시의 영역
//myType의 메소드나, 변수에 foo로서 접근이 가능하다.
//만일 myType으로의 변환에 실패할 경우 해당 영역에 접근할 수 없다.
}else{
//타입변환에 실패할 경우 진입하는 영역이다.
}
즉 어떠한 타입일지 모르는 변수 unknown을 myType으로 추측하여 foo에 담은 뒤, myType인 변수들이 알아들을 수 있는 메세지를 foo의 영역안에 보낼 수 있는 것이다. myType의 데이터가 아니어서 변환에 실패할 경우 nil을 반환하기에 부담이 적다. 예시처럼 실패할 경우의 행동을 취할 수 도 있다.
NSObject
swift는 objc를 대체하기 위해 만들어진 언어이다. 앞서 언급했던 Any의 경우도 objc의 호환성을 위해 만들어진 타입인데, 그렇다면 objc의 특성에 대해 어느정도 알아 둘 필요가 있다. 모든 objc의 클래스는 NSObject라는 클래스를 상속받는다. 즉 NSObject는 모든 objc 클래스의 루트 클래스라는 이야기이다. objc에서 클래스를 생성하게 되면 해당 클래스는 반드시 NSObject를 상속박아야 한다. 애초에 런타임이 그렇게 요구하도록 만들어져 있다.
NSNumber
objc에서 숫자를 다룰 때 사용하는 클래스이다. 정수형, 실수형 등 모든 숫자 형태는 NSNumber로 전달이 가능하고, 전달 받은 데이터를 swift에서 사용할 경우 알맞는 타입으로 변환해주면 된다.
let number = NSNumber(35.5)
let intified:Int = n.intValue
Date
날짜,시간을 표현하는 타입
1970년 이후 얼마나 시간이 흘렀는지를 게산한다. 백만분의 1초 단위로 측정가능.
이외에도 Calender, DateFormatter, DateComponents와 같은 날짜표시 클래스들이 존재한다.
날짜를 바로 UI에 표시하게 되면 지역마다 다른 날짜 체계에 혼동이 오게되어서 사용하는 클래스이다.
Data
ios API간 데이터를 전송할 때 사용하는 클래스이다.
각 자료의 형태에 맞는 Data구조를 제공한다.
Views
MVC에서의 뷰가 아닌, swift에서 UIView의 서브클래스들을 지칭한다. 즉 화면에 표현되는 좌표계를 동반한 사각형 화면을 이야기하는 것이다. view는 계층적 구조로 이루어져 있으며, UIView를 하위로 여러개의 서브뷰들이 스택으로 쌓여져 사용자에게 보여지는 화면이 완성되는 것이다. UI에 존재하는 버튼, 텍스트 등 모두 뷰에 해당한다.
타입은 UIView의 형태로 생성이 되며, 이렇게 계층구조를 이루고 있는 뷰는 각자에게 해당하는 상위(슈퍼)뷰나 하위(서브)뷰를 요청할 수 있다. 이는 당연히 있을수도 있고 없을수도 있으니 옵셔널 형태인 UIView?의 형태로 리턴이 된다.
이러한 뷰의 계층구조를 작성하는 방법은 크게 두가지가 있다. 첫번째는 우리가 흔히 사용했던 xcode의 인터페이스빌더를 통한 방법이다. 두번째는 코드를 통해 작성하는 방법이 있는데, 가장 핵심적인 두 메소드를 통해 서브뷰의 추가 및 삭제가 이루어진다.
메소드의 이름을 보면 알 수 있듯이 서브뷰 추가 메소드는 추가할 대상이 되는 상위 뷰에서 호출, 뷰의 삭제 메소드는 삭제할 대상이 되는 서브뷰에서 호출을 하면 된다.
view hierarchy(계층구조)의 가장 최상단 뷰는 바로 뷰컨트롤러의 view:UIView 변수이다. 자동으로 생성이 되며, 프로젝트의 초기 생성기 최상단의 검정색 뷰이다. 초기의 화면 구성을 위해 바로 이 view 변수에 접근하여 서브뷰를 추가하면 된다.
Initializing a UIView
뷰를 초기화 하는 방법에는 두가지 메소드가 있다.
init(frame:CGRect)
//UIView가 코드로 생성된 경우 사용
init(coder:NSCoder)
//UIView가 스토리보드(인터페이스빌더)로 생성된 경우
하지만 init()을 사용한 초기화는 비추천한다고 한다. 직접 상속을 받아 구현해야하는 부분이 많고 구현을 하다보면 코드가 겹치는 부분이 생기기 때문이라고 하는데, 그래서 사용하는 방법이 awakeFromNib()이라는 함수이다.
해당 함수는 스토리보드에서 생성된 모든 객체들이 초기화가 이루어졌을 때 호출되는 함수이다. 즉 코드로 생성된 뷰는 해당 방법으로는 초기화 할 수 없으니 참고하도록 하자. *Nib는 인터페이스빌더의 옛이름이다.
Coordinate System Datastructure
드로잉 하기 위한 중요한 4가지 자료형이 있다.
모두 CG로 시작을 하는데, 이는 CoreGraphic를 의미한다. ios에서 일반적인 2차원 드로잉을 위한 시스템이다.
CGFloat
부동소수점으로 좌표를 표현하는 기본 자료형이다. 화면의 좌표를 정수형태가 아닌 부동소수점으로 나타내며, Double, Float과는 다른 자료형이다. 초기화 함수가 있으므로 Double타입에서 CGFloat으로 타입 캐스팅이 가능하다. 드로잉을 하는 가장 기본적인 자료형으로 드로잉에 관련된 모든 곳에는 CGFloat타입을 사용한다.
CGPoint
CGFloat타입의 x,y변수가 담겨있는 구조체이다. 좌표가 담겨있는 CG 구조체라고 보면 된다.
var point = CGPoint(x:37.0, y:55.2)
point.y += 1
point.x -= 0.5
CGPoint와 CGFSize를 담고있는 구조체이다. 즉 좌표와 사이즈가 담긴구조체로 어느위치에 어느크기로 드로잉을 해야 하는지 정보를 담을 수 있다. Rect는 rectangle, 사각형을 의미한다.
struct CGRect{
var origin : CGPoint //좌표정보
var size : CGSize //크기정보
}
let rect = CGRect(origin: aCGPoint, size: aCGSize) //초기화
var minX: CGFloat //좌측테두리
var midY: CGFloat //수직 중간점
intersects(CGRect) -> Bool //다른 CGRect와의 영역간섭이 있는지 확인하는 함수
contains(CGPoint) -> Bool //해당 좌표를 CGRect가 포함하고있는지 확인 하는 함수
//이외에 여러가지 함수와 변수들이 있다.
origin에는 좌표정보를, size에는 크기정보를 담을 수 있다. 이외에 드로잉에 관련된 함수와 변수가 많다.
View Coordinate System
수학에서의 좌표는 좌측하단이 원점(0,0)이다. 하지만 스위프트의 View Coordinate System의 경우 화면의 좌측상단이 원점(0,0)이다.
y값이 증가하면 아래로, x값이 증가하면 오른쪽으로 이동이 된다.
화면표현의 단위는 픽셀(pixel)이 아닌 포인트(point)이다. 둘 사이에는 엄연한 차이점이 있는데, 우선 픽셀은 스크린을 구성하고 있는 작은 점이다. 일반적인 스크린 표현에는 하나의 점에 하나의 픽셀이 할당되는데에 비해 스위프트의 좌표계는 포인트당 1~3개의 픽셀이 배치되어 포인트의 경계에도 드로잉을 할 수 있는데, 이것이 부동소수점을 사용하는 이유이다. 이는 보다 부드러운 곡선을 표현하는데에 더욱 유리하며, 저해상도 디스플레이에서는 당연히 픽셀의 갯수가 적기 때문에 포인트당 하나의 픽셀을 할당해야 하며 이는 부드러운 곡선을 표현하기에 불리하다. apple에서 레티나디스플레이 라고 부르는 고해상도 디스플레이를 활용하기 위해 이러한 포인트 단위로 사용한다고 보면 되겠다.
bounds & frame
뷰에 있어서 중요한 두가지 변수가 있다. bounds와 frame이다. 최근 공채 면접에서 두가지 변수의 차이점에 대해서 물어보기도 했다.
var bounds: CGRect
var frame: CGRect
두 변수 모두 CGRect 타입인건 동일하지만, 쓰임새가 전혀 다르다.
UIView는 각자 서로 다른 좌표계를 가진다. 즉 자기 자신의 고유한 원점과 크기를 담은 변수가 bounds이며 이는 곧 뷰 안에서 드로잉 할 수 있는 영역의 범위를 뜻하기도 한다.
frame의 경우 해당 뷰가 상위뷰의 어느 지점에 있는지를 나타낸다. 즉 해당하는 뷰가 속해있는 상위 뷰의 원점에서 어느정도 떨어져 있는지 나타내는 좌표를 반환하는 것이다. 비슷한 변수로는 center:CGPoint 변수도 있다. 해당 뷰가 속한 상위뷰의 중심좌표를 반환한다.
결론은 frame과 center는 드로잉하고 있는 곳이 어딘지를 반환하는 변수이고, bounds는 지금 드로잉을 하는 곳을 반환한다고 보면 된다.
frame과 bounds의 크기는 같다고 생각 할 수 있겠지만, 뷰가 회전하는 경우를 생각해보면 아니다.
뷰 B의 bounds는 ((0,0), (200,250)) frame은 ((140,65),(320,320)) center는 (300,225)가 된다.
그렇다면 B의 중심점은 어떻게 알 수 있을까? 바로 CGRect에 담겨있는 midX와 midY변수를 통해 알 수 있다.
(bounds.midX, bounds.midY) = (100, 125)
Creating Views
일반적으로 뷰를 추가 하는 방법은 스토리보드에서 뷰를 추가하는 것이다. 하지만 이미 정해진채로 제공되는 뷰가 아닌 내가 직접 커스텀 한 뷰를 추가하고싶을때는 어떻게 해야 할까?
첫번째로 오브젝트 리스트에서 view라고 적혀있는 가장 일반적인 UIView를 꺼내온뒤, Identity indpector에서 내가 따로 작성한 클래스로 변경해주면 된다.
물론 스토리 보드가 아닌 코드로 작성하여 추가 하는 방법도 있다.
let newView = UIView(frame: myViewFrame)
//frame을 지정해서 추가할 경우
let newView = UIView()
//이 방법으로 생성시 해당 뷰의 frame은 ((0,0)(0,0))으로 설정되어 생성된다.
viewController에서 설정한다는 가정 하에, view는 아까 설명했듯이 뷰에 있어서 가장 최상단 UIView를 가리키는 변수이다. 즉 화면에 표시하기 위해서 view의 서브뷰로 추가하기 위해 assSubView()함수를 사용하여 (20,20)좌표에 (100,50)크기로 label을 추가해주는 것이다.
Custom Views
그렇다면 UIView를 상속받는 UILabel 이나 UIButton이 아닌 커스텀 뷰를 언제 사용하는 것일까? 일반적으로 본인이 원하는 드로잉이나 특별히 원하는 터치 이벤트를 다룰때 커스텀 클래스를 적용하게 된다. 이번에는 드로잉에 관해서만 다루는데, 바로 UIView에 정의되어있는 draw()함수를 오버라이드하는 것이다.
override func draw(_ rect: CGRect)
매개변수인 rect는 드로잉 영역으로서 사용된다. 화면 사이즈를 입력해도 되지만, 자원 사용량이 높은 경우(3d 그래픽 처리 등..) 최적화를 위한 공간 할당이 필요할 수 있다.
여기서 주의할 점은 draw(rect: CGRect)함수를 직접 호출해서는 안된다는 것이다. draw(rect: CGRect)를 호출하는 것은 오로지 ios뿐이다. 그렇다면 뷰를 수정하기 위해 새로 드로잉 하려면 어떻게 해야하나? 라는 질문이 생길텐데, 바로 setNeedsDisplay() 또는 setNeedsDisplay(_ rect: CGRect) 함수의 호출을 통해 ios에게 드로잉을 다시 하고 싶다고 알리는 방법 뿐이다. 여기서도 매개변수로 rect를 받는것 또한 다시 그려야할 영역을 정해줌으로써 자원사용량을 낮추기 위한 용도이다. 자원사용량이 많지 않아 전체 드로잉을 해도 상관없다면 rect변수 없이 호출해도 상관없다.
implements of draw(rect: CGRect)
그렇다면 draw(rect: CGRect)함수는 어떻게 구현할 수 있을까? 크게 두가지 방법으로 구현이 가능하다.
첫번째로UIGraphicsGetCurrentContext()를 사용하는 방법이다.
코어그래픽스는 컨텍스트(문맥)을 기반으로 드로잉을 하게 된다. 이때 컨텍스트를 받아오는 함수가 UIGraphicsGetCurrentContext()이다. draw(rect:CGRect)에서 호출이 가능하며, 호출을 하게 되면 컨텍스트에 경로를 지정해주어야 한다. 경로에는 곡선(arcs)을 그릴지 혹은 직선(lines)을 그릴지의 여부부터 움직이는 move(to)와 같은 것들이 포함되어있다.
경로를 설정하고 나면 드로잉의 성질을 설정하게 되는데, 드로잉의 성질에는 colors, fonts, textures, linewidths 와 같은 외형에 해당 하는 부분을 설정할 수 있다.
마지막으로 경로에 대한 테두리 그리기와 채워넣기 둘 중 하나를 선택하게 된다.
다음으로 UIBezierPath 객체를 사용하는 방법이다.
UIBezierPath는 컨텍스트를 자동으로 가져온다는 것 외에는 UIGraphicsGetCurrentContext()를 사용하는 것과 동일하다.
여기까지는 UIBezierPath 객체를 생성하고 경로를 지정한 것일 뿐, 화면에는 드로잉이 일어나지 않는다.
설정한 경로에 따른 드로잉을 표시하려면 드로잉의 성질을 설정한 뒤 테두리 그리기와 채워넣기 중 한가지를 선택해주어야지만 화면에 표시가 된다.
UIColor.green.setFill() //색상 채우기 설정
UIColor.red.setStroke() //선 스트로크 색상 설정
path.linewidth = 3.0 //선 두께 설정
path.fill() //채우기 시작 (앞에서 설정한 채우기 색상인 초록색으로 채워진다.)
path.stroke() //선긋기 시작 (앞에서 설정한 스트로크 색상인 빨간색으로 채워진다.)
이와 같은 코드를 draw(rect:CGRect) 또는 draw()안에 구현을 하게 되면 ios에서 자동으로 호출하여 드로잉하게 된다. 이외에도 여러함수를 통해 다양한 드로잉이 가능하다.
UIColor
색상을 사용하는 방법은 UIColor 구조체를 사용하는 것이다.
let green = UIColor.green
이 외에도 RGB값을 취하는 이니셜라이저나 , 색상,채도,밝기의 정보를 가지는 HSB 혹은 UIImage에서 이미지 패턴을 색상으로 취급하여 사용도 가능하다.
이러한 컬러들을 UIView에 있는 변수 backgroundColor: UIColor에 대입하면 뷰의 배경화면 색상이 변경이 된다.
색상에는 투명도인 alpha값을 조절하여 투명도를 조절 할 수 있다.
let semitransparentYellow = UIColor.yellow.withAlphaComponent(0.5)
투명(0.0) 부터 불투명(1.0)사이의 값을 적으면 된다.
투명도를 조절한 드로잉을 이용할 것이라면 꼭 알아할 점이 있는데, 바로 UIView에 있는 opaque: Bool변수이다. gpu 자원량을 아끼기 위해 기본적으로 true로 지정이 되어있으며 true의 경우 투명도 값을 사용하지 않는 것이다.(기존에 가려져서 표현 할 필요가 없는 부분이 투명해짐에 따라 표현을 해주어야 하기에..) 따라서 투명도를 이용한 드로잉을 할 때에는 opaque 변수의 값을 false로 설정하도록 하자.
인터페이스 빌더에서도 해당 옵션에 접근이 가능하다.
*opaque: 불투명한 안료. 필름에서, 화상의 일부나 필요한 부분에 칠하여 빛의 투과를 막음.
원한다면 뷰 자체를 투명하게 만들수도 있다. UIView에 alpha: CGFloat 변수에 값을 대입 하면 된다. 해당 뷰의 모든 드로잉이 해당 수치로 투명해지는 것이며, 마찬가지로 gpu 사용량이 올라가게 되니 참고하도록 하자.
Layers
UIView의 드로잉 매커니즘은 CALayer에서 이루어진다. *CA: CoreAnimation
뷰가 투명해지고, 움직이는 등 여러가지 애니메이션 효과는 CALayer에서 이루어진다고 보면 된다.
CALayer에는 여러가지 유용한 함수 및 변수들이 있는데, UIView의 Layer: CALayer변수에 접근하여 사용할 수 있다.
var cornerRadius: CGFloat //모서리가 둥근 사각형
var borderWidth: CGFloat //드로잉대상의 윤곽선
var borderColor: CGColor //드로잉목표의 윤곽선 색상. UIColor가 아닌 CGColor다.
borderColor변수가 UIColor가 아닌 CGColor로 된 이유는 코어 애니메이션 레이어의 매커니즘이 UIKit 레이어의 코어 그래픽스 레이어 위에서 이루어지기 때문이다.
*CGColor: 코어그래픽스에서 사용되는 색상타입
View Transparency
뷰의 투명도에 대한 이야기다. 서브뷰를 가지고 있는 모든 뷰들은 서브뷰를 배열형태로 가지고 있는데, 사용자 입장에서 가장 멀리 있는 뷰가 배열의 첫번째 서브뷰가 된다. 즉 서브뷰가 스택형태로 쌓여 배열의 가장 마지막 서브뷰가 사용자에게 가장 가까운 뷰라고 보면 된다.
물론 서브뷰 배열의 순서를 변경도 가능하다. 이런식으로 각 서브뷰의 투명도와 배치에 따라 사용자에게 보여지는 투명도를 조절할 수 있다.
이러한 뷰의 계층구조와 관계없이 뷰를 숨기는 것도 가능하다. 각 뷰에 isHidden: Bool변수를 통해서 true값이면 화면에서 사라지고, false값을 통해 화면에 보여지게 할 수 있다. 즉 계층구조 에는 남아있지만 화면에만 보여줄지 말지의 여부를 정하는 것이다. 주로 사용자와의 상호작용이 필요한 UI에 많이 사용한다. (Ex. 조건을 충족하면 숨겨 놓았던 뷰를 애니메이션과 함께 등장)
Drawing Text
텍스트 또한 드로잉이 가능하다. 우리가 흔히 사용하는 UILabel이 텍스트를 쉽게 드로잉 할 수 있는 뷰이다.
let text = NSAttributedString(string: "hello") //텍스트생성
text.draw(at: ACGPoint) //드로잉 실행
text.draw(in: CGRect) //CGRect 기준 드로잉도 가능하다.
let textsize: CGSize = text.size //텍스트크기 설정
Fonts
폰트는 앱UI의 전반적인 이미지를 결정짓는 중요한 요소이다. 앱이 ios의 look&feel을 전달하는데에 폰트가 큰 기여를 한다.
ios에서는 10가지 카테고리의 선호폰트(prefered font)를 제공한다. 제목폰트, 본문폰트, 캡션폰드, 각주폰트 등.. 상황과 목적에 맞는 선호폰트를 사용하도록 하자. 인터페이스 빌더에서 레이블, 버튼 등을 선택후 inspector 영역에서 선택이 가능하다. "prefered font"를 찾아 상황에 맞는 선호폰트를 적용하면 된다.
당연히 코드로 정의하는 것도 가능하다. UIFont에 정의된 preferedFont(forTextStyle: )을 사용하면 접근이 가능하다.
일부 사용자들은 본인이 사용하는 아이폰의 폰트크기를 기존 사이즈보다 크거나 때로는 작게 설정하여 사용한다. 이러한 사용자들을 고려하여 텍스트의 크기가 커지거나 작아졌을때에도 제대로 동작하는지 확인할 필요가 있는데, 해당 문제는 오토레이아웃을 사용하여 해결이 가능하다.
let font - UIFont(name:"Helvetica", size:36.0) //폰트명으로 폰트를 지정. 사이즈도 설정이 가능하다.
예시와 같이 폰트명을 직접 입력하여 폰트와 사이즈를 설정할 수 있다. 하지만 이렇게 UIFont생성자로 크기를 고정해 놓았다면, 휴대폰의 설정에서 폰트사이즈를 늘려도 반영되지 않게 된다. 특정 폰트를 지정하고, 휴대폰의 설정에 따라 크기를 반영하고싶다면 UIFontMetrics를 사용하여 해결이 가능하다.
let font - UIFont(name:"Helvetica", size:36.0) //폰트명으로 폰트를 지정. 사이즈도 설정이 가능하다.
let metrics = UIFontMetrics(forTextStyle: .body) //.body외에 아무거나 입력해도된다. 객체생성이 목적이기 때문.
//UIFontMetircs.default도 가능.
let fontToUse = metrics.scaledFont(for: font) //사용자의 폰트크기를 반영하여 새로운 폰트로 제공된다.
시스템 폰트는 버튼에만 사용하도록 하고 그 외 유저에게 내용을 전달하는 텍스트에는 선호폰트를 사용해도록 하자.
Drawing Images
마지막으로 이미지를 드로잉 하는 방법이다. UILabel과 마찬가지로 이미지를 드로잉하려면 UIImageView를 이용할 수 있다. 하지만 해당 방법은 대상 뷰에 UIView를 서브뷰로 추가하는 개념이고, 이미지 객체를 드로잉하고 싶다면 UIImage 객체를 이용할 수 있다.
UIImage객체는 jpg, gif등 여러가지 이미지 포맷을 지원한다. 그렇다면 어떻게 이미지를 가져올까? 총 3가지 방법이 있다.
1. 이름으로 가져오기
let image: UIImage? = UIImage(named: "foo")
Assects.xcassect 속의 파일을 이름으로 탐색하여 이미지를 가져온다. 당연히 사용할 이미지를 미리 드래그하여 저장해두어야 한다. 해당이름의 파일이 없을수도 있으니 UIImage? 옵셔널 타입을 사용하게 된다. (이미지가 없으면 nil을 반환하게 된다.)
2. 파일시스템을 이용하여 가져오기
let image: UIImage? = UIImage(contentsOfFile: pathString)
이미지의 파일 주소를 입력하여 가져올 수 있다. 마찬가지로 파일이 없을 수도 있으니 UIImage? 옵셔널로 접근해야 안전하다.
3. 인터넷을 통해 가져오기
let image: UIImage? = UIImage(data:aData)
인터넷을 통해 이미지를 받아올 수 도 있다. aData 속에 이미지 정보가 담겨있고, UIImage는 이를 들여다 보고서 이미지파일일 경우에 해당 이미지를 가져오게 된다.
위 세가지 방법을 통해 이미지를 객체로 담아 드로잉을 시작하면 된다.
image.draw(at point: ACGPoint) //좌표를 통해 드로잉
image.draw(in rect: ACGRect) //rect를 통해 드로잉 이미지가 rect의 크기에 맞게 스케일된다.
image.drawAsPattern(in rect: ACGRect) //rect의 크기에 맞게 이미지를 패턴으로 드로잉한다.
redraw on bounds change?
뷰의 bounds가 바뀌게 될 경우에는 다시 드로잉을 해야한다. 화면이 회전되는 경우가 이에 해당하는 예시인데, ios는 해당 경우에 자동으로 드로잉을 다시 해주지 않는다. 그저 화면비율에 맞게 뷰들을 늘려버리게 되는데 우리는 이러한 문제를 해결하기 위해 드로잉을 다시 해주어 배치를 알맞게 바꾸어 주어야 한다. 앞서 이야기 해듯이 우리는 draw()함수를 직접 호출할 수 없다.
이럴때 사용하는 것이 UIView에 있는 contentMode: UIViewContentMode 변수이다.
비트를 늘리거나 줄여서 새로운 bounds에 맞춘다. scaleToFill이 기본값으로 되어있다.
3. 다시 드로잉
.redraw
뷰의 bounds가 변경될 경우 darw(in rect: )를 재호출하여 드로잉을 다시하게 된다. 가장 이상적인 방법이다.
그렇다면 뷰의 bounds 변경시 서브뷰에는 어떤 조치를 해주어야 할까? 레이아웃 구성시 Auto Layout Constraints 설정을 해두었다면 자동으로 이루어 지지만, layoutSubViews()함수를 오버라이딩하여 수동으로 레이아웃을 정해줄수도있다.
override func layoutSubviews(){
super.layoutSubViews()
//새로 변경된 bounds에 알맞는 서브뷰의 frame을 설정해야 한다.
}
demo
enum을 활용한 PlayingCard데모를 작성했다.
PlayingCard.swift
import Foundation
struct PlayingCard:CustomStringConvertible{
//CustomStringConvertible 프로토콜의 description 변수 구현
//해당 구조체 출력시 반환 값을 수정할 수 있다.
var description: String{
return "\(rank) \(suit)" //rank와 suit값을 출력한다.
}
var suit:Suit
var rank:Rank
enum Suit:String,CustomStringConvertible{
//Suit형 변수 출력시 반환될 문자열 구현
var description: String{
return rawValue //enum의 rawValue를 반환한다.
}
//각 case의 rawValue를 String형으로 지정했다. 기본값은 Int이다.
case spades = "♠️"
case hearts = "❤️"
case clubs = "♣️"
case diamonds = "♦️"
//모든 suit를 반환하는 all 변수
static var all = [Suit.spades, .hearts, .clubs, .diamonds]
}
enum Rank:CustomStringConvertible{
//Rank형 변수 출력시 반환될 문자열 구현
var description: String{
return String(order)
}
case ace
case face(String)
case numeric(Int)
//case에 해당되는 order변수의 값 지정
var order:Int {
switch self{
case .ace: return 1
case .numeric(let pips): return pips
case .face(let kind) where kind == "J":return 11
case .face(let kind) where kind == "Q":return 12
case .face(let kind) where kind == "K":return 13
default : return 0
}
}
//Suit와 마찬가지로 모든 Rank값을 반환하는 all변수
static var all: [Rank]{
var allRanks = [Rank.ace]
for pips in 2...10{
allRanks.append(Rank.numeric(pips))
}
allRanks += [Rank.face("J"),face("Q"),face("K")]
return allRanks
}
}
}
이번데모에서 새로 배운건 CustomStringConvertible 프로토콜이다. 해당 프로토콜을 사용하는 구조체/클래스는 description변수를 구현하여 해당 구조체/클래스 출력시의 문자열을 수정할 수 있다.
다음으로는 enum의 rawValue이다. 기본적으로 enum은 각 case에 해당하는 값에 rawValue가 Int형으로 0부터 부여되는데, 선언부에 자료형을 따로 선언하게 되면 다른 자료형의 rawValue를 지정할 수 있다. Suit형 선언부를 보면 String으로 자료형이 지정되어있는 것을 확인할 수 있다.
PlayingCardDeck.swift
import Foundation
struct PlayingCardDeck{
private(set) var cards = [PlayingCard]() //빈 PlayingCard 배열 생성
init(){
for suit in PlayingCard.Suit.all{
for rank in PlayingCard.Rank.all{
cards.append(PlayingCard(suit: suit, rank: rank)) //모든 종류의 카드 추가
}
}
}
//카드반환 함수
mutating func draw() -> PlayingCard?{
if cards.count > 0 {
return cards.remove(at: cards.count.arc4random) //카드더미에서 무작위로 카드 반환
}else{
return nil //카드더미에 카드가 남아있지 않다면 nil 반환
}
}
}
//arc4random함수 Int에 extension
extension Int{
var arc4random:Int{
if self > 0{
return Int(arc4random_uniform(UInt32(self)))
}else if self < 0{
return -Int(arc4random_uniform(UInt32(abs(self))))
}else{
return 0
}
}
}
카드 더미에서 무작위 카드를 뽑아내기 위해 지난번 concentration 데모에서 사용했던 arc4random을 다시 사용했다.
ViewController.swift
import UIKit
class ViewController: UIViewController {
var deck = PlayingCardDeck()
override func viewDidLoad() {
super.viewDidLoad()
for _ in 1...10{
if let card = deck.draw(){
print("\(card)")
}
}
}
}
코드는 유지보수 및 수정이 용이하도록 작성해야 하는데, MVC 아키텍쳐는 그러한 여러가지 방법들 중 하나이다.
What is MVC?
Model, View, Controller의 약자이다. 즉 하나의 프로젝트를 크게 모델, 뷰, 컨트롤러로 나누어서 작업하는 것을 의미한다.
Model - what your app is
View - contoller's minons
Controller - how model is presented
모델에는 해당 앱이 무엇인지를, 컨트롤러는 해당 모델이 어떻게 보여지는지를 기술하는 것이다. 그렇다면 뷰는? 컨트롤러가 지시하는대로 유저에게 모습을 보여주는 부분이라고 생각하면 된다.
전반적인 통신은 모델과 컨트롤러, 그리고 컨트롤러와 뷰 이렇게 통신을 하게된다. 즉 모델과 뷰는 직접적으로 통신을 할 수 없다는 얘기.
모델은 자신에게 변경사항이 일어나면 컨트롤러에게 신호를 보낸다. 그렇게 되면 컨트롤러는 모델을 재탐색하여 변경사항을 알아내고 이를 뷰에 반영하게 된다. 해당 통신을 ios 에서는 KVO(key-value observing)이라고 한다.
뷰는 사용자의 이벤트를 감지하고 이를 action을 통해 컨트롤러에게 알린다. 반대로 컨트롤러는 outlet을 통해 자신의 지시를 전달하게 된다. MVC모델은 컨트롤러(controller)가 무엇을(model) 어떻게 표현(view)할것인지 구분하여 코드를 작성하는 방법이라고 생각하면 된다.
그렇다면 화면이 여러개인 앱들이 있을텐데 그러한 앱들은 MVC를 어떻게 적용하느냐? 라는 질문이 생기게 된다. 이 경우, 여러개의 MVC가 만들어 지는데 각 MVC는 나머지 MVC들을 하나의 뷰로 여기게 된다.
Demo
해당 데모는 지난번 카드뒤집기 데모에 MVC를 적용하여 카드 짝맞추기 게임으로 만든 것이다.
Model
import Foundation
struct Card{
//카드가 앞면인지 나타내는 속성
var isFaceUp = false
//카드의 짝이 맞는지 나타내는 속성
var isMatchedUp = false
//카드의 짝을 확인하기 위한 속성
var identifier: Int
//정적 선언. 즉 card타입 자체에 부여되는 속성이다.
static var identifierFactory = 0
//정적 선언. card타입 자체에 부여되는 함수. id를 하나씩 증가시켜 반환한다.
static func getUniqueIdentifier() -> Int{
identifierFactory += 1
return identifierFactory
}
//카드의 초기화가 일어날 때 마다 고유의 id를 생성한다.
init(){
self.identifier = Card.getUniqueIdentifier()
}
}
import Foundation
class Concentration{
//card타입의 배열 생성
var cards = [Card]()
//유일하게 앞면 상태의 카드를 나타내는 속성 이후에 두번째로 오픈되는 카드와 id를 비교하기위해 사용된다.
var indexOfOneAndOnlyFaceupCard:Int?
//카드를 선택할 때 수행할 함수이다. 유저가 선택한 카드가 몇번째 배열인지 배개변수로 받는다.
func chooseCard(at index: Int){
print("card's id:",cards[index].identifier)
print("card's index:",index)
if !cards[index].isMatchedUp{
//유저가 선택한 카드가 만약 쌍을 이루지 못한 상태라면,
if let matchIndex = indexOfOneAndOnlyFaceupCard, matchIndex != index{
//만약 유저가 선택한 카드 제외, 앞면인 상태의 카드가 한장이 존재한다면, 해당카드와 id를 비교
if cards[matchIndex].identifier == cards[index].identifier{
//서로의 id가 같다면, 두 카드는 쌍을 이룬 상태로 전환
cards[matchIndex].isMatchedUp = true
cards[index].isMatchedUp = true
}
//그렇지 않다면 유저가 선택한 카드는 앞면을 향하게 한다.
cards[index].isFaceUp = true
//더이상 유일하게 앞면을 보고있는 카드는 없다.
indexOfOneAndOnlyFaceupCard = nil
} else{
//indexOfOneAndOnlyFaceupCard값이 nil이라면, 즉 유저가 선택한 카드 이외 앞면인 카드가 한장보다 많으면,
for flipDownIndex in cards.indices{
//모든 카드를 뒷면으로 바꾼다.
cards[flipDownIndex].isFaceUp = false
}
//유저가 선택한 카드는 앞면으로 바꾼다.
cards[index].isFaceUp = true
//유저가 선택한 카드는 앞면을 바라보는 유일한 한장이다.
indexOfOneAndOnlyFaceupCard = index
}
}
}
//생성할 카드쌍의 수를 입력받는다. 즉 입력받는 수의 두배만큼 카드를 만든다.
init(numberOfPairsOfCards:Int){
for _ in 0..<numberOfPairsOfCards{
//동일카드 한쌍을 배열에 추가한다.
let card = Card()
cards += [card,card]
}
//TODO: 카드섞기
for index in 0..<numberOfPairsOfCards{
let randomIndex = Int(arc4random_uniform(UInt32(numberOfPairsOfCards)))
let swpidentifier = cards[index].identifier
cards[index].identifier = cards[randomIndex].identifier
cards[randomIndex].identifier = swpidentifier
}
}
}
View
Controller
import UIKit
class ViewController: UIViewController {
//게임 생성. 카드 쌍의 수는 카드버튼 갯수의 절반이다.
lazy var game = Concentration(numberOfPairsOfCards: cardButtons.count+1/2)
//카드를 뒤집은 수를 나타내는 레이블.
@IBOutlet weak var flipCountLabel: UILabel!
//flipCountLabel에 표시할 변수. 당연하게도 0부터 시작한다.
var flipCount = 0 {
//변수의 값 변동이 일어날 때마다 수행되는 메소드. flipCountLabel에 변경된 값을 전달하고 표시한다.
didSet{
flipCountLabel.text = "flipCount: \(flipCount)"
}
}
//UIButton을 카드모양으로 배치하였다. 해당 카드버튼들을 배열로 담았다.
@IBOutlet var cardButtons : [UIButton]!
//사용자가 카드를 터치할 때의 이벤트 함수. 어떤 카드가 터치된건지 UIButton을 매개변수로 넘긴다.
@IBAction func touchCard(_ sender: UIButton) {
if let cardNumber = cardButtons.firstIndex(of: sender){
//sender 즉 사용자가 터치한 카드가 cards배열에서 몇번째 카드인지 넘겨준다.
game.chooseCard(at: cardNumber)
//뷰에 모델의 변경사항을 반영한다.
updateViewFromModel()
} else{
//만약 카드가 cards배열에 없다면 오류문 출력
print("card is not in cardsArray")
}
}
//모델의 변경사항을 뷰에 알려준다.
func updateViewFromModel() {
for index in cardButtons.indices{
//카드버튼과 카드는 배열 속 번호가 동일하다.
let button = cardButtons[index]
let card = game.cards[index]
if card.isFaceUp{
//앞면인 카드가 있다면, 카드에 해당하는 카드버튼에 이모지를 삽입
button.setTitle(emoji(for: card), for: UIControl.State.normal)
button.backgroundColor = #colorLiteral(red: 1, green: 1, blue: 1, alpha: 1)
if !card.isMatchedUp{
//아직 짝이 없는 상태의 카드라면 flipCount증가.
flipCount += 1
}
} else{
//카드가 뒷면인 상태라면 해당 카드버튼은 이모지를 지우고 뒷면으로 바꾼다.
button.setTitle("", for: UIControl.State.normal)
//카드가 만약 짝이 맞는 상태라면 투명하게 그렇지 않다면 주황색으로 바꾼다.
button.backgroundColor = card.isMatchedUp ? #colorLiteral(red: 1, green: 1, blue: 1, alpha: 0) : #colorLiteral(red: 1, green: 0.5763723254, blue: 0, alpha: 1)
}
}
}
//이모티콘 후보들이다. 배열로 담아놓았다.
var emojiChoices = ["🦇", "😱", "🙀", "👿", "🎃", "👻", "🍭", "🍬", "🍎"]
//emojiChoices에서 이모지를 뽑아 [카드의 id: 이모지] 쌍으로 딕셔너리를 생성한다.
var emoji = [Int:String]()
//카드에 이모지를 그려넣는 함수. 카드를 매개변수로 받는다. 이모지를 반환한다.
func emoji(for card: Card) -> String{
if emoji[card.identifier] == nil, emojiChoices.count > 0{
//만약 매개변수 카드의 id가 emoji딕셔너리의 키로 존재하지 않는다면, 이모지 후보에서 랜덤하게 뽑아온뒤 [카드id:이모지] 딕셔너리에 추가한다.
let randomIndex = Int(arc4random_uniform(UInt32(emojiChoices.count)))
emoji[card.identifier] = emojiChoices.remove(at: randomIndex)
}
//카드 id를 키값으로 이모지 반환
return emoji[card.identifier] ?? "?"
}
}
lazy var
Cannot use instance member 'cardButtons' within property initializer;
property initializers run before 'self' is available
컨트롤러를 작성하면서 새롭게 배운것은 lazy이다. game을 생성할 때 카드쌍의 수를 입력해야 하는데, 카드의 갯수를 늘리거나 줄이는 경우에, 이에 대응하여 game이 유연하게 동작하는 게 하기 위해 cardButtons 배열의 갯수를 읽어오도록 했다. 우선 스위프트는 효율적인 메모리관리를 위해 변수의 초기화가 이루어져야만 사용을 할 수 있다. 하지만 game변수를 초기화하기 위해 속성을 초기화하려다보니 속성을 초기화하려면 변수가 초기화 되어있어야 한다고 오류가 뜨고 말았다. 이러한 꼬인 부분을 해결하기 위해 사용한 것이 lazy였다. lazy로 선언된 변수는 일단 초기화가 완료된 것으로 취급이 되고, 해당 변수가 필요하게 되면 초기화가 시작된다. 이렇게 해서 상호간에 일으키는 오류를 해결했던 점이 흥미로웠다.
optional ?? unwrap
emoji(for: card) 함수를 보면 마지막에 return emoji[card.identifier] ?? "?" 부분이 있다. 이러한 표현방법을 다른곳에서도 자주 봤지만 뜻을 잘 몰랐고 이번 강의를 통해서 이해하게 되었다. 해당 코드는 본래 아래와 같은 표현이다.
edwith를 통해 스탠포드대학의 ios강의를 번역자막을 보면서 시청할수있다. 해당 강의를 시청하며 정리한 내용을 적어보려고 한다.
what's in ios?
ios에 대한 간략한 설명을 해보자면 초기의 os X for iphone에서 3버전에는 iphone os, 2010년 4버전이 나오면서 ios라는 이름으로 정착되었다. ios는 크게 cocoa touch, media, core service,
core OS로 구분되어 사용자와 하드웨어간의 의사소통을 담당한다.
사용자
cocoa touch
media
core service
core OS
하드웨어
cocoa touch는 전반적인 ui를 담당한다. 버튼, 슬라이더, 맵킷, 카메라 등 사용자와 가장 가까운 부분의 처리를 수행한다.
media는 말 그대로 비디오, 오디오, 이미지 등 ios의 미디어 부분을 할당한다.
core service는 core location, network와 같은 핵심적인 서비스를 담당한다.
core OS는 BSD계열 unix로 구성되어있으며, 당연하게도 c언어 베이스이다.
해당 강의에서는 cocoa touch와 core service에 대해 다룰 예정이다.
Demo
이번 강의에 대한 카드뒤집기 데모를 만들었다.
import UIKit
class ViewController: UIViewController {
//카드를 뒤집은 수를 나타내는 레이블.
@IBOutlet weak var flipCountLabel: UILabel!
//flipCountLabel에 표시할 변수. 당연하게도 0부터 시작한다.
var flipCount = 0 {
//변수의 값 변동이 일어날 때마다 수행되는 메소드. flipCountLabel에 변경된 값을 전달하고 표시한다.
didSet{
flipCountLabel.text = "flipCount: \(flipCount)"
}
}
//카드를 뒤집는 함수. 카드에 그려질 이모티콘(문자열)과 어떤 카드에 그릴지 UIButton을 매개변수로 받는다.
func flipCard(withEmoji emoji:String, on button:UIButton) {
if button.currentTitle == emoji{
//카드가 앞면일 경우. 카드의 현재 문양(currentTitle)과 배개변수로 받은 이모티콘이 같다.
button.setTitle("", for: UIControl.State.normal)
button.backgroundColor = colorLiteral(red: 1, green: 0.5763723254, blue: 0, alpha: 1)
} else{
//카드가 뒷면일 경우. 카드에 배개변수로 받은 이모티콘을 그리고(setTitle) 배경을 흰색으로, flipCount를 증가시킨다.
button.setTitle(emoji, for: UIControl.State.normal)
button.backgroundColor = colorLiteral(red: 1, green: 1, blue: 1, alpha: 1)
//flipCount가 증가되면 didSet이 수행된다.
flipCount += 1
}
}
//UIButton을 카드모양으로 배치하였다. 해당 카드들을 배열로 담았다.
@IBOutlet var cards: [UIButton]!
//카드에 그려넣을 그림을 이모티콘으로 표현한다. 배열로 담았다.
let emojis = ["🐶","🦊","🐶","🦊"]
//사용자가 카드를 터치할 때의 이벤트 함수. 어떤 카드가 터치된건지 UIButton을 매개변수로 넘긴다.
@IBAction func touchCard(_ sender: UIButton) {
if let cardNumber = cards.firstIndex(of: sender){
//sender 즉 사용자가 터치한 카드가 cards배열에 몇번째 배열인지 반환한다.
//해당 카드와 같은 배열번호의 이모지를 배개변수로 넘겨 flipCard()함수 수행.
flipCard(withEmoji: emojis[cardNumber], on: sender)
} else{
//만약 카드가 cards배열에 없다면 오류문 출력
print("card is not in cardsArray")
}
}
}
여기서 인상깊었던 부분은 함수부분이다. 처음 스위프트를 배울 때 함수선언부분에서 왜 매개변수명을 굳이 두개나 적을까 궁금했는데, 새touchCard()의 flipCard() 호출부분을 보면 스위프트가 어째서 매개변수명을 두개로 적는지 알 수 있었다. 애플은 코드를 읽을 때 최대한 사람의 입장에서 자연스럽게 코드를 읽을 수 있기를 바랬고, 그러한 의도가 호출부에서 잘 나타났다.
flipCard(withEmoji: emojis[cardNumber], on : sender) ->전달자에 들어있는 이모지가 그려진 카드를 뒤집어라.
반대로 선언부에서는 withemoji와 on이라는 변수명이 부자연스러우니 emoji와 button이라는 변수명으로 사용이 된다. 이러한 변수명의 선택은 코드의 유지보수면에서 큰 도움이 된다고 생각한다. 강의를 많이 찾아본 것은 아니지만 적어도 학원강의에서는 이러한 부분을 전혀 알려주지 않았던 것을 보면 확실히 본토 대학강의가 훨씬 더 영양가있다고 생각한다.
이번에 didSet{ }에 대해서도 처음 배웠다. 속성감시자라고 번역이 되어있는데, 우리가 알고있는 변수는 스위프트에서 속성이라 부른다고 한다. 속성(변수)값이 변경될 경우 항상 수행되는 작업을 명시해줄 수 있다. 해당 데모에서 flipCount를 증가할 때 마다 레이블 수정작업을 따로 적을 필요없이 didSet{ }에 레이블 수정작업을 적어주어 코드라인을 줄일 수 있게 되었다.
