지난번에 올린 Tutorial 인 In App Purchase on Android 이전에 나왔던 새로운 기능에 대한 튜토리얼이 있었습니다.
그 주에 바빠서 정리를 못했는데 너무 delay 되다 보면 다루지 못하고 넘어갈 것 같아 서둘러 정리합니다.

앱을 만들다 보면 애니메이션을 사용할 때도 있고 꼭 애니메이션을 사용하지 않아도 많은 이미지 파일을 사용하게 됩니다.
disk에서 이미지를 불러와서 rendering 하고 화면에 display 하는 과정은 device의 resource를 많이 사용하는 아주 expensive 한 작업입니다.
너무 많은 이미지 사용은 앱의 용량도 크게하고 퍼포먼스에도 안 좋은 영향을 줍니다.

이번에 Corona에서 image sheet라는 새로운 API를 제공하면서 이러한 이미지 처리를 효율적으로 할 수 있는 방법을 제공하고 있습니다.

저도 Fire Man (Fire fighter)  앱이 너무 많은 애니메이션 기능 사용으로 아이폰 3GS나 구식 안드로이드 폰에서는 퍼포먼스가 아주 느려서 고민이 많았거든요.

다음 앱을 개발할 때는 이 image sheet를 사용해서 퍼포먼스에 문제가 없도록 해야 할 것 같습니다.

Corona build 2012.759 버전에 그래픽 관련 새로운 기능이 추가 됐습니다.
오늘은 이 기능에 대해 알아보겠습니다.

아주 많은 부분이 다뤄질 예정이니 주의를 집중해서 보세요. 조금 어렵기도 합니다. 아마 중급정도 수준의 튜토리얼이라고 할까요? 오늘 다룰 부분 중에는 이전의 Corona Doc나 튜토리얼에 나왔던 개념이 아닌 전혀 새로운 개념들도 있습니다.
오늘의 세가지 주요 topic은 아래와 같습니다.
- Image Sheets (새로운 기능)
- Image Groups (새로운 기능)
- Sprite (완전히 바뀜)

아래 다뤄지는 기능은 Corona sdk build 2012.759 버전 이상에서만 작동 됩니다. 그리고 build 2012.761 버전 이상을 사용하실 것을 권장합니다. 오늘 소개할 기능과 관련돼 약간 수정된 내용이 761버전 이후 부터 적용됐거든요.

Notes on Performance

Graphics의 많은 부분이 바뀌었고 그것과 더불어 performance 향상을 제공합니다. 특히 iPhone 3GS 같은 조금 오래된 기계에서 퍼포먼스가 안좋았던 부분이 많이 개선 됐습니다. 하지만 개발자로서 항상 유념해야 될 것은 잘 구성된 코드가 퍼포먼스 향상의 가장 기본이라는 것입니다.

Image Groups 같은 경우에는 어느 부분에서는 좋은 점을 제공하지만 또한 어느 부분에서는 사용하는데 제한이 있을 수 있습니다.
이 새로운 기능들을 사용할 때 이 잇점과 제한된 점을 잘 생각해서 best 한 선택을 하셔야 합니다.

그리고 또 하나의 좋은 소식은 최근의 코로나 버전에서 다른 방법으로 퍼포먼스 향상 효과를 주었는데요. 그것은 바로 화면 밖에 있는 객체에 대해서는 렌더링이 일어나지 않도록 만들었다는 것입니다. 이 방법은 따로 코딩을 바꾸실 필요는 없습니다. 그냥 최근 버전의 코로나를 다운 받으셔서 새로 빌드 하시면 됩니다.

Image Sheets

이 API는 이번에 새로 나온 기능 입니다. 전문 용어에 익숙하신 분은 texture atlas  기능이라고 하면 이해하시기 쉬우실 겁니다.

이해를 돕기위해 좀 은유적으로 설명을 드리자면 여러분 앱의 모든 이미지들이 한장의 종이에 있고 그 종이의 부분 부분을 가져와서 한개의 이미지처럼 사용할 수 있도록 합니다. 그러면 메모리를 줄일 수 있고 이미지 렌더링 시간도 줄일 수 있어서 큰 퍼포먼스의 향상을 가지고 올 수 있습니다.

