Integrate new InApp service to OpenIAB

[Yury Vasileuski]

Colleagues, I am developing new in-app service and want to be as close to Google as possible.

As basis, I have got Google example for client (extras/google/play_billing/in-app-billing-v03).

I have created my own AIDL with the same methods, so the only modification to in-app-billing-v03 to be done is to create wrapper around mService:

   private int isBillingSupported(int apiVersion, String packageName, String type) throws android.os.RemoteException {

    return mWrapperBillingService.isBillingSupported(apiVersion, packageName, type);

    }

    private android.os.Bundle getSkuDetails(int apiVersion, java.lang.String packageName, java.lang.String type, android.os.Bundle skusBundle) throws android.os.RemoteException {

    return mWrapperBillingService.getSkuDetails(apiVersion, packageName, type, skusBundle);

    }

    private android.os.Bundle getBuyIntent(int apiVersion, java.lang.String packageName, java.lang.String sku, java.lang.String type, java.lang.String developerPayload) throws android.os.RemoteException {

    return mWrapperBillingService.getBuyIntent(apiVersion, packageName, sku, type, developerPayload);

    }

    private android.os.Bundle getPurchases(int apiVersion, java.lang.String packageName, java.lang.String type, java.lang.String continuationToken) throws android.os.RemoteException {

    return mWrapperBillingService.getPurchases(apiVersion, packageName, type, continuationToken);

    }

    

    private int consumePurchase(int apiVersion, java.lang.String packageName, java.lang.String purchaseToken) throws android.os.RemoteException {

    return mWrapperBillingService.consumePurchase(apiVersion, packageName, purchaseToken);

    }

with initialization:

public void startSetup(final OnIabSetupFinishedListener listener, int billingServiceMode) {

        // If already set up, can't do it again.

        if (mSetupDone) throw new IllegalStateException("IAB helper is already set up.");

        

        // Connection to IAB service

        logDebug("Starting in-app billing setup.");

        

        mWrapperBillingService = new WrapperBillingService(billingServiceMode);

...

}

And as reference one of methods of WrapperBillingService:

    public int isBillingSupported(int apiVersion, String packageName, String type) throws RemoteException {

            switch(mMode) {

       case MODE_GOOGLE:

        return mGoogleService.isBillingSupported(apiVersion, packageName, type);

        default:

         return mMyMarketService.isBillingSupported(apiVersion, packageName, type);

            }

    }

====

How your OpenIAB could simplify usage of my approach and how can I integrate my in-app service into your OpenIAB?

Thanks,

Yury

[Vassili Philippov]

Hi Yury,

There could be situation when there are several appstores installed on a device. So you should provide developers a way to detect if your appstore was used to download the app.

I suggest implementing two additional methods in the interface:

1. To check if this appstore was used to install the app

2. To check if this appstore can handle in-app purchases of this app (in case the app was side-loaded so to appstore answers that the app was installed by it)

Best regards,
Vassili

[Yury Vasileuski]

Vassili,

My idea is a bit different - OpenIAB need to provide public Adapter for IabHelper mService so mService will be set by public setter or using startSetup.

Basic code to modify IabHelper I have provided above.

Adapter interface will be identical to IInAppBillingService to minimize modifications of IabHelper class.

Due to such modifications, OpenIAB will be more flexible with full support of GooglePlay-like in-app services.

If it is needed, I can contribute directly to code in github using fork and pull-requests.

Thanks,

Yury

[Vassili Philippov]

I agree, it makes sense.

[Vassili Philippov]

Let's brainstrorm general library structure together. First of all the library should be broader than in-app billing. It should include other store-specific APIs (like licensing, push, etc) as well. So I suggest the following structure:

enum AppstoreService {
    APPSTORE_SERVICE_IN_APP_BILLING,
    APPSTORE_SERVICE_LICENSING,
    ...
}

class AppstoreServiceManager {
    Appstore getAppstoreForService(String packageName, AppstoreService appstoreService);
    Appstore getInstallerAppstore(String packageName);
    List<Appstore> getAppstoresSupportingAPI(String packageName, AppstoreService appstoreService);
}

interface Appstore {
    boolean hasApp(String packageName);
    boolean isInstaller(String packageName);
    boolean isServiceSupported(AppstoreService appstoreService);
    AppstoreInAppBillingService getInAppBillingService();
    //... other methods that return different Appstore specific services
}

Will appreciate your feedback about this architecture.

Question:

1. Should we use "String package" parameter or just pass Context that the library would get application package name itself? 

Best regards,
Vassili

[y.vasi...@gmail.com]

First of all, it seems that "appstore" is dangerous name, at it usually associates with Apple and could be sued.

I strongly suggest to use another one, eg OpenStore, AndroidStore, CommonStore, UniversalStore, etc. Also, as your main idea is to provide wrapper/adapter for client part, but not store itself, it is useful to postfix with "lib", "client", etc.

Yury

[Vassili Philippov]

Don't warry. One can sue you only for trademark vialation but:

- You can violate a trademark only buy confusing end-users, using a trademark in API function name is not a trademark violation

- Apple failed to get "AppStore" trademark because the court has decided it is a generic term:
http://appleinsider.com/articles/13/01/02/court-dismisses-apple-trademark-suit-over-amazon-appstore-name

And there is no better term to describe an appstore than "appstore" ;) So I suggest just using it.

> Also, as your main idea is to provide
> wrapper/adapter for client part, but not store itself, it is useful to
> postfix with "lib", "client", etc.

I do not the fact is that it is a wrapper for an appstore not appstore itself it is a reason to reflect in the name. For developers this class is an appstore because it is how its app communicated with an appstore. 

If there is Camera class:
http://developer.android.com/reference/android/hardware/Camera.html

for sure it is not camera itself but  wrapper ;)

Best regards,
Vassili