오늘 SM 업무 수행 중인 모 기업에서 추가로 개발 중인 앱 개발자한테 연락이 왔다.

전달받은 인증서와 프로비저닝으로 빌드하고 In House 배포는 되었는데 


그쪽 개발자가 확인한 바로는 Swift 배포 이전에 생성된 인증서로는 Swift 관련 라이브러리 처리 시

오류가 발생한다는 것이다.


관련 내용


https://developer.apple.com/library/ios/qa/qa1886/_index.html


https://www.airsignapp.com/ios-apps-using-swift-crash-when-signed-with-inhouse-certificate/


아직 정확하게 확인은 못하였지만 기업 환경에서 Swift 개발 시 주의해야 할 것 같다.

저작자 표시
신고

같은 계정으로 등록된 앱이어야 공유가 가능하며

앱 아이디의 prefix가 같아야 한다...


업무상 iOS용 앱 2개 중 하나가 다른 하나의 버전을 체크해야 할 상황이 되었는데

이게 아무리 해도 안된다.


원인은 메인 앱은 현재 근무하고 있는 곳 계정이고 다른 앱은 타 개발사 계정으로 만들어진 앱이기 때문이었다.

결국 계획 무산...-.-

저작자 표시
신고

최초 작성일 : 2013/07/11 09:15 


다수의 SDK가 설치되어있는 경우

현재 적용된 SDK 버전 확인 방법


Mazdah-ui-Mac-mini:android mazdah$ /usr/bin/xcodebuild -showsdks

OS X SDKs:

Mac OS X 10.7                  -sdk macosx10.7

OS X 10.8                      -sdk macosx10.8


iOS SDKs:

iOS 6.1                        -sdk iphoneos6.1


iOS Simulator SDKs:

Simulator - iOS 6.1            -sdk iphonesimulator6.1


사용 중인 SDK 버전을 변경하는 방법


Xcode의 환경설정 -> Locations 탭에서 가장 하단에 있는 Command Line Tools를 사용중인

Xcode 버전으로 변경





저작자 표시
신고

최초 작성일 : 2013/05/23 17:28


곧 완성을 앞두고 있는 신규 앱에는 야심차게(?) IAP(In-App Purchase:앱내 구매)를

구현해보기로 했다.

이유는 당근 유/무료 버전을 나누는 것 보다는 IAP가 더 수익성이 좋을 것 같았기 때문이다.
그래봐야 1년이 가도록 겨우 개발자 등록비 뽑는 수준이지만...ㅠ.ㅠ

우선 기본적인 구현은 문제가 없었다.
맥부기 회원들의 도움으로 쉽게 구현을 마쳤다.
그런데 문제는 애플 서버를 이용한 영수증 인증이다.
탈옥을 통한 일종의 해킹 방지 차원이랄까?

이를 위해 특별히 애플에서 기본 소스 코드도 배포를 하고 있다.
아래 링크로 가면 간단한 설명이 있는 페이지가 나오고 그 페이지의 우상단에 보면
Companion File이라고 링크가 걸려있는데 여기에 VerificationController.h와
VerificationController.m 요렇게 약소하게 파일 2개가 들어있다.


이 파일에 적절하게 코드를 추가하여 처리하면 된다.
일단 가장 자세한 설명이 있었던 맥부기의 글이 아래 링크에 있다.


대체로 이 글을 통해 구현을 완료하였는데...
문제는 관련 글에도 있지만 SANBOX로 테스트하던 것을 애플 리뷰 후
실 상품 서버로 연결해야 하는데 이 것을 어떻게 해야 하냐는 것과

