iOS에서 개발한 View의 레이아웃에 대한 생각

9634 단어 iOS

경향


팀을 개발할 때 포석에 대한 생각이 분산되어 있기 때문에 여러분의 의식을 통일시키기 위해 일정한 방침을 고려했습니다.
참고로 여기서 말하는 포석은 디자인적인 것이 아니라 실제 개발할 때 화면을 어떻게 만드는지 의미의 포석이다.
그나저나 무슨 문제가 생겼는지...
  • 어떤 뷰의 위치를 바꾸면 다른view도 변한다
  • ViewController에 모든 View에 대한 레이아웃 처리가 촘촘히 적혀 있어 힘들다
  • 방침.


    화면의 배치를 고려할 때 아래의 방침에 따라 설계한다.
  • View 간 계층 고려
  • 계층화된 View를 사용자 지정 View로 처리
  • 다음 레이어까지 레이아웃을 결정하는 View
  • 1. 뷰 사이의 계층을 고려한다


    "차원화된 뷰를 사용자 정의 뷰로 처리하려면", "판면 디자인을 결정할 수 있는 것은 단지 하나의 차원 아래의 뷰"를 먼저 고려해야 한다.
    뷰 사이의 계층을 고려할 필요가 있다.
    뷰 간의 등급을 고려하기 위해 뷰를 그룹화합니다.
    예를 들어 점화기의 캡처를 사용하게 해 주세요.
    아래 그림을 만들 때 쓴다고 가정해 보세요.
    (아저씨와 오른쪽 상단에 있는 메인 아이콘이 없다는 뜻)

    1.1 첫 번째 그룹


    화면 전체의view(view Controller의view)가 먼저 큰 그룹이 될 것 같습니다.
    검은 테두리에 둘러싸인 부분입니다.이것이 BaseView라고 가정하십시오.

    1.2 2차 그룹


    다음은 크게 녹색 뷰와 빨간색 뷰, 파란색 뷰로 나눌 수 있다.
    각각 다음과 같다.
  • 그린→SerifView
  • 레드→CharacterTypew
  • 블루→StartView

  • 이럴 때는 다음과 같은 계층이 있다고 볼 수 있다.

    1.3 세 번째 그룹


    녹색 뷰(SerifView)에서는 주황색 및 분홍색 뷰로 나눌 수 있습니다.
  • 주황색→TextView
  • 핑크→ExpView
  • 같은 빨간색 View(CharacterType View)는 다음과 같은 몇 가지로 나눌 수 있습니다.
  • 퍼플→TitleView
  • 라이트 블루→FamousLabelView
  • 황록색→FamousCheckView
  • 노란색→MyWorld LabelView
  • 화이트→MyWorldCheckView

  • 이때 친자 관계는 다음과 같다.

    그룹을 나눌 수 없을 때까지 상기 내용을 반복합니다.
    예에서 스스로 포착에 색칠을 했지만 실제 개발할 때는 노트에 그림을 그린다.
    이런 느낌.

    2. 계층화된 View를 사용자 정의 View로 처리


    기본적으로 아이가 있는 뷰는 사용자 정의 뷰여야 합니다.
    이번 사례로 세리프뷰와 CharacterTypew는 각각 UIView반을 계승해 사용자 정의 반을 만들었다.
    이렇게 하면BaseView는 SerifView,CharacterTypew,StartView만 가져오면 됩니다.
    즉, BaseView는 TextView와 TitleView가 좋아질지 모른다는 것이다.
    BaseView.m
    // TextViewやTitleViewを持つ必要がない
    [self addSubView:serifView];
    [self addSubView:characterTypeView];
    [self addSubView:startView];
    
    기본 보기의 차원은 다음과 같다.

    3. 배치를 결정할 수 있는 뷰는 다음 레이어입니다.


    안 되는 일

  • 형제가 다른 형제의 판식을 결정한다

  • SerifView.m
    // 兄弟が別の兄弟のレイアウトを決める
    // そもそもStartViewを参照できるのもおかしいけど
    self.startView.frame = (0,0,self.view.frame.width,self.view.frame.height);
    
  • 아이가 부모의 포석을 결정한다

  • CharacterTypeView.m
    // 子が親のレイアウトを決める
    // そもそも参照できるのもおかしいけど
    self.baseView.frame = (0,0,self.view.frame.width,self.view.frame.height);
    
  • 부모가 손자의 포석을 결정한다

  • BaseView.m
    // 親が孫のレイアウトを決める
    // そもそも参照できないように設計するべき
    self.textView.frame = (0,0,self.view.frame.width,self.view.frame.height);
    // とか
    self.serifView.textView.frame = (0,0,self.view.frame.width,self.view.frame.height);
    

    할 수 있는 일

  • 부모가 아이의 포석을 결정한다
  • BaseView.m
    // serifViewはBaseViewの子なのでこれはOK
    self.serifView.frame = CGRectMake(0,0,self.view.frame.width,self.view.frame.height);
    
    이번 예를 들어 BaseView는 SerifView,CharacterTypew, StartView의 판면 디자인만 결정할 수 있다.
    아래 그림은 BaseView에서 본 레이아웃이 가능한지 여부입니다

    SerifView에서 볼 수 있는 레이아웃의 가부 여부는 다음과 같다

    방침에 따른 이점

  • 1층 아래 뷰만 관리하고 손자의 뷰를 바꾸면 부모와 아이의 뷰를 파괴하지 않는다
  • 부모의 코드 완성(손자의 레이아웃이 사라져서)
  • 총결산


    팀 개발에서 뷰 레이아웃과 관련해 이번처럼 의식적으로 층구조를 설계해 책임과 의무가 계층별로 나뉘어 유지보수가 용이한 코드가 됐다.

    좋은 웹페이지 즐겨찾기