Objective-C / Swift

CMD + SHIFT + J : 열려있는 파일을 프로젝트 트리에서 보여주기 CMD + SHIFT + D 또는 Y: 디버깅 윈도우 열기/닫기 토글 CTRL + 1 : 현재 파일 관련 추가 메뉴 (find caller, callee) CTRL + 6 : 현재 파일 요약 (method, variable list) CMD + click: 정의로 이동 CMD + OPT + click: 정의로 이동하되 현재 창 반대편에 열기 CTRL + CMD + 왼쪽 / 오른쪽: 히스토리 이전/다음 이동 CMD + SHIFT + F: 전체 파일 스트링 검색 CMD + SHIFT + O: 파일 검색창 오픈 검색된 파일 선택시 OPT + Enter: 현재창 반대편에 열기 검색된 파일 선택시 OPT + SHIFT + Enter: 창 고르기 CMD + R: 실행 CMD + SHIF + K: 클린 CMD + 1 … 9: 왼쪽 사이드바의 탭 선택- CMD + CTRL + E: 특정 단어 선택 후 누르면 현재 파일내 동일 단어를 일괄 편집 (모든 파일을 분석해서 업데이트해주는 refactor와는 다름에 주의) CMD + OPT + 왼쪽 / 오른쪽: 현재 커서가 위치한 블록 접기/펼치기 (코드 양이 많을때 불필요한 메서드나 nesting된 블록을 접어놓고 보기 좋음)

엑스코드 플레이그라운드(Xcode Playground)에서 간단하게 코드를 테스트 해보고 싶은데 해당 코드가 특정 cocoapod 라이브러리에 의존성이 있는 경우 cocoapods-playgrounds 명령어 도구를 사용하면 편리하다. 설치 및 사용 방법 설치 sudo gem install cocoapods-playgrounds 플레이그라운드 프로젝트 생성 cocoapods playgrounds podName 위 명령어를 실행하면 위 라이브러리가 연결된 워크스페이스가 자동으로 생성되고, 해당 워크스페이스 안에 우리가 사용할 수 있는 playground 파일까지 포함되어있으니 여기서 마음껏 테스트 해보면 된다. 여러 라이브러리 동시 참조 여러개 라이브러리에 의존성을 가지는 플레이그라운드 프로젝트를 만들고 싶을 경우, 라이브러리 이름을 컴마로 구분하여 붙여 써 둔다. ...

Swift에는 struct와 class타입이 공존하고있기 때문에 아래의 차이점을 잘 숙지하고 상황에 맞게 사용하는것이 매우 중요하다. struct call by value (할당 또는 파라메터 전달시 value copy가 일어남) stack memory 영역에 할당 (속도가 빠름) scope based lifetime: 컴파일타임에 compiler가 언제 메모리를 할당/해제할지 정확히 알고있음 data locality: CPU 캐시 히트율이 높음 상속 불가능 (protocol은 사용 가능) NSData로 serialize 불가능 Codable 프로토콜을 이용하여 손쉬운 JSON <-> struct 변환 가능 (Swift 4 이상) 항상 새로운 변수로 copy가 일어나기때문에 multi-thread 환경에서 공유변수로 인해 문제를 일으킬 확률이 적음 1 class call by reference (할당 또는 파라메터 전달시 객체를 가리키고있는 메모리 주소값만 복사됨) heap memory 영역에 할당 (속도가 느림) 런타임에 직접 alloc하며 reference counting을 통해 dealloc이 필요 memory fragmentation 등의 overhead가 존재 상속 가능 NSData serialize 가능 Codable 사용 불가능 런타임에 타입 캐스팅을 통해서 클래스 인스턴스에 따라 여러 동작이 가능 deinitializer 존재 참고: class안에 struct 변수를 property로 정의하는것 가능하며, 반대로 struct의 property중 하나로 class 인스턴스 변수를 갖고있는 것도 가능하다. 이 경우 해당 struct 변수의 copy가 일어날때 class 인스턴스의 주소값만 복사된다. ...

