LEEO TIL Dev Log

튜플의 비교 튜플은 이름없는 구조체 라고도 하죠. 튜플이 같은지 비교하는 방법은 간단합니다 == 기호를 써줍니다. 여러 예제를 통해 비교해 보도록 하겠습니다. let temp1 = ( 2 , 4 ) let temp2 = ( 2 , 4 ) let temp3 = ( 3 , 4 ) let temp4 = ( top : 2 ,bottom: 4 ) print (temp1 == temp1) // true print (temp1 == temp2) // true print (temp1 == temp3) // false print (temp1 == temp4) // true 당연히 자기 자신과 비교 하면, 같다 라는 결과가 나옵니다. 값을 비교하는 연산자 이기 때문이죠. 그리고 다른 변수에 할당 하더라도 값이 같으면 true 의 결과값이 나옵니다. 그리고 (2,4)와 (3,4)는 같지 않기 때문에 false 가 출력되는 것을 볼 수 있습니다. 또한 tuple은 element의 이름을 지정할 수 있는데, 두 튜플이 같다고 해서 elemene의 이름까지 같음을 보장하지는 않습니다. 그러므로 temp4와 temp1이 다른 element 이름을 가지고 있어도, 같은 튜플로 인식합니다.

Result 타입은 Swift5에 추가되었습니다. 그렇다면 왜 추가되어야 했는지 Result 타입이 없었을 때는 어떤 문제가 있는지 알아보면서 Result에 고마움에 대해 알아보도록 하겠습니다. Result가 없는 세상 Result 타입은 네트워크 요청 쪽에서 많이 사용되었습니다. 예를 들면 아래와 같은 상황에서 말이죠. import Foundation func getData <T: Decodable> (urlString: String, completion: @escaping (T?) -> Void ) { let url = URL (string: urlString)! URLSession .shared.dataTask(with: url) { data, response, error in if let error = error { return completion( nil ) } guard let data = data else { return completion( nil ) } guard let response = response as ? HTTPURLResponse , response.statusCode == 200 else { return completion( nil ) } guard let parsedData = try ? JSONDecoder ().decode( T . self , from: data) else { return completion( nil ) } completion(parsedData) }.resume() } URLSession.shared.dataTask 에서 요청한 응답 중 에러를 처리하려면, 정상적인 케이스와 정상적이지 않은 케이스들을 구...

개념의 차이 가장 쉽게 예를 들 수 있는 개념의 차이는 엑셀파일과 구글 스프레드 시트 입니다. 두 파일 다 문서를 같게 작성할 수 있는 문서 편집이 가능한 도구입니다. 내가 작성한 엑셀파일을 저장해서 상대방에게 전달 하면, 같은 내용의 파일이 하나 더 생겨서 전달이 됩니다. 이 때, 상대방이 전달받은 파일을 수정해도 독립적으로 수정되어 수정본이 생기는 것일 뿐 내가 작성한 내용이 변경되지는 않습니다. 이렇게 값을 전달해서 주는 타입을 value type 이라고 합니다. 반면에 구글 스프레드시트를 작성하고, 링크를 전달해서 상대방에게 전달 한 뒤, 상대방이 수정하면 어떻게 될까요? 상대방화면에서 수정된 내용이 그대로 내 눈앞에 보이는 화면이 실시간으로 변경되고, 결국 이전에 작업했던 내용은 없어진 수정된 내용만 남게 됩니다. 이렇게 주소값을 전달 해주는 타입을 reference type 이라고 합니다. class와 struct class의 인스턴스는 reference type 입니다. 그렇기 때문에 인스턴스를 생성하고, 다른곳에서 수정하면 원래 사용되고 있었던 곳에서도 다 영향을 받게 되죠. 그리고 struct의 인스턴스는 value type 입니다. 인스턴스를 생성해서 사용하고, 다른곳에 전달해서 수정해도 원래 사용되고 있었던 곳에서는 영향을 받지 않습니다. 추가적으로 closures는 reference type 입니다. 그렇기 때문에 원하는 값을 사용하기 위해서 capture를 해야하죠. 그렇지 않으면 계속 값이 바뀔테니까요!

