Wednesday, 23 November 2011

Comparing some mobile advertising services - part 3

Continuing my look at the various Mobile advertising services that are out there, I next decided to investigate MoPub. This follows on from the previous article, which looked at LeadBolt.


MoPub is another ad service from whom I recently received some publicity information, and decided to find out a bit more about them. They were apparently founded by former AdMob and Google employees, presumably they hope this will give them additional credibility among the Android developer community.

In addition to having their own "Marketplace" for ads, MoPub also offers an ad mediation service, whereby you can connect your accounts from other ad service providers, and in theory, MoPub should automatically deliver the highest earning ad. It's worth noting there are other ad mediation services available, for example MobClix (which I looked at previously), AdWhirl, and others.

The SDK integration for MoPub was straightforward. Their source code is available from a git repository, so you can pull the source directly using git, or download as a zip file. The fact that the source code is available is a nice bonus.

Although primarily an AdMob user, I had previously set up accounts with MobFox and InMobi for previous trials. So I decided to link these to my MoPub account, using their web-based administration console. MobFox and InMobi ads can then be served via MoPub via a direct server-to-server request. This method can't be used in the case of AdMob however (I believe this is due to AdMob's terms of use), so instead, the API must be called from within the app via an adapter that MoPub provide. This does also mean it's necessary to include the AdMob SDK in your app, but as a pre-existing AdMob user, this was not a major problem for me.

What I like about this ad mediation approach is once set up, the ad networks and their priorities can be adjusted in the console area and any changes will take effect in real time. So in the event that one network is performing badly, or you want to add in a new service, you can do this dynamically without re-releasing your app.
Illustration of a possible MoPub setup

My initial impressions of MoPub are positive. The MoPub marketplace is giving me eCPM values of around $0.70, which is significantly higher than other services I have looked at. The fall-back to the other ad services seems to be working, with MobFox being the most likely service chosen. MobFox is returning eCPM values of around $0.20, with AdMob a little lower. InMobi continues to give me too low a fill rate, as was the case in the previous trial, so I fairly quickly stopped using them.

On the downside, some of the ads in MoPob marketplace may be considered annoying by some users - some are animated and others include adverts for age-sensitive content that publishers may want to exclude, such as gambling or dating-related. Going forward, I would like to see MoPub allow publishers to exert more control over what kinds of adverts can be shown, and I believe such features are in the works. You can create a MoPub account here.

What to conclude?

As a result of these tests, my current preferred setup for ad services has changed. I will be looking to use MoPub as my primary service, with AdMob and MobFox configured as additional networks. I have switched some of my apps to this configuration and initial results are suggesting improved performance. Let's hope that continues. I will continue to monitor the situation and keep my eye out for other services that may be of interest, and keep you informed of my findings.

Monday, 21 November 2011

Comparing some mobile advertising services - part 2

In this second look at Mobile advertising services, I decided to investigate LeadBolt. This follows on from the previous article, which looked at MobClix, MobFox and InMobi.


LeadBolt caught my attention because they offer more than the traditional mobile ad service of simply providing an ad to fill a 320x50 pixel space. As well as a variety of ad sizes, they also offer a number novel features, such as:
- Ads as notifications
- Interstitial ads
- Content unlocking

I was a little skeptical about the ads as notifications, thinking some users may find them annoying. The interstitials (full screen ads between pages in the app) may have some uses when used appropriately. But for me, the feature of most interest is the ability to allow users of unlock content by interacting with ads.

Many developers have opted for an approach where they release a free "lite" version and also a paid "pro" version of an app. The free version intended to encourage users to upgrade to the paid version. I have tried this approach in the past with moderate success - but the number of users willing to upgrade is often a very small proportion - rates of 1 sale per 1000 free downloads are not uncommon.

The promise of the content unlock approach then, is that if users are to be rewarded with "free stuff", they are more likely to engage with the ads. Your premium content can reach a potentially larger audience while still ensuring you can generate income, thanks to the greater response rate to these kinds of ads. That's the theory, anyway.

