shcommit / learnmoreswiftinudemy

Hi, I'm Yang seunghyun

Me_

struct AboutMe {
  typealias Keywords = [String]
  let me😆 = ["senior in university", "ENTP", "study swift for developing iOS app"]
  
  func myMind👨🏻‍💻() -> Keywords {
    return ["Clean code", "Share my thoughts", "Technology that can make anything I imagine"]
  }
  func like🫠() -> Keywords {
    return ["Plan", "Develop", "iPhone"]
  }
}

Todo List_

extension AboutMe {
  func toDo📚() -> Keywords {
    return [
      "UIKit", "Swinject", "FireBase",
      "Algorithm", "ComputerScience",
      "LLDB", "GoF design pattern",
      "SwiftUI",
    ]
  }
}

knowledge_

extension AboutMe {
  func know🔥() -> Keywords {
    return [
      "Asynchronous. GCD, async/await, actor, Thread, Combine etc...",
      "Caching. disk cache, filemanager, NSCache etc...",
      "Networking. RESTFul, TCP/UDP Socket, Alamofire, URLSession", "URLSession protocols etc...",
      "Animation", "CoreAnimation", "UIKit", "Combine", "Unit Test", "AutoLayout", DIP+DI, "Protocol any, some, coposition..?"
      "Core data", "Firebase", "ImageIO",
      "MVC, MVVM, VIPER, Coordinator, MVVM+Clean Architecture etc...",
      "Computer science. OS, Algorithm, Data structure, Network etc...",
      "OOP", "POP", "SOLID etc...."
      "Kodeco code convention", "swift style guilde"
    ]
  }
}

extension AboutMe {
  func booksToStudy📖() -> Keywords {
    return [
      "오브젝트-위키북스",
      "켄트 벡의 구현 패턴-에이콘출판사",
      "CleanArchitecture"
    ]
  }
}

Baekjoon Tier_

Tech_

🚀  Strong Tools I Have Used and Learned

🚀  Knowledgable Tools I Have Used and Learned

My info_

learnmoreswiftinudemy's Issues

ଘ(੭ˊᵕˋ)੭* ੈ✩‧₊˚

[AutoLayout/CustomViewChallenge] Implemented Scene

[Clone/Instagram] Profile Scene 기능 개선, MVVM패턴 적용 | 색다른 시도 & 새롭게 알게 된 개념 & 개선해야 할 기능 #8

Profile Scene 기능 개선, MVVM패턴 적용

구현 영상

강의와 다른 색다른 시도

Navigation.title in ProfileVC

• 강의에서는 이미지 처리과정이 안나왔다. 그래서 여전히 제자리 걸음이었다. 이전 구현과 같이 여전히 ProfileVC로 이전했을 때 비동기 처리작업이 너무많아 navigation.title 도 업데이트 되지 않았다. 여기서 궁금했던 것이 커스텀 뷰를 navigation.titleView로 사용할 경우에 Scene가 진행중에 쉽게 값을 바꿀 수 있는데 기본적인 navigation.title의 reload하는 방법을 찾아 봤지만 알 수 없었다. 물론 답은 알고 있었다. profileVC가 로딩되기 이전에 미리 값을 주면 되는데 이게 싫었지만 방법을 몰라서 결국 앱의 초기 진입 화면의 컨트롤러에서 profileVC의 title에 들어갈 값을 미리 파이어베이스에서 받아왔다.

tabBar로 profileVC 초기 클릭시 FireStore, Storage에서 다운받은 사진, 사용자 정보가 2~3초 뒤에 나타나는 오류(링크 내용 중 개선해야할 기능의 gif에 해당)

• profileVC의 profileHeader에서 사용자의 이름, 프로필 사진이 필요한데 이는 Firebase의 Storage, Firestore에 저장되있었다. 이를 파싱하려면 파이어베이스 관련 함수를 꼭 써야 하는 것 같은데 진짜 느리다.. 프로필 사진 데이터가 정말 작을 텐데 채감상 23초 걸리다니 ㅠㅠ,,, 성공적으로 profieVC는 구현했지만 느린 파이어베이스 덕에 이를 해결하기 위해 고민을 많이 했다. 어떤 방법을 쓰고 비동기 처리, QoS 처리??(더 자세히 공부해야겠다.)등을 해도 느리다는 것을 깨닫았다.
  그래서 생각한 것이 그냥 초기 메인 홈뷰로 진입할 때 비동기 처리로 파이어베이스에서 프로필 사진과 사용자의 데이터를 비동기로 받아 버렸다. 초기에 메인 홈 뷰로 진입하는게 12초 딜레이가 있지만 흰색 배경이었다가 화면이 보여져서 자연스러웠고 profileVC로 이동시에도 비동기처리된 사진과 사용자 정보를 메인 홈 탭컨트롤러로부터 nil이 아닌 바인딩(didSet)된 실제 값을 통해 정보를 화면에 보여줌으로 이전보다 정말 빨라보였다,, 호호호

MVVM패턴 적용

• 이미지 처리에 대해 고민을 너무해서 MVVM패턴을 잊고 있었지만 HomeVC, ProfileVC등에 ViewModel을 통해 View들을 수정하도록 적용했다. 이때 HomeVC, ProfileVC에서 사용될 수 있도록 ViewModel을 선언했다. 둘 중 하나는 image 프로퍼티를 안쓰는데 그냥 nil처리하면 됬다.

• 완벽하진 않다. 아직 Controller의 의존성을 갖고 있다.. 옵저버등 공부해서 완벽하게 VM과 View의 동작을 만들어보고 싶다.

새로 알게 된 개념

• Firestore.firestore() 수식어가 길어서 사용자의 정보를 파이어베이스에서 fetch 할 때 새로운 프로퍼티로 참조해서 사용했었다. 이와 달리 Firestore.firestore(), Auth.auth(), Storage.storage() 등을 전역변수의 constant 변수로 하는 파일을 새로 구현했다는게 신선했다. 원래 C++에서는 자주 사용하고 선언 했었지만 swift에서는 전역 constant변수를 많이 선언하지 않았는데 이 기회를 토대로 많이 사용해야 겠다. 바로 리펙터링 했다.

탭바 컨트롤러에서 특정 VC 인스턴스 얻는 방법

tabBarController의 특정 VC 인스턴스는 tabBarController as? 특정VC클래스로 캐스팅한 인스턴스로 얻을 수 있다.

델리게이트 패턴에 관해 ***

내가 생각했던 델리게이트는 특정 a VC에서 다른 b VC로 1대1 관계로 생각했었는데 c VC에서 b vc로 호출할 때 a vc의 인스턴스를 넣어줌으로 델리게이트를 구현할 수 있다는 사실을 새롭게 알게 되었다.

잘못 git add한 staged에 있는 파일을 다시 Unstage로 변경하는 명령어

• git reset HEAD [file] 명령어를 통해 git add를 취소할 수 있다.

개선해야 할 기능

• 회원가입 실패 시 버퍼링 끊기

• 뒤늦게 확인했는데 ProfileVC진입시에 파이어베이스에서 받은 데이터를 홈뷰 진입시점으로 바꿨는데 로그인 -> 홈뷰로 갈 때 2초의 빈 상태가 있는데 다시 수정해야 한다.

• ProfileController에서 grid, list bookmark 버튼이있는데 이를 stackview+pageViewController로 추가 구현해보기

• 사용자 로그아웃 후 로그인 하고 프로필 VC들어가면 이전 사용자 기록이 있다. (왜이러지,, currentUser의 uid로 초기화 항상 되는데,, 다시 수정 해야한다.)

공부해야 할 것

• super.init(collectionVIewLayotu:) 시점에 UICollectionViewFlowLayout() 과 UICollectionViewLayout() 차이
• QoS처리

느낀점

• 저번 ProfileHeader 기능 구현할 때 Firestore과 storage를 통해 최근 로그인된 사용자 정보와 이미지 불러와 ProfireHeader의 정보를 구현하도록 혼자 짜봤는데 이번 강의에도 파이어베이스에서 데이터들로 ProfileHeader를 갱신하는 강의가 있었다.

[Clone/Instagram] 데이터 파싱 기능 개선, Feed 게시물 구현 | 새롭게 알게 된 개념 & 느낀점 #11

구현영상

• 이번에는 앱의 전반적인 중복 함수 제거, async 처리 가 주를 이뤘다. 추가로 UplaodPostController에서 사용자가 게시글을 작성할 경우 FeedVC에서 글을 보여주도록 구현했다.

강의와 다르게 구현한 기능

• Async/Await. Concurrency

Concurrency 처리는 현재 앱의 특성상 적용할게 없는 것 같다. 추후에 Feed VC 게시물이나 SearchController의 모든 사용자 프로필에 대해서 부분적으로 적용할 수 있으면 해볼 계획이다.

계속해서 파이어베이스의 데이터를 다운받고 이미지도 다운받는 작업이 어떻게하면 효율적으로 개선될 수 있을지 고민하고 있었다. @escaping 을 통해 비동기적으로 받은 파이어베이스 함수들의 completionHandler의 값을 또 @escaping completion으로 처리를 하고 있다.

근데 상황에 따라서 사용자의 uid를 얻고 그 후에 또 사용자의 이름, 닉네임 등의 정보를 얻기 위해 중첩으로 클로저 안에 클로저를 사용하고 그 값을 또 받는 곳애서 클로저로 사용하는 등 연달아 클로저를 호출 했었는데 컴파일러의 오류 메세지가 떴다 "너무 클로저를 남발하지 마세요..." ( 너무 completion에 의존한것 같기도 하고..)

함수가 종료된 후에도 메모리에 지워지지 않고 저장되어 있다가 호출 된 후에야 없어지는?(강력 순환 참조 발생시 안 사라질 수도?) @escaping 클로저를 계속해서 사용하는 것은 너무 쉬웠다. 그런데 약간씩 코드가 꼬이는 것을 볼 수 있었다.

이미지도 나름대로 백그라운드에서 다운받고 메인 스레드로 호출을 했는데

이런 에러가 계속 발생했다. (아흑 운영체제 때 배웠던 세마포어가 여기서도 사용 되는구나,,)

이참에 클론을 잠시 멈추고 앱의 성능을 향상 시키기 위해, 새로운 기능을 적용하기 위해 Async, Await 그리고 thread에 대해서 공부를 했다.

지금 일부 API호출을 async, await를 적용했는데 성공했다.+_+ (30분짜리 강의를 시청하는데 5시간이 걸린 결과인가..,....) 거의 절반 가량의 데이터 파싱 함수들을 Async, Await로 구현했다.

• try catch구문을 사용했다.

• 텍스트 필드 클래스를 만들어서 간단하게 델리게이트 구현후 count에 따라 현재 몇 글자인지 갱신하는 것과 일정 크기를 넘지 않도록 구현 했다. 근데 알고보니 textViewDelegate에도 텍스트 체인지 델리게이트가 있었는데 난 새로 구현해버렸다.

• 코드를 리펙터링할 때 Clean Code의 느낌을 살려서 코드화 해봤다.
  

추가로 공부한 것

• 에러처리 EmilY님 링크

• 에러 처리 공식 문서 링크

• Async/await WWDC 2021 링크 (외국 영상이라 그런지 모조리 쓰면서.. 영상에 나오는 개발자분의 말 하나하나 쓰고 정리하면서 공부를 했는데 30분짜리 영상을 5시간이나 공부했다;;; )

• task WWDC 2021 링크

• @escaping 개념 공부와 정리

---

새로 알게 된 개념

• 지금 async. await을 거의 적용해간다. 열심히 떱떱디시에서 공부했다.
  그리고 적용하려고 하는데 예외처리 추가로 예외처리에 대해 공부했다.

• selectedIndex

이 인덱스 값을 입력하면 해당 vc로 이동한다.

• tabBarControllerDelegate의
  tabBarController(_:shouldSelect:)

현재 VC의 델리게이트 등록하고
이를 통해 특정 탭바 버튼으로 vc가 로드되기 전에 tabBarController(:shouldSelect:) 메소드가 실행된다. 오잉?? 해당 컨트롤러의 viewWillAppear(:) 와 다른점은 무엇이지??

• 인디케이터의 start, end 함수는 extension에서 구현했는데 프로퍼티는 선언이 안 되서 못 만드는 줄 알았는데 static 변수는 선언이 가능하다는 것을 알게 되었다.

• 텍스트의 일정 크기가 넘을 경우

deleteBackward() 함수를 사용하자.

func checkMaxLine(_ textView: UITextView, maxLength: Int) {
   if textView.text.count > maxLength {
   	textView.deleteBackward()
   }
}

궁금한 것

- 지금 궁금한 것은 특정 프레임워크 함수가 에러를 발생할 수 있는데 이 에러를 정확하게 enum으로 정의해서 특정 case로 catch할 수 있도록 할 수 있을지가 궁금하다..

그러니까 내가 정의하거나 gaurd else구문을 통해서 내가 던진 에러는 처리할 수 있는데 프레임워크 함수에서 던져지는,, 데이터 파싱하다가 실패했을 때 발생되는 error는 어떻게 내 커스텀 enum : Error에서 받아서 처리해주는지 궁금하다.

음 임시적으로 떠오른 방법은 try? gaurd를 사용해서 throw해버리는거