Obj-C의 블락(block)이나 Swift 클로저(closure)는 컨셉은 거의 동일하나 closure 내부에서 현재 scope에 존재하는 값 타입(value type) 변수들을 캡쳐(capture)해서 사용할 때 기본동작이 반대로 되어있기 때문에 사용법에 주의를 기울여야 한다. 반면 클래스 인스턴스와 같은 참조 타입(reference type) 변수들은 항상 reference copy가 일어나기 때문에 두 언어를 사용할때 차이점에 크게 신경쓰지않아도 된다. (대신 retain cycle이 생기지 않도록 조심해야 한다.) 다음 예제들을 통해서 차이점을 좀 더 자세히 알아보자. Capture in Swift closure Swift의 경우 일반적으로 value type 변수를 다른 변수에 할당하거나, 함수 파라메터로 전달 할 때 copy동작이 기본이다. 하지만 closure에서 변수를 capture를 할 때는 명시적인 capture list를 작성하지 않으면 value type 변수(struct 변수 포함) 임에도 불구하고 reference capture가 일어난다. 확인을 위해서 다음 예제를 살펴보자. ...

Obj-C category의 위험성 Obj-C에서 동일한 메서드 이름을 가진 카테고리(category) A, B가 동시에 존재하더라도, 컴파일 타임에 오류가 발생하지 않고 정상적으로 빌드되어 실행이 가능하다. 하지만 런타임에서 A와 B중 어떤 녀석이 먼저 호출될지 알 수 없기때문에 (규칙이 없으며 랜덤하게 호출됨) 매우 위험한 상황이 발생한다. 이를 방지하기 위해서 Obj-C에서 카테고리 메서드에는 프로젝트에서 사용하는 고유의 prefix를 붙여줘서 이름이 완전히 겹칠 확률을 최대한 줄여주는 방식을 꼭 사용해야 한다. 그렇지 않으면 외부 라이브러리를 사용할때 해당 라이브러리에 동일한 category명이 존재해서 랜덤하게 호출되는 상황이 발생 할 수 있다. 이는 매우 원인 파악도 힘든 에러가 될 것이기에 꼭 피해야 한다. ...

iOS의 경우 기본적으로 Sandbox환경이라 다른 앱들간에 정보를 주고받는것이 간단하지 않다. 이때 정보를 주고받을 수 있는 대표적인 방법이 custom URL scheme이다. 앱의 고유한 scheme을 정의하고 이 scheme으로 시작하는 URL안에 정보를 담아서 URL을 열게되면 해당 scheme이 갖는 다른 앱을 실행하면서 정보전달을 할 수 있다. 하지만 이 방법에는 치명적인 단점이 있는데, 애플 앱스토어에서 해당 앱이 정의한 scheme의 uniqueness를 보장해주지 않기때문에 다른 앱들이 자신이 정의한 scheme을 사용하고 있을 수 있다는 점이다. 자신의 앱을 MyApp이라고 하고 이 앱이 myapp:// 이라는 custom URL scheme을 사용한다고 가정하자. (MyApp안의 info.plist 내에 존재하는 “URL types – URL Schemes” 항목에 myapp 이 정의하면 됨) 방금 정의한 custom schememyapp은 unique가 보장되지 않기 때문에 앱스토어에 올라온 YourApp 이라는 엉뚱한 앱이 동일하게 앱 내부에 custom scheme으로 myapp을 정의하는 일이 발생할 수 있다. 만약 MyApp과 YourApp이 동시에 설치되어 있는 device에서 myapp://으로 시작하는 URL을 open하게 되면 두 앱 중에서 누가 열릴지 알 수 없게 되어버린다. 설치 순서에 영향을 받는 것도 아니라서 특정한 규칙이 없으며, 상황에따라 두 앱중 하나가 열리게 되는 랜덤한 현상이 발생한다. ...

안드로이드, iOS, 윈도우 개발을 하는경우 플랫폼의 특성에 따라 각각의 플랫폼에 맞는 IDE를 사용할 수밖에 없다. 각각의 IDE를 사용해야 하기때문에 코드 작성을 위한 언어 공부는 그렇다 치더라도, 복잡한 빌드 설정 방법에 대해서도 많은 공부가 필요하다. 이제까지의 경험으로는 개발이 제일 쉽고 개발 환경 설정이 가장 어렵다. (하하) 간단한 단일 프로젝트의 경우 간단하게 기본 제공되는 템플릿대로 이용하면 된다. 하지만 다양한 환경에 따라 배포방식이 달라지는 경우나, 같은 코드베이스에서 약간의 코드 변형을 적용하여 미묘하게 다른 여러가지의 프로덕트를 만들어내야 하는 경우 (ex: 기능제약이 있는 무료버전 앱과 유료버전 앱을 만들어내는 경우) 에는 코드 작성도 중요하지만 프로젝트 환경 설정을 어떻게 하는지가 매우 중요하다. ...

