Category Archives: Android

Key learnings from analytics

Category : Android

Enough time has passed since I put Google Analytics into my Android game Laska. It has been collecting statistics for nearly a month now. Therefore, I want to share some data and show the key learnings I got out of it.

The majority of my users are from China and Poland

This was quite unexpected for me. The game is pretty german. It is even named after Emmanuel Lasker, the famous chess player. However, Germany is responsible for only a very small part of the visits. It is interesting for future localizations, because a mandarin translation might make a lot more sense than a german one.

There is always more to track

I started off with only tracking the in-app pages and a variable for won/lost games. But with this new information, there is already the next pending question. How many games were played at the easy level? How many at hard? What is the percentage of won games on hard? There is always more to measure and I will implement it in future versions of the game.

Devices used

The Samsung Galaxy S and HTC Wildfire are responsible for nearly half the usage. The most common display size is 480 x 800 with 42% of the visits, followed by 240 x 320 with nearly 30%. I did not expect the small display devices to have such a big share of the visits. One reason might be, that users in China and Poland are more likely to use lower end android devices than in the US or Germany.


Start measuring

Category : Android

I have been missing one important part of improving my software for a long time. But after starting my new job at 1&1 in Munich, I was reminded of how important it is.

always measure

Whatever you are trying to build is probably been used by an audience of users. Especially in the mobile sector, most of the software is built for a mass market. Therefore, good quality of an app is a requirement (but not a guarantee) for success. And for improving your software, you want to know which parts users are really using.

Does anyone care about the help document? How many percent of users ever opened it? How much time did they spend reading it? Where are your users from? It is possible to get some information out of Appstore/Market statistics, but only plain download numbers.

If you think measuring only makes sense for high traffic websites, consider this: I am using Google Analytics at this website for some time now. It tracks the location of every user and shows them in a world map. This is accurate enough to show the city of every visitor. With the relatively low number of users, I can have a pretty good guess which citizen of Tartu would visit my homepage. Or if any possible new employer checked out my homepage before the interview. You will find plenty of other interesting questions that can be answered by those numbers.

So head over to the Google Analytics for Mobile website, see how easy it is to integrate into your app and start measuring right away.


Android AppRater

Category : Android java

The Android AppRater is a little tool in form of a source code snippet for getting better ratings in the Android Market. Its basic idea is to kindly ask users to rate your application, after they have been using it for a while. Which is a fair deal, because many users only give negative ratings right before uninstalling an application. This way, you only ask those users that are actively using your application.

For my own Android game Laska (light-version) the AppRater is not yet integrated in the current Market version. But it will be part of the next update. The dialog will only be shown if the app is installed for more than three days and has been launched at least seven times. And if you dismiss the dialog, it will not pop up again. This is what it looks like:

Of course, if the application is a piece of crap, this doesn’t help in any way. But for all other apps, it might be worth the effort.

Concurrency in java (german)

Category : Android java

The Free Lunch Is Over – that is the famous headline of an article about how the evolution of hardware alone will not solve our performance problems anymore. With the rise of multicore CPUs, software developers have to put effort into their code, to see further performance gains. Even on mobile phones, as the Tegra 2 shows, we will see more and more multicore CPUs. Therefore, there is a good reason for using concurrency in your application. However, it can also be dangerous and lead to unpredictable errors.


The following is a talk I have given to co-workers about concurrency in general and how to do it in java. It focuses less on academic problems like deadlocks, but shows how painful multi-threading is with the standard library. And there are some best-practices for how to reduce the likeliness of errors.


Things I am missing in Android development

Category : Android

This is a list of things I would like to see for Android to improve the development of apps. Don’t get me wrong, Android is one of the best platforms out there, but this doesn’t mean it can not improve anymore.

Hot Code Replacement
It always takes a while to deploy your application on the mobile phone or in the emulator. If you just want to find out what is happening in the code this deployment cycle adds up to quite some time. I know it is hard to replace Dalvik code from a Sun Java machine, but it would help a lot. We even had hot code replacement with our Robocup machines while they were playing soccer. Another possibility would be to use something like hotswap for python. It monitors changes of source files and applies them to the running process as soon as possible.

