[iOS / SwiftUI] .mask를 활용하여 Custom ProgressView를 구현해보자

kodo_o — Thu, 27 Apr 2023 15:02:32 +0900

지금 진행하고 있는 프로젝트에서 디자인 시스템을 도입하고 있다.

다른 컴포넌트들은 디자인이 구상이 되어 있어서, 이를 그대로 구현하면 되는 상황이었지만 ProgressView는 명시된 디자인이 없었다. 그래서 어떻게 구현할지 고민하다가, 앱의 Identity와 UX라는 두 마리의 토끼를 모두 잡아보기로 결정했다.

이를 위해, 우리 앱의 로고를 사용하기로 했다.

하지만 단순히 로고만 띄어주기엔 이쁘지도 않고, 일단 UX적으로 마음에 들지 않았다.

Why?

ProgressView는 어떠한 요청(ex, API Request)에 대한 응답을 받기 전까지의 로딩을 시작적으로 표현하는 것인데, 단순히 로고만 띡 띄어놓으면 사용자는 이게 무슨 상황인지 전혀 알 방법이 없다. 그래서 Dynamic한 요소가 필요했는데, 그러던 중 Shimmer라는 기법(?)이 떠올랐다.

자주 참고하는 SwiftUI 관련 유튜버인데, 해당 영상에는 .mask를 활용해서 빛이 이동하면서 발생하는 그림자 효과를 주고 있었다.

이와 비슷하게 구현하되, 다른 느낌을 주고 싶었다.

그렇게 구현을 시작했고, 구현 결과는 아래와 같다.

앱의 로고를 활용하여 Identity를 가져가면서, 동시에 사용자에게 로딩 중이라는 정보를 제공할 수 있게 됐다.

구현

View

우선 첫 번째로 Base가 되는 View이다.

ZStack 내부에 같은 이미지를 두 장 배치했다.

2번 이미지에 컬러를 채워주고, .mask modifier를 붙여준다.

우선 .mask에 대해 간단하게 설명하자면, 그냥 우리가 사용하는 마스크를 떠올리면 된다.

얼굴을 가리는 것처럼, content를 가릴 수 있게 해주는 modifier이다.

한 번 써보면 무슨 느낌인지 알 수 있을 것이다.

이해를 돕기 위해, 위에 작성한 코드에서 .mask를 조금 수정해봤다.

로고에 .mask가 씌어져서 양 옆에 가려진 것을 볼 수 있다.

(사실 .mask를 쓰지 않아도, ZStack이나 Overlay로도 충분히 구현 가능하다는 생각이 들긴하지만... )

아무튼 다시 본론으로

2번 이미지를 가릴 수 있는 Rectangle 형태의 마스크를 선언한다.

여기서 로고가 왼쪽에서 오른쪽으로 채워지는 느낌을 주기 위해 애니메이션을 활용했다.

초기에는 Rectangle의 크기가 0이고, 애니메이션이 시작되면 로고의 너비까지 증가한다.

offset도 -(로고의 크기 * 0.35)이고, 애니메이션이 시작되면 0까지 증가한다.

이렇게 해주면 왼쪽에서 오른쪽으로 컬러가 채워지는 느낌을 줄 수 있게 된다.

ViewModifier

앞서 구현한 ProgressView를 사용할 ViewModifier이다. ProgressView에서는 형태를 정의했다면, 이 곳에서는 애니메이션을 부여하고 Background를 지정하는 역할을 수행한다.

ZStack을 활용하여 ProgressView가 보여질 때, Touch Event를 막기 위해 Background를 지정한다.

그리고 onAppear를 활용하여 View가 보여지면 애니메이션을 작동하도록 구현했다.

isPresented와 isAnimated가 헷갈릴 수 있는데

isPresented는 ProgressView를 띄우는 프로퍼티,

isAnimated는 ProgressView 내부의 애니메이션을 작동하는 프로퍼티라고 생각하면 된다.

Extension

앞서 구현한 ViewModifier를 Extension을 활용하여 Modifier의 형태로 사용할 수 있도록 맵핑한다.

그 결과, 최종적으로는 View에서 Extension만 호출해서 사용한다.

이런 식으로 ProgressView가 필요한 곳에서 modifier의 형태로 접근한다.

isPresented가 true이면 ProgressView가 보여지고,

false이면 ProgressView가 사라지게 된다.

TMI...

코드량이 많지는 않다.

그래도 코드량에 비해 많은 고민을 했던 컴포넌트였다.

또한 사용하는 과정에서 다른 애니메이션이랑 겹치는 문제가 발생했는데, 최상단 View에서 호출하는 것으로 해당 문제를 해결할 수 있었다.

[iOS / SwiftUI] View Memory Graph Hierarchy를 활용해보자

kodo_o — Tue, 14 Mar 2023 00:21:42 +0900

멋쟁이사자처럼 iOS 앱 스쿨에서 최종 프로젝트로 단어장 앱을 만들면서,

AVSpeechSynthesizer를 활용하여 TTS 기능을 구현하려고 했다.

하지만 구현 과정에서 예상치 못한? 오류를 만났고 생각보다 골머리를 썩였다.

코드 상으로는 전혀 문제가 없었는데 말이다. (~~진짜로? 문제 없는 거 맞아?~~)

그렇게 고민하던 중, 결국 View Memory Graph Hierarchy를 통해 오류를 해결할 수 있었다.

처음 써봤는데 정말 유용한 친구라는 걸 깨달았다.

아무튼 오늘은 메모리 관련 이슈가 있을 때 사용하면 정말 유용한 친구를 소개하고자 한다.

그 전에, AVSpeechSynthesizer는 어떻게 동작하는지에 대해 알아보도록 하자.

AVSpeechSynthesizer의 동작 과정

코드로는 이렇게 표현할 수 있다.

여기서 instance는 AVSpeechSynthesizer

이 코드가 실제로 어떻게 동작할까?

우선 AVSpeechSynthesizer에는 AVSpeechUtterance를 담을 수 있는 그릇(Queue)이 존재한다.

이곳에 AVSpeechUtterance 인스턴스가 담기고,

speak 메서드를 호출하면 Queue에서 Pop되면서 TTS가 작동하게 된다.

애니메이션으로는 이렇게 표현할 수 있다.

문제 상황

뭐, 정말 별 거 없다.

위 애니메이션만 보면 '아... 이렇게 동작하는구나...' 정도로 생각할 수도 있다.

간단한 애니메이션처럼 실제로 코드 상으로도 간단하게 구현할 수 있다. (~~간단할 줄 알았다...~~)

우선, 우리 앱에서의 단어 듣기 모드에는 세 가지 타입이 존재한다.

1. 선택한 단어 듣기(1개)

2. 선택한 단어 듣기(여러 개)

3. 전체 단어 듣기

1개의 단어만 들을 때(1번)는 TTS가 실행, 종료된 이후에 다시 TTS를 실행했을 때 아무 문제가 없었다.

하지만 2번과 3번처럼, TTS가 온전히 종료하기 전에 NavigationItems에 있는 "취소" 버튼으로 TTS를 강제 종료하는 순간 문제가 발생했다.

이렇게 TTS를 강제로 종료하게 되면 이후에 TTS가 실행되지 않는 치명적인 오류였다.

아래와 같은 오류를 내뿜으며 TTS가 작동하지 않았다.

아, 이거다!

구글링을 해봐도 내가 원하는 답변을 찾을 수 없었다.

그러던 중, 멘토님께서 하신 말씀이 머리를 스쳐 지나갔다.

'Xcode에서 메모리와 관련된 디버그 툴을 제공한다...'

아, 이거다!

평소에 자주 사용하던 View Hierarchy와 같은 곳에 존재했다.

아무튼 이 친구를 통해서 메모리에 어떤 인스턴스들이 올라가있나 직접 확인해봤고,

문제가 발생할 때와 발생하지 않을 때를 비교해봤다.

왼쪽 사진은 정상적으로 TTS가 종료됐을 때의 모습이고,

오른쪽은 취소 버튼을 눌러서 TTS를 강제 종료됐을 떄의 모습이다.

빨간 밑줄 친 저 놈, AVSpeechUtterance가 생생하게 살아있는 것을 목격했다.

그래서 얘를 메모리에서 제거하면 TTS가 정상적으로 실행될 거라는 확신이 생겼다.

그래서, 어떻게 제거할건데?

ARC를 활용하고자 했다.

wordUtterance를 nil로 만들어 줌으로써,

ARC에 의해 메모리에서 자동으로 제거되는 방향으로 접근했다.

하지만 아까 위에서 동작 원리에서 봤던 것처럼

AVSpeechSynthesizer에서 wordUtterance에 대한 참조를 갖고 있었고,

이로 인해 RC가 발생하여 ARC가 해당 인스턴스를 제거하지 않았다.

그래서 다른 방식으로 접근했다.

wordUtterance를 제거하는 것이 아니라 이를 담고 있는 AVSpeechSynthesizer 자체를 제거하는 방향으로 말이다.

결과는 성공적이었다.

앞서 발생한 문제를 말끔하게 해결할 수 있었다!

디버깅이 아니였다면 해결하지 못한 이슈로 남았을 것이다...

앞으로도 자주 활용해서, 메모리 관련 이슈를 말끔하게 해결해보자!

직접 부딪히고, 찾아보면서 작성한 글이라 잘못된 정보가 있을 수 있습니다.

피드백은 언제든지 환영입니다. 감사합니다.

전체 코드

import AVFoundation
import Foundation

enum SpeechType {
    case single
    case many
}

protocol TTSProtocol {
    /// 단어 하나를 읽어주는 메서드
    func speakWordAndMeaning(_ word: Word, to language: String, _ type: SpeechType)
    
    /// 여러개의 단어를 읽어주는 메서드
    func speakWordsAndMeanings(_ words: [Word], to language: String)
    
    /// 단어 읽기를 멈추는 메서드
    func stopSpeaking()
}

final class SpeechSynthesizer: NSObject, ObservableObject, TTSProtocol {
    // 싱글톤으로 정의
    private var instance: AVSpeechSynthesizer? = AVSpeechSynthesizer()
    
    // 단어와 의미 사이의 간격 (같은 단어 내에서)
    private let intervalOfWordAndMeaning = 0.3
    
    // 의미와 의미 사이의 간격 (같은 단어 내에서)
    private let intervalOfMeaningAndMeaning = 0.1
    
    // 단어와 단어 사이의 간격 (다른 단어끼리)
    private let intervalOfWordAndWord = 0.5
    
    // TODO: - 사용자가 설정한 언어에 따라 동적으로 뱌뀌는 코드 추가
    private let meaningUtteranceLanguage = "ko-KR"
    
    // 재생할 단어의 개수를 저장
    private var totalWordsCount: Int = 0
    private var spokenWordsCount: Int = 1
    
    // 단어 듣기의 재생 여부를 확인
    @Published var isPlaying = false
    
    override init() {
        super.init()
        instance?.delegate = self
    }
    
    /// 단어 하나를 읽어주는 메서드
    func speakWordAndMeaning(_ word: Word, to language: String, _ type: SpeechType) {
        if instance == nil {
            instance = AVSpeechSynthesizer()
            instance?.delegate = self
        }
        
        let wordUtterance = AVSpeechUtterance(string: word.word ?? "") // TTS로 들려줄 단어 설정
        wordUtterance.voice = AVSpeechSynthesisVoice(language: language) // 언어 설정
        wordUtterance.postUtteranceDelay = intervalOfWordAndMeaning // 다음 단어와의 시간 간격 설정
        instance?.speak(wordUtterance) // TTS 작동
        
        if type == SpeechType.single { return } // contextMenu로 접근한 경우
        
        // meaning 타입이 [String?]라서 순회하는 방식으로 구현
        word.meaning?.forEach { meaning in
            let meaningUtterance = AVSpeechUtterance(string: meaning)
            meaningUtterance.voice = AVSpeechSynthesisVoice(language: meaningUtteranceLanguage)
            meaningUtterance.postUtteranceDelay = intervalOfMeaningAndMeaning
            instance?.speak(meaningUtterance)
        }
    }
    
