메인 화면 - 회원가입 화면 1 - 회원가입 화면 2 순서로 이루어진 회원가입 플로우를 구현해본다.
- 프로젝트 진행 기간: 2020.11.30 ~ 2020.12.04
- 팀 프로젝트: 꼬말, 오동나무
- 구현 키워드: Keyboard, Swift, UIImagePicker, UINavigationController, 화면 전환
- sign up 버튼으로
회원가입 화면 1로 이동 (modal) - UIImagePickerController로 앨범에서 이미지 선택할 수 있도록 구현
- 다음 버튼 활성화/비활성화 기능 구현
- Password와 CheckPassword가 일치하는 동시에 화면의 모든 항목이 채워져야 가입 버튼이 활성화된다.
- 가입 버튼을 누르면
회원가입 화면 2로 이동 (push)
메인 화면 -> 회원가입 화면 1로 넘어갈 때와 회원가입 화면 1 -> 회원가입 화면 2로 이동할 때 각각 어떤 화면전환을 해주어야할지 고민이 필요했습니다. 이에 대한 힌트는 H.I.G(Human Interface Guidelines) 문서에서 얻을 수 있었습니다.
화면 전환은 목적지에 따라 경로가 논리적이고 사용자의 경험을 토대로 예측 가능해야 합니다. 또한 여러 문맥(context)이 필요한 경우라면 modal 방식의 화면전환을 고려해볼 수 있습니다. 이를 토대로 아래와 같이 도식화를 하게 되었고 메인 화면 -> 회원가입 화면 1로 넘어갈 때는 modal, 회원가입 화면 1 -> 회원가입 화면 2로 이동할 때에는 push 방식으로 화면 전환을 하게 되었습니다.
modal과 push 화면전환을 결정하는 데에는 '정보의 연속성' 을 기준으로 삼을 수 있었습니다. 설정앱과 같은 테이블뷰를 이용할 때에는 보통 '타고타고 들어가는' 연속적인 정보를 제공하는 경우가 많고, modal로 화면이 나타나는 것은 연속적인 흐름과는 어느정도 무관한 새로운 문맥의 화면이 나타나는 경우가 많았습니다.
따라서 첫 번째 회원가입 화면은 새로운 문맥의 화면이라 판단하여 modal로, 두 번째 회원가입 화면은 첫번째 회원가입 흐름과 이어져야한다고 생각하여 push로 화면전환하도록 구현하였습니다.
기획된 회원가입 화면 1의 특성상 터치가 가능한 빈 화면이 매우 좁아서 빈화면을 터치하는 방법으로 키보드를 내리기엔 부적합해보였고, 또한 UITextView는 return, done 버튼 대신 enter 버튼이 필요하다고 판단하여 다른 방법을 찾아야 했고, 결과적으로 keyboard accessaryView에 버튼을 추가하는 방향으로 구현하게 되었습니다.
키보드를 아래로 내리는 동작을 구현하던 중 두 가지의 메서드를 알게 되었습니다.
textField를 터치하게 되면 textField는 firstResponder가 됩니다. firstResponder는 처음으로 이벤트를 받는 responder를 말합니다. 그리고 resignFirstResponder 메서드는 firstResponder를 사임하는 메서드인데, 메서드를 호출한 firstResponder는 더 이상 firstResponder가 아니게 됩니다. 그렇기 때문에 키보드를 내리게 되는 것입니다.
endEditing은 비슷한 메서드이지만 주체가 특정되지 않는다는 차이점이 있었습니다. firstResponder를 알지 못하더라도 수행이 가능한 메서드입니다. firstResponder를 특정할 수 있는 상황이라면 resignFirstResponder가 endEditing보다 효율적이라고 하는데, endEditing은 firstResponder를 모르는 상태이기 때문에 이를 찾고 resign 해주는 과정이 필요하기 때문입니다. endEditing과의 비교는 StackOverFlow를 참고하였습니다.
회원가입 절차가 2개의 화면을 거쳐서 이루어지기 때문에 두번째 회원가입 화면으로 넘어가더라도 첫 번째 회원가입 화면에서 작성했던 유저의 정보를 가지고 있어야 했습니다. 또 만약 두번째 회원가입 화면 -> 첫 번째 회원가입 화면으로 이동했을 경우에도 전에 입력한 유저의 정보를 가지고 있어야 가입 과정이 초기화되지 않을 수 있었습니다.
다수의 ViewController에서 접근할 수 있으면서 유저의 정보를 저장할 수 있는 방법에 대해 고민해보았고 그 결과 UserDefaults와 Singleton Pattern으로 구현이 가능할 것 같았습니다. 하지만 UserDefaults를 사용하면 항목별로 따로 정보를 관리해야하는 번거로움이 있었기에 객체 하나에서 정보를 관리하면서 메서드도 구현할 수 있는 Singleton Pattern을 선택하게 되었습니다.
- 화면 전환, 키보드 등 평소에는 당연하게 여기던 것들을 개발자의 입장에서 다루어보았습니다. 개발자는 사용자의 사용성, 편의성에 대해서 끊임없지 고민해야하고 배려할 수 있어야한다고 생각했습니다.
- 프로젝트 완성도가 높지않다는 점은 아쉽지만 H.I.G 문서와 공식문서를 적극적으로 활용하여 이유있는 코드를 작성해볼 수 있었습니다. 문서에서 찾지 못한 내용은 StackOverFlow에서 찾을 수 있었습니다. 하지만 정보를 찾아다니는게 쉽지만은 않았습니다. 정보 자체를 찾기 힘들 때가 있고, 사람마다 의견이 다른 정보들도 있었습니다. 개발자에게는 정보를 흡수하는 능력도 중요하지만 원하는 정보를 빠르게 찾아내는 능력도 중요한 것 같습니다.