2018.06.01

• Codable: Codable프로토콜을 사용하여 JSONSerialization없이 바로 Data타입을 객체로 변환할 수 있었음
• 변환을 원하는 객체는 Codable타입이어야 함

2018.06.05

• 프로퍼티 옵저버 didSet
• 테이블뷰의 셀 높이 자동지정
  • tableView.rowHeight = UITableViewAutomaticDimension

2018.06.07

• Contact 프레임워크
• youtube에서 쉬운 튜토리얼을 찾았다. 그냥 진작에 이거부터 따라할걸ㅠㅠㅠ..
• privacy-sensitive data에 대해서 access권한 요청하기
  • 주소록같은 private한 데이터에 접근할때는 반드시 사용자에게 접근권한을 요청해야함. 이건 Info.plist에서 설정할 수 있는데 안그러면 앱이 아래의 에러를 뱉고 죽어버림. 에러에서 친절하게도 해결방법을 알려줘서 기록!
  • This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSContactsUsageDescription key with a string value explaining to the user how the app uses this data.
  • 해결방법: Info.plist파일로 가서 Information Property List 에서 +버튼 누르고 Privacy - Contacts 추가하여 description쓰기!

2018.04.30

• 4월 회고
• 카드게임 CardDeckDelegate 싱글톤구현

  class CardGameDelegate: CardGameManageable {
  
    static let defaultStackRange: CountableClosedRange = 1...7
    static let defaultStackNumber: Int = 7
  
    private static var sharedCardDeck = CardGameDelegate()
  
    private init() {
        cardDeck.shuffle()
        var stacks = [CardStack]()
        for numberOfCard in CardGameDelegate.defaultStackRange {
            let oneStack = cardDeck.makeStack(numberOf: numberOfCard)
            oneStack.sortDefaultStack()
            stacks.append(oneStack)
        }
        self.cardStacks = stacks
    }
  
    class func shared() -> CardGameDelegate {
        return sharedCardDeck
    }
    // 앱 내 어떤 클래스에서 이 메소드를 호출하더라도 이미 초기화된 sharedCardDeck만 리턴됨
    // 이때 초기화나 객체생성은 자기 자신 (CardGameDelegate)만 스스로 할 수 있도록 보호되어있음
  

4월 회고

Good

• 자판기완성!
• 카드게임부터 깃헙 이슈관리를 사용하기 시작했는데 적응됐다. 큰 요구사항도 단계별로 쪼개고 하나의 이슈로 관리하니까 수정사항 관리와 피드백관리가 편해짐.
• 커밋메시지쓰는 방법을 통일시키고 이슈번호와 함께 관리
  • 커밋메시지는 항상 타이틀: 간략 내용 형식으로 쓰고 만약 내용이 길어지면 아래 줄로 내려서 내용을 쓴다
• 뷰 - 뷰모델의 관계와 만드는 방법 이해함
  • 책임과 역할이 분명해진다: 그냥 단순 MVC보다 V-VM 관계를 만드니 더 책임과 관계의 경계가 명확해지는것같았다. 뷰모델에 있는 로직대로 바뀐 내용을 뷰는 그리기만 하면 된다.
  • 테스트가 가능해진다: 이렇게 되면 뷰모델을 테스트함으로써 뷰를 매번 그려가면서 결과화면을 보거나, 프린트로 그려지는 값을 찍어보는 1차원적인 방법으로 디버깅을 하지 않아도된다.
  • 또한 뷰모델을 만들면서 프로토콜에 의존하는 방법 (SOLID법칙에서 L - 다형성)을 이해하게됐다.
  • 모델을 확장 가능하게 만든다: 뷰와 뷰모델관계에서는 뷰가 뷰모델을 구현한 클래스를 속성으로 갖게되는데, 이때 뷰가 모델을 직접 가지는게 아니라 해당 모델클래스가 상속(구현)하고있는 프로토콜 타입을 가져야 한다.
  • 이렇게 모델클래스를 추상화한 프로토콜이 따로 있고, 어떤 클래스가 모델로 오더라도 확장에 열려있는 구조를 사용하는 것이 좋다. 이렇게 되면 뷰가 직접 모델을 가지는것이 아니라 프로토콜에 의존하는 약한 의존성을 갖게된다.

Bad

• 주말이나 수요일같은 여유시간에 공부를 많이 못했다. 쉴땐 쉰다는 핑계로..
• 근데 난 하나의 배경지식이라도 중요한 비전공자니께…
• 일단은 도움이 안되도 들어놓고 봐놓으면 언젠간 정말 도움이 되는것 같다.
• 처음 듣거나 볼때는 아예 모르겠는 말이 많은데, 한번 처음 볼 때 무슨 말인지 모르더라도 일단 봐두면 나중에 적어도 생소하지는 않으니, 처음보다는 편한 부분이 있었다.
• 항상 귀를 열고 눈을 열자!

앱 라이프사이클에 따른 AppDelegate methods 정리 Strategies for Handling App State Transitions 참고, 간단번역과 정리

• 대부분의 상태변화는 AppDelegate객체의 메소드 호출을 거친다.
• AppDelegate.swift 파일에는 앱의 상태에 따라 실행되는 함수들이 정의되어 있다.
• 앱의 상태에 따라 실행되는 delegate 함수들이 정의되어 있기때문에 함수안에 코드를 작성 함으로써 앱의 특정 상태에서 동작하는 로직을 구현 할 수 있다.

application(_:didFinishLaunching:) - 앱이 처음 시작될 때 실행
applicationWillResignActive: - 앱이 active 에서 inactive로 이동될 때 실행(foreground)
applicationDidEnterBackground: - 앱이 background 상태일 때 실행
applicationWillEnterForeground: - 앱이 background에서 foreground로 이동 될때 실행 (아직 foreground에서 실행중이진 않음)
applicationDidBecomeActive: - 앱이 active상태가 되어 실행 중(foreground)
applicationWillTerminate: - 앱이 종료될 때 실행

• application:willFinishLaunchingWithOptions:
  • 앱을 실행할 때 최초로 실행할 코드를 작성하면 좋음.
  • 앱을 실행할 때 필요한, 앱 번들이나 iCloud 컨테이너에 저장된 데이터 불러와서 설정할때 사용
• application:didFinishLaunchingWithOptions:
• 앱의 화면이 사용자에게 보여지기 직전에 최종 초기화 작업을 진행
• applicationDidBecomeActive: 앱이 이제 Foreground로 갈 것. 최종 준비작업.
• applicationWillResignActive:
  • 앱이 Foreground에서 다른 상태로 전환이 될것임을 알려줍니다. 앱이 잠잠한(quiescent) 상태로 변환되는 작업을 여기서 진행하세요.
  • Alert-based interruptions으로 인해 앱의 컨트롤이 일시적으로 중단될 수 있다. 앱은 foreground상태에서 계속 동작하지만, touch event를 받을 수 없는 상태이다. (It does continue to receive notifications and other types of events, such as accelerometer events, though.)
  • 이러한 상태에 대처하기위해 applicationWillResignActive를 구현해야함
    • Save data and any relevant state information.
    • Stop timers and other periodic tasks.
    • Stop any running metadata queries.
    • Do not initiate any new tasks.
    • Pause movie playback (except when playing back over AirPlay).
    • Enter into a pause state if your app is a game.
    • Throttle back OpenGL ES frame rates.
    • Suspend any dispatch queues or operation queues executing non-critical code. - (You can continue processing network requests and other time-sensitive background tasks while inactive.)
• applicationWillEnterForeground:
  • 앱이 Background에서 다시 Foreground로 돌아오게 될 것임을 알려줌. 아직 앱이 Active상태는 아님.
  • 이 함수는 applicationWillResignActive:는 반대의 상태일때 호출되는데, 이때는 reactivation에 필요한 동작을 구현해야한다.
    • restart timers, resume dispatch queues, and throttle up OpenGL ES frame rates again. However, games should not resume automatically; they should remain paused until the user chooses to resume them.
• applicationDidEnterBackground: 앱이 Background로 돌아감. 그리고 언제든지 Suspended상태로 변환이 될 수 있다.
• applicationWillTerminate: 앱이 종료될 것임을 알려줌. 만약 앱이 Suspended상태라면 이 메소드는 호출되지 않는다.

Responding to Temporary Interruptions

• Notifications that display a banner do not deactivate your app in the way that alert-based notifications do. Instead, the banner is laid along the top edge of your app window and your app continues receive touch events as before. However, if the user pulls down the banner to reveal the notification center, your app moves to the inactive state just as if an alert-based interruption had occurred. Your app remains in the inactive state until the user dismisses the notification center or launches another app. At this point, your app moves to the appropriate active or background state. The user can use the Settings app to configure which notifications display a banner and which display an alert.

• Pressing the Sleep/Wake button is another type of interruption that causes your app to be deactivated temporarily. When the user presses this button, the system disables touch events, moves the app to the background, sets the value of the app’s applicationState property to UIApplicationStateBackground, and locks the screen. A locked screen has additional consequences for apps that use data protection to encrypt files.

What to Do When Your App Enters the Foreground

Note: The UIApplicationWillEnterForegroundNotification notification is also available for tracking when your app reenters the foreground. Objects in your app can use the default notification center to register for this notification.

• 참고 - App Programming Guide for iOS
• 참고 - 앱 생명주기(App Lifecycle) vs 뷰 컨트롤러 생명주기(ViewController Lifecycle) in iOS
• 참고 - 앱라이프사이클

2018.04.16

• awakeFromNib()에대한 질문
  • 질문거리 정리하고 포스팅 수정
• 카드게임 피드백 처리하고 step3시작하기
  • 카드객체와 카드이미지뷰 1:1로 매핑되는 관계만들기
• CardDeck (UIImageview)의 제스쳐 이벤트
• CardDeck이 터치될때마다 탭제스쳐가 작동하지 않는 문제해결
  • 스택오버플로우에서 찾아본 바로는 isUserInteractionEnabled의 기본값은 true라고했는데,… 그게 아니었다.
  • UIView의 isUserInteractionEnabled / UIImageview의 isUserInteractionEnabled
    • (UIView에서 설명에 Note: ‘Some UIKit subclasses override this property and return a different default value.’를 잘 읽어봤어야했다..)
  • 심지어 클래스 참조 문제도 있었음.

2018.04.17

• 카드게임 step3 진행
  • 카드덱 터치부분 리팩토링: isUserInteractionEnabled - CardImageView에 적용
  • 아래 카드스택부분 출력 처리
    • 스택의 마지막 카드가 앞면인지 검사해서 앞면이 아니면 마지막 한장을 앞으로 뒤집는(open) 메소드 추가하기

2018.04.20

• CardStackDelegate만들기
• class 타입에서 struct로 변경. CardStackDelegate가 가진 stacks 상태가 변경되면 카드게임 앱 내 모든 객체가 똑같은 상태의 카드스택 상태를 알아야하므로 싱글톤 처럼 사용하는 느낌으로?
• 차라리 싱글톤으로 만드는게 나은가? 고민

2018.04.22

• 애니메이션 강의 정리
• 리스폰더체인 복습
• subclass CardImageView의 사이즈는 속성으로 고정하고 VC에서 origin만 부여하여 생성하는 방법 이슈 정리
  • < 간단한 질문, 답변내용 요약 >
  • Q: subview로 추가할 용도의 커스텀 UIView를 만들때 size값만 고정하고 origin만 superView에서 주는 방식으로 사용하는게 효율적인가?
  • A: 어차피 frame(특히 origin)값을 subview스스로 계산할 수 없다. superView기준으로 된 값이기때문에 superView에서 subview를 만들때 frame값을 넣어주는게 더 자연스러우며, superView의 코드를 짧게하고자 subview의 사이즈를 내부에 고정해두는 것 자체로는 큰 효율이 없다.
• animate 공부

커스텀 뷰 만들기의 장점

만약 하나의 뷰 컨트롤러에 여러 UIImageview(혹은 UIView) 타입의 서브뷰를 추가해야 할때, 그 여러 서브뷰들의 크기나, 테두리, 둥근 모서리와 같은 속성이 모두 동일한 경우가 있을 것이다. 만약 이 때 모든 서브뷰의 속성을 상위 뷰 컨트롤러에서 지정해준다면 반복되는 코드가 발생할 수 있고 뷰 컨트롤러의 코드가 비효율적으로 길어질 것이다.
이를 방지하기 위해서는, UIView를 상속받는 커스텀 코코아터치 클래스를 하나 만들어서, 내가 원하는 속성을 지정해주고, 추가할 서브뷰들의 타입을 커스텀뷰 타입으로 지정 해주면 된다.
여기서 서브뷰를 추가하는 방법에따라(뷰를 생성하는 방법에 따라) 호출되는 UIView의 초기화 함수가 결정되기 때문에, 커스텀뷰의 어디에 속성설정 코드를 넣어야 하는지가 중요하다!

UIView의 생성자

위에서 언급했듯이 뷰가 생성되는 방법에 따라 호출되는 초기화함수를 알아놓으면 이해가 쉬울 수 있어서 스탠포드 iOS강의 중 관련 부분을 정리해보았다.

• UIView는 두개의 필수 생성자가 있다. 바로 init(frame: CGRect)과 init(coder: NSCoder)이다.
• init(coder: NSCoder): 스토리보드 에서 나오면서 UIView를만들때 만들어지는 생성자.
  • 뷰를 스토리보드에서 드래그해서만들었는데, 만약 앱이 실행될때 스토리보드가 재구성되면 이 생성자가 호출되면서 UIView가 만들어짐.
• init(frame: CGRect): 코드로 뷰를 만들때 호출됨. 반드시 CGRect타입으로 프레임을 정해주고 UIView를 생성

  let rect = CGRect(x: 10, y: 10, width: 100, height: 100)
  let myView = UIView(frame: rect)
  

커스텀뷰에 뷰 속성 지정하기

만약 커스텀뷰를 상속받은 모든 뷰에 둥근 모서리(cornerRadius)속성을 부여하고 싶은 상황일 때는 아래의 방법들이 있다.

addSubVIew()로 서브뷰를 추가했을때

• 코드로 추가한 view에 속성을 적용하기 위해서는 init(frame:)에 속성을 지정해줘야한다.
• 다만, init(frame:)에는 무조건 frame값을 넣어줘야하기때문에, 아래 예시코드와 같은 방법으로 convenience init에 임시 frame값을 넣어줘도 된다.
  • 이 방법을 사용하면 원하는 frame값은 상위모듈에서 바꿔줘야한다.

override init(frame: CGRect) { // by code
    super.init(frame: frame)
    self.layer.cornerRadius = 5.0
    self.clipsToBounds = true
}

convenience init() {
    self.init(frame: CGRect(x: 0, y: 0, width: 0, height: 0))
}

인터페이스 빌더에서 서브뷰를 추가했을 때

• 인터페이스빌더에서 custom클래스로 지정한 뷰는 required init?(coder aDecoder:)가 호출된다.
• (스토리보드에서 뷰 컨트롤러가 가진 뷰의 타입을 오른쪽 탭 custom class에서 내가 추가한 커스텀뷰 클래스 이름 입력하여 연결)
• 만약에 어디서 호출될지 모르면 awakeFromNib과 두 convenience init에 설정하는 코드를 넣어주면 된다. 는 꼼수아닌 꼼수도 있다..

override func awakeFromNib() {
    // config setting code
        super.awakeFromNib()
    }

required init?(coder aDecoder: NSCoder) {
    // config setting code
    fatalError("init(coder:) has not been implemented")
}

+ 추가. awakeFromNib()

awakeFromNib()은 인터페이스 빌더에서 뷰가 만들어졌을때 호출된다고만 알고있었는데, 그보다 더 자세하게 알 필요가 있어서 추가

awakeFromNib이 호출되는 시점

awakeFromNib()은 객체가 초기화(인스턴스화)된 후 호출된다.

• UIView에서 상속받은 커스텀 View 클래스를 만들고 인터페이스빌더에 지정하면(오른쪽 탭 inspector에서 지정하는 방법으로) 커스텀 클래스는 아카이브되어 있다가 언아카이브됨(xib파일에)
• 이 때 init(coder:)가 호출되고 내부 속성이 초기화됨
• 일부는 이 때 의미없는 값으로 초기화되거나 IBOutlet을 비롯한 객체 참조 관계가 불명확할 수 있음
  • init 시점에서는 frame과 관련된 크기, 위치 등 뷰가 완벽하게 만들어지지 않은 상태
  • 이와같이 인터페이스 빌더에서 연결된 객체의 변수를 사용하려고 할때 awakeFromNib()을 사용함
  • 이렇게 awakeFromNib()은 객체를 인스턴스화 한 후(init()이 호출된 후) 호출된다.
• (IBOutlet이 없어도 awakeFromNib()은 호출됨)

awakeFromNib()과 init()에서 모두 설정해야 하는 이유

뷰를 만들고 커스텀뷰를 인터페이스빌더에서 연결했을땐 init(frame:), init(coder:)와 awakeFromNib()두 군데 모두에서 설정을 해준다의 의미

• 그래서 초기화가 끝나고 설정 awakeFromNib 시점에서 추가적인 작업이 필요한 경우 해야함.
• 커스텀 뷰를 만드는 개발자 입장에서는 다른 개발자가 init(frame:)을 호출해서 코드로 생성할지, 인터페이스 빌더에서 지정해서 사용할지 불명확하니까 코드로 만들던 인터페이스빌더로 작업하던 둘 다 동일한 동작이 가능하도록 지정하는 게 좋음
• JK의 코멘트 추가

  경험상 init(coder:) 시점에는 frame 이나 Layer 관련없는 값들,
  awakeFromNib 시점에는 frame 이나 Layer 관련된 값들을 설정하도록 구현하면 됩니다.
  init(frame:) 은 이미 frame 정보가 있으니까 괜찮구요.
  물론 autoLayout 처리를 하는 경우는 awakeFromNib 보다 더 뒤에 해야합니다.
  

참고링크 1, 참고링크 2, 참고링크 3