Flawless USB Connection
There are many cases where you have to unplug and plugin the development phone again. For example when I adb uninstall an app, it can not be installed again until the USB connection has been reset. The same goes for installing an apk from the SD card. You have to connect the phone as an external device, copy the apk and unplug again, before installing the app.
Another thing is that LogCat most of the time does not recognize when the phone is plugged in again. So you always need to switch to the DDMS view in Eclipse, click on the device and go back to the Java view again.

Simple caching of files
Some time ago I had this question on StackOverflow. Disk space is extremely limited on current Android phones. On the iPhone you can easily bundle 20 Megabytes of data with your application, because the app partition is huge. In contrary, most G1 users don’t even have 3 Megabytes of space on their phones. So until every Android device has a huge app partition (or could use the sdcard for it), we need to cache files and delete them on demand. There should be a standard way of caching, like RomainGuy described it with SoftReferences for storing images in memory.

Just in Time Compiler
Now this one is already in the works, but it might still be a while until it sees the light of day. But obviously the overall performance is not even close to the iPhone right now. A JIT compiler should be able to nearly close the gap.

Hardware Graphics Acceleration
The hardware of most Android devices is capable of handling a lot of 3D objects and textures with high framerates. In the standard user interface, this acceleration is not used. Hardware acceleration with OpenGL should speed up the overall performance a lot.

What kind of things can you think of? Put your own wishlist in the comments.

(this entry is cross-posted from my old blogger site)

Android Fundamentals talk

Category : Android

This is the screencast and voice of my Android Fundamentals talk from december 2009. It was given on the 29th floor of our jentower for the towerbyte.

“Read More”

Android: Deploying multiple targets from one project (outdated)

Category : Android java

Update: This way of deploying multiple targets is considered outdated. There is a better way now.

This posting is about how to create multiple versions of your Android application without cloning the whole project. For example if you want to create a full (paid) app, as well as a lite (free) version of it, you might want to automate the task of switching between them. Both versions should be able to use different graphics, different strings and even different featuresets.

First of all, what causes trouble with multiple targets on Android is the auto-generated source code and the strict checking of Java. Strings and graphics are all kept in one place, namely the res folder. Simply creating one res folder for each target and switch between those folders solves the problem with all resource files. I will give an example Ant-script for this later on.

So, having different resource files seems easy. But there is one more problem. We want to have two different applications, so both targets don’t replace each other on our phone. Meaning, the targets need a unique package name in the AndroidManifest.xml. And it’s getting worse. When changing your applications package name, you also change the package of the automatically generated R file. This R file usually is referenced in a lot of source files – basically everywhere you need graphics, strings or other resources. So you end up editing a great amount of your sourcefiles when changing the application package name.

What is the trick over here? Well, I don’t have any. My approach goes through every Java file and changes the import statement for the R file:

There are several targets in this Ant-script. The default target is myproject, the others depend on the default target (for example myproject is always executed before the otherResources target). myproject does the following:

  • deletes the current res folder
  • copies its own customized resources into res
  • replaces all ocurrences of “import*).R;” with “import;”. This might be necessary if the iamdifferent target changed it to “import;” for example.
  • the package name in the AndroidManifest is changed to the target name

Just execute a target to switch to this version of your app. You need to refresh the project in order to reflect the changes. In Eclipse, this can automatically be activated by setting the following option:

One more thing that does not work out of the box is the android:name parameter in activity declarations of the AndroidManifest. When auto-generated, they are declared relative to the project package. This doesn’t work anymore when the package name is changed. Therefore you have to set the activity name with absolute values. Instead of

<activity name=”.Test”>

You have to write something like

<activity name=””>

For all of you who like free lunch, here is an example project with two targets ready for download.

This is how three targets of the same app look like:

Thats it. With this approach you can deploy as many customized versions of the same project as you want. If you are missing a step or know an optimization of this, please leave me a comment.

(this entry is cross-posted from my old blogger site)

Recent Posts