disk에서 이미지를 메모리로 불러와서 그것을 렌더링 해서 앱에 표시하는 작업은 아주 비싼(에너지 소비가 많은) 작업입니다. 그래서 각각의 이미지별로 이 작업을 하도록 하기 보다는 여러 이미지를 하나의 이미지화 해서 이런 비싼 작업을 한번만 할 수 있도록 하는게 기본 개념입니다.

Texture Size Limit

한 개의 이미지 파일에 몇개의 실제 이미지를 넣을 수 있는지에 대한 제한은 없다. 하지만 이 부분은 유념해야 한다. 각 디바이스 마다 최대 texture size의 제한이 있다. 한개의 이미지 파일의 width,height에 대한 픽셀 수에 대한 제한값이다. 그러므로 한 이미지 파일안에 몇개의 실제 이미지가 들어가는지는 제한이 없지만 이미지 파일  크기가 너무 크면 사용할 수 없다. (그러면 이론적으로는 디바이스가 허용하는 최대크기의 이미지 파일의 픽셀 수가 최대 하용할 수 있는 이미지 갯수겠네요. 1픽셀짜리 이미지를 사용한다면.. 실제 그렇지는 않겠지만요.. 그러면 그건 이미지가 아니라 그냥 color가 있는 점이겠죠?  그냥 심심해서 상상해 봤어요... ^^)

아래 코드는 해당 디바이스에서 허용하는 texture 의 최대사이즈를 구하는 방법입니다.

print( system.getInfo( "maxTextureSize" ) )

대개 코로나가 지원하는 디바이스들은 허용 사이즈가 아주 크다는 겁니다. 여러분 앱에 수백개의 이미지 객체들이 들어간다고 하더라도 몇 개의 이미지 sheet만 사용해도 충분히 해결이 될 겁니다.

Wait, I’m already doing this!

여러분들 중에는 이전의 Sprite API를 사용해서 이러한 기능들을 이미 사용해 보신 분들도 많이 계실 겁니다. 이전의 Sprite API에서는 애니메이션을 사용하기 위한 기능을 주로 지원했습니다. 그래서 애니메이션이 아닌 정적인 이미지를 만들려면 불필요한 부분들이 많이 있습니다. 메모리를 절약하기 위해 이 Sprite API를 사용한다는 건 좀 부담스러운 일이죠.

그래서 이 image sheet를 지원하게 됐습니다. 이 image sheet API를 사용하면 훨씬 더 효율적으로 그리고 쉽게 사용할 수 있습니다. 이 API를 사용하면 정적인 이미지와 애니메이션 모두에서 사용하실 수 있습니다.

보너스가 한가지 더 있는데요. image sheet는 해상도별로 이미지를 다이나믹하게 지원해주는 기능이 있습니다. (예: retina graphics) 이전의 sprite API에서는 이 같은 기능을 구현하기 위해서는 조금 복잡하게 해야 합니다. 이 의미는 이 기능을 사용하면 이번에 해상도가 아주 높아져서 나온 새 애플(Apple)의 아이패드(New iPad) 에도 자동적으로 이미지가 맞게 지원된다는 겁니다.

How to Use Image Sheets

이제 이 image sheets를 어떻게 사용하는지 알아보겠습니다. 우선 신택스부터 보겠습니다. 그리고 나서 display.newImage()와 display.newImageRect()와 함께 어떻게 image sheets가 사용되는지 알아보는 예제를 다뤄보겠습니다. 이 image sheets를 image group과 sprite animation과 함께 사용 하실 수도 있습니다.

Image Sheet Syntax:
graphics.newImageSheet( filename, [baseDir, ] options )

아주 간단하죠? 파라미터 filename은 실제 image file의 이름이구요. baseDir은 디렉토리 입니다. (system.ResourceDirectory 가 될 수도 있고 아니면 다른 곳이 될 수도 있죠.) options 파리미터는 필수로 이 image sheet의 프레임에 대한 데이터를 가지고 있는 테이블을 가리킵니다.

혼란을 방지하기 위해 image는 image sheet file로 graphics.newImageSheet()로 불러온 파일을 말하고 frame은 그 image sheet안의 각각의 이미지들을 구분해서 말하고 있습니다.

options

option 테이블에는 세가지 케이스가 있을 수 있습니다.

    Simple: image sheet의 모든 frame들이 각각 같은 width와 height를 가질 경우
    Complex: image sheet의 frame들이 각각 다른 width나 height를 가질 경우
    Old-Style:  sprite API 데이터 포맷과 같은 방법입니다. (이전에는 sprite.newSpriteSheetFromData() 함수를 사용했었습니다.)

