HOW TO DESIGN WEBSITES OR ANDROID APPS

Oracle 11g step-by-step Install Guide with Screenshots guidelines

step 1:

run your file setup in the folder

during your installation make sure that your (SID) is change or you can maintain the default database name which is ORCL you can change it to your desired SID 

Continue your setup process , the product-specific prerequisite checks perform a random check that matches your system requirement , also make sure that your operating system is updated and validated and your network configuration adapter is complete, as this will indicate an error at the end of your installation

check your directory where you want your drive file to be installed make sure you direct it to C:/

installing progress
                                      

click on exit while your installation is complete

TESTING YOUR INSTALLATION SUCCESS!!!

To test that your installation completed successfully, perform the following steps:

Open a browser and enter the following URL:

https://<hostname>:1158/em

where <hostname> should be changed to your machine name, IP address, or localhost.

Because Enterprise Manager Database Control is a secure site, you need a certificate. Select the Accept this certificate permanently option, and then click OK.



Enter system as the User Name and oracle as the Password, and then click Login.


 

The Database Control Home Page appears. Your installation was successful.


 

Back to Topic List

Summary

In this tutorial, you learned how to install and test the Oracle Database 11g installation on Windows. 7 ultimate or other windows

Android: Importing your Jar files successfully to your Android Project

Integrating Your App with the Google API

Google Play offers great online help to help you implement in-app billing in your application. A good
place to start is with its sample application, which gives you a working model to start from. To get
started with its sample application, go here:

http://developer.android.com/training/in-app-billing/preparing-iab-app.html#GetSample
The old version 2.0 API included a sample app called Dungeons. you can see the
purchase screen from that app, illustrating how you can purchase a potion (“Puts dragons to sleep.”).

If at all possible, you should be integrating with the newer and simpler version 3.0 API, which uses a
different sample app called Trivial Drive

As far as enabling in-app billing in your own application, the following sections spell out the steps

to follow, beginning with downloading the in-app billing library. (We assume you have elected to use

version 3.0 of the API.)

Enabling Your App to Use In-App Billing

To download the in-app billing library, open the Android SDK Manager. Expand the Extras section,

select Google Play Billing Library, and install the Library.

Before you can use in-app billing, you must include a IinAppBillingService.aidl file in your project.

This file is an Android Interface Definition Language file that defines the interface to Google’s billing

service.

First, right-click the src directory of your project and select New ➤ Package. Name your new

package com.android.vending.billing. Move the IinAppBillingService.aidl class (found in

<sdk>/extras/google/play_billing/ as well as the previous sample app provided with the billing

library) into this package.

Add your product to the Google Play Developer Console. To do this, select your application in the

Developer Console and then select the In-app Products tab on the left side. You can then add a

new product. The In-app Product ID must be unique in your application’s namespace. Your product

type can be a Managed per user account, Unmanaged, or Subscription. You also need to add a

description and price.

Initial Setup For In-App Billing In Your App

You can follow the detailed instructions here for the setup process: http://developer.android.com/

training/in-app-billing/preparing-iab-app.html#GetSample

To summarize, you need to give your app permission to interact with the billing service via your

manifest file. You also need to create an Iabhelper, which is the in-app billing helper class. This

class enables a simplified synchronous style of communication that is one of the benefits of version 3.0 of the in-app billing API. The Iabhelper class uses callbacks to communicate with your code. In fact, the setup process uses an onIabSetupFinished callback function to return success or failure.

Using In-App Billing: Requesting a List of Items For Purchase

Again, the process is described here in great detail:

https://developer.android.com/google/play/billing/billing_integrate.html

At a high level, you need to build a list of purchasable items that you are querying. The previous link

uses this example:

List additionalSkuList = new List();

additionalSkuList.add(SKU_APPLE);

additionalSkuList.add(SKU_BANANA);

inAppBillingHelper.queryInventoryAsync(true, additionalSkuList,

mQueryFinishedListener);

As you might expect, the mQueryFinishedListener is a callback function that is called with a list of

available inventory, including their prices.

Using In-App Billing: Making the Purchase

Similarly, making a purchase involves a call the in-app billing helper, and the response is handled

with a callback listener function:

inAppBillingHelper.launchPurchaseFlow(this, SKU_APPLE, REQUEST_CODE_VALUE,

mPurchaseFinishedListener, "developerPayloadString");

SKU_APPLE is the item to be purchased. The REQUEST_CODE_VALUE is a positive integer that will

be returned back to the caller. The developer payload string is a convenience string for use by

developers to send supplemental information. It may be empty.

Using In-App Billing: Determining Which Items Have Already Been Purchased

Continuing the paradigm, you may determine which items have already been purchased with a query

to the in-app billing helper that is captured by a callback listener:

inAppBillingHelper.queryInventoryAsync(mGotInventoryListener);

You need to determine which items have been purchased each time your app restarts so your users

have access to capabilities that they have already purchased.

Using In-App Billing: Consumable Purchases

To consume an item that your user has purchased, you call the in-app billing helper as follows:

inAppBillingHelper.consumeAsync(inventory.getPurchase(SKU_APPLE),

mConsumeFinishedListener);

Integrating Your App with the Amazon API

If you’ve played around with the Google Play in-app billing sample application for version 2.0 of its

API (the Dungeons program), you have a great foundation to start learning how to integrate with the

Amazon API. This link teaches you how to modify the Dungeons application to be compatible

with the Amazon in-app purchasing API:

https://developer.amazon.com/sdk/in-app-purchasing/reference/google-to-iap.html

Amazon claims that its IAP solution requires less work and has a shorter development cycle. Note,

however, that Amazon is not comparing its solution with the newer version 3.0 API.

Enabling Your App to Use In-App Billing

Download the Amazon Mobile App SDK package from here: https://developer.amazon.com/sdk.html

Extract the ZIP file into a directory on your computer. Within this directory, you find an /In-App-

Purchasing/lib folder. This folder contains a JAR file called in-app-purchasing, which is the in-app

purchasing library and must be added to your eclipse project’s library path. You can do this by

accessing the Project Properties menu and going to the Java Build Path. There you can select the

Libraries tab and add the JAR file.

Before you can purchase a product from within an app, you must add your product to Amazon’s

distribution portal by signing into the Distribution Portal and selecting the My Apps tab. Choose the

Manage In-App Items option from the app drop-down menu. Now you must choose whether you

will be creating a Consumable, Entitlement, or Subscription product. You also need to add a price,

description, and thumbnail image.

Initial Setup For In-App Billing In Your App

As you might expect, your application must be given access to the Amazon in-app purchasing

library. The purchasing library is implemented as a broadcast receiver, and you declare it in your

manifest by adding the following to the <application> section:

<receiver android:name = "com.amazon.inapp.purchasing.ResponseReceiver" >

<intent-filter>

<action android:name = "com.amazon.inapp.purchasing.NOTIFY"

android:permission = "com.amazon.inapp.purchasing.Permission.NOTIFY" />

</intent-filter>

</receiver>

This class initiates all in-app billing requests. To capture callbacks from the PurchasingManager, you

must create a PurchasingObserver class and register it with the PurchasingManager. To do this, you

subclass BasePurchasingObserver. (We will discuss each of the methods that need to be subclassed

later in the chapter.) The registration with PurchaseManager occurs in your onStart and looks like this:

PurchasingManager.registerObserver(new MyPurchasingObserver());

You also need to register the user using your app with the Amazon service. 

This also occurs in your

onStart: PurchasingManager.initiateGetUserIdRequest()

You must implement a callback for this request in your PurchasingObserver class:

PurchasingObserver.onGetUserIdResponse(GetUserIdResponse)

Using In-App Billing: Requesting a List of Items for Purchase

Similarly, a call using the PurchasingManager requests the list of items for purchase:

PurchasingManager.initiateItemDataRequest(java.util.Set skus)

You need to implement the following callback in the PurchasingObserver:

PurchasingObserver.onItemDataResponse(ItemDataResponse itemDataResponse)

Using In-App Billing: Making the Purchase

To make a purchase, call the following:

PurchasingManager.initiatePurchaseRequest(java.lang.String sku)

The callback function you need to implement is the following:

PurchasingObserver.onPurchaseResponse(PurchaseResponse purchaseResponse)

Using In-App Billing: Determining Which Items Have Already Been Purchased

The PurchaseResponse field in the callback to the following is set to ALREADY_ENTITLED when an item has already been purchased (of course, the item in question must be an ENTITLEMENT product as set in the distribution portal):

Using In-App Billing: Consumable Purchases

Consumable purchases are simply non-entitled purchases. Once they are bought, the app must

track their use. They can be repurchased at any time.

Supporting In-App Billing with Multiple App Stores

As of this writing, there is no good solution that acts to abstract away the issues of dealing with

multiple app stores for in-app purchasing. However, an open-source project called OpenIAB is in the

works that may change that. OpenIAB is a part of the One Platform Foundation, a global initiative to

help developers submit their apps across multiple alternative app stores.

Although the code is not yet ready for prime time (or even finalized), you should track its

development because once the API is released, it will dramatically simplify the problems of dealing

with multiple in-app purchasing stores. 

You can learn more at the following web sites:

 One Platform Foundation: http://www.onepf.org/

 OpenIAB (Open In-App Billing): http://www.onepf.org/openiab

In-App Billing: Putting a Store in Your Application

In-app billing allows a developer to charge users for app features after their app has already been

downloaded. Imagine charging users for more levels of your game or charging them for virtual goods

(such as a magic sword in a game). For non-gaming apps, you could charge for special features or

even per use if the use case is strong enough.

Comics is an application that is designed to give Android smartphone and tablet users access to digital versions of their favorite comic books. Downloading the application is free, but most of the comics cost the user. We’re sure that Comixology had to make some sort of deal with the comic book companies in order to offer this service, but after those companies receive their share of the profits, we’re also sure that Comixology makes a healthy profit from comic book readers paying for digital comic book content. All that is required of the user is to create an account online, and it syncs up very well.

Tap Tap Revenge is a music game in which players tap the screen to the rhythm of their favorite tunes.The game offers a few songs for free, but if you want more, you have to pay. We’re sure that the music industry gets its percentage along with the developers.

Also SnakePike  is a simple snake game in which players tap the screen to move the snake in different direction, but if you want more, you have to download free from googleplay

  

Making Money with Ads on Your Application: Develop Apps Like a Pro

Software Engineering

Software projects are notorious for running over budget and schedule. An academic field called
software engineering creates and investigates processes that can keep this from happening. Let’s
spend a moment discussing what processes are used.
In the traditional waterfall model of software development, there is a series of steps that are followed
one after the other, like a multitiered waterfall.
The first step is requirements analysis, in which the requirements for the project are collected. One
might detail the purpose of the software and try to define its interfaces without getting into coding
issues.


Bug and Issue Tracking

Professionals track their bugs and feature requests. Without bug and issue tracking, it’s all but
certain that problems will be forgotten. In fact, sometimes an old unresolved bug manifests itself in
a new way. A record of past issues is a great way to do some forensic investigation of a supposedly
new bug. Instead of trying to remember what happened in the past, now you have an actual record
to consult. Typically, bugs and issues are enumerated in the bug or issue tracker. It is common
practice to use bug and issue tracking in concert with revision control by creating development
branches named after the bug number being fixed. In this way, developers tie their active work
directly to the issue or bug they are supposed to be working on.
Another benefit of tracking bugs is that it allows you to prioritize problems with ease. Some bugs
can be lived with, and others cannot. But you need to know the difference before you can release
your app to the public. You absolutely must track your bugs and issues, or else you will lose track of what work needs to be done. Of course, you could always use a text document or spreadsheet. If you want to develop like a professional, however, you should consider one of the numerous programs specifically designed for tracking your bugs and other open issues. Many are hosted online where, for a nominal sum, you can avoid any installation headaches.

The following list provides some examples:
 JIRA: JIRA by Atlassian is a popular issue tracker that integrates very nicely
within Eclipse. It costs $10/month (the money is donated to the Room to
Read charity) for small teams up to 10 users. If you do Agile development, its
Greenhopper companion product is $10 more.
 Bugzilla: A free, server-based bug tracking software designed to help users
manage software development. You can use your own computer as the server if
you need only a small-scale deployment. Bugzilla is used internally by numerous
high-profile, open-source projects, including Firefox, Apache, and Eclipse.
 Redmine: A free, open–source, flexible project management web application.
 Trac: A free, open–source bug tracker that also integrates tightly with popular
revision control systems, including Git, Subversion, Mercurial, and others. It
focuses on offering a minimalistic approach to software project management;
it tries to impose as little as possible on a team’s established development process.
 MantisBT: A free, popular web-based bug tracking system that is also open
source. Mantis also provides the MantisTouch client optimized for smartphones,
including Android!
 FogBugz: A commercial bug tracker, available both as an online hosted version
and as a self-managed client-server version (they can be the same computer).
It’s free for students and small (one-or-two-person) startups. If you don’t
mind paying for the commercial version when you’re more successful,
it might be worth a look. You can find code and details at
http://www.fogcreek.com/fogbugz/StudentAndStartup.html.



Summary

Mobile advertising is on the rise! Worldwide mobile advertising is expected to reach $11.4 billion in
2013 and is projected to reach $24.5 billion in 2016. The train is leaving the station, so let’s get
on board!
Naturally, if you’re interested in mobile advertising, you’re hoping to make some money. Mobile
advertising is a numbers game; the amount of money you will make per user is quite small, so you
must have a very large user base before you can make serious revenue.
On that note, consider that putting an ad in your paid app is often a fatal combination because
no one wants to pay for an app and then have to deal with advertising. Besides, in order to make
a significant profit, you have to get a lot of downloads, and paid apps rarely reach the level of
downloads needed to make meaningful ad revenue.

These numbers are intended only as an estimate. The actual values will depend heavily on the
specifics of your app. We’ll soon get into the math that will allow you to calculate these numbers for
your own app. That said, as you can see, it generally requires a surprisingly large number of users to
generate enough ad revenue to surpass the “beer money” stage.
To begin, you will need to sign up with one or more ad networks. These networks, such as
AdMob, Mobclix, and Leadbolt, connect advertisers with content publishers. From an advertiser’s
perspective, you as an app developer are a content publisher. On the technical side, the ad network
will give you an application programming interface (API) with which to serve its ads.
We’ll say more about that later, but let’s talk about the types of ads you can use first.


Mobile Ads by the Numbers

Let’s discuss how to do a revenue analysis of the type we presented in the chart at the beginning of
this chapter. Mobile advertising has a jargon all its own, and you need to know the lingo before you
can make sense of any financial calculations. In Figure 6-4, note the attention given to statistics such
as Revenue, eCPM, Requests, Impressions, Fill Rate, and CTR in the AdMob screen shot.

You’re going to hear a lot about eCPM, which is the estimated-cost-per-thousand (“M” is the Roman
numeral for thousand, remember). eCPM is the basic metric for evaluating your advertising revenue.
This abbreviation refers to the amount you will be paid for every 1,000 impressions. An impression
is when an ad gets displayed on your app somewhere in the world. So right away, you can see that
there are two key factors in maintaining a high eCPM. You need lots of people using your app and
you need them to use your app for a while. After all, the longer your app stays open, the more ads
will get served.
As a publisher, you will typically see eCPMs ranging between as little as $0.20 and as much as
$1.25. That’s the typical range, but there are no guarantees. Typically, advertisers pay on a sliding
scale where payment depends on the value of the ads that are served. The ad networks simply pass
on a portion of their proceeds to you, and the amount that advertisers are willing to pay depends on
the market they advertise to. For example, an insurance provider will typically be willing to pay much more to acquire customers than a video game manufacturer.


The click-through rate (CTR) lets you know how often a user actually clicks an ad that is shown
in your app. Some ad networks hide these figures from you and simply let you know your eCPM,
without regard to click-through rates. But you should understand that the more your users click ads,
the more money you stand to make. Naturally, this means you should always have an ad available
for your users to click (subject to fill rates, as discussed in the next paragraph). If your app has
multiple screens, consider putting an ad in every one! You can even put an ad in the Settings screen,
and we’ll show you how later. But keep in mind that too many ads might alienate users, so be aware
of “ad overkill.” You will have to experiment to find the optimal balance.
An ad network’s refresh rate is how often a new ad is sent for display to your app. Many ad networks
make these figures adjustable by the developer. You will have to experiment to determine what
works best for you. Consider that each new ad is a new opportunity for a user to find something
interesting enough to click. On the other hand, if you serve ads too often, your users will find them
distracting and perhaps even annoying enough to uninstall your app. Surprisingly, at least for the
uninitiated, often your app does not get served an ad even when it wants to display one. The fill
rate refers to the percentage of time your app will have ads when it’s ready to show them. Some fill
rates can be extremely low, and this directly impacts your revenue. AdMob is not known for having
the industry’s highest eCPMs, but on the plus side, if you enable the AdSense option (which serves
you AdSense ads when a banner ad isn’t available) AdMob will provide a near 100 percent fill rate.
Unfortunately, the AdSense ads don’t pay very well.
One option to get around low fill rates is to integrate your app with more than one ad network at the
same time. Then you can display ads from whoever sends the ad first.
Ok, so that’s a background on how the mobile ad business works. So how do you make those
revenue projections? You have to estimate your eCPM. As we’ve mentioned, somewhere between
$0.20 and $1.25 is usually safe. Now you need to estimate your fill rate. This depends on your ad
network, but if you want to pull a number out of a hat, you can start with 75 percent. Your earnings
per 1,000 requests are your eCPM multiplied by your fill rate (expressed as a fraction). So now all
you need to do is estimate how many requests you will get and you have a back-of-the-envelope
estimate for revenue.
Your requests are governed by how many users you have, how long they use the app, and your
refresh rate. If you have 10,000 users, and they each use your app for 5 minutes per month, and your
app requests an ad every minute, then you will have a total of 10,000 x 5 = 50,000 requests
per month. With a fill rate of 0.75 and an eCPM of $0.50, you would generate 50,000 * 0.75
(0.50/1000) = $18.75 per month. That’s not very much. But notice that if you double the number of
minutes users spend with your app, you will double your revenue. Time spent with your app is just
as important as user base size. Once again, these calculations show that you need a very large user
base to make a living on ad revenue alone.


AdMob

If you’re going to start somewhere, you might as well start with AdMob. Let’s walk you through the
process of using its ad-hosting SDK.

AdMob’s web site is at http://www.admob.com/. When Mark visited the site, AdMob identified him from
his Gmail account, which makes sense because it is owned by Google. If you don’t have a Gmail
account, you can also log in directly to its site. Not only is the Android area good, but you might
want to check out The Guide to the App Galaxy. Registration is simple, and you will receive a
confirmation email that includes a number of useful links. In particular, you should see a link to the
AdMob help center (http://helpcenter.admob.com/).


Advertisers can also find information in the help center. Just as a backgrounder, the advertiser will
start a campaign that specifies how its ads will be presented on applications. The advertisers enter
in a start date, end date, budget, and delivery method. They will then be asked to choose an ad
group to meet advertising goals and will be given the opportunity to add multiple ad groups. They
can then customize which devices they want it on, not to mention the countries or operators they
want targeted. Advertisers can even customize the user demographic. Advertisers can run a Text Ad
Unit or a Banner Ad Unit, and they can design them as they see fit. The ads will then begin to run,
and advertisers can monitor the campaign’s performance.
Okay, that’s how it works for advertisers, but let’s get back to you, the developer. For app
integration, follow these steps:

1. Register and/or log in at http://www.admob.com/.
2. Click Sites and Apps.
3. Click Add Site/App.
4. Provide the information about the Android application.
5. Download the SDK.
6. While the SDK is downloading, head back to the Sites & Apps tab, hover
over your app, and click the Manage Settings button that appears. Near the
top of the page that appears is a long hexadecimal number named Publisher
ID. Copy that number and paste it somewhere. You’ll need it later in an XML
layout file so that your app can let AdMob know who you are.
7. You can also take a moment to explore the AdMob dashboard. You’ll be
spending a lot of time on the Sites & Apps tab. This tab shows you your
revenue for all your apps, as well as your eCPM and fill rates. It also allows
you to view your revenue trends over time.
8. After the SDK has finished downloading, extract the zip file into a new
directory. The directory now contains the AdMob library, which you need to
link into your application.
9. To do that, right-click in the left-side Package Explorer pane in Eclipse. Click
Properties and then click the Java Build Path property. In the Java Build
Path section, click the Library tab. Now just add the JAR file you previously
unzipped into the directory.
10. Now move over to the Order and Export tab. You should see the AdMob JAR
file listed there. Make sure it is selected and move it to the top of the list for
good measure. This makes sure that AdMob is first in the build path so we
don’t get any dependency issues.

11. Once the AdMob JAR file is added to the project, you’ll need to grant your
application all the permissions required by AdMob. You might already be
using these or other permissions in your app’s manifest file, but be sure
you’ve got at least the following permissions:
<uses-permission android:name="android.permission.INTERNET"/>
and
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
12. You’ll also need to reference the AdMob activity in your application’s manifest
file. Place the following within the application tag in the manifest .xml file:
<activity android:name = "com.google.ads.AdActivity"
android:configChanges = "screenSize|smallestScreenSize|keyboard|keyboardHidden|
orientation|screenLayout|uiMode"/>
13. That lets your app know you’ll be using the AdMob activity. You’ll want to
display the ad in at least one layout, and ideally in enough layouts so the ad
is always visible to your users. Within each layout, the ad is simply a view,
aptly named AdView. Here’s an example of an AdView layout element:

<RelativeLayout
[...]
xmlns:ads="http://schemas.android.com/apk/lib/com.google.ads"
[...]
<com.google.ads.AdView
android:id="@+id/adView1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
ads:adUnitId="1234567890abcde"
ads:adSize="BANNER"
ads:loadAdOnCreate="true"/>

14. Notice the adUnitId tag. That number is the publisher ID we discussed
earlier. That’s it! You should now have ads enabled in your app. It might take
a few minutes before you’re served your first ad, so be a little patient.
An example of an application hosting AdMob is shown below:

Affiliate Programs

Although not precisely mobile ads, affiliate programs are similar in that you use your app to direct
users’ eyes to mobile websites. The idea of an affiliate program is that an advertiser encourages a
developer to send traffic to its retail sale web site, and a minute commission fee is given out for sales
rendered. As someone who has done a little work on the web, Mark occasionally receives some
revenue with affiliate programs such as Amazon. They are pretty easy to sign up for and set up, and
it is possible to use these same affiliates from within an Android app.
Beyond individual affiliates such as Amazon, you can also find affiliate networks. These companies
do for affiliates what ad networks do for advertisers. In other words, they connect affiliates with
publishers. Instead of an ad, a link to the affiliate’s web site is provided, and payment occurs when
a purchase occurs. In a sense, an affiliate network is a kind of ad network in which payment occurs
only if a sale is made on the referral.

You should weigh the benefits of an affiliate program versus a typical ad network. Ad networks
are more common in mobile apps and they are generally easier to integrate into your application.
Although affiliate programs make more money per transaction, it is harder to close a sale than it is
merely to get eyes on a web site. In other words, it’s likely that affiliate marketing will make sense
only if something about your app makes it very likely that the user will close a sale with your affiliate.

For example, if you have a music player app, perhaps referrals to a hardware provider that sells great
speakers for Android phones would result in a high rate of sales conversions.
Rakuten Linkshare (at http://mthink.com/affiliate/) is the top affiliate network in the world.
Although it doesn’t have an API specific to Android, it can be called from within an Android
application using an HTML API. This is the same way a publisher links with an affiliate on the web.
Rakuten Linkshare has tested its service with a number of mobile platforms, including Android. To
learn more, visit its web site at http://www.linkshare.com/advertisers/publishers/.

There are many other affiliate networks. To see a few, you can investigate the following sites:
 Commission Junction: http://www.cj.com
 ClickBank: http://clickbank.com
 ShareASale: http://shareasale.com
 AvantLink: http://avantlink.com
 RevenueWire: http://revenuewire.com

Even though Amazon isn’t an affiliate network, its sheer size makes it the third largest affiliate
service. You can learn about Amazon’s affiliate program at https://affiliate-program.amazon.com/
gp/associates/join/landing/main.html. eBay also has a large affiliate service. You can learn about
it at https://ebaypartnernetwork.com/files/hub/en-US/index.html.


Technical Tricks

One very useful trick to improve your ad revenue is to place an ad in every screen of your app.
Many apps have a Settings screen where user preferences are selected.

Android provides a standard framework for Preferences, and your ads can be made to work

with that framework. First, you will need a custom preference that supports ads. Note that the

following example extends Preference, a technique that has been deprecated in Android 3.0 in

favor of PreferenceFragment. This example continues to use Preference to support the roughly

40 percent of the market that isn’t using Android 3.0 or newer. If you are targeting only Android 3.0

and later, you should consider modifying your code to follow the example found here:

http://developer.android.com/reference/android/preference/PreferenceActivity.html

public class AdmobPreference extends Preference

{

public AdmobPreference(Context context) {

super(context, null);

}

public AdmobPreference(Context context, AttributeSet attrs) {

super(context, attrs);

}

@Override

protected View onCreateView(ViewGroup parent) {

//override here to return the admob ad instead of a regular preference display

LayoutInflater inflater = (LayoutInflater) getContext().getSystemService

(Context.LAYOUT_INFLATER_SERVICE);

return inflater.inflate(R.layout.admob_preference, null);

}

}

This custom preference simply looks for an admob_preference layout to inflate. That’s where all the

work is done. The .xml file (minus the XML header) is reproduced here (notice the familiar AdView

layout contained within):

<RelativeLayout

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:ads="http://schemas.android.com/apk/lib/com.google.ads"

android:layout_width="fill_parent" android:layout_height="fill_parent"

>

<com.google.ads.AdView

android:id="@+id/adView1"

android:layout_alignParentTop="true"

android:layout_centerHorizontal="true"

android:adjustViewBounds="true"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

ads:adUnitId="1234567890abcde"

ads:adSize="BANNER"

ads:loadAdOnCreate="true"/>

</RelativeLayout>

That’s it! Those two files are all you need. Simply place your AdmobPreference into your existing list of preferences and you’ll have ads in your Preferences screen!