So I decided to trial LeadBolt in one of my apps. But pretty quickly I hit the same dreaded problem that I had hit previously with MobClix: The SDK requires the android READ_PHONE_STATE permission. It seems to be becoming almost a pattern than my attempts to implement SDK from third parties are frustrated due to excessive permission requirements. For details on this permissions issue, see my previous article.

So what to do?

I contacted LeadBolt about the permission requirements, and they were at least responsive and replied they would look into it so see if it the READ_PHONE_STATE permission could be made optional. Until then I won't be implementing LeadBolt. However, because the features they offer are still potentially interesting to me, I will keep it on my list of possible services to look at again in the future. If this permission issue does not affect you, then you can create a LeadBolt account here.

I the next article, I'll be taking a look at MoPub.

Wednesday, 2 November 2011

Comparing some mobile advertising services - part 1

Mobile advertising is important for developers because it is one of they key methods of monetising apps. However, choosing the best one is not that simple as there are so many ad services available nowadays. So what in-app ad services are available? What are the relevant factors when choosing? How do different services compare?

As mentioned in my previous entry, I have been using Admob for nearly a couple of years now. In recent months though, I have noticed that for some of my apps, there has been a trend of (i) declining CTR (click-through-ratio) and (ii) declining eCPM (earnings-per-thousand-impressions). To illustrate this here are the figures for one of my games, Block Rampage

Admittedly Block Rampage is not one of my most downloaded games and so the figures are not based on a large data set. Also, not all my apps show this pattern. But it does nevertheless illustrate a trend, for which there may be a number of possible explanations:

1. Users are becoming accustomed to ads are less likely to click on them.
2. With an increasing proliferation of apps (and thus more available ad slots), advertisers are paying reduced amounts for their campaigns.
3. Admob becoming less competitive versus other players in the in-app ad market.

I regularly get emails from companies promoting their ad services. Not having the time to investigate, I tend to ignore most of them. That said, I decided it would be worth taking a look at some other ad services for comparison. I was interested in looking at how easy to implement the SDK is, what sort of income (eCPM) could be expected, and any other issues such as payout schedule and minimum payment threshold.

I started off by looking at MobClix, MobFox, and InMobi.


MobClix provides a mediation service with ads being obtained from multiple ad networks. This is attractive as it would allow testing of numerous ad services without having to implement multiple APIs. So I jumped right in and attempted to implement MobClix, but fairly quickly hit a problem. Although technically simple to implement, the SDK does require the app to have the READ_PHONE_STATE android permission. None of my apps currently use this permission, and I was reluctant to add it just to serve ads. The change of permissions would mean auto-updating of the app would no longer work, as users would be required to manually accept the new permissions. Also, as this permission gives the app access to the phone's IMEI and phone number, many users may be suspicious of why a simple game would need this permission.
The MobClix documentation states:
Required Permissions: android.permission.INTERNET - Used to retrieve ads. android.permission.READ_PHONE_STATE - Used to obtain a unique device identifier.
This justification - needing to obtain a unique identifier - is contradicted by the advice from Google on this page:
Android Developers Blog: Identifying App Installations
I raised this issue with MobClix support, and asked if they could at least make the READ_PHONE_STATE permission optional. However, they have not replied to my query. Therefore, my experiment with MobClix ended there!

MobFox and InMobi

I trialled MobFox in one of my games with a fairly low usage rate, Block Rampage. MobFox has a nice feature called "eCPM control", whereby unfilled requests can be passed on to another network. So I made use of this feature to also try out InMobi. This is similar to the setup suggested here by Project Journeyman.

The account creation, setup and implementation in the app was simple enough, so no complaints there. The payment threshhold for MobFox, $50 is pretty reasonable, but the schedule is NET 60 (i.e. 60 days after the end of the accounting period), is twice that of AdMob. After a few weeks, I took a look at the stats I was getting, and this is what I found:

1. The MobFox CTR and eCPM stats were similar to those I was getting from the same game when using Admob. I would describe them as satisfactory but not exciting. Anecdotally, I did happen to notice the same ad seemed to be appearing frequently, which did give me some concerns over the size of MobFox's range of available ads.