기존 코드의 paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray*)transactions
통해 수행하던 내용 중 [[SKPaymentQueue defaultQueuefinishTransaction:transaction];   
요넘을 어떻게 처리하느냐가 문제였다.

두 번째 문제의 경우 뭐 대충 델리게이트 써가면서 어렵지 않게 해결하였다.
특히 두 번째의 처리를 하지 않으니 IAP 서버에서 상품을 가져올 때마다
이전의 트랜잭션들이 모두 함께 내려와서 문제가 되었기에 반드시 처리를
해주어야 했다.

그리고 어렵게 처리한 첫 번째 문제

우선 구조가 NSMutableURLRequest를 이용해 서버에 연결하는 내용인데
처리는 우선 실 상품 서버로 연결을 하고 거기서 실패를 할 경우 테스트용 SANDBOX로
연결을 해야 하는 것이었다.

만일 테스트 계정으로 실 상품 서버로 연결을 하여 처리하게 되면
connection:didReceiveData: 함수에 response되는 결과값으로 21007이 떨어지게 된다.

이 21007이 확인된 이후 어떻게 해야 하는지에 대한 설명이 아무데도 없어서
혼자서 열심히 쌩X랄을 하였다.

우선 구매 요청부터 다시 보내보았다. 그랬더니 구매 팝업이 2번 뜨는 우스운 모양이
되어버려 실패...

다음으로는 처음 구매 요청후 생성된 transaction을 전역변수에 넣고 다시 서버 연결부 부터
진행을 해보았다. 역시 실패...

그리고 마지막에 처리한 것이 다음 방법이다.

영수증 인증을 위해 NSURLConnection을 이용하여
인증 서버로 연결할 때 인자로 넘기는 것이 transaction의 transactionReceipt 속성을
이용하여 만든 NSData형의 값이다.

그래서 전역 변수로 NSData형을 만들고 transaction. transactionReceipt를 이용하여
만든 NSData 값을 이 전역 변수에 할당 한 후 실 상품 서버에서 21007이 떨어지면
요넘만 인자로 넘겨서 다시 NSURLConnection커넥션을 하니 잘~ 처리가 되었다.

이로써 무사히 IAP 구현을 마치게 되었다...^^

위 설명한 프로세스를 요약하면 아래와 같다.

***
참고로  ITC_CONTENT_PROVIDER_SHARED_SECRET라는 값을 설정하도록 되어있는데
아무리 찾아봐도 내 계정의 아이튠즈 커넥트 화면에서는 그 값을 받아오는 링크가
보이질 않는다...ㅠ.ㅠ

설정을 안해도 테스트는 잘 되던데...이게 테스트이기 때문에 잘 되는 것인지...
요게 쪼끔 걸리네...ㅠ.ㅠ

============================================

PCStoreViewController : IAP 구매 화면 및 구매 시작을 담당함

구매버튼 터치시 아래 내용 실행
//payment는 SKPayment 타입의 전역변수

payment = [SKPayment paymentWithProduct:self.product];

 [[SKPaymentQueue defaultQueue] addPayment:payment];


addPayment 메서드 실행 후 델리게이트인 아래 메서드 실행

- (void) paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions


이 함수 내에서 transactions를 루프 돌리면서 각각의 transaction에 대해
transaction.transactionState에 따라 처리를 하게 되는데 다음 2가지 경우에 대해
VerificationController의 verifyPurchase:transaction 메서드를 호출한다.

SKPaymentTransactionStatePurchased

SKPaymentTransactionStateRestored



VerificationController : 영수증이 유효한 것인지 애플 서버를 통해 인증

 verifyPurchase:transaction 메서드 내에서 인자로 넘겨받은 transaction의
transactionReceipt 속성을 이용하여 NSData형의 값을 NSURLConnection을 통해 서버로 넘김 이 때 인자로 넘어가는 NSData를 전역변수에 할당을 해놓아 이후 21007
코드에 대비를 한다.

NSURLConnection의 델리게이트 메서드인 connection:didReceiveData:에서 최종 구매처리를 한다.
response 값으로 넘어온 NSData형의 data는 NSDictionary로 변환할 수 있는
JSON 값이며 여기에는 receipt라는 키로 NSDictionary 타입의 값이 들어있는데
이 값에는 각종 구매 정보가 들어있다.

그리고 status라는 키로 NSNumber 타입의 상태 정보가 넘어오는데 앞서 설명했듯이
테스트 계정으로 구매를 하는데 실 상품 서버로 연결을 하게 되면 이 값이 21007이
넘어온다.

만일 이 status가 이상이 없으면 (0이면) 구매 완료 처리를 하고 추가로 만든
델리게이트 메서드를 통해 finishTransaction 처리를 한 후 IAP 화면을 닫도록 하였고

21007인 경우 verifyPurchase: 메서드에서 전역변수에 저장해놓은 NSData를
인자로 하고 서버 주소는 SANDBOX(테스트)용 주소로 하여 다시 NSURLConnection
연결을 시도한다.

저작자 표시
신고

최초 작성일 : 2013/03/28 08:42 


한동안 Copy & Paste에 길들여져 있었더니 간혹 별 것 아닌 부분에서 헤매게 된다.


새로 개발하는 앱의 설정 화면을 테이블 뷰로 하고
스타일을 UITableViewStyleGrouped로 주었다.

그런데 이 것이 배경색이 딱 세로 스프라이트로 고정되어서
tableview.backgroundColor로 설정을 해도 변경이 되지 않는 것이다.

stack overflow에서 확인한 결과 다음과 같이 처리하니 해결이 되었다.

UIView* bview = [[UIView allocinit];

bview.backgroundColor = [UIColor clearColor];

[tableview setBackgroundView:bview];


다른 방법으로는 다음과 같은 방법이 있는데 iOS 5.x에서 문제가 발생한다고 한다.


[tableView setBackgroundView: nil];


저작자 표시
신고

최초 작성일 : 2013/03/19 09:00 


출처 : http://blog.jidolstar.com/trackback/842



NSArray - array =  @[ a, b, c ];

NSDictionary - dict = @{ k1 : o1, k2 : o2, k3 : o3 };
-> 요건 기존 딕셔너리 생성이 value, key 형식으로 코딩을 해야 해서
    좀 혼란스러웠는데 이렇게 쓰니까 key/value 순서에 맞게 되어 편하네요.

NSNumber *number;

number = @'X'; //char

number = @12345; //int

number = @12345ul; //unsigned long

number = @12345ll; //long long

number = @123.45f; //float

number = @123.45; //double

number = @YES; //bool

저작자 표시
신고

최초 작성일 : 2013/02/06 16:30 


기존 방식의 OAuth와 Twitter API를 이용하여 트위터 서비스를 제공하다가

이번에 iOS 5.0부터 iOS에 통합된 Twitter 프레임워크를 이용해보기로 하였다.

대체로 수정에 어려움은 없었고 전체적인 코드도 매우 깔끔해져서 좋았다.
하지만 한가지 문제가 발생을 했는데...

바로 DM(Direct Message) 목록을 보여주는 화면에서 권한이 없다는 응답과 함께
DM 목록이 보여지지 않는 것이었다.

구글링을 통해 확인한 결과 Twitter 개발자 페이지에서 다음 내용을 찾을 수 있었다.

What about Direct Messages?

The Twitter framework cannot read or delete Direct Messages but it can send them. If your application requires the ability to read or delete Direct Messages, you must follow the traditional OAuth web flow to obtain the user’s permission. You should then use the returned access token and secret for future calls that require DM read permission.

문서 링크 : https://dev.twitter.com/docs/ios

즉, Twitter 프에임워크에서는 DM 목록을 불러오거나 DM을 삭제할 수 없으며 이 기능을
사용하고자 하면 기존 OAuth방식을 따라야 한다는 것이다.

조금 골치아파진 것이 DM 리스트 기능 하나 때문에 Twitter 프레임워크를 못쓰거나 아니면
Twitter 프레임워크과 기존 Twitter API를 함께 사용해야 한다는 것이다.

애초 목적은 앱 내에서 트위터 로그인을 하도록 된 부분을 없애고자 한 것이었는데...
이 상태라면 DM 목록 보기 기능을 빼지 않는 한 목적을 이룰 방법이 없어진다...ㅠ.ㅠ
애플, 트위터...누가 나쁜거냐...-.-

저작자 표시
신고

최초 작성일 : 2013/01/17 11:08


최근 아이폰 5 출시 이후 현재 근무지에서 운영하고 있는 앱에 문제가 발생을 하였다.

jquery mobile 기반의 하이브리드 형태의 앱이었는데 아이폰 5에서 간헐적으로
입력필드 (input="text")를 터치했을 때 가상 키패드가 간헐적으로 올라오지 않는
문제이다.

그런데 이 문제가 혼란 스러웠던 것이 일단 아이폰 5 나오기 이전에 Xcode 4.4.1이나
Xcode 4.3 에서 빌드하여 배포한 버전(2012년 9월경)에서는 그런 문제가 거의
발생을 하지 않았는데 유독 4.5에서 빌드한 후 설치를 하니 그러한 문제가 발생을 하였고
나중에는 아이폰 4에까지 새로 빌드한 앱은 모두 키패드가 간헐적으로 올라오지 않는
문제가 발생을 하게 되었다.

새 버전 배포를 목전에 두고있던터라 속이 바싹바싹 탔는데...

다른 라이브러리를 적용하기 위해 작업을 하던 도중 __divmodsi4라는 심볼을
찾지 못한다는 오류가 발생을 하였고 이 문제의 해결책을 찾던 중 Xcode의 컴파일러를
LLVM GCC에서 Apple LLVM Compiler로 변경을 하였다.

우선 __divmodsi4 오류는 해결이 되었는데...

웬걸...아이폰5에서 키패드가 올라오지 않던 문제까지 같이 해결이 되어버렸다.

혹시라도 jquery mobile 기반의 하이브리드 앱이 아이폰 5에서 키보드를 잘 불러오지
못한다면 컴파일러를 Apple LLVM Compiler로 수정해 보시길~

아울러 __divmodsi4 오류 또한 마찬가지~^.~

저작자 표시
신고

최초 작성일 : 2012/10/15 11:21 


1. 카테고리 선정


가장 해보고 싶고 또 대박의 확률이 높은 뷴야가 게임이긴 하지만

스스로의 경험에 비추어보아서나 현재 시장 상황을 보아서나 아직까지 게임은 시기 상조라고 판단하였다.


게임을 제외하고 가장 사용자들이 꾸준히 사용하게되는 카테고리는 어떤 것인가에 대한 고민의 결과

선택된 분야가 '연락처'이다.


사실 연락처는 카테고리 구분이 모호하다. 유틸리티도 될 수 있고 생산성도 될 수 있고 비지니스도 될 수 있고

심지어는 소셜네트워크도 될 수 있다. 우선 위 열거한 카테고리 중 가장 인기가 좋은 소셜네트워크로

카테고리를 정할까 하다가 대부분의 연락처 앱들이 생산성 카테고리에 들어가있기에 나도 생산성으로

카테고리를 정하고 서브 카테고리를 소셜네트워크로 정했다.


사실 지금에 와서는 BizContact의 컨셉과도 부합하는 소셜네트워크쪽을 메인카테고리로 할 것을 그랬다는

생각이 절실하다.


애스토어에서 '연락처'를 검색해본 결과다. 생산성 카테고리가 많은 편이다.







2. BizContact의 중요 컨셉


21세기 IT 세상의 화두라면 역시 SNS다. 다양한 서비스들이 생겨나고 그중 일부는 상상을 초월하는 성공을

거두었다. 사람들은 비록 직접 보이지는 않지만 많은 사람들과 관계를 맺고자 하였고 이러한 열망을

크고 작은 서비스들이 충족시켜주었다.


돌이켜보면 인간을 사회적 동물이라 표현할 만큼 '사회성'이라는 것은 인간이 가진 기본적인 성향 중 하나이며

이런 성향을 표출시켜줄 서비스의 등장은 너무나도 당연한 일이다.


그렇다면 'SNS'라 불리워지는 서비스들이 생겨나기 이전에는 사람들이 어떤 방법으로 이러한 사회성을 유지하고 있었을까?

딱 잘라 말하자면 모바일 폰 그리고 그 안에 들어있는 '연락처'야말로 사람들이 사회성을 유지하고 또 그 영향력을

확대하기 위한 가장 강력한 정보였음이 분명하다.


즉 연락처는 SNS의 기원임과 동시에 현재로서도 그 형태가 다를 뿐 '연락처'라는 형식을 버리고는

SNS를 유지할 수 없다. 친구목록이 없는 페이스북이나 팔로워/팔로잉 목록이 없는 트위터를 상상할 수 있는가?

카톡은 대놓고 사용자들의 연락처를 뒤진다.


BizContact의 컨셉은 연기서 출발한다.

예전의, 전화번호나 주소, 이메일 주소 등만을 기록하던 연락처가 아닌, 그 연락처 안에서 현재 제공되는

SNS 서비스들의 친구들까지 관리해 줄 수 있는 연락처를 확대한 개념의 연락처.


그래서 BizContact는 연락처 안에서 그 연락처의 대상이 활동하고 있는 SNS(현재로서는 페이스북과 트위터)의

정보들을 추려서 볼 수 있도록 하고 이메일의 경우에도 단지 상대방에게 이메일을 보내는 기능에서 벗어나

상대방이 보낸 이메일만을 모아서 볼 수 있는 특화된 기능들이 추가되었다.



iOS 6에서 트위터와 페이스북 계정이 통합되었다.





각각의 계정에 로그인하면 연락처와의 동기화 옵션이 나타난다.






3. 한계


앞서 이야기한 바와 같이 카테고리 및 앱 성경에 대한 홍보에 문제가 있었다.

BizContact의 가장 중요한 특징은 SNS로 확장된 연락처 이상의 무엇이다. 굳이 말을 만들자면 Social Manager이다.

하지만 초기 판매당시 카테고리 자체도 생산성으로 정해진데다가 '연락처'라는 분야에 초점이 맞다보니

상대적으로 다른 연락처 앱에 비해 연락처 앱이 가져야할 필수 요건 몇가지가 빈약한 BizContact로서는 충분한

자기 어필을 할 수가 없었다. 그렇게 BizContact는 그냥 '연락처' 앱으로 전락하고 말았다.


또하나 '연락처'앱이 가질 수 밖에 없는 태생적 한계는 바로 애플의 제한으로 인해 기본 전화 앱의 정보에 접그할 수가

없다는 것이다.


사용자들이 연락처에 대해 중요시하게 생각하는 정보 중 하나가 부재중 수신에 대한 부분이다. 하지만 현재 개발자들은

이 내용을 표시해 줄 수가 없다. 이는 사용자들로 하여금 어쩔 수 없이 기본 전화 앱으로 가도록 만드는 악재 중의 악재이다.


사용자들이 중요시 여기는 부재중 통화(모든 수신목록 및 문자 데이터)에

접근하지 못하는 한계가 있다.



 


4. 전략적 과제


가장 기본적인 앱의 안정성은 두말하면 잔소리이니 제쳐두고...

무엇보다도 BizContact가 '연락처'라는 좁은 범위에서 벗어나는 것이 최우선 과제라고 볼 수 있다.

그러기 위해서는 전체적인 UI가 일반 연락처와는 달라질 필요가 있다. 즉 사용자의 정보 범위가 넓은 만큼

실제 화면상에서 사용자의 정보를 보여주는 영역이 많은 부분을 차지해야 한다. 물론 그 정보를 보기 위해

들어가야 하는 depth역시 최대한으로 줄여야 하는 것은 물론이다.


또한 SNS의 측면이 강화된다면 당연히 패드에 대한 진출도 고려를 해야 한다.

그저 연락처라 하면 '전화'를 기준으로 생각하기 마련이다. BizContact는 이 제약으로부터 벗어나야 한다.


문제는 이미 출시된 지 5개월이 다되가는 현재 기존 사용자들에게 박힌 선입관을 과연 극복할 수 있을까 하는 것이다.

최악의 경우 동일한 기능에 UI만 완전히 바뀐 새 앱을 출시해야 할지도 모른다…ㅠ.ㅠ

(실제로 그 준비도 진행 중이다…-.-)



요런 것이 BizContact만의 특징...^^;;;










5. 개인적인 꿈


나는 BizContact를 아이폰의 필수 앱 중 하나로 만들고자 한다.

마치 전화기에 연락처가 필수적이 듯…

얼마나 특화된 기능을 거부감 없이 BizContact에 심어 넣는냐 하는 것이 최대 관건이 될 것이다.

그리고 아직은 BizContact가 알려지지 않아 '나쁜 예'로서 자리잡고 있어서 별 문제 없겠지만

BizContact가 '좋은 예'로 격상되는 순간 등장하게 될 수많은 유사 앱으로부터 어떻게 자리를

지켜 나가야 하는지도 쉽지 않은 문제일 것이다.


BizContact 혹은 새롭게 탄생될 다른 Social Manager 앱이 스테디 셀러이자 아이폰의 킬러 앱이

되는 그날까지 '한 놈만 팰' 작정이다…^^

저작자 표시
신고

최초 작성일 : 2012/10/12 16:06


각설하고...


내가 구현하고자 하는 기능은

1. 달력에서 날짜를 터치하면
달력은 선택한 날짜가 있는 주만 보여주도록 축소되고 하단의 이벤트 목록이
확대되도록 화면을 구성하고 다시 달력월 원래대로 보여줄 수 있도록
버튼이 하나 추가된다.

2. 추가된 버튼을 터치하면 달력은 원래대로 모든 날짜가 나오고 이벤트
목록 영역은 축소되며 당연히 버튼은 사라진다.

이 기능을 구현하는데 버튼 처리는 viewWithTag와 removeFromSuperView
메서드를 이용해서 구현을 하였다.

그런데 기능 자체는 잘 적용이 되었는데 버튼이 보여지고 사라지는 시점이
영 맞질 않는다. 사라져야 할 시점에 이미지는 보여지는데 버튼이 기능을 안하거나
아니면 사라지지 말아야 할 시점에 사라진다거나.

이 문제를 해결하려고 거의 하루를 소비하였다.
그런데...

어처구니없게도 이 문제의 원인은 버튼에 태그를 잘못 달아준 것 때문이었다.
그래도 중복을 피해보겠다고 5자리 숫자로 길게 주고 있는데 10002로
태그를 주었더니 아마도 같은 태그를 갖는 뷰 혹은 컨트롤이 이미 있었나보다.
태그만 11112로 바꿔주니 바로 정상적으로 기능을 하였다.

보다 근본적인 원인은 커스텀 탭바 컨트롤러를 구현하여 사용하는 과정에서
뷰의 계층구조가 너무 복잡하게 중첩되어있어 다른 화면 어딘가에 태그가
10002로 부여된 컨트롤이 같은 뷰 계층 구조 내에 있었던 모양이다.

아무렇게나 사용하던 뷰(컨트롤러)의 tag였는데 앞으로는 신중하게 사용해야 할 것 같다.

저작자 표시
신고

+ Recent posts

티스토리 툴바