이게 맞는지는 모르겠다. 하지만 내 생각으로 try?처리를한 후에 다음 함수가 에러가 있을 경우 nil을 반환한다면? 그걸 guard로 바인딩해서 바인딩 실패되면 throw 처리해주는 방법이다. -> 맞는 것 같다. try? 처리의 경우 옵셔널 타입의 value or nil을 반환하는데 nil일 경우 특정 함수가 throw로 에러를 던진 것이다. 아닐수도... 더 좋은 방법을 계속해서 찾을 것이다.

개선해야 할 것

• 인디케이터 static으로 선언하고 각각의 vc로 선언된 인디케이터 변수 없애기.

• searchList의 이미지 처리를 cache로 활용하기 (필수..)

• 몇몇개의 source 코드 보면 controller에 helper가 있는데 VM으로 분리 시켜야한다. 추후에

• 11월 14~ 20일까지 약 일주일동안 컴바인과 task, Actor에 대해 공부해서 로직을 업데이트할 것이다. 컴바인으로 완벽하게 Controller로부터 분리를 시킬 예정이다.. 헤헿

[Clone/Instagram] 팔로우, 언팔 기능 추가. 이미지 처리 개선 | 새롭게 알게 된 개념 & 느낀점 #10

새롭게 알게 된 개념

• UISearchController

검색을 하면 특정 단어만 tableView cell에 나오도록 하는 방법.

UISearchResultsUpdating 프로토콜을 채택해서 updateSearchResults(for:)
메서드로 사용자가 검색을 할 때마다 매개변수.searchBar.text를 통해 받아지는 바인딩 된 사용자의 검색 단어를 얻어서 db의 특정 키워드에서 항목들을 찾아낸다.

그 예로 검색 창에서 타 사용자의 아이디를 찾고 싶은 경우 filter 메서드를 사용한다. 조건에 맞는 원하는 특정 index만 [Element]로 반환하는게 filter함수이다. 그렇게 특정 데이터만 반환된 리스트를 따로 프로퍼티에 저장해서 TableView cell을 특정 조건에 맞게 갱신하면 된다. filter에 의해 searchBar의 바인딩 된 값은 곧 사용자가 검색을 했음을 의미함으로 바인딩 될 때마다 tableView.reloadData()를 통해서 tableView의 numberOfRowsInSection, cellForRowAt를 구현하면 된다.

• 사용자끼리의 팔로우 관계는 어떻게 생성될지에 대해서 많이 궁금했다.

한 휴대폰에서 A가 로그인 했다면 나를 제외한 다른 사람들한테 팔로우를 걸 수 있다. 이때 팔로우를 눌렀을 때 그 사용자에 대한 db의 특정 위치에 값을 증가시키면 된다. 여기서는 맨 처음에 회원가입을 할 때 이메일과 비밀번호를 통해 유일한 사요자 구별 키 값인 uid를 받는데 이를 활용해서 사용자의 인적사항을 포함한 도큐먼트를 uid로 저장하고 팔로우나 언팔도 각각의 uid에 대해서 몇명의 사용자가 팔로우 했는지 uid를 통해 저장, 중복처리를 하면 된다.

누군가를 팔로우 할 때는 followers. following 둘 다 업데이트 해야한다.

앱을 사용중인 현재 사용자가 누군가를 팔로우 한다면 팔로우 당한 타 사용자의 식별 아이디가 필요하다. 그 해당 식별자의 팔로워 수를 증가시키려고 등록해야 하기 때문이다. 그렇다면 내가 팔로우 버튼을 눌렀을 때는 내가 팔로우 중인 db에 타 사용자를 추가해야 하고 타 사용자의 팔로워 숫자에 내 계정을 등록시켜야 한다. 여게서 타 사용자의 모든 정보를 등록해야 할 까? x 최소한으로 식별 가능한 ex) uid와 같은 정보만 등록하면 된다.

느낀점

• 클린 코드를 읽은 후에 중복되는 코드가 없에 최소한, 효율적인 코드를 구성하고 싶어서 ViewModel이 다른 controller에서 실행되는데 성능이 거~의 같아서 컨트롤러는 다르지만 VM을 같은 것을 사용했는데 기능을 추가하다보니 점점 두 컨트롤러의 VM차이가 나서 결국 따로 분리하게 됬다. 따라서 일단 따로 분리하고 다 구현했을 때 같은 거를 묶는 식으로 개발을 해야 할 것 같다는 생각을 했다.

• 강의에서 파이어베이스의 Storge에서 이미지를 다운 받아올 때 SDWebImage 오픈 라이브러리를 사용한다. 이 라이브러리의 함수를 쓰면 이미지를 받아와 ImaeView에 저장하고 비동기 처리와 동시에 캐싱 처리까지 되는 것 같다. 근데 실력향상할겸 그냥 내가 스스로 비동기 처리를 했는데 이미지 한개 받을 때는 그냥 불러오면 됬었다. 근데 여러개의 이미지가 있는 cell을 구현할 때는 dequeue관련 함수를 통해서 cell을 불러오는데 이미지를 다시 불러올 때 상당히 느렸다. 그래서 찾아본 결과 NSCache를 공부해야 할 것 같다. 그렇지 않으면 테이블 뷰를 예로들 때 위에 스코롤 하면 이미 있던 이전 이미지가 나온 후에 스크롤이 끝나고 해당 cell의 이미지로 로드된다. 일단 임시로 이미지가 이전 이상한 이미지에서 현재cell의 이미지로 로딩되는 것보단 흰색 -> 이미지로드로 바꾸었다. 추후에 바로 NSCache등을 통해서 효율적으로 이미지 처리를 해봐야겠다.

//좌 이전 이미지 , 우 임시로 개선한 이미지

마주한 에러

• Auth.auth().currentUser 값이 동기적으로 갱신되지 않는 에러

Auth.auth().currentUser를 통해서 현재 핸드폰에 로그인 한 사용자의 정보를 토대로 팔로우, 언팔, 정보등을 기록하고 업데이트 한다. 지금 현재 사용자가 로그아웃 후 다른 계정으로 로그인 했을 때는 즉각적으로 Auth.auth().currentUser의 값이 Auth.auth().signIn(withEmail:password:)를 통해 synchronous하게 갱신되야 한다. 하지만 실제로 그렇지 않았다. (참고 글) 음.. Auth.auth().currentUser에 상당히 의존적이었다. 프로필 상세정보, 이 정보를 토대로 다른 사용자의 팔로우 언팔 등을 다 Auth.auth().currentUser의 특정 값을 통해서 파싱 받고 처리했는데.... 앱을 완전히 종료 후 재 시작해야 비로소 이 값이 최신 상태로 바뀌기 때문에 다른 대안이 필요했다.

// AUTH.updateCurrentUser(user:) 이 함수도 적용x

영구 저장소를 사용해서 현재 로그인 중인 사용자의 정보를 파싱받을 수 있는 키 값만 따로 저장하고 현재 정보를 파싱받는 관련 함수을 전부 고치니 정상적으로 현재 사용자의 정보가 즉각 갱신됬다.

// currentUser대신 영구저장소에 로그인된 사용자의 정보를 등록하고 이를 토대로 currentUser 정보를 fetch한 이후에 Auth.auth().currentUser의 단점을 보완할 수 있었다. 아래 영상은 정상적으로 팔로우, 언팔이 되는 영상이다.

구현하면 서 어려운 점

• 지금까지 제일 까다로운 것은 다량의 이미지 처리를 효율적으로 사용하도록 구현하는 방법이 제일 어렵고 지금도 고민중이다.

• 파이어베이스에서 이미지 다운을 너무해서 할당량을 초과했었는데 음? 몇번 하지도 않은것 같은데 할당량을 초과해서 기능을 이미지 파싱이 잘 됬는지, 타 VC에서 이미지 로드가 잘 됬는지.. 중복된 코드, 중복 파싱 하려는 코드를 없애는데 할당량 초과가 되버리니까 확인을 못해 답답했다. 파베 쓸 때 이점 조심해야겠다.

색다른 시도

• 검색창에서 특정 cell을 터치할 때 이전에 저장된 dequeue의 cell의 정보를 토대로 사용자의 디테일한 정보를 보여 줬다.

• 추후에 또 개선할 건데.. 일단 임시적으로 정확한 정보를 보여주기 위해 재사용큐에서 꺼내올 때 흰색으로 구현했다.

• Auth.auth().currentUser가 꼭 앱을 종료했다 다시 실행해야 바뀌기에 영구 저장소를 활용했다.

[Clone/Instagram] Notification 기능 개발 느낀점, 고민거리, Coordinator 패턴 적용 #15

목표: 누군가 피드에서 팔로우나 커맨트, 좋아요 했을 때
Notificaiton Controller에서 알림을 뜨게 하는 것!

특정 사용자에게 알림을 업로드 해야한다.

A 계정으로 로그인 했을 때 B의 포스트에 하트 누르면 B의 notificaiton을 해서 알림 목록 리스트에 추가 해야한다.

B는 앱을 열고 알림창을 살펴봤을 때 A의 알림이 있어야 한다.

1. 특정 사용자에게 알림 타입을 업로드 해야한다.

• 코디네이터 적용!

구현 영상

추가적으로,, 서버에 올릴 때 Timestamp에 seconds로 저장했는데 다시 시 분 초로 바꿔서 시간을 업데이트 해야한다.

그리고 사용자가 앱을 나가있을 때도 알림을 fcm푸시를 구현해봐야겠다.

새로 알게 된 개념

• 인디케이터

단순히 호출만하는게 아니라 인디케이터 뷰가 나타나면 실행중인 동안에는 다른 뷰들의 상호작용을 차단해야 좋다.

그래서 인디케이터 시작 할 때 view.isUserInteractionEnalbled = false

-> 인디케이터 끝 시 view.isUserInteractionEnabled = true 로 대처했다.

• tableView.separatorStyle

separator는 cell 과 cell사이의 선을 말함. separator inset 는 leadingAnchor에 대한 여백

• 프로필 받는 string의 주소가 있다.

Data(contentsOf:)보다 URLSession와 같은 async network api를 사용하라고 한다.

URLSession.shared.dataTask(with: url) { (data, response, err)
...
}.resume()

마주한 오류

modern concurrency + combine을 사용할 때 주의사항..

ViewController의 state에 따른 Input을 ViewModel의 transform(_:)-> Output으로 로직 처리 후 다시 뷰 컨트롤러으 State를 업데이트 할 수 있도록 갱신해 주는 코드에서 refresh라는 이벤트가 발생되면 vm의 input으로 들어간다. 그리고 로직을 처리한다.

이때 기존 저장된 posts 배열에 담겨있는 포스트 정보를 모두 삭제한다. 그리고 fetchPosts를 통해 새로 갱신된 포스트 정보들을 받아온다. 그 후 .reloadData로 반환한다.

얼핏 보면 정상적인 코드 같지만... fetchPosts를 보면

Task를 통해 async함수인 apiClient.postCase.fetchPosts()를 비동기적으로 다운받는다. fetchPosts() 함수는 종료된다. 그리고 .reloadData state로 반환되어 ViewController의 State에서 데이터를 리 로드하라고 곧바로 전달한다. 하지만 async 함수는 await를 통해 여러번 실행, 중지 작업을 통해 포스트를 받아옴으로 새로 데이터를 갱신하기 위해 테이블 뷰.reloadData를 실행해도 async apiClient.postCase.fetchPosts()는 실행이 완료되지 않는다. 이 점을 조심해야 한다.

바인딩 중첩.

cell안에서 바인딩을 할 경우 바인딩이 중첩된다. prepareforReuse를 통해
재사용 큐에 저장했다가 특정 cell이 화면에 노출된다면 다시 꺼내 쓰는데 꺼낼때마다 바인딩 된다.

81e029b10819107)

그럼

NotificationCellViewModel의 transform(with:)가 재사용으로 꺼내질 때마다 바인딩이 되서 누적 바인드 된 만큼의 같은 value를 emit한다.

그래서 cell의 경우 prepareForReuse()에서 subscription들을 전부 cancel한 후에 다시 바인딩을 해주었다.

subscriptions을 holding한다고 해도 dismiss가 되는 경우가 아니면 중첩해서 쌓일 수 있어서 임의적으로 cancel과 재 할당 등을 통해 관리하는게 중요하단느 것을 알게 되었다.

최소한으로 바인딩 되는 경로를 줄였음에도 그래도 두 번씩 실행이 된다. 중복 호출해주는 구간이 없어서 그런데 이전에 있던 cell의 위치와 재사용큐에서 바로 꺼내오기 때문에 transform(with:)가 두 번 호출되는지 모르겠다. 정말 최소한의 호출인 것 같다. 여기서 operator를 사용하 단 한번만 사용하기로 했다. 나중에 문제 발생시 first()를 삭제해야겠다.

---

• TableView cell's UIImageView, UIButton object action event 실행 안되는 이유

https://dev-with-precious-dreams.tistory.com/168

---

passthroughSubject를 통해 delegate를 만들었는데 한번의 action event임에도 불구하고 두개씩 published되는 이유 NotificationController.swift 관련

결론적으로 두 번 send -> sink된 것이기 때문이다...

