(coronaでの)iOSアプリのアプリ内課金実装時の注意点in work

 
date:2011.08.04   posted by:hata
 

秦です。

少し前に、coronaを利用してアプリ内課金が必要なiOSアプリをリリースしましたので、その際に感じた注意点をまとめました。

1. 情報取得のタイムラグ
通信状況にも左右されるが、coronaのAPIを利用する場合、アプリ起動直後に課金アイテム情報を取得する処理を記述しても、取得までに若干のタイムラグがあるので注意が必要です。
可能ならば、起動直後1秒くらいは初期画面を表示して操作不能にするか、または購入画面までいくつか画面遷移を挟むなどして時間を稼いだほうが良いかも知れません。

ネイティブ開発だと同期処理で同期して取得処理終了まで次の処理を行わないようにする選択も有りですが、どちらにしても通信状況によってはかなり時間がかかる可能性もあるので、ローディング画面の表示と、一定時間レスポンスがない場合の処理は必須そうです。

2. プロダクトIDのレスポンス順序
これはcoronaは関係ないが、プロダクトIDから課金アイテム情報を取得する際、アイテム情報がリクエスト順ではなくプロダクトID先頭文字のアルファベット順で返却されるので注意が必要。
厳密には 「数字 → 大文字アルファベット順 → 小文字アルファベット順」で返ってくる。

例えば以下の順でリクエストした場合、
example1.test.id
Example2.test.id
3example.test.id
test4.test.id
Test5.test.id

返却値は以下の順になる。
3example.test.id
Example2.test.id
Test5.test.id
example1.test.id
test4.test.id

返却値を順に回して処理を行う場合などは気をつけておく必要があるでしょう。
返却順を気にしたくない場合は、プロダクトIDの第一小節をキーにした連想配列で返却値を管理するという方法が良いかも知れません。

3. 課金アイテム数の増減による対応
運用が絡む場合、課金アイテムが増えたり減ったりすることがあります。

例えば
tanaka.test.id
watanabe.test.id
aoyama.test.id

というプロダクトについてリクエストをかけていた場合、返却順は

aoyama.test.id
tanaka.test.id
watanabe.test.id

となるが、ここにもし新たなID「endou.test.id」が入ったとすると返却順は

aoyama.test.id
endou.test.id
tanaka.test.id
watanabe.test.id

となる。

つまり、これまでは「tanaka」プロダクトの処理をしていた順番に「endou」が割り込み、以降のプロダクトの処理順が1つずつ後ろにずれることになる。
よって返却された情報をもとに購入ボタンを順番に生成していた場合、2番目に作られるボタンは「tanaka」を購入するものではなく 「endou」を購入するボタンになるため、この点を注意する必要があります。

更新時に、プロダクトIDをもとに返却順がどうなるか確認する必要がある。

それよりは、予め

a000.test.id
a100.test.id
a200.test.id
a300.test.id

ようにIDを設定しておき、末尾にプロダクトを加えたい場合は「a400.test.id」を追加、途中に割り込ませたい場合は 「a150.test.id」を追加、のようにID側から順番を管理する方法が楽だと思いますが、管理画面でユニークな文字列が表示しないので、その点でまた面倒かも知れません。

best resume writing service
 
Copyright © TheDesignium inc. powered by WordPress & mootools.
Relative Keyword|none