LEEO TIL Dev Log

좀더 편하게 보시려면 노션링크 를 눌러주세요! 앱을 개발하다보면, 버튼의 이미지를 찾아 헤메이던 시간이 꼭 존재했습니다. 홈 버튼, 설정 버튼에 들어갈 이미지들을 찾는 것이죠. 하지만 지금은 그렇게 시작하지 않습니다. 왜냐하면 SF Symbols를 사용하고 있기 때문입니다. SF Symbols은 wwdc 2019에 소개 되었습니다. 딱 SwiftUI가 소개되던 해이기도 합니다. 그 말은 즉 SF Symbol을 사용하려면, 프로젝트가 iOS 13+ 을 지원해야한다는 뜻 입니다. 물론, 하위 버젼을 분기처리하고 진행하는 방법도 있긴 하지만, 통일성을 위해서 iOS 13 이상의 버젼에서 사용하는 것을 추천 드립니다. 그러면 이 SF Symbol로 무엇을 할 수 있을까요? 심볼 고르기 우리가 사용할 수 있는 심볼은 SF Symbols 라는 앱을 통해서 확인할 수 있습니다. 카테고리 별로 확인이 가능하고, 이름, 그리고 색상을 적용하면 어떻게 바뀌는지도 확인할 수 있습니다. 심볼 그리기 Image (systemName: "mic.and.signal.meter" ) SwiftUI에서는 위와 같은 방법으로 간편하게 심볼을 사용할 수 있습니다. 이미지이기 때문에, .resizable(), .aspectRatio(contentMode: .fit), frame(width:, height:) 를 활용하면 아름다운 심볼을 아주 간편하게 그릴 수 있습니다. 심볼 색칠하기 wwdc2021 에서 심볼에 색을 넣을 수 있는 기능이 추가되었습니다. 이에 더해 SF symbols 4에서는 다중 레이어에 대한 설명이 wwdc2022에 잘 설명 되어있습니다. 그래서 각 레이어 마다 다르게 색상을 적용할 수 있습니다. Monochrome 한가지 색으로 심볼을 적용하는 렌더링 모드입니다. 가장 단순한 방식으로 사용하며, 다른 색상을 적용해도 첫 번째 색상만 적용됩니다. Image ( systemName : " mic .and .si...

보기 좋은 노션링크 입니다. 개발을 하다보면 특히 iOS 개발을 하면 누군가에게 배우는 환경이 쉽지는 않아, 결국에는 독학을 하게 됩니다. 독학을 하다보니 이렇게 하지말껄, 다음에는 이렇게 하면 더 좋겠다 할 만한 내용들을 적어두었습니다. 왜 개발자? 매년 연초에 개발회사 전직원 연봉상승 뉴스는 개발자들 사이에서도 흥미로운 기사입니다. 뿐만 아니라 네카라쿠배당토, 주문같은 단어들도 생겨났습니다. 그래서 그런지 개발자가 되고싶은, 그리고 개발을 배우고 싶은 사람들이 많이 보입니다. 왜 개발자가 되고싶은지 살펴보면 크게 3가지 이유로 보입니다. 높은 연봉 좋은 복지 차오르는 뽕 물론 이런 것을 추구하는게 나쁘다고 생각하지 않습니다. 일을 하면서 돈을 많이 벌고 싶은 것은 너무나 당연한 것이고 좋은 복지와 남에게 자랑할 수 있는 직업을 가지는 것은 기분 좋은 일 일테니까요. 하지만 이렇게 좋은 모습에는 이면이 있습니다. 공부 할 것들이 엄청 많음 빠르게 변하는 기술 매우 큰 스트레스 컴퓨터 공학과의 의미를 담은 전공이 있고 대학에서 4년동안 공부할 만큼의 많은 지식이 필요합니다. 당장 개발 강의에서는 6개월만 공부하면 당신도 개발자! 라는 글을 자주 접하지만 실제 공부를 시작해보면 6개월만에 개발자가 되는 것은 맞지만, 개발자가 된 뒤에도 해야할 공부가 대학 4년치보다 많은 것은 변함없는 사실입니다. 그리고 애플 생태계에서는 매년 WWDC에서 공개되는 수백개의 영상이 있습니다. 매년 새로운 기술, 빠르게 변하는 트렌드는 늘 공부해도 뒤쳐지는 느낌이 듭니다. 눈에 보이지 않는 작업을 머릿속으로 해야하기도 하고, 마감 기한을 맞추기 위해 밤을 새야 하는 일도 자주 일어날 수 있습니다. 또한 업무 시간 이외에도 공부에 많은 시간을 쏟아 붓는 것은 스트레스가 심한 일이죠. 어디로 가야하죠? 막상 개발을 시작했더라도 강의를 하나 정도 다 듣고나면 여러 의문이 생깁니다. 지금 내가 무엇을 해야하지? 이 것을 안하면 어떻게 되지? ...

활용방법 #if문 의 state문 중 하나입니다. canImport() 안에 는 모듈이름이 들어가고, import 할 수 있으면 true를 반환합니다. 특정 코드에서 사용하는 모듈들이 조금씩 다를 때 분기를 해줍니다. 예를 들면 iOS에서는 UIKit을 사용하고, macoS에서는 AppKit을 사용한다면 분기를 해주어야겠죠? 사용에제는 아래와 같습니다. # if canImport(UIKit) import UIKit # endif # if canImport(AppKit) import AppKit # endif

개발을 하면서 개발자가 가장 많은 시간을 쓰는게 변수 명을 짓는 것 이라는 이야기가 있습니다. 이게 그냥 우스갯소리로 나온 것이 아니라, 제 개인적인 경험만 돌아봐도 개발시간의 많은 부분을 변수를 짓고 변수를 어떻게 지어야 하나 고민했습니다. 그 이유는 변수 명에 따라 그 이후의 개발 속도가 달라지기 때문입니다. 그래서 지금 짓는 변수에 많은 고민을 하고 시간을 소요하게 되었습니다. 글로는 알기 어려우니 예를 들어서 코드로 설명해 보겠습니다. 불명확한 이름이 가져오는 참사 틀리지는 않았지만 불명확한 이름이 가져오는 참사는 다음과 같습니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let number = getSomeNumber( with : numbers) 함수의 이름이 getSomeNumber 이라서 어떤 숫자가 반환될지 알기가 어렵습니다. 그래서 우리는 이 함수가 어떻게 생겼는지 알아보러 가야합니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let number = getSomeNumber(with: numbers) func getSomeNumber (with numbers: [Int]) -> Int ? { // ..... some code return numbers.first } 이렇게 보았을 때, 함수가 어떻게 동작하는지 내가 분석을 하고 반환값을 보고 나서야 변수 이름을 지을 수 있습니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let firstNumber = getSomeNumber(with: numbers) func getSomeNumber (with numbers: [Int]) -> Int ? { // ..... some code return numbers.first } 영어 문법에 맞는 이름 변수 이름을 영어로 짓기 때문에, 문법에 맞지 않는 이름은 의미가 불명확하게 전달 될 수 있습니다. 그렇기 때문...

관련주제 : Swift 난이도 : 하 디버깅 디버깅 모드에서 내 코드가 정상동작하는지 확인하기 위한 함수 입니다. 예를 들면, average = total / count 가 있을 때 count 가 0이 될 수 있다면 문제가 발생합니다. 그 상황을 디버깅 하기 위해서 물론 출력을 해도 됩니다. if count == 0 { print("0이 되었습니다") } 하지만 너무나 불편하기 때문에, assert(count != 0, "0이 되었습니다") 로 좀 더 의도를 명확히 할 수 있습니다. assert 함수를 어떻게 쓸 수 있는지는 공식 문서 를 참고하는 편이 명확합니다. 간단히 설명드리면 assert(조건, "조건문이 false 일 때 출력할 메시지") 입니다.

관련주제 : Swift 난이도 : 하 코딩을 하다가 보면 자주 보던 코드인데 언제 쓰는지 정리해 보도록 하겠습니다. #if 는 컴파일 이전에 처리되는 전처리문 입니다. 즉 컴파일되기 전에 참, 거짓을 판별해서 거짓으면 컴파일이 되지 않는다는 뜻이죠. Compiler Control Statements 주로 보던 코드는 #if DEBUG , #if os 와 같은 코드였습니다. 한 번도 찾아본적이 없어서 #if 다음에는 어떤 문구가 들어갈 수 있는지 찾아보았습니다. 링크 Swift 버전이 다른 문법을 하나의 파일에서 처리하거나, 운영체제 버전이 다른 분기를 만들어 사용할 때 주로 사용합니다. 참고 : https://docs.swift.org/swift-book/ReferenceManual/Statements.html#grammar_conditional-compilation-block

관련주제 : Swift 난이도 : 하 개발을 하다가보면, 먼저 구조만 잡아두고 나중에 구현을 해야하는 경우가 종종 있습니다. 이 때 저는 주로 //TODO: 혹은 //FIXME: 를 적어놓습니다. 그러면 Xcode에서 도큐먼트 메뉴에서 시각적으로 확인 할 수 있습니다. 자주사용하던 기능이었는데, 불편한 점이 하나 있어습니다. TODO:는 문자열 찾기로 찾아갈 수는 있는데, 구현을 까먹었을 때 이를 확일할 만한 방법이 없었습니다. 왜냐하면 컴파일에 영향을 주지 않기 때문이죠. 나 자신의 실수를 막기 위해서 사용하는 안전장치가 필요했습니다. MustTODO와 같은 기능이죠. 그래서 그 뒤로는 꼭 다시 돌아와야 하는 경우에는 컴파일러용 지시문을 사용합니다. 컴파일러용 지시문 #warning("message") 와 #error("message") 를 사용합니다. 그러면 컴파일을 했을경우 경고문이나, 에러문구가 Xcode의 왼쪽 네비게이터 중 에러 쪽에서 메시지가 출력됩니다. 아 이 부분을 꼭 구현했어야 했지 처럼 컴파일에 경고를 띄워주거나, 에러를 일부러 발생시킬 필요가 있을 때 사용하면 됩니다.