UINavigationController의 구성요소가 떠오르지 않는 사람을 위한 글

-

한 화면으로 이루어져 있는 앱을 만들다 보면, 다른 기능을 새로운 화면에 구성하고 싶은 생각이 듭니다. 이럴 때 필요한것이 화면 전화이죠. 화면 전환에는 여러가지 방법이 있으나, 그 중에 하나인, 가장 기본적이고 많은 기능을 제공하는 NavigationBar의 구성요소와 기능들에 대해 알아보도록 하겠습니다.

정의 및 구성요소

UINavigationBar는 UINavigationController라는 컨트롤러에 의해 제어됩니다. UIViewController를 상속받아 구현되어 있기 때문에 UIViewController가 가진 요소들을 가지고 있습니다. 가장먼저 UINavigationController에 대해 먼저 알아보겠습니다.

class UINavigationController : UIViewController

UINavigationController는 하나의 뷰 컨트롤러가 아닌 여러개의 뷰 컨트롤러의 계층을 만들고 관리 해주는 컨트롤러 입니다. 사용자가 상세화면이나 상위에 있는 화면이라고 생각하게 만들어주죠. 아래의 이미지를 보면서 생각해봅시다.

UINavigationController

첫 화면에서 General버튼을 누르면, General 페이지로 이동됩니다. 그려먼 화면의 타이틀이 바뀌고, 이전 페이지로 돌아갈 수 있는 버튼이 생기죠. 실제 화면이 쌓이고, 사라지는 순서를 관리하는 navigation stack이 있습니다. 네비게이션의 첫 뷰 컨트롤러는 스택의 root인 root view controller가 됩니다. 즉 네비게이션 컨트롤러는 root view controller인 뷰컨트롤러가 필요하죠.

NavigationBar

화면의 순서는 stack이 관리하지만, 사용자가 이 스택을 조종하기 위한 인터페이스로 UINavigationBar가 있습니다. UINavigationBar의 구성 요소는 위의 그림과 같습니다. 일반적으로 화면의 가장 상단에서 화면의 계층을 나타내 줍니다. 이전화면은 어디서 왔는지, 내가 할 수 있는 행동은 무엇인지, 이 페이지가 어디인지를 타이틀 등을 활용해서 나타내줍니다. 이미 사용경험이 많은 UI라 익숙하죠?

NavigationOverView

위 그림은 UINavigationController를 머리에 담을 때 가지고 있으면 좋은 전체의 큰 그림입니다. UINavigationController는 여러개의 뷰 컨트롤러들을 navigation stack을 통해관리하죠! 그리고 각 뷰컨트롤러들의 전환을 UINavigationBar를 이용해서 하게 됩니다.

필요하다면 toolbar를 UIToolbar를 이용해 구현할 수 있습니다. 그 이외에 델리게이트로 이벤트 들을 핸들링 할 수 있습니다.

다음으로는 각각의 요소들이 무슨기능을 할 수 있는지 알아보도록 하겠습니다.

NavigationController은 뷰 컨트롤러의 컨테이너 뷰 컨트롤러 입니다. 즉 화면에 보이는 뷰 컨트롤러를 네비게이션 컨트롤러가 감싸고 있습니다. 이게 전부가 아닙니다. 네비게이션바, 그리고 선택적으로 툴바도 있습니다. 이 모든 것들을 조립해서 관리합니다.

NavigationOverView

화면이 바뀌면 덩달아, 네비게이션 바도 업데이트가 되어야 하고, 툴바 또한 업데이트가 되어야 합니다. 사용 했던 경험을 생각해보면, 상세페이지로 넘어갔는데 title이 바뀌지 않는다면 이상함을 느낄테니까요.

UINavigationController의 구현체를 조금 살펴보겠습니다.

  • pushViewController
    • navigationstar에 뷰컨트롤러를 push 합니다.
  • popViewController
    • navigationstar에 뷰컨트롤러를 pop 합니다.
  • viewControllers
    • 현재 viewControllers를 가리킵니다.
  • navigationBar
    • 네비게이션바를 지칭합니다.
  • isNavigationBarHidden
    • 네비게이션바의 보임 여부를 나타냅니다.
  • toolbar
    • 툴바를 지칭합니다.
  • isToolbarHidden
    • 툴바의 보임 여부를 나타냅니다. 기본은 숨김입니다.

이 외에 무엇이 있고, 어떤 기능을 하는지 한 번쯤은 살펴보는 것이 좋다고 느끼고 있습니다. 실제 코딩을 할 때, 저런 프로퍼티와 메소드가 있는지도 모르고 구현했던 경험이 많습니다. 나중에는 내가 필요한 건 이미 있지 않을까 하는 생각이 먼저 들기 시작했고, 그래서 이런 글을 써서 정리하고 있습빈다.