old style은 이제는 권장하지 않습니다. simple이나 complex 케이스 중 하나만 선택하시면 됩니다. old style에 대해서는 따로 다루지 않겠습니다. 이 케이스가 있는 이유는 이것을 이용하던 다른 third-party 툴들이 있기 때문에 아직 없애지 않은 겁니다.

Simple Example

예제를 하나 소개해 드리겠습니다. 우선 image sheet를 로딩할 때 simple option을 사용하는 방법을 보죠. 다시한번 언급하면 image sheet 내의 모든 frame이 각각 같은 width와 height를 가지고 있는 경우 이 simple option을 사용합니다.

local options =
{
    -- The params below are required
   
    width = 70,
    height = 41,
    numFrames = 2,

    -- The params below are optional; used for dynamic resolution support

    sheetContentWidth = 70, -- width of original 1x size of entire sheet
    sheetContentHeight = 82 -- height of original 1x size of entire sheet
}

local imageSheet = graphics.newImageSheet( "fishies.png", options )

예제에서 보시듯이 simple case option은 진짜로 simple 합니다. options에 들어가는 파라미터는 width,height,numFrames 이렇게 3개밖에 없습니다. 남은 2개의 optional 파리미터들은 dynamic resolution images를 사용할 경우 필요한 겁니다. (예를 들어 retina graphics 를 사용하기 위한 image sheet의 @2x 버전 같은)

Complex Example

image sheets에 여러 다른 객체들을 넣어서 사용할 경우 complex-case option 테이블을 사용해야 합니다. 이 경우 각각의 frame에 대해 정해줘야겠죠.

local options =
{
    -- array of tables representing each frame (required)
    frames =
    {
        -- FRAME 1:
        {
            -- all params below are required for each frame
            x = 2,
            y = 70,
            width = 50,
            height = 50
        },
       
        -- FRAME 2:
        {
            x = 2,
            y = 242,
            width = 50,
            height = 52
        },
    },

    -- optional params; used for dynamic resolution support
    sheetContentWidth = 1024,
    sheetContentHeight = 1024
}

local imageSheet = graphics.newImageSheet( "imageframes.png", options )

위 예제를 보시면 image sheet는 두개의 frame을 가지고 있습니다. simple case와는 조금 다르죠? 왜냐하면 각각의 frame들을 array로 그 값을 지정해줘야 하기 때문입니다. image sheet의 complex-case option 테이블을 이용할 경우 이 예제를 참고로 작성하시면 됩니다.

Using with Existing Image Functions

다음으로는 image sheets로부터 얻어낸 각각의 객체들을 기존의 함수들인 display.newImage()와 display.newImageRect()을 가지고 어떻게 사용해야 하는지를 알아보겠습니다.

일단 image sheet를 이용해서 이미지 객체를 이미 만들었다고 가정한 후 아래 예제를 살펴 보세요.
-- assumes 'options' is already constructed (simple or complex cases)
local imageSheet = graphics.newImageSheet( "myimagesheet.png", options )

-- display.newImage()
--
-- SYNTAX:
-- display.newImage( [parent ,] sheet, frameIndex )

local fish = display.newImage( imageSheet, 2 )
fish.x, fish.y = 100, 100

-- display.newImageRect()
--
-- SYNTAX:
-- display.newImageRect( [parent ,] sheet, frameIndex, width, height )

local frog = display.newImageRect( imageSheet, 4, 40, 82 )
frog:setReferencePoint( display.TopLeftReferencePoint )
frog.x, frog.y = 0, 10

보시다시피 일반적으로 display.newImage()나 display.newImageRect()함수를 사용하는것과 크게 다르지 않습니다. 다른 점은 image sheet를 사용할 경우 특정 filename 대신 해당 frame index number를 사용한다는 것입니다.

여러분들이 image sheet를 로딩할 때 simple을 사용했던지 complex를 사용했던지 상관없이 위 예제처럼 사용하시면 됩니다. (old-style을 사용해도 마찬가지 입니다.)

Power of 2 Dimensions

