[PhotiCase] 3주

 

9월 12일

• 홈 화면 달력에서 사진이 있는 날짜의 셀을 탭하면 그 날 저장한 기록을 리스트 형태로 볼 수 있도록 테이블뷰로 구현했다.
  • 업데이트 때 개선의 여지가 있다. 리스트나 갤러리 형식 중 하나의 방식을 택해 표시할 수 있도록 선택지를 만들어 두면 좋을 것이다.
  • 이 뷰에서 기록을 삭제할 수 있다. 이런 면에서는 기본으로 주어지는 TableView의 기능이 아주 쓸만하고 강력한 것 같다.
• 기록이 없는 날 역시 탭했을 때 새로운 뷰를 show 형식으로 보여줄 수 있도록 했다. 대신 기록을 보여주는 게 아니라 기록이 없다는 안내 레이블을 보여주도록 했다.
• 앱아이콘을 다시 변경했다. 원래 나는 약간 청녹색 비슷한 파랑색 계열의 색을 primary 색상으로 선택해서 사용하고 있었는데, 아무래도 빨강 계열이 더 좋지 않겠냐는 말을 듣고 핑크-빨강 계열의 아이콘으로 다시 디자인했다. 인정하고 싶진 않았지만 기대 이상으로 훨씬 좋아보였다. 앱아이콘을 변경함에 따라 primary 색상도 해당 색상으로 변경했다.
• 주요 기능을 전부 구현하는 고지까지 얼마 남지 않았다는 것이 느껴졌다. 첫 빌드 때 포함하지 않을 기능들을 주석 처리하고, 텍스트를 변경했다.
• 원래 추가 뷰의 datePicker의 maximumDate를 Today로 설정해서 이 시간 뒤의 기록을 하는 것을 허용하지 않았는데, 생각해보니 단순히 본 것만 기록하기보다는 앞으로 관극이나 관람 일정을 관리할 수 있으면 더 좋을 것 같아서 maximumDate 제한을 풀었다.
• 하루에 여러 개의 기록이 있을 경우, 달력에서 봤을 때 기록한 사진을 세로로 나눠서(등분해서) 여러 개를 볼 수 있도록 구성했다. 코드는 스택오버플로우를 참고했으며... 추후 업데이트에서는 3장 이상일 때는 세로뿐 아니라 가로로도 분할할 수 있도록 변경할 예정이다. 세로 등분은 딱 2개까지가 보기 좋은 것 같다.
• Realm에서 데이터 필터링을 하는 과정에 약간의 문제가 있었다. 특정 날짜의 0시에 등록한 기록이 그 전날 기록에도 포함되는 것이었는데, 필터하는 데서 시간을 조정해줌으로써 해결했다.
• 직접 추가 뷰에서 등록할 사진을 고르고 편집한 뒤 완성할 때, 사진 앨범 권한에 대해 묻는 모달이 나타났다. PHPhotoLibrary의 requestAuthorization 메소드 때문인 것 같았는데, 당장은 사진 앨범이 아니라 디바이스 도큐먼트에만 저장하기 때문에 그 부분은 제했다.

 

 

9월 13일

• 홈 탭의 달력에서 어떤 날짜를 선택했을 때, 기록이 있고 없고의 여부와 상관없이 기록을 새로 추가할 수 있는 버튼을 뷰에 추가했다. 검색해서 추가할 수 있는 버튼과 직접 정보를 입력해 추가할 수 있는 버튼이다. 
• 기록을 추가하기 위해 정보를 입력하는 뷰에서 텍스트 필드에 clearButtonMode를 .whileEditing으로 설정했음에도 입력 중에 x 버튼이 나타나지 않는 문제가 있었다. 왜 그럴까 고민했는데, 패딩을 추가해주는 부분에서 문제가 있었다.
  • 기본으로 주어지는 UITextField는 패딩이 따로 없어서(왜 그런지 모르겠다) 따로 패딩을 추가해야 하는데, 왼쪽과 오른쪽에 패딩을 주기 위해 textfield.leftView = paddingView, textfield.rightView = paddingView를 하고 ViewMode를 always로 해놓은 게 문제였다.
  • 원래 clearButtonMode를 했을 때 나타나는 x 버튼은 rightView 자리에 위치한다. 그런데 paddingView가 always를 하면서 자리를 차지하고 있으니 x 버튼이 나타나지 않았다.
  • rightViewMode를 unlessEditing으로 변경하고 테스트해보니, 수정할 때는 x 버튼이 나타나고, 포커스가 맞춰져 있지 않은 상태에서는 패딩이 예쁘게 잘 적용되어 나왔다.
• 추가 뷰에 지금까지 입력했던 정보들을 모두 삭제할 수 있는 버튼을 추가했다.
• 런치스크린을 변경했다. SFPro 이탤릭 볼드체를 사용하려고 했는데, SFPro 이탤릭 볼드체는 직접 추가를 해야 해서 결국엔 이미지 파일로 만들어야 했다. (런치스크린은 빌드 전에 나오는 것이기 때문에 빌드 후의 에셋인 커스텀 폰트를 사용할 수 없는 모양이었다)
• 영화 기록에 대한 상세 뷰를 구현했다.

 

 