    /// 여러 개의 단어를 읽어주는 메서드
    /// 단어 하나를 읽어주는 메서드를 재사용하는 방식으로 구현
    func speakWordsAndMeanings(_ words: [Word], to language: String) {
        totalWordsCount = calculateWordsAndMeanings(words) // 단어 개수 카운트
        spokenWordsCount = 1
        
        isPlaying = true // 재생 상태로 변경
        
        words.forEach { word in
            self.speakWordAndMeaning(word, to: language, .many)
        }
    }
    
    /// 단어 읽기를 멈추는 메서드 (onDisapper)
    /// TTS가 작동 중인 상태였으면 (선택 듣기, 전체 듣기 도중 종료) AVSpeechSynthesizer를 초기화하여 오류를 방지
    func stopSpeaking() {
        instance?.stopSpeaking(at: .immediate)
        instance = nil // 인스턴스 초기화
        isPlaying = false // 정지 상태로 변경
    }
    
    /// 재생할 단어의 개수를 계산하는 메서드
    private func calculateWordsAndMeanings(_ words: [Word]) -> Int {
        var cnt = 0

        for word in words {
            cnt += 1

            for _ in word.meaning ?? [] {
                cnt += 1
            }
        }

        return cnt
    }
}

extension SpeechSynthesizer: AVSpeechSynthesizerDelegate {
    func speechSynthesizer(_ synthesizer: AVSpeechSynthesizer, didFinish utterance: AVSpeechUtterance) {
        // 재생이 완료된 단어의 개수가 총 단어의 개수와 일치하면 정지
        if totalWordsCount == spokenWordsCount {
            isPlaying = false
        } else {
            spokenWordsCount += 1
        }
    }
}

[Architecture] MVVM + Clean Architecture를 알아보자

kodo_o — Sat, 7 Jan 2023 12:53:55 +0900

SwiftUI에서는 @ObservableObject 덕분에 ViewModel(역할을 하는?)을 쉽게 구현할 수 있다. 덕분에 실습을 진행하면서 대부분의 프로젝트에서 ViewModel로 분리는 했지만 문제가 많았다. ~~일단 SwiftUI가 View 자체적으로 Data Binding이 가능하기 때문에 이미 ViewModel이 녹아들어간 느낌이다.~~ 하지만 이것보다도 하나의 ViewModel에서 여러 작업을 진행하다보니 Massive ViewModel이랄까? ViewModel이 비대해진 느낌이 들었고, 그래서 해커톤 때는 이런 것들을 걷어내고 아키텍쳐적으로 조금 더 괜찮은 앱을 구현하고 싶었다. 다행히도 팀원 중 한 분이 클린 아키텍쳐에 대해 잘 알고 계셔서 도움을 많이 받았고, 전보다는 어느정도 완성된 앱을 만들 수 있었다.

서론이 길었지만 아무튼 해커톤을 계기로 Clean Architecure에 대해 다시 공부하고 싶어서 전에 북마크해둔 글을 보면서 개념을 정리해보는 시간을 가졌다.

Clean Architecture and MVVM on iOS

When we develop software it is important to not only use design patterns, but also architectural patterns. There are many different…

tech.olx.com

GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoor

Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoordinator, DTO, Response Caching and one of the views in SwiftUI - GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Tem...

github.com

Clean Architecture

우선 이런 형태를 가진다.

의존 관계는 안쪽으로 향하게끔 설계를 하고, 안쪽에 있는 요소들은 바깥쪽에 있는 요소의 존재를 모른다.

예를 들어, Presenters에 해당하는 ViewModel은 Domain에 해당하는 Usecase에 의존적이지만, (생성자를 통해 전달)

Domain은 ViewModel에 대해 알 필요가 없다.

종속성 방향

Presentation Layer → Domain Layer ← Data Layer
Presentation Layer는 Domain Layer에 의존
Domain Layer가 Data Layer에 의존 → 추상화된 Repository에 의존하므로 의존성 역전

데이터 흐름

View는 ViewModel에서 메서드를 호출한다.
ViewModel은 UseCase를 실행한다.
UseCase는 User와 Repository의 데이터를 결합한다.
Repository는 DB, Network와 연결되어 데이터를 반환한다.
이렇게 한 쪽 방향으로 흐른 플로우는 다시 반대로 흘러간다. (단방향, 콜백)

Domain Layer

Entity, Usecase
Entity : 우리가 지금까지 Model로 작성한 것들
Usecase: 소프트웨어 공학에서 기능 단위로 설명하는데 거의 비슷하다고 볼 수 있음. 위 사진에서 볼 수 있듯, 영화 검색(Movie Search) 유스케이스, 최신 영화 목록?(Fetch Recent Movie Queries) 유스케이스처럼 기능에 대한 단위

안드로이드 공식 문서이지만, 아키텍쳐적인 관점에서는 iOS와 동일하므로 첨부했다.

Domain Layer에 대한 특징이 나와있다.

근데 유스케이스를 꼭 써야하나요?

→ Clean Architecture를 접하기 전까지만 하더라도 나도 같은 생각이였다. 여러 글을 참고하면서 내린 결론은 인터페이스적인 개념이 적용됐다는 것이다. 물론 이렇게 나누지 않고, Presentation가 Repository를 직접 참조해도 상관은 없다고 생각한다.

그렇다면 어떤 장점이 있기에, 이렇게 분리를 한 것일까?

일단, 직관적이다. ViewModel만 딱 봤을 때, 기능 단위로 분류해놓은 Usecase를 보고 바로 이해할 수 있게 된다.

다양한 Repository Layer를 참조하지 않고, 기능에 대한 최소 단위인 Usecase 참조하고 있으므로 ViewModel에서 어떤 기능(서비스)를 제공하고 있는지 명확하게 알 수 있다.

또한 기능이 확장됨에 따라 하나의 Usecase에서 다양한 Repository를 참조하는 경우가 발생할 것이다. 하지만 ViewModel은? Usecase가 어떤 Repository와 연결되어 있는지 알 필요가 없다. 그냥 내가 구현하려는 기능에 해당하는 Usecase를 바라보면 된다.

가령, 특정 기능에 대한 내부적인 로직이 조금 변경될 필요가 있다고 가정해보자. Usecase가 아닌, Repository 를 직접 참조하게 된다면 Repository 수정에 따른 ViewModel의 수정이 불가피할 것이다. 그런데 Usecase를 참조한다면? VIewModel은 그냥 가만히 있어도 된다. 비즈니스 로직을 담고 있는 Usecase 내에서 수정이 일어나기 때문이다.

설명이 길었지만 결론은 다른 Layer들이 어떤 일을 하고 있는지 알 필요가 전혀 없다는 것이다.

직접적으로 맞닿아있는 안쪽 Layer만 알고 있으면 된다.

~~내 윗집, 옆집에 누가 살고 있는지만 알면 된다는 점~~

결론,

유지보수 용이
직관적인 요구사항
의존성 최소화

Presentation Layer

ViewModel에는 import UIkit, SwiftUI가 없어야 한다. (모든 UI 프레임워크와의 단절)
이렇게 구현하면 UIKit → SwiftUI 전환이 매우 용이해진다. 다른 부분은 신경쓰지 않고 UI만 변경해주면 되기 때문이다.

1. ViewModel

protocol MoviesListViewModelInput {
    func didSearch(query: String)
    func didSelect(at indexPath: IndexPath)
}

protocol MoviesListViewModelOutput {
    var items: Observable<[MoviesListItemViewModel]> { get }
    var error: Observable<String> { get }
}

protocol MoviesListViewModel: MoviesListViewModelInput, MoviesListViewModelOutput { }

프로토콜 먼저 선언해주고, 프로토콜을 채택하여 정의한다.

final class DefaultMoviesListViewModel: MoviesListViewModel {
    
    private let searchMoviesUseCase: SearchMoviesUseCase
    private let actions: MoviesListViewModelActions?
    
    private var movies: [Movie] = []
    
    // MARK: - OUTPUT
    let items: Observable<[MoviesListItemViewModel]> = Observable([])
    let error: Observable<String> = Observable("")
    
    init(searchMoviesUseCase: SearchMoviesUseCase,
         actions: MoviesListViewModelActions) {
        self.searchMoviesUseCase = searchMoviesUseCase
        self.actions = actions
    }
    
    private func load(movieQuery: MovieQuery) {
        
        searchMoviesUseCase.execute(movieQuery: movieQuery) { result in
            switch result {
            case .success(let moviesPage):
                // Note: We must map here from Domain Entities into Item View Models. Separation of Domain and View
                self.items.value += moviesPage.movies.map(MoviesListItemViewModel.init)
                self.movies += moviesPage.movies
            case .failure:
                self.error.value = NSLocalizedString("Failed loading movies", comment: "")
            }
        }
    }
}

생성자로 Domain Layer(Usecase)의 인스턴스를 전달받는다.

// Note: This item view model is to display data and does not contain any domain model to prevent views accessing it
struct MoviesListItemViewModel: Equatable {
    let title: String
}

extension MoviesListItemViewModel {
    init(movie: Movie) {
        self.title = movie.title ?? ""
    }
}

또한 Model을 직접적으로 참조하면 안된다. View가 직접적으로 접근하면 안되기 때문이다. (처음에 그림을 생각할 것)

2. ViewController

import UIKit

final class MoviesListViewController: UIViewController, StoryboardInstantiable, UISearchBarDelegate {
    
    private var viewModel: MoviesListViewModel!
    
    final class func create(with viewModel: MoviesListViewModel) -> MoviesListViewController {
        let vc = MoviesListViewController.instantiateViewController()
        vc.viewModel = viewModel
        return vc
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        bind(to: viewModel)
    }
    
    private func bind(to viewModel: MoviesListViewModel) {
        viewModel.items.observe(on: self) { [weak self] items in
            self?.moviesTableViewController?.items = items
        }
        viewModel.error.observe(on: self) { [weak self] error in
            self?.showError(error)
        }
    }
    
    func searchBarSearchButtonClicked(_ searchBar: UISearchBar) {
        guard let searchText = searchBar.text, !searchText.isEmpty else { return }
        viewModel.didSearch(query: searchText)
    }
}

UI는 비즈니스 로직이나 어플리케이션 로직에 직접적으로 접근할 수 없고, 항상 ViewModel에만 접근할 수 있다.
아까 말했던 것처럼 ViewModel에 Entity에 해당하는 프로퍼티(items)를 별도로 둬서 View에서 Entity에 대해 알 필요가 없게 만들었다.
또한 View에서 ViewModel을 Observing하는 형태로 구현한다.
weak self를 통해 순환 참조를 방지한다.

protocol MoviesSearchFlowCoordinatorDependencies  {
    func makeMoviesListViewController() -> UIViewController
    func makeMoviesDetailsViewController(movie: Movie) -> UIViewController
}

final class MoviesSearchFlowCoordinator {
    
    private weak var navigationController: UINavigationController?
    private let dependencies: MoviesSearchFlowCoordinatorDependencies

    init(navigationController: UINavigationController,
         dependencies: MoviesSearchFlowCoordinatorDependencies) {
        self.navigationController = navigationController
        self.dependencies = dependencies
    }
    
    func start() {
        // Note: here we keep strong reference with actions closures, this way this flow do not need to be strong referenced
        let actions = MoviesListViewModelActions(showMovieDetails: showMovieDetails)
        let vc = dependencies.makeMoviesListViewController(actions: actions)
        
        navigationController?.pushViewController(vc, animated: false)
    }
    