build 2012.264를 보시면 power of 2 에 대한 제한이 있었습니다. 지금은 이 image sheet를 사용하면서 이 제한이 없어졌습니다. 그 제한들은 width와 hight가 8, 16, 32, 64, 128, 256, 512, 1024, 2048 .... 사이즈에 부합되야 한다는 것이었습니다. 하지만 image sheets를 사용하면서 이런 제약은 없어졌습니다. 하지만 texture memory 관리 등을 생각하면 이 power of 2 에 대한 규칙을 지키는 것이 좋습니다.

Removing Image Sheets

image sheet를 remove하려면 image sheet를 사용하는 객체를 그냥 remove 하시면 됩니다. (image objects, sprites, image groups 등) 그리고 나서 image sheet를 nil로 선언하세요.

아래 예제가 있습니다.

-- obj1 and obj2 are using the image sheet
obj1:removeSelf()
obj1 = nil

obj2:removeSelf()
obj2 = nil

-- remove reference to the image sheet
imageSheet = nil


======= o =====  o ====== o ======== o ========

내용이 길어서 2회로 나눠 싣습니다.
다음 글에서는 Image Groups() , Sprites 등에 대해 다룰 겁니다.

코로나 SDK에서 안드로이드용 In-App Purchase 관련  API를 내 놨습니다.
이제 아이폰,안드로이드폰 모두에서 코로나로 개발한 In-App Purchase기능을 사용할 수 있게 됐습니다.

아래 이번주에 Corona SDK에서 배포한 안드로이드 In-app Billing 튜토리얼을 정리했습니다.

여러분도 참고하세요.

======o ===== o ===== o ===== o ===== o =====

Getting Started with Android In-app Billing

앱을 통해서 돈을 벌 수 있는 방법은 유료 앱으로 publish를 하던가 광고를 달던가 아니면 가상 머니를 사용하는 방법이 있습니다.
그 외에 in-App Billing이 있는데요. 이번에 Corona SDK에서 안드로이드용 In-App Billing 기능을 발표했습니다.

이 in-App Purchase 기능은 모바일 앱을 이용한 많이 애용되는 비지니스 모델인데요 이것을 다른 말로 freemium 이라고 합니다. freemium은 일단 무료로 제공하고 그 외의 고급 기능이나 아이템을 유료로 구매할 수 있도록 하는 것을 말합니다.
모바일 앱의 경우는 다음 레벨로 가거나 특별한 아이템을 구한다던가 virtual currency를 사용하던가 하는 기능을 넣을 수가 있을 겁니다.

유저가 구매를 approve하면 새로운 컨텐츠가 unlock 되거나 외부 소스로부터 다운로드 되던가 할 겁니다.
이 방법을 사용하면 아주 다양한 방법의 수익 모델을 만들어 낼 수 있습니다. 그리고 이번에 Corona SDK에서 안드로이드 용으로 이 기능을 지원했기 때문에 그 다양한 수익 모델을 Corona SDK로 개발하면서도 사용할 수 있습니다.
아이폰 앱에는 이미 이 기능이 지원됐기 때문에 코로나 개발자들은 두개의 시장에서 이 기능을 이용할 수 있게 되겠죠? 이것이 Corona SDK 같은 cross-platform development tool의 매력이라고 할 수 있을 겁니다.

하지만 이 좋은 기능도 개발자나 기획자가 사용할 줄 모르면 아무 소용이 없을 겁니다. 이 기능을 이용하려면 최신버전의 Corona SDK가 있어야 합니다. (현재는 유료 사용자만이 다운 받을 수 있습니다.)

Getting Started

시작하기 전에 여러분이 준비해 두셔야 할 부분이 있습니다.
1. Corona SDK build 2012.769 이후 버전
2. Indie-Android나 Corona Pro 유료 사용자 일 것
3. Android Developer 계정을 가지고 있을 것

1. Android Deveoper Console
안드로이드 내에서 billing이 가능하게 하려면 BILLING 퍼미션이 build.settings에 세팅 돼 있어야 합니다. 그리고 이것을 Android Developer Console에 없로드해서 당신의 앱이 In-App Billing Products를 시작할 수 있도록 만들어 두어야 합니다.
main.lua에 아무런 코딩이 안 돼 있어도 이 작업을 해야 합니다. 그리고 지금 개발이 진행 중이라도 상관없습니다. 어쨌든 우선 이 step을 밟아야 합니다. 여러분의 앱에 In-app 상품을 넣을 수 있으려면 우선 이 과정을 거쳐야 하는게 구글이 만들어 놓은 룰입니다.
당신의 앱이 이미 판매중이거나 마켓에 오픈돼 있는 상태라도 이 기능을 넣으려면 우선 build.settings에 퍼미션을 넣고 업로드 한 다음에 In-App purchase 기능을 개발해야 합니다.
한번 이렇게 해 두면 Android developer console의 해당 앱 밑에 in-app products라는 링크를 클릭해서 이곳에서 올린 in-app 상품을 보실 수가 있습니다.