2. The InMobi stats were very poor, mainly because of a very poor fill rate, typically 10-15%. The eCPM was actually comparable to MobFox and Admob when the ads actually appeared, but that's not much use when the fill rate is so low. Maybe I would have got better results by using InMobi's SDK directly, rather than via MobFox, but these initial results didn't give me cause for thinking it would be worthwhile trying.

Which Service?

So, my conclusion was that although MobFox may have some potential, none of the services tested so far seemed to significantly improve on the offer from Admob, at least for me. So, I have decided to stay with tried-and-tested Admob for now. I will be looking at some other services, e.g. LeadBolt and MoPub next.

Tuesday, 11 October 2011

Using Admob in Android Apps

Admob is a mobile advertising service, acquired by Google 2009. There are numerous competing ad services out there but Admob is the most well-known in the Android world. It's also the one I started with in January 2010, and continue to use today. In this article I would like to share with you my experience using Admob to add advertising to an app, mentioning the good points and a problem I came across.

On the right is the introductory screen of an app showing the Admob "test" ad. The screenshot is from an accelerometer-based tilt game called Tilt 'n' Squish.

Nice features

Easy to implement:

Adding advertising to an app is pretty straightforward using the Admob API. The basic element is an "AdView" class which can be added to your screen layout just like any other view. The API also provides a degree of flexibility and additional options, for example to define ad appearance or choose whether to enable location-based ads. Your user account can also be easily managed via the Admob website.

Fast and reliable payments:

Admob start to process payments one month after the calendar month in which they are earned. In practise, I found this means the income made throughout January would typically arrive mid-March. That might not sound speedy but actually it's one of the fastest payment schedules out there.

Ability to create "House Ads":

There is the possibility to create your own ads and have Admob show these in the case where there are no others available. If you have more than one app or service, this is a particularly convenient method of cross-promotion.

AdSense integration:

It is now possible to increase the number of ads available to you by using Google's AdSense network. This option is available in the Admob online account management area.

Using location to optimize ads:

If your app uses the phone's location (i.e. has either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permissions), then you can pass the location information to Admob, to (hopefully) serve a more relevant ad.

Here is some example code - this method loads and shows the ad, and should be called whenever a layout containing an ad element is shown.
public void showAd() { AdView adView = (AdView) findViewById(; if (adView != null) { LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE); Location location = locationManager.getLastKnownLocation(LocationManager.NETWORK_PROVIDER); AdRequest adRequest = new AdRequest(); adRequest.setLocation(location); adRequest.addTestDevice(AdRequest.TEST_EMULATOR); adView.setVisibility(View.VISIBLE); adView.loadAd(adRequest); } }


This is a problem I hit pretty quickly with the 4.1.1 version (latest at time of writing) of the Admob SDK.

It seems to affect only older Android (1.5 or 1.6) devices, and is triggered periodically when loading an ad. The application would unexpectedly crash - but with no "force closed" dialog and no stack trace. However there was a long VM crash log which started like this:
10-11 11:10:14.363: INFO/DEBUG(9241): Build fingerprint: 'tmeu/htc_hero/hero/hero:1.5/' 10-11 11:10:14.363: INFO/DEBUG(9241): pid: 13148, tid: 13165 >>> com.spwebgames.test <<< 10-11 11:10:14.363: INFO/DEBUG(9241): signal 11 (SIGSEGV), fault addr 00000000 10-11 11:10:14.363: INFO/DEBUG(9241): r0 00000007 r1 411ab858 r2 411ab858 r3 00000000 10-11 11:10:14.363: INFO/DEBUG(9241): r4 411ab858 r5 001c7458 r6 00000000 r7 44adfcac 10-11 11:10:14.363: INFO/DEBUG(9241): r8 44adfda0 r9 4104be40 10 4104be2c fp 00000001 10-11 11:10:14.363: INFO/DEBUG(9241): ip 00000011 sp 44adfc70 lr ad046f05 pc ad03ff72 cpsr 00000030 It's probably the same problem as in this report.

