You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.mdown
+17-5Lines changed: 17 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -41,20 +41,31 @@ Usage
41
41
Subclassing AbstractBillingActivity
42
42
-----------------------------------
43
43
44
-
[AbstractBillingActivity][2] is an abstract activity that provides default integration with in-app billing. It is useful to get acquainted with the library, or for very simple applications. For more flexibility use [BillingController][3] instead.
44
+
[AbstractBillingActivity][2] is an abstract activity that provides default integration with in-app billing. It is useful to get acquainted with the library, or for very simple applications that require in-app billing integration in only one activity. For more flexibility use [BillingController][3] instead.
45
45
46
-
When started your [AbstractBillingActivity][2]subclass will check if in-app billing is supported, followed by a call to `onBillingChecked(boolean)`, which has to be implemented by the subclass.
46
+
When created your [AbstractBillingActivity][2]instance will check if in-app billing is supported, followed by a call to `onBillingChecked(boolean)`, which has to be implemented by the subclass.
47
47
48
-
Additionally, the first your [AbstractBillingActivity][2] subclass runs it will attempt to restore all transactions. This is necessary in case the user has previously installed the app and made purchases. Existing transactions will generate calls to `onPurchaseExecuted(String)`, `onPurchaseCancelled(String)` and `onPurchaseRefunded(String)` accordingly, all of which have to be implemented by the subclass.
48
+
Additionally, your [AbstractBillingActivity][2] subclass will attempt to restore all transactions, only once. This is necessary in case the user has previously installed the app and made purchases. Existing transactions will generate calls to `onPurchaseExecuted(String)`, `onPurchaseCancelled(String)` and `onPurchaseRefunded(String)` accordingly, all of which have to be implemented by the subclass.
49
49
50
50
Starting a purchase is as simple as calling `requestPurchase(String)`. [AbstractBillingActivity][2] will start the Android Market intent automatically and `onPurchase{State}(String)` will be called after the transaction is confirmed.
51
51
52
+
If you override any of the methods provided by [AbstractBillingActivity][2], make sure to call the superclass implementation.
53
+
52
54
BillingController
53
55
-----------------
54
56
55
57
[BillingController][3] provides high-level functions to interact with the Billing service and to query an obfuscated local transaction database.
56
58
57
-
Since most billing functions are asynchronous, [BillingController][3] notifies all registered [IBillingObserver][4] of the responses. Additionally, [BillingController][3] requires a `BillingController.IConfiguration` instance from which the public key required to validate signed messages and a salt to obfuscate transactions are obtained.
59
+
Since most billing functions are asynchronous, [BillingController][3] notifies all registered [IBillingObserver][4] of the responses.
60
+
61
+
Additionally, [BillingController][3] requires a `BillingController.IConfiguration` instance from which the public key required to validate signed messages and a salt to obfuscate transactions are obtained. A good place to provide the configuration is in the `Application` subclass.
62
+
63
+
Dungeons Redux
64
+
==============
65
+
66
+
[Dungeons Redux][5] is a sample app that shows how to use *Android Billing Library* through [BillingController][3]. It is a simplified version of the Dungeons in-app billing example provided by Google.
67
+
68
+
It should be noted that Dungeons Redux does not intend to be an example of how to use in-app billing in general.
0 commit comments