    private func showMovieDetails(movie: Movie) {
        let vc = dependencies.makeMoviesDetailsViewController(movie: movie)
        navigationController?.pushViewController(vc, animated: true)
    }
}

View와 ViewModel 사이에 Coordinator를 추가해서 ViewModel을 수정하지 않고 다른 뷰를 쉽게 사용할 수 있게 만들어 준다.
또한 ViewController에 대한 책임을 줄여주는 역할을 한다.
Delegate랑 비슷한듯? Coordinator는 좀 더 알아봐야겠다.

Data Layer

final class DefaultMoviesRepository {
    
    private let dataTransferService: DataTransfer
    
    init(dataTransferService: DataTransfer) {
        self.dataTransferService = dataTransferService
    }
}

extension DefaultMoviesRepository: MoviesRepository {
    
    public func fetchMoviesList(query: MovieQuery, page: Int, completion: @escaping (Result<MoviesPage, Error>) -> Void) -> Cancellable? {
        
        let endpoint = APIEndpoints.getMovies(with: MoviesRequestDTO(query: query.query,
                                                                     page: page))
        return dataTransferService.request(with: endpoint) { (response: Result<MoviesResponseDTO, Error>) in
            switch response {
            case .success(let moviesResponseDTO):
                completion(.success(moviesResponseDTO.toDomain()))
            case .failure(let error):
                completion(.failure(error))
            }
        }
    }
}

// MARK: - Data Transfer Object (DTO)
// It is used as intermediate object to encode/decode JSON response into domain, inside DataTransferService
struct MoviesRequestDTO: Encodable {
    let query: String
    let page: Int
}

struct MoviesResponseDTO: Decodable {
    private enum CodingKeys: String, CodingKey {
        case page
        case totalPages = "total_pages"
        case movies = "results"
    }
    let page: Int
    let totalPages: Int
    let movies: [MovieDTO]
}
...
// MARK: - Mappings to Domain
extension MoviesResponseDTO {
    func toDomain() -> MoviesPage {
        return .init(page: page,
                     totalPages: totalPages,
                     movies: movies.map { $0.toDomain() })
    }
}
...

Usecase가 의존하고 있는 Repository가 있다.
DTO(Data Transfer Object)가 정의되어 있다.
DB, Network로 데이터를 가져오고, Domain에 매핑된다. (completion으로 전달, Usecase를 거쳐 최종적으로 ViewModel까지)

개념적으로는 이해를 했지만 실제로 써보면서 요놈들이랑 더 친해져야겠다.

[iOS / SwiftUI] MapKit, 실시간으로 도로명 주소 변환하기

kodo_o — Tue, 20 Dec 2022 20:05:32 +0900

23.01.13 - 앱을 처음 설치했을 때 현재 위치로 이동하지 않는 오류 해결

지난 번 프로토타입에 이어 이번 주부터는 MVP를 진행하고 있다.

기존에 더미 데이터로 구현했던 것들을 실제 FireStore와 연동하고 구현하지 못했던 부분들을 구현하는 것을 목표로 잡았다.

이번 주에 구현하려는 기능은 아래와 같다.

1. 사용자가 지도를 움직이면 움직인 좌표에 대한 도로명 주소를 실시간을 가져옴

2. 사용자가 지도를 움직이면 마커가 살짝 위로 올라가고, 움직임이 멈추면 마커가 다시 내려옴

3. 사용자의 현재 위치를 가져오고, 버튼을 클릭하면 현재 위치로 지도의 Focus를 변경함

하나씩 살펴보도록 하자.

1. 사용자가 지도를 움직이면 움직인 좌표에 대한 도로명 주소를 실시간으로 가져오기

말이 좀 길다.

간단하게 설명하자면 지도를 움직였을 때 도로명 주소 가져온다고 생각하면 된다.

이 기능은 지난 번 프로토타입 때는 구현하지 못한 기능이었지만, 공식문서를 하나 하나 살펴보면서 결국에는 해결했다.

우선 기존 구현 방식을 살펴보면,

CLLocationManagerDelgate를 채택하고 mapViewDidChangeVisibleRegion(_ mapView: MKMapView) 메서드로 지도가 움직일 때 위치 정보를 가져오려고 했었다. 해당 메서드는 지도에서 보이는 영역이 변경되면 호출되는 메서드이다. 따라서 사용자가 지도를 움직이면 이 메서드가 호출되고, 이 메서드 내부에서 위, 경도를 도로명 주소로 변환해주는 ReverseGeocoding을 진행하면 될 것 같았다.

사용자가 지도를 움직일 때, 즉각적으로 위치 정보는 잘 가져왔다.

하지만 이를 도로명 주소로 변환하기 위해서 reverseGeocoding을 적용하면 문제가 발생했다.

에러를 읽어보면 API 호출을 너무 자주해주고 있다는 것

이 문제를 해결하기 위해선 가장 먼저 떠오른 방법은

위, 경도가 바뀔 때마다 호출하는 것이 아니라, TimeInterval을 줘서 특정 시간에 한 번씩만 호출되도록 하는 방법이었다.

검색해보니 어떤 분이 이 방식으로 같은 문제를 해결하고 있었다.

[ios - Swift] MapView 사용하기 (MKMapView 2 / 2)

이번 글에서는 지난 글에서 얘기한 것과 같이 지역 내 검색 및 좌표에 대한 정보를 추출하는 방법을 알아보도록 하겠습니다. 위 gif를 살펴보면 맵 뷰의 현재 위치, 중앙 위치의 주소, 주변 가게

poky-develop.tistory.com

하지만 뭔가 다른 방법으로 접근하고 싶었다.

전에 플러터로 GoogleMaps을 사용할 때 비슷한 기능을 제공하는 메서드가 있었고,

MapKit에도 있을 것이라고 생각하고 공식문서를 찾아봤다.

역시나 Mapkit에서도 제공하고 있었다.

각각에 대해서 간단하게 설명하자면

mapView(_:regionWillChangeAnimated:) 는 Position이 변경되기 직전에

mapViewDidChangeVisibleRegion 는 Position이 변경될 때

mapView(MKMapView, regionDidChangeAnimated:) 는 Position 변경이 종료된 후에 호출된다.

그 중에서 나는 세 번째 메서드를 통해 ReverseGeocoding을 진행했고,

이해를 돕기 위해 해당 메서드 내부에 print문을 찍어봤다.

움직임을 멈추면 Changed가 찍힌다

이렇게 사용자가 지도를 움직이고,

위도, 경도가 조금이라도 바뀌면 mapViewDidChangeVisibleRegion 메서드가 호출되면서

func convertCLLocationToAddress(location: CLLocation) {
        let geocoder = CLGeocoder()
        
        // Location To Address
        geocoder.reverseGeocodeLocation(location) { placemarks, error in
            if error != nil {
                return
            }
            
            guard let placemark = placemarks?.first else { return }
            self.startPlace = "\(placemark.country ?? "") \(placemark.locality ?? "") \(placemark.name ?? "")"
        }
    }

위에 구현한 convertCLLocationToAddress 메서드가 호출되도록 구현했다.

convertCLLocationToAddress은 Swift에서 자체적으로 제공하는 reverseGeocodeLocation을 활용했다.

이렇게 위, 경도를 도로명 주소로 변환하는 기능은 구현했다.

2. 사용자가 지도를 움직이면 마커가 살짝 위로 올라가고, 움직임이 멈추면 마커가 다시 내려옴

다음은 두 번째, 역시 말이 길다.

사용자가 지도를 움직이면 마커에 특정 효과를 주고 싶었다.

이 기능이 왜 필요하냐고 물어본다면...

사용자 인터랙션을 좋아하기에...

배민이랑 쏘카에서도 이 기능을 찾아볼 수 있다.

아무튼 이 기능이 좋아서 구현을 하려고 했고, 역시 위에서 언급한 메서드를 사용했다.

사용자가 지도를 움직이고 있다는 상태를 저장하기 위한 프로퍼티를 정의해서 구현했다.

	@Published var isChanging: Bool = false // 지도의 움직임 여부를 저장하는 프로퍼티
	
	// ... 생략

	// MARK: - MapView에서 화면이 이동하면 호출되는 메서드
    func mapViewDidChangeVisibleRegion(_ mapView: MKMapView) {
        DispatchQueue.main.async {
            self.isChanging = true
        }
    }
    
    // MARK: - MapView에서 화면 이동이 종료되면 호출되는 메서드
    func mapView(_ mapView: MKMapView, regionDidChangeAnimated: Bool) {
        let location: CLLocation = CLLocation(latitude: mapView.centerCoordinate.latitude, longitude: mapView.centerCoordinate.longitude)
        
        self.convertLocationToAddress(location: location)
        
        DispatchQueue.main.async {
            self.isChanging = false
        }
    }
    
    // ... 생략
    
    // MARK: - location을 도로명 주소로 변환해주는 메서드
    func convertLocationToAddress(location: CLLocation) {
        let geocoder = CLGeocoder()
        
        geocoder.reverseGeocodeLocation(location) { placemarks, error in
            if error != nil {
                return
            }
            
            guard let placemark = placemarks?.first else { return }
            
            self.startPlace = "\(placemark.country ?? "") \(placemark.locality ?? "") \(placemark.name ?? "")"
        }
    }

3. 사용자의 현재 위치를 가져오고, 버튼을 클릭하면 현재 위치로 지도의 Focus를 변경함

마지막 세 번째는 사용자의 현재 위치를 가져오고, 버튼을 클릭하면 사용자의 현재 위치로 이동하는 기능이다.

우선은 사용자의 위치를 가져와야 하기에, 위치 권한을 요청하는 작업을 먼저 진행한다.

info 파일에 아래처럼 Key를 추가하고

사용자가 위치 권한을 설정했는지 확인하고, 위치 권한을 요청하는 메서드를 구현했다.

    // MARK: - 사용자의 위치 권한 여부를 확인하고 요청하거나 현재 위치 MapView를 이동하는 메서드
    func configureLocationManager() {
        mapView.delegate = self
        manager.delegate = self
        
        let status = manager.authorizationStatus
        
        if status == .notDetermined {
            manager.requestAlwaysAuthorization()
        } else if status == .authorizedAlways || status == .authorizedWhenInUse {
            self.moveFocusOnUserLocation()
        }
    }
    
    // MARK: - 사용자의 현재 위치로 MapView를 이동하는 메서드
    func moveFocusOnUserLocation() {
        mapView.showsUserLocation = true
        mapView.setUserTrackingMode(.follow, animated: true)
    }

또한 사용자가 위치 권한을 변경하면 호출되는 메서드에서도 moveFocusOnUserLocation을 호출했다.

공식문서를 보다가 기존에 사용한 메서드는 Deprecated 된 메서드여서 새로운 메서드로 변경했다.

    // MARK: - 사용자에게 위치 권한이 변경되면 호출되는 메서드
    // Deprecated
//    func locationManager(_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
//
//        if status == .authorizedAlways || status == .authorizedWhenInUse {
//            self.moveFocusOnUserLocation()
//        }
//    }
    
    func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
        if manager.authorizationStatus == .authorizedAlways || manager.authorizationStatus == .authorizedWhenInUse {
            self.moveFocusOnUserLocation()
        }
    }

사실 locationManagerDidChangeAuthorization 메서드를 사용하지 않아도 앱은 구현하려는 기능은 정상적으로 작동한다.

그 이유는 해당 메서드는 사용자가 위치 권한을 변경했을 때 호출되는 메서드이기 때문이다.

구현한 코드 상에서는 LocationManager가 EnvironmentObject로 생성되어 있고,

