Airpush.com - Spam might be coming soon to your Android too

Having moderately successful application on Android Market (a few hundred thousand downloads or more) changes the rules of the game. Instead of knocking on their doors, you get invited to closed app stores owned by smartphone manufactures or carriers. Very same way you get invited to join all those ad networks that are supposed to bring you in some revenue.

Ads found within mobile apps are OK. In a perfect world, they would not exist but in this one they are acceptable. In most cases, ads are the only way for application developers to monetize their efforts; and there is nothing wrong in efforts being monetized. Out of the 10 apps that we have published through Android Market, 6 of them contain AdMob banner ads, placed at the bottom of the screen. The revenue from these ads does cover some of our expenses but once the app sales start building up, the ads are out. Anyway, back to the story.

Recently a sales representative from Airpush - the 'next-gen mobile ad network for Android apps' - contacted us. They were not shy about broadcasting their offer and, as you can see from their web site, they guarantee 10 to 30 times more ad revenue. This sounded more than interesting and it deserved a closer look. Just how were they able to promise such high CPMs? Read on ...


Airpush ads come in three different flavors: Push Notification Ads, Icon Ads and Signup Ads. The last one (though currently in a closed beta) is the standard ad screen that is displayed when the application launches or is triggered by the developer later during the app session, so I do not find it that interesting and innovative. However, the first two flavors, the Push Notification Ads and Icon Ads, they are the real refreshment in mobile ad industry.

Push Notification Ads

Our lovely Android notification tray. With all that icons like battery status, signal strength, and all those important notifications regarding received SMS and email messages, etc. Well ... why have the developers been waiting until now? Let the ads march in! Ads are important, and we should be notified about them. The very same way we are notified about our missed calls.

Image (C) by Airpush.com

Icon Ads

Clean smartphone desktops are overrated. Who needs order within those small screens anyway? We need more shortcuts, shortcuts that would 'link to valuable user content such as mobile search and daily deals'.


All joking aside, this is a serious issue. It would be sad if this ever catches on. Just imagine what kind of user experience you would have with gadgets of such a personal nature such are smartphones! So here is what we think about it and what we said in response to the Airpush sales representative:

We find your ads too invasive. They are more like spam. We would uninstall the app that introduced them on our device and we would give it a low rating accompanied with a raging comment. So, we are not interested and please do not contact us again.

Ads are already here, and let's keep them inside the apps themselves. Let's not allow them to infest our phones. For all those who would like to see what kind of Airpush horror they might expect to see on their phone, the demo is available here:

https://market.android.com/details?id=com.airpush.demo

I haven't tried this demo out as it asks for 'Read phone state and identity' permission.

I should be fair and mention that Airpush offers opt-out options. For Push Notification Ads, you can opt out, ad by ad, by clicking on provided opt-out links. You can opt-out completely as well, by installing Airpush's opt-out application or providing them with your IMEI number on their web page, which ever you prefer. It looks like you can't opt-out from icon ads, but Airpush says that you can remove those easily with one click. Well, we can remove them, shouldn't that make us happy enough? ;-)


Update: the same goes for LeadBolt.

Startup-related Podcast Episodes - Personal Recommendations

Sasha Strauss interview on Mixergy, archived.
Avinash Kaushik interview on Mixergy, archived.
Peter Voogd interview on Mixergy, archived.

Error reporting in Android applications

Why reporting?
Android application developers are well aware that their target devices are taking over the world. A vast number of them is already out there, and many more are yet to come. For an incomplete ever-growing list check out the Wikipedia article here: Comparison of Android devices. It’s starting to look like a flood and we have to be ready.

So many OS versions, so many display resolutions, different available sensors, different locales and language settings, different … it is obvious that you will not be able to test your application on all those variations, even if you wanted to do so. However, error conditions will happen and your bugs will slip through after the application is published …

Embrace the inevitable, in these cases your users will often be the first who’ll get hit. So let’s make things less painful for all of us.

When sh*t (i.e. error condition) happens we should do the following - show a polite error message to user, obtain a full stack trace for ourselves. Regarding the polite error message - avoid any kind of technical jibberish, these devices are complex enough for all non-geeks already. You do not need to make things even more confusing. And regarding the full stack trace - welcome to the craft of silent error logging.

What the logging should look like?
Here is the list of nice-to-have features:

• Log data is sent real-time back to us

When application crashes / reaches unwanted state, we want to know it immediately. Fix might be trivial, we might publish the new app version right away and leave better impression on users.

• If Internet connection is not available, log data is cashed and sent when possible
• Application user can turn logging off

In fact, logging should be invisible to users. However, if for some reason user wants to turn the logging of, he should be able to do so.

• Logging is turned off while application is in debug mode 

