Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Team1 iOS 잭슨 & 롤로] 레이블, 마일스톤 화면 구현 #35

Open
wants to merge 104 commits into
base: team-1
Choose a base branch
from

Conversation

eeeesong
Copy link

@eeeesong eeeesong commented Jun 21, 2021

안녕하세요! 이슈트래커 1팀 롤로입니다 :)
2주차 구현 내용에 대한 PR을 요청드립니다🙂 이번에도 잘 부탁드립니다!


구현 내용

기능

  • 레이블 & 마일스톤 목록, 레이블 추가하기 UI 구성
  • API 연동: GET / POST / PUT / DELETE

레이블 관련

  • Hex Color Code의 UIColor 변환 & 배경색에 따른 텍스트 컬러 변경 로직 구현

마일스톤 관련

  • 완료일 Label을 사용자의 UITextFiled input에 따라 변하도록 NSPredicateRegex를 이용해서 Check 하여 완료일 라벨 색상을 유동적으로 변경

리팩토링

  • View 재사용을 위한 View 요소 Subclassing
    • LabelView: 이슈 화면에서의 재사용을 위한 분리
    • InputStackView: 레이블, 마일스톤 화면에서 공통 사용
  • ViewController 재사용을 위해 필요한 Operation을 지정해줄 수 있도록 함
    • 새 레이블 추가 / 기존 레이블 수정 시 같은 뷰컨트롤러 사용하되, 완료 시 POST or PUT 할 수 있도록 클로저를 넘김
    • 기존 사용하던 ViewController subclassing 방식에서 변경, Subclassing 비용을 줄이고 코드를 간소화 함
  • TableViewDelegate 재사용
    • 레이블, 마일스톤 Swipe 메뉴에서 동일한 메소드 사용
  • 유저 로그인 정보에 싱글톤 패턴 사용
    • 지난 PR 피드백을 반영하여 싱글톤 패턴을 사용하여 리팩토링하였습니다

구현 화면

레이블

  • 레이블 조회 및 추가 & 수정 & 삭제

마일스톤

  • 마일스톤 조회 및 추가 & 수정 & 삭제

eeeesong and others added 30 commits June 14, 2021 16:10
- 레이블 테이블 셀 생성
- 배경색상에 맞춰 title 색상을 흰색 or 검정색으로 표시
- 재사용을 위해 request manager 생성
- 레이블 탭 진입 시 네트워크에서 레이블 목록 불러오도록 구현
- 확장성을 고려한 Enum 타입으로 구축
- 레이블 컬러 버튼 터치 시 레이블 컬러 변경
@ChocOZerO
Copy link

아 중간에 load하시면 그전의 코멘트를 보실수 있습니다.

저희가 분업하다가 합쳐서 dev/iOS 브랜치를 이용하다보니
이번 2차 PR이후에 과정이 그대로 담겨져 버렸네요.. ㅜ

이렇게 되면 PR마다 남기는 코멘트가 합쳐져서 혼동이 있을거 같아요. 저도 어떤게 변경됐는지 파악할 수 없어요. 기존에 merge된 브랜치를 기준으로 rebase를 하거나 현 브랜치에 merge해서 PR을 다시 만드는게 좋을 것 같습니다.

@JacksonPk
Copy link

네 지금은 다른 브랜치를 이용하고 있습니다. 어제 분업한 내용을 이 PR 브랜치 말고 다른 브랜치에서 했어야 했는데 이런 파급효과를 가져올지 몰랐네요..
수정을 하게 되면 알려드리도록 하겠습니다. 신경써주셔서 감사합니다 초코!

crongro pushed a commit that referenced this pull request Jun 25, 2021
* 유틸 폴더에 추가하였다.
* 네개의 컴포넌트에서 함께 사용한다.
crongro pushed a commit that referenced this pull request Jun 25, 2021
crongro pushed a commit that referenced this pull request Jun 25, 2021
crongro pushed a commit that referenced this pull request Jun 25, 2021
* 체크박스를 상위 부모로 옮겼다.
crongro pushed a commit that referenced this pull request Jun 28, 2021
crongro pushed a commit that referenced this pull request Jun 28, 2021
crongro pushed a commit that referenced this pull request Jun 28, 2021
crongro pushed a commit that referenced this pull request Jun 28, 2021
crongro pushed a commit that referenced this pull request Jun 28, 2021
crongro pushed a commit that referenced this pull request Jun 28, 2021
@JacksonPk
Copy link

JacksonPk commented Jun 28, 2021

코드에서 전반적으로 두부분이 눈에 밟혔습니다.

  1. thread 컨트롤은 모여있는게 관리하기 좋습니다. 함수마다 불려지는 thread에 의해 main thread로 보내는 작업을 하기보다. thread가 분리되는 이유를 파악해보면 컨트롤을 집중시킬 수 있다는걸 발견할 수 있을겁니다. -> 함수 내에서 독자적으로 main thread로 보내는 코드가 있다면 thread 관리가 제대로 되지 않다고 생각하고 고쳐보세요.

초코 2번에 대한 질문이 있습니다.
Thread 컨트롤에 대해서 말씀 주신 부분을 이해하려고 노력해보았으나 아직 제대로 이해가 되지 않습니다.
저희가 GCD를 사용한 경우는 모두 UI 업데이트에 관한 쓰레드 이기에(ex, delegate, reloadDate, present) 모두 main.async를 사용해야 해서 특정함수마다 스레드가 필요하다고 생각했습니다.
스레드를 관리한다는것이 따로 쓰레드관리하는 클래스를 만들어서 UI 업데이트가 필요한 곳에서 해당 클래스를 불러 큐에 넣는다는 식? 으로 접근을 해야하는 건가요?
아직 명확하게 어떤방법으로 접근해야하는지 잘 모르겠습니다. 답변주시면 감사하겠습니다.