저번에도 한번 컴바인으로 delegate 쓸 때 호출 가능한 경우를 최소한으로 줄였는데도 불구하고 두 번씩 호출 됐다. 계속해서 건드려봐도 안되서 어쩔 수 없이 first() operator를 사용해서 넘겼는데 이번에도 또 같은 상황이 발생됬다. 고치기 위해 안간힘을 썼는데도 계속 두 개씩 호출됬다.

상황 // Date: 1.13

1. cell의 object 터치 -> addTarget 메소드 한번 호출. 여기서 send로 currentValueSubject에게 데이터 전달하는데 두 번 전달하게 된다.

일단 cell안에 버튼과 프로필 이미지 뷰, 포스트 이미지 뷰 세 개가 있고 그 중 두 개의 액션 메서드다.

중요한 건 버튼, 프로필 이미지 한 번 클릭하면 분명 액션 메서드는 한번 동작한다. 그런데 subject의 sink를 두 번 받는다. 확인해본 결과 send를 두 번 한다. 바인딩이 두 번 됬다는 경우다.

이건 delegate를 받는쪽

cell에도 vm을 정의했다. 추후 Advanced architecure로 VM의 예를 정확히 봐야겠다.. ( Cell 또한 view인데 viewModel을 사용해도 괜찮은지.. 궁금하다)

원인을 찾지 못해 iOS개발 단톡방에 도움을 요청했는데 다행히 한분이 답해 주셨다.. "재사용 큐에서 꺼냈을때도 subscriptions 초기화를 했는지??!!?"

물론 했었다... 그럼에도 두 번씩 호출됬다. 결론적으로 어쨌든 두번씩 sink를 한 것은 바인딩을 두 번 했다는 의미로 결론을 내렸다. cell<-> cellVM , ViewController<->vm 코드 여기저기서 subscriptions를 유지하느라 바쁘다...

NotificationsController에도 vm과의 바인딩, NotificationCell 도 cellVM과의 바인딩, 게다가 cell과 notificationController의 델리게이트 간 바인딩 즉 subscriptions가 두 개 정도 있었는데 이중에서 delegate바인딩에 관한 subscriptions를 notificationController의 subscriptions 변수에서 찾기 힘들었다. 왜냐하면 Set으로 저장했기 때문이다.

상황 설명을 글로 남기기 애매한데 결과적으로 내가 잘못한 점은 단톡방에서 개발자 분이 해준 말이 맞다. 재사용큐에서 꺼내올 때 cell의 cellVM은 초기화를 했지만 NotificationController의 subscriptions는 초기화를 하지 않았다. 결론적으로 재사용 큐에서 꺼낼 때 초기화를 완전히 하지 못한 것이 된다.(cell의 subscriptions는 초기화 했었는데 델리게이트 관련 subscription을 NotificationCeneter에서 해주지 못한 내 잘못..ㅠ)

재사용큐 -> setupNotificationCellDelegate(_:)는 매번 sink를 통해 바인딩 되는데 이때 subscriptions를 초기화 해주지 않은 것이다.

바인딩을 이곳 저곳에서 하다 보니까 prepare를 통해 cell은 진작에 subscriptions 초기화 했지만 delegate관련은 해주지 못했던 것이다. ㅋㅋ,, 근데 심지어 cancellables는 Set에 저장시켜서 delegate관련 publihser의 cancellable는 찾기 힘들었다.

그래서 대안책으로 프로퍼티 하나 추가했다. 그리고 변수 명을 분명하게 했다. 그렇지 않으면 죄다 subsciriptions여서 정말 했갈린다. 좋은 경험을 한 것 같다.

그리고 재사용큐에서 setupNotificationCellDelegate함수가 호출될 때마다 delegateSubscription을 새로운 send로부터 holding하는 것으로 바꿔서 새로 delegate가 호출되면 다시 delegateSubscription이 새로운 거로 덮어지도록 함으로 에러를 고쳤다.

그리고 다시 화면 나타날때, reloadTableView로 테이블 뷰 데이터들 다시 갱신될 때도 해주었다 거의 모든 상황에 대비를 했다고 할 수 있다!! 후..

고민거리..

초기화 관련..

클로는 capture 성격이다. 특히 lazy var 를 남용할 경우 좋지 않지만 viewController시점에선 view가 load되기 이전에 addTarget을 통해 메서드를 등록할 경우 해당 메서드가 적용이 안되서 lazy var 키워들르 사용한다.

반면 함수는 호출 되어야 사용된다. 그리고 종료시점이 분명하다(async를 쓰지않는한)

좀 더 연구해봐야한다.

swift 공식문서에는 클로저로 변수 초기화가 없다. 다 선언 후 init메서드 안에서 초기화를 한다. 하지만 유명한 책에서도 클로저를 통해 초기화를 사용한다.

• let or lazy var 관련 스택 오버플로우 링크

원래의 경우 클래스의 상단부에 변수 선언 + 초기화, init메서드 안 초기화. 클래스 상단부에 선언하자마자 바로 함수를 사용해서 초기화를 함으로 클래스 상단부를 간략하게 해서 변수들을 보기 쉽게 하려고 했다.그런데 함수를 통해 init() 메서드가 시작이 안된, 초기화가 되지 않은 변수를 초기화 하기 위해서는 조건이 있다.

전역 함수인가? or 해당 클래스 내부의 함수인가? 이때 해당 클래스 내부의 함수인 경우 init()메서드를 통해 클래스가 초기화 되기 이전 이라면 클래스 내 구현했던 함수들은 사용하지 못한다.(클래스가 초기화 되지 않았기 때문,.,.)

왜?

A 클래스 내부의 변수들을 초기화 하기 위해 A 클래스 내부에 특정 프로퍼티에 대한 초기화 함수를 구현했지만 이 초기화 전용 함수들은 A 객체가 메모리에 할당 되어야만 사용할 수 있기 때문이다.

그래서 난 static 키워드를 통해서 함수를 선언했다. Static을 사용한다면 A 프로퍼티의 초기화가 없어도 사용할 수있기 때문이다. Static키워드를 사용하면 object's 메모리에 곧바로 할당되고 A 인스턴스 없이도 바로 이용할 수 있게 만들어주기 때문이다.

Static 키워드는 네트워크 파싱에 필요한 함수 등을 클래스 안에 구조화 해서 선언할 때 인스턴스를 생성하지 않고도 바로 사용할 수있도록 Static 키워드를 선언해서 사용했다. (Like singleton pattren) ? 연속적으로 인스턴스를 생성하게 되면 그만 큼 같은 프로퍼티, 함수들이 메모리에 쌓이는데 static을 사용하면 인스턴스를 생성하지 않고 static으로 지정된 함수들만 메모리에 allocate되기에 메모리 릭을 줄일 수있지 않을까..생각한다.

그때문에 이렇게 사용했다. ) 위 그림에서 변수들을 초기화하기 위해 선언된 initProfileImageView()... 등의 함수들 또한 static으로 구현됬다. 이 이미지 뷰, username, fullname label등을 갖는 UIView를 여러개 선언한다고 가정할 때 static 키워드로 함수를 만들면 (어차피 초기화 때 한번 쓰이는 함수들,,) 메모리에 연속적으로 함수까지 allocate되지 않고 단 한번 할당되기 때문이다.

클로저를 통해 변수를 초기화 할 때는 선언한 { } 형태의 클로저를 "( )"를 통해 클로저 실행 시켜야한다. 그리고 init()메서드가 실행되기 이전 return을 통해 특정 타입의 object를 정하는 클로저와 ()는 init메서드가 호출되기 전 시점에 실행되는 것이다. 근데 클로저는 일급 객체 함수이다. 어떤 개체와도 상호작용이 가능하다. return을 통해 반환된 값의 타입 추론을 통해 변수를 초기화 한다.

클로저는 특정 범위 내 변수를 바인딩하기 위해 사용할 수 있고 capture의 특징이 있다. 하지만 캡쳐는 외부의 변수에 값을 사용할 때만 캡쳐를 한다. ARC 는 reference type일 때 작동하는데 중요한 것은 클로저는 reference type이다.

일급 객체를 지원하는 Swift 스타일이 클래스 내 변수 초기화 시점에도 선호할까? 초기화 공식문서에는 클로저를 통해 초기화를 하는 구문이 없다.. .... 내 스타일은 변수들을 확인하고 관련 로직을 구현하기 위해 변수들을 한 눈에 보기 쉽게 해야한다. 그렇기에 클로저를 통한 초기화를 할 땐 클로저의 내부에 특정 프로퍼티를 초기화 하기 위한 기능들이 길게 늘어질 수 있단점이고 프로퍼티를 알기 상대적으로 어려울 수 있다. 이 부분만 따로 뺀다면 들쑥 날쑥해질 것이다. 그럼에도 선언과 동시에 초기화를 하는 클로저는 매력적이다.

그런데 내가 했던 static을 쓰는 방법은 좋은 방법일까 생각을 해봤다. 일단 다른 클래스에도 같은 이름을 사용한 static 클래스가 있다면? 물론 해당 static 함수가 이름이 같아도 클래스 안이기 때문에 식별이 가능하다. 하지만 특정 클래스를 사용하지 않아도 static func 가 메모리에 할당되기 때문에 좋지 않다고 판단했고 혼란스러웠다... 물론 static의 장점은 그럼에도 한번 메모리에 로드 된 이상 해당 클래스를 4개 만든다고 했을때도 static type은 중첩으로 메모리에 할당되지 않는다는 점이다.

그래도 계속해서 찾아봤는데 좋은 방안을 쉽게 찾을 수 없었다,, 계속해서 찾아보다가 클로저를 통한 lazy var는 thread unsafety하다는 것을 알게 되었다. 그럼에도 UIButton을 초기화 할 때 클로저를 통한 초기화를 하게 된다면, init()메서드 이전에 초기화를 한다는 말이다. 아직 self 키워드를 사용할 수 없다. init() 호출 시점 전 이니까,, 그렇다는 것은 func, @objc action method도 사용이 당연히 불가능하다. 그럼 클로저를 통한 변수 선언과 초기화 구문에서 클로저 안에 버튼에 addTarget을 통해 클래스 내에 있는 액션 메소드를 지정하면 init()시점이 아니기에 메모리에 클래스의 func, @objc func 가 할당되지 않았음으로 액션메소드가 등록되지 않아 lazy를 선언함으로 init()이후에 @objc func를 addTarget으로 등록하면서 초기화를 한다.

이런 lazy를 쓰면 좋지 않다니?! 그래서 계속해서 찾아보았다. ㅠ;
스토리보드 사용할 때 UI object를 클래스에 드래그하면 아울렛 변수가 선언되는데 강제 옵셔널 타입이다. weak var가 아닌 이상,, 그리고 어떤 글을 봤는데 UIViewController에서 사용되는 UI프로퍼티들은 거의 사용된다. 그래서 "!"를 쓰는데 이는 init()이후에 초기화가 됨으로 lazy를 쓰지 않아도 위와같은 lazy var 클로저 구문 or 함수를 사용하지 않아도 된다고 한다. 그래서 일단 요 방식으로 선택했다.

변수들을 바로 확인 할 수있어 좋다.
init메서드 안에서 함수를 통해 깔끔하게 초기화 할 수 있따.

일단 let, var, 클로저, ARC, retain 등 초기화에 관한 공부를 더 한 후 정리 해야겠다...

---

lazy var 변수를 선언할 때 선언된 변수의 기능을 지정하는 함수다. 근데 followButton을 너무 계속 써서 클로저를 통해 캡쳐되는 기능을 활용하면 좋지 않을까 생각했고

UtilsUI 안에 setupLayout이라는 커스텀 함수를 통해 클로저를 구현했다. 쉽게 $0으로 초기화를 했다

[Clone/Instagram] 초기 tabBar와 ViewControllers 세팅 | 복습 & 새롭게 알게된 개념 #1

초기 세팅

---

• 강의에는 자동으로 navigation이랑 tabBar 색이 자동 적용 되었는데 난 흰색으로 적용이 안되서 간단하게 appearance로 white색을 정했다.

• 탭바의 viewControllers를 구현했다.

---

복습한 내용

• navigationController 인스턴스의 .tabBarItem은 탭바가 등록되었을 경우에 한해 사용 가능하다.

새롭게 공부한 개념

• TintColor : 터치했을 때 잠깐(터치 되었음을 표시하거나) or 터치시에 화면에 지속적으로 (나 터치중이다?) 보여지게 될 색상을 정한다. UIView를 상속받는 뭐든 정할 수 있고 이미지의 경우 renderMode 옵션을 .alwaysTemplate로 지정해야 한다.

[Clone/Instagram] CommentController 채팅 기능 추가 & 개념 정리(UIResponder) #14 - 2

채팅 기능 구현

• 구현 형상

채팅 기능 구현 과정 리뷰

TODO: 상대방 포스트의 하단 comment 클릭시 특정 포스트에 대한 채팅 기능 구현

• CommentService //Global
• CommentController //Controller
• CommentModel //Model
• CommentViewModelProtocols //ViewModel
• CommentViewModel //ViewModel
• InputTextView //VIew
• CommentInputAccessoryView //View
• CommentCell //View

1. 채팅 UI

위 사진은 CommentController의 Scene이다.

