인스타그램을 하면서 항상 궁금했다. 내 스토리에 친구들이 하트를 눌러보면 보이는 저 하트가 올라가는 애니메이션은 어떻게 구현한 걸까?

유니티로는 파티클 애니메이션을 구현해 본 적이 있는데, Swift로 네이티브 iOS 앱을 만들 때는 어떻게 만들어야 할지 감도 안 왔다.

이것저것 찾아보니 방법에는 크게 두 가지가 있었다. CAEmitterLayer와 SpriteKit에 포함되어 있는 SKEmitterNode다.

SKEmitterNode

위에서 잠깐 설명했듯, Swift로 게임을 만들 수 있게 지원하는 SpriteKit에 포함되어 있다. 인스펙터에서 실제 파티클이 생성되는 모습을 보며 값들을 조정해줄 수 있어 편리하다.

하지만 UIView에 올리기 위해서는 SKView라는 SpriteKit의 뷰를 하나 만들어 SpriteKit Scene을 얹고 이를 뷰에 얹어주게 되어 있어 사실상 자연스러운 구조는 아니다.

그렇다고 해서 실제 사용되는 메모리 양을 보니 CAEmitter와 SKEmitter 간 의미있는 수준의 차이는 없었다. 그냥 SKEmitter는 게임을 위해 만들어진 탓에 non-game 앱에서는 구조가 조금 안 예쁠 뿐인 것 같다. (CAEmitter는 일반적인 UIView 위에 레이어 하나만 더해주면 된다.) CAEmitter로 구현이 가능한 경우라면 Non-game에서 굳이 SKEmitter를 썼을 때의 메리트를 찾지 못했다.

그래서 나는 SKEmitterNode로 대략적인 파라미터들의 값과 작동원리를 파악한 후 실제 구현은 CAEmitterLayer로 했다.

이 글에서 SKEmitterNode를 따로 설명하지는 않을 예정이다. 대신 이 영상에 잘 설명되어 있다.

CAEmitterLayer

CAEmitterLayer는 View 위에 얹어지는 Layer의 한 종류로, CAEmitterCell로 생성되는 파티클들을 Layer 위에 그려내는 방식이다. CAEmitterLayer와 CAEmitterCell에 설정할 수 있는 프로퍼티가 너무 많아서 일단 코드를 써보며 하나하나 살펴보는 게 훨씬 빠르게 먹힐 것이다.

위로 올라가는 하트 만들기 (방향, 각도 설정)

우선 CAEmitterLayer 하나를 만들어준다. 이게 뭐라고 이해하는 데 많은 시간을 할애하는 것보다는 지금은 그냥 파티클이 뿌려지는 하나의 캔버스라고 생각하면 쉽다. 이 캔버스에서는 파티클이 어떤 모양으로 뿌려질지, 얼마나 많은 파티클이 뿌려질지, 어느 위치에 뿌려질지 등을 정해줄 수 있다. 자세한 프로퍼티는 Zedd님이 잘 정리해두셨다. (Zedd 블로그)

let heartEmitter = CAEmitterLayer()
heartEmitter.emitterPosition = CGPoint(x: view.bounds.width/2, y: view.bounds.height/2)
heartEmitter.emitterSize = CGSize(width: 100, height: 100)
heartEmitter.emitterShape = .circle

이렇게 쓰고 실행시켜봤자 아무 일도 일어나지 않을 것이다. 우리는 지금 캔버스 하나를 만들었을 뿐이고, 실제로 파티클 하나하나가 어떤 특성을 가지는지는 CAEmitterCell에서 정의해주어야 하기 때문이다. CAEmitterCell에서는 파티클 이미지, 유지 시간, 속도, 나아가는 방향과 각도 등을 정의해줄 수 있다.

아래 코드에서는 예시로 인스타그램처럼 일렁이며 올라가는 하트 셀을 구현해보았다.

let heartCell = CAEmitterCell()
heartCell.contents = UIImage(named: "heart.png")?.cgImage // 이미지
heartCell.birthRate = 5 // 초당 생성 개수
heartCell.lifetime = 1.0 // 셀 유지 시간
heartCell.velocity = 100 // 속도
heartCell.emissionRange = .pi / 5 // 생성 각도
heartCell.emissionLongitude = .pi / -2 // 생성 각도

그 후에 우리가 만든 Layer에 Cell을 얹혀주고, 그 Layer을 원하는 뷰의 subLayer로 더해주면 된다.

heartEmitter.emitterCells = [heartCell]
view.layer.addSublayer(heartEmitter)

여기까지 코드를 쓰면 아래와 같은 모습이 된다. (현재까지의 코드)

위로 올라갈수록 옅어지게 만들기

지금도 충분히 일렁거리며 잘 올라가고 있지만, 어딘가 어색하다. 인스타그램의 하트와는 다르게 올라가며 툭툭 갑자기 사라지는 느낌이 든다. 위로 올라갈수록 alpha 값이 옅어지게 만들어 이를 해결해볼 수 있다.

위로 올라갈수록 alpha 값이 조정되는 건 셀 하나하나의 고유 값이 변경되는 것이므로 Layer가 아닌 Cell의 프로퍼티를 변경해주면 된다.

heartCell.alphaRange = 0.3
heartCell.alphaSpeed = -0.5

alphaRange는 해당 셀이 0부터 얼마까지의 알파 값을 가질 수 있느냐를 의미한다. 여기서는 0부터 0.3 사이의 값을 가지게 했다.

-0.5의 값을 준 alphaSpeed는 시간이 갈수록 알파 값을 줄여줄 것이다.

위로 올라가며 서서히 사라지는 모습이 되었다. (현재까지의 코드)

크기 변화 주기

이제 제법 인스타그램과 비슷해졌는데, 재밌는 걸 좀 더 붙여보려 한다. 셀이 모두 같은 크기엔 게 심심하니 크기에 변화를 줘볼 예정이다.

아래 값들로 변화를 주었다. 시작하는 크기, 크기 변화 범위, 시간이 흐를수록 얼마나 크기를 빠르게 변화시킬 건지 등을 설정해줄 수 있다.

heartCell.scale = 0.15
heartCell.scaleRange = 1
heartCell.scaleSpeed = 0.5

크기가 좀 더 다양한 하트가 되었다.

이모지를 EmitterCell로 사용할 수 있을까?

이쯤 되면 궁금한 게 생긴다. 이미지가 아닌 텍스트도 EmitterCell로 사용할 수 있을까? 텍스트도 사용할 수 있다면, 이미지를 하나하나 찾지 않고 기본 이모지를 활용해 더 재미난 파티클 애니메이션을 만들어볼 수 있을 것이다.

당연히 가능하다.

heartCell.contents = {
    let emoji = "🎉"
    let font = UIFont.systemFont(ofSize: 10)
    let size = emoji.size(withAttributes: [.font: font])
    let renderer = UIGraphicsImageRenderer(size: size)
    let image = renderer.image { context in
        emoji.draw(at: .zero, withAttributes: [.font: font])
    }
    return image.cgImage
}()

다만, 텍스트 자체로 contents 프로퍼티에 넣어주니 이모지는 나오지 않았고, 텍스트 이모지를 이미지로 렌더링 한 후 cgImage로 변환시켜주는 과정이 필요했다.

이모지도 잘 나오는 모습이다. (더 많은 파티클이 나오게끔 파라미터를 조금 조정해주었다) (현재까지의 코드)

이모지 섞기

여기까지 오니 욕심이 나기 시작한다. 꼭 한 종류의 이모지만 나와야 할까? 여러 종류의 이모지가 한 번에 섞여 나오면 더 멋있지 않을까?

물론 이것도 가능하다.

하나의 CAEmitterLayer는 여러 개의 CAEmitterCell을 가질 수 있다. 이 점을 활용하면 된다.

신경 써야 할 것이 많지는 않다.

1. 이모지 개수만큼 Cell이 생성되게 할 것
2. 이모지 개수가 많아져도 실제 스폰 되는 개수는 변하지 않게 할 것

let emojiStrings = ["❤️", "💙", "💛", "💜", "🤎"]

var emitterCells: [CAEmitterCell] = [] // 셀들을 담을 곳을 만들고
for emoji in emojiStrings { // 각 이모지에 대해 셀 생성
    let emitterCell = CAEmitterCell()
    emitterCell.contents = {
        let font = UIFont.systemFont(ofSize: 20)
        let size = emoji.size(withAttributes: [.font: font])
        let renderer = UIGraphicsImageRenderer(size: size)
        let image = renderer.image { context in
            emoji.draw(at: .zero, withAttributes: [.font: font])
        }
        return image.cgImage
    }()
    emitterCell.birthRate = 30 / Float(emojiStrings.count) // 생성 개수는 이모지 개수로 나눠준다
    // (다른 프로퍼티들은 생략)

    emitterCells.append(emitterCell)
}

emitterLayer.emitterCells = emitterCells

여기까지 쓰면 이런 다채로운 하트 이모지들을 만날 수 있다. (현재까지의 코드)

정리하며

여기선 인스타 스토리 하트 파티클을 만든다는 목표로 하나의 형태의 파티클을 만들어봤지만, 실제로 CAEmitter를 잘 활용하면 눈/비 내리는 효과, 폭발 효과, 반딧불 등 예쁜 이펙트를 많이 만들어낼 수 있다.

이것저것 만져보면 재밌기도 하고, 생각보다 러닝커브가 높지 않다는 걸 느낄 수 있을 것이다.

아래는 전체 코드다.

//
//  InstaStyleParticleVC.swift
//  iOSLab
//
//  Created by Danna Lee on 2023/03/26.
//

import UIKit

class InstaStyleParticleVC: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        generateParticle()
    }
}

extension InstaStyleParticleVC {
    private func generateParticle() {
        let emitterLayer = CAEmitterLayer()
        emitterLayer.emitterPosition = CGPoint(x: view.bounds.width/2, y: view.bounds.height - 100)
        emitterLayer.emitterSize = CGSize(width: 100, height: 100)
        emitterLayer.emitterShape = .point

        let emojiStrings = ["🥳", "👏🏻", "🍾", "🎉"]

        var emitterCells: [CAEmitterCell] = []
        for emoji in emojiStrings {
            let emitterCell = CAEmitterCell()
            emitterCell.contents = {
                let font = UIFont.systemFont(ofSize: 20)
                let size = emoji.size(withAttributes: [.font: font])
                let renderer = UIGraphicsImageRenderer(size: size)
                let image = renderer.image { context in
                    emoji.draw(at: .zero, withAttributes: [.font: font])
                }
                return image.cgImage
            }()
            emitterCell.birthRate = 30 / Float(emojiStrings.count)
            emitterCell.lifetime = 1.0
            emitterCell.velocity = 300
            emitterCell.velocityRange = 50
            emitterCell.emissionRange = .pi / 5
            emitterCell.emissionLongitude = .pi / -2
            emitterCell.alphaRange = 0.3
            emitterCell.alphaSpeed = -0.5
            emitterCell.scale = 0.15
            emitterCell.scaleRange = 1
            emitterCell.scaleSpeed = 0.5

            emitterCells.append(emitterCell)
        }

        emitterLayer.emitterCells = emitterCells
        view.layer.addSublayer(emitterLayer)
    }
}

신나게 자축하며 끝

1. The evolution of Facebook’s iOS app architecture 페이스북 iOS 앱은 Meta에서 관리하는 모바일 코드베이스 중 가장 오래된 코드베이스다. 이 아티클은 2014년부터 현재까지 메타에서 일하고 있는 Dustin Shahidehpour라는 사람이 쓴 아티클로, 2012년에 전체 코드를 모두 새로 쓴 이후 어떤 의사 결정 과정에 의해 코드 베이스가 발전되어 왔고, 지금의 구조를 가지게 되었는지 상세히 설명하고 있다. 흥미로운 점은, 페이스북 iOS 앱에는 Apple SDK가 거의 하나도 쓰이지 않았다고 한다.

2. Save money when using GitHub Actions for iOS CI/CD 깃허브 프라이빗 레포지토리의 액션에서 iOS 베이스 코드 CI/CD를 구축할 때 MacOS를 빌드 머신으로 사용하면 리눅스 베이스 러너보다 10배 가량 높은 비용이 청구된다. 위 아티클에선 다양한 케이스를 들어 빌드 비용을 아끼는 법을 설명한다. 하지만 위 아티클에는 Self-hosted runner에 대한 설명이 없어 이 문서도 같이 보면 좋다고 한다.

3. Find Problematic Constraint 단 한 장의 직관적인 사진인데, iOS 뉴비라면 모두가 고통받고 있을 만한 문제의 솔루션을 잘 제시한 사진이다. constraint가 중첩되거나 누락되었을 때 콘솔에 찍히는 에러메시지로부터 정확히 어떤 제약에서 문제가 생긴건지 바로 알 수 있는 방법을 안내한다.

4. iOS in-app subscription tutorial with StoreKit 2 and Swift RevenueCat이라는 서비스를 만드는 회사에서 써낸 아티클이다. StoreKit2를 사용한 iOS의 인앱결제 개발 방법을 설명하고 있다. 결제 관련 유틸리티를 만들고 있는 회사지만 자사 제품 광고보다는 설명 그 자체에 많은 공을 들인 걸 알 수 있는 자세한 설명에 감탄했다. 끝은 결국 이 방법의 한계에 대해 설명하며 자사 제품을 쓰면 그 한계를 어떻게 극복할 수 있는지 설명하고 있지만, 그 전까지만 봐도 충분히 매력있는 아티클이다.

하지만, 하나 무시할 수 없는 문제가 있다. 유니티는 게임엔진이지, UI에 최적화 되어 있는 것은 아니기 때문에 유니티에서 작업한 UI는 어쩔 수 없이 조금 뿌옇게 화면에 보이게 된다. 유니티가 최근 새로 밀고 있는 UI Toolkit도 예외는 아니다. 문제가 되는 건 구현해야 하는 게 게임 형식의 앱이 아닌 일반 앱의 UI를 가져야 할 때다. 3D 뷰가 필요하지만 게임이 아닌 심플한 메타버스 형식의 앱들이 그 예시가 될 수 있을 것 같다. 이렇게 유니티로만 만들어진 게임이 아닌 앱들의 UI는 섬세하지 않은 눈을 가진 사람도 가장자리나 색 표현이 좀 뿌연데? 하는 느낌을 받을 수 있을 정도다.

그래서 Swift UIKit으로 구현한 iOS 앱 베이스에 일부 3D 뷰만 유니티로 구현하며, 유니티 위에 뜨는 버튼도 네이티브에서 구현하기로 결정했다.

Unity VC에 대한 이해

iOS에서 Unity 뷰를 띄울 때는 unity as a library 방식을 이용한다. 간단히 말하면 유니티를 라이브러리처럼 빌드해서 iOS 네이티브 프로젝트에 얹는 방식이다. uaal에 대한 설명은 유니티에서 공식적으로 공개한 uaal example github에 자세히 나와있다.

iOS 네이티브 코드에서 show unity를 하게 되면 Unity ViewController(줄여서 UnityVC라고 하겠습니다)가 생기고 그 위에 유니티에서 구현한 뷰가 그려지는 방식이다. 이렇게 만들어진 뷰컨트롤러는 우리가 네이티브에서 뷰컨트롤러를 사용하듯 사용할 수 있다. 해당 뷰컨트롤러에 뷰를 자유롭게 추가할 수도 있고 없앨 수도 있다는 의미다.

Unity 뷰 위에 네이티브 버튼 얹기

UnityViewController의 존재에 대해 알았으니 이제 그 뷰컨트롤러 위에 네이티브 버튼을 어떻게 얹을지 고민하면 된다. 버튼 하나만 만들어서 UnityVC에 위치를 계산해 넣어줄 수도 있을 거고, 화면 전체 크기의 뷰를 만들어 그 위에 필요한 UI를 모두 얹어준 뒤 화면 전체 크기만큼 그 뷰를 얹어줄 수도 있을 것이다. 어떤 방법을 택하든 생각해줘야 할 것은 같다.

1. UnityVC를 가져올 수 있어야 하고,
2. 그 위에 addSubview를 할 수 있어야 한다.

UnityVC 가져오기

위에서 언급한 uaal-example 코드대로 iOS 네이티브(Swift)+Unity 프로젝트를 세팅했다면, MainViewController.mm 파일을 찾을 수 있을 것이다.

여기 보면 ufw가 정의되어 있는 모습을 볼 수 있는데, 이를 중심으로 유니티 프레임워크가 관리된다.

그리고 타고 들어가다 보면 appController의 이름으로 관리되는 UnityAppController를 볼 수 있고, 또 그 UnityAppControllersms rootViewController를 관리하고 있다. 바로 이 rootViewController를 가져오면 우리는 이 뷰컨트롤러를 UnityViewController로 사용할 수 있게 된다. (그 위에 텍스트, 버튼, 뷰를 얹을 수 있게 된다.)

아래처럼 접근해주면 된다.

- (UIViewController*)getUnityController {
    return [[[self ufw] appController] rootViewController];
}

UnityManager 구축하기

어느 VC에서든 유니티 뷰에 접근할 일이 있는데, 유니티 관련 로직이 uaal example에서처럼 특정 VC 내에서만 관리된다면, 개발에 큰 어려움이 있을 것이다. 그래서 iOS native에 Unity를 통합한 사례들을 보면 UnityManager를 싱글톤으로 구현해 접근을 관리하고 있다. UnityManager를 구축하는 방법은 설명한 블로그가 많기 때문에 여기서는 따로 언급하지 않고, 예시 블로그를 첨부하겠다.

UnityManager를 구축했다면, 그 안에 위에서 정의한 getUnityController 메서드를 위치시키고, 어디서든 유니티 컨트롤러를 부를 수 있게 해주면 된다. 예시 블로그와 다르게 나는 UnityManager을 objc 코드로 구현했고, objective-c와 swift가 통신할 수 있게 브릿지를 구축해 swift 코드에서 사용할 수 있게 했다. 어디서든 아래의 코드를 입력하면 현재 떠있는 UnityVC를 가져올 수 있다.

let unityVC: UIViewController? = UnityManager.sharedInstance().getUnityController()

VC 위에 뷰 추가하기

ViewController까지 가져왔다면 그 위에 뷰를 추가하는 건 일도 아니다. 그냥 항상 하듯이 addSubview()를 이용해주면 된다. 예를 들어, UnityVC 크기만한 뷰를 위에 얹는 건 아래 코드처럼 쓸 수 있다.