build.settings에 BILLING 퍼미션을 넣는 방법은 아래와 같습니다.

settings =
{
    orientation =
    {
        default = "landscapeRight",
    },

    android =
    {
        usesPermissions =
        {
            "com.android.vending.BILLING",
        },
    }
}

이 예제에서 주의깊게 보셔야 할 점은 android - usesPermissions의 com.android.vending.BILLING 부분 입니다.
이 부분은 orientation을 지정한 settings 다음에 위치해 있습니다.
 
이렇게 하신 후에 android 앱으로 build하세요. 그리고 그 apk화일을 android developer console에 업로드 하시면 됩니다.

아직까지는 Publish를 하지는 마세요.

그렇게 한 다음부터 In-app 제품을 넣기 위한 Administering In-app Billing Guide를 진행 하실 수 있습니다.

안드로이드 개발자로서 마켓에 앱을 올려보신 분들은 아시겠지만 앱을 다 개발 한 다음에 publish를 해야하는데요. 요즘은 이것을 또 Activate 하는 단계도 생겼더라구요.
혹시 나중에 앱을 다 만들고 나서 마켓에 올리고 테스트 할 때 주의하세요.

Google Documentation

구글 Guide에 대해서는 위에 링크를 걸어 놓기는 했지만 여기에 대해서는 한번 언급하고 넘어가는게 좋을 것 같습니다.

구글에서는 In-app Products를 어떻게 셋업해야 하는지에 대해 꽤 좋은 가이드를 제공하고 있습니다. 그리고 그것을 쉽게 테스트 할 수 있도록 했구요.
만약 여러분이 Android Developer Console쪽에서 어떻게 세팅해야 하는지를 자세히 알고 싶으시면 아래 두 가이드를 참고하세요.

• Setting up In-app Billing products for your apps.
• Testing In-app Billing Products

2. The Corona "store" API

이 튜토리얼에서는 구글에서 제공하는 test product identifier들을 사용하겠습니다.
이 테스트 상품에서는 아래 세가지 Action을 가져올 수 있습니다.

- android.test.purchased : 구매가 성공했을 때 얻어 옴
- android.test.canceled : 구매 트랜잭션이 cancel 됐을 때 얻어 옴
- android.test.item_unavailable : 해당 제품 구매가 가능하지 않을 때 얻어 옴

이 테스트 상품의 진짜 nice 한 점은 이렇게 각각 다른 상황에서 여러분들이 이를 어떻게 쉽게 콘트롤 할 수 있을 지 경험할 수 있게 해 준다는 점 입니다. 예를 들어 여러분은 android.test.canceled 상품을 이용해서 유저가 트랜잭션 중 cancel했을 경우에 대한 코딩을 할 수 있게 됩니다.

store.init("google", transactionCallback)

여러분이 코딩을 하면서 이 in-app purchase 기능을 구현하기 위해서는 제일 처음 store.init() API를 사용하게 될 겁니다. 파라미터로는 구글 마켓(얼마전 Google Play로 바뀌었습니다.)을 사용할 거라는 것을 알리는 "google"을 첫번째로 넣고 두번째로는 불러올 함수 명을 넣습니다.

아래 transaction callback listener 함수와 함께 store.init()을 사용하는 방법에 대한 샘플 예제가 있습니다.

local function transactionCallback( event )
    local transaction = event.transaction

    if transaction.state == "purchased" then
            -- Transaction was successful; unlock/download content now
   
    elseif transaction.state == "restored" then
           -- You'll never reach this transaction state on Android.

    elseif transaction.state == "refunded" then
        -- Android-only; user refunded their purchase
        local productId = transaction.productIdentifier
        -- Restrict/remove content associated with above productId now
  
    elseif transaction.state == "cancelled" then
        -- Transaction was cancelled; tell you app to react accordingly here

    elseif transaction.state == "failed" then
            -- Transaction failed; tell you app to react accordingly here
     end

    -- The following must be called after transaction is complete.
    -- If your In-app product needs to download, do not call the following
    -- function until AFTER the download is complete:

    store.finishTransaction( transaction )