CommentController를 화면으로 호출하면 tabBar를 숨기고 커스텀 view인 CommentInputAccessoryView가 화면의 하단에 나온다. 이는 사용자의 메시지 입력, Post 전송 두 개의 객체로 구성되어 있다. 사용자가 입력한 텍스트는 CollectionViewFlowLayout으로 구현했다.근데 TableView로 추후 리펙터링할 것이다. cell의 width를 뷰의 크기에 맞춰서 레이아웃 구현해야 하기 때문이다.

2. upload comment, fetch comment

사용자가 텍스트를 입력한 후에 Post버튼을 누르게 되면 CommentInputAccessoryView의 내부 post 프로퍼티의 이벤트 헨들러 함수를 통해 handling했다. 입력한 comment는 파이어베이스에 업로드 후 파이어베이스에서 특정 post의 comment 컬랙션의 문서 추가 후 fetch할 때 파이어베이스 옵저버 함수를 통해 데이터가 추가되었을 때 자동으로 컬랙션 뷰 셀을 갱신한다. 여기서 문제는 데이터를 보낼 때 CommentInputAccessoryView가 UIView인 것이다. CommentController의 navigation을 인스턴스로 갖고 있지 않기 때문에 델리게이트로 CommentController에서 처리하도록 구현했다.

(Firebase data model relation)

파이어베이스에서 여러 컬랙션 중 posts data model entiry는 모든 유저가 올린 post를 저장한다. posts 컬랙션은 여러 개의 문서가 존재한다. 이때 각각의 문서는 사용자가 올린 post정보가 된다.

특정 문서를 클릭하면 필드가 존재한다. 필드에 post 정보가 담긴다. 이 뿐 아니라 comemnts 컬랙션을 추가했다. comments 컬랙션에서는 특정 post에 대해 comment를 날린 user의 문자와 특정 사용자 정보가 저장되어 있다.

맨 처음 CommentController가 초기화 될 때 viewModel에선 fetchComments() 함수를 통해 파이어베이스에서 특정 포스트에 대한 데이터가 추가될 경우 데이터를 받아오는 작업을 observe하도록 설정했다.

위에서 언급한 파이어베이스의 특정 post-> comments에서 사용자의 데이터가 추가될 경우 addSnapshotListener 함수를 통해 fetch를 바로바로 할 수 있다. 파이어베이스에서 지원해주는 함수인데 정말 진짜 신기했다.

초기 viewModel init에서 fetchComments()를 통해 comment 리스트를 받아옴과 동시에 파이어베이스의 addSnapshotListener를 통해 new comment 가 감지 되면 viewModel의 comments 리스트를 업데이트 함과 동시에 newComment publisher에게 input stream을 전송하고 transform(input:) 를 통해 CommentController의 state 중 cell을 갱신한다.

5. 다이나믹 셀

CommentCell의 label에 대해 commentLabel.numberOfLines = 0으로 함으로써 다이내믹한 height를 설정했다.

---

새로 알게된 점

UIView타입의 view를 구현하고 auto layout을 지정한 경우 이를 Controller에서 사용할 때 뷰를 추가하면 된다.

새로 공부한 개념

NSMutableAttributedString vs NSAttributedString

이전에도 공부했는데 까먹어서 확실하게 복습했다.

[Clone/Instagram] Login Scene 구현 | 복습 & 새롭게 알게된 개념 #3

Login Scene 구현

강의를 보기전에 혼자 구현해봤다. 난 그냥 anchor로 구현했는데 강의에선 email, password, login버튼 다stackview로 구현했다. 난 그 아래 작은 글씨들만 stackView로 구현했다.

로그인 할 때 초기에 navigationBar를 숨기는 방법도 있다는 것을 새롭게 알았다.. 그라디언트는 내가 맘에 드는 색으로 정했다!!

까다로웠던 점

• UITextField의 margin은 어떻게 줘야하는가?

원래 view에 마진을 줄 때는 layoutMargins의 값으로 UIEdgeInsets()를 적용했는데 textField는 되지 않았다. 그후로 공식문서를 살펴보니 editing 양 옆에 overlay view로 leftView, rightView가 존재한다는 것을 알게 되었다. 정리 차원에서 글을 작성했다.

복습한 개념

• lazy키워드는 언제 써야하는가?

lazy키워드는 인스턴스의 초기화를 늦출수 있다는 장점이 있기에 메모리를 훨씬 절약해서 사용할 수 있다. lazy가 초기화 되는 시점은 해당 인스턴스가 사용되는 시점이다. 클로저를 통해서 인스턴스를 초기화한다. 순환 참조를 일으키지 않고 @NoEscape가 적용된다. 그렇다면 모든 인스턴스를 lazy키워드로 써야할까?

음.. 원래 클래스 또는 구조체의 초기화는 변수들을 훓은 담에( 변수 생성과 동시에 초기화 되는 변수가 있는지?) init() 생성자 함수가 실행된다. 이를 통해 thread는 변수들의 초기화를 진행하는데 lazy의 경우 변수는 초기에 값이 존재하지 않는다. 그래서 thread safety가 보장되지 않는다.

변수를 초기화하는 함수의 경우 static타입인 정적으로 선언해야 변수의 초기화가 가능하다. 하지만 lazy의 경우 클래스 내 변수들의 초기화 시점에 초기화 되지 않기에 static 키워드를 붙이지 않아도 된다.

동시성적인 프로그래밍 상황에서는 lazy var 변수선언이 옳은가? 시간 내서 다시 한번 정독해봐야겠다..

그렇다면 진짜로 언제 써야하는가?

이 강의를 보면서 알게 됬는데 버튼의 경우 addTarget시에 self 를 참조한다. 근데 이것은 해당 클래스가 완전히 초기화되지 않은 상태에서 버튼 변수의 선언과 동시에 초기화를 할 때 addTarget의 self를 참조하는 것보다 lazy키워드를 선언해 해당 클래스가 완전히 초기화 된 이후에 버튼에 대한 초기화에서 addTarget(self...)가 들어가는게 바람직하다고 한다.

이 말고도 순환참조가 일어날 상황의 클래스의 변수에 대해서도 lazy키워드를 선언해도 좋다. 또한 서버에서 다량의 데이터를 불러와야할 경우에도 뷰가 호출되는 시점에 바로 다량의 데이터를 불러오는 것보다 사용자의 액션에 의해 서버 데이터가 필요한 경우에만 호출할 수 있도록 lazy 키워드를 사용하는 것이 좋다.

새롭게 알게된 개념

• CAGradientLayer

안드로이드에선 초반에 배웠었는데 그라디언트 넣는 방법을 ios공부한지 약 7개월만에 접하게 됐다ㄷㄷ...

• .backgroundColor = .init(white: 1, alpha: 0.1)

UIView의 백그라운드를 위와같이 정하면 superView의 백그라운드 색과 잘 어울리도록 된다.

[Clone/Instagram] ⭐전체적인 MVVM Architecture Pattern 리펙터링 with combine. | 마주한 에러, 문제 & 새롭게 알게 된 개념 & 개선해야 할 기능 & 느낀점 #12

TODO : adopt MVVM with combine

이번에 해볼 것은 Combine을 통해 MVVM을 분리 with DI. 안전하게 수행하기 위해 adoptCombineWithMVVMBranch 이 브랜치에서 리펙토링을 진행하고 있다.

클린코드, 가독성, DI 를 고려한 코드를 짜도록 고민을 많이 하면서 리펙터링을 했다.

새로 구현한 기능, 기능 개선

• 회원가입 기능 Combine, MVVM 적용

RegistrationViewModel RegistrationController commit log etc..

• 로그인 기능 Combine, MVVM 적용

LoginController, LoginViewModel commit log etc...

• 프로필 관련 Combine, MVVM 적용

ProfileController, ProfileHeader, ProfileHeaderViewMdoel commit log etc...

• 검색 관련 Combine, MVVM 적용.
  SearchViewModel, SearchController, SearchViewModelProtocols commit log etc...

SearchViewModelProtocols

SearchViewModel

로그인 기능 리펙터링 중 마주한 문제 1

TextField.publiser(for:)를 사용했으나 텍스트 영역을 벗어나야만 publish 되는 경우

email, password textfield가 적어도 한개씩 입력 되어야 로그인 버튼을 작동할 수 있는 기능을 컴바인을 통해 리펙터링 하고 있었다. 위 사진과 같이 구현했다. viewModel.passwd의 경우 @published로 선언했다. checkIsValidTextFields(withLogin:) 을 통해 사용자가 입력하는 실시간 타이핑에 대해 반응 하려고 위와 같은 코드를 작성했다.

TextFiled publisher는 선언이 됬다. Combine은 아직까진 UIKit에 대한 UIControl의 기능들을 추가 해주지 않았기에 TextField 포커싱에서 벗어나야만 텍스트가 변했다는 published를 해준다.

사용자가 타이핑하는 한 글자마다 publish를 원했기에 publisher(for:) 사용은 이번 구현 목표와 맞지 않았다. 따라서 NoticifationCenter를 사용해서 기본적으로 지원되는 notification을 이용했다.

여러번 작성될 것 같아서 함수로 만들었다 :)

참고한 글

검색 기능 리펙터링 중 마주한 잠재적 에러

말 그대로 잠재적 에러다.. 어떤 특정 문자열을 입력할 경우에만 항상 범위를 벗어난다고했다. 심지어 그 단어가 한개 일 지라도 잘 필터링 됬는데 에러가 발생했다. 예전에는 왜 그런지 원인을 계속 찾지 못해서 컴파일러 기분따라 그러는가보다 하고 넘어갔다가 오늘에서야 이상함을 느꼈다. 컴바인을 사용했음에도 (물론 로직은 동일) 에러가 나서 계속해서 원인을 탐색하다가 드디어 이유를 알게 되었다....

파이어베이스에서 이미지를 받아올 때 엄청 소량의 데이터임에도 불구하고 몇십번만 fetch하면 바로 돈 내라고해서 그덕에 개발을 못한 경험이 3번(3일정도) 있었다. 그래서 searchController의 tableView(numberOfRowsInSection:) 목록 크기를 대폭 낮춰서 Constant인 3으로 해버려서 이런 문제가 발생했던 것이다.

• filteredUsers(검색에의해 필터링 된 데이터들 ) PassthroughSubject 타입으로 초기에 설정했다가 @published타입으로 바꿨는데 이때 관련 로직을 깜빡하고 수정하지 않아서 이상한 indexPath.row가 나왔던 것,,,

또 하나 발견한 에러는 string.contains()는 대소문자를 구별한다. 근데 나의 경우 사용자의 첫 글자를 대문자로 입력하도록 설정해서 검색이 잘 안됬다. 그래서 데이터를 filter할 때 lowercase()를 사용함으로 해결했다.

---

개념 정리

컴바인을 공부하면서 Notification을 공부했었지만 이참에 간략하게 다시 정리한다.

Notificaiton

Swift에서 notification은 애플리케이션 내에서 "알림을 방송"하는 역할을 갖는다. 그렇다면 방송을 하기 위해 어디로 송신, 어느 체널로 주파수를 맞춰야 방송을 들을 수 있는지 정해야 한다. Notification을 전달하는 중심은 NotificationCenter이다.

NotificationCenter

등록된 observer들에게 정보의 BroadCast를 가능하게 하는 Notification Dispatch 매커니즘 통해 동작.

DispatchQueue, NotificationCenter등을 통해 직접 접근할 수 없는 system 기능을 이용할 수 있도록 도와주는 것이다. NotificationCenter를 통해 notification을 하기 위해서는 observer(or subscriber), publisher가 있어야 한다. 즉 publisher가 published한 notification은 NotificationCenter를 통해 subscriber, observer등에게로 전달된다. .default를 통해 하나의 객체로 관리할 수 있도록 만들었는데 싱글톤의 개념과 달리 커스텀이 가능하다고 한다!! ( 방학때 더 공부해 봐야겠다..)

그리고 UIControl 관련 기능을 아직.. 지원하지 않지만 NotificationCenter.default.publisher(for:object:) default로 정의된 UIControl관련 notification기능을 publish 할 수 있는 publisher를 사용할 수 있다 :) CombineUtils.setupBindings()을 통해 사용할 수 있도록 했다.

왜 이런 코드를 짰을까?

SearchController에서 검색에 의한 tableView cell 업데이트 관련 코드

updateSearchResults(for:) -> searchResult.send(text) -> viewModel.transform -> searchResult subscriber 실행 -> 데이터 필터링 후 테이블 리로드 .

이제 cell 업데이트가 시작된다.

원래 내 계획은 viewModel의 searchResult에서 필터링 과정 후 그 결과를 PassthroughSubject<[userInfoModel],Never> 타입의 filteredUsers(필터링 된 특정 데이터 배열)에 send하려고했다. 근데 filteredUsers를 PassthroughSubject타입으로 하자니 필터링 된 전체 값을 반환할 때 sink를 통해 반환해야하는데 이때 또 다른 변수를 선언해야 했기 때문에 PassthroughSubject가 아닌 @published로 타입을 바꾸었다. 이때 @published에 맞게 바꿔야했었는데 깜빡하고 오류가 난 부분만 수정해서 wrong code를 바탕으로 계속해서 코드를 구현해갔다. 그래서 sink가 필요하지 않아도 계속해서 publised된 값을 받아서 indexPath.row가 filteredUsers의 범위를 초과했다는 오류를 계속 발생시킨 것이다. 코드를 더 깔끔하게 분산시켜야겠다.. 코드 짜는 내내 이리갔다 저리갔다 해서 잘못된 로직을 파악하지 못 했던 것 같다.

