This was also nicely put by the article Android iOS Development Monetization Marketing: “The facts are pretty staggering. While all of us iOS app marketers have our heads buried in the latest App Store algorithm changes and churn and burn models, the rest of the world was buying Android phones.”

Also according to netmarketshare.com stating in the article Android overtakes iOS in usage stats for the first time ever: “The latest data from Net Applications show that smartphones and tablets powered by Android were used more than iPhones, iPads, and iPod touches powered by iOS this July. While iOS usage dipped from 45.61% in June to 44.19%, Android’s increased from 43.75% to 44.62%.”

Therefore one might conclude that a global market share difference of 73% and more app usage will equal more money on Android. However it’s a bit more complicated than that as this article claims: “Real differentiators between iOS and Android are their users”.

At the end Google Play downloads exceeded iOS App Store downloads by around 60 percent this quarter, while the iOS App Store earned about 80 percent more revenue according to App Annie Intelligence estimates. More can be read here.

As always – it depends as stated in the article Android Monetization Myths: “Actually, numbers imply that Android apps can be just as profitable when monetization is done properly and with respect to specific rules that guide customers’ behaviour on the platform. For example, direct sales and in-app purchases are clearly Apple territory at this time, but Android offers much more in terms of potential for ad-driven revenue. […] Don’t get discouraged by the urban legends about Android monetization and get reliable data before you start planning how to make money on your app.”

It’s healthy to test for yourself here are some lessons from Chris Pruett’s GDC Talk 2013 (Robot Invader) – Fact and Fiction: Lessons from Wind-up Knight and Rise of the Blobs

Everyone who uses apps knows that they are sometimes rather tough to exit. It’s not always because developers don’t care too much about it. Sometimes the api is tricky. If you want the user to exit your application by pressing the back button you need to override the onKeyDown method in your activity. The default implementation would be moveTaskToBack(true), which basically pauses your app and sends it to the background, right? Wrong! Because it only pauses the ui-thread.

Which means any other asynchronous task running keeps running. It wastes resources, leading to a worse user experience and and eventually to uninstalls. Why? Because it’s a unexpected behaviour. I mean don’t get me wrong, it’s perfectly fine if the app goes to the background because the user is getting interrupted by other apps. However if he wants to exit, he should have a possibility to do so. But what then?

Calling finish() often doesn’t do the trick. In that case you can use killProcess with the app process id.

Java

1

2

3

4

5

6

7

8

@Override

publicbooleanonKeyDown(intkeyCode,KeyEvent event){

// cleanup app, save preferences, etc.

android.os.Process.killProcess(android.os.Process.myPid());

// finish(); // not working properly, especially not with asynchronous tasks running

// return moveTaskToBack(true);

returnsuper.onKeyDown(keyCode,event);

}

Done. Just make sure that you have finished all your business before actually killing your app like saving preferences, etc. It will immediatelly close the app.

Some time ago I’ve made a short post (here) about the basics of how to get opengl infos on an android device. For an app I’m currently working on it was required to get all interesting information once more in my android device information application. The basic idea is to add a respective opengl 1.1 or opengl 2.0 and possibly even opengl 3.0+ context to the active view, load all information in the onSurfaceCreate method of the renderer and remove the view afterwards again.

Soooo Albért and Marco were visiting me the past week. They needed a couch to crash in Berlin to watch the football world championship. Congrats to Germany by the way for winning the champion ship! Anyways, Marco works as a DJ and he was playing around with his laptop to generate some random sounds. That got me inspired to create a little app over night. It basically loops through a matrix of matrices of tones and plays them that’s why the name Soundlooper. Pure creativity I know, right? xD

In order to run your android unit tests automatically on external virtual server after each git commit you need a continuous integration system. There are a couple of good services e.g. jenkins and travis out there. But how do you use them? Here is one way for travis. You can start off by forking android-maven-example and adapt it to your own project. Maven’s package manager ability let’s you download and install all dependency packages. In example you also have several maven goals pre-defined. Most important ones are install – installing to a device or emulator, package – creating a jar of your libs and clean.

Now the automated tests are setup and you only need to make an account on https://travis-ci.org/ and turn on all the repositories which you want to let test.

The android maven example travis file is a bit outdated however. Android has been added as a first class citizen. So your travis.yml file could look like this:

For everyone who also ran into internal storage shortages on android devices, clear up /data/log, /data/lost+found/ and /data/local/tmp – in my case it consumed 1.7GB out of my 2GB memory. (requires a rooted device)

So here I was again, trying to figure out a way to get opengl infos like max texture size, max uniform vectors, max vertex attributes, etc. for several android devices. Technically you could just use a small getter:

The problem was that on many devices the the returned number would always be 0. That’s because there hasn’t been created an opengl context yet. As suggested on Stackoverflow you could create a GLSurfaceView, add a renderer which could read the required infos by adding the glsurfaceview to the actual main active view and simply remove itself when done. In order to get opengles 1.0 and opengles 2.0 infos you would need to create two surfacesviews with different opengl versions. The following example looks a bit complicated, because I use fragments which i need to update on the main thread after I got all the infos I wanted. A full example is on github.

I’ve been developing on multiplayer game called Drag’n Slay on at least 4 different locations and it’s been a pain in the ass to change the ip address on the backend-server web and unity android client and unity editor client everytime manually so they will connect to the socket.io (tcp) and diagram (udp) server.

So had an idea. What if I could let the clients connect to my already payed webserver and get the fixed but changing ip. I figured it would require a couple of steps to do so:

1) load ftp credentials from a git-ignored file 2) figuring out the lan and wan ip address 3) creating a php script that respond a json object with the accessable ip addresses to the server 4) uploading the php script to my always accessable webserver 5) loading the json file on the clients and connect to the server by using the dynamic ip address