Day 11 개발일지 iOS
처음에는 아래 자료를 보고 우리만의 큐알 코드 스캔 뷰를 만들어보려고 했다. 하지만 바인딩하는 과정에서 에러가 났고 정확한 이유를 알지 못한 채 시간만 흘러갔다.
Camera preview and a QR-code Scanner in SwiftUI
그러다가 아래 자료를 발견했고, 여기서 보여주었던 라이브러리를 사용하기로 결정했다.
Scanning QR codes with SwiftUI
구글과 깃허브의 큐알 코드에서 넘어오는 값을 빨리 확인해 보고 싶어서 우선은 라이브러리를 사용하여 구현했다. 하지만 향후 꼭 라이브러리를 삭제하고 우리가 만든 스캐너 뷰를 사용할 것이다.
otpauth://totp/GitHub:{ 내 아이디 }?secret={ 키값 }&issuer=GitHub
구글과 깃허브 모두 위와 같은 형식으로 값이 넘어오는 것을 확인했다. secret 값을 사용하여 비밀번호를 생성하여야 하기 때문에 parsing 과정이 필요했다.
처음에는 ?로 자르고 &로 또 자르고.. 이런 방식으로 일일히 값 추출 과정을 구현하려고 했다. 하지만 기억을 더듬어 보니 예전에 URLComponent라는 것을 사용했던 것이 떠올랐고 이를 사용하여 쉽게 secret값을 추출할 수 있다는 것을 알게 되었다.
아직 큐알 값으로 셀을 추가하는 기능을 구현하지 않았기 때문에 우선은 확인한 키값을 그대로 더미 데이터에 넣어서 비밀 번호가 잘 생성되는지 확인해 보았다. 하지만 아쉽게도 Google Authenticator와 Twilio Authy가 생성해내는 비밀번호와 같지 않았다. 시간 차가 있어서 이정도 오차가 있을 수도 있지 않을까 생각했었지만 저 두 앱에서 생성된 비밀번호가 완전히 동일한 것을 보고 우리의 알고리즘이 잘못되었다고 확신할 수 있었다.
큐알 코드 스캐너 뷰가 나오기 전에 큐알 코드 가이드 뷰를 띄우기로 했었다. 드디어 swiftUI로는 처음으로 화면 전환을 구현하게 된 것이다. 이를 위해 MainView를 NavigationView로 감싸주었다. 그런데 다음과 같이 윗 부분에 빈 공간이 생겼다.
이것도 왜 그런지 이유를 잘 몰라서 padding, Spacer 등 이것저것 해보면서 공간을 없애보려고 했다. 그러다 문득 NavigationBar의 title 공간인가 의심되었다. 그래서 다음 코드를 추가해보았고, 문제는 해결되었다.
.navigationBarHidden(true)QRCodeGuideView의 디자인을 할 때 title을 화면 위에 작게 표시하기로 했다. 그런데 .navigationBarTitle("QR 코드")로 추가했을 때 기본적으로 LargeTitle로 표현되었다. 그래서 조금 더 검색해보니 .navigationBarTitle("QR 코드", displayMode: .inline)와 같은 코드로 속성을 변경할 수 있다는 것을 알게 되었다.
또한 이전에 LargeTitle로 표현된 것은, 기본 속성이 automatic이고 이는 부모의 속성을 그대로 받는 것이기 때문이다. 앞선 뷰에서 따로 지정을 해주지 않았었고 그 때의 디폴트 값이 LargeTitle이었기 때문에 QRCodeGuideView에서 아무 설정을 해주지 않았더니 LargeTitle로 표시된 것이다.
참고: The Complete Guide to NavigationView in SwiftUI
이전 화면으로 돌아가는 백버튼이 기본으로는 cancel로 표시 된다. 이를 원하는 형태로 변경하기 위해선 아래 참고 자료에서 설명한 대로 해주어야 한다. 우선 navigationBarBackButtonHidden로 기본 제공되는 백버튼을 안보이게 해주고, navigationBarItems로 우리가 사용할 버튼을 추가해주면 된다. 또한 아래와 같이 mode라는 변수를 사용하여 해당 버튼을 눌렀을 때 화면이 제대로 dismiss되도록 호출해 주어야 한다.
struct QRGuideView : View {
@Environment(\.presentationMode) var mode: Binding<PresentationMode>
var body: some View {
VStack {
...
}
.navigationBarBackButtonHidden(true)
.navigationBarItems(
leading: Button(action: {
mode.wrappedValue.dismiss()
}, label: {
Text("취소")
.foregroundColor(.black)
})
)
}
}참고: SwiftUI - Adding a custom back button to Navigation Bar
cell의 색을 지정하기 위해 다음과 같이 코드를 작성하였는데 xcode가 이를 인식하지 못하는 현상이 발생했다. 유추컨데, .(dot)이 너무 많이 찍혀있어서 일일히 들어가 탐색해야할 값이 늘어났고 또한 해당 코드가 파일의 맨 아래 쪽에 있다보니 메모리에 올라가는 코드량이 많아져서 컴파일러가 분석을 못하게 된 것 같다. 그래서 viewmodel안에서 color를 바로 가져오도록 해서 dot을 줄여주었더니 해결되었다.
큐알 코드를 스캔한 후, 바로 셀 추가 화면으로 이동되어야 한다. 하지만 이 부분은 아직 어떻게 구현해야 할지 잘 모르겠다.
- 엄청난 실수...
- 파생데이터 이슈
트래비스를 사용한 덕분에 충돌이 나는 코드를 그대로 머지할 뻔 한 것을 막을 수 있었다.
MainViewModel이 가지고 있는 Tokens 데이터가 앱 전체적으로 접근해야하는 상황이 많이 발생하게 되었다. 처음에는 여기까지 예측할 수 없어서 MainViewModel에 위치하게 되었는데, 그러다보니 다른 뷰모델에 이 값을 전달해주기 위해 많은 코드들이 추가되었고 객체간 의존성도 복잡하게 생겨버렸다. EnvironmentObject로 MainViewModel을 사용해볼까 했지만, 이것은 좋은 구조가 아니라고 판단되었다.
그래서 앱 전체에서 사용되는 상태값을 관리해주는 구조를 다시 설계해줄 필요가 생겼다. 이를 위해 마스터님이 알려주신 Composable Architecture나 이전에 적용하면 좋겠다 싶었던 Repository Architecture를 주말동안 찾아보고 적용해보기로 했다.
다음 개발일지에는 MVVM을 프로젝트에 녹인 과정을 작성해보아야겠다.
뷰를 extension해서 hideKeyboard()함수를 추가해주었다.
extension View {
func hideKeyboard() {
UIApplication.shared.sendAction(#selector(UIResponder.resignFirstResponder),
to: nil,
from: nil,
for: nil)
}
}Web은 3명이 작업하니까 풀리퀘가 막 쌓이고 머지할때 컨플릭나는 이슈가 흔히 발생한다. 하지만 iOS는 두 명이고, 머지할 때 같이 하고 작업 동기화하고 새로 시작하다보니 이런 컨플릭이 많이 없었는데, 우리도 두개 이상 풀리퀘가 발생할때는 어떻게 대처해야할까?
우리는 현재 이 방식을 따르고 있다.
- 재명님 어진님이 각자 브랜치에서 dev-iOS로 풀리퀘를 보내면 2개가 쌓인다.
- dev-iOS에 앞선 풀리퀘 하나를 머지한다.
- 만약 앞선 풀리퀘 후 컨플릭이 생겼다는 깃헙 경고가 뜨면 깃헙 내에서 컨플릭을 고친다.
- 또한 TravisCI로 다시 한 번 확인할 수 있겠다.
- 뒤이어 머지한다.
엄청 간단했다.
Master브랜치에서 License라는 제목으로 입력하면 오른쪽에 라이센스 템플릿 선택하는 버튼이 뜬다!
거기서 사용하고 싶은 라이센스를 택하고 커밋하면 끝!!
많은 종류의 라이센스가 있었지만, 우리는 MIT Licnese를 적용했다.
- 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스이다.
- 내 코드를 가져다 써도 돼. 하지만 썼다고 명시해줘
- 가장 느슨한 조건을 가진 라이선스 중 하나기 때문에 인기가 많다고 한다.
호호 우리프로젝트에도 이제 라이센스가 있지요
(솔직히 쓰기 - 현재 파트너 또는 누군가가 본다고 생각하지 말고 미래의 내가 본다고 생각하며 쓰면 어떨까요??😏)
- 코로나가 무지하게 심해졌다. 우리의 공간이던 스파크 플러스도 카페도 가지 못하게 됐다...ㅠㅠ
- 우리 앱 구조에 관해서 깊게 생각하지 못한채로 프로젝트에 들어간것이 이번 주 패착이었다. 주말동안 공부해서 다음주중으로 마구 파악한 후 적용해보아야겠다!!!! 잘 하고 싶다..!
- 사실 처음에 SwiftUI가 제약사항으로 주어졌을 때 큰 제약사항이라고 느끼지는 못했다. 아애 앱 만드는 것이 처음이 아니니 사용 방법만 검색해서 적용하면 될 것이라고 생각했던 것 같다. 하지만 뷰를 생성하는 방식이 너무나도 많이 달랐고 그래서인지 검색해서 적용하는 시간이 생각보다 훨씬 오래걸렸다. 그래도 한 주간 이것 저것 해보면서 swiftUI와 굉장히 많이 친해질 수 있었다.
- 구현에 급급하다 보니 앱의 구조나 꼭 챙겨야하는 알고리즘에 소홀했었다. 그 결과가 오늘 겪었던 문제들이었다. 다음 주에는 코어 시간에 최대한 구현에 집중하고 이후에는 TOTP 알고리즘, 세부적인 SwiftUI 기능 등을 학습하는 시간을 꼭 가져야겠다.