The solution is to ensure the ad is destroyed when each view containing the ad is destroyed. This means calling a method like this just before an ad-containing layout changes:
public void destroyAd() { AdView adView = (AdView) findViewById(; if (adView != null) { adView.destroy(); } }

Using Admob

Overall, I have found Admob to be an effective and worthwhile method of generating income from free apps. The ease of implementation combined with Google's large advertising network make for a compelling combination. However, a number of other players have appeared on the scene such as MobClix, InMobi and MobFox, and there is some debate as to whether Admob is still the best paying service from the developer/publisher's viewpoint. I will try to investigate this question in future articles.

Wednesday, 28 September 2011

Android for the Java Developer - part 2

In part 1, there was a brief introduction to developing on Android from a Java programmer's perspective, with some of the similarities and differences highlighted.

The purpose of this article is look at some of these differences in more detail. For a pre-existing Java app, these are effectively the parts of an app that would require Android-specific development rather than simply re-using Java code. As a Java developer myself, they are also the differences I first noticed when I started to develop with Android.

When comparing the Java and Android development process, it's worth remembering that the two languages are there to address requirements. A client-side Java app would usually have been written for a desktop computer with a large screen, mouse and keyboard. In contrast, the Android app is likely to be running on a smaller device with touch screen and (possibly) no keyboard. In addition, the Android device may have other features you may want to make use of such as the GPS for location information, or the accelerometer.
That said, now let us look at some common tasks and consider how to approach them in Android...

User Interface Layouts

Most commonly, writing Java user interfaces meant using the java.awt or javax.swing packages. Due to a lack of good-quality UI building tools, this may have meant some painful manual coding. Anyone who has wrestled with the finer points of GridBagLayouts and the like knows what I mean. The good news is that Android makes UI design a lot easier by defining an XML-based layout language. Here is a fairly readable example of an XML fragment that produces a component with two buttons, labelled "Start" and "Exit":
<LinearLayout android:layout_width="fill_parent" android:layout_height="fill_parent" android:padding="5dp" android:orientation="vertical" <Button android:id="@+id/button_start" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="Start" android:textSize="16dp" android:drawableLeft="@drawable/icon_start"/> <Button android:id="@+id/button_exit" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="Exit" android:textSize="16dp" android:drawableLeft="@drawable/icon_exit"/> </LinearLayout>
Essentially your Android app should contain an XML layout file like this for each screen, which simply needs to be saved in the correct location (PROJECT_DIR/res/layout) in your project.

Handling Events

In Java, UI components and controls (such as buttons, menus, checkboxes, etc) have the ability for listeners to be assigned. The listener responds to any events from the component, such as a button press in this example:
Button startButton = new Button("Start"); startButton.addActionListener(new MyActionListener()); public class MyActionListener implements ActionListener { public void actionPerformed(ActionEvent evt) { //the button was pressed! } }
In Android, the model is almost exactly the same. Assuming the button in question has been defined in the XML layout file (see above), we can access the button in code and define a listener as follows:
Button startButton = findViewById(; startButton.setOnClickListener(new MyOnClickListener()); public class MyOnClickListener implements OnClickListener { public void onClick(View view) { //the button was pressed! } }

Loading Graphics

Most applications will need to load image resources. In java, depending on how your project is structured, you may have something similar to this:
public class ImageHandler { private Image titleImage; public void loadImages() { URL url = ImageHandler.class.getResource("title.png"); if (url != null){ titleImage = Toolkit.getDefaultToolkit().getImage(url); } ... } }
In Android, some of the work is done for you. The image file simply needs to be dropped into a standard location in your project (PROJECT_DIR/res/drawable). The equivalent code would be:
public class ImageHandler { private Drawable titleImage; public void loadImages() { titleImage = resources.getDrawable(R.drawable.title); } ... }
The "R" class in Android is auto-generated by the build process. All your resources (images, sounds, layouts) can be accessed via this class.

On-screen Rendering

Sometimes you may need to draw shapes or images directly on screen using a Graphics context. This is typically the case with simple games. In a Java Applet/Application, you can use the Graphics or Graphics2D class do this:
public void paint(Graphics g) { //change the colour g.setColor(Color.BLUE); //draw some text g.drawString("Hello world", x1, y1); //draw a rectangle g.drawRect(x1, y1, wd, ht); //draw an image g.drawImage(titleImage, x1, y1, wd, ht, null); }
In Android, the approach is similar. There is a SurfaceHolder interface from which you can get a Canvas object to use for your drawing:
public void paint(Canvas canvas) { Paint paint = new Paint(Paint.ANTI_ALIAS_FLAG); //change the colour paint.setColor(Color.BLUE); //draw some text canvas.drawText("Hello world", x1, y1, paint); //draw a rectangle canvas.drawRect(x1, y1, x2, y2, paint); //draw an image titleImage.setBounds(x1, y1, x2, y2); titleImage.draw(canvas); }
Important differences to note: (1) In Android, it is necessary to create a Paint object - this will control details such as the colour, line thickness, etc of drawn objects. (2) In Android, methods such as drawRect use the coordinates of the rectangle's vertices (x1,y1) -> (x2,y2), rather than the width and height arguments as used by Java's drawRect.


We looked at some factors a developer needs to be aware of when developing on both Java and Android platforms, or when learning Android from a background in Java.

There are lots of other differences between the languages of course, but hopefully these represent a good starting point. Let me know if you think there should be more articles along these lines. The next article will be about using AdMob to generate income from in-app advertising.

Wednesday, 21 September 2011

Android for the Java Developer - part 1

In this article, we will look at beginning Android development from a Java programmer's perspective. We will take a look at the similarities and differences between Java and Android, and consider how these may affect how best to develop an Android app. The information may assist if you are, for example:
  • Converting an existing Java program to Android.
  • Developing an application for both Java and Android.
  • Have some experience with Java and want to learn Android.

Android can be thought of as a direct descendant of Java. Not only do the languages share are large common core, but also many existing Java libraries can be used in Android apps directly and without modification or recompilation. This makes Android a relatively easy step for anyone who has a Java background.

Let's take a look at some of the well-known package names from the Java SDK. Those on the left are also included in Android. Those on the right are in Java only.
Packages in Java AND Android ¹ Packages in Java but NOT Android
  • java.beans
  • java.lang
  • java.math
  • java.nio
  • java.sql
  • java.text
  • java.util
  • javax.crypto
  • javax.sql
  • javax.xml
  • java.applet
  • java.awt
  • java.rmi
  • javax.sound
  • javax.swing
¹ Top level packages only, not an exhaustive list.

It's clear that a very large chunk of the JDK is available to the Android developer. In addition, because Java libraries can incorporated into an Android app, it means any existing Java library can be used as long as it only needs packages from the left-hand column.

Turning now to the right-hand column, arguably the most significant "missing" packages are the ones related to user interface building, java.awt and javax.swing. This is because Android has its own system for building UI elements - more on this in another article coming soon.

So what to conclude from this, and how should it affect the design of an Android app we might want to build? Good application design should separate the core program logic from the user interface. If this principle is used, it will also make life easier should you want work with both Java and Android. The program logic parts of the app are typically going to use packages common to both languages, and hence can be easily reused.

A pure Java user interface cannot be reused however, and so an Android-specific version will need to be built. We will look at aspect more in the next article (coming soon).

For those developing an application for both Java and Android, or wanting to migrate an existing Java application to Android, here is a simplified diagram of how an app might be structured.

In the next article, we will explore in more detail the differences between Java and Android, and how we might navigate these to build our Android app.

Friday, 9 September 2011

What's this all about?

I am long-time programmer who started experimenting with the Java language in the late 1990s when the latest JDK version was only 1.1. In those days I created a number of simple browser-based applet games which I then put on my website,

After that, my main focus shifted to what became the mainstay of Java development, server-side web applications. However, In late 2009, with Android set to become the next big hit in the mobile device world, I decided to dust off these applets with a view further developing and converting them to Android.

I now have over 10 apps released on Android Market with the degree of success varying markedly (Downloads ranging from around a thousand to several hundred thousands). I decided it was time write some notes on my experiences, and in particular, on these topics:

- The current state and future of Android development
- Using in-app advertising services to generate income
- Converting Java applications/applets to Android
- Programming for the web
- Anything else that comes to mind