따라서 앱이 실행될 때 LocationManager의 인스턴스를 생성한다.

그 이후에 configureLocationManger 메서드가 호출되는 방식이다.

따라서 사용자가 위치 권한은 변경했는지와 관계 없이 위치 권한이 허용 상태이면,

사용자의 현재 위치로 이동하게 된다.

Apple Developer Documentation

developer.apple.com

그리고 공식문서를 읽어보면 알 수 있는데,

해당 메서드는 LocationManager의 인스턴스가 생성되거나 위치 권한이 변경될 때 호출된다고 나와있다.

실제로 앱이 실행될 때 EnvironmentObject로 LocationManager의 인스턴스를 생성하므로 앱의 완성도를 좀 더 높힌다면?

configureLocationManager에서 moveFocusOnUserLocation를 호출하지 않고,

locationManagerDidChangeAuthorization에서 호출하는 것이 더 적절하다고 생각한다.

아무튼 여기까지 해서 버그 해결~

(23.01.13 - 앱을 처음 설치했을 때 현재 위치로 이동하지 않는 오류 해결)

우선, 프로젝트에 대해 간단하게 설명하자면 간단한 일기 앱이고, 일기를 작성할 때 사용자의 위치를 등록할 수 있도록 구현할 계획이었다.

또한 일기 작성 페이지에서 MapView를 .onSheet(또는 .FullScreen)로 적용하고 있었다.

이 프로젝트에 기존 코드를 그대로 적용을 했는데,

앱을 처음 실행했을 때 위치 권한을 부여하고, 이후에 MapView가 정상적으로 작동하지 않는 오류가 있었다.

오류를 살펴보면,

1. 사용자의 현재 위치를 가져오지 못함.

2. 다른 기능(화면을 움직일 때 마커가 위, 아래로 움직이는 기능, 실시간으로 도로명 주소를 가져오는 기능)이 정상적으로 작동하지 않음.

코드를 다시 하나 하나 살펴보면서 내린 결론은 LocationManager 인스턴스의 생성 시기였다.

기존 코드는 MapView에서 LocationManager의 인스턴스를 생성하고 있었다.

이를 MapView가 보여지는 페이지가 아닌 이전 페이지(일기를 작성하는 페이지)에서 생성하고 파라미터로 넘겨주는 방식으로 변경했고,

오류를 해결할 수 있었다.

오류를 해결하면서 불필요한 코드를 제거하고, 위에서 언급한 moveFocusOnUserLocation의 역할을

locationManagerDidChangeAuthorization에서 처리하도록 변경했다.

또한 didUpdateLocation 메서드의 경우 특정 조건에서만 실행되고, 이 메서드를 호출하지 않아도 기능을 정상적으로 구현할 수 있기에 내부의 코드를 지워줬다.

전체 코드

// ... 생략
// MARK: - MapView 커스텀
struct MapViewCoordinator: UIViewRepresentable {
    @ObservedObject var locationManager: LocationManager
    
    func makeUIView(context: Context) -> some UIView {
        return locationManager.mapView
    }
    
    func updateUIView(_ uiView: UIViewType, context: Context) { }
}

//
//  LocationManager.swift
//
//  Created by 고도 on 2022/12/20.
//

import Foundation
import MapKit

class LocationManager: NSObject, ObservableObject, MKMapViewDelegate, CLLocationManagerDelegate {
    @Published var mapView: MKMapView = .init()
    @Published var isChanging: Bool = false // 지도의 움직임 여부를 저장하는 프로퍼티
    @Published var currentPlace: String = "" // 현재 위치의 도로명 주소를 저장하는 프로퍼티
    
    private var manager: CLLocationManager = .init()
    private var currentGeoPoint: CLLocationCoordinate2D? // 현재 위치를 저장하는 프로퍼티
    
    override init() {
        super.init()
        
        self.configureLocationManager()
    }
    
    // MARK: - 사용자의 위치 권한 여부를 확인하고 요청하거나 현재 위치 MapView를 이동하는 메서드
    func configureLocationManager() {
        mapView.delegate = self
        manager.delegate = self
        
        let status = manager.authorizationStatus
        
        if status == .notDetermined {
            manager.requestAlwaysAuthorization()
        } else if status == .authorizedAlways || status == .authorizedWhenInUse {
            mapView.showsUserLocation = true // 사용자의 현재 위치를 확인할 수 있도록
        }
    }
    
    // MARK: - MapView에서 화면이 이동하면 호출되는 메서드
    func mapViewDidChangeVisibleRegion(_ mapView: MKMapView) {
        DispatchQueue.main.async {
            self.isChanging = true
        }
    }
    
    // MARK: - MapView에서 화면 이동이 종료되면 호출되는 메서드
    func mapView(_ mapView: MKMapView, regionDidChangeAnimated: Bool) {
        let location: CLLocation = CLLocation(latitude: mapView.centerCoordinate.latitude, longitude: mapView.centerCoordinate.longitude)
        
        self.convertLocationToAddress(location: location)
        
        DispatchQueue.main.async {
            self.isChanging = false
        }
    }
    
    // MARK: - 특정 위치로 MapView의 Focus를 이동하는 메서드
    func mapViewFocusChange() {
        print("[SUCCESS] Map Focus Changed")
        let span = MKCoordinateSpan(latitudeDelta: 0.005, longitudeDelta: 0.005)
        let region = MKCoordinateRegion(center: self.currentGeoPoint ??  CLLocationCoordinate2D(latitude: 37.394776, longitude: 127.11116), span: span)
        mapView.setRegion(region, animated: true)
    }

    // MARK: - 사용자에게 위치 권한이 변경되면 호출되는 메서드 (LocationManager 인스턴스가 생성될 때도 호출)
    func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
        if manager.authorizationStatus == .authorizedAlways || manager.authorizationStatus == .authorizedWhenInUse {
            guard let location = manager.location else {
                print("[ERROR] No Location")
                return
            }
            
            self.currentGeoPoint = location.coordinate // 현재 위치를 저장하고
            self.mapViewFocusChange() // 현재 위치로 MapView를 이동
            self.convertLocationToAddress(location: location)
        }
    }
    
    // MARK: - 사용자의 위치가 변경되면 호출되는 메서드
    /// startUpdatingLocation 메서드 또는 requestLocation 메서드를 호출했을 때에만 이 메서드가 호출
    func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
        print("[SUCCESS] Did Update Locations")
    }
    
    // MARK: - 사용자의 현재 위치를 가져오는 것을 실패했을 때 호출되는 메서드
    func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
        print(error)
    }
    
    // MARK: - location을 도로명 주소로 변환해주는 메서드
    func convertLocationToAddress(location: CLLocation) {
        let geocoder = CLGeocoder()
        
        geocoder.reverseGeocodeLocation(location) { placemarks, error in
            if error != nil {
                return
            }
            
            guard let placemark = placemarks?.first else { return }
            
            self.startPlace = "\(placemark.country ?? "") \(placemark.locality ?? "") \(placemark.name ?? "")"
        }
    }
}

다음 게시물은 네이버 검색 API와 Katech 좌표를 WGS 좌표로 변환하는 네이버 Maps API을 활용해서

목적지를 지도 상에 표시해주는 기능에 대한 게시물로!

[iOS / SwiftUI] OnAppear, OnDisappear는 언제 호출될까?

kodo_o — Thu, 1 Dec 2022 00:24:29 +0900

SwiftUI로 개발을 진행하다가 View 내부에서 직접적으로 프로퍼티에 접근할 때 onAppear를 한 번쯤은 사용한 경험이 있을 것이다.

가령, print(프로퍼티)처럼 View 내부에서 접근하면 이런 에러가 뜬다.

View를 반환해달라는 에러다.

이런 에러와 마주치지 않기 위해 View 내부에서 직접적으로 접근하지 않고, onAppear 클로저 내부에서 접근하는 방식을 택한다.

아무튼 이럴 때 자주 사용하는 onAppear는 SwiftUI View Life Cycle에 속하고, 오늘은 Life Cycle에 대해 알아보려고 한다.

SwiftUI에선 3개의 Life Cycle이 있고, 각각의 Appear, Update, Disappear 이다.

https://www.vadimbulavin.com/swiftui-view-lifecycle

1. onAppear

https://developer.apple.com/documentation/swiftui/view/onappear(perform:)

onAppear은 View가 보여지기 전에 호출된다.

UIkit으로 치면 viewWillAppear라고 생각하는데 아래 링크에서는 viewDidAppear라고 설명하고 있다.

https://www.hackingwithswift.com/quick-start/swiftui/how-to-respond-to-view-lifecycle-events-onappear-and-ondisappear

How to respond to view lifecycle events: onAppear() and onDisappear() - a free SwiftUI by Example tutorial

Was this page useful? Let us know! 1 2 3 4 5

www.hackingwithswift.com

실제로 공식 문서에서도 "before this view appears"로 나와있고, 뷰가 나타나기 전이니까 willAppear가 맞지 않을까 하는데...

~~(알고 게신분이 있으시면 도움 부탁드립니다 ㅠ)~~

2. onDisappear

https://developer.apple.com/documentation/swiftui/view/ondisappear(perform:)

그렇다면 Disappear는?

onAppear과 반대로 View가 사라진 뒤에 호출된다.

요건 UiKit에서의 viewDidDisappear라고 생각한다. 사라진 뒤에 호출되는 거니까?

근데 뭔가 이렇게 세트로 맞아야할 것 같은데

(SwiftUI) - (UIKit)

onAppear - viewWillAppear

onDisappear - viewWillDisappear

내 생각대로하면 이런 느낌이라

(SwiftUI) - (UIKit)

onAppear - viewWillAppear

onDisappear - viewDidDisappear

안 맞으니까 불편하다.

이 부분은 좀 더 알아봐야겠다.

3. NavigationStack

Update에 대해서는 나중에 다시 한 번 알아보도록 하고...

사실 오늘은 특정 뷰의 Life Cycle을 알아보다가 신기해서 적는 글이다.

뭔가 전환이 일어나거나 특정 뷰 위에 존재하는 뷰인 NavigationStack - NavigationLink, ModalSheet, Alert.

이 친구들에 대해서 알아봤다.

우선 첫 번째로, NavigationStack에서의 언제 호출되는지 알아보자.

import SwiftUI

// 첫 번째 뷰
struct FirstView: View {
    var body: some View {
        NavigationStack {
            NavigationLink(destination: SecondView()) {
                Text("다음으로 가볼까요?")
            }
        }
        .onAppear {
            print("FirstView Appear")
        }
        .onDisappear {
            print("FirstView Disappear")
        }
    }
}

// 두 번째 뷰
struct SecondView: View {
    var body: some View {
        NavigationLink(destination: ThridView()) {
            Text("다음으로 가볼까요?")
        }
        .onAppear {
            print("SecondView Appear")
        }
        .onDisappear {
            print("SecondView Disappear")
        }
    }
}

// 세 번째 뷰
struct ThridView: View {
    var body: some View {
        NavigationStack {
            Text("세 번째까지 왔습니다.")
                .onAppear {
                    print("ThirdView Appear")
                }
                .onDisappear {
                    print("ThirdView Disappear")
                }
        }
    }
}

이렇게 코드를 작성하고 아까 위에서 봤던 Flow를 그대로 실행하면 어떤 결과가 출력될까?

위에서 얘기했던 것처럼 onAppear는 보여지기 전, onDisappear는 사라진 후에 호출된다고 했다.

그렇다면 다음 View의 onAppear가 먼저 출력되고 이후에 이전 View의 onDisappear가 출력되지 않을까?

FirstView Appear
SecondView Appear
FirstView Disappear
ThirdView Appear
SecondView Disppear