let unityVC = UnityManager.sharedInstance().getUnityController()

let view = TempView(frame: (unityVC?.view.bounds)!)
unityVC?.view.addSubview(view)

UnityVC 위 네이티브 뷰 관리하기

버튼 하나씩 UnityVC 위에 추가해줄 수도 있지만, 전체화면 크기의 뷰 단위로 UnityVC 위에 추가하고 삭제하며 관리하는 게 더 효과적이다. 구현해야 하는 UI 특성상 상태에 따라 UI 버튼 구성 전체가 바뀌어야 하는 경우가 많기 때문이다. 그러나, 이 위에 얹어지는 뷰를 뷰컨트롤러로 만들 수는 없는데, 유니티뷰까지 터치이벤트까지 가야 하기 때문이다. UnityVC 위에 overlay로 ViewController를 얹을 경우 유니티에서 터치이벤트를 관리할 수 없는 한계가 있었다.

View로 관리하면 가장 큰 문제가 있는데, 바로 네비게이션 컨트롤러나 modal present, dismiss 같은 뷰컨트롤러 방식대로 VC 스택 관리를 할 수 없다는 것이다. 직접 View를 얹고 삭제하며 관리해주어야 한다. 그래서 선택한 방법은 VC처럼 View의 계층과 생성 삭제를 관리해주는 싱글톤 ViewManager를 만들어 관리하는 방법이었다.

나는 이 관리 모듈을 UnityOverlayViewManager.swift 로 이름 지었다. 이 매니저가 해야 할 일은 크게 3개가 있다.

1. 뷰 전환하기
2. 현재 있는 뷰 위에 뷰 하나 더 쌓기
3. 뷰 삭제하기

UnityOverlayViewManager에서 뷰 전환하기

예를 들어 네비게이션 컨트롤러 위에서 관리되는 ViewController에서의 뷰 전환은 navigationController?.pushViewController(vc, animated: true)와 같은 코드로 간단하게 구현할 수 있다. UnityOverlayViewManager에서의 뷰 전환도 이처럼 간단하게 호출할 수 있도록 구현했다.

뷰를 전환할 때 홈을 중심으로 버튼을 누르면 UI가 전환 되었다 돌아와야 하는 구조로 되어 있다. 따라서 홈은 계속해서 추가, 삭제 되지 않아야 했다.

다른 뷰로 전환될 때 홈은 hidden 처리 되고, 홈이 아닌 다른 뷰들은 removeFromSuperView 되게 구현했다. 모든 뷰는 싱글톤 UnityOverlayViewManager의 viewStack으로 관리될 수 있도록 설계했다.

private var viewStack: [UIView] = []

우선 홈이 처음 로드될 때 우리 매니저 위에서 관리되어야 했다.

/// 가장 처음 홈이 로드될 때 호출
public func initializeHome() {
    let home = HomeView(frame: (unityVC?.view.bounds)!)
    unityVC?.view.addSubview(home)
    viewStack.append(home)
}

위 코드를 보면 홈뷰를 로드해 유니티에 addSubview 한 후 viewStack에 추가하는 모습을 볼 수 있다.

그리고 전환하는 로직은 아래 코드처럼 쓸 수 있다. 기본적인 메커니즘은 다음과 같다.

1. 홈은 뷰 추가, 삭제하지 않는다. 대신 isHidden true, false 처리를 한다.

2. 홈이 아닌 모든 뷰는 unityVC 위에 추가/삭제 한다.

3. unityVC 위 모든 뷰는 viewStack으로 관리되고 있어야 한다.

   /// 홈으로 전환하기
   public func presentHome() {
    guard let firstView = viewStack[0] as? HomeView else { return }
   
    firstView.isHidden = false // 홈은 addSubview 대신 숨김 false 처리
    removeAllSubviews() // 홈 이외에 모든 뷰는 삭제
   }
   

/// (홈이 아닌) 아예 새로운 뷰로 전환하기 public func present(_ newView: UIView) { if let _ = newView as? HomeView { fatalError("HomeView로 전환할 때는 presentHome()을 사용하세요.") }

let homeView = viewStack[0]
homeView.isHidden = true // 홈은 뷰 삭제 대신 숨김 처리

viewStack.append(newView) // 새로운 뷰를 뷰 스택에 추가
unityVC?.view.addSubview(newView) // 새로운 뷰를 unityVC에 추가

removeAllSubviews(includeLast: false) // 홈과 방금 추가한 뷰를 제외하고 모두 삭제

}

