Changes to Google's Android Market Developer Distribution Agreement (DDA)

This morning I had a new message from 'Android Market' in my inbox.  It stated:

You are receiving this email because you have applications published in Android Market.

We'd like to let you know that there is a new Developer Distribution Agreement (DDA) for Android Market. The next time you sign in to the Android Market publisher website, you'll be asked to agree to these new terms before continuing. If you have not accepted the new DDA by Monday, August 23, 2010 12:00:00 PM Pacific Daylight Time, your application(s) will be unpublished from the Android Market.

You can view and accept the new agreement by visiting http://market.android.com/publish/ddaUpdate. Please do not reply to this message.

Thanks,

The Android Market Team
 
As I've only recently become an Android developer I sat up and took notice.  Maybe more experienced developers get this kind of e-mail every month or so and are just used to agreeing to the new agreement without looking at the changes that were made.  I had made the point of printing out my original DDA so took the time this morning to compare the original (retrieved from Google's UK DDA publishing point on 24th June 2010).

So, what did I find?...

Section 3.2:  The URI specified for 'Transaction Fee' used to be http://market.android.com/support/bin/answer.py?answer=112622 which works. The new document states a new URI as http://www.android.com/support/market/bin/answer.py?answer=112622 which does not work - or, at least, has not worked for the last three hours (between 6am and 9am GMT, 24 July 2010).  This is what I get:

Hmmm...  Maybe it's on the TODO list of somebody at Google for Monday morning?

Section 13.1:  I don't have any legal qualifications of any sort but this is the first paragraph where there is a significant change.  It talks about indemnification.  They've juggled the stakeholders around a bit but from what I can see the main implication is that they've now added 'any Authorized Carrier' as an additional entity that we, the developers, need to be protecting from law suits!