하지만 결과는 달랐다.

FirstView Disappear가 출력되지 않았다.

UI에서 사라졌는데 onDisappear가 출력되지 않는게 이상해서 디버깅을 진행했고, 실제로 UI Hierarchy를 출력해봤다.

엥, 똑같다?

사진을 보면 UIKitNavigationController와 NavigationStackHostingController가 동일하게 배치되어 있다.

NavigationLink로 화면이 전환되도, 그 기반을 이루는 NavigationStack(Controller)는 실제로 보이진 않지만 그대로 유지되고 있기에 onDisappear가 호출되지 않은 것이었다.

그렇다면 NavigationStack이 아닌, 내부에 위치하고 있는 NavigationLink에 적용하면 어떻게 될까?

struct FirstView: View {
    var body: some View {
        NavigationStack {
            NavigationLink(destination: SecondView()) {
                Text("다음으로 가볼까요?")
            }
            .onAppear {
                print("FirstView Appear")
            }
            .onDisappear {
                print("FirstView Disappear")
            }
        }
    }
}

뭔가, 이번엔 제대로 동작할 것 같다는 느낌이 들었다.

이번엔 우리가 처음에 예상했던 것처럼 출력됐다!

NavigationStack에서 onAppear나 onDisappear를 사용할 필요가 있을 때는 내부에 위치하고 있는 View에서 접근하는 것이 좋을 듯 하다!

NavigationStack이 이렇게 작동하는 걸 보니까 다른 View들도 궁금해졌다.

4. Modal View

그 다음 타자는, Modal View였다.

Model View도 다른 View과 함께 존재하므로 뭔가 알아보고 싶었다.

struct FirstView: View {
    @State private var isShow: Bool = false
    
    var body: some View {
        NavigationStack {
            VStack {
                NavigationLink(destination: SecondView()) {
                    Text("다음으로 가볼까요?")
                }
                Button(action: {
                    isShow.toggle()
                }) {
                    Text("모달 꺼내기")
                }
                .onAppear {
                    print("FirstView Appear")
                }
                .onDisappear {
                    print("FirstView Disappear")
                }
            }
            .sheet(isPresented: $isShow, onDismiss: {
                print("ModalSheet Dismiss")
            }) {
                Text("나? 모달")
            }
            .onAppear {
                print("ModelSheet Appear")
            }
            .onDisappear {
                print("ModelSheet Disappear")
            }
        }
    }
}

Model View가 보여지고 닫히는 Flow를 실행하면 어떤 결과가 출력 될까?

FirstView Appear

ModalSheet Appear

ModalSheet Dismiss

ModalSheet Disappear

하지만 달랐다...

FirstView Appear보다 ModalSheet Appear가 먼저 이뤄졌고 Modal이 사라졌을 때 Dismiss만 호출됐을 뿐, Disappear는 호출되지 않았다.

UI Hierarchy에서 Modal이 올라오기 전, 올라오고 난 후의 차이가 있음에도 ModalSheet Appear가 Modal이 실제로 올라왔을 때 출력되지 않는 이유에 대해서는 아직 잘 모르겠다.

~~(알고 게신 분 있으시면 도움 부탁드립니다 ㅠ)~~

그래서, 일단 NavigationStack처럼 내부에 존재하는 View에 onAppear와 onDisappear를 달아줬다.

struct FirstView: View {
    @State private var isShow: Bool = false
    
    var body: some View {
        NavigationStack {
            VStack {
                NavigationLink(destination: SecondView()) {
                    Text("다음으로 가볼까요?")
                }
                Button(action: {
                    isShow.toggle()
                }) {
                    Text("모달 꺼내기")
                }
                .onAppear {
                    print("FirstView Appear")
                }
                .onDisappear {
                    print("FirstView Disappear")
                }
            }
            .sheet(isPresented: $isShow, onDismiss: {
                print("ModalSheet Dismiss")
            }) {
                Text("나? 모달")
                    .onAppear {
                        print("ModelSheet Appear")
                    }
                    .onDisappear {
                        print("ModelSheet Disappear")
                    }
            }
        }
    }
}

과연?

이번엔 정상적으로 작동한다!

NavigationStack과 마찬가지로, Sheet에서 onAppear나 onDisappear를 사용할 필요가 있을 때는 내부에 위치하고 있는 View에서 접근하는 것이 좋을 듯 하다!

5. Alert

마지막으로 Alert, 이 친구도 궁금해졌다.

struct FirstView: View {
    @State private var isShow: Bool = false
    @State private var isAlert: Bool = false
    
    var body: some View {
        NavigationStack {
            VStack {
                NavigationLink(destination: SecondView()) {
                    Text("다음으로 가볼까요?")
                }
                Button(action: {
                    isShow.toggle()
                }) {
                    Text("모달 꺼내기")
                }
                .onAppear {
                    print("FirstView Appear")
                }
                .onDisappear {
                    print("FirstView Disappear")
                }
            }
            .sheet(isPresented: $isShow, onDismiss: {
                print("ModalSheet Dismiss")
            }) {
                VStack {
                    Text("나? 모달")
                    
                    Button(action: {
                        self.isAlert.toggle()
                    }) {
                        Text("알랏 띄우기")
                    }
                    .alert("안녕", isPresented: $isAlert) {
                        Button("확인") {}
                    } message: {
                        Text("나? 알랏")
                    }
                    .onAppear {
                        print("Alert Appear")
                    }
                    .onDisappear {
                        print("Alert Disappear")
                    }
                }
                .onAppear {
                    print("ModelSheet Appear")
                }
                .onDisappear {
                    print("ModelSheet Disappear")
                }
            }
        }
    }
}

이번에도 앞서 봤던 다른 View들처럼 마지막에 modifer를 추가해줬다.

Alert이 보여지는 View인, Modal View가 보여질 때 Alert의 onAppear도 호출된다.

역시나 우리의 생각대로 움직이지 않는다.

그래서 기존에 View의 마지막에 추가해줬던 modifier를 View의 내부로 이동시켰다.

struct FirstView: View {
    @State private var isShow: Bool = false
    @State private var isAlert: Bool = false
    
    var body: some View {
        NavigationStack {
            VStack {
                NavigationLink(destination: SecondView()) {
                    Text("다음으로 가볼까요?")
                }
                Button(action: {
                    isShow.toggle()
                }) {
                    Text("모달 꺼내기")
                }
                .onAppear {
                    print("FirstView Appear")
                }
                .onDisappear {
                    print("FirstView Disappear")
                }
            }
            .sheet(isPresented: $isShow, onDismiss: {
                print("ModalSheet Dismiss")
            }) {
                VStack {
                    Text("나? 모달")
                    
                    Button(action: {
                        self.isAlert.toggle()
                    }) {
                        Text("알랏 띄우기")
                            .onAppear {
                                print("Alert Appear")
                            }
                            .onDisappear {
                                print("Alert Disappear")
                            }
                    }
                    .alert("안녕", isPresented: $isAlert) {
                        Button("확인") {}
                    } message: {
                        Text("나? 알랏")
                    }
                }
                .onAppear {
                    print("ModelSheet Appear")
                }
                .onDisappear {
                    print("ModelSheet Disappear")
                }
            }
        }
    }
}

과연?

이번엔 우리가 생각했던 대로 호출된다!

UI hierarchy가 궁금해서 출력해봤다.

역시 이번에도 Controller가 존재하는 것을 볼 수 있다.

Controller가 존재하는 뷰라고 할까?

이러한 뷰들은 뷰 자체에 Life cycle modifier를 달지 말고,

내부에 존재하는 뷰에 modifier를 달아야

우리가 의도했던 대로 작동한다.

지난 포스팅에서도 ScrollView 자체에 달지 않고, 내부에 존재하는 LectureItemView에 달아준 것처럼 말이다.

만약 Life cycle이 제대로 동작하지 않는다면, Controller에 달려있나 확인해 볼 것!

[에러와의 동침] 22년 11월 4주차

kodo_o — Mon, 28 Nov 2022 01:08:25 +0900

22.11.21

json에 존재하는 key, value를 struct에서 정의하지 않을 경우에는 정상적으로 Decoding
반대로 json에 존재하지 않는 key, value를 struct에서 정의하는 경우에는 KeyNotFound Error가 발생
특정 value에 key-value가 부분적으로 존재할 때는 Optional을 적용
- 만약, key-value를 제대로 정의했는데 KeyNotFound Error가 발생하면 특정 key-value가 부분적으로 존재하는지 확인할 것

22.11.22

json에는 id가 없지만 identifiable을 만족시키기 위해 uuid를 넣어주는 경우 var이 아닌 let으로 선언
EnvironmentObject를 사용할 때, 최상단에서 인스턴스를 넣어주기에 뷰의 게층 구조 내에서만 접근이 가능
- 뷰의 계층 구조에서만 접근이 가능한 게 당연한 말이다.
- 만약, 접근할 수 없는데 접근하는 경우에 아래와 같은 오류가 발생
- SwiftUI/EnvironmentObject.swift:70: Fatal error: No ObservableObject of type <ClassType> found.

22.11.23

NSURLConnection SSL error
- API, 특히 OpenAPI 사용하다보면 자주 접하는 에러인데 App Transport Security Settings을 설정하면 해결
- 암호화가 적용되지 않은 http를 사용하면 발생하는 에러 또한 이걸로 해결 가능

ObservableObject로 VIewModel을 구현하고 특정 데이터에 변화를 줄 때 보라색 에러가 발생
- DispatchQueue를 통해 Main Thread에서 변경하도록 수정

22.11.24

Async-Await-Throw 관련 코드 좀 더 찾아보기
지오코딩 관련 이슈 분석

[iOS / SwiftUI] 스크롤, 무한으로 즐겨요~ (LazyVStack으로 무한 스크롤 구현하기)

kodo_o — Mon, 28 Nov 2022 00:34:21 +0900

오늘은 ScrollView와 LazyVStack을 활용하여 SwiftUI에서 무한 스크롤을 구현해보려고 한다.

사실, LazyVStack이 조금 생소할 수 있다.

LazyVStack은 말 그대로 Lazy하게 VStack을 그린다는 느낌으로,

VStack으로 보여줄 항목이 실제로 UI에 보여질 때 렌더링을 진행하는 View이다.

Apple Developer Docs

Apple Developer Documentation

developer.apple.com

그렇다면 기존에 사용하던 VStack과는 어떤 차이가 있을까?

평소에 사용하던 VStack은 뷰가 보여질 때(onAppear) 모든 항목을 렌더링한다.

그렇기에 ScrollView + VStack 조합으로 List를 나타낸다면 초기에 많은 리소스를 소모하게 된다.

적은 개수의 간단한 항목들을 표시할 경우에는 상관이 없지만,

많은 개수의 항목들을 표시할 경우에는 적절하지 못한 방법일 것이다.

가령, 중고거래 플랫폼 앱이 있는데 앱을 켰을 때 특정 카테고리에 있는 모든 항목을 가져온다고 해보자.

엄청난 리소스를 소모하게 될 것이다. ~~(사용자의 셀룰러 데이터나, CPU 혹은 RAM과 같은 자원이 될 수 있다.)~~

그래서 초기에는 10개, 혹은 20개와 같이 적은 개수의 데이터만 보여주고

마지막 항목이 보여지면 데이터를 추가하는 방식인 무한 스크롤 방식으로 구현하는 것이 좋다.

실제로 두 가지 방식으로 구현한 결과를 보면 그 차이를 명확하게 알 수 있다.

onAppear에 print를 달아주고 테스트를 진행했다.

평소에 사용하던 VStack은 View가 보여질 때 모든 항목이 렌더링 되는 것을 알 수 있다. (실제로는 보여지지 않더라도)

VStack

