swift

뷰와 데이터 관련한 것은 분리하도록 하자. 역할을 분리해서 함수를 작성하자. UIViewController + UITableView UITableViewController만 사용할 수 있으면 얼마나 편할까? 그러나 UITableViewController를 사용하는 경우에는 좀 더 유연한 화면 구성이 어렵다. 이미 화면 전체가 테이블뷰로 가득 차 있어 영역의 크기 조정이 어렵기 때문이다. (이 말인 즉슨 RootView가 UITableView라는 것이다.) 그렇기에 TableView만 따로 올려서 화면을 구성하는 경우가 더 많다. TableView 생성 + 아웃렛 연결 TableViewCell 생성 (프로토타입 셀, XIB 이용) + 셀 클래스 연결 + 아웃렛 연결 TableView에 필요한 프로토콜 선언..

그 동안 막연하게도 타입 어노테이션(명시)가 컴파일 속도가 더 빠르다고 생각했던지라 아무 생각 없이 타입 명시를 하는 습관을 들이고 있었다. 그러나 최근 듣고 있는 교육 과정에서 멘토님께서 타입 추론을 하는 것이 더 나아보인다라는 말씀을 해주셨고, 왜인지 궁금했던지라 여쭤보게 되었다. 답변 주신 것으로는 컴파일러의 성능이 점점 더 개선되고 있고, 타입 추론이 컴파일 속도가 더 빠르다는 실험 결과도 있다고 답변주셨다. 실제로 아래에 첨부한 링크를 보면 간단한 실험 결과를 확인해볼 수 있다. https://forums.swift.org/t/regarding-swift-type-inference-compile-time-performance/49748/2 let a = "hello, world!" // type..

네비게이션 바/탭 바 bottom/top 라인 디폴트로 제공되는 속성은 없다. 커스텀 해야 함. 화면 분기 처리 단순히 2개만 분기가 되는 경우는 값 전달로 분기 처리 가능. 재사용되는 화면이 많아 진다면 열거형을 사용해서 좀 더 유연하게 대응할 수 있음. 네비게이션 타이틀 커스텀 하나만 택해라. 애플 가이드를 지키거나, 아예 새로 만들거나! 애플의 시스템 형태 그대로를 사용한다면 커스텀이 사실상 어려움. 커스텀 영역은 UIView를 가지고 개발자가 직접 다 바꾼 것이라고 보아도 무방. Navigation Title 부분을 UIView로 대체할 수 있음 titleView 프로퍼티 이용 라벨에 inset 간단한 방법으로는 텍스트 좌우에 여백을 넣어서 해결 가능 글자 수의 범위가 고정적이거나 일정하다면 Co..

App Bundle, ipa .app bundle 앱 번들을 이용한 빌드에 대해서 진작에 알았다면 어땠을까? 이전에 다른 사람들의 프로젝트를 다운받아서 사용성 테스트를 해야 하는 일이 있었는데 프로젝트 패키지 인덱싱을 하는 시간이 너무 오래 걸려서 테스트하는 데 반나절 이상 시간을 썼던 기억이 있다. 빌드가 되는 앱 번들을 받았다면 좋았을텐데.. 눈물이 난다. .ipa iOS 애플리케이션 아카이브 파일 계정이 붙어 있음. Build 시뮬레이터(Option) 실제 기기(개발자 계정 필요) Debug mode : 개발용 Release mode : 출시 Xcode 단축키 단축키는 시간날 때 정리해서 돌아와야지 option + cmd + [ , ] : 코드 블럭 이동 shift + control + 클릭 : 다..

화면 전환에서 헷갈릴만한 지점 네비게이션 스택 관리 (코드로 화면 전환을 구현할 때 놓치기 쉽다.) 네비게이션 스택으로 관리되다가 중간에 Present된 모달이 나오면 스택이 끊기게 된다. 중간에 새롭게 네비게이션 컨트롤러를 embed해서 전환을 이어나갈 수 있고, 이 시점부터는 새로운 네비게이션 스택이 생기게 된다. 시작점의 중요성 (탭바 컨트롤러, 네비게이션 컨트롤러) 스토리보드에 네비게이션 컨트롤러를 embed 해놓더라도 인스턴스를 가져올 때 주의하지 않으면 원하는 구현을 할 수 없다. 화면 전환하면서 값 전달 전달 받을 화면에 공간 만들기 데이터 전달하기 받은 데이터 가지고 뷰에 표현하기 화면 전달 시 적절하게 변수에 값을 담아보내기 위해서는 다운 캐스팅이 필요하다. (우리가 ViewControl..

옵셔널 바인딩 (Optional Binding) 옵셔널 바인딩 처리된 상수의 범위가 다름 if ~ let guard ~ let 인스턴스 프로퍼티 vs 타입 프로퍼티 UIKit 요소는 모두 클래스이다. 인스턴스 프로퍼티 인스턴스가 생성된 뒤, 내부에 있는 멤버로서 프로퍼티에 접근할 수 있다. 타입 프로퍼티 static 키워드가 붙은 프로퍼티는 인스턴스 자체에서 접근할 수 없다. 변수의 종류 저장, 연산, 감시자 프로퍼티 초기화, 해제 화면이 push 될 때 init(초기화) 됨. 메모리에 올라감. 화면이 pop 될 때 deinit 됨. 메모리에서 내려감. 문자열 관리 휴먼에러 관리 열거형 열거형은 초기화 불가 인스턴스 없음 그렇기에 구조체, 클래스를 사용하는 상황과 구분 필요 컴파일 시점에 에러 탐지 가능..

TableViewCell 데이터 설정 Cell에 데이터를 넣어줘야 하는 경우가 있다. 간단하게 생각을 해보면 CellForRowAt 메서드 단계에서 Cell의 프로퍼티에 접근하여 데이터를 하나씩 넣어줄 수 있을 것이다. 그런데 넣어줘야 하는 데이터가 여러 개인 경우 하나씩 다 넣어주기가 정말 번거롭고 비효율적인 작업이 될 것이다. 이 작업을 Cell에게 대신 부여해서 데이터만 통째로 넘겨주면 Cell이 알아서 UI 요소에 데이터를 넣어주도록 하면 깔끔해질 것이다. 데이터 역시 인자로 하나씩 넘겨줄 수 있겠지만 그 수가 많다면 힘들 것이다. 그래서 구조체 형태로 여러 타입의 데이터를 한 묶음으로 생각해서 데이터를 넘겨주면 편할 것이다. // Model Struct struct Movie { var titl..

1. 아웃렛 컬렉션(Outlet Collection)을 언제 사용하는 것이 좋을까에 대한 고민 단순 요소 반복 또는 동일한 UI 구성, 디자인적 요소를 다룰 때 적합하다고 볼 수 있다. 물론 인덱스를 활용해서 데이터에 접근하거나 변경하는 것도 가능하지만 이후에 UI 구조가 변경되거나 코드를 다시 확인하고자 할 때 어려움이 생길 수 있다. 디자인적인 부분과 데이터적인 부분은 분리가 더 적절할 수 있다. 2. 객체의 선언 위치 (feat. DateFormatter) 함수 내부 클래스 내부 파일 전체 3. TableView Contents Static cell : 형식이 항상 동일함 Dynamic type : 데이터에 따라 컨텐츠가 달라짐, 대부분의 경우 해당 방식을 사용 View Header View Foo..