An uncustomary user messaging misstep from Google search.
Asking two questions and only providing for one answer is confusing. Here, answering yes actually opts you into the service. This isn’t clear from the “Yes” button, the label for which suggests it’s answering the second question but not necessarily both.
I’ve been unable to code for the past week, so as I started to ease myself back in today, I took time to investigate a phenomenon I first noticed months back.
Reto Meier has been a strong advocate for the use of analytics, his code and all the available sample code indicate that you call the analytics tracker on the UI thread. But if you use the Google Analytics SDK for Android like this, calling the tracker on the UI thread, it can make your app very unresponsive. I noticed this after adding the library to my Metaglow application, buttons that had felt very snappy immediately felt sluggish, even though I’d taken care to keep the UI thread ‘hygenic’.
Today I sat down and wrote a little stub of code that collects some basic call-time statistics for the GoogleAnalyticsTracker class from version 1.1 of the SDK. I made a few runs on my Nexus One by proceeding to use Metaglow over an extended session. In each run I collected timings for approximately 100 calls to the trackPageView and trackEvent methods.
Of the three runs, these were the most typical numbers (one set slightly was slightly faster, one set was significantly slower):
So, you can expect users to occasionally encounter UI glitches of 1/5th* of a second or more just from queuing an analytics event; and (admittedly I don’t have figures for this) it’s my experience that the pauses are more significant than this; infrequent, but long when they occur; this gives a bad user experience.
It’s documented that the analytics data is queued into batches and dispatched separately from the call that records them, so this behaviour (infrequent but lengthy pauses) can’t be due to network I/O. But it is what we are told to expect when we are performing writes to Flash storage. So I used traceview to peek inside the execution of the analytics code and confirm that this was the cause.
Those green blocks, which are just about visible, are writes inside Sqlite3 and this explains the uneven performance.
Since I want to keep analytics I will probably write my own event queue around the Google analytics tracker, to decouple it from the UI thread. If you use Google analytics and want to give users a smooth experience, you may need to do this work too.
(*) this figure is based on 2 standard deviations above the mean
I think Apple has adopted an interesting market strategy.
It has been clear to me, since coverage of Apple partnership with News Corp. began, that Apple had shifted its emphasis from application sales to book/magazine sales in a way that is similar to the smooth evolution from music sales to encompass application sales that preceded it. But where there are similarities, there are also differences.
The recent news that Apple is to monopolize in-app purchases1 might strike one as bold to the point of hubristic. But I think this is the reasoning behind it:
Companies want their services and applications present on Apple devices because they are well regarded and extremely popular. Nevertheless, Apple almost certainly perceives the threat that a large number of cheaper (but nevertheless extremely capable) devices running the Android OS will significantly limit future iPhone/iPad sales. One direct way of neutralizing this threat is to make the Apple devices cheaper to buy2.
A device can be continue to be made to the same high standards (preserving it’s brand status) but sold more cheaply if it can become the source of other revenue. If Google can subsidize handset manufacturers by giving them Android for free in anticipation of future advertising revenue, one might reason that Apple can compete by subsidizing their own hardware with the burgeoning revenue from in-app purchases.
A virtuous circle for Apple may emerge: lower hardware pricing yielding more users, forcing online merchants to sell via Apple’s devices, generating more revenue for Apple that can be used to further subsidize hardware prices.
I don’t often share my predictions or analysis on my blog (not enough time - I’d never get any coding done) so I’m not used to waiting to see if events bear me out. This time, I’ll be following the tech news about Apple a bit more closely - I might be able to say “I was right”.