LazyVStack은 View가 보여질 때 모든 항목이 렌더링 되지 않고, 실제로 보여지는 것만 렌더링 되는 것을 알 수 있다.

LazyVStack

또한 자주 쓰는 List 역시 Lazy하게 동작한다. ~~(List를 애용하도록 하자)~~

List

그럼 이제 본론으로 들어가서, 실제 코드를 보면서 무한스크롤을 어떤 식으로 구현했는지 알아보자.

우선 파일 구조는 이렇게 잡았고, MVVM 패턴으로 구현했다.

1. Model

우선 Model의 경우, API를 호출했을 때 받아오는 Json의 구조를 그대로 구현해줬다.

import Foundation

struct Lecture: Codable {
    let pagination: Pagination
    let results: [Result]
}

struct Pagination: Codable {
    let count: Int
    let numPages: Int
    let next: URL
    
    enum CodingKeys: String, CodingKey {
        case count
        case numPages = "num_pages"
        case next
    }
}

struct Result: Codable, Identifiable {
    let id: UUID = UUID() // List를 사용하기 위해 identifiable 추가
    let name: String
    let media: Media
    let teachers: String
    let shortDesc: String
    let startDisplay: String
    
    enum CodingKeys: String, CodingKey {
        case name
        case teachers
        case media
        case shortDesc = "short_description"
        case startDisplay = "start_display"
    }
}

struct Media: Codable {
    let image: ImagePerSize
}

struct ImagePerSize: Codable {
    let raw: URL
    let small: URL
    let large: URL
}

사용한 API에 대한 정보는 아래 링크에서 확인할 수 있다.

국가평생교육진흥원_K-MOOC_강좌정보API

한국형 온라인 공개강좌(K-MOOC)의 강좌 목록 API 및 강좌 세부 정보 API 제공

www.data.go.kr

2. ViewModel

ViewModel에서는 Lecture를 담고 있는 리스트를 @Published로 정의했다.

또한 앱을 처음 켰을 때 강좌를 가져오는 메소드와 스크롤을 끝까지 내렸을 때 추가적으로 강좌를 가져오는 메소드를 정의했다.

import Foundation

class LectureViewModel: ObservableObject {
    @Published var items: [Result] = []
    private var nextURL: String = ""
    private var APIKEY: String = ""
    
    init() {}
    
    // 앱을 처음 켰을 때 강좌를 가져오기 위한 메소드
    func getLecturesOnServer() async throws {
        let responseData: Lecture = try await WebService.shared.loadJson("https://apis.data.go.kr/B552881/kmooc/courseList?serviceKey=\(APIKEY)&Page=1&Org=FUNMOOC&Mobile=1")
 
        DispatchQueue.main.async {
            self.items = responseData.results
            self.nextURL = "\(responseData.pagination.next)"
        }
    }
    
    // 스크롤을 끝까지 내렸을 때 추가적으로 강좌를 가져오기 위한 메소드
    func getLecturesOnServerAtFinishedScroll() async throws {
        let responseData: Lecture = try await WebService.shared.loadJson(nextURL)
        
        // 기존 강좌 목록에 새로 가져온 강좌 목록을 추가
        DispatchQueue.main.async {
            self.items += responseData.results
            self.nextURL = "\(responseData.pagination.next)"
        }
    }
}

프로퍼티 중에 nextURL의 경우, json에서 다음 강좌 목록에 해당하는 URL을 넘겨주는데 이를 활용했다.

3. WebService

WebService에서는 API를 호출할 때 사용하는 메소드를 정의해줬다.

import Foundation

class WebService {
    static let shared = WebService()
    
    // json을 T타입의 데이터로 디코딩하는 메소드
    func loadJson<T: Decodable>(_ url: String) async throws -> T {
        do {
            let url = URL(string: url)!
            let (data, _) = try await URLSession.shared.data(from: url)
            return try JSONDecoder().decode(T.self, from: data)
        } catch {
            fatalError("Unable to parse data : \(error)")
        }
    }
}

타입에 상관없이 해당 클래스와 메소드를 사용할 수 있도록 제네릭을 적용했다.

4. View

ViewModel에서 @Published로 정의한 items를 활용했고,

앱을 실행했을 때는 items에 어떠한 데이터도 들어있지 않기에, 이 때는 ProgressBar가 보여지도록 했다.

또한 동시에 API를 호출하여 강좌 목록을 가져오게 하였고

강좌 목록을 가져오는데 성공하면 items에 데이터가 들어있게 되고, 이후에는 ProgressBar가 사라지도록 했다.

ViewModel, 아니 ObservableObject를 활용하면 이러한 형태의 앱을 정말 손쉽게 구현할 수 있다. (SwiftUI 짱짱!! )

import SwiftUI

struct LectureListView: View {
    @EnvironmentObject var lectureVM: LectureViewModel
    @State private var num: Int = 0
    
    var body: some View {
        if lectureVM.items.isEmpty {
            ProgressView()
            // 앱을 처음 실행했을 때만 ProgressView를 보여줌
                .task {
                    do {
                        try await lectureVM.getLecturesOnServer()
                    } catch (let error) {
                        print("Unable to get data : \(error)")
                    }
                }
        } else {
            ScrollView {
                LazyVStack {
                    ForEach(lectureVM.items) { item in
                        LectureItemView(lecture: item)
                            .onAppear {
                                guard let index = lectureVM.items.firstIndex(where: { $0.id == item.id }) else { return }
                                
                                if index % 10 == 9 {
                                    Task {
                                        do {
                                            try await lectureVM.getLecturesOnServerAtFinishedScroll()
                                        } catch (let error) {
                                            print("Unable to get data : \(error)")
                                        }
                                    }
                                    
                                }
                            }
                    }
                }
            }
            .navigationTitle("K-MOOC 강좌 목록")
        }
        
    }
}

위에서 설명했던 것처럼 LazyVStack은 특정 아이템이 UI에 그려질 타이밍에 렌더링을 진행한다.

이를 활용해서 불러온 강좌 목록에서 마지막 강좌가 보여지면,

새롭게 강좌 목록을 불러오도록 구현했다.

강좌 목록을 보여주는 ScrollView에서 하나의 강좌를 보여주는 View인, LectureItemView는 이렇게 구현했다.

import SwiftUI

struct LectureItemView: View {
    var lecture: Result
    
    var body: some View {
        HStack {
            AsyncImage(url: lecture.media.image.small) { image in
                image
                    .resizable()
                
            } placeholder: {
                ProgressView()
                .frame(width: 140)
            }
            .scaledToFill()
            .frame(width: 140)
            .clipped()
            .cornerRadius(8)
            
            VStack(alignment: .leading) {
                Text(lecture.name)
                    .font(.body)
                    .fontWeight(.bold)
                
                Spacer()
                
                Text(lecture.teachers)
                    .font(.footnote)
                    .lineLimit(1)
                
                Spacer()
                
                Text(lecture.startDisplay)
                    .font(.footnote)
            }
            .padding(4)
            
            Spacer()
        }
        .padding(8)
    }
}

실제 구현 결과를 보자!

마지막 강좌가 보여질 때 API를 호출하여 10개의 강좌를 더 가져오는 것을 볼 수 있다!

"let us: Go! 2022 Fall"에 다녀왔습니다!

kodo_o — Mon, 14 Nov 2022 19:38:06 +0900

두근두근 렛어스고!

지난 주에 렛어스고에 다녀왔다.
11월 5일에 다녀왔지만! 지금 회고를 쓰고 있다.
~~원래 회고는 일주일 뒤에 쓰는게 국룰!~~

우선 렛어스고는 지금 하고 있는 멋사 앱스쿨에서 한 분이 정보를 공유해주셔서 알게 됐고, 운 좋게 티켓팅에 성공해서 참가하게 됐다.

티켓은 학생 티켓과 일반 티켓이 있다.
학생 티켓이 훨씬 저렴하지만 수량이 적어서, 학생 티켓 예매에는 실패했고 일반 티켓을 예매했다!
버스를 타고 서울까지 가야하는 상황이라 조금 고민이 많았지만, 그래도 iOS 세미나를 참가해보고 싶어서 아침 일찍 서울을 향했다.

발표 장소는 코엑스 앞에 있는 Finda였다.

30분 정도 일찍 도착했더니 운영진을 제외하고는 거의 없었다.
뒤에 계신 분과 얘기를 나눌까했지만 같이 오신 분이 있는 것 같아서 그냥 조용히 혼자 있었다.
체크인할 때 받은 사은품(후드집업, 스티커, 컵)을 살펴보고 인증샷을 찍었따!

13시가 되자 세미나가 시작됐다.

간단하게 개회식을 진행하고 바로 첫 번째 Speaker님의 발표로 이어졌다.
Rubin님의 발표였고, UIKit을 SwiftUI처럼 구현하기에 관한 주제였다. 신기했다!

발표와는 별개로 주변 사람들과 친해지고 싶었다.
하지만.. 뭔가 다른 분들은 다들 이미 친분이 있으신듯한? 느낌이었다.
새로운 사람들을 만나는 걸 좋아하는 나인데, 이미 친하신 모습을 보니까 말 걸기가 더 어려워졌다... ㅠ
그렇게 고민하다가 내 양쪽에 계신 분한테 말을 걸었다.
한 분은 야곰아카데미를 수강하고 있는 분이셨고, 다른 한 분은 개발자 && 대학생이신 분이었다.

아무튼 그렇게 간단하게 자기 소개를 하니 쉬는 시간이 끝나서 다음 세션으로 넘어 갔다.
그러다 네트워킹 및 기념사진 촬영 시간이 되었고, 서로 인사도 나누고 명함도 받았다. ~~명함 많이 받았어요~~~

대부분 현업 개발자분들이었다.
나처럼 부트 캠프를 듣고 있는, 대학생분들도 꽤 있었다.

한 가지 놀랐던 것은 고등학생 개발자분들이 꽤나 많았다는 사실이었다.
부럽기도 하면서 되게 멋있어 보였다. ~~나는 그 나이에 무엇을 하고 있었던가...~~

거의 한 시간정도 네트워킹 시간을 가졌다.
다른 분들과 얘기할 수 있어서 너무 좋았다.

이후에 3개의 발표 세션이 더 있었는데 그 중, Clyne님과 Sueaty님의 발표가 너무 재밌었다.
Clyne님은 인터페이스 모듈을 통해 의존성을 분리하는 내용이었는데 어려운 내용을 되게 쉽게 설명해주셔서 더 인상 깊었다.
Sueaty님은 ~~연예인~~, 비개발적인 주제였고, 회사를 즐겁게 다니는 방법에 대해 발표해주셨는데 너무 재밌었다.
두 분의 발표를 듣고 너무 감명받아서 직접 자리에 찾아가서 인사까지 드리고 왔다! 명함도 받았따.

다른 분들의 발표도 너무 재밌었다.
승진님의 UITesting, 태승님의 모두를 위한 앱 만들기, Rubin, 태태님의 발표까지...

태태님의 발표!

공식적인 일정이 끝나고 근처 치킨집에서 뒷풀이가 진행됐다.
새로운 사람들과 사담을 나눌 수 있어서 너무 좋았다.

사실 가기 전에, 많은 생각이 들었다. 아직 iOS를 시작한지 얼마안됐기에 이러한 세미나를 참석해도 될까? 라는 고민이었지만 결과는 대만족이었다.

현업 개발자분들과 대학생분들, iOS에 진심인 분들을 실제로 만나뵙고 이런 저런 얘기를 나누면서 동기 부여가 확실하게 됐다.
안드로이드에겐 미안하지만 iOS에 발을 들인게 정말 잘한 선택이라고 생각한다. 너무 재밌다!

기회가 된다면 내년에도 참석해보려고 한다.

