네트워크 통신하다보면 응답 데이터를  텍스트로 받을 경우가 있다.


전문도 그렇게 오는데, 공백과 줄바꿈 항목을 trim하고 싶을 때 아래와 같이 사용하면 된다.



NSString *resStr = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];

resStr = [resStr stringByReplacingOccurrencesOfString:@" " withString:@""];     // 공백 제거

resStr = [[resStr componentsSeparatedByCharactersInSet:[NSCharacterSet newlineCharacterSet]] componentsJoinedByString:@""];     // 바꿈 제거




한 2년 가까이 iOS 프로그램을 안만들었더니...세월이 넘 빠르게 흘러버렸는지 도데체 감이 안온다.

그 사이에 swift도 나왔고, iWatch도 나오고, 그리고 얼마전에는 Metal도 공개되었다.

이것저것 바뀐게 꽤 많은데, 계속 follow-up을 하지 않으니 뭐가 나왔다더라 이상은 모르는 게 사실.


대부분의 국내 기업들이 안드로이드나 하이브리드 방식으로 앱을 개발하는 관계로 꽤 오랫동안 본의아니게 등안 시 했었는데, 이러다가 iOS 다 잊어버리겠다는 생각이 들어서 하루에 조금씩 다시 관련 내용들을 살펴보기로 했다.


아무튼, 오픈 소스 컨트롤러 몇 개를 검색해보다보니 대부분의 소스들이 CocoaPod 를 통해서 개별 프로젝트에 라이브러리를 따로따로 파편화되는 것은 방지하고, repository를 통해서 관리하고, 팀 간 협업을 지원할 수 있으며, 간편하게 새로운 버전 또는 공동 작업 버전의 오프소스를 관리 및 업데이트할 수 있다고 한다.


CocoaPod 홈 - https://cocoapods.org



Ant, Maven이나 Gradle과 같은 빌드자동화 툴인지는 아니지만, 일부 기능이 일맥상통하는 부분이 있다.


Apache Ant는 빌드자동화 툴로 많이 알려졌고, xml 기반의 빌드 스크립트가 커지고 dependency 이슈로 인해서 이를 관리하기 힘들어져 나중에 Apache IVY를 추가하게 되었다고 한다.


Maven의 경우는 Ant의 이러한 문제점을 해결하기 위해서 나왔지만 여전히 xml에 사양을 기재하는 방식이다. 하지만 기존의 Ant가 빌드에 필요한 모든 커맨드들을 모두 기재해야 했다면, Maven은 규약들과 invoke 해야할 타겟을 지정하는 형태로 사용하기 때문에 Ant와는 큰 차이가 있다고 한다. 더 가볍고, 라이브러리의 버전 및 프로젝트 관리가 더 편한 Maven도 라이브러리의 dependency 관리에 이슈가 있다고 한다.(Ant는 라이브러리의 dependency를 Apache IVY 추가를 통해서 보완했다)


아무튼 이 와중에 Gradle이 2012년에 나왔고, 구글이 이를 안드로이드 배포 패키지 관리를 위한 빌드자동화툴로 선택하며서 많이 퍼지게 되었다. 아주 빠른 속도로 이 툴은 선택되었다.


Gradle 역시 Maven과 같이 필드와 라이브러리 관리를 모두 지원하며, Ant의 강력함과 유연성 그리고 Maven의 라이프사이클 관리와 사용 편리성을 모두 갖췄다고 한다. 기존의 XML을 통한 방식보다는 Groovy 언어 기반의 DSL(Domain Specific Language)을 이용한다. 그 결과 Ant나 Maven 보다 더 읽기 쉽고, 간단한 빌드 사양을 작성할 수 있다. 처음에 Apache IVY를 dependency 관리 툴로 사용했지만 나중에 자체 관리기능으로 변경했다고 한다.


*. 참조해서 읽은 글 - http://technologyconversations.com/2014/06/18/build-tools/


- Ant: https://en.wikipedia.org/wiki/Apache_Ant

- Maven: https://en.wikipedia.org/wiki/Apache_Maven

- Gradle: https://en.wikipedia.org/wiki/Gradle

- DSL: https://en.wikipedia.org/wiki/Domain-specific_language



아무튼, 또 쓰잘데기 없이 '이게 뭔가?'해서 문서들을 이것저것 읽어댔는데...


이런 빌드자동화 툴보다는 사용법은 NPM과 같은 비슷하면서 Mac 개발환경 하의 라이브러리 dependency 관리 및 프로젝트 관리에  도움을 주는 일종의 툴로 보면 될 것 같다. 


지금 떠오르는 장점을 좀 생각해보자면, 이 정도일 것 같다.


1) 라이브러리의 중복을 제거한다.

2) 라이브러리의 버전을 관리한다.

3) 팀 프로젝트의 형상관리 시 동일한 버전의 라이브러리를 운영한다.


그럼, 한 번 설치해보자.



1. CocoaPod의 설치


CocoaPod는 루비(Ruby)로 만들어졌다고 한다. OS X의 기본 설치된 루비를 이용하면 된다고 하는데, 루비 버전은 그냥 신경쓰지말라고 그냥 아래의 명령어를 입력하여 설치하면 된다고 한다.


설치 가이드 - https://guides.cocoapods.org/using/getting-started.html#getting-started



$ sudo gem install cocoapods



관리자 권한으로 명령어를 입력하면, 비밀번호 확인하고 설치가 한참있다가 시작된다. 

잠시 뭔가 이상이 생긴것이 아닌가라는 생각이 들정도로 딜레이가 있다.



내 경우에는 1분이 넘어서 아래와 같이 설치 및 완료를 볼 수 있었다.



설치 가이드 밑에 보면 sudo 권한을 통하지 않고, 설치하는 방법도 나와있으므로 참고해서 설치하고 싶은면 따라하면 될 것 같다.


설치할 때 가끔 이슈가 발생하기도 하나 보다. 그럴 경우에는 다음의 페이지를 참조해서 해당 이슈를 해결해보자.


트러블슈팅 - https://guides.cocoapods.org/using/troubleshooting#installing-cocoapods



2. CocoaPod를 통한 프로젝트 설정


간단하게 프로젝트 설정을 다음의 오픈소스를 가지고 진행해보았다.


https://github.com/jdg/MBProgressHUD




+ Recent posts