end

store.init( "google", transactionCallback )

맨 아래 store.init()이 transactionCallback 함수를 call 하는 보분이 있죠? 이 부분이 Android In-app Billing 이벤트가 발생 했을 때 실행 될 부분입니다.

Handling Refunds

Android In-app billing은 iOS의 In-app billing과 거의 같은데 한가지 refunded라는 트랜잭션 상태가 더 있습니다. iOS와는 다르게 안드로이드 플랫폼에서는 유저가 refund할 수 있도록 해 줍니다. 그래서 유저에게 주었던 contents를 다시 가져오려면 바로 이 refunded 트랜잭션 상태일 때 해야 할 것입니다.

위 샘플에서 보듯이 refunded 트랜잭션 상태에서 받는 중요한 데이터는 event.transaction.productIdentifier입니다. 이 정보를 가지고 여러분은 필요한 작업을 하실 수 있습니다. 아마도 그 필요한 작업은 환불 했을 경우 해당 content를 다시 block 시키는 거겠죠? 아니면 돈을 내고 추가로 다운 받은 파일을 지우는 기능이던가요.

No "restored" State on Android

store.restore() 함수는 로그인 된 유저 계정과 연관된 product id의 리스트를 다시 검색할 수 있도록 해 줍니다. iOS에서는 이 product 리스팅이 transactionCallback listener 의 restored 트랜잭션 상태에서 받을 수 있습니다. 그리고 안드로이드에서는 이 restored 트랜잭션 상태가 없습니다. 대신에 그 상품이 purchased를 다시 실행하면서 그 기능을 할 수 있습니다.
아주 작은 차이이지만 transactionCallback listener 함수를 디자인할 때 잘 고려해서 디자인을 해야 합니다.

Other Transacton Event Data

transaction events와 관계된 다른 모든 데이터들은 iOS의 In-app purchase와 동일합니다. 그러니까 다음 guide를 꼭 봐 주세요.
In-app  Purchase Guide
Transaction Listener Callback Events
그리고 예전에 in-Purchase app 샘플을 분석했던 글을 보시면 도움이 되실겁니다.
코로나 네트워킹 과 웹 서비스 3 (In App Purchase 1)

store.finishTransaction (transaction)

위 샘플 코드에 있는 transactionCallback() 함수에 있는 모두 아주 중요한 것들입니다.
store.finishTransaction은 모든 트랜잭션의 마지막부분에 반드시 call 되야 합니다.
어떤 트랜잭션이 끝났다는 것을 확실히 정의하는 부분입니다.
만약 어떤 파일을 다운로드 받아야 할 때는  어떤 상황이 발생할 까요? 아마도 이 다운로드가 모드 끝나고 나서 store.finishTransaction()이 call 되어야 할 겁니다. (그러려면 어딘가에 network.download() 리스너가 있어야 겠죠.)

만약 이미 코딩은 최초 다운받은 앱에 다 돼 있고 단순히 어떤 content를 unlock 하는 기능만 수행될거면 callback 리스너 마지막 부분에 store.finishTransaction()을 넣으면 되겠죠.

두 경우 모두 첫번째 인수로 event.transaction 테이블을 넘겨줘야 한다는 것을 잊지 마세요.
 store.finishTransaction( event.transaction )

3. Purchasing Products

이제 purchases, refunds, failed/cancelled 같은 트랜잭션들을 어떻게 다뤄야 할 지 알아 보겠습니다. iOS in-app purchase에서와 같이 store.purchase()를 사용해서 트랜잭션을 초기화 합니다. 대개 앱 화면에서 Buy 버튼을 누르면 이벤트 리스너가 감지해서 call할 때 이 동작이 이뤄 집니다.
-- single product purchase
    store.purchase( { "android.test.purchased" } )

-- multi-item purchase
   store.purchase( { "android.test.purchased", "android.test.canceled" } )

여기서도 Google에서 제공하는 테스트 product들을 사용해서 테스트 해 볼 수 있습니다.
좀 더 자세한 정보를 보시려면 store.purchase() documentation 을 참고하세요.