11월 30일에 더 큰 행사인 렛츠스위프트가 열리는데 이건 평일이라 참석하지 못할 듯하다. 아쉽다... ㅠ

LetSwift2022:Swift Playgrounds

iOS 개발자들의 놀이터, 레츠스위프트 컨퍼런스 2022 에서 온라인의 갈증을 해소해보세요.

letswift.kr

발표 자료

1. 태태님 - MVI Architecture

GitHub - uuu1101/Letusgo-2022-fall: Let us go ! 2022 fall 발표자료

Let us go ! 2022 fall 발표자료. Contribute to uuu1101/Letusgo-2022-fall development by creating an account on GitHub.

github.com

2. 태승님 - 공정사회를 위한 엔지니어링: 모두를 위한 앱 만들기

GitHub - ryan-son/let-us-go-2022-fall-engineering-for-equity: let us: Go! 2022 가을, 공정 사회를 위한 엔지니어링:

let us: Go! 2022 가을, 공정 사회를 위한 엔지니어링: 모두를 위한 제품 만들기 섹션 자료입니다. - GitHub - ryan-son/let-us-go-2022-fall-engineering-for-equity: let us: Go! 2022 가을, 공정 사회를 위한 엔지니어링:

github.com

3. Clyne님 - 느슨한 결합을 몸으로 느껴보자

GitHub - clyne-kim/letusgo2022: 렛어스고 2022 가을 세미나 자료

렛어스고 2022 가을 세미나 자료. Contribute to clyne-kim/letusgo2022 development by creating an account on GitHub.

github.com

[iOS / Swift] Swift 문자열 정복하기 (aka 'Character')

kodo_o — Thu, 3 Nov 2022 20:16:48 +0900

Swift로 문자열 문제를 풀다보면 오류를 자주 접하게 된다.

(~~error: cannot convert value of type 'String.Element' (aka 'Character') to closure result type 'String)~~

'이게 왜 안됨? ㅋㅋ' 라는 생각이 들 정도로 안된다.

아무튼 이런 오류를 자주 접했기에 글로 정리하면서 다시 한 번 복습하려고 한다.

파이썬 1승

1. 문자열 형 변환하기

1. String -> Int

다른 언어에서처럼 Int()로 형 변환을 진행한다.

이 때, String인지 SubString인지 Character인지 잘 살펴본다.

(그렇지 않으면... ~~error: cannot convert value of type 'String.Element' (aka 'Character') to closure result type 'String~~')

var a: String = "1"
var b: Substring = "2"
var c: Character = "3"

print(Int(a)) // Optional(1)
print(Int(b)) // Optional(2)
print(Int(c)) // Error!

2. Int -> String

var a: Int = 1

print(String(a)) // 1

3. 다른 기본 타입들

String -> Int 와 동일하다.

String과 Character, Optional에 주의한다.

2. 문자열을 한 개씩 분리하기

하나의 문자열을 하나의 문자로 나눠야할 때는 map을 사용한다. 반환 값이 [Character] 타입이므로 주의한다.

var s: String = "abcdefg"

var characters: [Character] = s.map { $0 } // [Character]
var strings: [String] = s.map { String($0) } // [String]

3. 문자열을 특정 문자를 기준으로 나누기

문자열을 공백이나 기호를 기준으로 나눌 때는 split이나 components를 사용한다.

1. split

반환 결과가 [SubString] 타입이므로 [String] 타입이 필요한 경우 형 변환을 해준다.

var s: String = "a b c d e f g" // 공백이 존재

var subStrings: [SubString] = s.split(separator: " ").map { $0 } // [SubString]
var strings: [String] = s.split(separator: " ").map { String($0) } // [String]

2. components

비슷하게 components가 있고, Foundation import를 통해 사용할 수 있으며 반환 값이 [String] 타입이다.

import Foundation

var s: String = "a b c d e f g" // 공백이 존재
var strings: [String] = s.components(separatedBy: " ")

4. 문자열 내 특정 문자 포함 여부

1. contains

var s: String = "kodo"
var a: String = "k"
var b: Character = "k"
var c: Substring = "k"

print(s.contains(a)) // true
print(s.contains(b)) // true
print(s.contains(c)) // true

2. hasPrefix

앞에서부터 문자열을 비교한다.

hasPrefix 메소드에 넘겨주는 인자는 String 타입이어야 한다.

var s: String = "kodo"
var a: String = "k"
var b: Character = "k"

print(s.hasPrefix(a)) // true
print(s.hasPrefix(b)) // Error!

3. hasSuffix

hasPrefix와 반대로 뒤에서부터 문자열을 비교한다.

var s: String = "kodo"
var a: String = "k"
var b: Character = "k"

print(s.hasSuffix(a)) // false
print(s.hasSuffix(b)) // Error!

var c: String = "o"
var d: String = "do"
var e: String = "odo"
var f: String = "kod"

print(s.hasSuffix(c)) // true
print(s.hasSuffix(d)) // true
print(s.hasSuffix(e)) // true
print(s.hasSuffix(f)) // false

5. 문자열 내 특정 위치, 문자 반환

1. startIndex, endIndex

Swift에서는 문자열에 인덱스로 직접적으로 접근할 수 없다.

String[index]가 불가능하고, String[String.index]로 접근할 수 있다.

startIndex는 문자열의 첫 인덱스를, endIndex는 문자열의 마지막 인덱스 + 1을 반환한다.

var s: String = "kodo"
var start: String.Index = s.startIndex
var end: String.Index = s.endIndex

print(s[0]) // Error!
print(s[start]) // k
print(s[end]) // Error!

이를 활용해서 문자열 파싱이 가능하다.

var s: String = "kodo"
var start: String.Index = s.startIndex
var end: String.Index = s.endIndex

print(s[start..<end - 1]) // kodo
print(s[start...) // kodo

2. firstIndex

firstIndex 메소드에 넘겨주는 인자가 처음 등장하는 인덱스를 반환한다.

인자는 Character 타입이고, 반환 값이 없을 수도 있기에 해당 메소드의 반환 타입은 Optional이다.

var s: String = "kodo"

var e1: String = "o"
var index: String.Index? = s.firstIndex(of: e1) // Error!

var e2: Character = "o"
var index: String.Index? = s.firstIndex(of: e2) // Optional(...)

3. index

특정 인덱스 이전, 이후의 인덱스에 접근할 수 있다.

after의 경우 after 이후의 인덱스를, before의 경우 before 이전의 인덱스를 반환한다.

var s: String = "kodo"
var start = s.startIndex // 0
var end = s.endIndex // 4

print(s[s.index(after: start)]) // s[1] = o
print(s[s.index(start, offsetBy: 0)]) // s[0] = k
print(s[s.index(start, offsetBy: 1)]) // s[1] = o

print(s[end]) // Out of Bounds
print(s[s.index(before: end)]) // s[3] = o
print(s[s.index(end, offsetBy: -1)]) s[3] = o

6. 아스키코드 변환하기

문자를 아스키코드로 변환하거나, 아스키코드를 문자로 변환할 때는 UnicodeScalar를 사용한다.

1. String -> ASCII

아스키코드로 변환할 때는 UnicodeScalar에 넘겨주는 인자가 String 타입이어야 한다.

또한 변환 결과가 Optional이므로 강제 언래핑을 진행한다.

var s: String = "kodo"

var stringToAscii: [Int] = s.map { UnicodeScalar($0)?.value } // Error!
var stringToAscii: [Int] = s.map { UnicodeScalar(String($0))?.value } // Error!
var stringToAscii: [UInt32] = s.map { UnicodeScalar(String($0))!.value } // 107 ...
var stringToAscii: [Int] = s.map { Int(UnicodeScalar(String($0))!.value) } // 107 ...

2. ASCII -> String

역시 UnicodeScalar의 결과가 Optional이므로 강제 언래핑을 진행한다.

var asciis: [Int] = [107, 111, 100, 111] 
var asciiToString = asciis.map { String(UnicodeScalar($0)!) }.joined() // joined로 문자열 변환

7. 문자열 뒤집기

Collections 타입의 reversed를 활용한다.

var s: String = "kodo"
print(s.map { String($0) }.reversed().joined()) // "odok"

[iOS / SwiftUI] 다양한 상태 프로퍼티들을 알아보자!

kodo_o — Mon, 24 Oct 2022 13:52:27 +0900

State와 Binding

지난 시간 @State와 @Binding 프로퍼티 래퍼에 대해 학습했다.

1. @State

@State 프로퍼티 래퍼를 사용해서 상태 프로퍼티를 작성하면 해당 프로퍼티가 선언된 뷰와 바인딩할 수 있게 된다.

좀 더 쉽게 설명하자면 뷰와 바인딩이 되어 있는 상태프로퍼티에 변경이 일어나면 자동으로 뷰가 갱신된다는 말이다.

코드로 직접 살펴보자.

아래 코드는 버튼을 클릭하면 숫자가 1씩 증가하도록 구현한 앱이다.

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
    }
}

앱을 실행시키고 버튼을 눌러보면 누를 때마다 숫자가 1씩 증가하는 것을 볼 수 있다.

숫자가 증가한 뒤 이를 참조하고 있는 뷰를 갱신하지 않아도 알아서 갱신된다.

그렇다면 @Binding는 무엇일까?

2. @Binding

위에서 작성한 코드는 상태 프로퍼티를 선언한 뷰에서 상태 프로퍼티를 직접 사용하고 있다.

즉, 선언과 사용이 하나의 뷰(Struct)에서 진행된다는 말이다.

그렇다면 메인 뷰(부모)에서 선언한 상태 프로퍼티를 서브 뷰(자식)에서 사용한다면 어떻게 될까?

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
    }
}

struct SubView: View {
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
        }
        .padding()
        .background(.gray)
    }
}

코드를 작성하고 빌드를 진행하면 컴파일 에러가 발생한다.

SubView 내부에 number 프로퍼티가 선언되어 있지 않기 때문이다.

그렇다면 SubView 내부에 number 프로퍼티를 선언하면 어떻게 될까?

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
    }
}

struct SubView: View {
	private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
        }
        .padding()
        .background(.gray)
    }
}

이번엔 빌드는 정상적으로 진행된다.

하지만 버튼을 클릭해도 서브뷰에 있는 텍스트는 변경되지 않는다.

SubView의 number와 ContentView의 number는 서로 다른 프로퍼티이기 때문이다.

그렇다면 두 개를 연결해주면 문제를 해결해 줄 수 있지 않을까?

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
            
            SubView(number: number)
        }
    }
}

struct SubView: View {
	// 생성자를 통해 number 전달
    init(number: Int) {
        self.number = number
    }
    
    private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
        }
        .padding()
        .background(.gray)
    }
}

생성자를 통해서 메인 뷰의 number를 전달했더니 서브 뷰에서도 화면이 갱신되는 것을 볼 수 있다.

서론이 길었지만 @Binding 프로퍼티 래퍼를 통해서 간단한 형태로 작성할 수 있다.

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
            
            SubView(number: $number)
        }
    }
}

struct SubView: View {
    @Binding var number: Int
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
        }
        .padding()
        .background(.gray)
    }
}

생성자를 통해서 프로퍼티를 전달한 방식과 유사하다.

차이점은 서브 뷰에서 @Binding 프로퍼티 래퍼로 변수를 선언만 한다는 것이다.

메인 뷰에서는 Argument로 $number를 전달한다.

여기서 명심해야할 것은 $(달러)!

$(달러)기호를 빼먹으면 컴파일 에러가 발생한다.

서브 뷰에서 Binding<Int> 형으로 number를 선언했는데 Int형 number를 전달해서 발생하는 타입 에러이다.

처음 의도했던 대로 정상적으로 작동하는 것을 볼 수 있다.

