문제 상황

현재 프로젝트는 다음과 같은 구조로 되어있다:

```swift let project = Project( name: "AppCraft", packages: [ .remote( url: "https://github.com/pointfreeco/swift-composable-architecture", requirement: .upToNextMajor(from: "1.8.0") ), .remote( url: "https://github.com/firebase/firebase-ios-sdk", requirement: .branch("main") ) ], targets: [...] ) 이 구조에서:

CoreDatabase가 FirebaseFirestore를 참조 CoreAuth가 CoreDatabase와 FirebaseAuth를 참조 각 모듈이 staticFramework로 설정되어 있어서 중복 구현 에러 발생

Copyobjc[41982]: Class ... is implemented in both ... and ... One of the two will be used. Which one is undefined. 해결 과정

모든 모듈을 staticFramework에서 framework로 변경

swiftCopyTarget( name: "CoreDatabase", platform: .iOS, product: .framework, // .staticFramework에서 변경 ... )

CoreAuth와 CoreDatabase 모듈 통합

Firebase 관련 의존성을 한 곳에서 관리하기 위해 CoreAuth 로직을 CoreDatabase로 이동 의존성 순환 문제 해결 코드 중복 제거

남은 과정

Preview 동작 이슈는 아직 해결해야 할 문제로 남아있음

배운 점

framework와 staticFramework의 차이점

framework

동적 링크 방식 런타임에 로드됨 여러 타겟이 하나의 프레임워크를 공유 메모리 효율적 앱 크기 감소

staticFramework

정적 링크 방식 빌드 시점에 바이너리에 포함 각 타겟마다 복사본 생성 메모리/용량 증가 iOS 버전 호환성 좋음

Firebase같은 외부 의존성은 한 모듈에서 관리하는 것이 좋다

의존성 충돌 방지 코드 중복 최소화 유지보수 용이

이렇게 모듈 구조를 개선하니 빌드는 성공적으로 됐다. Preview 이슈는 다음 글에서 다뤄보도록 하겠다.

총 64장의 카드가 있습니다.

자신의 보드에,

한 종류의 동물카드가 4장이 되거나

모든 종류의 동물카드가 1장씩 깔리면

패배합니다. 😭

🕹️ 게임 진행 방식

1. 총 64장의 카드를 골고루 섞어 분배합니다.

(손에 있는 카드는 상대에게 보이지 않습니다.)

2. 방장 부터 손에서 상대에게 넘길 카드를 한장 고릅니다. (상대에게 보여지지 않습니다.)

3. 카드를 넘길 상대를 선택합니다.

4. 고른 카드를 어떤 카드라고 속일까요? 골라주세요.

“이 카드는 개구리 입니다 ..!”

5. 수비자는 이 카드가 개구리가 맞는지 아닌지를 고릅니다.

“이 카드는 개구리가 맞습니다 !”

6. 공격에 성공했으면 수비자의 보드에, 실패했다면 공격자의 보드에 카드가 깔립니다.

위 예시에서는, 카드가 개구리가 아닌 뱀이기 때문에 수비자의 보드에 카드가 깔립니다.

뱀 카드 한장이 적립됩니다.

7. 카드를 넘길 수도 있습니다.

수비자는 “맞습니다” 또는 “아닙니다” 를 통해 공격을 맞받아칠 수 있지만,

“카드 넘기기” 를 통해 카드의 정체를 모르는 다른 이에게

공격자가 되어 카드를 넘길 수 있습니다.

이 때, 기존 수비자가 공격자로 바뀝니다.

이후 다시 3번 부터 과정이 반복됩니다.

자신의 보드에,

한 종류의 동물카드가 4장이 되거나

모든 종류의 동물카드가 1장씩 깔리면

패배합니다. 😭

패배자는 1명, 나머지는 모두 승자가 됩니다 !

건승을 빕니다.

이 글은 Firebase 프로젝트 설치 후의 내용입니다.

1. Android

Compose Multiplatform 앱 (이하 CMP) 중 Android에 Firebase 프로젝트를 추가해보자.

프로젝트 생성 후 좌측 상단 톱니바퀴 클릭

내 앱 -> 앱 추가 클릭 -> 안드로이드 클릭

google-services.json 다운 ( 폴더에 넣지말고 넘어가세요 )

3번 탭의 가이드를 모두 따라줍니다.

App 파일 -> src -> androidMain -> AndroidMainfest.xml 에 인터넷 권한을 줍니다.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <uses-permission android:name="android.permission.INTERNET"/> <!--This line-->
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> <!--This line-->

   ....

composeApp -> src -> androidMain -> kotlin -> MainActivity.kt 에서 Firebase 를 init 하면 성공

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        Firebase.initialize(this)
        setContent {
            App()
        }
    }
}

2. iOS

먼저 App Folder 의 iosApp를 Xcode로 실행시켜주세요.

Firebase -> 앱 추가 를 다시 눌러서 이번엔 iOS를 추가합니다.

앱을 등록해야하는데,

좌측 상단 iosApp 클릭,

Signing & Capabilities 에서

Bundle Identifier 를 복사해서 앱 등록시에 붙여넣기 해주세요.

안드로이드처럼, google-service 다운 받아서, iosApp 폴더 안에 넣어주세요.

좌측 상단에 Add Package Dependencies 클릭

https://github.com/firebase/firebase-ios-sdk 를 검색해서 Add Package 해줍니다.

이후 iOSApp.swift 파일에서 FirebaseApp.configure() 입력 후 cmd + b 로 빌드에 성공하면 완료

import SwiftUI
import FirebaseCore

@main
struct iOSApp: App {

    init() {
        FirebaseApp.configure()
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

No such module 'FirebaseCore' 오류 대응

이거 때문에 하루를 날렸는데,

먼저

터미널로 iosApp 폴더까지 들어가줍니다.

pod init 

pod install //pod 를 설치해주세요.

이후 폴더를 들어가보면, iosApp.xcworkspace 가 추가되어있습니다.

좌측 상단 iosApp 클릭,

TARGETS 클릭 후 General 를 클릭해주세요.

Frameworks, Libraries, and ... 안에 + 를 누르고

Firebase Package 안에 내용물을 다 때려넣어주세요.

이렇게 하니 성공했습니다 :)

이제 진짜 개발 시작...!

나의 어플리케이션에 인스타그램 피드를 가져오자

인스타그램 연동을 위해서는 몇가지 준비물이 필요하다.

0. Meta for Developers 의 테스트 앱
1. 인스타그램을 연동할 어플리케이션
2. 페이스북 아이디
3. 인스타그램 비즈니스 계정

0번 테스트 앱 준비

0번의 준비가 가장 까다롭다. https://developers.facebook.com/?locale=ko_KR 에 가입한 후 , 앱을 하나 만들자 이런식으로 앱을 만들고 나면 , 테스트앱을 만들어야한다.

일반 앱에는 권한을 줄 수 없다. 테스트앱에만 모든 권한을 줄 수 있고, 테스트앱을 만들어야만 페이스북 앱 검수를 받을 수 있다.

당신이 어플에 인스타그램 연동 기능을 넣겠다고 다짐한 순간 까다로운 Apple 심사와 함께 더 까다롭다고 소문난 Meta 앱 검수를 함께 진행해야한다.

테스트앱을 만들고 나면

Instagram Basic Display, Facebook 로그인 두 제품을 선택하고 안에 앱 번들 등을 입력해줘야하는 번거로운 작업을 완료해 두어야 한다.

일반 앱에서는 개발모드에서 페이스북 로그인 기능을 넣어놔도 적용이 되지 않는다. 라이브 모드로 바꿔야하는데, 인스타그램 권한이 없기 때문에 라이브모드로 바꿔도 말짱 도루묵.

테스트앱에서는 개발모드에서도 모든 기능이 사용가능하다. 단,내가 관리자가 아니라면,

테스터를 추가해주어야한다.

다른 블로그에서 흔히 보여주는 인스타그램 테스터와는 완전 다르다. 저 테스터는 "페이스북 테스터" 이고, 인스타 연동을 해본적도 없는 블로그에서 보여주는 테스터는 이 인스타그램 테스터이다.

앱에 정식으로 연동기능을 넣으려면 인스타그램 테스터는 단 한 계정도 필요가 없다. 갖다 버려도 좋다.

우린 페이스북 로그인을 통해 인스타그램 정보를 가져와야 하기 때문에 "페이스북 테스터"로 등록해야한다. 인스타그램 OAuth 로그인이라는 것은 존재하지 않는다.

위 준비물이 준비 되었다면 인스타그램과 페이스북 계정의 이해가 필요하다.

인스타그램 계정 == 페이스북 계정 ...?

메타 ( 구 페이스북 ) 은 인스타그램을 인수했다. 그래서 인스타그램 계정과 페이스북 계정이 1대 1 대응을 이룬다고 생각할 수 있지만 그렇지 않다.

인스타그램 계정 여러개가 하나의 페이스북 계정에 연결된다. 페이스북 계정에 연동하려면 페이스북 페이지에 연결을 해야한다.

자세한 과정은 https://antennagom.com/525 에서 확인 할 수 있다.

내 인스타그램 비즈니스 계정을 페이스북 아이디에 연동을 하고나면 이제 정말 연동을 할 준비가 된 것이다.

Graph Api ???

그래프 api 는 메타에서 만든 api 이다. Rest Api 의 OverFetching 또는 UnderFetching 의 단점을 보완하는 강력한 api라고 한다. 니꼬 선생님의 유튜브에서 자세한 설명을 확인 할 수 있다.

아무튼 우리는 이 graph api를 활용해서 인스타그램 정보를 가져와야한다. 그래프 Api 탐색기를 준비하자.
( 연동이 끝나는 시점까지 계속 사용할 예정이니 오른쪽 상단 탭에 항상 하나씩 올려놓도록 하자 )

자 그럼 정말 준비물은 끝났다. 토큰을 이해하러 가보자.

Fxxxing Token

나는 연동을 하는 과정에서 토큰에 대한 이해가 제일 어려웠다. 공식문서에서는 토큰을 자세하게 설명해주고 있지 않다.

1. 액세스 토큰

액세스 토큰 혹은 OAuth Token 은 카카오톡 로그인 네이버 로그인 처럼 일반적인 써드 파티 로그인을 했을 때 발급되는 토큰이다. 이 토큰은 로그인 기능을 제공함과 동시에 다른 여러 기능에 액세스 할수 있게 도와준다.

토큰을 먼저 발급 받아보자.

Swift Package Manager 을 사용하던, Cocoapods를 사용하던 원하는 방법으로 페이스북 SDK를 프로젝트에 설치한 후 버튼을 하나 만들자.

Firebase 공식 문서 에서 잘 설명해주고 있다.

버튼을 만들고 나면

요놈을 임포트 해주고,

        let manager = LoginManager()
        manager.logIn(permissions: ["public_profile", "instagram_basic", "pages_show_list"], from: self) { result, error in
            if let error = error {
                print("Process error: \(error)")
                return
            }
            guard let result = result else {
                print("No Result")
                return
            }
            if result.isCancelled {
                print("Login Cancelled")
                return
            }

        }

위의 코드와 함께 로그인을 세팅해주자. permissions 에는 우리가 사용할 인스타그램 권한을 넣어주면 된다. "public_profile"은 페이스북 정보에 대한 접근 권한. "instagram_basic"은 인스타그램 정보에대한 접근 권한. ( 팔로워 수, 이름, 닉네임 등등 에 대한 권한이다) "pages_show_list"는 페이스북 페이지 목록에 접근 권한이다. (페이스북 페이지에 접근이 가능해야 페이지에 연결된 인스타그램 계정에 연동이 가능하다)

자 이제 액세스 토큰으로 어떻게 내 인스타그램 계정을 가져올지 고민해보자.

그래프 Api 탐색기를 켜고 오른쪽 Generate Access Token을 눌러보자

다음으로 이렇게 비즈니스 계정을 선택

다음으로 페이스북 페이지를 선택하고

권한을 허용해주면 액세스 토큰이 마침내 발급된다.

발급받은 토큰을 활용하는 방법은 다음 장에서 다뤄보겠다.

Any Problem?

정말 구글에 나와있는 대부분의 인스타그램 연동글을 본 것 같다.

여기에 나와있는 모든 글들은 제대로 연동을 하고 있지 않다.

대부분의 경우에서 위와 같은 테스트 사용자를 만들어서 토큰을 발급하고 피드를 받아오거나 연동하는 일을 진행했을 것이다.

하지만 우리가 정말 인스타그램 연동을 해야하는 어플리케이션을 앱스토어에 내야한다면?

여기 "사용자 토큰 생성기" 에 나와 있는 토큰은 도대체 어디에서 발급되는 것인가?

이렇게 토큰을 생성하는 일도 우리 어플리케이션 안에서 이루어져야한다.

그래서 페이스북 개발자 페이지의 DOCS를 살펴본다. 정말 놀랍게도 iOS는 Objective-C 로 작성되어있다. 이것은 고사하고, 토큰이 정말 많고 어느게 어떤 토큰인지 제대로 설명하고 있지도 않다.

지난 한 달 간 내가 어떻게 공식 문서없이 토큰을 발급받아 나의 어플리케이션으로 인스타그램 피드를 불러오는데 성공했는지, 그 과정을 앞으로 적어보려고 한다.

당신이 테스터로 등록하지 않는 방법으로 인스타그램 연동을 구현하려고 했다면 나의 블로그를 찾은 것이 신의 한수가 될 것이다.

Problem

"피플"은 Single, Observable을 정말 많이 리턴한다.

코드를 살펴보자

    func fetchFive() -> Single<[CalendarModel]> {


        return Single.create() { observable in


            let urlString = "\(self.baseUrl)/api/v1/account/calendar/after/test?minusDay=5&accountUuid=\(UserDatabaseManager.shared.myUserModel!.uuid)"

            guard let url = URL(string: urlString) else {
                observable(.error(DatabaseFetchingErrorType.urlFailedError))
                return Disposables.create()
            }

            var request = URLRequest(url: url)
            request.httpMethod = "GET"
            request.setValue("application/json", forHTTPHeaderField: "Content-Type")
            request.setValue(UserDatabaseManager.shared.jwtToken, forHTTPHeaderField: "X-AUTH-TOKEN")
            request.timeoutInterval = 10

            AF.request(request).responseData { response in
                switch response.result {
                case .success(let data):
                    if let calendarModelArray = self.decode(jsonData: data, type: [CalendarModel].self) {
                        observable(.success(calendarModelArray))
                        print("[Calendar 5] fetching 성공")
                    } else {
                        observable(.success([]))
                    }

                case .failure(let err):
                    print("🚫[Calendar 5] 에러 \(err)")
                    observable(.error(DatabaseFetchingErrorType.fetchingFailedError))
                }
            }

            return Disposables.create()
        }
    }

Calendar Manager의 fetchFive라는 함수이다. 최근 5개의 CalendarModel을 리턴한다. Single 로 리턴한다.

다른 코드들 또한 이러한 형식을 많이 따른다. request에 필요한 파라미터를 담고, 리퀘스트를 디코딩해서 결과를 얻어 Bind한다.

그런데, 벌써 코드가 30~40줄 정도가 되는 것 같다.

이러한 함수가 20 ~ 30개가 되니 코드의 양은 너무 방대해져버렸다.

Param과 Path를 인자로 받아 원하는 타입의 Single을 리턴하는 함수를 만들어보자.

func single<T: Codable>(path: String, type: T.Type, params: [String: Any]?) -> Single<T>

선언은 이렇게한다. path 와 type, 그리고 파라미터는 없을 수도 있으니까 옵셔널로 받는다.

            var queryParams = ""
            if let params = params {
                queryParams = params.map { k, v in "\(k)=\(v)" }.joined(separator: "&")
            }

            var fullPath = path.hasPrefix("http") ? path : self.baseUrl + path
            if queryParams.count > 0 {
                fullPath += "?" + queryParams
            }

파라미터에대한 처리는 위처럼 해준다.

&로 key=value를 묶어 마지막에 path 뒤에 ? 를 붙여 fullPath를 완성한다.

            var request = URLRequest(url: url)
            request.httpMethod = "GET"
            request.setValue("application/json", forHTTPHeaderField: "Content-Type")
            request.setValue(UserDatabaseManager.shared.jwtToken, forHTTPHeaderField: "X-AUTH-TOKEN")
            request.timeoutInterval = 10

            AF.request(request).responseData { response in
                switch response.result {
                case .success(let data):
                    if let returnData = self.decode(jsonData: data, type: type.self) {
                        observable(.success(returnData))
                        print("[\(type)] fetching 성공")

                    } else {
                        observable(.error(DatabaseFetchingErrorType.encodingFailedError))
                    }

                case .failure(let err):
                    print("🚫[\(type)] 에러 \(err)")
                    observable(.error(DatabaseFetchingErrorType.fetchingFailedError))
                }
            }
            return Disposables.create()

그리고 나서는 똑같이 함수를 적어 리턴해주면 제네릭 함수가 완성된다.

결론

    func fetchFive() -> Single<[CalendarModel]> {
        return single(path: fivePath, type: [CalendarModel].self, params: ["accountUuid": UserDatabaseManager.shared.myUserModel!.uuid])
    }

세 줄로 줄었다.

하지만 지금당장은 Single 만 사용을 해보았고, 다른 복잡한 형태의 제네릭 함수구현을 위해서는 조금 더 공부를 해보아야겠다.

"피플"은 10개정도의 Manager 들에 의해 BackEnd 소스들과 http 통신이 이루어진다. 가장 많은 코드를 가진 Manager은 역시 사연부분을 담당하는 DontionDatabaseManager 이다.

리팩터링을 진행하기 전까지 약 870줄 정도의 코드를 가진 Massive한 파일이다.

1. Decode

HTTP 통신을 많이하는 앱을 만들어보았다면 Decode를 해야하는 모델이 상당히 많다는 것을 알고 있을 것이다. 디코딩을 매우 편리하게 도와주는 퀵타입의 존재도 분명히 알고 있을 것이다.

    private func decodeNoticeModel(of jsonData: Data) -> [NoticeModel]? {
        do {
            let noticeArray = try JSONDecoder().decode([NoticeModel].self, from: jsonData)
            return noticeArray
        } catch {
            print("🚫 [공지] 디코딩 실패 !:\(error)")
            return nil
        }
    }

이전까지는 이렇게 각 모델마다 디코딩을 해주는 코드를 작성해 디코딩을 해주었다. 하지만 하나 둘 쌓이는 모델들...

이렇게 디코딩을 하게되면 모델 수만큼 디코딩을 해주어야 하고 그만큼 코드의 양도 방대해지는 불상사가 일어나게 된다. (지금까지는 이런 멍청한 방법을 사용해왔다.)

나름 중복코드를 줄이고자 10개 정도의 Manager들이 상속받고 있었던 CommonBackendType에 공통 Decode 코드를 추가해주었다.

    func decode<T: Decodable>(jsonData: Data, type: T.Type) -> T? {
        do {
            let data = try JSONDecoder().decode(type.self, from: jsonData)
            return data
        } catch {
            return nil
        }
    }

코드를 잘 살펴보면 제네릭 선언부의 T를 제외하고도 returnType이라는 파라미터에 타입자체를 넣어주었다. 단톡방에 물어보니 , 꺽새 안에 들어가는 T는 제네릭 함수에 T의 제약만을 걸어주는 것이지 T에 대한 제네릭 함수이다 라는 것을 알려주지 않는다고 한다.

예를 들어, returnType을 적지 않고 그대로 T의 옵셔널을 리턴해준다면 decode함수 선언부에서는 에러가 나지 않지만, decode를 가져다 사용하는 부분에서 분명 에러가 날 것이다.

generic function을 specify 하라는 에러가 나올 것이다. T의 타입을 정확히 규정해달라는 말이다.

Bad

    func test<T: Decodable>(data: Data) -> T? {
        do {
            let data = try JSONDecoder().decode(T.self, from: data)
            return data
        } catch {
            return nil
        }
    }

이런 함수를 사용한다고 해보자

if let returnData = self.test(jsonData: data) 

data를 나쁜 함수로 디코딩을 해준다면,

정확히 T를 추론할 수 없다고 나온다. (Generic paramter 'T' could not be inferred)

그렇다면 타입을 직접 입력해주면 ?

if let returnData = self.test<T>(jsonData: data) {

Specialize 할 수 없다는 에러를 뱉는다. (Cannot explicitly specialize a generic function)

결론

제네릭 함수를 만들고 리턴을 제네릭으로 해야한다면 정확한 타입을 파라미터로 받아주자!

1. 개발 환경 세팅

시작이 반이라고, 때려치고 싶은 부분이다.

https://docs.flutter.dev/get-started/install/macos 플러터 홈페이지에서 플러터를 다운받고

Android Studio, Xcode 에서 시뮬레이터들을 설치해주자. M1 칩이면 Android 시뮬레이터는 arm64 로 된 것들을 설치하면 된다.

플러터 개발은 Jetbrains 의 Intellij 나 Android Studio 를 통해 하면 된다. 안드로이드 스튜디오는 뭔가 구려보여서 Intellij 를 선택했다. ( 둘이 매우 비슷하다 )

plugin에서 플러터를 설치해주면 끝난다.

New Project 위에 Flutter 을 설치한 경로를 설정해주고, 알맞은 위치에 새로운 플러터 프로젝트를 만드는 것으로 환경설정은 끝난다.

*내 기억으로는 React-Native Cli 환경설정이 백배는 어렵다 *

2. Widget

Flutter 개발이 Swift UI 와 굉장히 유사하다고 느낀 점이 있다. Swift 는 ViewController 라는 하나의 화면을 기준으로 개발이 이루어진다면 ( 이 또한 아키텍쳐에 따라 매우 상이하다. Ribs 아키텍쳐는 완전 다른 개념을 갖고 개발한다. ) SwiftUI 는 말 그대로 UI 를 쌓는 식으로 개발이 이루어지는데, Flutter 역시 마찬가지다.

Swift에 View 가 있다면 Flutter 에는 Widget이 있다.

이 페이지에는 30개가 넘는 Widget 이 쌓여있는 형태이다.

가장 먼저 앱을 구성하는 MaterialApp 위젯 .

화면을 상 중 하로 나누는 Scaffold 위젯

맨위에 AppBar 위젯 안에 Text위젯, IconButton 위젯

ListView 위젯 안에 ListTile 위젯 등등

모든 것을 위젯이라고 부른다.

기본 디자인이 매우 구글틱한 것은 매우 마음에 안들지만 나중에 바꿀 수 있다.

중요한 위젯들을 공부해보자.

• Scaffold

  화면을 상 중 하로 나눈다. 요즘 어플리케이션들은 대부분 이러한 형태를 띈다. 맨 위에 들어갈 수 있는 AppBar, 가운데에 들어가는 Body, 맨 아래에 들어가는 BottomNavigationBar 등이 있다.

• SizedBox Vs Container

  아직은 큰 차이는 모르겠지만 Container 가 좀 더 무거운 위젯이라고 한다. 남용하면 SizedBox 를 쓰라는 Lint 가 나온다. 크기와 관련된 width, height 등을 설정하지 않으면, SizedBox : child 에 맞춰 크기가 정해진다. Container: 최대 크기로 늘린다. 이러한 차이가 있다.

• Buttons

  TextButton IconButton ElevatedButton 여러 버튼들이 있지만 이런 세개의 버튼이 있고, 각 버튼은 종류에 따라 child 가 달라진다. TextButton 의 child 는 당연히 Text 위젯이 된다. child 와 onPressed 함수 등을 파라미터로 넣을 수 있다. Dart 언어는 Swift 처럼 익명함수 ( 클로저 ) 를 지원한다. onPressed: () { function(); } 이 가능하다.

• AppBar

  화면 맨 위에 들어가는 길다란 Bar 이다. Title : 중앙 제목 Leading : 왼쪽 아이콘 Actions: [우측 아이콘들]

• BottomNavigationBar

  Items 들로 구성된다. 아래에 들어가는 탭 아이콘이라고 생각하면 된다. 아이템이 하나면 에러, label 이 하나라도 비어있으면 안된다.

3. Custom Widget

위에 2번에서 공부한 내용정도면 다른 위젯들을 검색해보고 공부하는데에 있어서 전혀 문제되지 않는다.

하지만 항상 Custom , 내 맛대로 커스텀해서 사용하는 것이 훨씬 어렵고, 결국 사용해야 하는 것은 Custom Widget이 된다. 커스텀 위젯을 공부하기전에 State라는 개념을 공부해야한다. 이것이 Native 어플리케이션 개발과 아주 큰 차이라고 생각한다. 그러면서도 아주 편리한 기능이다. 다음 포스트에서 State 에 대해 공부해보자.

2020년 10월에 Android 공부를 시작으로 입문하게 된 어플리케이션 공부. 2021년 2월에는 맥북프로를 구매하며 iOS에 입문하게 되었고 6월에는 첫 어플리케이션을 배포했다. 하지만 분명 나는 아직 대학생 신분으로, 부족한 경험을 채우기 위해서는 어찌 됐든 경험을 해보는 것이 중요했고, iOS와 안드로이드를 모두 해결하기 위해 결국 12월에는 Flutter을 공부하게 됐다.

2. React Native vs Flutter

Meta vs Google 이라고 봐도 무방할 정도의 라인업. 하이브리드 어플 계의 부동의 투탑이라고 생각한다. 하나를 공부하기 시작하면 다른쪽으로 넘어가는 것이 쉽지 않기에 고민을 거듭하다 결국 Flutter 로 정하게 되었다.

• JavaScript ..? Dart ..?

  iOS 를 공부하며 swift 로 코딩테스트를 수차례 통과해봤는데, 코딩테스트 연습 사이트인 백준에서 골드 4 ~ 5정도의 문제나, 프로그래머스에서 2레벨정도의 문제를 풀 수 있는 능력이 있다면 ( 어떤 언어로든 ) 두 언어를 배우는 데에는 전혀 문제가 없을 것이다. 코딩테스트를 볼 주 언어가 되지 않는다면, 어플리케이션을 만들 때 쓰이는 문법은 아주 한정적이다.

ReactNative 와 Flutter 을 비교하는 많은 블로그들에서 언어가 다르다 는 것을 강조하고 있지만, 이것은 다른 언어를 한번도 배워보지 않은 사람들에게 해당한다고 생각한다. 둘 다 별로 어렵지 않다.

3. React Native를 선택하지 않은 이유

먼저 내가 React Native에 혹했던 점을 알아보자.

• 두 가지의 개발방법

  Expo 를 이용한 방식과 , Cli 를 사용한 방식 두 가지가 있다. Expo는 조금 더 초보자를 위한 개발방법, Cli 는 좀 더 숙련자를 위한 방법이다.

• RN + Native

  JS 코드에 Native 코드를 추가해서 앱을 만들 수가 있다.

나는 두 번째 RN + Native 이 Native앱 을 공부한 사람으로써 엄청난 어드밴티지로 다가왔다.

• 너무 오래걸리는 빌드

  시뮬레이터 키는데 너무 오래걸리고 많이 공부해보지 않아서 그럴지도 모르지만 , 버전에 따른 에러가 엄청 많은 것 같다.

앱 개발자로서 고쳐야한다고 생각하지만, 나는 앱을 빌드를 정말 자주하면서 개발한다. RN 의 빌드 속도는 ** 정말 매우, 매우 느리다. **

4. Flutter

구글에서 만든 Dart 언어를 사용한다. 2020년 가장 인기 없는 언어 중 하나로 뽑혔다는데, 언어는 별로 중요하지 않다고 생각한다. 개발자의 역량이 중요하지

앞으로 내가 포스팅하는 글에는 JetBrains 의 Intellij IDE 를 이용한다. 프로버전은 유료지만.. 기분이라도 내고 싶었다.

코딩애플의 강의를 들으며 입문하였고, 이 강의는 초심자를 대상으로 한 강의이지만 , 나는 한번 앱을 공부해본 사람의 입장에서 궁금했던 점을 직접 찾아 덧붙여보았다.

열심히 공부해보자 !

iOS에서 DB로 AWS를 활용해보자

주변 앱개발 공부를 하는 많은 사람들이 초반엔 Google Cloud Platform ( GCP ) 를 외부 DB로 활용한다.

-Realtime database-

나도 GCP를 1년정도 사용해본 결과 정말 어플리케이션 친화적이고 초보자들이 활용하기에 안성맞춤이라는 생각이 들었다.

실시간으로 눈에 보이는 데이터들의 변화과정은 어떠한 DB에서도 제공되지 않는 아주 특별한 기능이라고 생각한다. 실시간으로 수정하고, 실시간으로 확인할 수 있다.

하지만 얼마전 헬로비즈 ( 외주업체 ) 의 CTO 분에게 컨설팅을 받은 결과 GCP 도 정말 좋은 플랫폼이지만 결국 현업으로 뛰어들게 된다면 모두 AWS 를 활용한다는 조언을 해주셨다. 또한, 막상 배워놔도 나쁠것이 전혀 없다고... 회사들이 AWS 를 활용하는 가장 큰 이유는 바로 "돈" 이다.

GCP 가 AWS 에 비해 가격이 현저히 높다고 한다. 사실 나같은 초보 앱 개발자들이 가격의 차이를 느낄만큼 큰 데이터를 다룰일이 없었기에 전혀 생각하지 못했던 부분이다. ( 사실 아직 무료단계에서도 벗어나지 못한 양의 데이터만 다루고 있었다 )

분명 앱 개발을 초보 단계에서 멈출 생각이 없기에 이번 기회에 진지하게 AWS 를 어플리케이션에 테스트로 적용해보자 라는 생각으로 공부를 시작했다.

공부하면서 느꼈지만 확실히 AWS 는 앱 친화적이라는 생각은 들지 않는다. HostPage 를 웹에 두고, 앱은 Sub 로 활용하는 회사들에서 많이 활용하지 않을까 싶다.

AWS Cognito 를 이용하여 로그인 기능을 추가해보자

사실 AWS 홈페이지에 가보면 GCP 만큼 자세하지는 않지만.. 꽤나 자세하게 로그인, 로그아웃, 회원가입 등 Auth 기능을 추가하는 방법을 알려주고 있다. 가이드라인에도 잘 나와있다. 그런데 이상하게 우리나라 페이지에는 SwiftUI 를 이용한 가이드라인이 소개되어있다. 나는 당연히 Swift로 설명해보려고 한다.

AWS 가이드라인에는 간단한 Todo 앱을 AWS Cognito, DB, Storage 에 저장, 업데이트, 삭제 등을 하며 소개하고있다.

1. UserData 클래스를 만들고 Note 클래스도 만들어주자.

2. 터미널에서 Amplify를 활용하기 위해 amplify CLI 를 설치하자

npm이 설치되어있지 않다면 다른 방법도 많다. 이 방법으로 설치되지 않는다면 무적의 sudo 를 사용하는 것을 추천한다.

3. 디렉토리로 가서 Amplify init

git 이나, cocoapod 과 비슷하게 amplify init 으로 초기화한다.

여기서 중요한 점. 처음 aws 를 이용하시는 분들은 profile 이 없다고 메세지가 나온다.

그럴 땐 profile을 생성해주어야한다.

aws configure --profile #name 을 통해 생성하고 나서

AWS Profile 설정 가이드라인으로 가서 지역등록과 인증 키를 등록해주어야 앞으로 과정이 정상적으로 작동될 것이다.

4. pod init, pod install !

코코아팟에 amplify 와 tools 를 넣고 인스톨해주자.

5. json 파일을 넣어주자

지금까지 잘 따라왔다면 아래처럼 두개의 json 파일이 생긴다. 프로젝트 파일안에 넣어주자

이 두 파일이 나오지 않았다면 AWS Profile 이 제대로 되지 않아 생기지 않았을 확률이 매우 높다. 다시 한번 위의 과정을 천천히 해보길 바란다.

6. Backend 파일 생성

Backend.swift 라는 파일을 만들고 아래를 복붙 해주자.

import UIKit
import Amplify

class Backend {
    static let shared = Backend()
    static func initialize() -> Backend {
        return .shared
    }
    private init() {
      // initialize amplify
      do {
        try Amplify.configure()
        print("Initialized Amplify");
      } catch {
        print("Could not initialize Amplify: \(error)")
      }
    }
}

7. Appdelegate 설정

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.

        // initialize Amplify
        let _ = Backend.initialize()

        return true
    }

didFinishLaunchingWithOptions 에는 항상 뭔가가 들어간다.

겉으로는 쉬워보이지만 사실 Profile 에서 엄청난 삽질을 했다는... 다음 포스트에서는 로그인과 로그아웃 기능에 대해 살펴보겠다.

연속 합 문제를 Swift로 풀어보자

이 문제를 1차원 적으로 접근해보자.

for 문을 두번 돌려서 문제를 푼다고 생각 할 것이다.

예제 ( 10, -4, 3, 1, 5, 6, -35, 12, 21, -1 ) 을 예로 들면,

10 부터 -1 까지 돌려가며 최댓값을 저장하고,

-4 부터 -1 까지 돌리며 최댓값을 저장하고,

3 부터 -1, 1부터 -1 .... 그렇게 n * (n + 1) / 2 만큼 배열을 돌리며 최댓값을 구할 것이다.

dp를 사용해보자

한번만 for문을 돌려서 풀 수 있는 방법을 고민해보자.

먼저 for 문을 돌리기 전 , 모든 숫자가 음수라면, 즉 원소 중 최댓값이 음수라면 정답은 음수가 될 것이다.

ans = numbers.max()! , 그리고 ans < 0 이면 print(ans) 로 솔루션을 종료한다.

이러한 특수상황이 아닐 때를 고민해보자.

1

• 10
• tmp = 10
• ans = 21

먼저 10 이 나온다.

10은 양수이다. 현재 ans 에는 21 ( numbers.max()!) 이 저장되어있다. tmp 에 10 을 더해준다

2

• 10 -4
• tmp = 6
• ans = 21

다음에 -4 가 나온다. -4는 음수이다. 따라서 -4 부터 시작하는 연속 된 수들의 합은, 10부터 시작하는 연속된 수들의 합보다 클 수가 없다. 따라서 tmp 에는 -4, 10 -4 =6 중 더 큰 수인 6이 들어간다.

3

• 10 -4 3
• tmp = 9
• ans = 21

다음은 3이 나온다. 10 -4 + 3 , -4 + 3 , 3 중 가장 큰 9 가 tmp 에 들어간다. 아직 ans 이 tmp 보다 크다.

여기까지 했으면 감이 잡힌다.

어찌되었던 numbers[0] 부터 numbers[i] 까지의 합이 numbers[i] 보다 크다면, 앞으로도 연속된 수의 합은 전자가 더크다.

코드

엑셀 데이터를 json 으로 변환해보자

데이터를 다루다 보면 절대로 빠지지 않는 형식이 몇 가지 있다. 그중 하나는 xls 엑셀 데이터일 것이고 ,

또 하나는 json 데이터 일 것이다.

그렇다면 이 엑셀 데이터를 json 으로 변환하는 방법을 알아보자.

1. xls -> json Dictionary

먼저

http://shancarter.github.io/mr-data-converter/

로 이동하자.

이 사이트에서, 데이터를 xls 데이터를 json Dictionary로 변환이 가능하다.

2. json Dictionary 에 맞는 클래스 형식 파악하기

https://app.quicktype.io/ 로 이동해서 방금 구해온 데이터를 복사 붙여넣기를 하면,

어떤 식으로 클래스를 구성해야 할 지 알 수 있다.

3. Xcode 에서 jsonDecoder 로 parse

                    if let jsonData = try? String(contentsOf: url!).data(using: .utf8) {
                        let decoder = JSONDecoder()

                        let itemArr = try! decoder.decode(ItemArr.self, from: jsonData)

jsonDecoder을 이용해서 typeAlias로 되어있는 Welcome으로 디코딩을 해주면 우리가 쉽게 사용할 수 있는 WelcomeValue 라는 클래스로 변환이 된다.

반응형 프로그래밍으로 로그인 화면을 만들어보자.

이 화면을 구현해보자.

Email은 "@" 와 "." 이 들어가있어야 빨간색 점이 사라지며 Valid 되고, password는 총 6자 이상이어야 Valid 되며 빨간 점이 사라진다.

그리고 Email, Password 둘다 Valid 되어 빨간점이 없어야 LogIn 버튼이 활성화 Enable 된다.

1. RxSwift 없이

내가 만약 RxSwift를 알지 못했더라면, 일단 ViewController 에 TextFieldDelegate를 확장해준 후,

아래와 같이 textFieldDidEndEditing 에서 처리를 해줄 것 같다.

Delegate 또한 ReactiveX 와 같이 어느정도 실시간 데이터 처리를 해줄 수 있기 때문. 그렇다면 LoginButton 의 Enabled 여부는 어떻게 해줄까?

역시, textFieldDidEndEditing 안에 조건을 걸어 Email, Password 둘다 Valid 하다면 enable 해주면 된다.

Delegate을 걸어주는 것은 항상 잊지 말자!

이렇게 하면 위처럼 어느정도 로그인이 구현되었음을 알 수 있다.

하지만, Reactive를 사용하지 않고 작성한

이 코드는 치명적인 단점이 있다.

textFieldDidEndEditing 즉, textField의 Editing이 끝난 시점에서 함수가 실행된다는 뜻인데, Editing 이 끝난다는 것은 커서를 다른쪽으로 옮겼을 때 라는 말이 된다. 따라서 실시간처리로 볼 수 있지만 완벽한 실시간 데이터 처리라고는 할 수 없다.

그렇다면, TextFieldDelegate 에 더 많은 override 함수 안에서 해답을 찾을 수 있지 않을까?

하고 찾아봤지만 역시 녹록치않다.

이렇게 우리는 RxSwift에 발을 담구게 된다.

2. MVVM 무시, RxSwift

우리가 생각해야할 객체는 총 다섯 개다. idTextField, pwTextField, idValid, pwValid, LoginButton

먼저 idTextField를 Observe 해보자.

idField의 text 를 orEmpty 로 옵셔널을 벗겨주고, checkEmailValid 되었는지 매핑해서 뱉어준다. 그러면 ob1 은 Bool 타입 Observable 이 된다. distinctUntilChanged() 는 같은 값이 들어오면 무시하는 메서드이다.

패스워드 역시 같게 해주고, 우리는 이 두 Observable 들을 idValidView, pwValidView에 binding 해줘야한다.

이렇게 두 Observable 을 뷰에 bind 해주었다.

이제 남은 LoginButton 은 두 Observable 들이 모두 true 일 때 라는 조건을 받아와야한다. Observable 들을 Combine 해주자.

이렇게 해주고 실행을 시키면,

실시간으로 아주 잘 변하는 것을 볼 수 있다. 아름답다. 두 Textfield 의 text를 Observe 하고 있는 ob1, ob2 두 Observable 들을 idValidView 와 pwValidView 에 bind 해서 빨간점을 상황에 맞게 없애주고, ob1, ob2 를 세트로 묶어 LoginButton 에 bind 해서 상황에 맞게 Enable 시켜준다.

ob1, ob2 는 두 개의 View에 bind 되어있다. disposed 되기 전까지는..

코드를 보면 위와 같다.

한 함수에서 모든 것을 처리하니 나중에 더 많은 Observable들을 사용하게 되면 유지 보수가 힘들어질 것이다.

대표적인 어플리케이션 아키텍쳐인 MVVM 모델을 사용해서 이 코드를 정리해보자.

3. MVVM , RxSwift

ViewModel 을 만들자. 그리고 checkEmailValid 와 checkPasswordValid 를 모두 뷰 모델로 보낸다.

우리가 View 에서 Input 받는 것은 idTextField 와 PasswordTextField 두개이다. 이 두 인풋값이 Valid 한지 안한지 판단은 ViewModel 에서 해준다.

ViewModel 의 setEmailText , setPwText로 보내주자.

isValid 로 email, password의 Valid 유무를 담아줬다. 이제 isValid 를 idValidView, pwValidView 에 Output으로 넣어줘야하는데 isValid 는 Bool 타입 Observable 이 아니다. 그냥 Bool 이다.

외부에서 넘어온 값을 받기 위해 BehaviorSubject 로 받아주자.

각 Subject 에 담아주고 View 들에 Bind 해주자.

이렇게 하면 ViewController 에서 bindInput() 함수에서 , 우리가 받아올 idText 와 pwText를 인풋받아와서 ViewModel 에서 Text가 Valid 한지 판단해준 후,

bindOutput() 함수에서 View들에 적용시켜주었다.

여기서는 Model이 딱히 필요하지 않아 사용하지 않았지만, View와 ViewModel 의 역할을 구분지어서 사용하게 해주었다.

끝!

RxSwift?

지금까지 벨로그에서 RxSwift 에 대해 여러 포스트를 남겼다. 유튜브 "곰튀김" 님의 강의를 듣고 입문을 하게 된 것인데, 강의를 들으면서 이 기술을 어디에 써먹을 수 있을까... 를 계속 생각하면서 들었다.

공부를 하면서 느낀 점이 있는데, 나는 지금껏 앱 개발을 공부하면서 알게 모르게 비동기적인 반응형 프로그래밍을 구현하고 있었다. 이렇게 할 수 있었던 이유는, 비동기적 프로그래밍을 구현해주는 라이브러리가 많이 나와있어서이다. 예를 들어, KingFisher 이라는 이미지 비동기 처리 라이브러리이다. 어느정도 캐시 처리도 해주고 있어서 내가 아주 애용하는 라이브러리인데, RxSwift를 공부하고 이 코드를 보면 참 닮았다는 생각이 많이 든다. 또, Firebase의 코드를 살펴보면,

이렇게 Firebase 역시 Observe라는 단어를 쓰는 것이 참 닮았다는 생각이 든다. Firebase의 Observe는 RxSwift의 subscribe와 비슷한 기능을 한다.

RxSwift를 공부해야겠다고 생각이 들었던 이유는 Firebase에서 생겼다. 위에 코드를 보면 알겠지만 Firebase 의 RealtimeDatabase 는 위 사진처럼 데이터 트리 형태를 띈다. 그렇다면 깊숙하게 있는 데이터를 꺼낼 때는 코드가 더 길어진다는 뜻이 된다. 그렇기에 나는 코드를 줄이기 위해 적어도 사용자의 정보 정도는 간단하게

func getUserInfo(_ uid: String)->UserModel {
    유저의 정보를 불러오는 코드..
}

정도로 만들어서 불러오고 싶었다. 하지만 불러오는 것은 가능하고, 리턴하는 것이 불가능 하다는 것을 깨닳았다. 왜냐면 위처럼 코드를 짠다고 가정했을 때,

func getUserInfo(_ uid: String) -> UserModel {

    Database.database().reference().child("Users").child(uid!).observe(DataEventType.value) {
        DataSnapShot in 

           let user = UserModel(Json: DataSnapShot.value as? [String: Any])
    유저를 어디에서 리턴할 것인가??!!
        여기서 리턴한다면, 에러가 나온다.
        return user 불가능
    }
        그렇다고 여기서 리턴한다면,
        데이터가 user 에 담기기 까지 시간이 걸리기 때문에, 
        담기기 전에 리턴이 되어버린다.
        user = nil...
}

위처럼 된다. 인터넷 통신을 통한 데이터는 확실히 느리다. 그렇다면 그 "나중에 생기는 데이터" 를 객체로 만들어보자. @escaping 으로 구현해보자.

class 나중에생기는데이터<T> {
    private let task: (@escaping (T) -> Void) -> Void

    init(task: @escaping (@escaping (T) -> Void) -> Void) {
        self.task = task
    }

    func 데이터가받아지면(_ f: @escaping (T) -> Void) {
        task(f)
    }
}

이렇게 구현을 해볼 수 있겠다.

이러한 클래스를 RxSwift에서 Observable 이라고 부른다. Observable 은 직역해보면 "관찰가능한" 이 된다. 아직 관찰하지 않았다. .subscribe를 통해 "관찰"이 가능하다.

Observable 은 한번만 subscribe 가능하다. Observable 이 subscribe 되면 Disposable 이 된다. Disposable 은 직역하면 " 사용 후 버릴 수 있는" 이 된다. 아직 버리지 않았다. .dispose() 를 통해 버릴 수 있다.

예문을 통해 알아보기

간단하게 url 에서 json 을 받아오는 코드를 짜보자.

     MARK: 함수에서 async를 사용하는 방법 1
    func downloadJson(_ url: String, _ completion: @escaping (String?) -> Void) {
        DispatchQueue.global().async {
            let url = URL(string: url)!
            let data = try! Data(contentsOf: url)
            let json = String(data: data, encoding: .utf8)
            DispatchQueue.main.async {
                completion(json)
            }
        }
    }

비동기로 구현해야 하기 때문에 DispatchQueue.global().async 에서 데이터를 받아온 다음

downloadJson(URL_NAME) { json in 
    UI 처리.
}

UI처리는 DispatchQueue.main 에서 처리 해주면 끝.

이제 이 코드를 RxSwift로 구현해보자.

   //MARK: 1. 비동기로 생기는 데이터를 Observable로 감싸서 리턴하는 방법

    func downloadJson(_ url: String) -> Observable<String?> {
        return Observable.create { emitter in
            let url = URL(string: url)!
            let task = URLSession.shared.dataTask(with: url) { (data, _, error) in
                guard error == nil else {
                    emitter.onError(error!)
                    return
                }

                if let dat = data, let json = String(data: dat, encoding: .utf8) {
                    emitter.onNext(json)
                }
                emitter.onCompleted()
            }
            task.resume()
            return Disposables.create {
                task.cancel()
            }
        }
    }

나중에 생기는 데이터 , Observable 을 리턴해보자.

Observe.create 를 통해 Observable 을 생성하고 UrlSession에서 json을 받아온다. 에러가 발생하면 빠져나와 Subscribe 가 끝난 Observable , Disposable을 리턴한다. 위 함수를 만들어놓고 나면,

        let observable = downloadJson(MEMBER_LIST_URL)
        _ = observable.subscribe { event in
            switch event {
            case .next:
                메인 쓰레드에서 ui처리
            case .error:
                break
            case .completed:
                break
            }
        }

앞으로는 어떠한 url 도 downloadJson으로 손쉽게 데이터를 불러올 수 있다.

버튼을 하나 만들어주고, 다른 ViewController에 드래그하면

deprecated 된것들은 제끼고 대충 Show 와 Present가 보인다.

영어로 된 설명이다. 간단하게 말하면, Show 와 Present 의 차이는 바로 뒤에 깔린 ViewController 이다.

일단 우리가 흔히 아는 앱들을 켜보면, 뭔가 새로운 화면을 띄우면 그 뒤에는 그 전 화면이 있다는 것을 알고 있다. 이렇게 스택 형식으로 쌓이게 되는데, Show 는 moving the source viewcontroller out of the way라고 명시되어있다. 치운다는 뜻인데 어떻게 영향을 주는 지는 아직 잘 모르겠다. 반면 present 는 그대로 우리가 보이는 그대로 아래에 source viewcontroller 가 존재하고 있는 상태이다.

UITabBarController ??

그렇다면 좀 특이한 형태의 UITabBarController 에 대해 알아보자. TabBarController 을 생각해보면 , 서로가 서로를 present하거나, show 하는 형태가 아님을 알 수 있다. 그렇다면 어떤 구조일까? TabBarController 에서 이미, 2개 이상의 ViewController을 present하고 있는 구조가 된다. 중요한건 이미 ViewController 들이 Present 되어있기 때문에 더이상 instantiate 을 해서는 안된다. ( 같은 코드를 사용하는 새로운 View가 등장할 것이다.) 그렇다면, TabBarController 간의 정보를 공유하기 위해서는, 모든 뷰 들의 공통점인 TabBarController로 정보를 보내서 소통해야겠다는 짐작이 든다.

서론

iOS가 되던, 안드로이드가 되던 앱개발에 있어서 절대 빠질 수 없는 것 중 하나가 바로 화면간 정보 전달이다. 화면을 아무리 예쁘가 만들고 멋지게 만들어내도 우리가 화면을 전환할 때, 가져가야 할 것들을 가져가지 못하면 그 새로운 화면에는 어떠한 정보도 띄울 수 없을 것이다.

iOS 를 독학하기 시작했을 때부터 여러 방법들을 찾아보고 구글링 해봤지만 어떠한 블로그나 사이트에서도 한번에 깔끔하게 정리해놓은 곳을 찾지 못했다. 내가 부족한 지식이지만 정리를 해보려고한다.

ViewController의 구조

UIViewController 의 구조에 대해 알아보자.

안드로이드, iOS 의 뷰에는 LifeCycle 생명주기가 존재한다. iOS 뷰의 LifeCycle은 아래 그림과 같다.

우리가 흔히 ViewController을 만들면 기본적으로 생성되어있는 ViewDidLoad() 는 세번째 단계에 해당한다.

그렇다면 LifeCycle의 Load 와 Appear은 어떤 차이가 있을까? 어플리케이션을 켜면, 어플리케이션의 첫 화면이 등장하기까지 짧은 시간이 소요된다. 그 시간동안 어플리케이션은 코드를 처리한다. 그리고 완료된 코드를 바탕으로 View를 띄운다. 즉 View는 그의 해당하는 코드( ViewController )를 처리해준 후 보여준다. 간단한 예로, 이런 간단한 코드가 있다고 하자. 우리는 UILabel 에 This is Shawn 이라는 단어를 띄우고 싶다. 이 ViewController의 코드를 처리해주지 않으면 mainLabel 에는 This is Shawn이 나오지 않을 것이다.

잘 나온 모습이다. 그렇다면 라이프사이클에서, ViewDidLoad 다음인 ViewWillAppear에서 Label에 코드를 추가해주면 어떨까? 결과는 ?

잘 나온다. 자 그럼 이번엔 ViewDidAppear은 어떨까? 이번에도 잘 나온다. 직접 코드로 실행시켜본다면 느끼겠지만, ViewWillAppear이나, ViewDidLoad보다 훨씬 늦게 This is Shawn이 나타나는 것을 알 수 있다.

이처럼 , ViewController 안에 오버라이드 된 생명주기 함수들은 차례로 코드를 처리하며 뷰를 보여준다. ViewDidAppear의 text가 늦게 나타난 이유는 당연히 함수 이름처럼 View가 나타난 이후에 text를 적용시켜주기 때문이다.

사실, 아주 당연해 보이는 이 실험을 해본 이유는 따로있다.

아래처럼, ViewDidLoad에서 text를 적용시키고, TwoViewController 을 Present 방식으로 띄워보자.

그리고, TwoViewController 안에는 main 이라는 이름의 IBOutlet UILabel 이 있다. 결과는 어떻게될까? VC.main이 없다는 에러가 뜬다. 우리는 분명 코드에 적어줬는데?

UI와 관련된 객체들은 다른 레퍼런스들과 좀 다른 특성을 띈다. 쓰레드도 Main쓰레드를 사용해야만하고,, 그리고 View가 Load되기 전까지는 없는 객체가 된다. 우리가 버튼을 눌렀을 때, 없는 Label의 text를 적용 시킨 꼴이 된다.

하지만 이렇게 이미 뷰가 present가 된 이후에 코드를 적어주거나, Completion안에 넣어준다면, text가 잘 적용된 모습을 볼 수 있다. 이것도 마음에 들지 않는다면, TwoViewController 에 value 를 새로 만든다음 적용 시킨 후 TwoViewController 의 ViewDidLoad에서 새로 적용 시켜주면 된다.

Subject

Subject에 대해 알아보자 . 공식 홈페이지를 이용해보면,

4가지의 Subject가 있다고 한다. 하나하나 살펴보자.

1. AsyncSubject

마블을 통해 이해해보자.

AsyncSubject는 Observable을 통해 Subscribe 된 후 어떠한 이벤트가 발생해도 결과를 배출하지 않는다. 그러다가 Observable의 동작이 완료되고 나면 마지막 결과를 모든 Observable에 배출한다. ( 파랑색이 모든 Stream에 있다. )

또한, Observable이 오류로 인해 동작이 끝난다면, 모든 Observable에 오류값을 전달한다.

2. BehaviorSubject

옵저버가 BehaviorSubject를 Subscribe 하기 시작하면, 기본값 (분홍색) 을 배출하고, 앞으로 오는 모든 이벤트를 배출한다. 도중 다른 옵저버가 Subscribe 하면, 바로 직전의 값 (연두) 를 배출하는 것으로 보아 분홍색 이벤트가 완전 Default 값이 아닐 수도 있다고 추측할 수 있다. 바로 직전 이벤트일 수도 있다.

오류로 인해 종료된다면, 에러를 반환한다. 새로 subscribe한 Observable 에도 에러를 반환한다.

3. PublishSubject

이번엔 Subscribe 했을 때 아무것도 배출하지 않고, 그다음 이벤트부터 배출하는 것을 볼 수 있다.

에러가 발생했을 때도 예상이 가능하다.

4. RelaySubject

RelaySubject 는 Subscribe 시점과 별개로 그 전에 발생했던 모든 이벤트들을 배출한다.

RxCocoa

이번 포스팅에서는 RxCocoa를 이용한 로그인 시스템에 대해 알아보겠다.

UI 는 다음과 같이 구성되어있다. Email, Password Textfield 와 형식이 다르다면 보여지는 Email, Password Valid View (빨간 점) 그리고 마지막으로 Email, password 형식이 모두 같으면 Log In이 보여지고 아니면 Fill the Fields 가 보이는 로그인 버튼이다.

코드

        idField.rx.text.orEmpty
            .map(checkEmailValid)
            .subscribe(onNext: { s in
                self.idValidView.isHidden = s
        })
        .disposed(by: disposeBag)

idField 의 형식을 체크하는 코드이다. 물론 "비동기" 로 이루어진다. 사실 이번 강의를 듣기 전까지 동기, 비동기에 대해 많이 들어봤지만 실제 앱에서 어떤식으로 적용이 되는지에 대해 의문이 있었다. 이번에 좀 해소가 되는듯 하다. idField.rx.text : idField 의 text를 비동기로 처리해주겠다는 코드이다. .orEmpty : filter { $0 != nil } 과 map { $0 ! } 과 같은 코드이다. 옵셔널 처리.

checkEmailValid 함수는 따로 작성을 해줬다. 간단히 .contain("@"), .contain(".")으로...

그리고 subscribe으로 나오는 값을, Bool 형식으로 나오는 값을 self.isValidView.isHidden 에 적용시키면, idField의 text가 변할때 마다 비동기로! s 가 변하는 것을 알 수 있다.

Q. Delegate 과 비슷한데..?

코드를 작성하다보니 , 특히 TextField 에서는, Delegate과 매우 비슷하다는 생각이 든다. 위의 코드를 RxSwift, RxCocoa 를 사용하지 않고 작성해보자면, 일단 ViewController에 UITextfieldDelegate 를 익스텐션 해주고, TextfieldDidEndEditing에 코드를 작성해주면 될 것 같다. 그래서 구글링을 해보니 Delegate을 통해 비동기 처리를 해준다고 한다.

생각해보면 CollectionView, TableView 도 Delegate 을 통해 비동기처리를 해주고 있었던 것이다. TableView 함수들이나 CollectionView 함수들에 적혀진 함수들은 자동으로 처리되고 있었고, 내가 Database로 사용하고 있었던 Firebase에서 사용하던 Observe나 ObserveSingleEvent 함수도 결국 생각해보면 비동기 처리를 해주고 있지 않았나 생각이 든다.

Combine

idField 의 비동기처리 코드를 보았다면 어렵지 않게 pwField 비동기 처리를 해줄 수 있다.

        idField.rx.text.orEmpty
            .map(checkEmailValid)
            .subscribe(onNext: { s in
                self.idValidView.isHidden = s
        })
        .disposed(by: disposeBag)

        pwField.rx.text.orEmpty
            .map(checkPasswordValid)
            .subscribe(onNext: { s in
                self.pwValidView.isHidden = s
        })
        .disposed(by: disposeBag)

그렇다면 이제 로그인 버튼을 생각해보자. 위의 두 Observable들이 true 일 때 , Login In 이 표시되어야 한다.

코드를 보면 ,

        Observable.combineLatest(
            idField.rx.text.orEmpty.map(checkEmailValid),
            pwField.rx.text.orEmpty.map(checkPasswordValid),
        resultSelector: { s1, s2 in s1 && s2 }
        )
        .subscribe(onNext: { b in
            self.loginButton.isEnabled = b
        })
        .disposed(by: disposeBag)

두 옵저버블을 선언해준 다음 , returnSelector안에 담아서 subscribe 해주면 된다. 이번역시 self.loginButton.isEnabled 에 적용시키면 비동기로 , 값이 바뀔 때 마다 , Delegate 처럼 바뀌는 Login버튼을 확인 할 수 있다.

그렇다면 지금까지 공부한 코드를 좀 더 간단하게 사용하는 방법을 알아보자.

Simple

먼저, id 작성 textfield의 observable을 만들어보자.

이름을 idInputOb라고 해주고, idField.rx를 치면 , 리턴 값이 Reactive형식이라고 나온다 . 흥미롭다 text까지 입력하면 ControlProperty, 컨트롤 할 객체 라는 것 같다. 우리는 Observable 을 원하기 때문에, asObservable() 을 입력해준다. 그리고 빨간 점에도 옵저버블을 만들어주자.

비밀번호까지 완료했다.

이제 만든 Observable 들을 Subscribe 해주자.

이렇게 isHidden 에 적용시켜준다.

이제 두 옵저버블을 Combine 해서, 로그인 버튼에 달아주자.

아까 적었던 코드와 똑같은 비동기 처리를 해주는 코드가 된다. 확실히 좀 더 많은 Observable이 들어가는 코드에서 더 알아보기 편할 것 같다.

Operator 활용하기

지난 포스트에서 다룬 Operator들을 더 자세하게 다뤄보자. 공식 홈페이지에 잘 번역되어있는 Operator로 들어가면,

다양한 Operator들에 대해 설명을 해주고 있다. 여기서 중요한 것은, Reactive 만의 특별한 설명 방식인데,

Just() 를 다음과 같이 구슬로 설명하고 있다. 그대로 빨간공이 내려오면 종료 (dispose) 하겠다는 의미이다.

First도 한번 살펴보자.

첫번째 구슬이 내려오자마자 Dispose를 한다. 이런 것들은 코드를 통해서 확인해보고 싶어진다.

    @IBAction func exJust2() {
        Observable.just(["Hello", "World"])
            .subscribe(onNext: { arr in
                print(arr)
            })
            .disposed(by: disposeBag)
    }

전에 다뤘던 예문 2 코드에서, single()를 얹어보자.

공식홈페이지에서 Single 을 클릭하니 First가 나오는 것으로 보아, 같은 기능인 것으로 보인다

    @IBAction func exJust2() {
        Observable.just(["Hello", "World"])
            .single()
            .subscribe(onNext: { arr in
                print(arr)
            })
            .disposed(by: disposeBag)
    }

그리고 subscribe를 이벤트 형태로 받아보자.

    @IBAction func exJust2() {
        Observable.just(["Hello", "World"])
            .single()
            .subscribe { event in
                switch event {
                case .next(let d):
                    print("next: \(d)")
                    break
                case .error(let error):
                    print("error: \(error)")
                    break
                case .completed:
                    print("completed")
                    break
                }
            }
            .disposed(by: disposeBag)
    }

subscribe 이벤트는 세가지 케이스가 있는데, .next, .error, .completed 가 있다. 이대로 실행시켜보면 어떻게될까? 이렇게 나온다. Just을 통해 Hello, World 배열이 "동시에" 내려왔기 때문에 한 구슬에 담겨 내려왔음을 알 수 있다. 그렇다면, Just가 아니라 From 으로 바꿔보겠다. Single() 은 하나의 구슬이 내려오지 않으면 에러를 뱉기 때문에, next를 통해 Hello 구슬이 내려온 뒤, 아직 World 구슬이 내려오지 않고 남아있는 것을 확인한 후 Error을 출력한다. World 를 지우면,

예상대로, Hello 이후에 Completed가 출력되는 것을 볼 수 있다.

Scheduler

    @IBAction func exMap3() {
        Observable.just("800x600")
            .observeOn(ConcurrentDispatchQueueScheduler(qos: .default))
            .map { $0.replacingOccurrences(of: "x", with: "/") }
            .map { "https://picsum.photos/\($0)/?random" }
            .map { URL(string: $0) }
            .filter { $0 != nil }
            .map { $0! }
            .map { try Data(contentsOf: $0) }
            .map { UIImage(data: $0) }
            .observeOn(MainScheduler.instance)
            .subscribe(onNext: { image in
                self.imageView.image = image
            })
            .disposed(by: disposeBag)
    }

이렇게 observeOn(스케쥴러) 를 이용해서 해결할 수 있다. ConcurrentDispatchQueueScheduler 로 비동기로 사진을 불러온다. 두 줄이 새로 추가됐는데, observeOn이 두줄 추가됐다.

윗 줄의 .observeOn 아래로 또다시 .observeOn이 나오기 전까지의 Operator 들은 비동기로 진행된다. 그러다가 다시 메인 쓰레드로 접근하게 하는 observeOn(MainScheduler.instance) 이 호출된 이후 아래의 subscribe은 메인에서 진행된다. (UI 이기 때문에 메인에서!)

실행시켜보면, 이미지가 불러오는중에도 드래그가 잘 되는 것을 확인 할 수 있다. Main에서 이미지를 Url 에서 불러오는 것이 아니라, Thread1 에서 이미지를 받아오고 있다. Main Thread에 있는 UI들은 어떠한 제약도 받지 않는다.

굳이 구역을 정해서 비동기화를 쓰지 않고, subscribe 시작부터 전체 비동기화를 하고 싶다면, 아무곳에나 .subscribeOn(ConcurrentDispatchQueueScheduler)을 넣어주면 된다. 하지만 , observeOn(MainThread) 는 꼭 넣어줘야한다. UI를 꼭 다뤄야하기 때문,....

Side-Effect

Side effect란 간단히 말하면, 현재 함수 밖에 영향을 주는 코드를 말한다.

    @IBAction func exMap3() {
        Observable.just("800x600")
            .observeOn(ConcurrentDispatchQueueScheduler(qos: .default))
            .map { $0.replacingOccurrences(of: "x", with: "/") }
            .map { "https://picsum.photos/\($0)/?random" }
            .map { URL(string: $0) }
            .filter { $0 != nil }
            .map { $0! }
            .map { try Data(contentsOf: $0) }
            .map { UIImage(data: $0) }
            .observeOn(MainScheduler.instance)
            .subscribe(onNext: { image in
                self.imageView.image = image
            })
            .disposed(by: disposeBag)
    }

이 코드에서는 self.imageView.image = image 코드가 Side-Effect를 주고 있다. Side-Effect를 사용하기 좋은 곳이 딱 두 곳 있는데, 이 코드의 .subscribe가 있고, 아래의 Do 가 있다.

Do

Do 함수를 살펴보자

오메나 여러 switch - case 문을 활용하기 좋아보이는 상황들이 있는데, 알맞은 상황에 맞춰서 side-effect를 주면 된다. 다음 포스트에서는 RxCocoa에 대해 알아본다.

이번에는 Operator들에 대해서 공부해보려고 한다.

Operator

공식 홈페이지 문서에 보면 Operator 에 대한 설명이 뭐라뭐라 나와있다. 하지만 솔직히 말하자면, Operator을 처음 접하는 내 입장에서는 정확하게 이해하기 어렵다.

그냥 예문을 통해서 Operator가 무엇인지 살펴보자.

예문 1

    @IBAction func exJust1() {
        Observable.just("Hello World")
            .subscribe(onNext: { str in
                print(str)
            })
            .disposed(by: disposeBag)
    }

Operator 중 Just 에 대한 예문이다. Just는 () 안에 객체를 그대로 가져온다. 결과는 로 예상 가능하다.

예문 2

    @IBAction func exJust2() {
        Observable.just(["Hello", "World"])
            .subscribe(onNext: { arr in
                print(arr)
            })
            .disposed(by: disposeBag)
    }

Just를 Array에 적용시켰다. 크게 다르지 않다.

예문 3

    @IBAction func exFrom1() {
        Observable.from(["RxSwift", "In", "4", "Hours"])
            .subscribe(onNext: { str in
                print(str)
            })
            .disposed(by: disposeBag)
    }

이번엔 From에 대해 알아보자.

결과가 다음과 같은 것으로 보아 Just와 달리 From은 Array 안에 객체를 각각 받아오는 것으로 유추할 수 있다.

예문 4

    @IBAction func exMap1() {
        Observable.just("Hello")
            .map { str in "\(str) RxSwift" }
            .subscribe(onNext: { str in
                print(str)
            })
            .disposed(by: disposeBag)
    }

** Mapping ** 여기서 .map 이 나온다. Swift 언어로 알고리즘 공부를 하다가 Programmers 에서 문제를 풀기 시작했었는데, 해답을 보니 짧고 간단한 코드들은 모두 Map() 이라는 함수가 들어갔던 것으로 기억한다. Just 의 "Hello" 를 map 에서 str로 받아와 in "(str) RxSwift" 에 적용 시킨 후 subscribe 에서 print 해준다.

Q1. 코드 끝에 disposed를 없애면 어떻게 될까?

없애기 전.

없앤 후.

결과는 차이가 없지만 코드에서, 에러가 나오는데, .subscribe를 사용하고 나면 dispose 되었을 때 이벤트를 적어주라는 경고이다. 일단은 이 에러가 나오는 것 말고는 큰 차이는 없다. 더 공부하다보면 나올 것 같다.

Q2. .subscribe를 사용하지 않고 구현해보면?

먼저 subscribe를 제거하고 코드를 짜 보았다.

    @IBAction func exMap1() {
        Observable.just("Hello")
            .map { str in "\(str) RxSwift" }
            .map { str in print(str) }
    }

결과로는 아무것도 print 되지 않는다.

다음으로는, print를 subscribe가 아니라 map 에서 해줬다.

    @IBAction func exMap1() {
        Observable.just("Hello")
            .map { str in "\(str) RxSwift" }
            .map { str in print(str) }
            .subscribe(onNext: { Void in

            })
            .disposed(by: disposeBag)
    }

출력이 정상적으로 되는 것을 볼 수 있다.

위의 두 가지 호기심으로 알 수 있었던 것은 Observable 은 항상 끝에 subscribe로 끝나야 하는 것 같다. 그리고 가면 갈 수록 SwiftUI와 굉장히 비슷하다는 생각이 든다.

예문 5

    @IBAction func exMap2() {
        Observable.from(["with", "shawn"])
            .map { $0.count }
            .subscribe(onNext: { str in
                print(str)
            })
            .disposed(by: disposeBag)
    }

from으로 받아온 array 전체 ( $0 ) 를 .count 해서 출력한다.

예문 6

    @IBAction func exFilter() {
        Observable.from([1, 2, 3, 4, 5, 6, 7, 8, 9, 10])
            .filter { $0 % 2 == 0 }
            .subscribe(onNext: { n in
                print(n)
            })
            .disposed(by: disposeBag)
    }

from으로 받아온 array 중 .filter 안에 true 인것만 .subscribe 의 n 안에 넣어준다. 2, 4, 6, 8, 10이 출력된다.

예문 7

    @IBAction func exMap3() {
        Observable.just("800x600")
            .map { $0.replacingOccurrences(of: "x", with: "/") }
            .map { "https://picsum.photos/\($0)/?random" }
            .map { URL(string: $0) }
            .filter { $0 != nil }
            .map { $0! }
            .map { try Data(contentsOf: $0) }
            .map { UIImage(data: $0) }
            .subscribe(onNext: { image in
                self.imageView.image = image
            })
            .disposed(by: disposeBag)
    }

제일 중요한 예문인데, 800x600 에서 x 를 /로 바꾼다. ( replacingOccurrences 를 이용 ) 이미지 url 에서 800/600 사이즈의 이미지를 찾아오는 코드인 것 같다. url 을 URL 로 바꾸고, nil 이 아닌 것을 filter 해주고 (예외처리 인 것 같다 ) UIImageview에 넣기 위해 Data로 바꿔주고 이미지를 띄워주면 끝.

What's New?

앱 개발자들을 필요로하는 스타트업들을 찾아보니, 대부분이 iOS Android를 함께 만들기 위해 ReactiveNative 같은 하이브리드 앱 개발자들을 많이 찾는다. (결국 회사가 성장함에 따라 네이티브로 바뀌겠지만) 애플 또한 SwiftUI로 갈아타게끔 하려는 추세인 지금 반응형 프로그래밍을 제대로 아는것이 너무 중요한 것 같다. 오늘 배운 7가지 예문들을 보면 SwiftUI 와 매우 비슷하게 흘러가면서 ㅊㅊ: 리액티브 공식 홈페이지

Observable Stream이라는게 뭔지 감을 잡을 수 있었다.