3

アプリ内購入の構成方法を決定しています。私の目標は、独自のサーバー インフラストラクチャなしでそれを行うことです。

私のアプリは、電子メールでエクスポートされる PDF 形式のレポートを生成します。レポートの数を 3 つに制限したいと思います。それを超えると、別の 3 つを購入する必要があります。レポートのすべてのデータとレポート自体は、デバイス上でローカルに作成されます。

Non-Consumableこれはタイプであるべきですか？ドキュメントには、これは一度だけ購入する必要があると記載されているため、そうではないかもしれません. しかし、ユーザーがさらに 3 つまたは 10 個のレポートを再度購入できるようにしたいと考えています。ただし、このタイプは、アプリがインストールされているすべてのデバイスで自動的に利用できるようにする必要があるとも書かれています。

それとも型にするべきConsumable？繰り返しますが、これは適合していないようです。ドキュメントには、「ユーザーがそのアイテムを必要とするたびに購入する必要がある」と記載されています。. 概念的には、これは近いように思えますが、たとえば、iPhone で 2 つのレポートが消費され、すべてのデバイスで 1 つのレポートが引き続き利用可能である場合、どのように追跡すればよいでしょうか?

除外できると思いAuto-Renewable Subscriptionます。

多分それはである必要がありNon-Renewable Subscriptionます。ただし、レポート クレジットに有効期限を設定したくありません。また、理想的には、レポート クレジットがすべてのデバイスに伝播する必要がありますが、このタイプではこれも提供されません。

すべてのデバイスへの伝播については、喜んで妥協します。クレジットは正確に追跡され、無制限に購入できる必要があります。

これをアプリにどのように実装しますか? NSUserDefaultsエクスポートボタンを有効にする前にチェックされる数字だけですか？レポートがエクスポートされるたびに StoreKit 経由で何らかの方法でチェックすることは可能ですか? (これは電子メール エクスポートなので、とにかくオンラインであることが前提条件です)。

独自のサーバー インフラストラクチャを回避することは可能ですか? そうでない場合、何を追跡する必要がありますか?

何か考え、ガイダンス、推奨事項はありますか?

4

2 に答える 2

2

Black Frog の回答で述べたように、Apple 側に依存することは、サーバー インフラストラクチャを回避するためだけに、より難しい回避策になる可能性があります。古い購入を取り消して、ユーザーが何を費やし、何が残っているかを計算する必要があります。そのためにも、サーバーが必要になると思います。

消耗品のアプリ内サイクル全体をバラバラにしようとします。

  • アプリ内のクライアント側を実装する (iOS)
  • サーバー側の場合は、次のものが必要です。(最小限の労力)
    • 2 つのテーブル。1 つはユーザーとその残りの使用時間 (クレジット) を保持し、もう 1 つは購入レポートを保存します。
    • 2 つのスクリプト (PHP では数行で簡単です) 1 つはクレジットを減らすため、もう 1 つは Apple からの領収書情報を保存し、それを検証するためのものです。

基本的に、アプリ内のサーバー側を実装するためにインフラストラクチャ全体は必要ないので、怖がらせないでください。私が見る限り、ユーザーに販売するすべての情報を保持する方が、Apple 側に頼るよりも安全です。

ここで注意すべきもう 1 つの重要な点は、アプリ内購入が偽造される可能性があることです。これを防ぐ唯一の方法は、購入した領収書を確認することです。こちらをご覧ください。また、php スクリプトを使用すると、これがはるかに簡単になることにも注意してください。取得した領収書を送信して、ユーザーのデバイスから検証に送信しようとすると、そのためのクラス全体を実装することになります。

何か思い当たることがあれば教えてください。

于 2012-11-02T19:28:01.793 に答える
0

独自のサーバーインフラストラクチャを作成したくないため、ユーザーはアプリを使用して最高のエクスペリエンスを得ることができません。さまざまな種類のアプリ内購入を少しの間忘れてください。暗号化されたファイルでユーザーがデバイス上で生成できるレポートの数を追跡するとします。ファイルがにあるとしましょうNSApplicationSupportDirectory。

アプリ固有のファイルを保存する場所の決定に関するAppleDocsからの抜粋：

  • アプリがユーザーのために作成および管理するリソースファイルとデータファイル。このディレクトリを使用して、アプリの状態情報、計算またはダウンロードされたデータ、さらにはユーザーに代わって管理するユーザー作成データを保存できます。
  • ファイルを自動保存します。
  • iOSでは、このディレクトリの内容はiTunesによってバックアップされます。

したがって、ユーザーがアプリ内購入を行うたびに、その量だけカウントを増やします。そして、ユーザーがドキュメントを生成するたびに、私はそれを減らします。そしてiCloudでは、この情報はユーザーが所有するすべてのデバイスにあります。

これは、悪いユーザーエクスペリエンスが発生する可能性がある場所です。デバイスが1つあり、レポートを5つ購入したとします。使用しているのは2つだけです。デバイスのストレージが不足していて、アプリを一時的に削除したいとします。再度インストールすると、クレジットにある3つのレポートが失われます。これが、購入の追跡/履歴とレポートがいつ生成されたかを追跡するためのサーバーが必要な理由です。

于 2012-11-02T14:54:30.877 に答える