[iOS] 앱의 화면전환이 항상 헷갈릴 때 보는 글

-




앱을 만들다보면, SingleView App에서 어느새 여러개의 화면전환이 필요한 순간이 오게됩니다. 그런데 화면 전환의 방법과 종류가 너무 많아서 어느 순간에 어떤 화면을 써야하는지 계속 찾계되어 정리하게 되었습니다.

  • 화면 전환할 때, 이전 코드를 복사해서 쓰고있는 사람
  • 다른 사람의 코드를 복사해서 화면전환을 하는 사람
  • 이것 저것 다 해보다가 내가 원하는 결과가 나온사람
  • 미래의 나

가 읽으면 좋을 것 같습니다.

화면전환

화면 전환이란 다른 화면이 등장하는 것을 말합니다. 버튼을 눌렀을 때 혹은 테이블 뷰나 컬렉션 뷰의 셀을 눌렀을 때 다른 화면이 나오는 경우이죠.

보통 많이 사용했던 방법을 나열 해보면 아래와 같습니다.

  1. viewController에서 다른 viewController를 present 해줍니다.
  2. NavigationController에 embed 시켜고 다른 viewController를 push 합니다.
  3. 스토리 보드에서 seque를 이용해서 control키를 누르고 드래그로 나타날 화면을 지정 해줍니다.

모달이나 전체화면과 같은 화면의 종류에 대해서는 이 글에서 다루지 않겠습니다. modalPresentationStyle에 대한 글을 나중에 정리하게 되면 추가 해놓겠습니다.

viewController에서 다른 viewController 부르기

viewController를 만드는 방법에는 저는 보통 2가지를 사용합니다. 코드로 만들거나, storyBoard에 뷰컨트롤러를 그립니다.

코드로 뷰 컨트롤러를 만들었을 때, present의 인자로 내가 만든 viewController의 인스턴스를 넘겨줍니다. 그러면 화면 전환이 일어납니다.

@IBAction func clickPresentByCodeButton(_ sender: Any) {
    let myViewController = MyViewController()
    self.present(myViewController, animated: true, completion: nil)
}

스토리 보드에 만들었을 때는, 스토리 보드에 그려진 뷰컨트롤러에 identifier를 지정해주고 해당 값을 이용해서 불러올 수 있습니다.

@IBAction func clickPresentButton(_ sender: Any) {
    guard let vcName = self.storyboard?.instantiateViewController(withIdentifier: "NewViewController") else { return }
    self.present(vcName, animated: true, completion: nil)
}

결국 뷰컨트롤러를 어떻게 만드느냐의 차이일 뿐, self(viewController)에서 다른 viewController를 persent 해주면 됩니다.

뷰컨트롤러에서 다른 뷰컨트롤러를 호출하면, 뒤로갈 수 있는 버튼이 제공되지 않습니다. NavigationController를 이용하는 이유 중 하나는, 상세 화면에서 뒤로가기를 쓰기 위해서 입니다. 네비게이션 컨트롤러에서 화면 전환을 하면 전환이 된다기 보다는, 화면위에 다른 화면을 올려놓는 느낌이기 때문입니다. 그렇기 때문에 이전화면으로 돌아 가기 쉽죠. 대신 좌측 상단에 뒤로가기 버튼도 생깁니다.

뷰 컨트러에서 화면 전환을 했던 것과 같은 방법으로, 네비게이션 컨트롤러에 embed된 뷰 컨트롤러의 화면 전환을 해줄 수 있습니다.

코드로 작성된 뷰 컨트롤러와, 스토리보드에 작성된 뷰 컨트롤러를 불러와서 화면전환 하는 부분은 윗 부분을 참고해주세요! 여기서는 네비게이션 컨트롤러에서 화면전환을 하면 뷰 뷰컨트롤러만 있을 때와 어떤 차이가있고 공통점이 있는지 보여드리겠습니다.

@IBAction func navigationPushButton(_ sender: Any) {
    guard let pushVC = self.storyboard?.instantiateViewController(withIdentifier: "OrangeViewController") else { return }
    self.navigationController?.pushViewController(pushVC, animated: true)
}

차이점이 보이시나요? 스토리 보드에 있는 뷰 컨트롤러를 인스턴스로 만든 다음에, self가 아닌, self.navigationController에서 pushViewController 해줍니다.

pushViewController 해주려면 navigationController에 viewController가 들어있어야겠죠?

스토리 보드에서 seque

화면 전환을 하는 방법중에는 가장 간단하고 생각합니다. 다만 이 방법을 쓰기 위해서는 storyBoard에 viewController들이 잘 그려져 있어야 한다는 전제조건이 필요합니다.

방법은 간단합니다. 스토리 보드상에서, 버튼을 클릭한 상태에서 control키를 눌러줍니다. 버튼을 다시 눌러주고, 드래그해서 불러 올 뷰 컨트롤러에 드랍 해줍니다. 그러면 뷰 컨트롤러사이에 segue 화살표가 생깁니다. 이 방법을 이용하면, 코드 한 줄 작성하지 않고 화면전환을 할 수 있습니다.

segue를 이용한 데이터 전달방법은 화면전환과는 다른 문제라 이 글에서 다루지는 않겠습니다.

정리

  • 스토리보드 없이
    • 네비게이션 컨틀롤러 없이
      • 코드로 만들어서
        • 뷰컨트롤러 인스턴스 생성
        • self.present
      • 스토리보드에 만들어서
        • self.storyboard?.instantiateViewController
        • self.present
    • 네비게이션 컨트롤러 있이
      • 코드로 만들어서
        • 뷰컨트롤러 인스턴스 생성
        • self.navigationController?.pushViewController
      • 스토리보드에 만들어서
        • self.storyboard?.instantiateViewController
        • self.navigationController?.pushViewController
  • 스토리보드 이용해서
    • segue를 사용해서

참고자료

에밀리의 블로그


댓글

댓글 쓰기

이 블로그의 인기 게시물

[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)
자세한 내용 보기