There is no point in collecting data while logs are displayed on our screen right away.

• Application crashes and freezes are reported as well

Not all your users have Android 2.2+ devices that have crash & freeze reporting and not all your users have downloaded application from Android Market.

• Easy to integrate
• Preferably Open Source Software

What should be reported?
Here is the list of mandatory things:

• Caught exception or custom message
• OS version
• Device type
• Package name
• Application version
• ...

How it should be reported?
Here are the possibilities:

• Via HTTP to your server
• Via HTTP to Google Docs
• Via email

What are the error reporting libraries available out there?
First, my recommendation - ACRA (Application Crash Report for Android). You should check the URL, it really has more or less all of the mentioned features and it is really easy to integrate / use.

Other available libraries are:

• Flurry
• android-remote-stacktrace (not updated since Dec 10, 2009)
• android-log-collector (not updated since Nov 14, 2009)
• microlog4android (not updated since Sep 12, 2010)

Also, some blog posts that you might be interested in:

• http://jyro.blogspot.com/2009/09/crash-report-for-android-app.html
• http://androidblogger.blogspot.com/2009/12/how-to-improve-your-application-crash.html
• http://androidblogger.blogspot.com/2010/03/crash-reporter-for-android-slight.html

And relevant Q&A on Stack Overflow:

• http://stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application

Happy coding!

javax.jdo.JDOException: Class Date for query has not been resolved.

You have to declare missing imports using query.declareImports(). Example:

Query query = pm.newQuery(
    "SELECT FROM " + Device.class.getCanonicalName() + " WHERE" +
    " lastSeen < dataExpireDate"
);
                 
query.declareImports("import java.util.Date");
query.declareParameters("Date dataExpireDate");

'or' filters can only check equality Exception

As described in "Query Filters" section here:

... keep in mind that || can only be employed when the filters it separates all have the same field name. In other words, || is only legal in situations where the filters it separates can be combined into a single contains() filter.

Email parsing and automated responding with PHP

In this short post I'll show how to create a simple email responder in PHP. No big deal, we are just going to reply on each received message with a new message that contains custom body and the very same subject.

If you are interested in more complex example feel free to check it out here. It is an email auto responder that for given location (address or coordinates) in Croatia replies with the list of neighboring points of interests. It also features abuse blocking implemented via PHP Authorization web service.

But now let's get back to our simple example!

In first two steps we are going to create a new email account and set a forwarder. Let's say that your hosting environment is equipped with cPanel. The instructions are not much different for any other site management application.

So, in 'Mail' section we click on 'Email Accounts':

and fill out the 'Add a New Email Account' form. For example:

We click on 'Create' and new email account is there. Now let's set up forwarding for that account. Again in 'Mail' section we click on 'Forwarders':

 

Here we configure forwarder for newly created e-mail address. As 'Destination' we select 'Pipe to a Program' and in text box we enter a relative path (from home directory) to our PHP script:

After we click on 'Add Forwarder' we are done with cPanel. Before we go on with PHP, you can try out what has been done so far and send a first email to forwarded address. In case you do so, you can expect a bounce back mail with the similar content:

We have received an error since the message was forwarder to non-existing script. Nice, let's proceed with PHP.

First important thing is that before our <?php tag, we have to start with hashbang. In my case, the hashbang is the following:

#!/usr/local/bin/php

This basically says that our script should be interpreted by PHP which can be found on that and that path. Tha path to PHP executable might be different on your system, you can find it out by executing which php in your console.

Second important thing is that actual email is piped to our script via standard input aka stdin. We can think of stdin as of a file that can be reached by opening php://stdin

With the following statement:

$lines = file("php://stdin");

we will read complete email into array of strings, each string being a line. As it has been said earlier, our auto-responder will reply back to sender with email that contains the same subject and a custom message body. For that purpose we'll extract 'From:' and 'Subject:' fields using regular expressions. So the complete code snippet would be:

#!/usr/local/bin/php
<?php

$from    = "";
$subject = "";
$message = "Thanks for email!";

$lines = file("php://stdin");
foreach ($lines as $line) {
 if (preg_match("/^From: (.*)/", $line, $matches)) {
  $from = $matches[1];
 } else if (preg_match("/^Subject: (.*)/", $line, $matches)) {
  $subject = $matches[1];
 }
}

mail($from, $subject, $message);

?>

We are not done yet. As our script should be executable file and not a webpage, we have to set the right permissions and chmod it to 0755. Another important note is that PHP script should not produce any output, so be sure that you don't have any trailing whitespace after ?> tag.

Depending on your requirements and frequency of incoming emails, as mail function is time consuming, you might want to send out emails in batch mode when server is not under heavy load. In that case you should check out PHP Batch Mail.

And that would be it!