Jan 6, 2016

Device Discovery in Wifi Networks

To use a baby monitor two smartphones have to connect. They have to find and see each other in the network, one device needs to discover another device automatically without much user interaction.

There was an IT world before the smartphone entered our lifes. So all the nuts and bolts are already available: to discover devices in a network you simply send a UDP broadcast message into the wifi network and listen for such messages on each device. This is the textbook approach which only took a few minutes of coding to build. Then the details of Android-reality bit me.

Does your babysitter talk "IP MULTICAST"?
In order to work with UDP broadcast Messages an Android application needs to have the permission CHANGE_WIFI_MULTICAST_STATE. Appearently, that is a safety measure in Google's thinking. However, I wonder which typical user actually understands whether an app should be allowed multicasts? Do your babysitter and your grandma understand what this is? Mine don't - but well, who cares, this permission is easily added to the application.

    Persmission CHANGE_WIFI_MULTICAST_STATE
    Allows applications to enter Wi-Fi Multicast mode.

From now on, when grandma does the babysitting with the app, I'll just tell her IP-multicasting is a good thing... sure she will understand.

Some devices just kill broadcasts but won't tell you
Android provides features and functions to manage IP-multicasting. Ultimately, this is to save battery life and avoid excessive use of multicasting which is a battery burner. You can switch multicasting on and off to cover only specific moments when you really need it. However, some manufacturers/devices simly ignore this without notice. Reason unknown, they just won't do UDP discovery. Go figure... The worst part of it is that there is no way for a developer to get feedback from the device, nothing like a reliable active/inactive status for multicasting.

To make device discovery working also for such non-multicast devices another discovery technique must be in place. The obvious choice is to use a TCP scan: check the whole subnet and ask each possible IP address if there is a baby monitor available. The major drawback of this is obvious - it can be a long running process for large Wifi networks in hotels and company buildings.

No netmask? An Android bug.
When building a TCP scan I noticed that on one of my devices, a new Moto G, the scan went on for very, very long. Other devices did well, though. After a lengthy tracing and log search analysis it turned out that Android 5 has a significant bug: it won't give your app the current Wifi netmask - it'll simply return zero which can lead to unpredictable behaviour. To Google this is a known issue (issue 82477). By now Google's bug database contains a good workaround. It is difficult to understand how such a fundamental flaw can make it into a consumer grade operating system.

Summary: while device discovery is easy in the textbooks, the reality in the fragmented Android device and version space makes it a challenging task using a combination of UDP broadcast, TCP scan and working around Android bugs.

Jan 3, 2016

App Store Optimization - A Language Trap (ASO part 2)

Looking at Google Play download statistics I noticed the following in the early days:

For some reason English downloads, with the US the biggest user space, are low compared to the peer group of similar apps. Typically, US-English should represent 20-25% of app downloads according to Google Play. I am seeing 2%. This is not good.

Lost in Translation
I am German. In Germany we use the term ‘babyphone’ - everyone knows what a babyphone is even though ‘phone’ is an english word. Pah! A quick check on the web reveals that ‘babyphone’ is not actually an english term, at least not one commonly used. It should be ‘baby monitor’, this is what I really meant. I stepped right into a language trap ... how could this happen? To me?

A/B Test
Before I change texts in the app store listing I'll give this idea a verification. Another A/B-test is set up quickly in Google Play, this time it's a localized test to compare different texts in the English listing.

 
However, this A/B test is not showing any meaningful results. Either actual download numbers in the US are too small to produce meaningful statistics, or the text doesn't make a difference at all. Maybe parents in the US are not checking on their babies? Hm...
 
Looking at this for a while I noticed that in the A/B tests only the description texts can be changed while the app title remains:
 
 
Probably, the app's title is actually what users look at most but the title cannot be A/B-tested. I went to try something different. Fortunately, there is a separate language provisioned for 'English - United Kingdom'. So there is a separate English language to play around with while keeping US unchanged. The app's English-UK downloads should acommodate for 7% of overall downloads according to public Google Play overall statistics, whereas I am seeing 3% for my app.
 
Testing with English-UK
I added a new language entry in the Google Play listing for English-UK and also updated the apk file to contain English-UK texts, changing 'Babyphone Wifi' to 'Baby Monitor Wifi'. After a few days UK downloads have increased to match the expected overall share of 7%:
 

Interestingly, also US downloads have increased a little but. It seems that some users in the US have set their phone to English-UK.


Doing the Change
With all the testing there now was enough confidence to change the name of the app from 'Babyphone' to 'Baby Monitor' for English users. With this change, cumulated downloads of English-US and English-UK users increased significantly - by approximately 200%.

 
 
Result: App store optimization is not always straight forward and may require a second thought.
 
Update: Not only 'Baby Monitor' is a good description of the app, I also use 'Baby Alarm' meanwhile