SwiftUI by Example - free quick start tutorials for Swift developers
SwiftUI란 무엇인가?
- SwiftUI는 선언적 방식으로 앱을 디자인 할 수 있는 사용자 인터페이스 툴킷입니다.
명령형 UI (Imperative UI)
- 버튼을 클릭할 때 함수를 호출 할 수 있고 함수 내부에서 값을 읽고 레이블을 표시한다.
- 정기적으로 사용자 인터페이스의 모양과 동작을 변경해야 한다.
- 명령형 UI는 모든 종류의 문제를 일으키는데 대부분의 문제는 상태(코드에 저장한 값)를 기반으로 발생합니다.
- 코드의 상태를 추적하고 사용자 인터페이스가 해당 상태를 올바르게 반영하는지 확인해야합니다.
- UI에 영향을 주는 두 개의 Bool 속성이 있는 화면에서 Bool은 4가지 상태가 된다.
- 만약 Bool 속성이 3개 라면? 아니면 다섯? 혹은 Bool이 아닌 Int, String, Date 등이라면? 훨씬 더 복잡해질 것이다.
선언적 UI (Declarative UI)
-
선언적 UI를 사용하면 iOS에 가능한 모든 앱 상태를 알릴 수 있습니다.
-
로그인 한 경우 시작 메시지를 보여주고, 로그아웃 한 경우 로그인 버튼을 보여주게 할 수 있습니다.
-
이 두 상태 사이를 이동하는 코드를 직접 작성할 필요가 없습니다.
-
대신 SwiftUI는 상태가 변경 될 때 UI 레이아웃 간에 이동하게 합니다.
-
사용자가 로그인 했는지 또는 로그아웃 했는지에 따라 무엇을 보여줄지 미리 정해 놓습니다.
-
그래서 우리가 인증 상태를 바꿀 때 SwiftUI는 우리 대신에 UI를 업데이트 할 수 있습니다.
-
SwiftUI 구성 요소를 표시하고 숨기는 것을 직접할 필요가 없습니다.
-
iOS, macOS, tvOS 및 심지어 watchOS에서 작동하는 교차 플랫폼 UI 레이어의 역할도 합니다.
-
즉, 이제 하나의 언어와 하나의 레이아웃 프레임워크를 익히고 어디서든 코드를 배포 할 수 있습니다.
-
"선언적"패러다임에서 사용자 인터페이스는 이를 나타내는 일부 데이터의 함수로 "선언"됩니다.
-
이 데이터를 “상태” 라고 합니다 .
-
상태가 변경되면 UI가 자동으로 업데이트됩니다.
-
예상치 못한 결과나 일관성없는 결과를 방지하여 모든 다른 상태들이 한 곳에서 설명됩니다.
-
그로 인한 효과
- 복잡성 크게 감소
- 더 적은 코드
- 향상된 코드 품질
- 개발 시간 단축
SwiftUI vs Interface Builder and storyboards
-
storyboard 또는 XIB 파일의 코드를 직접 편집하기란 매우 어려운 일이다.
-
storyboard 수정으로 풀 요청을 할 때 스토리 보드와 XIB에 문제가있는 경우 변경된 사항을 보는 것은 기본적으로 불가능합니다.
-
storyboard 또는 dequeue table view cells에서 뷰 컨트롤러를 생성 할 때 문자열을 사용하여 코드에서 중요한 객체를 식별합니다. (문자열 형식의 API)
-
그럼에도 불구하고 Swift는 반환 된 테이블 뷰 셀이 실제로 MooncakeTableViewCell이라는 사실을 알 수 없기 때문에 타입캐스팅(typecast)을 사용해야합니다.
-
IB와 스위프트는 서로 매우 독립적이기 때문에 이러한 문제가 발생합니다.
-
SwiftUI가 어떻게 작동하는지 정확히 알게 될 것입니다. 지금 당장은 SwiftUI가 이전 Swift + Interface Builder 접근 방식으로 발생하는 많은 문제점을 보완할 수 있다는 점만 알면 됩니다.
-
SwiftUI는 우리에게 동시에 두 가지를 제공하기 때문에 프로그래밍 방식이나 스토리 보드 기반 디자인에 대해 더 이상 논쟁 할 필요가 없습니다.
-
storyboard, XML 보다 코드를 읽고 관리하기가 훨씬 쉽기 때문에 더 이상 사용자 인터페이스 작업을 할 때 소스 제어 문제를 만들지 않아도됩니다.
-
문자열 형식의 API에 대해 더 이상 걱정할 필요가 없습니다. 일부는 있지만 상당히 적습니다.
-
Swift 컴파일러가 사용자 인터페이스를 검사하기 때문에 더 이상 존재하지 않는 함수를 호출 할 필요가 없습니다.
SwiftUI에 관해 자주 묻는 질문들
SwiftUI와 UIKit 중에 어느 것을 배울 것인가?
- 현재 iOS 앱의 압도적인 다수는 UIKit을 사용하여 작성되었습니다.
- 따라서 SwiftUI를 1 년, 2 년 또는 그 이상 무시한다고 하더라도 당신을 위한 일자리 부족은 없을 것입니다.
- 어느 누구도(심지어 애플도) iOS 커뮤니티가 빠른 속도로 SwiftUI로 마이그레이션 할 것이라고 기대하지 않습니다.
- 많은 코드와 많은 시간, 그리고 많은 돈이 UIKit 앱에 투자되었습니다.
SwiftUI는 어디에서 사용할 수 있습니까?
- SwiftUI는 iOS 13, macOS 10.15, tvOS 13 및 watchOS 6 또는 향후 플랫폼의 모든 버전에서 실행됩니다.
- SwiftUI를 Java의 Swing 또는 React Native와 유사한 다중 플랫폼 프레임 워크로 생각하지 않는 것이 중요합니다.
- 공식적으로 SwiftUI는 다중 플랫폼 프레임 워크가 아니라 여러 플랫폼에서 애플리케이션을 만드는 프레임 워크 입니다.
- 그건 똑같은 소리 일지 모르지만 중요한 차이가 있습니다.
- Apple은 모든 플랫폼에서 동일한 SwiftUI 코드를 사용할 수 있다고 말하지 않습니다. 일부 기능 만 가능하기 때문입니다.
- 예를 들어 Mac에서 Apple Watch의 디지털 크라운을 사용할 수있는 방법이 없으며 마찬가지로 watchOS 앱의 탭 막대를 사용하면 작동하지 않습니다.
SwiftUI가 UIKit을 대체합니까?
- 아닙니다. SwiftUI의 많은 부분은 UITableView와 같은 기존 UIKit 구성 요소 위에 직접 구축됩니다.
- 물론 다른 많은 부분은 그렇지 않습니다. UIKit이 아닌 SwiftUI에 의해 렌더링 된 새로운 컨트롤도 존재합니다.
- UIKit에 어느 정도 관련되어 있는지는 중요하지 않습니다.
- SwiftUI는 UIKit의 동작을 거의 완전히 가려줍니다.
- 그래서 SwiftUI로 앱을 작성하고 나서 Apple이 2년 후에 UIKit을 어떻게 바꾸던지 걱정할 필요가 없습니다.
- Apple이 무엇을 어떻게 바꾸던지 SwiftUI와 UIKit에 동일한 메소드 및 속성과 호환 가능하게 만들면 코드가 변경되지 않습니다.
SwiftUI는 오토레이아웃이 적용됩니까?
- 오토레이아웃이 확실하게 scene 뒤에서 어떤 용도로 사용되는 동안, SwiftUI 디자이너인 우리에게 노출되지 않았습니다. ❓
- While Auto Layout is certainly being used for some things behind the scenes, it’s not exposed to us as SwiftUI designers.
- 대신 웹에서 오는 개발자에게 친숙한 유연한 박스 레이아웃 시스템을 사용합니다.
SwiftUI는 빠른가요?
- SwiftUI는 놀라 울 정도로 빠릅니다. 지금까지의 모든 테스트에서 UIKit을 능가하는 것으로 보입니다.
- 그것을 만든 팀과 이야기를 나눈 후 이유를 알게 되었습니다.
- 그들은 적극적으로 레이어 계층 구조를 평평하게하므로 시스템은 그리기 작업을 덜하게 됩니다.
- 많은 작업이 Core Animation을 완전히 우회하여 추가 속도를 위해 Metal로 곧장 이동합니다.
코드와 preview가 얼마나 일치합니까?
- 미리보기를 변경하면 생성 된 코드도 업데이트됩니다. 마찬가지로 코드를 변경하면 사용자 인터페이스도 업데이트됩니다.
- 따라서 코드와 미리보기는 동일하며 항상 동기화 상태를 유지합니다.
UIKit은 이제 끝인가요?
- 아니요! 애플은 이번 주 WWDC에서 방영되는 새로운 UIKit 기능을 방대한 규모로 갖고 있습니다.
- Apple이 UIKit의 새로운 기능에 대해 WWDC의 회담을 계속하고 있다면, 당신은 매우 안전합니다. 놀랍게도 은퇴 할 위험은 없습니다.
SwiftUI 및 UIKit에서 view를 혼합 할 수 있습니까?
- 네. 각각 서로를 내부에 내장 할 수 있으며, 그것은 훌륭하게 작동합니다.
UIKit에서 SwiftUI로 마이그레이션
-
이전에 UIKit을 사용 해왔다면, 당신이 알고 있고 좋아하는 많은 클래스는 UI 프리픽스를 없애기 만하면 SwiftUI에 해당하는 클래스에 직접 매핑됩니다.
-
그렇다고해서 그들이 똑같은 기능을 가졌음을 의미하지는 않습니다.
-
다음은 SwiftUI 이름 뒤에 UIKit 클래스 이름을 사용하여 시작할 수있는 목록입니다.
- UITableView: List - UICollectionView: SwiftUI 해당 사항 없음 - UILabel: Text - UITextField: TextField - UITextField (isSecureTextEntry가 true로 설정된): SecureField - UITextView: SwiftUI 해당 사항 없음 - UISwitch: Toggle - UISlider: Slider - UIButton: Button - UINavigationController: NavigationView - UIAlertController (스타일이 .alert인 경우): Alert - UIAlertController (스타일이 .actionSheet인 경우): ActionSheet - UIStackView (가로축): HStack - UIStackView (세로축): VStack - UIImageView: Image - UISegmentedControl: SegmentedControl - UIStepper: Stepper - UIDatePicker: DatePicker - NSAttributedString: SwiftUI와 호환되지 않습니다. 대신 Text를 사용하십시오.
-
SwiftUI에 독점적 인 다른 많은 구성 요소가 있습니다. 예를 들어 가로 또는 세로가 아닌 깊이로 물건을 만들 수있는 스택보기가 있습니다. (
ZStack
)
댓글