추가, 개선 해야할 기능

• 검색하기 위해 서치바를 클릭할 때 tableView reloadData가 실행된다. 이것을 없애야한다.

• ProfileVC 관련 tableView delegate들 input/output패턴으로 VM으로 리펙터링 해야 한다.

• Login 관련 기능

추후 비밀번호 최소 입력 개수를 제한하고 알림창을 띄우는 기능을 추가할 것이다. 또한 토스의 회원가입 절차처럼 만들어 볼 것이다.

고민거리..

약간 고민인게 struct타입의 모델에 @published, PassthroughSubject 같은 publisher 타입의 변수를 선언해도 되는지 했갈린다.... 데이터를 저장 + 흐름까지 갖게 되어서 선언하면 편한데.. 본질이 망가지는게 아닌지 고민스럽다.. 결론은 그냥 Model선언을 안하면 되는데.. 그래서 안 했다. (Model의 영향이 많이 줄었네..)

근데 해도 될 것 같다.

새로 리펙터링 해야할 것

• Feed VC 관련
• Upload VC 관련

SearchController 를 SearchViewModel과 분리할 때 SearchViewModelProtocols 요기에서 이 두 함수를 꼭 UserViewModel로 분리해야한다. SearchViewModel에 의존적이다.

시험이 7일 남았다.. 큰일났다.. 학교 공부보다 스위프트를 할 때 시간이 빨리간다.

// 여담..

컴바인 공부만 3주? 한달 째 되가는데 한달 전에 주문한 책이 드디어 도착했다. 기말고사 빨리 끝나면 좋겠다. ˘ᗜ˘

[Clone/Instagram] 🚩 LoginController MVVM 리펙터링(에러처리, clean code) with combine | LoginController Code Review 🖋️ | 마주한 에러 & 개선해야 할 기능 & 느낀점 & #13

TODO: 이번엔 Never인 경우는 없다는 생각으로 LoginController 리펙터링.

구현 영상

---

간단한 LoginController 코드 리뷰 ( 시험 끝나도 까먹지 않기 위해.. )

👋 TODO: 사용자가 로그인 하는 과정을 컴바인으로 구현 with mvvm pattern + DI(Dependency Injection). 이때 발생할 수 있는 모든 오류 throws -> 처리.

• LoginController

• LoginViewModelProtocols

• LoginViewModel

사용자의 로그인 기능, 화면과 관련있는(회원가입 빼고!!) 소스코드는 위에 있는 단 3개로 구성했다.

1. LoginController에 관해 (LoginController Link)

• input/output pattern. DI

구현영상 초기 화면에서 보듯 LoginController의 view는 2개의 textfield(id, pw 입력) login button으로 구성되된다. RxSwift에서 MVVM 패턴을 사용할 때 input/ output pattern을 이용한다. 이를 이용하면 Dependency Injection(DI) 또한 가능하다. LoginController가 초기화 될 때 반드시 LoginViewModelType로 초기화 함으로 DI했다.

• input/output implement with error handling

LoginController는 viewModel을 사용할 때 많은 함수가 필요 없다. 그저 input, ouput을 바인딩 하기만 하면 된다. 따라서 LoginController에서는 viewModel 변수를 통해 transform 단 한개의 함수만 실행하도록 했다. 왜? input/output pattern을 통해서 LoginController에서 발생되는 모든 view의 Event flow handling을 viewModel에서 하기 때문이다.

• render(in:)

한가지 더! LoginController에서 주시할 함수는 render함수이다. LoginController에서 발생한 각각의 이벤트에 대해서 viewModel의 transform(input:) 함수를 통해 특정 publisher의 chains 함수를 통한 흐름 처리 이후에 값을 output로 받는다.

이때의 output 종류는 LoginControllerState에 따른 3가지가 있다. 주 역할은 view의 상태 변화를 위한 output을 enum으로 정의한 것 뿐이다. 그저 state에 따라 view의 상태 변화를 실행하면 된다.

2. LoginViewModelProtocols에 관해 (LoginViewModelProtocols Link)

LoginViewModel을 설명하기 전에 위의 protocols를 보면서 작업하면 편하다. 맨 처음에 delegate가 있는데 추후 없앨 계획이다. (델리게이트 때매 꼬이는 느낌이..)

• viewModel's all error type

LoginController의 upstream input로 오는 각각의 publisher에 대해 stream operator chains를 수행할 때 발생 할 수 있는 모든 오류를 정의했다. 맨 위 제목에서 보듯 Never타입이란 없다고 가정하고 발생할 수 있는 모든 에러에 대한 처리를 하고 싶었기에 정의 했다. 원래는 콘솔창에 단순한 출력이 아닌 특정 case에 따른 알림 or 다른 화면으로 이동해 다시 특정 로직을 수행하는 로직을 구현해야 한다. 방학때.. 할 것이다.

그래서 LoginController의 input, output publisher의 failure타입은 전부 LoginViewModelErrorType가 된다. ( 제네릭값들을 typealias로 바꾸면 얼마나 좋을까 찾아봤는데 없었다 ㅋㅋ,,)

// 여담

한가지 느낀점은 c언어로 테트리스 만들었을 때 각각의 enum은 숫자의 값만 갖을 수? 있었는데 swift는 특정 case자체를 string으로반환하거나 각각의 case에 대해 특정 타입으로 반환하는게 진짜 매력인듯 하다.

• LoginViewModelInput

다음은 LoginController에서 발생할 수 있는 이벤트들을 struct로 정의한 것이다. 이 각각의 publisher가 publised될 경우 viewModel에선 특정 input의 publiser에 대한 upstream publisher's operator chaining을 수행한 후 output으로 반환한다.

• LoginViewModelInputCase

다른 건 없다. 각각의 input's upstream publisher에 대한 결과 처리를 stream의 형태로 처리하는 실질적인 함수들이다. 이때 protocol로 구현한 이유는 코드를 모듈화 시켜 transform(input:)함수의 로직을 읽을 때 이해하기 쉽게 하기 위해서 그렇다. 물론 내가 생각한게 아니다.(언젠간 나만의 규칙을 꼭 만들 것이다... 대중적으로 인정받으면 좋고,,) (링크) 요기에서 보이는 책의 저자가 많은 세월을 코드와 함께 하면서 쌓은 노하우들을 바탕으로 클린 코드를 구현했다. 난 이 저자의 규칙이 정말 괜찮은 것 같아 클린코드의 규칙을 따라 구현을 했다!!!

• LoginControllerState

input -> transform(input:) -> LoginViewModelInput -> LoginViewModelInputCase 를 거친 후에 각각의 input에 대해서 Merge를 통해 최소한의 subscriber된 각각의 publiser 가 연산을 처리하면서의 결과를 반환한다. 크게 뷰의 상태 변화는 3가지이다. 사용자가 id, pw를 입력했는지 -> 둘다 입력했을 경우 loginButton enabled됨 else disabled. none, 실행중인 인디케이터 해제. 이 세가지다!!

• LoginViewModelNetworkServiceType

그 밖에 로그인 버튼을 통해 로그인 할 때 파이어베이스에 등록된 계정이 맞는지 여부 함수다. wwdc 2021에서 소개된 async, await 비동기 처리를 도입했다. 헤헤. 나중에 컴바인과 결합 할 코드를 구현할 것이다.

// 여담2 이번 방학때 Swinject 아니면 needle를 공부할 것이다. DI는 지난 3주간 컴바인 공부 때 머릿속으로만 계속 떠올리다가 학교 과제 ISS (링크)약 2주간 Instruction Set Simulator를 구현 할 때 의존성이 있는 코드를 도입 하고자 열심히 노력했다. iss 프로젝트 끝난 후 개념으로만 숙지하고 있던 Combine을 적용하고 있는데 protocol 관련은 나쁘지 않게 스위프트에 바로 도입할 수 있었다.
근데 C++에 interface가 지원이 안 된다는 것을 진짜 몰랐다. 그래서 define으로 정하긴 했다.. 근데 순수 가상함수를 선언 해도 결국엔 상속받는 하위 클래스에서 반드시 구현할 때 .h 파일에 재 선언 후 .cpp 파일에서 구현해야 한다는게 너무 아쉬웠다. swift 였다면 중첩 선언이 없는 깔끔한 코드였을 텐데.. 아무튼 ISS를 구현한 덕에 DI관련 개념을 적용하는 것은 나쁘지 않았다는 말!!

3. LoginViewModel (LoginViewModel Link)

이거는 직접 코드로 보는게 좋겠다.

원래 코드 리뷰를 정말 좋아한다. 그리고 주석 으로 부연설명하는 것을 굉장히 좋아한다.. 학교 교수님들이 시켜서 습관이 된 것이 있기도 했다. 클린 코드를 읽으며 코드를 직접 읽을 때 한번에 알 수 있도록 하는 네이밍이 굉장히 중요하다고 했다. 그래서 요즘은 주석 처리하는 습관 대신 깃헙의 issue에 개발하다가 느낀 경험이나 문제, 에러들을 문서화?로 작성하고 있다. 근데 코드리뷰, 주석 습관은 정말 좋다고 생각한다. 하지만 주석 없이 몇 번만에 코드를 이해하는 코드는 정말 훌룡한 코드이고 주석이 필요 없지만 중간에 마주한 상황, 배운점들은 주석이 아닌 issue에 기록하는 새로 습관을 들이고 있다. 그리고 최대한 네이밍을 자세히 해서 코드의 흐름을 정확하게 파악할 수 있도록 구현하는 것이 내 목표다. +_+

---

마주한 에러1

Combine의 publisher tryMap의 사용시 failure타입에 관한 에러.

tryMap을 사용해 error를 던질 수 있을 경우 publisher의 failure타입은 Never가 되면 안된다. Merge -> 그대로 eraseToAnyPublisher()로 변환한 subscription을 갖을 경우에 타입의 모호함 에러가 뜬다.

마주한 에러2

failure 타입이 Never가 아닌 경우

tryMap 은 any error 타입 반환한다. 내가 원하는 publisher failure type에 맞게 mapError를 사용해서 커스텀 error타입으로 에러를 캐스팅 해야 한다. 그래야 subscriber에게 failure를 던질 수 있다. publisher의 failure타입 Never가 아닌 경우에는 map이 아닌 tryMap같은 try 기능이 담긴 연산자를 사용해야 한다.

LoginController와 MainHomeTabViewController 간에 델리게이트를 이전에 작성했기에 살작 복잡했는데 publisher의 input output에 두개의 vc를 전달함으로 해결했다.

복습한 개념

A, B두 개의 publisher가 있다고 가정.
let myZip = A.zip(B)

• combineLatest
  얘는 A가 publish하고 B또한 publish해야만 myZip이 published된다. 약간 커플느낌? 한 쌍이 publish되야만 비로소myZip이 작동한다. 약간 내가 구현하는 id,pw둘다 입력해야만 로그인 버튼 해제되는 로직과 같음. 아래꺼는 약간 password 두번 입력해서 자기가 입력한 password 맞는지 확인할 때의 operator라고 보면 될 거같다.

• zip
  얘는 A가 publish하고 B가 publish해야만 myZip이 publised된다. 그리고 A가 publish되면 B의 최신 값과 함께 publish된다. 즉 둘다 published한 경우에 A만 publish해도 B는 최신 publis 값을 재사용한다. 반대의 경우도 같다.

추가, 개선 해야할 기능

• 검색하기 위해 서치바를 클릭할 때 tableView reloadData가 실행된다. 이것을 없애야한다.

• LoginController 비밀번호 최소 입력 개수 제한

• RegistrationController

또한 토스의 회원가입 절차처럼 만들어 볼 것이다.

새로 리펙터링 해야할 것

• Feed VC 관련
• Upload VC 관련

SearchController 를 SearchViewModel과 분리할 때 SearchViewModelProtocols 요기에서 이 두 함수를 꼭 UserViewModel로 분리해야한다. SearchViewModel에 의존적이다.

시험이 6일 남았다.. 정말 큰일났다.

느낀점

사실 에러 처리를 단순히 콘솔창에 출력했다. 방학이 내게 온다면 특정 상황에 맞는 알림이나 오류를 대체할 수 있는 로직을 구현할 것이다.

(시험만 끝난다면 컴바인 책으로 추가 공부할 텐데)

[Clone/Instagram] 프로필 Scene 구현 | 색다른 시도 & 새롭게 알게된 개념 & 개선해야 할 기능 #7

프로필 Scene 구현

구현 영상

강의와는 다르게

• 로그인된 사용자의 정보를 Firebase DB에서 꺼내와 실시간으로 갱신하도록 추가 구현
• profileHeader의 프로필, 사용자 이름등 Firestore DB의 데이터를 fetch하는 함수 만듬
• Firestore Database에 값을 꺼내오거나 저장할 때 Codable타입으로 Model을 새로 구현했다.

개선해야 할 기능

