In App Purchase 매뉴얼..

In-App Purchase Programming Guide

Overview of In-App Purchase

Product

팔고 싶은 특성 모두. iTunes Connect 를 통해 새로운 앱을 만들때 처럼 연결.  4가지 방법. & 컨텐트 : 전자첵. 잡지, 사진, 아트웤, 게임레벨, 케릭 등등  어플에 배달 가능한 컨텐트. & 기능 : 이미 구현되어 있는 기능을 언락 / 기능 확장. & 서비스 : 1회성 서비스에 대해 과금. 음성 받아적기 등. & Subscriptions : 확장에 기반한 컨텐트/서비스 접속. 금융 정보에 1달간 접속 가능, 온라인 게임 포털에 접속 가능… 등.. 제품 설계 시 중요한 가이드라인. > 실제 제품 판매에는 사용하지 말것. > 전자머니를 나타내는 아이템을 제공하지 말라.. 사용자가 특정 아이템/서비스를 구매하는 것으로 아는 것이 중요 > 포르노, 도박, 혐오 에 관련되지 않도록..

Registering Products with the App Store

모든 아이템은 iTunes Connect 를 통해 먼저 등록 되어야 함.  이름/설명/가격 이 있어야 함. 특정 제품을 <product identifier> 라는 스트링으로 구별할 수 있다. 스토어킷을 이용하면 제품에 제공한 데이터를 가져올 때 PI 를 사용. 나중에 고객이 구매하고자 할 때, 어플은 PI 를 이용하여 그 제품이 구매된 것인 지 구별한다. 앱 스토어가 제공하는 제품의 종류 > Consumable : 매번 사야 하는 것. 1회성. > Non-consumable : 특정 유저가 한번만 구매.  모든 디바이스에 적용. 스토어킷은 이러한 기능 제공. > Auto-renewable subscriptions : 앞의 것처럼 모든 기기에 적용. subscription 의 기간 선택. 당신의 앱이 유효한지 안한지 책임진다. 가장 최근의 결재를 업데이트… > Free subscriptions : 뉴스 스탠드에 무료 자료. 폐기되지 않고 ‘뉴스 스탠드’ 가능한 앱에서만 사용 가능. > Non-renewing subscriptions : 제한된 기간을 갖는 제품. 오토-리뉴어블 과 다른 점. >> 아이튠즈커낵트에 제품 생성 시 섭스크립션 이란 단어가 선언되지 않음. 당신의 앱이 제공. 보통 제품 설명에 포함. >> 넌-리뉴잉 은 여러번 구매할 수 있다. 앱스토어에 의해 자동으로 ‘리뉴’ 되지 않음. 리뉴얼 프로세스를 앱 안에서 구현해라. >> 넌 리뉴잉  을 모든 기기에서 보여줘야. 자동으로 싱크되지 않음.

Feature Delivery

Buil-in / sever model..

Built-in Product Model

앱 내부에 모든 것이 이미 구현. [풀어 주는] 기능. 즉시 제공 가능. 대부분은 non-consumable.. *** IAP 는 결재 성공 후 어플을 패치하는 것은 하지 않음. 어플의 번들에 변화가 필요하면 업데이트된 버전을 앱스토어에 배달해야 함. 제품을 구별하기 위해 당신의 어플은 PI를 번들에 저장. Plist 를 권장. 컨텐트 주도 어플은 소스를 바꾸지 않고 새로운 컨텐트를 추가 가능. 구배 성공 후 언락하고 기능을 제공해야 한다. 가장 쉬운 방법은 preferences 를 바꾸는 것..  Implementing Application Preferences어플 프레퍼런스는 백업 된다. 유저에게 백업하라고 추천할 수도 있음.  도표 참조..

Server Product Model

당신이 제품을 공급할 서버를 운영.  게임 등에서는 뉴 레벨 등을 배달 가능. 스토어 킷은 어떤 것도 제공하지 않음. 당근.. 특정 유저를 구별하는 메카니즘도 제공 안 함.  도표 참조 …

## 사용자 스토어에서 아이템 선택 -> 어플이 앱 스토어에 결재 요청 전송 -> 앱 스토어 결재한 후 결재완료 리턴 -> 어플이 영수증 받고 서버로 보냄 …
—-> ** 서버가 앱 스토어로 확인 영수증 데이터 보냄. -> ** 앱 스토어가  영수증이 유효한지 확인한 후 영수증과 확인 되었는지 보냄 -> 서버가 반환된 영수증을 통해 구매 물품 확인 -> 서버가 구매 물품 어플에 전달.

애플은 서버로부터 PI를 받는 것을 추천.. plist에 저장은 비추.. >> 업데이트 없이 물품 추가하는 유연성 제공.

서버가 영수증을 받고 물품 확인 하는 절차.. Verifying Store Receipts..

서버 모델은 추가적인 보안, 신뢰성 부가… 보안코딩 가이드 참조할것..

Non-consumable 제품은 스토어 킷의 기능을 이용해 회복 가능하지만, non-renewing 제품은 당신의 서버에 저장되야 한다. 이 정보를 저장하는 것은 네 책임이다. Consumable 제품 역시 당신 서버에 의해 추적가능하다.  이 제품이 서버에 의해 제공되는 것이면, 사용자가 각 기기에서 수습하게 할 수 있다.

Retrieving Product Information

어플이 스토어를 보여줄 준비가 되면, 앱 스토어로부터의 정보를 UI 에 덧붙여야 함.  이 장은 앱 스토어에 제품 디테일을 요청하는 방법에 관한 것임.

Sending Requests to the App Store

스토어 킷은 요청하는 메카니즘 제공.  request 객체를 생성, 초기화 딜리깃을 붙이고 요청 시작. 시작하면 앱 스토어에 전달. 앱 스토어가 요청을 실행하면 딜리깃이 비동기적으로 불려서 결과를 전달함.

SKRequest : abstract base class

SKRequestDelegate : protocol  : 구현할 부분. 성공/실패 에 대하여

Requesting Information About Products

어플은 제품에 대해 로컬 정보를 얻기 위해 products request 를 사용.
어플이 product identifier string 의 리스트를 포함하는 request 를 생성. 앞에서 설명한대로 어플은 PI를 어플 내부에 임베드하거나 혹은 서버를 통해 갱신할 수 있다.  request 를 시작하면 identifier string 이 앱 스토어에 넘겨진다. 앱 스토어가 iTunes Connect 에서 입력한 로컬화된 정보로 응답한다. 이 디테일로 당신 스토어의 UI에 덧붙여라.

##** 중요 : 제품 구매를 허락하기 전에 특정 제품 identifier 를 요청해야 함. 앱 스토어로부터 제품 정보를 갱신하므로 제대로 된 제품을 파는 것을 보장할 수 있음.

SKProductsRequest

product identifier 의 리스트와 함께 생성.  상점에 진열될..

SKProductsRequestDelegate  프로토콜

상점으로부터의 반응을 받기 위해 구현.  요청이 성공되면 대답을 받음.

SKProductsResponse

스토어에 의해 인식되지 않은 PI의 리스트 뿐만 아니라 원래 요청의 유효한 PI 마다 하나의 SKProduct 객체를 갖고 있음. 스토어는 여러 이유로 식별하지 못할 수도 있음 : 오타, 판매 불가로 표시,  iTunes Connect 에서의 변경이 모든 앱 스토어 서버로 전달되지 않아서.

SKProduct

앱 스토어에 등록한 제품에 대해 로컬 정보를 제공함.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중