9월 14일

• 완성한 기록을 수정할 수 있는 뷰도 만들었다. 이 뷰는 추가 뷰와 약간 다른 레이아웃을 적용했다. 당연히 여기서 기록을 수정하면 Realm의 데이터도 변경된다.
• Photos를 import하면, 사용자의 사진 앨범에서 사진을 불러오는 데에는 어떤 허가를 구하는 모달을 띄우지 않아도 된다. 하지만 사진 앨범에 사진을 저장하려면 그 때는 허가가 필요하다. NSPhotoLibraryAddUsageDescription을 Info.plist에 추가하고, 사진을 저장하는 부분에서 authorizationStatus를 검사해서 아직 허가 여부가 결정되지 않았다면 그 때 허가 여부를 묻는 모달을 띄운다.
  • 이걸 왜 알게 됐느냐? 포스터를 저장하거나 사용자가 직접 편집한 포토티켓의 사진을 도큐먼트가 아니라 앨범에 저장하고 싶을 때 권한을 받아야 저장이 가능하기 때문이다. 이 부분 처리를 했다.
  • 만약 권한이 제한됐거나 거부됐을 때라면 "설정"에서 직접 사용자가 권한을 허용할 수 있는데 그럴 것인지 묻고 그렇게 하겠다고 하면 설정으로 인도하도록 했다.

 

 

9월 15일

• 영화 상세 페이지에서 포스터를 탭하면 포스터의 고화질 원본이 모달로 올라오게 되어 있다. 그런데 고화질이다 보니 킹피셔에서 받아오는 시간이 좀 걸린다. 이 때, 사용자에게 사진을 받아오고 있다는 표시를 해주면 지금 어떤 상황인지 인지하는 데 도움을 줄 것 같아서 ActivityIndicator를 붙였다.
• API 키를 저장하는 plist를 만들어서 키를 따로 관리하기 시작했다. 진작 했어야 했는데 🤣
• 홈 씬의 파일들을 리팩토링했다. 주로 warning이 뜨는 줄을 잡아서 warning이 뜨지 않도록 var를 let으로 바꿔준다든가, 명확하지 않은 self가 무엇인지 정하는(lazy를 안 해서 생긴 문제가 많았다) 작업 등을 했다.
• 또 하나, 원래 .systemFont로 폰트 크기와 굵기 등을 설정했는데 이걸 .preferredFont로 바꿔서 설정했다. 이렇게 하면 텍스트 크기가 고정되지 않고, 사용자의 폰 텍스트 크기에 따라 텍스트 크기가 달리 보이는 접근성을 지원할 수 있게 된다.
  • accessibility 이상으로 올라가면 레이아웃이 깨지는 경우가 많은데, 이런 경우에는 레이아웃 자체를 달리 해야될 것 같은데 어떻게 해야될지가 고민이다.

 

 

9월 16일

• 검색, 추가, 티켓북 부분의 뷰 리팩토링도 했다.
  
  • (1) 중복되는 코드의 메소드 -> 재활용
  • (2) 쓰지 않는 변수 삭제
  • (3) 하드코딩된 숫자나 문자열들을 변수로 등록
  • (4) .systemFont -> .preferredFont로 변경
  • (5) TableView나 CollectionView에서 Cell, Item에 접근할 때 직접 프로퍼티에 접근하는 방식을 변경. public 메소드를 하나 선언하고, 변수는 private으로 감춤
  • (6) 좀 더 일관된 변수와 함수명
  • (7) 불변 변수를 let으로 변경
• 등이 대상이다.
• 사실 개발은 이 때쯤 거의 다 끝나긴 했는데, 몇 가지 테스트를 하다가 에러가 나는 부분을 발견했다.
  • 문제 상황은 이렇다. 기록에 대한 상세 뷰는 거의 모든 탭에서 접근이 가능하다. 그래서 내가 "홈" 탭에서 A 기록을 보고 있는데, "티켓북" 탭에서도 A 기록을 보고 있다가 돌연 삭제를 해버린다. 그런데 내가 다시 "홈" 탭으로 돌아가서 A 기록을 돌아가거나 하는 일이 생겨서는 안 될 것이다.
  • 처음 코드에는 이런 에러 상황을 생각하지 못해서 처리를 못 했는데, 뷰와 탭을 이동할 때마다 viewWillAppear에서 Realm에서 해당 데이터를 접근 가능한지 매번 검사해서 접근이 불가능하다면 삭제된 것으로 간주해 AlertController를 띄우고 뒤로 돌아갈 수 있도록 처리했다.
• 아무 기록이 없을 때 티켓북에 기록이 없음을 알리는 레이블을 추가했다.

 

 

9월 17일

• 기기별로 accessibility 텍스트 크기를 실험했다. 텍스트 크기 설정이 작을 때는 문제가 거의 없지만, 크기가 커졌을 때가 문제였다. 일부는 최고 크기에서 3단계 정도 줄인 것을 최대로 해야 하는 경우도 있었다(대표적인 예가 달력). 그렇지 않으면 레이아웃이 깨져버리기 때문이었다.