• 회원가입 실패 시 버퍼링 끊기
• profile Header의 image를 Storage.storage에서 받아오는데 시간이 많이 걸림. 기능 개선이 필요.. (원래 파이어베이스에서 작은 이미지 받아오는 경우도 느린지 모르겠다,,)

• ProfileController에서 grid, list bookmark 버튼이있는데 이를 stackview+pageViewController로 추가 구현해보기

새로 알게된 것

컬랙션 헤더를 사용하기 위해서는

1. 헤더를 등록해야함
   collectionView.register(_:forSupplementaryViewOfKind:withReuseIdentifier:)
2. DataSource로 Header뷰를 반환하면 됨 collectionView(_:viewForSupplementaryElementOfKind:at:)

이때 얘는 UICollectionReusableView를 반환함으로 HeaderView의 타입은 UICollectionReusableView로 구현하면 된다.

3. collectionView(_:layout:referenceSizeForHeaderInSection:)

헤더 크기 반환!

---

CollectionViewDelegateFlowLayout

• collectionView(_:layout:minimumLineSpacingForSectionAt:)

minimumLineSpacing 경우 아래로 스크롤하는 레이아웃일 때 row간의 최소 간격을 정한다. horizontally의 collectionLayout의 경우 column간 최소 간격을 결정한다.

• collectionView(_:layout:minimumInteritemSpacingForSectionAt: )

minimumInteritem을 설명하자면 아래로 내리는 collection layout인 경우 cell의 row간 최소 space를 설정할 수 있게 해준다. 옆으로 스크롤하는 collectionLayout인 경우 cell의 column간 최소 space를 설정하게 해준다.

vertical 기준으로 minimumLineSpace는 행 간의 최소 간격, minimumInteritem의 경우 row의 cell간 최소 간격을 지정한다.

---

cf.

UICollectionViewDelegateFlowLayout
-> collectionView cell의 사이즈 조절

UICollectionViewDelegate
-> cell 선택 관련 메서드

---

cocoapods 관련

삭제 후 재설치 or 업데이트

• pod cache clean --all && pod install --repo-update

• pod update

• 내가 설치한 cocoapods과정 (iterm을 로제타로 실행)

• 코코아팟 문제 생겼을 때 삭제하는 방법 참고로 프로젝트에 연결된 Pods, .xcworkspace 등은 삭제해도 된다. 다시 깔면 됨. 중요한건 소스코드다.

마주한 에러

arch -x86_64로 m1 용으로 설치했는데 아래 에러가 계속 발생했다. 음 Target-> Build Settings ->Architectures -> Excluded Architectures 에서 arm64를 추가 해보고 Any ios simulator SDK arm64로 선언해도 여전히 해결이 안됬다.

---

뭔가 대단히 잘못 되어가고 있다... 원래 내 목적은 firestore에서 저장된 도큐멘트의 필드값 유저 정보를 Codable 타입으로 받아오기 위해서 ... pod FirebaseFirestoreSwift을 추가한 것 뿐인데

이 에러들이 계속 발생했다;;;

arch -x86_64로 m1 용으로 설치했는데 아래 에러가 계속 발생했다. 음 Target-> Build Settings ->Architectures -> Excluded Architectures 에서 arm64를 추가 해보고 Any ios simulator SDK arm64로 선언해도 여전히 해결이 안됬다.

(진짜 큰일났다. 2일째 개발은 물론 지금 프로젝트 내 파일까지 잘못 삭제해 버렸다;;)

cocoapods를 삭제하고 재 설치하려고 했는데

이 에러가 발생했다. chmod로 user에게 권한도 줬지만 여전히 이런 에러가 발생했고 위와 같은 에러가 발생햇다.

(살려줘..)

지금 gem으로 bundler도 설치가안되고 cocoapods도 설치가 여전히 안되고 있다...

어찌어찌 해서 arch -x86_64 로 코코아 팟을 설치했을 땐

Ignoring ffi-1.15.4 because its extensions are not built. Try: gem pristine ffi --version 1.15.4

이 에러가 발생하면서

이 에러가 발생했는데 이 에러는 자세한 에러를 알 수 없다고 한다... 퓨ㅠㅠ 이것때매 뭐 잘못 삭제 했다가 프로젝트 안에 파일 일부를 실수로 삭제 해버린 것..

지금 가장 큰 문제는 gem을 통해 설치하려고하면 사용자 권한이 아니라 루트 권한을 요구해서 **(Gem::FilePermissionError)**가 자꾸만 발생했다.

이분의 블로그 글을 통해서 설치해도 마찬가지였는데...

rbenv 최신 버전 3.1.2인가? 그걸로 계속했는데 안됬다. 어떤 다른 분의 글에서는 3.xx버전에선 뭔가가? 설치가 안된다고해서 2.xx버전으로 재 설치했는데 다행히 Gem::FilePermissionError 가 더이상 발생되지 않았다...

그래도 여전히 Command ComplieSwift failed with a nonzero exit code가 발생했다...

결국 해결책은 찾지 못해서 앱을 다시 새로 만들었는데도 위에 에러가 계속 발생했다.

지금 그 이유를 알았다;;;; RESTful API가 아니라 파이어베이스를 사용하기 때문에 파이어베이스 시작 할 때 앱 번들 아이디를 토대로 파이어베이스 plist가 주어지고, AppDelegate에 FirebaseApp.configure()로 등록도 해줘야 하는데 이 부분을 간과했다. 그래서 파이어베이스에 등록된 앱을 삭제하고 다시 새로 만든 번들을 추가해서 다행히 에러가 해결되었다... ㅠㅅㅠ 약 2일간 고생했다..

---

다음엔 rvm을 써봐야겠다. 결론. 깃헙 커밋을 자주자주 하고 정말 안 될때는 새로 만들어서 소스코드 복붇하기. 파이어베이스 쓸 경우 앱 번들아이디 삭제 후 새로 등록하기

HotCoffee 강의 안보고 일단 초기 레이아웃 구현 #1

[Clone/Instagram] 전체적인 기능 개선, 에러 수정 | 새롭게 알게 된 개념 #9

전체적인 기능개선

• 회원가입버튼 클릭시 파이어베이스에 등록하는 과정 시간 좀 걸려서 인디케이터 처리 완료
• 반복적으로 메인 탭컨트롤러의 subController들이 호출되는 것 한번으로 개선
• 로그인 화면 앱이 시작될 경우 메인 탭 바의 FeedVC 인스턴스 등록 안되는 버그 개선
• 로그인 상태에서 로그아웃 후 다른 계정으로 로그인 시에 파이어베이스의 currentUser가 잘 작동이 안되서 프로필 VC의 프로필이 앱을 껏다 켜야 하는 갱신되는 버그 고침. (Auth.auth().currentUser 믿지 말것,,)
• 프로필 이미지 다운로드 하는 것을 초기 로그인 때부터 비동기로 받아와 프로필VC를 클릭했을 때 거의 바로 보여도록 개선
• 상대적으로 크기가 큰 프로필 이미지는 다운이 안되는 버그 수정

구현 영상

에러 수정(겪은 점)

앱 삭제하고 맨 초기에 로그인화면에서 로그인 후 mainTab컨트롤러의 first subviewController FeedVC 안 들어가지는 에러 수정.

현재 앱 상태를 간단히 요약.

UIWindow의 루트뷰 컨트롤러 디폴트는 메인 홈 탭 컨트롤러이다. 초기 앱이 실행되면 메인 홈 탭컨트롤러 뷰 로드 과정에서 파이어베이스에 사용자가 로그인 되어 있을 경우를 확인한다. 해당 정보를 홈 탭 컨트롤러 프로퍼티 userVM에 초기화 하면서부터 앱이 시작된다. userVM이 초기화 되면 tabController의 viewControllers의 뷰들이 등록되고 첫번째 뷰인 FeedVC가 로드된다. 메인탭컨트롤러의 subViewController들은 userVM에 정말 의존적이다. userVM값이 초기화 되야 서브컨트롤러들이 등록되기 때문이다.(파이어스토어에서 다운받는 방식이 살짝 느려서 미리미리 최소한의 사용자 데이터를 준비하기기 위해 이렇게 정했다.)

근데 만약 앱에서 (파이어베이스)로그아웃을 한 다음에 앱 종료 -> 다시 앱을 시작할 때 현재 사용자 로그인 기록이 없기 때문에 메인 홈 탭컨트롤러의 서브tabVC들이 초기화 되지 않는다. userVM이 초기화 되지 않았기 때문. 메인 홈탭컨트롤러 viewLoad 시점에서 LoginVC로 이동된다. 여기서 메인 홈 탭컨트롤러는 완전히 뷰가 로드되지 않은 채로 로그인 뷰 컨트롤러로 을 할 때 경고 메세지가 발생됬다.

• • Unbalanced calls to begin/end appearance transitions for <Instagram.MainHomeTabController: 0x12d02ca00>

여기서 약간 애매하고 난감한 상황이 발생됬다. 반드시 userVM이 초기화 되어야 메인 홈컨트롤러의 서브VC들이 추가되면서 FeedVC가 로드된다는 점인데... userVM이 초기화되기 위해서는 사용자가 파이어베이스에 로그인 되어있는지 확인해야 한다. 뷰가 메모리에 로드되는 viewDidLoad 시점에 사용자의 로그인 검사를 하고 로그인 화면으로 넘어가자니 위와 같은 경고 메세지가 발생 되지만 사용자의 로그인 화면은 불러와진다. 다시 LoginVC를 dismiss했을 경우에 메인 홈탭컨트롤러가 이상하게 초기화되서 그런지 흰 화면이 뜬다. 뷰 계층 구도를 봐도 FeedVC가 안 불러와 진다.( userVM초기화 델리게이트를 LoginVC에서 사용자의 로그인 성공시에 등록해줬지만 안됬다. 위의 경고메시지처럼 UIWindow에 루트뷰컨트롤러 등록할 때 오류가 난 것 같다는 생각이,,) viewWillAppear시점에 로그인 컨트롤러 화면 전환을 해도 역시 위와 같은 경고 메세지가 발생된다.(viewWillAppear까지 함수가 완료되야 비로소 메모리에 뷰가 로드되는 것 같다..아닌가? 더 알아봐야겠다.)

메인 홈 뷰가 완벽하게 초기화 된 이후에 사용자 로그인 검사를 하고 나서 로그인VC를 초기화 해야하는데 방법이 떠오르지 않아서 다양한 시도를 했다. 계속 씨름하던 중 좋은 방법이 떠올랐다. 원래 내가 구현한 로그인 확인 코드는 파이어베이스에서 사용자의 current 정보가 없는 경우에 무조건 로그인 화면으로 present하라는 함수를 선언했었다. isLogin 변수를 추가해서 메인 홈탭컨트롤러의 메모리 로드시점에서 사용자 로그인에 대한 bool 정보를 담고 뷰 로드가 완벽하게 된 후를 알 수 있는 방법은 변수들이 초기화 된 시점인 didSet을 통해서 해결할 수 있었다.. (하하)

로그아웃 후 다른 계정으로 로그인 시 로그인된 사용자의 계정 정보 업데이트 안되는것 고침
로그아웃 후 로그인시 UserService.fetchCurrentUserInfo(completion:)에서 current user데이터를 받아온다. 이때 사용되는 파이어베이스의 도큐먼트 key값인 uid를 Auth.auth().currentUser로 받아온다. 근데 이게 바로 바로 업데이트가 되지 않는다.(왜 그런진 모르겠다. 앱을 종료하거 재접속해야만 비로소 반영이 된다.) 그래서 아이디와 비밀번호로 로그인 할 때 (handleIsLoginAccount) 바로 반환받는 결과는 따끈따끈하게 방금 로그인 된 사용자의 uid를 얻을 수 있다. 이점을 이용했다.

현재 에러

계속적으로 확인해본 바 x

새롭게 알게 된 개념

Error Domain=FIRAuthErrorDomain Code=17008

• 파이어베이스에서 이메일, 비번 만든 거 등록할 때 이메일은 이메일의 규칙을 지켜야한다.

NSLocalizedFailureReason" : "Password should be at least 6 characters"

• 비번 만들 때 사용자는 최소한 6자리 넘게 만들어야 한다.

• 한가지 궁금한 점은 파이어베이스에서 등록된 로그인 성공시에 result는 바로 사용자의 account 반영이 되는데 왜 Auth.auth().currentUser는 앱을 재시작 하기 전까지 이전 로그인된 계정 정보를 담고 있는 것일까?

HotCoffee Postman 사용!!

쉽게 서버에 GET으로 데이터 확인할수도있고 POST로 서버에 데이터를 넣어줄 수도 있다.

초기 MVC패턴으로 간단하게 api파싱후 tableViewCell 구성.

news API를 Alamofire로 파싱한 json Object를 우선 그냥 Controller를 통해 tableViewCell을 구성했다.
이제 Controller가 아니라 ViewModel의 관점에서 어떻게 View에 관여하는지 공부할 것이다.

[Clone/Instagram] Firebase 구현 | 복습 & 새롭게 알게된 개념 #5

Firestore Database로 회원가입 구현

구현 영상

느낀점

이번에는 파이어베이스를 처음 다뤘기에 강의를 보며 구현했다. 하지만 계속 에러가 발생했다.( 데이터베이스에는 올라갔는데 AuthService.registerUser함수의 completion 클로저의 error.localizedDescription에서 에러가 발견됬다.)