```swift
/// [모든 뷰 지우기]
/// includeLast: 다음 뷰 호출 로직이 사라져야 할 뷰 내에 있을 때를 위한 안전장치
private func removeAllSubviews(includeLast: Bool = true) {
    if includeLast {
        for view in viewStack[1...] {
            view.removeFromSuperview()
        }
    } else {
        for view in viewStack[1...].dropLast() {
            view.removeFromSuperview()
        }
    }
}

모든 뷰를 지우는 부분에서 왜 싱글톤 매니저에서 뷰스택을 관리해야 하는지 알 수 있다. 뷰 스택으로 관리되지 않으면 매번 unityVC.view.subviews로 뷰를 가져와야 할 텐데, 뷰를 추가할 때마다 viewStack에 그 reference를 등록해둔 덕에 바로바로 접근해 삭제가 가능하다.

하나 이상해 보일 수 있는 부분이 있을 수 있는데, present 로직에서 왜 모든 뷰를 삭제한 후에 새로운 뷰를 더하지 않고, 새로운 뷰를 더한 후에 나머지 뷰들을 삭제하냐는 것이다. 그 이유는 예를 들어 A라는 뷰가 있고, A라는 뷰가 삭제되고 B라는 뷰로 전환되어야 하는 경우가 있다고 가정한다. 그럼 A라는 뷰에서 B 뷰로 전환하는 과정에서 B 뷰가 추가되기 전에 A 뷰가 삭제되는 경우가 생긴다. 이 경우를 위해 우선 필요한 모든 뷰를 addSubview 한 후 사용하지 않는 뷰를 삭제하는 순서로 로직을 전개했다.

해당 메서드를 사용해 실제로 뷰를 전환하려면 간단하게 아래처럼 쓸 수 있다.

UnityOverlayViewManager.shared.presentHome() // 홈으로 전환
UnityOverlayViewManager.shared.present(TempView()) // 홈 이외의 뷰로 전환

현재 있는 뷰 위에 뷰 하나 더 쌓기

위처럼 present까지 구현했다면 뷰를 하나 더 쌓는 건 일도 아니다. 그냥 unityVC에 뷰를 하나 더해주고 뷰 스택에 추가해주면 된다.

/// 현재 있는 뷰 위에 뷰 쌓기
public func addView(_ newView: UIView) {
    viewStack.append(newView)
    unityVC?.view.addSubview(newView)
}

뷰 삭제하기

뷰 삭제하기도 마찬가지로 복잡하지 않다. 모든 뷰를 삭제하고 viewStack에서도 제거해주면 된다.

반 년동안 2주에 한 번 글을 적어야 하는데, 그 첫 발걸음으로 다짐을 모두가 보는 이곳에 박제해볼까 합니다.

1. 가장 단순하지만, 6개월 동안 한 번도 빠지지 않고 글을 적어내 보고 싶습니다. 글 쓰는 것을 좋아했지만 이제는 많이 멀어져 버려, 그 과정에서 잃어버린 자신감을 되찾는 것이 목표입니다.

2. 그리고 그다음의 목표는 개발 생태계에 기여할 수 있는 의미 있는 글을 적는 것입니다. 별 것 아니지만 IT동아리 활동을 하며 신입회원들을 대상으로 git 세션을 주최한 적이 있었습니다. 그때 자료를 준비하며 적었던 블로그 글에 만 명이 넘는 사람이 방문했고, 심지어는 링크를 알려준 적 없던 지인의 북마크에도 들어가 있는 모습을 보았습니다. 그때 글로써 개발 생태계에 기여하는 뿌듯함을 처음 경험했습니다. 단순히 보증금을 위해 글자 채우기로 적는 글이 아니라, 제 글이 작게나마 한국 개발 생태계의 선순환에 한 발 보탰으면 하는 마음으로 글을 적어나가고 싶습니다.

3. 욕심을 좀 내보자면, 글에 철학을 녹여내는 것입니다. 무엇이든 본질을 찾아가 천천히 생각하고 정리하는 것을 좋아합니다. 개발도 예외는 아니었습니다. 회사에서도, 친구들과 프로젝트를 할 때도 항상 이유 있는 결정을 하고자 했고, 그 과정에서의 사고 과정, 고려된 것들, 도출된 결론을 종종 공유했습니다. 이 과정에서 빈 공간이 많이 채워지고, 서로의 생각이 한 곳으로 얼라인 될 수 있어 함께 일하는 분들은 제가 이렇게 공유하는 시간을 좋아했습니다. 이 점이 저와 함께 일하는 분들뿐만 아니라 개발을 공부하는 분들에게도 어쩌면 도움이 될 수 있겠다 생각이 듭니다. 개발 스택과 같은 결정을 할 때 단순히 유행을 따라 선택하는 것보다 이유 있는 선택을 돕기 위해 본질부터 잘 고찰하고 정리한 글을 적고 싶습니다.

4. 마지막으로, 다양한 경험을 가진 분들을 알아가고 싶습니다. 제 글만 적어내려가는 게 아니라 6개월 동안은 다른 분들의 글도 많이 읽고, 피드백을 남겨보려 합니다. 다른 사람들은 어떤 생각을 하고 사는지, 어떤 일을 하고 있는지 많은 이야기를 듣고, 저도 제가 가진 경험과 인사이트를 함께 공유하고 싶습니다.

글또 활동을 하면서 해이해질 때마다 이 글을 보고 다시금 마음을 잡으러 들어오겠습니다.

그럼 파이팅!

이번에는 그 뒤에서 어떤 로직들이 일어나고 있는지 더 자세히 분석하려 합니다.

저번의 방식과 똑같이 시간 순서대로 나열하려면 필요없는 로직부를 너무 많이 설명하게 될 것 같아 이번에는 주요 아키텍쳐나 구현 방식 중심으로 적어보겠습니다.

Scene 관련 로직

Scene 이동

Startup -> MainMenu 이동

전 글에서도 잠깐 언급했듯, 모든 건 Startup Scene에서 시작합니다.

하지만 Startup 씬을 보면 이렇게 로딩 페이지만 있고, 실제로는 어떻게 메인 메뉴 씬으로 넘어가게 되는지 알지 못합니다.

그 해답은 script에 있는데요, hierarchy를 보면 ApplicationController라는 게 가장 위에 보입니다.

스크립트로 들어가보니 상단부에 summary가 있고, ApplicationController가 어떤 역할을 하고 있는지에 대한 설명이 있습니다.

" An entry point to the application, where we bind all the common dependencies to the root DI scope. "
-> 애플리케이션의 엔트리포인트이며, root DI(Dependency injection; 의존성 주입) scope에 공통적으로 사용되는 모든 객체의 의존성을 정의하는 곳이다.

쉽게 말해, 애플리케이션 실행 주기 전반에 걸쳐 사용될 것들의 초기 세팅을 하는 곳이라 이해했습니다.

그래서 코드 구조를 보면 이벤트 함수인 Awake()에 의존성 주입과 관련된 세팅 코드가 있고, 모든 세팅이 끝난 이후에 불리는 Start()에 비로소 MainMenu를 부르는 코드가 적혀 있습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Shared
{
    /// <summary>
    /// An entry point to the application, where we bind all the common dependencies to the root DI scope.
    /// </summary>
    public class ApplicationController : MonoBehaviour
    {
        private void Awake()
        {
            Application.wantsToQuit += OnWantToQuit;

            DontDestroyOnLoad(gameObject);
            DontDestroyOnLoad(m_UpdateRunner.gameObject);

            var scope = DIScope.RootScope;

            scope.BindInstanceAsSingle(this);
            scope.BindInstanceAsSingle(m_UpdateRunner);
            scope.BindInstanceAsSingle(m_GameNetPortal);
            scope.BindInstanceAsSingle(m_ClientNetPortal);
            scope.BindInstanceAsSingle(m_ServerGameNetPortal);

            // ...

            Application.targetFrameRate = 120;
        }

        private void Start()
        {
            SceneManager.LoadScene("MainMenu"); // MainMenu Scene으로 이동
        }
    }
}

여기서 잠깐 Awake와 Start 이벤트 함수가 불리는 정확한 시점에 관한 유니티 문서를 보고 가겠습니다.

Awake: This function is always called before any Start functions and also just after a prefab is instantiated. (If a GameObject is inactive during start up Awake is not called until it is made active.)
-> Start 함수 실행 전, 프리팹이 초기화 되고 난 즉시 불린다.

Start: Start is called before the first frame update only if the script instance is enabled.
-> 첫 프레임이 업데이트 되기 전에 불린다. 단, 스크립트 인스턴스가 활성화 되었을 때만 불린다.

따라서 의존성 주입 등의 세팅 작업이 Awake에서 끝나면, Start 함수에 정의된 MainMenu를 호출하는 코드가 실행되게 되고, 바로 메인메뉴로 이동하게 되는 것입니다.

팝업 표출

MainMenu의 'IP로 시작 팝업'

메인메뉴에서 두 번째 버튼(START WITH DIRECT IP)을 누르면 특정 IP를 지정해 게임을 호스트하거나 참여할 수 있는 팝업이 뜹니다.

이 팝업을 띄우는 로직을 살펴보려 합니다.

MainMenu Scene hierarchy를 보면 맨 위에 MainMenuState를 볼 수 있습니다. 상태값에 따라 MainMenu 각 버튼을 비롯한 UI를 변화시키는 로직이 담긴 스크립트입니다. MainMenuState의 inspector를 보면 ClientMainMenuState.cs 스크립트와 연결이 되어 있는 것을 확인할 수 있습니다. 여기서 다시 'IP로 시작 팝업' 관련 로직은 serializedField로 관리되고 있는 IPUIMediator에 연결된 IPPopup에서 관장하고 있겠네요. IPPopup은 IPUIMediator.cs라는 스크립트에 연결된 것까지 확인할 수 있습니다.

IPUIMediator.cs에 들어가보면 긴 코드가 보이지만, 우리가 집중해야 할 건 몇 줄 안 됩니다. 중요한 코드만 모아 보겠습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Visual
{
    public class IPUIMediator : MonoBehaviour
    {
        [SerializeField] CanvasGroup m_CanvasGroup; // 팝업 캔버스

        public void Show()
        {
            m_CanvasGroup.alpha = 1f;
            m_CanvasGroup.interactable = true;
            m_CanvasGroup.blocksRaycasts = true;

            DisableSignInSpinner();
        }

        public void Hide()
        {
            m_CanvasGroup.alpha = 0f;
            m_CanvasGroup.interactable = false;
            m_CanvasGroup.blocksRaycasts = false;
        }
    }
}

팝업을 어떻게 띄우는지 보려고 했던 것이므로, 팝업을 띄우고 없애는 로직 이외에는 다 지워봤습니다.

상당히 직관적인 코드입니다. 없애고 나타내야 할 때 알파값을 조정하고, 사용자 인터랙션을 끄고 켜고, raycast를 막고 푸는 작업을 합니다.

팝업은 기본적으로 보이는 상태고, IPUIMediator.cs 스크립트의 Awake()에서 Hide() 되고 있습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Visual
{
    public class IPUIMediator : MonoBehaviour
    {
        void Awake()
        {
            Hide();
        }
    }
}

기본적으로는 Hide 되어 있는 팝업이지만, START WITH DIRECT IP 버튼을 누르면 팝업이 나와야 합니다.

이 로직은 Hierarchy의 IP Start Button 프리팹의 버튼 컴포넌트 > On Click에서 시작점을 찾아볼 수 있습니다.

버튼이 클릭되면 ClientMainMenuState.cs에 정의되어 있는 OnDirectIPClicked라는 메서드를 부르라고 되어 있네요.

따라가보면 이런 코드를 볼 수 있습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Client
{
    public class ClientMainMenuState : GameStateBehaviour
    {
        [SerializeField] LobbyUIMediator m_LobbyUIMediator;
        [SerializeField] IPUIMediator m_IPUIMediator;

        public void OnDirectIPClicked()
        {
            m_LobbyUIMediator.Hide();
            m_IPUIMediator.Show();
        }
    }
}

로비 팝업 (맨 위 버튼 누르면 나오는 팝업)이 혹시 있다면 숨기고, IP 팝업을 나타나게 하라는 간단한 코드입니다.

각각 Hide와 Show를 따라 들어가보면 또 알파값, 유저인터랙션, 래이케스트 값을 조정하는 코드가 있겠죠.

이렇게 팝업을 나타나게 하는 로직을 살펴봤습니다.

이제는 팝업이 사라지는 로직을 살펴보겠습니다. 간단합니다.

만약 우상단의 X 버튼이 클릭된다면 Cancel Button 오브젝트의 Button > On Click에서 Hide() 메서드를 불러줍니다.

그런데 보니 Hide만 불리고 있는 게 아니라 CancelConnectionWindow라는 메서드도 함께 불리고 있습니다.

얘는 뭘까요?

namespace Unity.Multiplayer.Samples.BossRoom.Visual
{
    public class IPUIMediator : MonoBehaviour
    {
        // To be called from the Cancel (X) UI button
        public void CancelConnectingWindow()
        {
            RequestShutdown();
            m_IPConnectionWindow.CancelConnectionWindow();
        }

        void RequestShutdown()
        {
            if (m_ConnectionManager && m_ConnectionManager.NetworkManager)
            {
                m_ConnectionManager.RequestShutdown();
            }
        }
    }
}

간단히 말해 네트워크 통신 중이었다면 연결을 끊고, 로딩창도 숨기라는 뜻입니다.

자세한 건 직접 코드를 살펴보시면 쉽게 이해하실 수 있을 것 같습니다. (코드를 타고타고 들어가다 보면 관련된 코드가 너무 많아 상세히 적지 않겠습니다)

이렇게 팝업 띄우고 없애기를 모두 살펴보았습니다.

본격적으로 폴더 하나하나를 뜯어보겠습니다.

우선 Scenes 폴더 내부는 아래처럼 이루어져 있습니다.

Startup Scene

Startup에서 게임을 시작할 수 있습니다.

MainMenu Scene

바로 MainMenu Scene으로 넘어가는데요,

복잡하게 떠있는 팝업을 잠깐 가려보면, 이런 화면을 볼 수 있습니다.

게임을 시작하기 위해 사용자가 가장 먼저 보게 되는 장면입니다.

중앙 부분에 버튼이 크게 세 개 있는데,

[START WITH LOBBY] START WITH LOBBY 버튼은 유니티의 Lobby, Relay와 연동하면 활성화되며, 로비에 방을 만들어 게임을 시작하는 방식입니다.

처음 들어오면 첫 번째 버튼이 비활성화 되어 있을 텐데,

1. 본인의 유니티 대시보드로 가서
2. 새 프로젝트 생성
3. Multiplayer > Lobby, Relay 활성화
4. Unity 에디터 프로젝트 세팅 > Services에서 계정 연결
   해주면 버튼이 활성화되고, 친구들과 로비를 만들어 플레이할 수 있게 됩니다. 자세한 내용은 Boss room 공식 문서에서 찾아볼 수 있습니다.
   

+) 설정 해주지 않아도 두 번째 버튼을 눌러 게임을 해 볼 수 있습니다.

[START WITH DIRECT IP] 이 방법은 별도의 서버 없이 로컬호스트로 로컬에서 게임을 시작하는 방법이나 포트포워딩을 통해 포트 번호로 직접 게임에 참여하는 방법입니다. 로컬호스트로 자신의 ip가 서버와 동시에 클라이언트가 되어 바로 게임을 해볼 수 있습니다.

[CHANGE PROFILE] 프로필을 생성, 변경할 수 있는 버튼입니다.

각각 Lobby Start Button, IP Start Button, Profile Button으로 만들어져 있고, 각 버튼에 다른 클릭 액션이 매핑되어 있습니다.

예시로 Lobby Start BUtton > Button 컴포넌트의 On click인데, 클릭이 되었을 때 ClientMainMenuState.cs 파일의 OnStartClicked 메서드를 트리거 하고 있는 것을 확인할 수 있습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Client
{
    public class ClientMainMenuState : GameStateBehaviour
    {
        // ...

        public void OnStartClicked()
        {
            m_LobbyUIMediator.ToggleJoinLobbyUI();
            m_LobbyUIMediator.Show();
        }

        // ...
    }
}

여기서 m_LobbyUIMediator는 SerializedField로 정의되어 UI 상에서 연결이 되어 있는데, MainMenuState 프리팹에서 ClientMainMenuState.cs 파일에 연동되어 있는 컴포넌트를 보면, LobbyPopup에 연결되어 있는 걸 확인할 수 있습니다.

LobbyPopup은 다시 LobbyUIMediator.cs 파일에 연동되어 있으며, ToggleJoinLobbyUI()가 이렇게 구현되어 있습니다.

namespace Unity.Multiplayer.Samples.BossRoom.Visual
{
    public class LobbyUIMediator : MonoBehaviour
    {
        public void ToggleJoinLobbyUI()
        {
            m_LobbyJoiningUI.Show();
            m_LobbyCreationUI.Hide();
            m_JoinToggleHighlight.SetToColor(1);
            m_JoinToggleTabBlocker.SetToColor(1);
            m_CreateToggleHighlight.SetToColor(0);
            m_CreateToggleTabBlocker.SetToColor(0);
        }
    }
}

m_으로 선언되어 있는 것들은 역시 SerializedField로 정의되어 스크립트 컴포넌트에서 연결이 되어 있습니다.

즉, START WITH LOBBY 버튼이 클릭되면, 연결되어 있는 각 오브젝트를 보여주고, 숨기고, 색을 설정하는 작업을 하게 됩니다.

프로젝트 구조만 간단히 알아보려고 했으니 버튼은 여기까지만 하고, 다른 씬으로 넘어가보겠습니다.

CharSelect Scene

게임 방에 참여하면 캐릭터를 고르게 됩니다.

모든 플레이어가 캐릭터를 고르고 READY! 버튼을 누르면 게임이 시작됩니다.

BossRoom Scene

테스트 플레이 할 때 마음대로 게임을 설정할 수 있는 Debug Cheat 팝업과 게임 설명 팝업이 나옵니다. 이 팝업을 잠시 꺼보면 게임의 맵이 보입니다.

BossRoom에는 특이한 점이 하나 있는데, 최상위 게임오브젝트가 하나인 다른 씬들과는 다르게 총 4개의 최상위 게임 오브젝트로 이루어져 있다는 점입니다.

그 이유는 하나처럼 보이는 던전 맵이 총 세 부분으로 나누어져 있기 때문인데,

플레이어들이 게임에 입장하면 가장 처음 스폰되는 Entrance, 문을 열고 들어가면 나오는 Transition, 보스가 등장하는 BossRoom으로 구성됩니다.

이들이 왜 구분되어 있고, 어떻게 하나처럼 유기적으로 동작하는지는 나중에 Transition 방식을 살펴보는 글에서 자세히 적겠습니다.

PostGame Scene

게임이 끝나면 게임 결과를 알려주고 메인 메뉴로 나가거나 다시 게임할 수 있게 하는 씬입니다.

이렇게 게임 진행 순서에 따라 씬을 정리해보았습니다.

다음 글에서는 Scripts 폴더를 살펴보겠습니다.

유니티로 멀티플레이를 처음 구현해보는 사람에게는 교과서같은 프로젝트입니다.

유니티를 공부할 때 Docs나 강의, 책을 보고 공부하는 것도 좋지만, 가끔은 이렇게 잘 만들어진 소스코드 전체를 확인하면서 흐름을 잡아가는 것도 좋아 보입니다.

이 보스룸 프로젝트를 분석해 도움이 될 만하거나 흥미로운 지점들을 계속해서 써내려 갈 예정인데, 이 포스팅에서는 프로젝트의 가장 기본이 되는 구조부터 뜯어보겠습니다.

글을 읽기 전에 실제로 게임을 한 판 하고 오시면 이해에 도움이 됩니다. 2P 이상 참여해야 플레이가 가능합니다. (한 명이 버튼 누르고 문 열어줄 때 나머지 한 명이 문을 통과해야 함)

Assets 폴더

Assets 폴더는 씬, 개발자가 작성한 소스코드, 프리팹이 모두 모여 있는 폴더입니다. 유니티 개발을 하면 대부분의 작업은 이 Assets 폴더 안에서 하게 됩니다.

전체 파일의 구조는 아래와 같지만, 너무 방대하니 조금씩 잘라서 설명하겠습니다.

.
├── Animations
│   └── UI
├── Fonts
├── GameData
│   ├── Action
│   │   ├── Archer
│   │   ├── Boss
│   │   ├── General
│   │   ├── Imp
│   │   ├── Mage
│   │   ├── Rogue
│   │   ├── Tank
│   │   └── VandalImp
│   ├── Avatars
│   ├── Character
│   │   ├── Archer
│   │   ├── Imp
│   │   ├── ImpBoss
│   │   ├── Mage
│   │   ├── Rogue
│   │   ├── Tank
│   │   └── VandalImp
│   ├── Collections
│   ├── Game
│   │   ├── EnemySpawner
│   │   └── SpawnedEnemy
│   ├── GameEvents
│   ├── Shared
│   ├── Systems
│   ├── Transforms
│   └── UI
├── Material
│   ├── Characters
│   │   └── Toon
│   └── Dungeon
├── Models
│   ├── Animated
│   └── Animation Controllers
├── Prefabs
│   ├── Actions
│   ├── CharGFX
│   │   ├── CharacterGraphics
│   │   │   └── CharacterSelect
│   │   └── Head
│   ├── Character
│   ├── Dungeon
│   │   └── Dungeon Pieces
│   │       ├── animated
│   │       ├── crystal
│   │       ├── pillar
│   │       └── pots
│   ├── Game
│   │   └── StaticNetworkObjects
│   ├── GameCam
│   ├── Menus
│   ├── State
│   └── UI
├── Scenes
│   ├── BossRoom
│   └── PostGame
├── Scripts
│   ├── ApplicationLifecycle
│   │   └── Messages
│   ├── Audio
│   ├── CameraController
│   ├── Editor
│   │   └── Readme
│   ├── Gameplay
│   │   ├── Action
│   │   ├── Configuration
│   │   ├── ConnectionManagement
│   │   ├── DebugCheats
│   │   ├── GameState
│   │   ├── GameplayObjects
│   │   │   ├── AnimationCallbacks
│   │   │   ├── Audio
│   │   │   ├── Character
│   │   │   │   └── AI
│   │   │   └── RuntimeDataContainers
│   │   ├── Input
│   │   ├── Messages
│   │   └── UI
│   │       └── Lobby
│   ├── Infrastructure
│   │   ├── PubSub
│   │   └── ScriptableObjectArchitecture
│   │       └── Editor
│   ├── Navigation
│   ├── UnityServices
│   │   ├── Auth
│   │   ├── Infrastructure
│   │   │   └── Messages
│   │   └── Lobbies
│   │       └── Messages
│   ├── Utils
│   │   └── NetworkOverlay
│   └── VisualEffects
├── Shaders
├── Sounds
│   ├── Character
│   │   ├── Archer
│   │   ├── Boss
│   │   ├── Imp
│   │   ├── Mage
│   │   ├── Rogue
│   │   ├── Shared
│   │   └── Tank
│   ├── Env
│   └── Music
├── StreamingAssets
├── Tests
│   └── Runtime
├── TextMesh Pro
│   ├── Documentation
│   ├── Fonts
│   ├── Resources
│   │   ├── Fonts & Materials
│   │   ├── Sprite Assets
│   │   └── Style Sheets
│   ├── Shaders
│   └── Sprites
├── Textures
│   ├── Characters
│   ├── Environment
│   └── UI
│       └── Unity
├── URP
│   └── Mobile
└── VFX
    ├── Materials
    ├── Meshes
    ├── Prefabs
    │   ├── Archer
    │   ├── Boss
    │   ├── Caster
    │   ├── Environment
    │   ├── Imp
    │   │   └── Throw_bomb
    │   ├── Rogue
    │   ├── Shared Hero FX
    │   ├── Tank
    │   └── UI
    ├── Shaders
    └── Textures

다른 걸 다 잘라내고 Assets 하위에 위치한 폴더만 살펴보면, Assets 폴더의 하위는 아래와 같은 서브 폴더들로 구성되어 있습니다.

.
├── Animations
├── Fonts
├── GameData
├── Material
├── Models
├── Prefabs
├── Scenes
├── Scripts
├── Shaders
├── Sounds
├── StreamingAssets
├── Tests
├── TextMesh Pro
├── Textures
├── URP
└── VFX

대중적인 구조에서 크게 벗어나지 않는 파일 구조를 가지고 있습니다. 게임 씬 저장을 위한 Scenes, 스크립트 저장을 위한 Scripts, 프리팹 저장을 위한 Prefabs, 등등 ... 익숙한 구조입니다.

TextMesh Pro가 익숙하지 않으시다면, 기존의 유니티 UI 텍스트를 완벽히 대체하며 더 고도화된 기능을 제공하는 플러그인이고, (원래는 유니티 에셋 스토어에서 유료로 팔고 있던 에셋인데 유니티에서 인수해 무료로 제공하게 되었다고 합니다.)

이어지는 글에서 프로젝트 구조를 하나하나 뜯어 살펴보겠습니다.

웹 프론트엔드 개발 후 vercel로 배포를 하면서 버튼 하나로 배포 되는 건 진짜 신세계다 생각하고 있었는데, 몇 달 전 서버에서는 heroku가 간편한 배포를 지원하고 있다는 걸 알게 되었다.

https://www.heroku.com

다양하게 커스텀하기에는 한계가 있지만 간편하게 서버를 띄우고 싶을 땐 꽤 유용하다. 무려 https로 배포해준다.

헤로쿠 가입

만약 헤로쿠가 처음이라면 여기로 들어가서 가입하면 된다.

앱 생성

바로 create new app을 눌러 앱을 생성한다. 만약 계정에 앱이 하나도 없는 상태라면 조금 더 큰 버튼으로 떴던 기억이 난다. 어떻게 생겼든 create new app이라고 쓰인 버튼을 눌러주면 된다.

앱 이름을 정하고 지역 설정을 해준다. 지역은 United States, Europe 두 개밖에 없어서 나는 미국으로 해줬다.

그 후 바로 Create app 버튼을 눌러준다.

무료계정에서 앱은 최대 100개까지 생성할 수 있다고 한다. (비인증 시 5개)

프로젝트 연결 (깃허브)

프로젝트 파일이 깃허브에 있다면 바로 연결해줄 수 있다. 가장 간편한 방법이다.

Deploy 탭에서 Deployment method를 보면 세 가지 옵션이 있는데, 그 중 GitHub을 클릭해준다.

Connect to GitHub 쪽을 보면 계정을 선택할 수 있다. 개인계정/organization 모두 선택 가능하다. 만약 원하는 organization이 보이지 않는다면, 아래 Ensure Heroku Dashboard has team access 버튼을 눌러 권한을 부여해준다.

버튼이 만약 Grant라면 내가 organization의 오너라 바로 권한을 부여할 수 있는 경우고, Request라면 나는 member라서 organization의 오너에게 대신 권한 허용 알림이 가게 된다.

권한 허용을 해주고 나면 해당 오가니제이션이 헤로쿠에서 성공적으로 읽힐 것이다.

원하는 오가니제이션 혹은 개인 계정을 선택해주고 서버 코드가 있는 repo-name을 검색한다.

레포를 찾았다면 Connect를 눌러준다.

성공적으로 연결되면 여러 설정을 할 수 있게 되는데, develop 브랜치에 머지가 되면 자동으로 배포하는 옵션 (Automatic deploys)를 설정해주었다.

만약 github action 등으로 수행되는 CI 단계가 있다면 Wait for CI to pass before deploy 설정을 꼭 해주는 것이 좋다.

Manual deploy에서 특정 브랜치를 선택해 즉시 배포할 수도 있다.

프로젝트 연결 (CLI)

만약 코드가 GitHub에 있지 않다면, CLI로 연결해줄 수 있다.

Deployment method에서 Heroku Git을 선택하면 방법이 안내되어 있다.

우선 Herocu CLI를 설치해줘야 한다.

맥을 쓴다면 terminal에서 brew tap heroku/brew && brew install heroku 명령어로 설치할 수 있다.

설치가 되었다면 terminal에서 heroku 로그인을 해주어야 한다. heroku login을 해서 시키는대로 하면 로그인이 된다. (브라우저에서 로그인을 시킬 것이다)

그 후 terminal에서 코드가 있는 곳으로 이동해서 heroku git:remote -a [앱 이름]을 입력해준다. 여기서 [앱 이름]은 우리가 헤로쿠에서 만든 앱 이름이다. git으로 관리되고 있는 로컬의 코드를 헤로쿠 깃(리모트)와 연결하는 과정이다.

만약 로컬에 코드가 없다면 위 명령어 대신 heroku git:clone -a [앱 이름]을 해주면 된다. 클론을 받아왔다면 cd [앱 이름] 명령어로 해당 폴더로 이동한다.

그런 후에는 헤로쿠 깃으로 푸시해주면 바로 빌드가 되는데, 푸시는 git push heroku master로 간단히 할 수 있다. 만약 현재 로컬의 브랜치가 master가 아니라면 에러가 뜰 텐데, 그러면 git push heroku [현재 브랜치 이름]:master 명령어를 써주면 된다. 예를 들어 develop 브랜치에서 작업하고 있다면, git push heroku develop:mater 이런 식이다.

그럼 자동으로 빌드가 시작된다. 빌드에서 에러가 나도 괜찮다. 아직 자잘한 설정을 안 맞춰준 탓이다.

만약 여기까지 했는데 빌드가 되고 API 호출도 성공적으로 된다면 나는 정말 운 좋은 사람이다 세 번 외치고 뒤로가기 버튼을 누르면 된다.

Procfile 생성

Procfile은 헤로쿠 서버가 시작될 때 수행할 명령을 적어주는 파일이다. 루트에 파일을 만들어주면 된다.

상황에 맞게 web:node dist나 web:npm start를 해주면 된다.

뒤에서 node BuildPack을 추가해 줄 텐데, 빌드팩이 있으면 Procfile은 없어도 된다고 하니 넘어가도 된다.

Package.json 확인

헤로쿠 서버는 typescript를 처리하지 못한다. 그래서 tsc로 javascript 전환 후 dist 파일을 node로 컴파일 해야 한다.

// package.json

"scripts": {
  "start": "node dist/server.js",
  "build": "tsc",
  "postinstall": "npm run build",
},

나는 이 조합을 선호한다.

빌드 시에 tsc로 javascript로 전환하고, start 시에 node dist/server.js를 하는 방법이다. dist나 server.js는 자신의 프로젝트에서 설정한 폴더/파일 이름을 넣어주면 된다.

postinstall이 중요한데, postinstall을 생략하면 build 후에 멈춰버리는 현상이 생긴다. tsc를 실행하고 아무것도 실행되지 않는 상태로 빌드가 얼어버리는 것이다. 꼭 postinstall 설정을 해주자.

(나는 프로젝트에서 yarn을 쓰고 있는데, 이상하게 yarn은 또 안 될 때가 있어서 heroku 서버에서는 npm run build를 해주고 있다.)

그 외에 엔진 버전(node, yarn 등)을 명시하라는 에러가 날 수도 있는데, 그럴 때는 package.json 최상단에 아래 코드를 추가해준다. 프로젝트 세팅에서 사용하는 버전에 맞게 써주면 된다. 대부분은 아래와 같을 것이다.

// package.json

"engines": {
  "node": "16.x"
  "yarn": "1.x"
},

Buildpack 추가

Node를 쓰는 프로젝트는 빌드팩을 추가해주어야 한다. 터미널 해당 프로젝트 폴더 경로에서 heroku buildpacks:set heroku/nodejs로 추가해줄 수 있다.

혹은 경로를 찾아가지 않고도 -a [앱 이름] 옵션을 줘도 된다.

추가된 노드 빌드팩은 헤로쿠 대시보드의 세팅에서 확인할 수 있다.

환경 변수 등록

만약 프로젝트가 환경변수를 사용하고 있다면 (DB 정보 등) 헤로쿠에 이 정보도 등록해주어야 한다.

보통은 .env 파일을 gitignore 해 사용하지만, 헤로쿠에는 안타깝게도 파일을 올릴 수 없다. (ec2와 가장 크게 다른 점이다)

헤로쿠는 매번 푸시가 될 때마다 모든 파일을 덮어쓰기 때문에 서버 컴퓨터에 접속해 .env 파일을 등록했다고 하더라도 다음 빌드에서 삭제될 것이다.

따라서 사이트에서 하나하나 등록해주어야 한다. (구글에 찾아보면 다른 방법도 많았는데, 뭔갈 많이 설치해야 하고 잘 안 되는 경우도 많아서 나는 사이트에서 등록해주는 편이 가장 속 편했다)

헤로쿠 사이트 > 대시보드 > 우리가 쓰는 앱으로 들어가면, Setting에서 Config Vars 항목을 볼 수 있다.

여기가 바로 환경변수를 등록해주는 곳이다.

Reveal Config Vars를 눌러서 key와 value를 각각 등록해주면 된다.

빌드 확인

여기까지 따라왔다면 빌드를 한 번 해보자. 헤로쿠 깃의 브랜치로 푸시하면 바로 빌드가 진행된다. git push heroku [현재 브랜치 이름]:master 명령어로 푸시할 수 있다.

빌드가 성공하면 빌드 성공이라는 메시지와 함께 배포된 링크도 함께 나온다.

로그 확인하기

API 호출 로그는 heroku logs --tail -a [앱 이름]으로 확인해 볼 수 있다. 만약 terminal에서 해당 프로젝트 폴더 위치에 있다면 -a [앱 이름]을 생략하고 heroku logs --tail만 입력해도 된다.

이런 식으로 로그가 들어온다.

팁) 계정에서 빌드 가능한 횟수를 초과했다는 에러 해결 방법

CLI로 빌드를 열심히 돌리다 보면 갑자기 계정에서 빌드 가능한 횟수를 초과했다는 에러가 나기도 한다.

당황하지 말고, 이전에 실행했던 빌드가 끝나지 않은 상태로 갇혀있거나 아직 빌드 진행 중인 경우에 이런 에러가 뜬다.

heroku builds:cancel -a [앱 이름]으로 이전에 실행된 빌드를 강제 종료할 수 있다.

Unity로 개발하던 중에 iOS의 HealthKit과 연동해 기기 사용자의 건강 정보를 읽고 업데이트 하고 싶었는데, 한글 자료는 물론 외국 자료도 마땅치 않더라구요. 그래서 작성하는 글입니다.

기본적으로 Unity 프로젝트에 Swift 코드를 임베드 하는 방법을 설명하고, HealthKit 연동 방법까지 공유합니다.

0️⃣ Unity와 iOS 네이티브 프레임워크 연동

희망편 - 주류 프레임워크

네이티브 alert 팝업, 갤러리/카메라 권한 사용을 위한 UIImagePickerController와 그 delegate 등은 워낙 Unity에서도 많이 사용되는 네이티브 프레임워크라 에셋 스토어에 무료 또는 아주 싼 가격에 플러그인이 공유 되고 있습니다. 이런 플러그인들은 비교적 최근까지 잘 관리가 되어 있고, 사용자 층이 두터워 커뮤니티 내에서 질문과 응답이 활발하게 오가기 때문에 디버깅도 간편합니다.

간단히 다운 받아서 시키는대로 설정한 후 시키는대로 코드를 쓰면 어려운 단계 없이 바로 동작합니다.

unity와 iOS 네이티브 프레임워크 연동 희망편입니다.

절망편 - 비주류 프레임워크

하지만 내가 쓰려 하는 프레임워크가 이렇게 자주 쓰이는 프레임워크가 아니라면? 제목에도 있는 HealthKit 역시 swift로 개발하는 iOS 네이티브 내에서도, 물론 Unity에서 iOS 앱 최적화를 할 때도 비주류에 속합니다. 사실 비주류라는 용어도 부끄러울 만큼 google에 그 어떤 자료도 나오지 않습니다.

사진에 캡쳐되어 있는 게 의미있는 검색 결과의 전부입니다.

그나마 BEHealthKit이라는 플러그인이 하나 나오긴 하는데, 1 seat 당 40달러라는 무서운 가격을 가지고 있고 공식적으로 제공하는 docs가 가격에 비해 친절하지 않았습니다.

결국 5만원을 지불하고도 stackoverflow와 기타 개발 커뮤니티를 전전하며 디버깅 해야 할 상황이 올 것 같았습니다.

결정적으로 BEHealthKit을 사용하다 stackoverflow에 질문한 이렇게 긴 글에

답변이 딱 하나 달렸고, 그 마저도 2줄짜리에, 질문자의 댓글이 Yes, But...으로 시작하는 절망적인 케이스였습니다.

그렇다고 Unity에서 HealthKit 연동을 시도한 흔적(그 흔한 가이드 블로그글, 스택오버플로우 질문, 유니티 포럼 질문)이 많은 편도 아니었습니다. 다 합쳐서 겨우 다섯 손가락을 채울 정도였습니다.

이게 비주류의 슬픔인가?

결국 접근 방법을 바꾸기로 했습니다.

5만원을 주고도 오랫동안 헤매야 할 미래가 눈앞에 훤히 보였고, 그렇게 고생해봤자 HealthKit 연동 이외에는 쓸 구석이 없는 플러그인이라면 과감히 포기하기로 했습니다. 기왕 고생할 거 제대로 고생해서 HealthKit 뿐만 아니라 다른 Swift 코드도 쓰고 싶을 때 언제든지 써서 임베드 할 수 있는 확장성 있는 기반을 다져놓자 다짐했습니다.

1️⃣ 유니티 프로젝트에 Swift 코드 임베드 하기

Swift로 iOS 네이티브 앱 개발을 할 때 HealthKit을 써본 적이 있기 때문에 Swift 코드로는 HealthKit 연동이 매우 간단하다는 걸 알고 있었습니다.

그럼 그냥 Unity 프로젝트에서 Swift가 해석되게 하면 되는 거 아닌가? 라는 바보같고도 단순한 질문에서 시작되었습니다. 말처럼 간단하지 않았거든요 ㅎ

+) 왜 유니티에서 Swift 코드를 쓰지 못할까?

이 질문은 왜 unity에서 네이티브 최적화를 할 때는 objective-C를 쓸까?라는 질문의 연장선에 있습니다.

iOS 개발을 조금이라도 찍먹해본 사람은 다 알고 있듯 Objective-C는 이제 레거시 취급을 받고 있고, 예전에 개발되어 그나마 남아있는 Objective-C 코드들도 다 Swift로 리팩토링 하는 추세입니다.

그런데도 왜 유니티와 iOS 키워드로 구글에 검색하면 다 Objective-C 코드만 나오는지 궁금했습니다. 1-2년 내에 쓰인 비교적 최근 글들임에도 불구하고요.

(아래는 꼭 iOS 플러그인을 만드는 데 Objective-C를 써도 괜찮을 경우 참고할 만한 괜찮은 자료들입니다) [YouTube] Unity3d iOS Plugins - How To Create An iOS Plugin With Unity3d ? [YouTube] Unity3d iOS Plugins - How To Call Native iOS Alerts From Unity ? [Medium] Integrating native iOS code into Unity

유니티(C#)은 스위프트와 바로 소통하지 못합니다. 그래서 우리는 Objective-C를 브릿지로 이용해야 합니다.

C#은 Objective-C와 소통할 수 있고, Swift 역시 Objective-C로 소통할 수 있으니 C#과 Swift 사이에 Objective-C라는 통역관을 하나 두는 것과 같습니다.

따라서 Unity에서는 Swift를 아예 쓰지 못한다라기보다는 Objective-C를 거치지 않고는 쓰지 못한다라는 표현이 더 정확합니다.

이 점을 고려하며 Swift 함수를 Unity에서 실행시키는 방법에는 몇 가지가 있습니다. 그 중 가장 간편하게 사용할 수 있었던 방법을 몇 가지 소개하겠습니다.

1. Swift Package -> Framework -> Unity Plugin

유니티 공식문서와 더불어 어느 한 유튜브 영상에서 설명하고 있는 방법입니다.

1) Xcode에서 Package 생성

Xcode에서 상단바 File > New > Package를 눌러 새로운 패키지를 생성합니다.

원하는 위치에 원하는 이름으로 패키지를 생성합니다.

2) 보일러 플레이트 정리

처음 Package가 만들어지면 크게 Source 폴더, Tests 폴더가 생길 것입니다. 하지만, Unity에서 빌드할 때는 패키지를 프레임워크로 추출해서 사용할 것이기 때문에 test 코드는 아예 실행되지 않습니다. 따라서 Test 코드 보일러 플레이트를 삭제해주도록 합시다. (사진에서 드래그 된 부분을 모두 삭제해주면 됩니다)

마찬가지로, Source 폴더를 보면 패키지와 같은 이름의 파일이 하나 생성되어 있는데, 이 보일러 플레이트 코드도 지워줍니다. (드래그 된 부분을 지워주면 됩니다)

이렇게 두 파일을 각각 class, struct가 정의된 상태로 만들면 본격적으로 코드 쓸 준비가 끝납니다.

3) 메서드 정의 파일 구현

JS로 리액트 개발을 할 때 index.js 파일과 비슷한 역할을 한다고 생각하면 좋습니다. 해당 패키지 내에 어떤 메서드가 있는지 정의하고 라우팅 하는 역할을 합니다.

원하는 이름으로 파일을 하나 생성해줍니다.

그리고 메서드를 하나 만들어 볼게요. 이 메서드는 유니티 프로젝트의 C# 코드에서 바로 호출할 메서드이므로, 이름에 Swift, NativeiOS 등을 포함해 이 메서드는 유니티 프로젝트 밖에 있음을 암시하는 이름이면 좋습니다.

그리고 별다른 로직 없이 바로 Swift Package Source 파일 내에 정의된 메서드를 호출해 줍니다. 실제 로직은 NativeiOSCode, 즉 패키지 이름으로 생성된 파일에서 구현합니다.

위 코드를 보면 익숙하지 않은 부분이 한 줄 있을 텐데요, @_cdecl()은 C 베이스 코드에서 Swift 함수를 호출할 때 사용하는 비공식 attribute입니다. 공식화 하자는 논의는 꽤 있었으나, 플랫폼 호환성이나 안정성 면에서 아직은 공식화가 되지 않고 있습니다. bridging-header를 사용해 C 베이스 언어들과 소통하는 방법이 꾸준히 추천되고 있는 듯합니다.

어쨌든, @_cdecl("메서드 이름") 형태로 메서드 위에 적어주면 C 베이스 언어에서 Swift 코드와 소통할 수 있게 됩니다. 그래서 위 코드 이미지에서는 @_cdecl("NativeiOSCode_runNativeCode")로 적어주었습니다.

하지만 위에서도 잠깐 언급했듯, 컴파일 단계에서 안정성을 보장하지는 않습니다. (라고 하지만 스위프트 포럼을 보니 심각한 문제가 일어난 적은 없어 보입니다)

4) 실제 로직 메서드 구현

메서드 정의 파일에서 NativeiOSCode_runNativeCode 메서드를 만들고 NativeiOSCode.runNativeCode()로 어떤 메서드를 호출해주었는데요, 여기까지 하면 에러가 난 상태일 겁니다. 바로 해당 메서드가 구현이 되지 않은 상태이기 때문입니다.

다시 NativeiOSCode 파일(패키지 이름으로 생성된 파일)로 가 runNativeCode()라는 함수를 구현해줍니다.

간단히 콘솔에 프린트만 하는 코드를 작성했습니다.

물론, 매개변수가 있는 경우도 정상적으로 동작합니다.

5) xcodeproj 파일 생성

이 상태로 Finder에서 폴더에 들어가보면 xcodeproj 파일이 없는 걸 볼 수 있습니다. 간단한 명령어로 하나 만들어 줄 수 있습니다.

터미널에서 우리가 만든 Swift Package가 있는 폴더로 가 아래 명령어를 입력합니다. swift package generate-xcodeproj --skip-extra-files

명령어가 성공적으로 실행되면 해당 폴더에 project 파일이 생성됩니다.

6) 패키지 빌드

xcodeproj 파일을 생성하고 나면 패키지를 빌드해 프레임워크 파일을 추출할 수 있습니다. xcodebuild -project [패키지이름].xcodeproj -scheme [패키지이름]-Package -configuration Release -sdk iphoneos CONFIGURATION_BUILD_DIR=.

하나 하나 뜯어보면 -project [패키지이름].xcodeproj: [패키지이름] 프로젝트 파일에 대해 -scheme [패키지이름]-Package: 그 중 [패키지이름] 스키마를 (한 프로젝트 파일에 여러 스키마가 존재할 수 있습니다) -configuration Release: 릴리즈 모드로 -sdk iphoneos: iPhoneOS(iOS)에서 사용할 sdk를 CONFIGURATION_BUILD_DIR=.: 현재 폴더로 빌드한다.

[패키지이름] 프로젝트 파일 중 [패키지이름] 스키마를 릴리즈 모드로 iPhoneOS(iOS)에서 사용할 sdk를 현재 폴더에 빌드한다. 라는 뜻의 명령어가 됩니다.

명령어가 성공적으로 실행되면, framework 파일과 dSYM 파일이 생성됩니다.

이 중 framework 파일이 우리가 유니티 프로젝트에서 플러그인으로 사용할 파일이 됩니다.

7) Unity로 프레임워크 import

Unity 프로젝트의 Assets 폴더 안에 Plugins > iOS 폴더를 만들고, 그 안에 framework 파일을 import 해줍니다. 간단히 드래그 앤 드롭 해주면 됩니다.

그 후 해당 framework 파일의 inspector로 가서 Platform settings > Add to Embedded Binaries 체크박스를 체크해주세요. 그 후 Apply를 눌러 적용시켜줍니다.

8) Unity C# Script에서 Swift 메서드 호출

원하는 Script에서 Swift 메서드를 호출해줍시다.

우선 외부 메서드를 우리가 script에서 쓸 수 있게 import 해주는 과정이 필요합니다.

using System.Runtime.InteropServices;

public class Showcase : MonoBehaviour 
{
    #if UNITY_IOS
        [DllImport("__Internal")]
        private static extern void NativeiOSCode_runNativeCode();
    #endif

    void Start()
    {
    }

    // (하략)
}

코드를 조금 뜯어보자면, DllImport()는 외부 플랫폼의 플러그인을 동적으로 불러올 때 사용합니다. 괄호 안에 플러그인 이름을 적어주면 됩니다. 하지만 우리 코드는 DllImport("__Internal")로 쓰여있는 걸 볼 수 있는데요, 여기서 __internal은 정적으로 연결된 네이티브 코드를 쓸 때 사용합니다. (더 자세한 설명은 유니티 공식문서에서 확인할 수 있습니다)

Note that when using Javascript you will need to use the following syntax, where DLLName is the name of the plug-in you have written, or “__Internal” if you are writing statically linked native code:

@DllImport (DLLName)
static private function FooPluginFunction () : float {};

그리고 함수 선언부의 extern 키워드는 해당 메서드가 유니티 프로젝트의 바깥에 있을 때, 즉 외부 플러그인을 불러올 때 사용합니다.

iOS 네이티브 플러그인은 실제 디바이스 배포 중에만 호출할 수 있기 때문에 이 코드는 특정 플랫폼에서만 실행될 수 있도록 래핑해주는 단계가 필요합니다. 그래서 우리는 코드를 #if UNITY_IOS로 감싸주었습니다.

그 후에는 코드를 바로 호출하기보다 내부에서 처리로직을 한 번 더 두어 안전한 호출을 해봅시다.

public class Showcase : MonoBehaviour 
{
    void Start()
    {
        runNativeCode();
    }

    private void runNativeCode()
    {
        #if UNITY_IOS
            NativeiOSCode_runNativeCode();
        #else
            Debug.Log("No iOS Device Found");
        #endif
    }
}

유니티의 이벤트 함수인 Start()에서 runNativeCode()를 불러 스크립트가 실행될 때 실행되도록 해주었고, 실제 runNativeCode() 안에는 별다른 로직 없이 플랫폼 래핑과 분기처리만 해주었습니다.

❗️주의: 플랫폼 래핑 코드를 Start() 안에 쓰면 NoEntry 에러가 나니 꼭 runNativeCode() 안에서 해주어야 합니다.

여기까지 코드를 작성했다면, 전체 코드는 다음과 같습니다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System.Runtime.InteropServices;

public class Showcase : MonoBehaviour 
{
    #if UNITY_IOS
        [DllImport("__Internal")]
        private static extern void NativeiOSCode_runNativeCode();
    #endif

    void Start()
    {
        runNativeCode();
    }

    private void runNativeCode()
    {
        #if UNITY_IOS
            NativeiOSCode_runNativeCode();
        #else
            Debug.Log("No iOS Device Found");
        #endif
    }
}

9) Unity 빌드

다음은 Unity에서 iOS 플랫폼으로 빌드를 해주면 됩니다. (컴퓨터에 Xcode가 설치되어 있어야 합니다)

만약 Xcode에서 signing 설정이 안 되어 있다면 로그인 후 프로젝트 세팅에서 Signing & Capabilities 설정을 해줍니다.

설정 후 실행시켜보면 우리가 Swift로 쓴 함수가 실행돼 로그가 잘 찍히고 있는 모습을 확인할 수 있습니다.

2. Swift Framework -> Bridge -> Unity Plugin

두 번째 방법은 이 미디엄에서 설명하고 있는 방법입니다.

1) Xcode에서 iOS Framework 생성

새로운 프로젝트를 생성해봅시다. iOS > Framework를 클릭하고 마음에 드는 이름으로 프로젝트를 생성합니다.

2) Bridge 생성

자동으로 Source와 Products가 생성되어 있을 텐데요, (최근 Xcode 업데이트로 Products 파일이 생략되었을 수 있으나 중요하지 않습니다. 없는 상태로 계속 진행하셔도 됩니다.) Source 폴더에서 이미 생성되어 있는 [프레임워크이름].swift 파일 이외에 [프레임워크이름]Bridge.mm 파일과 [프레임워크이름]-Bridging-Header.h 파일을 생성해주어야 합니다.

[프레임워크이름]Bridge.mm 파일은 조금 헷갈릴 수 있는데, cmd + n 혹은 New > File을 누른 후 Objective-C 파일을 선택하면 .m 파일이 생성됩니다. 그럼 파일 이름 변경을 눌러 .mm 파일로 바꿔주면 됩니다.

.mm 파일은 Objective-C를 컴파일 할 때 C++로 컴파일 되고, .m 파일은 C로 컴파일 된다는 차이가 있습니다. (위키피디아 참고)

3) Swift 메서드 작성

위에서 소스 파일을 세 개 만들었는데요, 순서대로 코드를 작성해보겠습니다.

[.swift 파일] - 실제 로직 [프레임워크이름].swift 파일에 원하는 로직의 메서드를 작성합니다.

import Foundation

@objc public class UnityPlugin : NSObject {

    @objc public static let shared = UnityPlugin()
    @objc public func AddTwoNumber(a:Int,b:Int ) -> Int {

        let result = a+b;
        return result;
    }
}

싱글톤 객체로 선언하였고, 내부 swift 로직이 아닌 objc-briding-header에 의해 읽힐 메서드이니 @objc 키워드를 붙여주었습니다.

[.mm 파일] - 유니티와 소통할 수 있게 하는 브릿지 .mm 파일은 이렇게 작성해주었습니다.

#import <Foundation/Foundation.h>
#include "UnityFramework/UnityFramework-Swift.h"

extern "C" {

#pragma mark - Functions

    int _addTwoNumberInIOS(int a , int b) {

        int result = [[UnityPlugin shared] AddTwoNumberWithA:(a) b:(b)];
        return result;
    }
}

extern "C"는 C++ (.cpp) 또는 Objective-C++ (.mm)를 사용하여 플러그인을 실행할 경우 네임 맹글링 문제를 피하기 위해 함수를 C링크에 선언하는 방법입니다.

그 후 함수 이름을 선언하고, 싱글톤으로 선언된 .swift 파일에서 만들었던 메서드를 불러주었습니다. 여기서 매개변수와 리턴값은 유니티의 호출 코드와 소통합니다.

[.h 파일] - 헤더 파일 .h 파일은 생성하면 코드가 자동으로 입력되어 있을 텐데요, 아래처럼 잘 생성이 되었다면 건들지 않아도 됩니다.

#ifndef [프레임워크이름]_Bridging_Header_h
#define [프레임워크이름]_Bridging_Header_h


#endif /* [프레임워크이름]_Bridging_Header_h */

4) 유니티 프로젝트에 플러그인 세팅

유니티 프로젝트의 Assets 폴더 안에 Plugins라는 폴더를 생성합니다. 그 안에 iOS 폴더를 생성하고, Xcode에서 작성한 Source 파일 전체를 해당 폴더 안으로 가져옵니다. Source 폴더 안에 우리가 Xcode에서 만든 3개의 파일이 있는 상태여야 합니다. 그 후 Editor 폴더를 추가하고, SwiftPostProcess.cs 파일을 생성해줍니다.

5) SwiftPostProcess.cs 설정

위에서 생성한 SwiftPostProcess.cs 파일로 들어갑니다.

그리고 그 파일에 아래 코드를 복사해서 붙여넣어주세요. [프레임워크이름] 부분을 아까 Xcode에서 생성한 자신의 프레임워크 이름으로 바꿔주면 됩니다. 제 경우에는 UnityIosPlugin입니다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using UnityEditor.Callbacks;
using UnityEditor.iOS.Xcode;
using System.Diagnostics;

using System.IO;
using System.Linq;

public static class SwiftPostProcess
{

    [PostProcessBuild]
    public static void OnPostProcessBuild(BuildTarget buildTarget, string buildPath)
    {
        if (buildTarget == BuildTarget.iOS)
        {
            var projPath = buildPath + "/Unity-Iphone.xcodeproj/project.pbxproj";
            var proj = new PBXProject();
            proj.ReadFromFile(projPath);

            var targetGuid = proj.TargetGuidByName(PBXProject.GetUnityTestTargetName());

            proj.SetBuildProperty(targetGuid, "ENABLE_BITCODE", "NO");

            proj.SetBuildProperty(targetGuid, "SWIFT_OBJC_BRIDGING_HEADER", "Libraries/Plugins/iOS/[프레임워크이름]/Source/UnityPlugin-Bridging-Header.h");

            proj.SetBuildProperty(targetGuid, "SWIFT_OBJC_INTERFACE_HEADER_NAME", "[프레임워크이름]-Swift.h");

            proj.AddBuildProperty(targetGuid, "LD_RUNPATH_SEARCH_PATHS", "@executable_path/Frameworks $(PROJECT_DIR)/lib/$(CONFIGURATION) $(inherited)");
            proj.AddBuildProperty(targetGuid, "FRAMERWORK_SEARCH_PATHS",
                "$(inherited) $(PROJECT_DIR) $(PROJECT_DIR)/Frameworks");
            proj.AddBuildProperty(targetGuid, "ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES", "YES");
            proj.AddBuildProperty(targetGuid, "DYLIB_INSTALL_NAME_BASE", "@rpath");
            proj.AddBuildProperty(targetGuid, "LD_DYLIB_INSTALL_NAME",
                "@executable_path/../Frameworks/$(EXECUTABLE_PATH)");
            proj.AddBuildProperty(targetGuid, "DEFINES_MODULE", "YES");
            proj.AddBuildProperty(targetGuid, "SWIFT_VERSION", "4.0");
            proj.AddBuildProperty(targetGuid, "COREML_CODEGEN_LANGUAGE", "Swift");

            proj.WriteToFile(projPath);
        }
    }

}

이 파일이 없으면 매번 iOS 빌드를 하고 난 후에 pbxproj(프로젝트 세팅 파일)에 들어가서 빌드 프로퍼티를 수정, 생성 해줘야 하는데요, PostProcessBuild를 통해 빌드가 끝나면 자동으로 빌드 프로퍼티를 입력해주는 역할을 합니다.

이 파일에서 objc bridging header의 위치를 가리켜주었고, 제대로 실행될 수 있게 해주었습니다.

혹 권한이라든지 프로젝트 세팅 파일에 더 설정해주어야 할 내용이 생긴다면 proj.WriteToFile(projPath); 위에 적어주면 됩니다.

6) Unity C# Script에서 Swift 메서드 호출

이제 원하는 스크립트 파일에서 스위프트 함수를 불러주기만 하면 됩니다.

패키지를 사용했던 첫번째 방법과 마찬가지로 코드를 작성해보겠습니다. 위와 같은 로직이므로 설명은 하지 않습니다.

using System.Runtime.InteropServices;
using UnityEngine;
using UnityEngine.UI;

public class PluginHelper : MonoBehaviour
{
    #if UNITY_IOS
        [DllImport("__Internal")]
        private static extern int _addTwoNumberInIOS(int a, int b);
    #endif

    void Start()
    {
        AddTwoNumber();
    }

    public void AddTwoNumber()
    {
        #if UNITY_IOS
            int result = _addTwoNumberInIOS(10, 5);
            Debug.log(result)
        #else
            Debug.Log("No iOS Device Found");
        #endif
    }
}

7) Unity 빌드

유니티에서 iOS를 하고 나면 플러그인에 우리가 만든 프레임워크가 플러그인으로 잘 들어가있는 걸 볼 수 있습니다.

Xcode에 로그도 잘 찍힙니다.

주의사항) XCode 작업 코드 빌드 전 꼭 Unity로 옮기기

Swift 코드를 수정할 일이 생기면 유니티 에디터에서는 swift 코드 수정을 못 하기 때문에 편의상 iOS 빌드가 된 후 생긴 Xcode 프로젝트 파일로 열게 될 텐데요, 여기서 소스 코드를 수정하고 나면 꼭 빌드 전 Unity 소스파일로 옮겨주어야 합니다. 그냥 빌드를 하면 Xcode 프로젝트 파일은 덮어쓰기가 되기 때문에 힘들게 쓴 코드가 다 날아가는 대참사가 날 수 있습니다. 경험담입니다.

2️⃣ Unity에서 iOS HealthKit 사용하기

여기까지 따라왔다면 Unity에서 Swift 메서드를 부를 수 있는 상태가 되었습니다. 굉장히 자유롭게 Swift 코드를 쓸 수 있는 상태가 된 겁니다.

그럼 원래 우리의 목표였던 대망의 HealthKit 연동을 해보겠습니다. 이미 Swift 연동을 해놓았으므로 Swift로 iOS 네이티브 코드를 구현하던 것과 같이 구현하면 됩니다.

전 위에서 설명한 방법 중 두번째 방법이었던 프레임워크 생성 후 소스코드를 복사하는 방법으로 구현했습니다.

프레임워크 소스코드 중 .swift 파일에 import HealthKit을 해주고 원하는 로직을 작성합니다. Swift로 HealthKit을 다루는 법은 좋은 아티클과 애플이 제공하는 데모코드가 많으므로 여기서 자세하게 다루지는 않겠습니다. 구글에 iOS HealthKit swift 키워드로 찾아보시기를 추천드립니다.

우리가 신경써줘야 할 것은 이 swift 파일에서 HealthKit을 임포트 했을 때 그걸 Unity가 알아들을 수 있냐는 부분인데, 그 설정을 SwiftPostProcess.cs 파일에서 해주면 됩니다.

파일에 아래 코드를 추가해줍니다.

var manager = new ProjectCapabilityManager(projPath, "Entitlements.entitlements", null, proj.GetUnityMainTargetGuid());
manager.AddHealthKit();
manager.WriteToFile();

Entitlement에 HealthKit을 추가해주는 방법으로, .AddHealthKit()은 유니티가 iOS와의 호환성을 위해 Capability를 쉽게 등록할 수 있도록 제공하는 메서드입니다. 만약 HealthKit이 아닌 다른 Kit을 등록하고자 할 때도 마찬가지로 manager.Add~로 쓸 수 있습니다.

이 부분이 추가된 SwiftPostProcess.cs의 전체코드는 다음과 같습니다.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using UnityEditor.Callbacks;
using UnityEditor.iOS.Xcode;
using System.Diagnostics;

using System.IO;
using System.Linq;

public static class SwiftPostProcess
{

    [PostProcessBuild]
    public static void OnPostProcessBuild(BuildTarget buildTarget, string buildPath)
    {
        if (buildTarget == BuildTarget.iOS)
        {
            var projPath = buildPath + "/Unity-Iphone.xcodeproj/project.pbxproj";
            var proj = new PBXProject();
            proj.ReadFromFile(projPath);

            var targetGuid = proj.TargetGuidByName(PBXProject.GetUnityTestTargetName());

            proj.AddFrameworkToProject(targetGuid, "HealthKit.framework", false);

            proj.SetBuildProperty(targetGuid, "ENABLE_BITCODE", "NO");

            proj.SetBuildProperty(targetGuid, "SWIFT_OBJC_BRIDGING_HEADER", "Libraries/10Etc/Plugins/iOS/EmbeddedSwift/Source/EmbeddedSwift-Bridging-Header.h");

            proj.SetBuildProperty(targetGuid, "SWIFT_OBJC_INTERFACE_HEADER_NAME", "EmbeddedSwift-Swift.h");

            proj.AddBuildProperty(targetGuid, "LD_RUNPATH_SEARCH_PATHS", "@executable_path/Frameworks $(PROJECT_DIR)/lib/$(CONFIGURATION) $(inherited)");
            proj.AddBuildProperty(targetGuid, "FRAMERWORK_SEARCH_PATHS",
                "$(inherited) $(PROJECT_DIR) $(PROJECT_DIR)/Frameworks");
            proj.AddBuildProperty(targetGuid, "ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES", "YES");
            proj.AddBuildProperty(targetGuid, "DYLIB_INSTALL_NAME_BASE", "@rpath");
            proj.AddBuildProperty(targetGuid, "LD_DYLIB_INSTALL_NAME",
                "@executable_path/../Frameworks/$(EXECUTABLE_PATH)");
            proj.AddBuildProperty(targetGuid, "DEFINES_MODULE", "YES");
            proj.AddBuildProperty(targetGuid, "SWIFT_VERSION", "4.0");
            proj.AddBuildProperty(targetGuid, "COREML_CODEGEN_LANGUAGE", "Swift");

            proj.WriteToFile(projPath);

            var manager = new ProjectCapabilityManager(projPath, "Entitlements.entitlements", null, proj.GetUnityMainTargetGuid());
            manager.AddHealthKit();
            manager.WriteToFile();
        }
    }
}

또, 권한 요청이 있을 경우에 관련 설명을 추가해주어야 하는데, 이 역시도 PostProcess에서 해주면 간편합니다.

rootDict.SetString("NSHealthShareUsageDescription", "You can check your exercise record on Apple Fitness");
rootDict.SetString("NSHealthUpdateUsageDescription", "You can check your exercise record on Apple Fitness");

이렇게 적어주면 iOS 빌드가 되었을 때 세팅 파일에 잘 등록되어 있는 모습을 볼 수 있습니다.

이렇게 하면 Unity에서 iOS의 HealthKit 코드를 Swift로 적기의 대장정이 끝이 납니다.

파이썬으로 API 서버를 구축하기 위해 이렇게 간단한 코드를 짜서 실행시켜봤는데, ImportError: cannot import name 'Flask' from partially initialized module 'flask' (most likely due to a circular import) 에러가 났다.

뭐지.. 또 M1이 모듈 설치 이상하게 해놓고 객기 부리나.. 했는데

ㅋㅋㅋㅋ 옙. 간단한 이유였다.

파일명을 flask.py가 아닌 다른 것으로 바꾸기만 하면 해결된다.

저를 5초만에 구해준 위 스택오버플로우 링크는 https://stackoverflow.com/questions/61032702/importerror-cannot-import-name-flask-from-partially-initialized-module-flask 여기입니다.

사실 UIViewController 공식문서는 iOS 개발을 시작할 때쯤 (그러니까 아마 작년 이맘때..) 읽어본 적이 있다. 근데 사실 온전히 이해를 못 했었다. 이제 막 걸음마 배우고 있는 단계에 육상선수의 트레이닝법을 설명한 글을 읽고 있었던 것 같은 느낌. 이제 달릴 줄 아는 단계니까 다시 읽어보면 느낌이 또 다르겠지?!

뷰컨트롤러의 생명주기에 대해 공부하기 전에 먼저 ViewController가 뭔지부터 천천히 읽어보고 공부해봤습니다.

참고한 공식 문서 🖥 UIViewController 🖥 View Controller Programming Guide for iOS 🖥 loadView()

UIViewController의 역할

A view controller’s main responsibilities include the following:

• Updating the contents of the views, usually in response to changes to the underlying data.

• Responding to user interactions with views.

• Resizing views and managing the layout of the overall interface.

• Coordinating with other objects—including other view controllers—in your app.

• 데이터에 변동이 일어나면 뷰 내용 업데이트 하기

• 유저 인터랙션(터치, 드래그 등) 처리하기

• 뷰 크기 조정, 레이아웃 관리하기

• 다른 뷰컨트롤러 등의 객체들과 상호작용 하기

유저는 한 번에 한 뷰컨트롤러의 뷰만 볼 수 있지만, 그 뷰 컨트롤러 이외에도 다른 뷰 컨트롤러들이 존재할 수 있다. (공식문서에서는 '하나의 뷰 컨트롤러에서 여러 항목을 테이블뷰로 보여주고 있으면 다른 한 뷰 컨트롤러에서 선택된 항목들만 보여주는 뷰가 존재할 수 있다'라고 설명하고 있네요.) 이렇게 뷰 컨트롤러는 새로운 뷰를 보여주기 위해 다른 뷰 컨트롤러를 띄우거나(present), 다른 뷰컨트롤러의 컨테이너 역할을 하면서 뷰에 애니메이션을 적용시키는 역할을 하기도 한다.

[ViewController의 종류]

There are two types of view controllers:

• Content view controllers manage a discrete piece of your app’s content and are the main type of view controller that you create.

• Container view controllers collect information from other view controllers (known as child view controllers) and present it in a way that facilitates navigation or presents the content of those view controllers differently.

• Content view controllers: 앱의 구성요소들을 관리. 메인이 되는 뷰 컨트롤러.

• Container view controllers: 다른 뷰 컨트롤러(child view controllers; 자식 뷰 컨트롤러)로부터 정보를 수집. 뷰 사이의 이동을 돕거나 자식 뷰 컨트롤러의 내용을 여러 방면에서 보여주는 방식으로 뷰를 띄움.

(말이 어려웠지만, Container view controller는 위에서 설명한 것처럼 애니메이션을 보여준다든지, 다른 뷰로 넘어가는 그 과정을 관장하는 것 같습니다. container view controller의 예시로는 UINavigationController, UITabBarController, UISplitViewController 등이 있습니다.)

대부분의 앱은 이 두 종류의 뷰 컨트롤러가 적절하게 섞여 만들어진다.

뷰 관리

아무래도 뷰 컨트롤러의 가장 중요한 역할은 뷰의 계층을 관리하는 것이다.(라고 애플이 그랬어요)

The most important role of a view controller is to manage a hierarchy of views. Every view controller has a single root view that encloses all of the view controller’s content. To that root view, you add the views you need to display your content.

모든 뷰 컨트롤러는 뷰 컨트롤러 위에 있는 모든 뷰들을 담는 하나의 root view를 가지고 있다. 그래서 우리는 그 root view에 우리가 보여주고자 하는 내용을 얹으면 된다. 위 사진은 뷰 컨트롤러와 뷰의 관계를 그린 모식도입니다. 보면, 뷰 컨트롤러가 하나의 root view를 가지고 있고, 우리가 화면에 띄우고자 하는 view들이 모두 그 root view 위에 얹어져 있는, 하나의 계층을 이루고 있는 모습을 확인할 수 있어요.

The view controller always has a reference to its root view and each view has strong references to its subviews.

뷰 컨트롤러는 항상 root view를 참조하고(가리키고) 있고, 모든 뷰는 그 subview(뷰 계층에서 하단에 위치하는 뷰; 아마 자식 뷰)를 강하게 참조하고 있다.

뷰 컨트롤러와 뷰들의 강한 관계성을 설명하고 있는 듯합니다.

A content view controller manages all of its views by itself. A container view controller manages its own views plus the root views from one or more of its child view controllers. The container does not manage the content of its children. It manages only the root view, sizing and placing it according to the container’s design. Figure 1-2 illustrates the relationship between a split view controller and its children. The split view controller manages the overall size and position of its child views, but the child view controllers manage the actual contents of those views.

content view controller는 그 위의 모든 뷰를 스스로 관리한다. container view controller는 자신의 뷰 + 자식 뷰 컨트롤러들의 root view들까지 관리한다. content 자체에는 관여하지 않고, 오직 root view만 컨트롤한다. 사진을 보면 split view controller와 자식 뷰 컨트롤러들을 보여주고 있는데, 최상단의 split view controller는 자식 뷰들의 전체적인 크기와 위치를 관리하고 있지만, 자식 뷰 컨트롤러 위에 있는 실제 보여지는 내용(뷰)들은 자식 컨트롤러가 직접 관리하고 있다.

content view controller와 container view controller의 차이를 설명하기 위해 split view controller가 등장했습니다. 모식도를 보면, split view controller 위에 두 개의 자식 뷰 컨트롤러가 얹어져 있는 모습을 볼 수 있습니다. 여기서 강조하고 있는 건, 자식 뷰 컨트롤러의 위치와 크기(즉 어떻게 배치되어 있느냐겠지요)는 container view controller인 split view controller에서 관리하지만, 실제 유저가 보는 화면의 내용 그 자체는 content view controller인 자식 뷰 컨트롤러들 (View Controller A, View Controller B)가 띄우고 있다는 것을 확인할 수 있습니다. 쉽게 말해 IBOutlet 같은 걸 자식 뷰 컨트롤러들에서 정의하고 레이아웃도 거기서 잡아준다는 걸 이야기하고 있는 것 같아요.

View controllers load their views lazily. Accessing the view property for the first time loads or creates the view controller’s views. There are several ways to specify the views for a view controller:

• Specify the view controller and its views in your app’s Storyboard. Storyboards are the preferred way to specify your views. With a storyboard, you specify the views and their connections to the view controller. You also specify the relationships and segues between your view controllers, which makes it easier to see and modify your app's behavior. To load a view controller from a storyboard, call the instantiateViewController(withIdentifier:) method of the appropriate UIStoryboard object. The storyboard object creates the view controller and returns it to your code.
• Specify the views for a view controller using a Nib file. A nib file lets you specify the views of a single view controller but does not let you define segues or relationships between view controllers. The nib file also stores only minimal information about the view controller itself. To initialize a view controller object using a nib file, create your view controller class programmatically and initialize it using the init(nibName:bundle:) method. When its views are requested, the view controller loads them from the nib file.
• Specify the views for a view controller using the loadView() method. In that method, create your view hierarchy programmatically and assign the root view of that hierarchy to the view controller’s view property.

뷰 컨트롤러는 뷰를 lazy하게 로드한다. 뷰 프로퍼티에 처음 접근할 때에야 비로소 뷰 컨트롤러에 뷰를 로드하고 만드는 작업을 하게 된다. 뷰 컨트롤러에 어떤 뷰를 띄워야 할지 정해줄 수 있는 방법이 있다.

• 스토리보드에서 뷰 컨트롤러 위에 뷰를 직접 얹기. 뷰와 뷰 컨트롤러를 바로 연결해줄 수 있음. 뷰 컨트롤러 간 관계성이나 세그도 정해줄 수 있음. 보기 쉽고 수정하기 쉬워짐. 특정 스토리보드에 있는 뷰 컨트롤러를 로드하기 위해서는 해당 UIStoryboard 객체에서instantiateViewController(withIdentifier:) 메서드를 호출해주면 됨.
• Nib file 활용하기. nib으로 뷰 컨트롤러 위에 해당 뷰를 띄울 수는 있지만, 세그나 뷰 컨트롤러 사이의 관계성을 정의하지는 못함. nib파일로 뷰 컨트롤러에 뷰를 띄우기 위해서는 init(nibName:bundle:)를 활용. 해당 코드로 뷰가 불러지면 뷰 컨트롤러가 그 nib 파일을 로드하게 됨.
• loadView() 메서드 활용. 뷰 계층을 코드로 짜서 해당 뷰 계층의 root view를 뷰 컨트롤러에 장착.

첫 번째 방법인 스토리보드에서 직접 작업해주는 방법은 제가 가장 많이 쓰고 있는 방법이기도 합니다. 공식문서에서도 언급했다시피, 가장 보편적으로 쓰이고 있는 방법이 아닐까 합니다.

/// 다른 스토리보드에 있는 뷰 컨트롤러를 호출할 때는 storyboard 이름을 명시함
let storyboard = UIStoryboard(name: "Main", bundle: nil)
guard let dvc = storyboard.instantiateViewController(withIdentifier: "ViewController") as? ViewController else { return }

/// 동일 스토리보드에 있는 뷰 컨트롤러를 호출할 때는 storyboard 정의를 생략함
self.instantiateViewController(withIdentifier: "ViewController") as? ViewController else { return }

이런 식의 코드를 보신 적이 있을 겁니다. 이 코드는 Main 스토리보드 파일에 있는 ViewController 뷰 컨트롤러를 불러오라는 뜻의 코드입니다. 그리고 ViewController에는 사용자에게 보여주고자 하는 뷰들이 짜여져 있겠지요. 이게 바로 첫 번째 방법에서 설명하고 있는 스토리보드를 이용해 뷰컨트롤러 위에 뷰를 띄우는 방법입니다.

두 번째 방법은 nib 파일(xib)에 뷰를 만들어 불러와주는 코드입니다.

let vc = NibViewController(nibName: "NibViewController", bundle: nil)

이런 식으로 사용되는 코드입니다. 스토리보드 방식과 큰 차이는 없지만, 스토리보드가 제공하는 GUI 상에서 드래그 해 세그를 연결해주는 건 못 한다는 점이 다릅니다.

마지막 방법인 loadView()를 활용하는 방법은 개인적으로 쓰여진 코드를 읽어본 적만 있고 써본 적은 없는 방식입니다. loadView()를 사용할 일이 많이 없었던 이유는 저는 항상 GUI상에 실제로 존재하는 뷰 컨트롤러를 생성했기 때문인데, (많이들 쓰시는 그 방법입니다) 이 방법으로 뷰 컨트롤러를 생성하면 위에서도 잠깐 언급했다시피 하나의 view(root view)가 자동으로 함께 생성됩니다. 하지만 스토리보드나 xib를 사용하지 않고 코드로 뷰 컨트롤러를 만들게 되면 그 안에 뷰가 자동으로 생성되지 않기 때문에 뷰를 직접 만들어줘야 하고, 이때 그 뷰를 만들어주는 방법이 loadView()를 사용하는 방법입니다. 공식문서에서는 이 loadView()를 지금 설명하는 예시처럼 코드로 직접 ViewController를 만들어주는 상황이 아니면 직접 호출하지 말라고 이야기 하고 있습니다.

import UIKit

class NoGUIViewController: UIViewController {
    override func loadView() {
        super.loadView()
        self.view.backgroundColor = .gray
    }
    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

공식 문서에서도 언급하고 있듯, 이 세 방법은 모두 같은 결과를 가져오기 때문에 상황에 맞게 골라 사용하면 됩니다.

A view controller is the sole owner of its view and any subviews it creates. It is responsible for creating those views and for relinquishing ownership of them at the appropriate times such as when the view controller itself is released. If you use a storyboard or a nib file to store your view objects, each view controller object automatically gets its own copy of these views when the view controller asks for them. However, if you create your views manually, each view controller must have its own unique set of views. You cannot share views between view controllers.

뷰 컨트롤러는 그 뷰와 서브뷰들의 오직 하나의 주인이다. 그래서 적절한 타이밍(예를 들면 뷰 컨트롤러 자체가 사라질 때)에 그 뷰들을 만들거나 제거하는 일을 한다. 스토리보드나 nib을 사용해 뷰를 만든다면 뷰 컨트롤러가 요구할 때 자동으로 뷰의 복사본을 만들어내지만, 코드로 짠 뷰는 모든 뷰 컨트롤러에서 다 다른 각자의 뷰들을 가지고 있어야 한다. 뷰를 다른 뷰 컨트롤러와 같이 사용할 수 없다는 의미다.

iOS 개발을 하며 항상 아쉬웠던 부분을 짚어줬습니다. 반복되는 뷰가 있으면 A라는 뷰 컨트롤러에서 만들어서 B라는 뷰 컨트롤러에서도 쓸 수 있으면 좋은데, 뷰는 오로지 그 뷰 컨트롤러에 종속되어야 하기 때문에 다른 뷰 컨트롤러에서는 사용할 수 없다고 이야기하고 있습니다. (그래서 저는 xib로 custom view를 만든 후 delegate를 활용하는 방법으로 재사용이 필요한 헤더 등을 제작하고 있긴 합니다)

Viewcontroller 생명주기

공식문서에서는 Handling View-Related Notifications 타이틀로 소개되고 있는 부분입니다.

When the visibility of its views changes, a view controller automatically calls its own methods so that subclasses can respond to the change. Use a method like viewWillAppear(_:) to prepare your views to appear onscreen, and use the viewWillDisappear(_:) to save changes or other state information.

뷰의 보이는 상태가 변화하면, 뷰 컨트롤러는 자동으로 관련한 메서드를 호출해 서브클래스들이 변화에 반응할 수 있도록 한다. viewWillAppear(:)과 같은 메서드를 활용해 뷰가 스크린에 띄워지는 것을 준비하고, viewWillDisappear(:)로 변화나 상태 정보를 저장할 수 있다.

Xcode 상의 코드에서 viewDidLoad를 마우스 우클릭하고 jump to definition을 해보면, 주석에 아래처럼 쓰여있는 것을 확인할 수 있습니다.

1. init 2. loadView

- (void)loadView; // This is where subclasses should create their custom view hierarchy if they aren't using a nib. Should never be called directly.

위에서 계속 나왔다시피 코드로 뷰 컨트롤러를 생성하게 되면 불러야 하는 메서드입니다.

3. viewDidLoad

- (void)viewDidLoad; // Called after the view has been loaded. For view controllers created in code, this is after -loadView. For view controllers unarchived from a nib, this is after the view is set.

즉, 뷰 로드가 끝나자마자 불리고, 만약 뷰컨트롤러를 코드로 짰다면 loadView 다음에 불린다고 합니다. 만약 스토리보드나 nib 파일로 뷰 컨트롤러를 만들었다면 그 뷰가 셋 되고 난 다음에 불리겠지요. 따라서 리소스 초기화, 초기 화면 구성 등을 할 때 용이하게 사용할 수 있습니다. 다만, 뷰가 처음 만들어질 때 딱 한 번만 실행되는 메서드이므로, 뷰가 나타날 때마다 초기화 되어야 하는 리소스나 바뀌어야 하는 화면 구성이 있다면 해당 메서드는 바람직하지 않습니다. (뒤에서 설명하겠지만, 이런 경우에는 viewWillAppear를 활용하면 좋습니다)

4. viewWillAppear

- (void)viewWillAppear:(BOOL)animated // Called when the view is about to made visible. Default does nothing

뷰가 나타나기 직전에 호출됩니다. 뷰가 이제 나타날 거라는 신호를 뷰 컨트롤러에게 알려줍니다. viewDidLoad와 다른 점은 viewDidLoad는 로드될 때 딱 한 번 불리고, viewWillAppear는 쉽게 말해 눈에 보이기 직전에 호출 됩니다. 뷰가 눈에서 사라진다고 해서 항상 unload가 되지 않습니다. 사용자의 눈에 나타났다, 없어졌다 하는 상태를 관리하기 좋은 메서드입니다.

5. viewDidAppear

- (void)viewDidAppear:(BOOL)animated; // Called when the view has been fully transitioned onto the screen. Default does nothing

뷰가 나타난 직후 호출됩니다.

6. viewWillDisappear

- (void)viewWillDisappear:(BOOL)animated; // Called when the view is dismissed, covered or otherwise hidden. Default does nothing

뷰가 눈에서 사라지기 직전에 호출됩니다. 여기서 '사라진다'는 것은 dismiss 되거나, 다른 뷰에 의해 가려지거나 하는 상황을 의미합니다.

7. viewDidDisappear

- (void)viewDidDisappear:(BOOL)animated; // Called after the view was dismissed, covered or otherwise hidden. Default does nothing

뷰가 눈에서 사라진 직후에 호출됩니다.

8. viewDidUnload

- (void)viewDidUnload API_DEPRECATED("", ios(3.0, 6.0)) API_UNAVAILABLE(tvos); // Called after the view controller's view is released and set to nil. For example, a memory warning which causes the view to be purged. Not invoked as a result of -dealloc.

메모리 관리

Memory is a critical resource in iOS, and view controllers provide built-in support for reducing their memory footprint at critical times. The UIViewController class provides some automatic handling of low-memory conditions through its didReceiveMemoryWarning() method, which releases unneeded memory.

메모리 관리를 위해 UIViewController 클래스에서 메모리가 부족할 경우를 핸들링 할 수 있게 해주는 didReceiveMemoryWarning() 메서드를 제공하고 있다. 해당 메서드는 필요없는 메모리를 해제시킨다.

마침, iOS 기술 면접을 볼 일이 생겨 이 기회에 이론적인 개념을 정리해보려 한다.

iOS 개발 (기본편)

1. View Controller, View의 생명주기에 대해 설명하세요.

ViewController의 생명주기 공부에서 시작한 ViewController와 View에 대한 고찰

2. App의 생명주기에 대해 설명하세요.

3. scene delegate에 대해 설명하세요.

4. ARC(Automatic Reference Counting)에 대해 설명하세요.

5. Weak와 Strong, unowned에 대해 설명하세요.

6. Escaping Closure에 대해 설명하세요.

7. 타입 캐스팅을 할 때 사용하는 키워드인 as, as?, as! 이 셋의 차이를 설명하세요.

8. Swift에서 Class와 Struct의 차이를 설명하세요.

Swift) 구조체와 클래스

9. Frame 과 Bounds 의 차이를 설명하세요.

10. delegate 패턴에 대해 설명하세요.

11. Delegate vs Block vs Notification의 차이에 대해 설명하세요.

12. 스토리보드를 이용했을때의 장단점을 설명하세요.

13. Safearea에 대해서 설명하세요.

14. 코코아 프레임워크에 대해 설명하세요.

15. 옵셔널 바인딩에 대해 설명하세요.

16. lazy 키워드에 대해 설명하세요.

17. 실제 디바이스가 없을 경우 개발 환경에서 할 수 있는 것과 없는 것을 설명하세요.

iOS 개발 (심화편)

1. MVC, MVVM 등 디자인 패턴에 대해 설명하세요.

2. RxSwift에 대해 설명하세요.

3. Swift로 동기/비동기 처리하는 방법들에 대해 설명하세요.

CS 이론 질문

1. 동기 비동기에 대해 설명하세요.

2. 스레드에 대한 개념을 설명하세요.

3. 선언형, 절차형 프로그래밍에 대해 설명하세요.

4. call by value, call by reference의 차이에 대해 설명하세요.

5. 순수함수, 익명함수, 고차함수에 대해 설명하세요.

6. overloading, overriding에 대해 설명하세요.

👉🏻 질문을 수집하는 과정에서 참고한 곳들 https://ugly-developer.tistory.com/5 https://github.com/JeaSungLEE/iOSInterviewquestions https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/iOS

1. 열정

• 당신의 열정은 무엇입니까?
• 열정을 가지고 있다면 그 열정을 우리가 발산하게 해줄 것이고, 열정을 발산할 곳을 아직 찾지 못했다면 우리가 그것을 찾는 데 도움을 줄 것입니다.
• 정해진 과제는 없습니다. 우리의 역할은 단지 당신이 열정을 발산할 수 있도록 돕는 것뿐입니다.

2. 아카데미와 관련해

• 하나의 커뮤니티를 가지고 교육과 네트워크를 제공하고 있습니다.

• 9개월 간의 교육

• 한국은 2번째로 큰 아카데미가 될 거예요

• 아카데미의 다양성을 존중하기 위해 노력합니다. (인종, 교육적 배경, 사회적 배경, 성별 등)

  • 지난 몇 년간 아카데미의 여성 비율이 6배 증가했습니다
  • 17-57세까지 다양한 연령대가 있습니다
  • 다양한 직업을 가진 사람들이 함께하고 있습니다
  • 그들의 공통점은 열정을 가지고 있었다는 것입니다

• 과제는 없습니다.

  • 과제라고 부를 게 없죠, 그냥 앱을 만들어서 앱스토어에 내면 됩니다.
  • 취업할 때 '당신의 앱 개발 능력은 어느 정도입니까?' 라는 질문에 '전 제 앱이 있고, 7천 다운로드가 넘어갑니다'라고 답하는 것보다 더 좋은 답변은 없겠죠

• 졸업생 성과

  • WWDC

    • 1주간의 개발자 컨퍼런스
    • WWDC에서 장학금 받은 사람이 431명이나 나왔습니다

  • 아카데미 졸업생에 의해 162개의 새로운 회사가 창업되었습니다.

  • 그래서 하고 싶은 얘기는, 당신이 아카데미를 통해 성장해서 취업을 하든 창업을 하든 취업을 하다 창업을 하든 무엇이든 할 수 있다는 겁니다

    
    

3. 커리큘럼: T자형 전문가

• design, develop, business + professional skills
• 사람들을 리드하고, 협업하고, 사람들에게 영향을 주고, 설득을 하고, 어떻게 프로세스를 관리하는가를 배웁니다
• 커리큘럼이라고 부르기보다는 'learning experience(학습 경험)'라고 얘기할게요
• 디자인, 개발, 사업을 모두 할 줄 알아야 하겠죠.
• 모두가 갖춰야 할 기본적인 능력을 갖추게 될 것입니다.
  • 그렇게 기본적인 것을 배우다 보면 각자 두각을 나타내는 영역이 다를 것이고, 그 분야를 더 깊게 공부할 수 있어야 합니다. 그래서 내 path를 쌓아가야 해요
• 아카데미에서 같은 걸 배우고 있더라도 아무도 같은 일을 하고 있는 사람이 없을 겁니다
  • 우리가 하라고 해서 하는 게 아니라 당신이 원해서 해야 합니다
• Engage, Investigate, Act

• 커리큘럼이 있지만 모든 사람이 다 같은 걸 배우진 않을 겁니다.
  • 심지어는 같은 프로젝트 안에서도 누구는 백엔드에 집중하고 누군가는 인터페이스에 집중하는 등 다 다른 걸 배우고 있을 거예요

• 브릿지는 회고와 앞으로의 방향성을 잡아가는 데 도움을 줄 겁니다

4. 질의응답

1. 강의 언어?
   1. 한국어 50/영어 50, 발표를 하거나 멘토와 소통을 할 때 영어를 써야 할 경우가 있을 겁니다
2. 나이 제한?
   1. 만 19세 이상 (2022.03.01. 기준)
3. swift 할 줄 알아야 하나요?
   1. 스위프트가 prerequisite이 아닙니다
   2. 스위프트를 할 줄 안다면 좋겠지만 그게 이 사람이 열정을 가졌다는 것의 증거가 되지 않을 수도 있습니다
4. swift만 배우나요?
   1. swift가 메인 언어가 되겠지만, 여전히 현업에서 C++ 등 중요한 언어들이 많으므로 방대하게 다루려 합니다.
5. 강의자에 대해?
   1. 우리는 강의자를 멘토라고 부릅니다
   2. 다양한 배경의 12-14명(세션)이 있을 예정이고, personal 교육을 제공할 예정입니다.
   3. 동료와 함께 성장하고 멘토의 팁을 들으세요
   4. 모르겠어라고 얘기할 때 앉아서 같이 고민해보자라고 대답할 수 있는 사람
6. 교육 비용
   1. 교육비 전액 지원, 정착지원금(100만원) 지원, 장비(맥북프로, 최신 아이폰 등) 대여
   2. 기숙사 거주 원할 경우 한 달 30만원 내외
7. 트랙
   1. 트랙을 선택하긴 하지만 거기에 얽매일 필요는 없습니다
8. ML
   1. 머신러닝이 커리큘럼 안에 있긴 하지만, 모두가 배울 필요는 없습니다
9. 아카데미 밖 사람과 협업해 앱을 제작해도 되나요?
   1. 바깥의 리소스를 활용하는 건 가능합니다
   2. 하지만 바깥 사람과 팀을 이루어 협업하면 안됩니다
10. 회사나 학교에 다니고 있으면 어떡하나요?
    1. 아침 8-12부터나 오후 4시간에 참가해야 합니다
    2. 애플에서 스튜디오에 직접 오는 걸 강력하게 권장합니다
11. 다른 나라에서 진행된 아카데미의 성과
    1. 아시아의 경우, 졸업생의 98프로가 취업에 성공
    2. 취업 후에도 더 빠른 승진을 함
    3. 작년 128개의 회사가 캠퍼스에 학생들의 성과를 보기 위해 방문
    4. 코로나 때문에 일할 준비가 된 졸업생들은 평균 1.5개의 회사에서 입사 제안을 받았음. 코로나 이전에는 평균 3개였음.
12. 경쟁률?
    1. 3% 합격, 10% 합격
    2. 근데 지역에 따라 많이 달라짐

지원

• 누구?
  • 19세 이상 누구나
  • 코딩 할 줄 몰라도 됩니다. 그거 배우려고 오는 거예요.
  • 다양한 교육적 배경의 사람들이 왔으면 합니다.
  • 다양성을 추구합니다.
• 포트폴리오
  • 당신이 할 수 있는 걸 보여주세요
  • 당신이 가진 열정을 증명해보세요
  • 디자이너면 작품을 보여주시고, 뮤지션이면 음악을 들려주세요, 개발자면 깃헙을 보여주세요
• 온라인 테스트
  • logic and problem solving (not tech related)
  • basic programming
  • bonus part) 자료를 먼저 주면 당신이 읽어서 공부해올 수 있는지, 주어지는 것만 받아먹는 사람인지 능동적인 학습을 하는 사람인지 확인
  • 디자이너라면 당연히 컴퓨터 관련해서는 아무것도 못 할 테니까 당연히 다르게 채점합니다
  • 하지만 T자형 인재상과 맞춰 디자이너지만 코딩을 할 줄 안다면 너무너무 좋겠죠

그래서 보통 피커뷰로 날짜를 설정하려고 하면 iOS에서 기본으로 제공하는 UIDatePicker을 사용하는데, 예쁘고 간편하긴 하지만 커스텀이 제한적이라 실제로 서비스에서 사용해본 적은 많이 없는 것 같다.

대신 커스텀이 용이한 UIPickerView로 UIDatePicker를 흉내내는 방식의 구현을 자주 사용한다.

iOS 프로젝트 개발에서 생각보다 많을 것 같지만, 한글로 된 블로그 글이 몇 개 없는 것 같아 정리해보는 오늘의 주제는 아래처럼 정했다.

UIPickerView로 년, 월만 선택 가능한 피커 만들기

1. 텍스트필드 얹기

피커뷰를 뷰에 컴포넌트로 얹을 수도 있지만, 보통은 코드로 많이 생성한다. (뇌피셜로는 뷰에 얹어서 isHidden 처리 해주는 것보다 코드로 설정해주는 게 훨씬 간단하기 때문일 것 같다)

피커뷰를 코드로 만들기 위해서는 뜬금없지만 뷰에 UITextField가 있는 상태여야 한다. 추후에 이 텍스트필드에 입력수단으로 피커뷰를 이용할 계획이다. (텍스트필드의 커서는 없애서 UIButton처럼 구동하게 할 생각이므로 같은 동작을 하는 버튼은 없어도 된다. 버튼 대신 텍스트필드를 얹자)

나는 스토리보드에서 yearTextField라는 텍스트필드를 만들고 IBOutlet을 연결해주었다.

@IBOutlet var yearTextField: UITextField!

2. 피커뷰 코드 쓰기

그 후에는 이제 생성한 텍스트필드의 입력 수단으로 이용될 피커뷰를 제작하면 되는데, 이때는 스토리보드에서 아무런 작업 없이 코드만 추가해주면 된다.

override func viewDidLoad() {
    super.viewDidLoad()

    createPickerView()
}

/// 피커뷰 생성
func createPickerView() {
    /// 피커 세팅
    let pickerView = UIPickerView()
    pickerView.delegate = self
    pickerView.dataSource = self
    yearTextField.tintColor = .clear

    /// 텍스트필드 입력 수단 연결
    yearTextField.inputView = pickerView
}

extension FundManagerThinkVC: UIPickerViewDelegate, UIPickerViewDataSource {
    func numberOfComponents(in pickerView: UIPickerView) -> Int {
        return 2 /// 년, 월 두 가지 선택하는 피커뷰
    }

    func pickerView(_ pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
        switch component {
        case 0:
            return availableYear.count /// 연도의 아이템 개수
        case 1:
            return allMonth.count /// 월의 아이템 개수
        default:
            return 0
        }
    }

    /// 표출할 텍스트 (2020년, 2021년 / 1월, 2월, 3월, 4월 ... )
    func pickerView(_ pickerView: UIPickerView, titleForRow row: Int, forComponent component: Int) -> String? {
        switch component {
        case 0:
            return "\(availableYear[row])년"
        case 1:
            return "\(allMonth[row])월"
        default:
            return ""
        }
    }

    /// 피커뷰에서 선택된 행을 처리할 수 있는 메서드
    func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) {

        switch component {
        case 0:
            selectedYear = availableYear[row]
        case 1:
            selectedMonth = allMonth[row]
        default:
            break
        }
    }
}

이렇게 하면 텍스트필드를 클릭했을 때 피커뷰가 올라온다.

3. 툴바 코드 쓰기

하지만 확인 버튼이 없네..? 피커뷰는 어떻게 내리지?

그 처리를 위해 툴바를 추가해준다. 참고로 툴바는 입력창 위에 취소, 확인 버튼 있는 부분이다.

툴바 코드를 추가한 피커뷰 코드는 다음과 같다.

/// 피커뷰 생성
func createPickerView() {
    /// 피커 세팅
    let pickerView = UIPickerView()
    pickerView.delegate = self
    pickerView.dataSource = self
    yearTextField.tintColor = .clear

    /// 툴바 세팅
    let toolBar = UIToolbar()
    toolBar.sizeToFit()

    let btnDone = UIBarButtonItem(title: "확인", style: .done, target: self, action: #selector(onPickDone))
    let space = UIBarButtonItem(barButtonSystemItem: .flexibleSpace, target: self, action: nil)
    let btnCancel = UIBarButtonItem(title: "취소", style: .done, target: self, action: #selector(onPickCancel))
    toolBar.setItems([btnCancel , space , btnDone], animated: true)
    toolBar.isUserInteractionEnabled = true

    /// 텍스트필드 입력 수단 연결
    yearTextField.inputView = pickerView
    yearTextField.inputAccessoryView = toolBar
}

// 피커뷰 > 확인 클릭
@objc func onPickDone() {
    /// 확인 눌렀을 때 액션 정의 -> 아래 코드에서는 라벨 텍스트 업데이트
    yearLabel.text = "\(selectedYear)년"
    monthLabel.text = "\(selectedMonth)월"

    yearTextField.resignFirstResponder() /// 피커뷰 내림
}

// 피커뷰 > 취소 클릭
@objc func onPickCancel() {
    yearTextField.resignFirstResponder() /// 피커뷰 내림
}

부가 설명을 하자면, 확인 버튼, 취소 버튼을 설정하는 부분에서 let btnDone = UIBarButtonItem(title: "확인", style: .done, target: self, action: #selector(onPickDone)) 이 코드에서 title은 버튼 텍스트를, style은 버튼의 형태, 코드에서 .을 눌러보면 모든 옵션을 볼 수 있는데 done과 plain이 있다 그리고 action: #selector()에서는 버튼이 눌렸을 때 어떤 액션을 취할 것인지 @objc func를 넣을 수 있는 형태로 되어 있다. 여기서는 onPickDone이라는 메서드를 정의했고,

// 피커뷰 > 확인 클릭
@objc func onPickDone() {
    /// 확인 눌렀을 때 액션 정의 -> 아래 코드에서는 라벨 텍스트 업데이트
    yearLabel.text = "\(selectedYear)년"
    monthLabel.text = "\(selectedMonth)월"

    yearTextField.resignFirstResponder() /// 피커뷰 내림
}

이러한 액션들을 하고 있다. 다른 부분은 마음대로 써도 되지만, textField.resignFirstResponder() 부분은 꼭 써줘야 확인을 눌렀을 때 피커뷰가 사라진다.

같은 원리로 취소 버튼도 만들어주면 된다.

4. 날짜 계산

사실 2번까지만 해도 피커뷰를 띄울 수는 있지만, 조건이 하나 더 붙은 상황이라고 가정해보자.

2020년 1월부터 현재까지만 선택 가능하게 해주세요

라는 조건이 붙었을 때 우리는 아 날짜 계산을 해야겠다라고 생각하게 된다.

계산은 오늘 날짜를 계산해주는 Date()라는 걸 활용할 예정이다.

var availableYear: [Int] = []
var allMonth: [Int] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
var selectedYear = 0
var selectedMonth = 0
var todayYear = "0"
var todayMonth = "0"

/// 가능한 날짜 설정
func setAvailableDate() {
    /// 선택 가능한 연도 설정
    let formatterYear = DateFormatter()
    formatterYear.dateFormat = "yyyy"
    todayYear = formatterYear.string(from: Date())

    for i in 2020...Int(todayYear)! {
        availableYear.append(i)
    }

    /// 선택 가능한 달 설정
    let formatterMonth = DateFormatter()
    formatterMonth.dateFormat = "MM"
    todayMonth = formatterMonth.string(from: Date())

    selectedYear = Int(todayYear)!
    selectedMonth = Int(todayMonth)!
}

5. 미래 날짜 선택 막기

마지막으로 해줘야 할 것이 미래 날짜를 선택했을 때 막는 기능이다. 생각보다 간단하다. 기본으로 제공되는 pickerView.selectRow()를 이용하면 된다. 그러면 우리가 원하는 행으로 피커 휠을 돌릴 수 있다.

pickerView didselectRow에 다음 코드를 추가해주었다.

if (Int(todayYear) == selectedYear && Int(todayMonth)! < selectedMonth) {
        pickerView.selectRow(Int(todayMonth)!-1, inComponent: 1, animated: true)
        selectedMonth = Int(todayMonth)!
}

여기서 맨 처음 인자로는 돌릴 행(몇 월인지 - Int(todayMonth)!-1)을 inComponent에는 돌릴 열(이 코드에서 년도면 0, 월이면 1)을, 마지막으로는 돌아가는 애니메이션을 넣을지 말지를 설정해주면 된다.

그러면 만약 오늘이 2021년 10월이라고 할 때, 사용자가 2021년 11월을 선택하면 2021년 10월로 자동으로 돌려주게 된다.

부록) 전체 코드

var availableYear: [Int] = []
var allMonth: [Int] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
var selectedYear = 0
var selectedMonth = 0
var todayYear = "0"
var todayMonth = "0"

@IBOutlet var yearTextField: UITextField!

override func viewDidLoad() {
    super.viewDidLoad()

    setAvailableDate()
    createPickerView()
}

/// 피커뷰 생성
func createPickerView() {
    /// 피커 세팅
    let pickerView = UIPickerView()
    pickerView.delegate = self
    pickerView.dataSource = self
    yearTextField.tintColor = .clear

    /// 툴바 세팅
    let toolBar = UIToolbar()
    toolBar.sizeToFit()

    let btnDone = UIBarButtonItem(title: "확인", style: .done, target: self, action: #selector(onPickDone))
    let space = UIBarButtonItem(barButtonSystemItem: .flexibleSpace, target: self, action: nil)
    let btnCancel = UIBarButtonItem(title: "취소", style: .done, target: self, action: #selector(onPickCancel))
    toolBar.setItems([btnCancel , space , btnDone], animated: true)
    toolBar.isUserInteractionEnabled = true

    /// 텍스트필드 입력 수단 연결
    yearTextField.inputView = pickerView
    yearTextField.inputAccessoryView = toolBar
}

// 피커뷰 > 확인 클릭
@objc func onPickDone() {
    /// 확인 눌렀을 때 액션 정의 -> 아래 코드에서는 라벨 텍스트 업데이트
    yearLabel.text = "\(selectedYear)년"
    monthLabel.text = "\(selectedMonth)월"

    yearTextField.resignFirstResponder() /// 피커뷰 내림
}

// 피커뷰 > 취소 클릭
@objc func onPickCancel() {
    yearTextField.resignFirstResponder() /// 피커뷰 내림
}

/// 가능한 날짜 설정
func setAvailableDate() {
    /// 선택 가능한 연도 설정
    let formatterYear = DateFormatter()
    formatterYear.dateFormat = "yyyy"
    todayYear = formatterYear.string(from: Date())

    for i in 2020...Int(todayYear)! {
        availableYear.append(i)
    }

    /// 선택 가능한 달 설정
    let formatterMonth = DateFormatter()
    formatterMonth.dateFormat = "MM"
    todayMonth = formatterMonth.string(from: Date())

    selectedYear = Int(todayYear)!
    selectedMonth = Int(todayMonth)!
}

extension ViewController: UIPickerViewDelegate, UIPickerViewDataSource {
    func numberOfComponents(in pickerView: UIPickerView) -> Int {
        return 2
    }

    func pickerView(_ pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
        switch component {
        case 0:
            return availableYear.count
        case 1:
            return allMonth.count
        default:
            return 0
        }
    }

    func pickerView(_ pickerView: UIPickerView, titleForRow row: Int, forComponent component: Int) -> String? {
        switch component {
        case 0:
            return "\(availableYear[row])년"
        case 1:
            return "\(allMonth[row])월"
        default:
            return ""
        }
    }

    func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) {

        switch component {
        case 0:
            selectedYear = availableYear[row]
        case 1:
            selectedMonth = allMonth[row]
        default:
            break
        }

        if (Int(todayYear) == selectedYear && Int(todayMonth)! < selectedMonth) {
            pickerView.selectRow(Int(todayMonth)!-1, inComponent: 1, animated: true)
            selectedMonth = Int(todayMonth)!
        }
    }
}

이번에는 제목 바로 뒤에 복사 버튼을 넣어달라는 요청을 받았다. 이런 식으로 이름 옆에 복사 버튼을 넣어서 제목을 복사할 수 있게 해야 하는데, 제목은 한 줄이 될지, 두 줄이 될지, 세 줄이 될지 모르는 상태였다.

복사 버튼을 추가하기 전 제목 부분의 구조는 line이 0으로 설정된 UIlabel로 구현되어 있었고, 제약 역시 superview에 leading, trailing 모두 상수값 0으로 잡혀 있는 상태였다. 여기서 superview는 제목 부분(제목, 펀드코드)를 감싸는 titleContain UIView안에 있었다. UIView는 디바이스 전체 너비를 superview로 두고 상수값으로 leading, trailing이 잡혀있는 상태.

주절주절 말이 많았지만, 정리하자면, 제목 라벨의 영역이 이렇게 잡혀있는 상태였다.

그러면 복사 버튼 위치는 어떻게 설정해야 하지?

고민하다 처음 선택했던 방법은 (바보같았던 방법이다) 버튼에 title, image를 함께 넣으면 타이틀 뒤에 이미지가 온다는 것을 활용하려 했다. 하지만 ... 뜻대로 보여지지 않았고(멀티라인 때문이었다), 타이틀이 왼쪽에, 버튼이 오른쪽에 오는 아주 기이한 형태가 되었다.

그러다가 구세주 블로그 글을 하나 발견했는데,

https://zeddios.tistory.com/406

'UIButton, UILabel에 이미지 추가'라는 매력적인 제목을 가지고 있었다. 홀린듯이 들어갔고!!! 그때 이 블로그 글을 클릭한 나를 칭찬하게 됐다.

결론부터 얘기하자면 이런 코드로 성공했다.

// attributedString 선언
let attributedString = NSMutableAttributedString(string: "")

// 붙일 이미지 선언
let imageAttachment = NSTextAttachment()
imageAttachment.image = UIImage(named: "IconCopy")

// 텍스트, 이미지 순서대로 append해주기
attributedString.append(NSAttributedString(string: fundTitle))
attributedString.append(NSAttributedString(attachment: imageAttachment))

// 대상 라벨에 attributedText 속성 연결
titleLabel.attributedText = attributedString 

간단히 설명하자면, attributedString을 속성을 이용해 텍스트 뒤에 이미지를 붙여주는 방식이다.

NSMutableattributedString을 자주 쓰지만, image를 attatch하는 기능이 있는지는 처음 알았다 ㅎㅎ

나는 기존 구조를 변경하기 힘들어 titleLabel과 사이즈, 위치를 동일하게 설정한 button 위에 titleLabel을 얹는 방식으로 했지만, 시간이 여유로워지면 button에 setTitle하는 방식으로 리팩토링 할 예정이다.

👉🏻 무한 배너가 어려운 이유

얼핏 보면 쉬워보이지만, 따져야 할 것들이 조금 있어 까다로운 기능이다.

1. 무한으로 셀이 생성돼야 한다
2. 자동으로 스크롤 돼야 한다

사실 작년 이맘때에 이 기능을 구현해본 적이 있는데, 그때는 라이브러리를 사용했었다.

하지만 내가 지금 하고 있는 프로젝트는 이미 프로젝트 자체가 너무 무겁기도 하고 더이상의 라이브러리는 안 쓰거나 최소화하는 게 나을 거 같아 라이브러리 없이 야매로 이 기능을 구현해보기로 했다. (사실 말이 장황했지만 그냥 고집인 거 같기도 하다)

👉🏻 야매 로직

일단 CollectionView를 사용하기로 결정했고, 내가 머리로 짠 로직은 이렇다.

1. 보여지는 셀이 2개이므로 그거보다 하나 더 많은 3개의 셀을 만든다.
2. 마지막 셀로 넘어갔을 때 재빠르게 첫번째 셀로 되돌린다 (여기서 animation: false 설정해서 되돌아가는 게 안 보이게)

(1) 셀을 자동으로 스크롤 해주는 코드

우선, 셀 세 개를 넘기는 코드는 이렇게 작성했다.

func weatherTimer() {
    let _: Timer = Timer.scheduledTimer(withTimeInterval: 2, repeats: true) { (Timer) in
        self.weatherMove()
    }
}

func weatherMove() {
    // 다음 페이지로 전환
    currPage += 1
    fundWeatherCollectionView.scrollToItem(at: NSIndexPath(item: nowPage, section: 0) as IndexPath, at: .bottom, animated: true)
}

변수로 var currPage = 0을 선언해주고, viewDidLoad에서 weatherTime()을 호출해주면, 설정된 Timer에 따라 weatherMove() 메서드를 2초마다 불러주게 된다.

Timer.scheduledTimer()을 더 자세히 살펴보면, withTimeInterval은 타이머를 실행할 시간(초)를, repeats는 true일 때 해당 타이머를 계속해서 반복하고, false일 때는 1번 실행하고 끝난다.

weatherMove() 메서드에서는 currPage를 하나씩 증가시킨 후, currPage로 이동시키는 scrollToItem()을 사용한다. *** 여기서 animated: true로 설정하면 스크롤 되는 애니메이션이 보이고, false로 설정하면 보이지 않는다.

(2) 마지막 셀에서 첫 셀로 돌려주는 코드

여기서 포인트는 아무도 모르게 돌려야 한다는 것이다. 위에서 잠깐 힌트가 나왔는데, scrollToItem에서 animated를 false로 설정해주면, 아무도 모르게 되돌릴 수 있을 것이다.

그래서 되돌리는 코드를

func scrollTofirstIndex() {
    fundWeatherCollectionView.scrollToItem(at: NSIndexPath(item: 0, section: 0) as IndexPath, at: .top, animated: false)
    currPage = 0
}

이렇게 작성했다.

(3) 타이밍 맞추기

마지막 셀로 갔다가 첫 셀로 돌아오는데, 이게 만약 똑같이 2초의 텀을 가지고 있다면, 아무리 우리가 아무도 모르게 첫 셀로 돌려놨다고 해도 사용자는 똑같은 셀을 4초 동안 봐야 하는 문제가 있다. 그래서 타이머 영향을 받지 않으면서 눈속임하는 마지막 코드가 필요했다.

사실 가장 많이 헤맨 부분이기도 한데, 이스케이핑 클로저도 써보고 코드의 순서도 바꿔보았지만, 결국 내가 선택한 방법은 DispatchQueue.main.asyncAfter로 delay를 주는 방법이다.

그 이유는 2->3번째 셀 넘어갈 때의 애니메이션이 보여야 하고, 그 후 바로 아무도 모르게 1번째 셀로 넘어와야 하기 때문에 delay를 줘서 애니메이션만 보여지게 한 후 바로 1번째 셀로 돌리는 방법을 사용했다.

if self.currPage == self.topWeatherData.count-1 {
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.3) {
        self.scrollTofirstIndex()
    }
}

이런 식으로 현재 보여지고 있는 페이지가 마지막 페이지일 때, 0.3초의 딜레이(페이지가 넘어가는 애니메이션이 보여지는 시간)을 주고 바로 첫번째 인덱스로 돌아가는 코드다.

(4) 전체 코드

이런 식으로 구현을 하니까 정말 나조차도 모르게 부드럽게 구현이 되었다. 전체 코드는 다음과 같다.

var currPage: Int = 0

override func viewDidLoad() {
    weatherTimer()
}

func weatherTimer() {
    let _: Timer = Timer.scheduledTimer(withTimeInterval: 2, repeats: true) { (Timer) in
        self.weatherMove()
    }
}

func weatherMove() {
    currPage += 1
    fundWeatherCollectionView.scrollToItem(at: NSIndexPath(item: currPage, section: 0) as IndexPath, at: .bottom, animated: true)

    if self.currPage == self.topWeatherData.count-1 {
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.3) {
            self.scrollTofirstIndex()
        }
    }
}

func scrollTofirstIndex() {
    fundWeatherCollectionView.scrollToItem(at: NSIndexPath(item: 0, section: 0) as IndexPath, at: .top, animated: false)
    currPage = 0
}

끊어서 설명해서 코드가 길어보였지만, 코드는 정말 짧다.

1. "태그 개수" column 를 만들고 property type을 formula로 설정한다.

2. 태그의 개수를 세고 싶은 "column의 이름"을 넣어 수식을 만든다

length(replaceAll(prop("column 이름"), "(.+?)(?:,|$)", "*")) -> 여기서 "column 이름" 부분만 수정하면 됩니다)

• ex) 위 사진의 경우에는 length(replaceAll(prop("제출 과제"), "(.+?)(?:,|$)", "*"))

3. 굳이 볼 필요 없는 column이니까 숨긴다

4. 태그 개수를 sort 기준에 넣는다

당연히 레퍼런스는 없었다. 어딘가 한 번쯤 보게 생겼는데, 했을 때쯤에는 웹에서는 많이 봤지만 앱에서는 한 번도 본 적이 없다는 것을 깨달은 후였다.

막막했다.

막막하게 한 3일 정도 라이브러리 서치와 어떻게 구현할 수 있을지, javascript로 구현해서 web뷰 이식을 하는 방법이 나을지 별의 별 궁리를 다 했다.

그러다가 기적처럼 라이브러리 딱 하나를 발견했다. https://www.highcharts.com/ Highcharts라는 다양한 차트 라이브러리였다. 이미 웹 프론트엔드, 안드로이드, iOS 환경 모두를 지원하고 있었다. 깃허브를 잠시 살펴 보니 마지막 업데이트를 한지 1달도 채 되지 않을 만큼 꾸준히 업데이트가 일어나고 있었고, 차트 분야에서는 사용자도 꽤 많은 것 같았다. API docs도 꽤 논리적이고 꼼꼼하게 구성되어 있었다.

그 중에서도 내가 키워드 버블을 구현하기 위해 사용했던 라이브러리 모듈은 Packed bubble chart이다. https://www.highcharts.com/demo/ios/packed-bubble

코드도 예시가 나와 있어서 사실 docs 없이도 눈치껏 할 수 있을 것 같았다.

import Highcharts
import UIKit

class ViewController: UIViewController {

  override func viewDidLoad() {
    super.viewDidLoad()

    let chartView = HIChartView(frame: view.bounds)

    let options = HIOptions()

    let chart = HIChart()
    chart.type = "packedbubble"
    chart.height = "100%"
    options.chart = chart

    let title = HITitle()
    title.text = "Carbon emissions around the world (2014)"
    options.title = title

    let tooltip = HITooltip()
    tooltip.useHTML = true
    tooltip.pointFormat = "<b>{point.name}:</b> {point.value}m CO<sub>2</sub>"
    options.tooltip = tooltip

    let plotOptions = HIPlotOptions()
    plotOptions.packedbubble = HIPackedbubble()
    plotOptions.packedbubble.minSize = "30%"
    plotOptions.packedbubble.maxSize = "120%"
    // plotOptions.packedbubble.zMin = 0
    // plotOptions.packedbubble.zMax = 1000
    plotOptions.packedbubble.layoutAlgorithm = HILayoutAlgorithm()
    plotOptions.packedbubble.layoutAlgorithm.splitSeries = "false"
    plotOptions.packedbubble.layoutAlgorithm.gravitationalConstant = 0.02

    let dataLabels = HIDataLabels()
    dataLabels.enabled = true
    dataLabels.format = "{point.name}"
    dataLabels.filter = HIFilter()
    dataLabels.filter.property = "y"
    dataLabels.filter.operator = ">"
    dataLabels.filter.value = 250
    dataLabels.style = HIStyle()
    dataLabels.style.color = "black"
    dataLabels.style.textOutline = "none"
    dataLabels.style.fontWeight = "normal"

    plotOptions.packedbubble.dataLabels = [dataLabels]

    options.plotOptions = plotOptions

    let europe = HIPackedbubble()
    europe.name = "Europe"

    let germany = HIData()
    germany.name = "Germany"
    germany.value = 767.1

    let belgium = HIData()
    belgium.name = "Belgium"
    belgium.value = 97.2

    // 중략 (버블 선언부)

    let korea = HIData()
    korea.name = "Korea"
    korea.value = 610.1

    asia.data = [nepal, georgia, bruneiDarussalam, kyrgyzstan, afghanistan, myanmar, mongolia, sriLanka, bahrain, yemen, jordan, lebanon, azerbaijan, singapore, hongKong, syria, dPRKorea, israel, turkmenistan, oman, qatar, philippines, kuwait, uzbekistan, iraq, pakistan, vietnam, unitedArabEmirates, malaysia, kazakhstan, thailand, taiwan, indonesia, saudiArabia, japan, china, india, russia, iran, korea]

    options.series = [europe, africa, oceania, northAmerica, southAmerica, asia]

    chartView.options = options

    self.view.addSubview(chartView)

사이트에 공개돼있는 해당 사진을 만들기 위한 swift 코드다.

기본적으로 JS 베이스로 되어있는 코드고, swift로 접근할 수 있게 만들어진 프레임워크로 코드를 짜면 그게 js로 변환되어 웹뷰로 띄우는 구조로 되어 있는 것 같았다.

하이차트로 swift 개발을 한 선례는 많이 없었지만, 곧 쉽게 커스텀 할 수 있게 되었는데, Js로 나와있는 예시를 swift로 다 변환할 수 있는 이 구조를 알면 쉬웠다.

예시를 하나 들자면, 만약 버블의 투명도를 조절하는 Js 코드 예시가 아래처럼 나와있다면,

Highcharts.chart('container', {
    plotOptions: {
        series: {
            marker: {
                fillOpacity: '#FFFFFF', // 투명도 조절하는 부분
            }
        }
    },
});

swift에서 쓸 때는 HIMarker 클래스를 marker 변수에 상속해준 후, 내가 기존에 선언해놓은 plotOptions.packedbubble에 해당 marker를 계속해서 이어주면 된다. js의 계층은 그대로 따르되, 클래스 변수를 선언하는 과정이 한 번 더 있어야 하는 것이다.

/// 동그라미 투명도 조절하기
let marker = HIMarker()
plotOptions.packedbubble.marker = marker
plotOptions.packedbubble.marker.fillOpacity = 1

이걸 알기 전에는 계속 프로퍼티가 nil이 떠서 고생했었는데, let marker = HIMarker() 한 줄에 모든 것이 해결되었다. 신기하다.

그래서 나는 햄버거바 숨기기, 크레딧 text 수정, 버블 투명도 조절, 타이틀 디자인, 카테고리 숨기기, 클릭 이벤트 넣기 등의 커스텀을 했다.

/// 햄버거바 숨기기
let exporting = HIExporting()
exporting.enabled = false
options.exporting = exporting

/// 크레딧 자리에 기준날짜 띄우기
let credits = HICredits()
credits.text = "\(getDateToday()) 기준"
options.credits = credits

/// 동그라미 투명도 조절하기
let marker = HIMarker()
plotOptions.packedbubble.marker = marker
plotOptions.packedbubble.marker.fillOpacity = 1

/// 타이틀 디자인
let style = HICSSObject()
title.style = style
title.style.fontSize = "15"
title.style.fontWeight = "bold"

/// 카테고리 숨기기
let legend = HILegend()
legend.enabled = false
options.legend = legend

/// 클릭 이벤트
let chartSeries = HISeries()
plotOptions.series = chartSeries

let chartPoint = HIPoint()
plotOptions.series.point = chartPoint

let chartEvents = HIEvents()
plotOptions.series.point.events = chartEvents

let chartFunction = HIFunction(closure: { context in
  guard let context = context else { return }
  let bubbleIndex: Int = context.getProperty("this.index") as! Int
  // 클릭이벤트 처리 로직
}, properties: ["this.index"])

plotOptions.series.point.events.click = chartFunction

이렇게 커스텀을 해서 결국 이런 식으로 서버에서 넘어오는 데이터를 버블차트에 띄울 수 있게 되었다!!

아쉬웠던 건,

1. 회색인 버블은 약간 진한 색의 데이터라벨을 띄우고 싶었고, 색이 있는 버블은 흰색의 데이터 라벨을 띄우고 싶었는데, 그 부분을 커스텀하는 법을 모르겠다는 것
2. 데이터 라벨의 글자 크기를 버블 크기에 따라 바꾸고 싶은데, 거기까지는 커스텀을 하지 못했다는 것

커스텀 할 수는 있을 것 같은데 서버 데이터도 받아오고 해야 해서 너무 하드코딩이 될 것 같아서 하지 않았는데 .. 나중에 시간이 더 많다면 이 부분 커스텀을 더 해보고 싶다.

나는 원래 개발할 때 xib를 웬만하면 사용하지 않는 편인데, 이번에 외주 맡게 된 앱의 기존 코드를 보니 xib 덩어리라 "그래,,, 이 기회에 xib 연습이라도 더 해보자" 하는 마음으로 새로운 뷰를 xib로 구현하고 있다.

그러던 중, 상상치도 못 한 난관에 봉착했는데, 바로 xib 위에 얹은 테이블뷰에는 원래 개발하던 식으로 그 안에 tableViewCell을 얹고 나서 UI 작업을 하지 못 하는 거였다! 자꾸 TableView 안으로 cell이 안 들어가길래 넣으려고 요리조리 해봤지만, 절대 안 들어갔다 ..

사실 테이블뷰도 기존 스토리보드 위 viewController에서 보던 거랑 조금 다르게 생기긴 했었다. (거기서부터 불안했음)

조금 알아보니, https://stackoverflow.com/questions/41715537/not-able-to-add-static-uitableviewcell-into-tableview 원래 xib에 있는 테이블뷰에는 커스텀 셀을 넣을 수 없고, 따로 xib로 제작해서 넣어야 한다고 한다.

오히려 좋아 ... 이 기회에 xib 마스터 해버리자.

1. TableViewCell 만들기

원래처럼 테이블뷰 셀을 만든다. 하나 달라진 게 있다면, Also create XIB file에 체크를 해줘야 xib 파일이 함께 만들어진다.

그러고 Next를 클릭한다. 이렇게 파일이 두 개 만들어졌다면 성공!

2. 테이블뷰셀 퍼블리싱

원하는대로 테이블뷰셀을 만듭니다! 뚝딱뚝딱 🛠

3. 테이블뷰셀 identifier 지정

1) TableViewCell 클릭 2) Attributes Inspector 클릭 3) identifier 적어주기

이 단계를 꼭 해주셔야 테이블뷰셀을 찾을 때, 테이블뷰셀이 재사용될 때, 해당 셀을 올바르게 불러올 수 있습니다. identifier는 통상적으로 테이블뷰셀의 이름과 동일하게 짓는 경우가 가장 많습니다! 아마 식별하기 편해서 그런 거겠죠?

4. 테이블뷰셀 장착!

이제 다시 원래 테이블뷰가 있던 뷰로 돌아와서 viewDidLoad()나 원하는 곳에

// TableViewCell 불러오기
let nibName = UINib(nibName: "FundDropdownTVC", bundle: nil)
fundTableView.register(nibName, forCellReuseIdentifier: "FundDropdownTVC")

이 코드를 추가해줍니다. nibName: "[identifier]" 에는 3번에서 설정했던 identifier를 넣어주세요.

그 후 tableview datasource cellForRowAt에는 이렇게 적어주면 됩니다. 원래랑 똑같음!

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    // 테이블뷰 셀 불러오기
    let cell = tableView.dequeueReusableCell(withIdentifier: "FundDropdownTVC", for: indexPath) as! FundDropdownTVC

    // 테이블뷰셀에 넣을 데이터 설정
    cell.textLabel?.text = temp[indexPath.row]

    return cell
}

5. 실행시키고 감탄하기

이렇게 하면 끝!!!

👉🏻 참고한 친절한 글들 👈🏻 https://dongminyoon.tistory.com/50 https://sunidev.github.io/ios/make-tableview-of-xib/

저같이 바보같은 행동 하실 분은 없겠지만 비슷한 에러를 겪게 되실 누군가를 위해 기록으로 남깁니다. 사실 심장 떨어질 뻔 한 거 기억하고 싶어서 쓰는 글이기도 합니다.

pr 머지 완료 후 새로운 브랜치에서 프로젝트 파일을 열었는데, 아무것도 없었다..

처음에는 그냥 xcode 버그인 줄 알고 xcuserdata도 지웠다 켜보고 노트북도 껐다 켜봤는데, 저 상태 그대로였다. 멘붕 ... 거짓말 안 치고 한 20번 껐다 켰다.

설상가상 깃에는 .xcworkspace 파일 전체가 안 올라가 있는 상황이라 살릴 수 있는 방법도 없었다. 살리려면 저 20개의 커밋을 리셋해야 하는 상황..!

온 몸에 기운이 다 빠져서 그냥 잘까 하다가 오늘 해결 못 하면 내일은 더 하기 싫어질 거 같아서 일단 깃에 올려뒀던 다른 프로젝트 파일을 살펴봤다. .xcworkspace 파일 안에 대체 뭐가 있는지!!!!

그랬더니 심상치 않은 녀석 하나를 발견할 수 있었다. 요 녀석!!

누가 봐도 .xcworkspace에서 불러올 프로젝트 파일, Pod 파일을 명시하고 있는 파일이었다. 흐흐

근데 내 건? vi 에디터로 열어보니 아무것도 없었다. FileRef가 없고 그냥 워크스페이스만 덩그러니 있는 상태.. 그래서 옛 커밋을 돌려보며 저 파일이 살아있는 커밋을 찾아냈다.

임시 브랜치를 하나 만들어서 그 커밋으로 리셋한 후, 저 파일 내용만 복사해와서 붙여넣어줬다. 그랬더니..!!!!! 열렸다 ... ㅠ

오늘도 알차게 삽질했다! 졸려도 gitignore 할 때는 정신 차리고 하자!