keepsafe / cashier Goto Github PK

That way it is optional and can be excluded from debug builds.

Test purchases don't have an orderId field, which ensures that there are no actual charges to user accounts.

This is confusing / problematic because Cashier doesnt relay this information. There should either be an option to allow sandbox testing where the order id field is not required, or it should be communicated that the purchase received was a test purchase.

Cashier does not need to operate on Lists, the only need is when talking to IAB, and so we should not force callers to pass Lists

This will eliminate the need for activities to implement onActivityResult

The billing api communicates back to your app via activity results. So currently users of the library would need to implement handling logic in each activity they use the library with. Fragments also have the ability to handle activity results, and can be added / removed from any hosting activity. Fragments also do not need to display any UI, so the idea is to attach the fragment for the sole purpose of retrieving the result and passing it back to the library.

The existing getInventory does a lot of work that is not applicable to every use case.

The only need for an Activity over a regular Context is for the startIntentSenderForResult call only used while purchasing an item. The API shouldn't be handicapped by this, however. Removing the need for an Activity in each interaction with an instance of Cashier allows background/asynchronous product / inventory queries among other things that are not easily possible right now.

The cashier-iab-debug module was added so that you can prevent debug activities from being included in the release APK. However, there isn't any good way to include that module with compileDebug.

The easiest way to set up fake billing in debug currently is with something like this:

val billingApi = if (BuildConfig.DEBUG) {
     FakeInAppBillingV3Api.addTestProduct(NO_ADS_PRODUCT)
     FakeInAppBillingV3Api(activity)
 } else {
     InAppBillingV3API()
 }

However, that requires that FakeInAppBillingV3Api be present in all builds, or the code won't compile. What would be more useful is for some way to set up fake billing without referencing debug-only code.

There are a few ways to do it. One is to make another apk that has stubs for the fake stuff, which would result in a build file like this:

compile(name: 'cashier-0.1.0', ext: 'aar')
compile(name: 'cashier-iab-0.1.0', ext: 'aar')
compile(name: 'cashier-iab-fake-0.1.0', ext: 'aar')
compileDebug(name: 'cashier-iab-fake-debug-0.1.0', ext: 'aar')

You could also move the external interface back into Cashier and some reflection. There are other ways to do it as well. As it is, the separate artifact for iab-debug is only useful for the the manifest merge.

The logger class is pretty barebones, it also exposes an api to set a log tag, which is not ideal since the user can never effectively set a tag. This is because vendors will override the tag on creation.

Additionally, there are a lot of exceptions that are caught where the exception itself is never propagated to the user. Should either log that to the logger or make it a part of Vendor.Error

Currently the fake checkout experience looks way too similar to the real checkout process and may be confusing. It should be different enough that there is no question as to what checkout process is in use.