테이블뷰 headerview, section, indexPath를 이용한 뷰 구성 주의할 점.

[Youngminah]

사전지식

• 여러가지 케이스를 살펴보기 앞서 한가지 개념을 확실히 하고 가자
• 뷰의 위계(계층)와 데이터의 위계(계층)가 같아야 유지 보수 및 코드를 이해하기가 더 좋다❗️❗️
• 즉, 뷰의 위계와, 데이터 위계는 스파게티식이 아닌, 체계적 구성을 하여야 한다.

만약 광고가 있는 배너

어떻게 뷰를 구성하는 것이 좋을까?

• 광고배너는 보통 가장 위에 수평 스크롤뷰로 (테이블뷰 관점에서) 반복되지 않는 구성이 된다.
• 헤더뷰로 구성하는 것이 적합할 수 있다.

section 또는 indexPath로 구성한다면 어떠한 문제점이 있을까?

• 유지보수 관점에서 보았을 때, 좋은 구성은 아닐 수 있다.

• indexPath로 구성하는 것은 피하자!

  • 테이블뷰 입장에서 반복되지 않는 배너 한 부분을 위하여 , tag를 달고,
  • 테이블뷰 프로토콜 함수를 불러올 때마다 if-else case를 나누는 코드를 추가하여야한다. ( 코드의 중복성 )
  • 데이터 위계 관점에서 보았을때, if - else의 데이터 위계는 같지 않다.
  • indexPath로 위계를 같게 구성하는 것은 유지보수 관점에서 Cost로 작용될 수 있다. ❗️

• section로 구성을 할 때

  • section으로 나눌 때는 뷰의 위계와 데이터 위계가 과연 관련이 있는지 생각을 해보아야한다.

  • 위계가 관련이 있다면 좋은 구성일 수도 있다는 말!

  • 예를 들어, 아래 사진은 다른 section의 구성 모두들 별 상관이 없는 이유로 나뉘고 있다.

    • 
    • 이러한 경우는 각각의 section이 별 상관이 없는 이유로 나뉘고 있다는 section들만의 공통점이 생긴다!
    • 그렇다면 배너 광고 또한 맨위에 오늘의 광고처럼 section을 이용하여 추가하여도 위계가 같아지는 것..!
    • 한마디로 section으로 구성하여도 좋다!

  • 또 다른 경우를 살펴보자

    • 
    • 위의 사진 같은 경우 광고 배너는 가장위에 딱한번 구성되어있고,
    • 밑에는 모두 음식점과 관련된 구성이 된다.
    • 이러한 경우, section으로 구성하는것 보다 헤더뷰로 구성하는 것이 적합하다.
    • (물론 스크롤이 되는지 UI적으로 우선적 확인해보아야함. 아니라면 UIView로 테이블뷰 바깥에 같은 위계로 구성)
    • 코드 중복성을 줄이며, 직관적 분류가 가능하기 때문.

• 결론 ⭐️

  • headerview, section, indexPath를 구성할 때에는,
  • 맨처음 UI적으로 확인이 필요하지만,
  • UI에서 눈으로 확인 할 수없는 구성에 관한 부분에서는 스스로 생각을 하여야 한다.
  • 그런데 네이버 iOS 개발자님 피드백에 따르면,
  • 유지보수에서 큰 Cost로 작용하지 않기 위해,
  • 뷰의 위계와, 데이터 위계는 스파게티식이 아닌, 체계적 구성을 하여야 한다.라고 피드백을 주셨다.
  • 위 부분을 생각하지 않고 구성을 할 경우,
  • 댓글의 대댓글, 댓글의 대댓글 selfsizing 과 같이 조금만 복잡해져도
  • 유지보수 관점에서 보았을 때 스파게티식 뷰 구성이 나올 수 있다.