Cross-Platform Development

코로나의 장점은 한번의 코딩으로  아이폰, 안드로이드 용 앱을 만들 수 있는 multi-platform 기능입니다. 이 기능을 좀 더 쉽게 콘트롤 할 수 있도록 코로나에서는 store API에 새로운 프로퍼티를 추가했습니다.
애플의 In-app Purchase는 iOS 디바이스들에서만 가능하고 안드로이드의 In-app Billing은 Google Play에서만 가능합니다. (같은 안드로이드 앱이라도 Nook나 Kindle Fire 에서는 In-app Billing을 사용할 수 없습니다.)
새로 제공되는 기능은 store.availableStores 테이블로 어떤 디바이스 인지를 알수 있는 파라미터 입니다.

아래 예제가 있습니다.

if store.availableStores.apple then
    store.init("apple", transactionCallback)
   
elseif store.availableStores.google then
    store.init("google", transactionCallback)
end

이렇게 코딩을 하면 아이폰용과 안드로이드 용 파일을 따로 관리할 필요가 없겠죠?

iOS의 In-app Purchases와 Android의 In-app Billing은 한가지 크게 다른 개념이 있습니다. 안드로이드에서는 각각의 In-App product들에 대해 정보를 retrieve할 수 없는 반면에 iOS에서는 이 기능이 가능합니다. 이것은 구글의 한계라고 볼 수 있겠죠. 이 의미는 상품의 이름, description같은 정보들을 직접 앱 내에서 혹은 외부 서버에서 개발자들이 직접 관리해야 한다는 얘기 입니다. (만약에 필요하다면요.)

이 다른 점 때문에 store.loadProducts() 함수가 있는데 이것은 iOS in-app purchases에서만 사용될 수 있습니다. 여러분이 iOS,안드로이드 두 플랫폼 모두에서 돌아가는 앱을 개발하고자 한다면 이 함수가 가능한지 여부를 체크하기 위해서 store.canLoadProducts 프로퍼티를 사용하실 수 있습니다. (store.init()에서 pass된 플랫폼이 무엇인가에 따라 true와 false를 return 하게 됩니다.)

 Additional Resources

Android In-app Billing 을 테스트 하시려면 구글에서 제공하는 테스트 상품으로 쉽게 테스트하실 수 있구요. 또 여러분이 만든 상품으로도 쉽게 테스트 하실 수 있습니다. 이번에 새로 제공되는 Corona SDK 내의 InAppPurchase 샘플 코드를 참조하세요.
/SampleCode/Networking/InAppPurchase 에 있습니다.

그리고 예전에 iOS in-app purchase와 관련해서 올려 놓은 In-app Purchase Guide도 보시구요. iOS용 가이드 이지만 대부분이 안드로이드에서도 적용 됩니다. 그리고 각각의 store API 함수에 대한 정보를 보시려면 In-app Purchase API Reference를 보시기를 권장합니다.

이 기능은 Corona Daily Build 2012.760 이후 버전에서만 가능합니다.
현재까지 이 버전은 유료 사용자만 받으실 수 있습니다.

======o ===== o ===== o ===== o ===== o =====

요즘 예전처럼 폭풍집필이 잘 안되네요.
슬럼프인가봐요.. 휴~~~~~~~
여러분의 추천이 큰 힘이 될 수 있을 것 같아요.
추천 부탁드려요.

추천.. 추천.. ~~~ ~~~ 감사.. 감사..

요즘 사무실 이사에 이런 저런 일들이 많이 생겨서 블로그 글 올리는 일이 뜸해졌습니다.

어느 정도 일이 정리 되면 다시 열심히 Study 해서 이 블로그에 정리 해 놓을께요. 그리고 댓글 올리신 분들도 많이 계신데 미처 답글을 드리지 못했습니다. 이번주에 질문 올리신 분들 제가 research 하고 직접 테스트 한 답을 구해서 답글 올릴께요.

오늘은 코로나에서 새로 나올 Corona Level Editor 에 대한 아이콘 콘테스트가 있어서 이 소식을 소개합니다.

아래 글은 Corona sdk를 만든 회사인 Ansca 의 CEO 인 Carlos 가 올린 글입니다.

===== o ===== o ===== o ===== o =====

Corona Level Editor Icon Challenge

Posted on March 13, 2012 by carlos