새로 알게된 개념

• firestore에서 저장하는 방법

Firestore.firestore().collection("users").document(uid).setData(data, completion: completion)

1. collection이름 정의 -> users로 정함
2. 도큐먼트 이름 정의 -> uid로 값을 가짐
3. 도큐먼트에 해당하는 데이터 정의 ->data는 RegistrationViewModel 모델임

---

• 로그인시 정보를 어떻게 처리해야하는가?

1. 로그인 버튼이 눌릴시 사용자의 로그인 정보가 있다. 이 정보를 파베에 바로 업로드 하기 전에 우선 이미지를 따로 처리 해야 한다. 로그인 이메일 비번 등의 정보는 Firebase Database에 저장하는데 이때 사용자의 이미지의 경우 UIImage가 들어갈 순 없어서 data나 url 주소를 JSON으로 처리한다. 이미지는 Storage에 따로 저장된다. 그래서 사용자의 로그인 정보를 먼저 처리하기 전에 이미지부터 Storage에 업로드 하고 성공적으로 파이어베이스에 업로드 됬다면 그 url을 포함해서 사용자의 회원가입 정보를 FirestoreDatabase에 올린다.

2. 이미지 자체를 올리고 내려받을 경우에 용량이 크기 때문에 jpegData(compressionQuality:)를 통해 해상도를 약간 낮추어서 Storage().storage().reference(withPath:)를 통해 저장되는 경로를 지정한 후에 이 인스턴스를 통해 이미지를 파이어베이스에 올린다. 업로드된 이미지의 url또한 얻을 수 있다. 이 url을 포함해서 Firestore Database 필드에 사용자의 정보를 추가하면 된다.

3. Firestore Database 필드에 사용자 정보를 등록하기 위해
   Auth.auth().createUser(withEmail:password:)를 통해 먼저 사용자 등록을 통한 user 식별자를 생성한다.

createUser를 통해서 각 사용자는 자신만의 식별자를 가지게 된다. firestore()의 collection("users").document(uid).setData()에 사용자의 모든 정보를 저장하기에
users는 uid로 이루어져있고 그 uid는 .setdata 필드 정보를 기록하고 있다.

createUser의 completion에서 에러가 없다면 사용자의 정보가 등록됨을 알 수 있다. 그 특별한 식별 인스턴스는 result?.user.uid로 얻을 수 있다.

재 정리하자면

위에서 언급한 2. 의 이미지 우선 업로드 이후에 url 정보를 포함한 사용자의 회원가입 data는 firestore Database에 저장할 것이다.

이 구조는 firestore Database에서 구현한 구조이다.(RegistrationViewModel -> JSON)

파이어스토어는 다양한 컬랙션들을 만들 수 있다. (알림, 포스트, 사용자 정보 등등) (엔터티로 이해하고 싶네,,) 컬랙션은 Firestore.firestore().collection() 을 통해 만들 수 있다. 그리고 컬랙션에는 각각의 문서가 있다. 이 문서는 각각의 사용자 정보 테이블(필드)을 호출하기 위한 특별한 사용자의 식별자를 저장할 수 있다. document의 이름은 ..collection("users").document(특별한 사용자의 값) 을 통해 정의한 후에 이 특별한 사용자의 값에 JSON형식의 데이터를 저장한다.(필드)

한마디로 여러개의 주제로 나뉠 수 있는 컬랙션 집합 중 한 컬랙션은 이 컬랙션의 data modeling 엔터티를 바탕으로 다양하게 정의된 테이블들의 데이터(필드)가 존재하는데 테이블들을 가리킬 수 있는 게 문서다. 이 문서들로 특정한 한 컬랙션이 구성된다.

이 강의에선 컬랙션에 users라는 컬랙션을 추가하고 컬랙션을 구성하는 여러 문서는 uid를 통해서 문서를 구성한다. 근데 이 uid는 Auth.auth().createUser(withEmail:password:)를 통해 만들어진 고유의 식별자이므로 문서의 값들은 집합(Set)의 속성을 지니게 된다. 문서를 열어보면 필드가 나오는데 이 필드에 RegistrationViewModel의 특정 사용자 회원가입 데이터 JSON구조가 저장된다.

윽;; AuthService.registerUser(withUserInfo:)에서 파이어베이스에는 성공적으로 유저의 정보가 업로드 되는데 차꾸만 데이터베이스 nil처리가 되었다고 했는데 알고보니 에러처리를 잘못한 내 실수였다... 그래도 파이어베이스에 대해 좀 더 알아보게 되었다.

---

새롭게 알게된 개념

• jpegData(compressionQuality)

원래는 pngData()를 사용했는데 이번에 새롭게 jpegData()에 대해 알게 됬다.

• 파이어베이스 프로젝트 등록,,

1. 프로젝트 생성
2. Authentication에서 로그인 제공업체 지정
3. storage bucket 설정. 앱에서 로그인 생성할 때 사진을 request했다면 따로 설정해줘야한다. Rules에서 사용자의 승인 전에 사진 업로드 할 수 있도록 setup해야한다.

allow read, write: if request.auth != null || request.auth == null ;

4. db추가하는데 ios -> 번들아이디 등등 입력.

HotCoffee decoder로 변환하는 과정에서 차꾸 nil이 적용되네,,

Data has been successfully retrieved. However, Codable is not applied during the decoder.decode(_:from:) process.

[AutoLayout/CHCRLab] Anchor로 auto layout 정의 할 때 발생하는 모호성

GoodNews codereview

GoodWeather 구현

Hotcoffee 완료

중간에 마주한 에러는 POST로 data는 잘 전송됬지만 이전화면으로 넘어가지지 않고

UITableViewAlertForLayoutOutsideViewHierarchy error: Warning once only (iOS 13 GM) 이 에러를 마주했다.
아마 영상보면서 따라했지만 화면 전환과정 등등 다르게 했기에 에러가 발생했다... 원인은 이미 테이블뷰가 존재함에도 불구하고 추가적인 Order를 넣어서 곧바로 테이블 뷰 의 셀을 한칸늘리도록했기 때문에 발생한 에러인 것 같다.

해결방법은 viewWillAppear에 tableView.reloadData()를 실행해주고 그냥 오더 받으면 첫번째 메인화면에서 단지 list에 값만 추가하는 방식으로 해결했다.

[Clone/Instagram] 새로운 기능 추가, 리펙터링 | 마주한 에러 & 개념 정리(UIResponder) #14 - 1

새로운 기능 추가, 리펙터링

• 특정 사용자 검색 후 해당 프로필 아래의 posts 중 하나 클릭시 상세 페이지로 들어감
• PostController에서 부분적으로 동시성이 필요한 경우 async let. or TaskGroup로 동시성 적용.
• API fetch 전부 async await 리펙터링

마주한 문제1

FeedController에서 리프레시할 때 에러를 발견했다. FeedController에서 리프레쉬를 하면 Index out of range가 뜬다.

FeedController 변수 posts를 화면에 띄운다. 리프레시할 때 현재 있는 posts변수를 RemoveAll한다.

그 후 fetchPosts() 함수를 호출해 데이터들을 fetch한 후에 posts(collectionView cell 구성하는 데이터) 값을 갱신한다. 그런데 이때 에러가 발생한다. 짐작되는 가장 큰 이유는 fetchPosts()는 async함수인 점이다. Task()에서 데이터를 fetch해야 posts가 갱신된다. 중요한 것은 비동기 함수라는 것.

refresh 이벤트가 발생 후 handleRefresh()로 포스트는 삭제됬다. 동시에 리프레쉬 동작으로 인해 컬랙션 셀들이 아래서 위로 올라오면서 아래 나올 가능성이 있는 1~2개의 cell을 dequeueReusableCell에서 꺼내온다. 이때 posts는 값이 없으므로 Index out of range 오류가 뜨는 것이다.

해결 방법은 리프레시 이벤트 헨들러에서 posts.removeAll()이후에 바로 컬랙션 뷰를 리로드 하는 것이다. 그래서 collectionView의 cell의 개수를 0으로 설정하는 것이다. 다른 대안이 있긴한데... 그냥 이 방법이 나쁘지 않은것 같다

마주한 문제2

Concurrency로 taskGroup가 아닌 async let 을 사용하려고 한다. In ProfileViewModel.swift

fetchToCheckIfUserIsFollowed() //사용자가 나를 팔로우했는지(bool)

fetchUserStats() //사용자의 팔로우, 팔로잉 상태

fetchImage(profileUrl:) 사용자의 이미지

이 세게를 동시에 fetch 하려고한다.

각각의 async 함수들은 안에서 에러를 잡아주기 때문에 async let 을 선언할 때 함수 throw 처리 생각하지 않아도 된다.

이렇게 Concurrency를 선언했다면 타입 표현이 ambigous하다는 경고가 나온다. 왜 그럴까

곰곰히 생각해봤는데 249라인에서 결국 배열의 각 원소는 Bool, Userstats, UIImage 원소가 있을 거고 이 세가지 타입을 모두 허용하는 배열은 없다. 그래서 배열의 타입은 Any가 된다. 그래서 프로퍼티 변수에 값을 대입할 때 위와 같은 에러가 발생하는 것 같다.

여러가지 종류의 값을 받을 수있는 튜플을 사용해서 해결했다.

만약 각각의 함수안에서 에러 처리를 하지 않은 상태라면

async let 변수 = try async 함수 를 한 후에

let _ = try await [변수1,변수2,...] 이런식으로 할 경우

각각의 에러 처리는 어떻게 해야 좋을지 고민했는데 아직 해결방안을 떠올리진 못했다.

새로 알게된 개념1

• cell의 특정 객체 이벤트 발생 시 화면 전환

FeedCell에서 대화 버튼 클릭하면 navigation stack을 통해 CommentController Scene을 보여 주려고 한다.

FeedCell의 타입은 UICollectionViewCell이다. 상위 View는 collectionView이다. 그래서 UICollectionReueableView 타입에 속하는데 이는 UIView 타입이다. 즉 UINavigationController를 상속받지 않았기 때문에 pushViewController(:aninamted:) 사용할 수 없다. 또한 UIViewController의 present(:animated:) 메소드도 사용할 수 없다. 결국 FeedCell에서 화면을 전환하는 경우는 FeedCell을 호출하는 FeedController의 힘을 빌려야 한다.

이벤트는 FeedCell의 @objc func didTapCommnet(_:)에서 발생한다. 어떻게 FeedController의 UIViewController나 UINavigationController의 객체를 빌려서 화면 전환을 할 수 있을까?

현재 생각할 수 있는 해결 방법은 두 가지이다.

1. delegate 채택해서 FeedController에 FeedCell의 델리게이트 채택.

2. Combine사용해서 publiser의 published 흐름에 따른 화면 전환.

3. delegate 사용의 경우

• 프로토콜 추가

• FeedCell에 변수를 추가.

• FeedCell에서 델리게이트 변수를 통한 함수 사용.

델리게이트 타입의 의존성을 갖는 delegate변수를 선언한 후 didTapComment(_:) 함수에서 프로토콜의 함수를 사용한다.

• FeedController에 프로토콜 채택 후 구현.

이제 화면 전환 할 로직은 FeedController에서 FeedCellDelegate프로토콜 채택 후 구현하면 된다.

• FeedController의 collectionView(_:cellForItemAt:)에서 각 셀마다 delegate 자신으로 등록

2. Combine 사용의 경우

• FeedCell에서 publiser와 anyCancellable 선언

• FeedCell에서 publisher에게 published.

• FeedController의 collectionView(_:cellForItemAt:)에서 각 셀마다 cell에서 publiser의 input stream 구독.

• 코드정리

FeedController의 collectionView(_:cellForItemAt:) 에서 코드가 길어지기 때문에 cell의 메서드로 뺐다.

FeedController에선 그냥 함수 호출만하면된다.

컴바인을 사용하는 것과 델리게이트 프로토콜을 채택하는 것 둘다 비슷한 개념인 것 같다. 중요한 것은 cell 내부 클래스에선 화면 전환을 할 수 없다는 개념을 새로 알게 됬다.

근데 컴바인을 사용했을 때 위와 같은 에러가 발생했다. 화면 몇 번 내린 후에 셀의 메세지 버튼을 클릭할 때 재사용큐 보다 빨리 터치가 되는 것 같다.

재사용 큐로 꺼내지기 전에 있는 포스트 cell로 들어 갔다가 뒤늦게 재사용 큐에 의해 꺼내진 cell로 인한 포스트가 갱신되는 것 같다. 그래서 또 대화 창으로 들어가진다. subscribeFromDidTapPublisher에서 들어갈 때마다 기존 didTapPublisher의 값을 다시 nil 처리를 했다.

새로 알게 된 개념2

텍스트를 입력하기 위한 TextField와 버튼을 view로 만들었을 때 inputAccessoryView에 내가 커스텀한 UIView(TextField와 버튼이 있는)를 입력한다.
inputAccessoryView는 nil이다. 커스텀으로 정의한 뷰를 system에서 지원해주는 input view로 부착하기 위해서는 inputAccessoryView를 재 정의해서 UIResponder에서 읽고 쓸 수 있게 해야 한다.