정의 UUID는 U niversally U nique ID entifier의 약자입니다. 직역 해보자면, 범용적인 고유 식별 아이디 입니다. 즉 유일한 값입니다. 그렇다면 이 유일한 값은 어떻게 만들어지고, 어느 범위까지 사용할 수 있는 것 일까요? 내용 내용은 위키 를 참고해서 정리 해 보있습니다. 8-4-4-4-12 의 포맷의 16진수로 만들어진 ID입니다. 생성 방법에 따라 버젼이 존재하며, 각 버젼은 아래와 같은 방법으로 생생된다고 합니다. 버전 1 (시간 + MAC 주소) 버전 2 (시간 + DCE 보안) 버전 3 (네임스페이스 + MD5 해시) 버전 4 (랜덤) 버전 5 (네임스페이스 + SHA-1 해시) 그렇다면, 우리가 사용하는 let uuid = UUID() 는 어떤 방법을 사용하는 것 일까요? 정확한 내용은 애플의 문서 에도 설명되어 있습니다. init() - Initializes a new UUID with RFC 4122 version 4 random bytes . 네 버젼4, 랜덤 방식을 사용한다고 합니다. 그렇다면 나올 수 있는 경우의 수는 16의 32승 가지가 되겠네요, 같은 숫자가 나올 확률은 16의 32승의 제곱 분의 1 . 물론 불가능 한 확률은 아니지만 거의 0에 가까운 확률로 같은 UUID를 생성할테니 랜덤 방식으로 만들어도 고유 식별 아이디가 생성된다고 봐도 무방할 듯 싶습니다.

String type 은 Collection 프로토콜을 채택했기 때문에, 문자열은 컬렉션입니다. 라고 말할 수 있습니다. 이것이 의미하는 바는, Collection 타입이 가지고 있는 프로퍼티와 메소드들을 사용할 수 있습니다. 예를들면 startIndex , isEmpty 와 같은 프로퍼티, index(_ i: Self.Index, offsetBy distance: Int, limitedBy limit: Self.Index) -> Self.Index? 와 같은 메소드 입니다. Collection 프로토콜은 원소들을 순회하는 연속성을 가지고 있습니다. 기본적으로 Sequence 프로토콜을 채택하고 있기 때문입니다. 하지만 Sequence 프로토콜과 다른점은, 순서대로만이 아닌 임의 key, index 값을 가지고 접근할수 있습니다. 또한 처음부터 끝까지 돌아가는게 아닌, 중간부분부터 얻을 수 있습니다.

범위 연산자 범위를 나타내는 여러가지 방법이 있습니다. closed range operator 0...5 // [0, 1, 2, 3, 4, 5] half-open range operator 0..<5 // [0, 1, 2, 3, 4] one-sided range operator ...5 // ?? 특정 조건에서는 one-sided ranges 를 사용할 수 있습니다. 에를 들면 아래의 코드 같은 경우 입니다. let friends = [ "Leeo" , "Jonh" , "Tim" , "Lisa" , "Mons" ] let member = friends[..< 3 ] // "Leeo" , "Jonh" , "Tim" 활용 배열을 잘라서 사용해야 할 떄, 일부분을 자르는게 아닌, 처음부터 어디까지 혹은 어디부터 끝까지 자를 떄 활용하면 편리합니다. 어디서 부터 시작인지, 어디까지가 끝인지 명시하지 않아도 잘리기 때문이죠.

테이블 뷰를 그리는데 매번 정형화된 데이터는 JSON 이었습니다. 그래서 이번에는 XML Parser를 이용해, RSS를 읽어오는 Reader를 만들었습니다. 앱 구조 테이블 뷰, 한 개의 화면으로 이루어진 앱 입니다. 기능 또한 심플합니다. rss요청에 대한 응답을 받아와 파싱해서 읽을 수 있게 나열해주는 것 입니다. 앱 구현 순서 구체적으로 나열하지 않아도, 여태까지 앱을 만들었던 순서는 항상 아래와 같았습니다. 앱을 여려개 만들다 보니 나름의 공정과정이 생긴 것 같습니다. 와이어 프레임 및 동선구현 - 네비게이션 뷰, 상세, 팝업 페이지 구현 UI구현 - 필요한 뷰와 셀들을 구현해둡니다. 버튼을 배치 합니다. 모델링 - 내가 필요한 데이터를 모델링 하고, 목 데이터를 만듭니다. 기능 구현 - 목 데이터를 가지고 필요한 기능을 구현합니다 네트워크 - 실제 필요한 데이터를 API를 통해 가져옵니다. 에러 처리 - 네트워크 요청에 대한 실패 케이스를 정리해줍니다. 기타 화면 작성 - 로딩 뷰, 데이터 없음, 에러 페이지 작성 리팩토링 - 내가 작성한 코드가 읽기 쉽고, 확장성 있게 만들어 줍니다. 마무리 테이블 뷰와 관련된 앱만 여러개 만들다 보니 이제 좀 익숙 해졌습니다. 앱의 기초라 할 수 있는 테이블 뷰의 활용 방법에 대해 더 정리할 수 있는 기회가 있다면 다른 글에 적어놓도록 하겠습니다. 전체 코드는 github 에 올려놓도록 하겠습니다.