NavigationController안에 보면, NavigationBar과 NavigationItem 둘 다 있습니다. 이 부분이 계속 헷갈리고 네비게이션 바를 제대로 사용하지 못하게 되는 원인이라 확실하게 스스로 가지고 있는 궁금증을 정리하려고 합니다.

1. 언제 NavigationBar를 써야하고 언제 NavigationItem를 써야하나요?

navigationController?.navigationBar.backgroundColor = UIColor.white
navigationController?.navigationBar.isTranslucent = false

navigationItem.hidesBackButton = true
navigationItem.leftItemsSupplementBackButton = true
navigationItem.leftBarButtonItem = backButtonItem

보통 위와 같은 코드를 많이 보아서, 언제 무엇을 써야하는지 헷갈립니다. 왜 이런 코드들이 나오는지를 알기 위해서 navigationController 구현체를 뜯어보면, 아래쪽에 UIViewController의 extension이 있습니다.

extension UIViewController {
    open var navigationItem: UINavigationItem { get } // Created on-demand so that a view controller may customize its navigation appearance.

    open var hidesBottomBarWhenPushed: Bool // If YES, then when this view controller is pushed into a controller hierarchy with a bottom bar (like a tab bar), the bottom bar will slide out. Default is NO.

    open var navigationController: UINavigationController? { get } // If this view controller has been pushed onto a navigation controller, return it.
}

네비게이션 바를 사용할 때, 다른 뷰와는 달리 subview를 추가하는 방법이 아닌, navigationItem을 사용해야 합니다. 이게 무슨말이냐면, 자유롭게 원하는 걸 추가하는것이 아닌, 이미 정해진 곳에만 네비게이션 바를 커스터마이징 할 수 있다는 뜻 입니다. 그래서 navigationItem.leftBarButtonItem 이라는 정해진 위치에 넣게 되는거죠. 참고로 searchController도 navigationItem에 있습니다. 그러므로 네비게이션에 서치바를 넣으려면 아래와 같이 해주면 되겠죠?

let searchController = UISearchController(searchResultsController: nil)
self.navigationItem.searchController = searchController

정리해보면, 네비게이션 바의 틴트 색상이나, 배경색과 같이 바 자체의 모양이과 외형에 대한 값을 설정할 때는, navigationBar를 사용하고, 네비게이션 바의 기능 동작을 위한 새로운 아이템을 추가하고 기능을 구현할 때는 NavigationItem에 rightBarButtonItems나 leftBarButtonItems에 커스텀한 버튼들을 넣어우어 해결할 수 있습니다.

2. UINavigationBar에는 어떤 것들을 설정할 수 있나요?

UINavigationBar의 인스턴스입니다. UIView를 상속했습니다. 블로그를 읽을 때 왜 무엇을 상속했는지 써둔 내용을 별 의미없이 넘겼었는데, 나중에 돌아보니 어떤 프로퍼티가 있고 메소드가 있습니다를 다 정리하면 한 문장으로 OO를 상속했습니다가 되는구요. 그 후로는 어떤 클래스를 상속했는지 유심히 보고 있습니다.

NavigationBar

  • barStyle
  • isTranslucent
  • topItem
  • backItem
  • prefersLargeTitles
  • tintColor
  • barTintColor
  • setBackgroundImage()
  • titleTextAttributes
  • largeTitleTextAttributes

등이 있습니다. 위의 값을 가져오거나 설정해야 할 일이 있을 때 NavigationBar를 사용합시다.

3. NavigationItem에는 어떤 기능이 있나요?

  • title
  • titleView
  • backBarButtonItem
  • backButtonTitle
  • hidesBackButton
  • leftBarButtonItem
  • rightBarButtonItem
  • largeTitleDisplayMode
  • searchController
  • hidesSearchBarWhenScrolling

와 같은 기능이 필요할 때 사용합니다. 좀 더 자세한 내용은 직접 코드에서 구현체를 살펴보는 좋을 것 같습니다.

정리

네비게이션컨트롤러 및 뷰 컨트롤러에서, 네비게이션바를 설정하거나, 네비게이션 아이템을 추가할 때 항상 헷갈렸는데 이번 기회에 코드를 다 한번씩을 살펴보면서 어떤 요소들이 구현되어있는지 살펴보았습니다. 필요한 기능을 찾아서 구현하는 것도 좋지만, 내가쓰고있는 SDK가 어떻게 구현되어 있는지 보는것도 다른 설계를 위해 필요하다고 생각합니다. 잘못된 내용이나, 첨부할 만한 내용은 댓글 혹은 이메일로 보내주시면 감사하겠습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[IOS] AppDelegate는 뭐하는 녀석이지?