Responder

UIResponder는 UIKit app에서 이벤트 처리의 뼈대이다. 많은 키 오브젝트는 responder다.(such as UIApplicaiton, UIViewController, UIView) 이벤트가 발생하면 UIKit는 앱의 responder 인스턴스를 다룰 수 있게 발송해준다.

• 이벤트?

touch event, motion event, remote- control evetn, press event가 대표적으로 있다. 특정 타입의 이벤트를 다루기 위해선 responder가 특정 메서드와 일치하게 오버라이드 해야 한다. 그 예로 터치 이벤트에선 responder를 구현하기 위해서는 touchesBegan(:with:), touchesEnded(:with:) 등 메서드를 구현해야 한다. 터치를 예로 들자면 responder는 이벤트 정보를 UIKit에서 제공 받고 터치나 앱의 인터페이스를 알맞게 업데이트하기 위해 추적하고 바꾼다.

이벤트 헨들링은 UIKit responder들이 또한 앱에서 앞으로 처리되지 않을 이벤트 또한 관리한다. 주어진 responder가 이벤트를 처리하지 않는다면 responder chain 의 다음 이벤트를 처리할 수 있게 호출한다. UIKit는 responder chain을 동적으로 관리한다. 미리 정의된 규칙들을 사용해 어느 object가 다음 이벤트를 받을 지 결정한다.
그 예로 view는 자신의 superView로 이벤트를 호출하고, 계층구조의 root view 연결된 viewController로 이벤트를 호출한다.

Responder는 UIEvent object를 처리한다. 근데 커스텀 input. input view 또한 처리할 수 있다. system's keyboard가 input view의 가장 명백한 예제이다.

input view란?

사용자가 화면에서 UITextField 또는 UITextView object를 tap할 때, The view becoms the first responder and display its input view. 뷰는 최초 responder가 되고 input view를 화면에 띄운다. 여기서 input view는 system keyboard이다. 유사하게, 커스텀 input view를 만들고 다른 responder가 activate될 수 있을 때 화면에 출력할 수 있다. resopnder를 통한 input view를 커스텀하고 연결시키려면 inputView 프로퍼티의 responder를 뷰에 할당하면 된다.

다시 말해 Responder는 raw event data를 받고 다른 이벤트를 처리하거나 다른 responder object에게 호출한다. 앱에서 이벤트를 받는다면 UIKit 은 자동적으로 가장 적절한 responder object에게 이벤트를 지시한다. 그 예로 first responder가 있다.

만약에 UITextField에서 이벤트 처리를 하지 못한다면 UIKit은 이벤트를 text field의 부모인 UIView object에게 전달한다.( UIWindow인 루트 뷰에서 파생된,,) root view에선 responder chain으로 다이렉트로 root view인 UIWindow에게 이벤트를 전달하기 전에!! UIView와 연결된 UIViewController에게 event를 전달한다. 만약 window 또한 이벤트를 처리할 수 없다면 UIKit는 UIApplication object에게 이벤트를 전달하고 아직 responder chain의 일부가 아니라면 app delegate에게 전달한다.

Controls

컨트롤은 action message를 사용해서 target 를 통해 연결된 object와 direct하게 소통한다. 컨트롤을 통해 사용자의 상호작용이 일어날 때, 컨트롤은 action message를 자신의 target object에게 전달한다. action message는 이벤트가 아닌데, 여전히 responder chain을 활용할 수 있다. target object의 control이 nil인 경우에 UIKit는 target object로부터 시작해서 resopnder chain을 통해 적절한 action method를 취할 수 있는 object를 찾을 때까지 chain에 연결된 객체들을 찾아간다.

Gesture

Gesture recognizer는 뷰에서 터치와 입력 이벤트 받을 수 있다. 연속적인 터치로 인해 view's gesture가 인식 실패 한다면, UIKit은 뷰에게 터치를 보낸다. 뷰가 터치에 대한 처리를 하지 못한다면 UIKit는 responder chain으로 통과시킨다.

여러 Response chain 중 현재 상태에서 이벤트를 가장 먼저 받는다면 Frist Responder가 된다. 그 예로 텍스트 필드를 누르고 타이핑 할 경우 First Responder는 Textfiend이다. 만약 textfield에서 이벤트에 대한 처리를 하지 않는다면(못한다면) Resopnder chain에 의해 다른 responder로 넘긴다.

inputView, inputAccessoryView

위에서도 설명했지만 inputView는 Frist Responder가 될 때 인데 대표적으로 system keyboard다. UITextField, TextView가 First Responder가 됬을 때 자동으로 나온다. 그래야 텍스트 필드를 입력할 수 있기 때문,, 근데 inputView는 get-only 프로퍼티인데 오버라이딩한다면 커스텀 input view사용이 가능하고 그렇다는건 텍스트 필드를 클릭한 후 First Responder가 되었을 때 알림을 통한 기능이나 picker 등 다양하게 다른 UIView타입의 object를 호출 할 수 있다는 말이다.

---

autoresizingMask = .flexibleHeight 이걸 선언할 경우 superview의 크기, 바운스 등에 따라 높이가 자동적으로 조정된다. ( in CommentInputAccessoryView.swift )

[Clone/Instagram] SignUp 구현 | 복습 & 새롭게 알게된 개념 #4

초기 구현 영상

까다로웠던 점

• 사용자 로그인 생성컨트롤에 관해

View에서 이미지 추가하기 위한 photo plus를 UIImageVIew로 설정했다. 그리고 제스쳐를 추가 등록했는데 이상하게도 sender가 올바르지 않다는 에러가 났다. 그래서 버튼에 이미지를 추가하는 방식으로 해결했다.

• TextField에 대해서

바인딩을 직접 구현 후에 전부 값이 들어있을 경우 버튼의 .isEnable true처리해야하는데 바인딩 함수 호출 이후에 값을 VM에 넣은 뒤에 전부 값이 들어있는지의 함수를 호출했었어야 했는데 값 있는지 체크하는 함수부터 호출하는 바람에 살짝 애를 먹었다. 학교 공부하고 하루 지나고 보니 단번에 에러를 수정할 수 있었다.

코테 구현할 때도 그렇고 가끔은 너무 코드만 바라보면 생각보다 쉬운 답도 못 찾는것 같다.

복습한 개념

• clipsToBounds옵션

RegistrationController에서 이미지 피커로 선택된 이후에 이미지 선택 버튼의 cornerRadius를 해당 버튼의 절반으로 둥글게 조절했다. 그럼에도 사진은 여전히 ImagePicker의 edited된 네모였다. 아하,, 버튼의 clipsToBounds 옵션을 true로 바꾸지않아서 내부의 View가 잘리지 않았던 것..(깜빡)

• withRenderingMode(.alwaysTemplate)

이미지의 색 대신 내가 직접 이미지의 색을 정할 수 있다.

새롭게 알게된 개념

• 커스텀 뷰의 super.init(frame:) 에 관해서

UIView관련된 객체를 커스텀할 때 항상 궁금했었다. 반드시 override init(frame: CGRect) 를 구현해서 super.init(frame:frame)으로 frame을 넘겨줘야 하는 코드를 구현했어야 init가 가능했었다. 내 맘대로 매개변수 생성자 함수를 지정해도 어차피 super.init()은 없고 super.init(frame)이나 .init(coder:)를 호출해야 했었어서 난 매번 함수를 통해 커스텀 뷰들의 옵션을 부여했었다.

이번 강의를 통해 내가 커스텀으로 init()을 선언해도 반드시 부모 생성자 함수를 호출해야하는데 이때 super.init(frame: .zero) 값을 준 후에 다시 size를 정의하면 된다는 것을 새롭게 알았다 +_+

새로 적용한 개념

아직 컴바인을 배우지 않아서 클로저로 textField바인딩을 할 수 있도록 새로 만들었다. 원래는 TextField의 바인딩만 적용하면 됬는데 복습겸 VM에서 값 변경시 TextField에 반영되도록 Dynamic 타입을 구현했다.

강의 보기 전 Login에서 로그인 버튼 isEnable관련해서 id pw입력되어야만 터치이벤트가 가능하는 기능을 구현할 때 등록하는 화면에서도 쓰일 것 같아 프로토콜로 처리했다. 강의에서도 비슷하게 했다 .. ㅎㄷㄷ 근데 좀 다른 것은 난 함수 터치 이벤트 함수까지 선언했었다 +_+

Add MVVM Pattern

웹뷰도 한번 슥 구현 했는데 뒤로가기 버튼 적용이 어렵네,,

GoodWeather 초기 UI세팅

강의 계획을 보고 사전에 간단하게 UI세팅.
lottie 사용해봄.

[Clone/Instagram] 로그인 기능 구현 | 복습 & 새롭게 알게된 개념 #6

Login, Logout기능 구현

구현 영상

강의와는 다르게

• 회원가입 진행완료시에 파베에 업로드하는 과정이 시간이 걸리고 로그인 시에도 대기시간이 있어서 간단하게 인디케이터로 과정을 표시했다.

• 회원가입을 해도 로그인을 직접 해야만 인스타그램 계정이 활성화 되도록 했다.

• 매인 홈 뷰(first vc == Feed Scene)에서 파이어베이스의 최근 유저 auth가 없을 경우에 로그인 화면으로 presnt 되는데 이 과정에서 이미 만들어져 있는 Feed Scene가 보인 후에 로그인 Scene가 present됬다. 추가적인 처리를 해서 Feed Scene가 보이도록 구현했다.

약간 의아했던 점은 강의 보기전에 난 로그아웃시에 로그인 기능을 Auth.auth.signIn(withEmail:email:password:) 을 바로 로그인 컨트롤러의 로그인에 현재 동적으로 바인딩된 vm을 이용해서 로그인 기능을 구현했는데 강의에서는 굳이,,?
Auth.auth.signIn(withEmail:email:password:) 이 메서드를 한번 감싸서 AuthService 클래스 함수로 구현해줬다.

새로 알게된 개념

초기에 사용자 회원가입을 할 때 Auth.auth()의 createUser함수를 통해 firebase의 Authentication 에 email, password를 등록하고 UID를 부여받았다. 이 덕에 파이어베이스에는 사용자의 이메일과 비번 그에따른 유일한 식별자 UID를 Authentication에 저장한다. UID를 통해 Firestore DB 컬랙션의 문서를 식별이 가능하고 필드값도 얻을 수 있다. (파이어베이스를 써서,, 상당히 간편했다. 백엔드의 입장에서 나중에 배워보고싶은 마음이 들었다.)

이 때문에 Auth.auth() 를 통해서 signIn할수도, signOut을 할 수 있다. 그리고 signIn을 한 경우 Auth에 특정 식별자가 기록이 되는 것 같다. 이 정보는 Auth.auth().currentUser를 통해 확인할 수 있다. 앱을 종료했다가 다시 실행해도 Auth에 저장된 currentUser는 Auth.auth().signOut()를 하기 전까지 계속해서 유지 된다.

// 추가로 구현해야할것

• 간단한 커스텀 알림창

[AutoLayout/DemoStackView] issues

BindingMVVM textChanged 다루기

[Clone/Instagram] FeedCell 초기 UI 구현 | 복습 & 새롭게 알게된 개념 #2

FeedCell 초기 UI구현

cell의 디자인을 보고 강의 보기 전에 혼자 구현해봤다. 강의에선 오토레이아웃을 사용하기 편하게 UIView를 Extension했다. 하지만 AutoLayout 복습도 할겸 그냥 anchor로 AutoLayout을 구현했다.

까다로웠던 점

tableView와 달리 collectionView는 cell의 width의 길이에 따라 많은 cell이 한 line에 올 수도 단 한개의 cell이 한 라인을 차지할 수 있음을 알게 되었다. width는 view의 width로 하면 되는데 height가 문제였다. collectionView(: cellForItemAt:) DataSource 메서드가 실행되기 이전에 collectionView(:layout:sizeForItemAt:)가 실행되어서 height를 지정하기 애매했다. 다이나믹한 cell의 height 설정 방법을 고민하고 있다.

복습한 개념

• UIImageView contentMode

ScaleToFill : UIImageView크기와 같게 이미지 size 늘어남

ScaleAspectFit : 이미지 원본 비율 유지하며 UIImageView의 size에 맞게 이미지를 확장

ScaleAspectFill : 비율 유지하면서 view의 size에 맞게 이미지 채운다.

• ContentCompressionResistance

cell의 크기는 정해져있고 vertical로 5개정도의 subView를 추가했다. imageView의 크기가 상당히 클수 있기에 그 아래에 존재하는 subView들은 가려지게 되었다. 그래서 contentCompressionResistance 우선순위를 줄여 이미지 뷰 아래에 존재하는 subView들의 각자 intrinsic size는 챙기고 imageView의 height를 감소하도록 했당..

새롭게 알게된 개념

• ClipsToBounds

View의 bounds에 의해 subview들이 clip(잘리다)될 수 있는지 의미

• UIView의 frame과 bounds 차이

frame.origin은 superView에 의해 결정되고 bounds.origin은 순수 View자체에 기준을 갖는다.

frame.size는 View가 차지하는 영역을 사각형으로 감싼 값이 들어간다. ( 유동적으로 바뀐다.)

bounds.size는 View자체 순수 size다.