iOS 앱에서 상품을 등록하고 판매하는 과정은 꽤나 복잡하다. 그 중에서도 정기구독 자동결제(Auto-Renewable Subscription) 상품을 판매하는 경우 신경써야 할 부분이 매우 많다. 2016년 WWDC에서 애플은 Auto-Renewable Subscription을 모든 카테고리의 앱에 적용가능하도록 허용하기로 했고(기존에는 잡지, 음악 등 특정 컨텐츠에 대해서만 허용되었었음), 해당 타입의 결제를 통해 발생한 매출의 경우 다음 조건을 만족할 경우 앱 판매 수수료를 30% ->15%로 인하 하는 내용에 대해서 발표했다. 수수료 인하 조건 해당유저가 1년이상 결제를 유지한 경우 1년 이후 결제분의 수수료를 15%로 인하 (2016년 6월 13일 이후 부터 적용) 사용자가 중간에 정기 결제를 취소했더라도 60일 이내에 다시 정기결제를 시작한경우 해당 유저의 결제 기간은 계속 누적된다. (60일을 넘을 경우 리셋) 이번 발표 전 기존 결제 기간도 카운트 된다. (Prior days of paid service are counted.) 즉, 이미 1년간 결제해온 사용자가 6월 13일 이후에 결제할 경우 수수료는 15%로 줄어든다. Auto-Renewable Subscription에 대해 자세히 설명하기 전에 먼저 앱스토어의 다른 상품 타입들에 대해서도 간략히 정리해보도록 하자. ...

UIImage의 size 는 픽셀(px)단위가 아닌 포인트(point) 단위로 처리가된다. 따라서 사이즈 정보에 추가적으로 스케일(scale) 정보를 같이 같고있다. UIImage를 bundle에서 [UIImage imageNamed:]를 이용하여 불러올때는 이미지에 붙어있는 @2x 또는 @3x 포스트픽스를 통해서 해당이미지의 스케일이 정상적으로 설정되어 특별히 신경쓸 필요가 없다. 마찬가지로 서버에 이미지 데이터를 요청해서 받아올 경우에도 AFNetworking의 AFImageResponseSerializer을 사용하면 UIImage를 만들어줄 때 스케일 관련 정보 또한 내부적으로 처리를 해주니 신경을 쓸 필요가 없다. 하지만 NSData로부터 UIImage 를 생성할때나 파일명에 포스트 픽스가 없는 다운로드된 파일로 부터 UIImage를 생성할 때는 이러한 스케일 처리를 따로 해줘야 된다. ...

블루투스 연결을 사용하는 멀티플랫폼(Mac, Window, Android, Windows Store app) 앱 개발을 하면서 겪은 경험과 노하우들을 정리해 보았다. 아직 완전히 개발이 끝나지 않았기때문에 포스트 내용에도 부족한 점들이 많이 있지만, 일단은 먼저 경험을 공유하는 것이 중요한 것같아서 포스팅을 해둔다. Bluetooth 연결 기본 블루투스는 디바이스를 어떻게 찾는가? 블루투스 디바이스는 자신이 제공할 수있는 서비스를 무선 네트워크상에 publish해서 다른 디바이스들이 검색할 수 있도록 하는데, 이때 사용되는 것이 Service Discovery Protocol(SDP) 이다. 예를들어 블루투스 키보드는 자신이 HID 서비스(입력장치)가 가능하다고 무선네트워크상에 계속 신호를 보내고있는 상태인 것이고, 컴퓨터에서 주변 블루투스 장치를 검색할때 이 신호를 인식하여 “블루투스 키보드 장치가 있다”는 사실을 알게되는것이다. 이때 이러한 서비스들을 유니크하게 구분하기위해 UUID를 사용하게된다. UUID의 기존에 이미 정의된 것들을 사용할 수 있으며, 새롭게 임의로 UUID를 생성해서 사용하는것도 가능하다. ...