-
이미지
[IOS] AppDelegate AppDelegate.swift 는 swift로 IOS 개발을 시작하면서 부터 보였고, 계속 궁금해서 이 기회에 정리해놓으려한다. 공식문서 참고 UIApplicationDelegate AppDelegate.swift 크게 두가지 기능을 한다. AppDelegate 클래스를 정의 어플리케이션이 그려질 window를 생성하고, 상태가 변할 때 반응 할 수 있게 한다. 또한 AppDelegate 클래스는 UIApplicationDelegate 프로토콜을 채택해야한다. 앱에 대한 진입 점과 입력 이벤트를 앱에 전달하는 실행 루프를 생성 이 작업은 파일 상단에 나타나는 UIApplicationMain 의 특성이다. (@UIApplicationMain)에 의해 수행된다. 하지만 IOS13부터는 AppDelegate.swift , SceneDelegate.swift 두 파일로 나뉘어 생긴다. 그렇기 때문에 여러 소스를 보았을 때 혼란을 야기했다. 이전에는 (~ IOS12) 아래와 같은 구조였다. AppDelegate Process Lifecycle App Launched App Terminated UI Lifecycle Entered Foreground Become active 하지만 지금은 (IOS13) 아래와 같다. Session Lifecycle에 대한 역할이 추가되었다. AppDelegate Process Lifecycle Session Lifecycle Session Created Session Discarded SceneDelegate UI Lifecycle Entered Foreground Become active AppDelegate 클래스에 있던 프로퍼티인 window가 SceneDelegate로 옮겨졌다. 하지만 하나의 화면에서 여러개의 다중 화면을 지원하면서 scene 개념이 추가...
자세한 내용 보기

[git] Github 이슈 라벨(issue labels)

-
이미지
[dev] Github issue labels Github에서 프로젝트의 문제점을 알리거나 기여를 할 때 이 issue label을 달거나 읽어야 할 일이 생긴다. 해당 이슈에 알맞은 라벨을 선택하고, 의미를 파악하기 위해 알아두자. keyword 의미 bug 예기치 않은 문제 또는 의도하지 않은 동작(버그)을 나타냅니다. documentation 문서를 개선하거나 추가 할 필요가 있음을 나타냅니다. duplicate 해당이슈 또는 PR이 기존에 있음을 나타냅니다. enhancement 새로운 기능 요청을 나타냅니다. good first issue 처음 기여해볼 사람에게 좋은 문제를 나타냅니다. help wanted 관리자가 문제 또는 PR 요청에 대한 도움을 원함을 나타냅니다. invalid 이슈 또는 PR 요청이 더 이상 관련이 없음을 나타냅니다. question 이슈 또는 풀 요청에 추가 정보가 필요함을 나타냅니다. wontfix 문제 나 PR 요청에서 작업이 계속되지 않음을 나타냅니다. 참고 : https://help.github.com/en/github/managing-your-work-on-github/about-labels
자세한 내용 보기

[git] git의 upstream과 origin 헷갈리는 사람 손!

-
이미지
[git] git의 upstream과 origin git의 upstream과 origin upstream과 downstream 사전적인 의미를 파악해보면, upstream 이 상류, downstream 이 하류입니다. 물이 상류에서 하류로 흐르듯이 pull 하는 주최가 downstream 당하는 쪽이 upstream 입니다. 내 레포에서 다른 레포를 풀 해서 작업하고 있다면 다른 레포가 업스트림이 되겠군요! otherRepository(upstream) -> (git pull) myRepository(downstream) 이미지 출처 : https://aktiasolutions.com/upstream-kanban-business-agility/ upstream과 origin 그렇다면 업스트림과 오리진은 어떤 차이가 있는지 정리 하겠습니다. 보통은 다른 레포를 포크해서 내 레포를 만들어 놓고 내 레포를 클론, 풀 해서 작업합니다. 이때 가장 근본이 되는 레포를 upstream 이라고 부릅니다. 내가 fork해서 가져온 레포를 origin이라고 부릅니다. 그러므로 내가 로컬에 클론 해 놓고 작업할 때, origin/master에서 가져올지, upstream/master에서 가져와야 할지 생각해서 가져와야겠죠? otherRepository(upstream) -> (fork) myRepository(origin) otherRepository(upstream) -> (git pull) myRepository(local) myRepository(origin) -> (git pull) myRepository(local)
자세한 내용 보기