Section 13.2:  Brand new paragraph.  How exciting!  Looks like an attempt to protect Google and (more importantly) the payment processor (err, that'll be Google again then!) against tax authorities.  That is we, the developers, indemnify them against claims in that respect too!

It's worth noting that the agreements I've been reading are specific to the UK and that Google do publish different documents for other jurisdictions (e.g. US and Australia).

I'm not sure how often Google update the DDA but the strict tone of the alert email makes me wonder if there's an ulterior motive here.  Is this a handy way of 'booting' the various Spam developers who flood the Market.  I wonder.

And, finally, if I'm going to get really picky...

Section 7.2 (c):  Typo in both documents 'rgeulations' should be 'regulations'.
Section 15.1:  Typo in both documents 'acse' should be 'case'.

But then in my limited exposure to the legal fraternity (getting contracts drafted for my business in respect of employment law) I've never been very impressed with their accuracy or ability to work the basic tools of the trade...  like, for example, a word processor!

Android Market Developer Distribution Agreement versus Wordle

It's funny the things that cross your mind when you're up early on a Saturday morning, watching BBC breakfast news and reviewing Google's latest legal agreement updates!

Last night Google sent me an e-mail in relation to my Android Market developer account.  They've updated the DDA document.  So I decided I would have a read through to compare differences from the original version I signed up to (yes, I do keep these things!).  Then BBC News' Click had an item on Wordle and I couldn't resist.  I had to put the DDA through it...

Click for larger version.

Quite revealing I feel.  I doubt 'word soup' would be a foolproof strategy for the rest of us to read legal documents... but...

Does HTC Sense... err... make sense?

I've just finished an early evening meeting with a salesman who's quoting to fit us some windows.  He's of my parents generation so not so comfortable with modern technology (though I have no doubt he knows his windows!).

Anyway, I whipped my Nexus One out to do some calculations and he identified that it looked very similar to the new handset he had just been sold by the O2 shop.  In fact it turned out he had the HTC Desire (same as the Nexus One but with a few cosmetic hardware changes and HTC's Sense UI as an additional software layer over the base Android look and feel).

He told me that he was a bit confused as to how to answer calls on it.  He was not sure how to answer it.

I did think this was something that they should have shown him in the shop.  And, besides, it's not exactly difficult on the Nexus One.  But I said I would take a look.

We made a test call from my phone to his.  I was immediately like a fish out of water as the interface on receipt of a call on the HTC is completely different.  In very small writing at the bottom of the screen it does explain what to do though.  You have to drag vertically in one direction to answer the call (I think it was down) and the other direction to drop it.

Every time he had received a call he had not had the time to read that little message and had simply jabbed at the screen until it did something!

Once I had showed him how that works we moved on to other niggles...  voicemail...

Firstly he had not been shown how to drag the notifications in to view from the home screen status bar.  I explained it in terms of being a drawer that could be opened.  Which clicked with him so we had a good starting point.

As it turned out he had already managed to get to voicemail but had not worked out how to get the number keypad up in order to control it!  On my Nexus One (i.e. default Android look) it says 'Dialpad' under the keypad button when you're in a call so you don't have to rely on just an icon to know which button to press.  HTC's 'Sense' only gives you a button with an icon that looks vaguely like a keypad.  To me as a techie this was obviously the button to press - but not anywhere near so obvious to my man from the window company.

I show him this (a revelation) plus, as a Brucie bonus, showed him the speaker phone mode too.

In 5 minutes of showing him through the basics of using his device he went away very happy.

I, on the other hand, am somewhat bemused.  I thought HTC were meant to be making the UI easier to use with 'Sense' (tm).  I don't think so.  Give me basic Android OS any day...

Java CodeTimer

In the process of writing my first Android application I had the need to time how long a particular section of my code was taking to execute. I couldn't immediately find an obviously available class in the Java or Android utility libraries to help me. So I knocked one up:

import java.text.DecimalFormat;

public class CodeTimer {

    private static final DecimalFormat formatter = new DecimalFormat("###,##0.00");

    private boolean paused = false;
    private long segmentStartNS;
    private long pauseTotalNS = 0;
    private long segmentCount = 0;
    private long minSegmentDeltaNS = Long.MAX_VALUE;
    private long maxSegmentDeltaNS = Long.MIN_VALUE;

    public CodeTimer(boolean startPaused)
    {
        reset(startPaused);
    }

    public void reset(boolean startPaused)
    {
        minSegmentDeltaNS = Long.MAX_VALUE;
        maxSegmentDeltaNS = Long.MIN_VALUE;
        pauseTotalNS = 0;
        segmentCount = 0;
        if ( !startPaused )
            segmentStartNS = System.nanoTime();
        paused = startPaused;
    }

    public void pause()
    {
        if ( paused )
            return;
        long deltaNS = System.nanoTime() - segmentStartNS;
        if ( deltaNS < minsegmentdeltans =" deltaNS;"> maxSegmentDeltaNS )
            maxSegmentDeltaNS = deltaNS;
        pauseTotalNS += deltaNS;
        segmentCount += 1;
        paused = true;
    }

    public void resume()
    {
        if ( !paused )
            return;
        segmentStartNS = System.nanoTime();
        paused = false;
    }

    public String elapsed()
    {
        double deltaMS = elapsedTotalMilliseconds();
        if ( segmentCount > 0 )
        {
            double avgMS = deltaMS / (double)(segmentCount);
            double minMS = ((double)minSegmentDeltaNS) / 1000000.0;
            double maxMS = ((double)maxSegmentDeltaNS) / 1000000.0;
            return formatter.format(deltaMS) + " ms ("
                + segmentCount + " complete sample" + ( (segmentCount>1) ? "s" : "" )
                + ": Avg=" + formatter.format(avgMS)
                + ", Min=" + formatter.format(minMS)
                + ", Max=" + formatter.format(maxMS)
                + ")";
        }
        else
            return formatter.format(deltaMS) + " ms"; // pause has not been used - simple report
    }

    public double elapsedTotalMilliseconds()
    {
        long deltaNS = pauseTotalNS;
        if ( !paused )
            deltaNS += (System.nanoTime() - segmentStartNS);
        return ((double)deltaNS) / 1000000.0;  
    }
 
    public long elapsedTotalMicroseconds()
    {
        return (long)Math.round(elapsedTotalMilliseconds() * 1000.0);
    }

}

The idea is that you instantiate a new instance of this class - optionally telling it whether you want it to time immediately. Then call resume just before the block of code you wish to time and pause just after. Doing this as many times as is necessary. You then use the elapsed method to get a textual description of all timings to far (e.g. to send to the Log.v function).

Hopefully this will help somebody! Please feel free to use this code snippet for your application. No attribution required.

Updated 14 July 2010: In use I noticed a bug in the elapsed method. I've now fixed this plus added two new functions to allow you to query total time passed in milliseconds or microseconds.

Google Android Nexus One

Having been using this phone for a few months I wanted to document my thoughts as to the implementation. Despite being a Google branded device it is actually manufactured by HTC.

Positives

Android: Full stop. Excellent, open operating system (i.e. not Apple or Microsoft). Froyo (update 2.2) which landed on my phone in early July 2010 only made the experience quicker and much smoother. I'm now teaching myself the Android SDK and learning a lot more about Java. There is certainly a learning curve going from the (slightly lazy) world of VB and .NET but I feel this can only enhance and improve my skills (generically) as a programmer. The market for Android Apps will only get bigger with the number of devices being released by big players using the Android OS.

Negatives

There are a lot of good things about this phone. But, of course, it's the bad stuff which tends to affect daily use more so that's what I am covering (for now) in most detail.

• The glass screen is far too fragile. Within a month of getting the phone I had broken the screen. Dropped from a table on to a concrete floor. Like buttered toast it had to hit the floor at the worst possible point - directly on a corner. Looking around the edge of the glass there is no visible sign of any dampening or buffering from the casing. Despite having it in the little (neoprene?) case that came with it the case managed to slip off 'mid-flight' on the way to the floor. What's really annoying is that I remember watching a Google / HTC sales video for the Nexus One showing how they tested the unit for robustness in a machine looking like a tumble drier. Cost charged to me by HTC UK for fixing my phone was 105 quid (included new screen, labour and postage). At my expense. Despite the fact that I strongly believe this is a design flaw - phones DO get dropped.
• The power button (top left edge) does not, unlike the iPhone 3G, require a long press to power up the device. Just the lightest, shortest press turns the device on. This is a major problem if you've turned it off during a long flight or similar in order to save battery as it's quite liable, with the slightest brush past the power button, to switch itself back on. As, indeed, it did for me on a flight to the US. Important contact details for where I was staying were inaccessible to me on arrival thanks to the battery being completely drained. I had turned it off on departure but it had turned itself back on mid-flight (probably as I put it in my bag or pocket). Very annoying.
• The USB port at the bottom of the device, also used for connecting the charger, does not use the popular Mini USB B-type (like most devices). Instead it uses the Micro USB B-Type. Most of my devices whether they be scanners, cameras, hard drives or phones use the sensible (accepted standard) Mini USB connector. Why HTC / Google chose Micro USB I cannot understand. I have lots of Mini USB cables but cannot just 'grab' one to work with my Nexus One because it has to be the odd one out using silly connectors. The same goes for charging it.
• Battery life. Always a problem with smartphones it seems. And this is no different with the Nexus One. If you switch on WiFi when you're at home or in the office and enable background synchronisation then you'll be lucky to last until early evening before the battery indicator has gone orange indicating battery level circa 10%. And that's on a day when I don't use the phone that much. I have to get in to the routine of switching off WiFi, background sync and sometimes even 3G when I go out and about just to ensure my phone lasts a whole day. To function, let's face it, as a phone! At least, unlike Apple's phones, this device can have the battery changed. So, maybe... just maybe... somebody will come out with a battery technology that'll keep these devices running for days as opposed to hours. While my Nexus One was away with HTC to have the screen fixed I was using an old Orange SPV handset for a few days. This required a charge once every three days!