하지만 의문점이 한 가지가 있다.
생성자를 통해서 전달하는 방식도 있는데 굳이 @Binding이라는 프로퍼티 래퍼가 등장한 이유는 무엇일까?

지금 예시들은 뷰 사이에서 단방향으로 데이터를 주고 받고 있다.

메인 뷰(ContentView) -> 서브 뷰(SubView) 방향으로, 다시 말해 서브 뷰에 파라미터로 메인 뷰의 프로퍼티를 전달하고 있다.

양방향으로 데이터를 주고 받도록 코드를 변경해보면 @Binding을 사용하려는 이유에 대해 명확하게 알 수 있다.

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
            
            SubView(number: self.number)
        }
    }
}

struct SubView: View {
    private var number: Int = 0
    
    init(number: Int) {
        self.number = number
    }
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
            
            Button(action: {
            	self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

서브 뷰에도 버튼을 달아서 SubView 값도 변경할 수 있도록 코드를 변경해줬다.

하지만 컴파일 오류를 발생시킨다.

View 자체가 Struct이므로 Immutable하기 때문이다.

컴파일 자체가 안되지만 논리적으로 생각해보면 우리가 구현하려는 기능은 일반적인 프로퍼티로는 불가능하다는 것을 알 수 있다.

메인 뷰 내부에 서브 뷰 인스턴스를 생성하고 파라미터로 프로퍼티 값을 전달하고 있다.

메인 뷰에서도 서브 뷰의 프로퍼티를 접근하기 위해선, 서브 뷰 내부에 메인 뷰 인스턴스를 생성하여 파라미터로 전달하기 때문이다.

그렇다면 이 기능은 구현할 수 없는 것일까?

이 때, @Binding 프로퍼티 래퍼를 사용하면 된다!

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        VStack {
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
            
            SubView(number: $number)
        }
    }
}

struct SubView: View {
    @Binding var number: Int
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
    
    mutating func addNumber() {
        self.number += 1
    }
}

정상적으로 컴파일이 정상적으로 진행되고 앱을 실행해보면 메인 뷰의 number와 서브 뷰의 number가 같은 값을 가지고 있고, 양방향으로 데이터를 주고 받고 있는 것을 볼 수 있다!

이것이 바로 @Binding을 사용하는 이유이다.

하지만 @Binding 역시 단점은 존재한다.

앞서 말했던 것처럼 상태 프로퍼티는 프로퍼티를 선언한 뷰에서만 접근이 가능하다.

하위 뷰가 아니거나 바인딩이 구현되어 있지 않으면 다른 뷰에서 접근이 불가능하다.

또한 뷰 자체에 종속적인 개념이므로 뷰가 사라지면 프로퍼티 역시 사라진다.

이러한 문제를 해결해주는 것이 Observable 객체다.

앞서 말한 문제점들을 해결하고, 다른 뷰에서 접근할 수 있는 영구적인 데이터를 표현하기 위해 사용한다.

Observable 객체

아래 코드와 빌드된 앱을 보면 @Binding 프로퍼티 래퍼를 사용해서, 페이지가 변경되어도 하나의 값을 가르키고 이를 변경하고 있다.

struct ContentView: View {
    @State private var number: Int = 0
    
    var body: some View {
        NavigationView {
            VStack {
                Text("\(self.number)")
                
                Button(action: {
                    self.number += 1
                }) {
                    Text("눌러주세요!")
                }
                
                SubView(number: $number)
                
                
                NavigationLink(destination: SecondView(number: $number)) {
                    Text("Second View로 이동")
                }
            }
        }
    }
}

struct SubView: View {
    @Binding var number: Int
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

struct SecondView: View {
    @Binding var number: Int
    
    var body: some View {
        VStack {
            Text("This is Second View")
            Text("\(self.number)")
            
            Button(action: {
                self.number += 1
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

하지만 메인 뷰 내부에 Second View가 종속적으로 선언되어 있고, 매번 @Binding를 달아준 프로퍼티를 선언해야 한다.

단순히 하나의 페이지(부모)의 프로퍼티를 다른 페이지(자식)에서 사용하는 경우에는 기존 방식대로 @Binding으로 전달해도 되지만, 페이지 이동이 잦아지면 매번 직접 연결해줘야 하므로 번거롭다.

이런 문제들을 Observable이 해결해준다.

ViewModel과 비슷한 역할을 수행하는데, 특정 상황에 따라 변경되는 데이터를 수집하고 관리하는 역할을 수행한다고 볼 수 있다.

Observable 객체는 Observer 객체와 하나의 세트를 이룬다.

Observable 객체는 프로퍼티를 게시(Publish)하고 Observer 객체는 이를 구독하고 있다.

import Foundation
import Combine

class CustomNumber: ObservableObject {
    @Published var number = 0
    
    func increateNumber() {
        self.number += 1
    }
}

struct ContentView: View {
    @ObservedObject var number: CustomNumber
    
    var body: some View {
        NavigationView {
            VStack {
                Text("\(self.number.number)")
                
                Button(action: {
                    self.number.increateNumber()
                }) {
                    Text("눌러주세요!")
                }
                
                SubView(number: number)
                
                NavigationLink(destination: SecondView(number: number)) {
                    Text("Second View로 이동")
                }
            }
        }
    }
}

struct SubView: View {
    @ObservedObject var number: CustomNumber
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number.number)")
            
            Button(action: {
                self.number.increateNumber()
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

struct SecondView: View {
    @ObservedObject var number: CustomNumber
    
    var body: some View {
        VStack {
            Text("This is Second View")
            Text("\(self.number.number)")
            
            Button(action: {
                self.number.increateNumber()
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

기존에 @Binding으로 작성한 코드와 비교해보면 number 증가에 대한 로직을 ObservableObject 프로토콜을 채택한 CustomNumber에서 담당하고 있는 것을 볼 수 있다.

Environment 객체

number 증가에 대한 로직을 CustomNumber 클래스로 분리했지만 여전히 Navigation을 진행할 때 구독 객체에 대한 참조체를 전달해야 한다.

상황에 따라 다르지만 앱 내의 여러 뷰가 동일한 구독 객체에 접근해야하는 경우에는 복잡해질 수 있다.

이럴 때 사용하는 것이 Environment 객체다.

방법은 Observable 객체와 동일하지만 뷰에서 뷰로 전달할 필요 없이 모든 뷰가 접근할 수 있다는 것이다.

import SwiftUI

@main
struct _21024_ObservableApp: App {
    let customNumber: CustomNumber = CustomNumber()
    
    var body: some Scene {
        WindowGroup {
            ContentView().environmentObject(customNumber)
        }
    }
}

하지만 사용하기 전에 Sence에서 각각의 뷰에서 참조하려는 ObservableObject를 등록해줘야 한다.

struct ContentView: View {
    @EnvironmentObject var number: CustomNumber
    
    var body: some View {
        NavigationView {
            VStack {
                Text("\(self.number.number)")
                
                Button(action: {
                    self.number.increateNumber()
                }) {
                    Text("눌러주세요!")
                }
                
                SubView()
                
                NavigationLink(destination: SecondView()) {
                    Text("Second View로 이동")
                }
            }
        }
    }
}

struct SubView: View {
    @EnvironmentObject var number: CustomNumber
    
    var body: some View {
        VStack {
            Text("This is SubView")
            Text("\(self.number.number)")
            
            Button(action: {
                self.number.increateNumber()
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

struct SecondView: View {
    @EnvironmentObject var number: CustomNumber
    
    var body: some View {
        VStack {
            Text("This is Second View")
            Text("\(self.number.number)")
            
            Button(action: {
                self.number.increateNumber()
            }) {
                Text("눌러주세요!")
            }
        }
        .padding()
        .background(.gray)
    }
}

기존 방식과 다르게 뷰와 뷰 사이 간에 Navigation을 진행할 때 매개변수로 넘겨주지 않아도 된다는 장점이 있다.

사실 @State, @Binding, @ObservedObject, @EnvironmentObject 중에 어느 것을 쓸 지는 개발자 마음이고 어떻게 구현하느냐에 따라 달라진다고 생각한다.

그래도 각 프로퍼티 래퍼별로 장점이 있으니, 장점에 맞게 사용하면 될 듯하다.

정리

하나의 뷰, 혹은 특정 뷰의 종속적인 뷰에서 단방향으로 데이터를 주고 받을 때 -> @State

양방향으로 데이터를 주고 받을 때 -> @Binding

양방향으로 주고 받으면서, 로직을 분리하고 싶을 때 -> @ObservedObject

모든 뷰에서 참조할 수 있는 데이터와 로직을 분리하고 싶을 때 -> @EnvironmentObject

회고

Environment 객체의 경우 Flutter의 Provider와 매우 유사한 형태를 지녔다. Provider를 통해 하위 위젯에서 데이터를 접근할 수 있는데 이것과 완전히 똑같았다. 한 가지 궁금한 점은 Flutter에서는 값의 변경이 일어나면 해당 위젯을 전부 다시 렌더링을 진행한다. (Consumer를 적용해서 특정 부분 렌더링도 가능하다.) SwiftUI에서는 자체적으로 특정 부분만 렌더링을 하는건지 전부 렌더링을 진행하는 것인지 좀 더 알아봐아겠다.

[iOS / SwiftUI] .mask를 활용하여 Custom ProgressView를 구현해보자

구현

View

ViewModifier

Extension

TMI...

[iOS / SwiftUI] View Memory Graph Hierarchy를 활용해보자

AVSpeechSynthesizer의 동작 과정

문제 상황

아, 이거다!

그래서, 어떻게 제거할건데?

전체 코드

광고

[Architecture] MVVM + Clean Architecture를 알아보자

Clean Architecture

종속성 방향

데이터 흐름

Domain Layer

Presentation Layer

1. ViewModel

2. ViewController

Data Layer

[iOS / SwiftUI] MapKit, 실시간으로 도로명 주소 변환하기

1. 사용자가 지도를 움직이면 움직인 좌표에 대한 도로명 주소를 실시간으로 가져오기

2. 사용자가 지도를 움직이면 마커가 살짝 위로 올라가고, 움직임이 멈추면 마커가 다시 내려옴

3. 사용자의 현재 위치를 가져오고, 버튼을 클릭하면 현재 위치로 지도의 Focus를 변경함

전체 코드

[iOS / SwiftUI] OnAppear, OnDisappear는 언제 호출될까?

1. onAppear

2. onDisappear

3. NavigationStack

4. Modal View

5. Alert

[에러와의 동침] 22년 11월 4주차

22.11.21

22.11.22

22.11.23

22.11.24

[iOS / SwiftUI] 스크롤, 무한으로 즐겨요~ (LazyVStack으로 무한 스크롤 구현하기)

1. Model

2. ViewModel

3. WebService

4. View

"let us: Go! 2022 Fall"에 다녀왔습니다!

두근두근 렛어스고!

발표 자료

[iOS / Swift] Swift 문자열 정복하기 (aka 'Character')

1. 문자열 형 변환하기

1. String -> Int

2. Int -> String

3. 다른 기본 타입들

2. 문자열을 한 개씩 분리하기

3. 문자열을 특정 문자를 기준으로 나누기

1. split

2. components

4. 문자열 내 특정 문자 포함 여부

1. contains

2. hasPrefix

3. hasSuffix

5. 문자열 내 특정 위치, 문자 반환

1. startIndex, endIndex

2. firstIndex

3. index

6. 아스키코드 변환하기

1. String -> ASCII

2. ASCII -> String

7. 문자열 뒤집기

[iOS / SwiftUI] 다양한 상태 프로퍼티들을 알아보자!

State와 Binding

1. @State

2. @Binding

Observable 객체

Environment 객체

정리

회고