UI 업데이트에 관한 내용을 main 쓰레드로 보내는건 피할 수 없습니다.
view 관련 클래스에 있는 함수에서 어떤건 main으로 보내야 하고 어떤건 main으로 보내지 않아도 되는건 왜일까요?
함수 작성을 할때 이 함수는 main에서 불려야한다는걸 코드 작성시에 알 수 있을까요?
왜 main으로 보내는 코드가 필요하게 됐을까?

위의 대답들을 고민해보면서 접근하면 좋을 것 같네요. 고민의 시간을 좀 더 드리겠습니다 ㅎㅎ

안녕하세요 초코.
과정이 끝났지만 초코가 질문한 것에 해답을 더 알아보고싶어서 남겨드립니다.
쓰레드와 GCD에서 한번 다시 보게 되었고, UI 업데이트관련은 메인쓰레드의 Serial 큐를 통해서 이용한다는점은 이해했습니다.
하지만 아직 헷갈리는 부분이 모두 UI업데이트를 위해 쓰레드를 사용했고 Controller를 이용했다는 점인데 쓰레드 분리 및 관리를 어떻게 해야 Thread 관리가 이루어진다는 것인지 잘 이해가 안돼서 다시한번 여쭈어봅니다.

@ChocOZerO
Copy link

코드에서 전반적으로 두부분이 눈에 밟혔습니다.

  1. thread 컨트롤은 모여있는게 관리하기 좋습니다. 함수마다 불려지는 thread에 의해 main thread로 보내는 작업을 하기보다. thread가 분리되는 이유를 파악해보면 컨트롤을 집중시킬 수 있다는걸 발견할 수 있을겁니다. -> 함수 내에서 독자적으로 main thread로 보내는 코드가 있다면 thread 관리가 제대로 되지 않다고 생각하고 고쳐보세요.

초코 2번에 대한 질문이 있습니다.
Thread 컨트롤에 대해서 말씀 주신 부분을 이해하려고 노력해보았으나 아직 제대로 이해가 되지 않습니다.
저희가 GCD를 사용한 경우는 모두 UI 업데이트에 관한 쓰레드 이기에(ex, delegate, reloadDate, present) 모두 main.async를 사용해야 해서 특정함수마다 스레드가 필요하다고 생각했습니다.
스레드를 관리한다는것이 따로 쓰레드관리하는 클래스를 만들어서 UI 업데이트가 필요한 곳에서 해당 클래스를 불러 큐에 넣는다는 식? 으로 접근을 해야하는 건가요?
아직 명확하게 어떤방법으로 접근해야하는지 잘 모르겠습니다. 답변주시면 감사하겠습니다.

UI 업데이트에 관한 내용을 main 쓰레드로 보내는건 피할 수 없습니다.
view 관련 클래스에 있는 함수에서 어떤건 main으로 보내야 하고 어떤건 main으로 보내지 않아도 되는건 왜일까요?
함수 작성을 할때 이 함수는 main에서 불려야한다는걸 코드 작성시에 알 수 있을까요?
왜 main으로 보내는 코드가 필요하게 됐을까?
위의 대답들을 고민해보면서 접근하면 좋을 것 같네요. 고민의 시간을 좀 더 드리겠습니다 ㅎㅎ

안녕하세요 초코.
과정이 끝났지만 초코가 질문한 것에 해답을 더 알아보고싶어서 남겨드립니다.
쓰레드와 GCD에서 한번 다시 보게 되었고, UI 업데이트관련은 메인쓰레드의 Serial 큐를 통해서 이용한다는점은 이해했습니다.
하지만 아직 헷갈리는 부분이 모두 UI업데이트를 위해 쓰레드를 사용했고 Controller를 이용했다는 점인데 쓰레드 분리 및 관리를 어떻게 해야 Thread 관리가 이루어진다는 것인지 잘 이해가 안돼서 다시한번 여쭈어봅니다.

UI업데이트는 main 에서 처리합니다. 그렇다고 모든 View 객체내의 메소드에서 main으로 보내는 코드가 필요할까요?
메소드를 작성할때마다 이 함수가 어느 thread에서 불리는지 알 수 있을까요?
만약에 뷰가 재사용된다면, 그 뷰도 동일한 함수는 항상 동일하게 메인 쓰레드로 보내는 처리를 해야할까요?
여기에 대한 답은 전부 NO 입니다.

그렇다면 이건 어떻게 처리할 수 있을까요?
스레드를 왜 main으로 보내야할까요?
기존 코드에선 메인으로 보내는 코드가 없이 뷰를 컨트롤했는데 왜 갑자기 이런 코드가 필요하게 된걸까요?

그건 main에서 벗어나 다른 스레드로 보내는 코드가 생겼기 때문입니다.
네트워크 통신이라는 비동기 환경이 생겼기 때문이죠.
네트워크 통신 객체가 스레드를 변경시키는 행위를 했습니다. 이건 다른 객체에서 알 수가 없어요. 그렇기때문에 네트워크 통신 객체 스스로가 자신이 책임지고 컨트롤 할 수 있다면 다른 객체에 스레드를 관리하는 책임이 전파되지 않을 수 있습니다.
그렇게 된다면 뷰객체에선 기존처럼 스레드와 상관없이 자신에게 필요한 책임과 역할만 다하면 됩니다.

이렇게 작업이 되면, 어떤 사람은 통신모듈을 만들고, 어떤사람은 뷰를 만들고 이런식으로 역할 분담하기도 좋습니다.
언제 어느 타이밍에 불릴지 신경쓰지 않고 필요한 행위만 코드에 담으면 되기 때문이죠.

이해 안되는 부분이 있다면 추가 질문은 언제든 환영입니다 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants