Chris Risner . Com

We’re getting quite close to the end of the 31 Days of Android so it’s time to talk about how to make some money with your apps.  There are several ways to make money with your applications.  You could just charge for the sale of your app.  Many developers do this and put out a free version with limited features to get users interested in paying for the full version.  Another way to make money is through in-app purchases.  This seems to be more common in games where you can charge users to get special perks or abilities for their in-game character.  Another way to make money, and the focus of today’s article, is in-app advertisements.  One quick note is that you NEED your project to target Android 3.2 or later.  While previous projects targeted 2.2, the sample code today targets 4.0.  You can download the starter code we’ll use today here.

Creating an AdMob Account

For today’s talk we’re going to use AdMob.  AdMob is an advertising network owned by Google.  There is no requirement to use AdMob in Android and there are other alternatives that you could implement yourself.  Step one is to go to www.admob.com and sign up for an account.  If you’re making an account for yourself, you’ll need to put your social security number in (remember the idea is that they’re going to pay you money so they need your info).  If you’re entering it for a business, you’ll have to enter some information specific to your business (i.e. a Tax Identification Number).  After that you can choose to have money put into a bank account or directly into your PayPal account.  Once that is done you have to add a new site / app.  Here you can choose between an Android App, iPad App, iPhone App, Smartphone Web, or a Windows Phone 7 App (this supports more than just Android).  Choose Android App and then you’ll need to enter your app’s name and package.  Once you’ve created your app, you should be taken to a page that lists your Publisher ID as well as give you a link to the Publisher Code.  Download the code and keep track of the Publisher ID as you’ll need it later. 

Adding the AddMob Library to your Project

Typically with any third party libraries, I will drop them into a Libs folder in my project’s directory prior to adding it to the project.  After you do that, right click on your project in Eclipse and go to Properties.  Choose the Java Build Path section from the left of the window and then the Libraries tab from the top of the window.  Choose Add JARs, expand DayThirty/libs and choose GoogleAdMobAdsSDK-#.#.#.jar.  When your done the properties window should look like this:

Manifest File Changes

There are a few different manifest file changes you need to make.  First you need to add permissions for INTERNET and ACCESS_NETWORK_STATE:

<uses-permission android:name="android.permission.INTERNET"/>

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

These are necessary because you’re displaying ads that the device has to fetch from the internet.  Second, you need to add a new Activity into the xml with the other activities:

<activity android:name="com.google.ads.AdActivity"

android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"/>

If you try to run your application without putting this in your manifest, your ad will actually say:

You must have AdActivity declared in AndroidManifest.xml with configChanges.

Adding the Publisher ID

You don’t have to have your Publisher ID in your strings resource file but’s not a bad idea to put it there.  Open your res/values/strings.xml and add “admob_id” in with the Publisher ID you got from the AdMob website:

<string name="admob_id">a14eef56ac6acfb </string>

Adding an Ad to your Layout

Now you can open your res/layout/main.xml layout to add an AD in.  Go ahead and drop a com.google.ads.AdView element in above the TextView at the top:

<com.google.ads.AdView

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

android:id="@+id/ad"

android:layout_width="fill_parent"

android:layout_height="wrap_content"

googleads:adSize="BANNER"

googleads:adUnitId="@string/admob_id" />

Here you’re using the admob_id you put in your strings file just a moment ago.  The last step you need to take is to load an AdRequest into your AdView.

Loading the AdView with Ads and Using Test Mode

Open the src/com.daythirty/DayThirtyActivity.java class and go to the bottom of the onCreate method.  You need to do two things here:  load the ads and add your device and emulator to test mode.  While in development, it’s important that you add your devices and emulator to test mode so that you aren’t affecting your impressions inappropriately.  Thankfully this is done very easy.  For each device you just need to get it’s serial number which can be pulled from DDMS or from the device selection screen when running your app.  When you’re done, your code should look like this:

AdRequest request = new AdRequest();

request.addTestDevice(AdRequest.TEST_EMULATOR);

request.addTestDevice("015ED03511005018");

AdView ad = (AdView) findViewById(R.id.ad);

ad.loadAd(request);

Here I’ve added my device’s serial number as a test device as well as the emulator.  Then the same request is used to load the ads into your AdView.  Now when you run your app, you should see an ad at the top (it may take a couple minutes to show up when you run for the first time):

Note that when your app first loads the Ad won’t be loaded yet and the TextView will be all the way at the top of the screen.  Once the Ad loads, the rest of your UI elements will be pushed down.  It’s worth keeping this in mind when you decide on the placement of your Ads.

Different AD Sizes

In the AD you’ve put into your project, you’ve set the size to be BANNER.  This Ad size is 320 x 50.  In portrait mode, the Ad should stretch across the screen.  However, if you rotate to landscape, the Ad will be centered and only take up part of the screen:

There are other Ad sizes which are banner specific.  IAB_MRECT is a medium rectangle and is sized at 300 x 250.  IAB_BANNER is a full size banner and is 468 x 60.  IAB_LEADERBOARD is 728 x 90.

Passing Targeted Information to Ads

As you might imagine, there is a lot of information that could be used to deliver more targeted Ads to your users.  This is done using several methods on the AdRequest object.  This is a list of the current methods:

• setBirthday - Set the user's birthday.
• setGender - Specifies if the user is male or female.
• setLocation - Specify the user's current location
• setKeywords - Pass in keywords for specific ads (like "Technology")
• setExtras - I'm not really sure.
• setPlusOneOptOut - Has something to do with plus oneing things.

As noted, I’m not exactly sure what the last two methods are used for but the rest of these methods should enable you to present some pretty targeted Ads to your users.  Do think about user privacy before you try to implement any of these.  Some users are ok with this sort of information being passed around and others are very not ok with it.

Using what you’ve learned today, you should be able to put Ads in your applications and put them in the right place so they will look good.  You can download the final code from today here.

Today we’re going to talk about using the camera in your applications as we get close to wrapping up the 31 Days of Android.  There are two different ways you can use the camera in your applications:  via an Intent or directly using the camera hardware.  If you use an Intent, you’re relying on a different application to handle taking the picture or video and “handing it back” to your app.  Today we’ll look at how you can get pictures from the camera with an Intent as well as how to get some more information from the camera.  You can download the starter code we’ll use today here.

Manifest Changes

Before you can use the camera, you need to add a permission to the manifest file.  This will be listed when users go to install your application so that they will know your app will use their camera.

<uses-permission android:name="android.permission.CAMERA" />

Technically this is the only change you need to make to your manifest.  However, you can also specify that the camera is a feature of your app by adding this to your manifest file:

<uses-feature android:name="android.hardware.camera" android:required="false" />

Note that at the end you’re saying that the camera isn’t required to install your app.  If you set this to true or remove it, then users wont’ be able to install your app if they don’t have a camera.  Today I think all phone and tablets that come out come with cameras though it’s entirely possible devices without cameras could access the Android Marketplace (i.e. Google TV boxes) so if you’re building an application that completely depends on having a camera, you may want to require it in your manifest file.  If you aren’t going to require a camera but want to check to see if a camera is available you can use the PackageManager to find out:

PackageManager packageManager = getPackageManager();

boolean doesHaveCamera = 

        packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA);

If hasSystemFeature returns false than you know the device doesn’t have a camera available.  While not necessary for camera usage, you should also add the permission for external storage to your manifest file:

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Later on you’ll write your images to external storage so it’s easier to take care of this now.

Using the Camera with Intents

Just starting the camera is actually remarkably easy.  If you’ve used intents before to launch other applications, this will look very familiar:

Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);

startActivityForResult(intent, 100);

Running this code will launch the camera app.  The default camera app will allow you to take a picture and then either approve it, retake it, or cancel.  Once you’ve said you’re done or cancelled, you’ll return to your application.  At this point, nothing else is happening.  When the camera app returns to your application, it sends an Intent over which you can get at in the onActivtiyResult method.  Let’s say you want to take the image that was taken and display it back to the user.  First you’ll need to open the res/layout/main.xml and add an ImageView under the last button:

<Button

    android:id="@+id/button2"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"

    android:text="Button" />

<ImageView

    android:id="@+id/imageView1"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"/>

Now in your onActvitiyResult method, you can put the image that was taken in as the ImageView:

@Override

protected void onActivityResult(int requestCode, int resultCode, Intent intent) {

    Bundle extras = intent.getExtras();

    ImageView imageView1 = (ImageView) findViewById(R.id.imageView1);

    imageView1.setImageBitmap((Bitmap) extras.get("data"));

}

The camera returns the image data as an extra named “data” and once you get it you can cast it to a Bitmap to use it as an image.  From there it’s easy to just set the ImageView’s ImageBitmap property.  Now when you run your app and take a picture, you should see the picture show up on beneath the button:

If you close down your application and run the gallery application, you’ll see that the images you took for your app are there.  This means that it’s storing images in the default location.  If you want to, you can specify a place to put the images you capture.  This is done by putting an extra on your image capture Intent before you send it:

Intent intent = new Intent(

        MediaStore.ACTION_IMAGE_CAPTURE);

// Get our fileURI

Uri fileUri = getOutputMediaFile();

intent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri); 

startActivityForResult(intent, 100);

The fileURI you are passing in is created from a File you create on the disk.  You could write these files to any location that you have access to.  If you wanted to keep them private to your application, you could pass in a URI for your app’s data directory.  If you wanted to store them externally on the SD card, you could do something like this:

private Uri getOutputMediaFile() throws IOException {

    File mediaStorageDir = new File(

            Environment.getExternalStoragePublicDirectory(

                    Environment.DIRECTORY_PICTURES),"DayTwentyNine");

    // Create a media file name

    String timeStamp = new SimpleDateFormat("yyyyMMdd_HHmmss")

            .format(new Date());

    File mediaFile;

    mediaFile = new File(mediaStorageDir.getPath() + File.separator

            + "IMG_" + timeStamp + ".jpg");

    if (mediaFile.exists() == false) {

        mediaFile.getParentFile().mkdirs();

        mediaFile.createNewFile();

    }

    return Uri.fromFile(mediaFile);

}

Here you’re creating a file in the SD card’s pictures directory, under a subfolder named “DayTwentyNine”.  The name of the file is “IMG_” followed by the timestamp.  Now if you run your app, it’s going to crash when it returns from taking the picture.  The reason is that when you pass in the EXTRA_OUTPUT extra, the camera doesn’t return the image data because it knows you know where it’s going to write the file to.  Once the camera returns, in onActivityResult you can check to make sure it was a success and then do whatever you need with the picture.  If you wanted to be able to handle the picture being returned or not being returned, your onActivityResultmethod might look like this:

@Override

protected void onActivityResult(int requestCode, int resultCode,

        Intent intent) {

    if (requestCode == 100) {

        if (resultCode == RESULT_OK) {

            if (intent == null) {

                // The picture was taken but not returned

                Toast.makeText(

                        getApplicationContext(),

                        "The picture was taken and is located here: "

                                + fileUri.toString(), Toast.LENGTH_LONG)

                        .show();

            } else {

                // The picture was returned

                Bundle extras = intent.getExtras();

                ImageView imageView1 = (ImageView) findViewById(R.id.imageView1);

                imageView1.setImageBitmap((Bitmap) extras.get("data"));

            }

        }

    }

}

Here you’re still setting the ImageView if the data is returned, otherwise you’re just showing a Toast with the file location.  You could alternatively open that file and display it in the ImageView if you wanted. 

Checking Megapixels

One scenario I’ve found myself in at work that took some research to figure out was knowing how many megapixels the camera was.  It seems like there should be an easy to use built-in way to get a rating on the camera on the device but, as of yet, I haven’t found anything.  Thankfully it’s not very difficult to calculate how many megapixels the camera supports.  First you need to make a connection to the camera hardware, and then you can use the getSupportedPictureSizes method to get a list of supported picture sizes.  This gives you a list of heights and widths which you can multiply to get picture resolutions in pixels.  You can use this number to find megapixels.  This code will go through these lists and round up or down appropriately to get megapixels:

ArrayList<Integer> supportedMegaPixels;

Camera cam = Camera.open();

camParameters = cam.getParameters();

pictureSizes = camParameters.getSupportedPictureSizes();

if (pictureSizes.size() > 0) {

    supportedMegaPixels = new ArrayList<Integer>();

    for (int i = 0; i < pictureSizes.size(); i++) {

        supportedMegaPixels.add(((pictureSizes.get(i).height * 

            pictureSizes.get(i).width) + 1000000 / 2) / 1000000);

    }

}

cam.release();

You can then check the supportedMegaPixels ArrayList to see the maximum number of megapixels as well as to see if a specific resolution was supported.  For example, here’s a method that will check to see if the camera supports 5 megapixels:

public static boolean doesSupport5MP() {

    return (supportedMegaPixels.contains(5));        

}

I do have a few words of caution.  First, if your device has a front facing camera as well, it will return the supported picture sizes of that camera along with the picture sizes for the (typically) higher quality rear camera.  Secondly, if you’re using the camera and calling Camera.open() make sure you call release on the camera object when you’re done.  If you open the camera and then try to fire the ACTION_IMAGE_CAPTURE intent, the camera won’t work. 

If you need more control over the camera or want to make your own image capture program, you’ll want to directly connect with the camera hardware.  We won’t go over that today but you can read more about it on the Android site (and maybe I’ll go over it in the future).

You can download the code we ended up with today here.