WARNING: The SponsorPay Developer Portal has been updated, and this document is now outdated. You can access the new version of the Developer Portal at http://developer.sponsorpay.com.
Please update any bookmarks or direct links to this article - the URL will stop working after a period of time.
The Offer Wall is implemented as an Android activity.
AndroidManifest.xmlfile inside the Application element:
<activity android:name="com.sponsorpay.sdk.android.publisher.OfferWallActivity" android:configChanges="orientation"/>
com.sponsorpay.sdk.android.publisher.SponsorPayPublisherclass into the source file from which you will call the SDK.
OfferWallActivity, by calling
SponsorPayPublisher.getIntentForOfferWallActivity(context, shouldStayOpen), where
contextis a reference to your application context and
shouldStayOpenis a boolean parameter that lets you specify the behavior of the offerwall activity once the user clicks on an offer and is redirected outside your app. From this point on, the OfferWall will be using the parameters available on the current credentials (created with the
offerWallIntentis the intent you got from the SDK in the previous step. This will show the Offer Wall activity. Don’t forget that the activity must be defined in your application manifest (see step 1).
onActivityResult(int requestCode, int resultCode, Intent data)in the activity that called the Offer Wall activity. The request code passed to this method will be the same you passed to your offerWallIntent in the step 4,
Optionally, you can determine the behavior that the Offer Wall will exhibit when a user is redirected outside your app by clicking on an offer and then coming back. By default, the Offer Wall activity will remain on top of your application activity stack, and when the user returns to your app it will reload its contents. You can override this behavior by specifying that the Offer Wall activity should close when the user is redirected out of your application. This way, when the user comes back to your game, it will do it to the activity which called the Offer Wall activity.
To accomplish this, use a different
SponsorPayPublisher.getIntentForOfferWallActivity(Context context, boolean shouldStayOpen)
Where the boolean parameter
shouldStayOpen will have the value
If the device’s Internet connection is down or an unknown error involving the SDK or SponsorPay’s backend happens when loading the Offer Wall, the
OfferWallActivity will present an alert dialog to the user. The dialog will have a title, a message, and one single button to dismiss the alert. We have provided the following default messages in English:
|ERROR_DIALOG_TITLE||Single title for all alert dialogs||"Error"|
|ERROR_NO_INTERNET_CONNECTION||Error message presented when the device seems to have a broken connection to the internet and, as a consequence, the Offer Wall cannot be loaded.||An error happened when loading the Offer Wall (no internet connection)"|
|ERROR_LOADING_OFFERWALL||Error message shown when an unknown cause has prevented the Offer Wall from being loaded.||"An error happened when loading the Offer Wall”|
|GENERIC_ERROR||Generic error message. It’s not in use at the moment.||"An error happened when performing this operation"|
|DISMISS_ERROR_DIALOG||The caption of the dismiss dialog button.||“Dismiss”|
|LOADING_INTERSTITIAL||A loading message which appears next to the progress bar when loading the interstitial ad. (Not used by the Offer Wall)||“Loading…”|
|LOADING_OFFERWALL||A loading message which appears next to the progress bar when loading the mobile Offer Wall||“Loading…”|
We encourage you to provide you own versions of the error messages in several languages. To accomplish this, we provide the following static methods inside the SponsorPayPublisher class:
setCustomUIString(UIStringIdentifier identifier, String message)this method lets you specify one overrided version of a message at a time. You can identify the message you want to customize by using the enumeration
setCustomUIStrings(EnumMap<UIStringIdentifier, String> messages)this will let you specify several or all overriden messages at once by passing an EnumMap instance. If the passed map doesn’t contain keys for each of the possible messages, those not specified will be left to its default value.
setCustomString(UIString Identifier identifier, int message, Context context)and
setCustomUIStrings(EnumMap<UIStringIdentifier, Integer> messages, Context context)are the localization-friendly versions of the two previous methods. Instead of passing a string with the text for the overridden message, pass an integer reference to your strings and let the Android localization mechanism do the rest! Please refer to the Android documentation about localization for more details
<application android:icon="@drawable/icon" android:label="@string/app_name"> <activity android:name="com.sponsorpay.sdk.android.publisher.OfferWallActivity" android:configChanges="orientation" /> </application> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
import com.sponsorpay.sdk.android.publisher.SponsorPayPublisher; // We assume this code is running inside an android.app.Activity subclass Intent offerWallIntent = SponsorPayPublisher.getIntentForOfferWallActivity(getApplicationContext(), true); startActivityForResult(offerWallIntent, SponsorPayPublisher.DEFAULT_OFFERWALL_REQUEST_CODE);
Android will show navigation controls on top of all activities when running on devices without dedicated hardware navigation buttons. This is called the System Bar. In some cases, an extra button whose caption consists of three little dots, called "action overflow button", will be displayed on the right of the System Bar. This button performs the function of the "menu" button which used to be present in all of Androd 1.x and 2.x devices, and is shown by the system even if the foreground activity has no menu options declared. This can affect as well the SponsorPay Mobile Offer Wall activity.
The easiest way to work around this issue is to modify your application manifest
uses-sdk element to declare a
targetSdkVersion of at least
14 (if you don't run into any compatibility issues):
<uses-sdk android:minSdkVersion="[your minimum acceptable SDK version]" android:targetSdkVersion="14" />
In any case you can keep your
minSdkVersion version unmodified.