HTC Hero

A week and a bit ago I upgraded my phone (a Nokia 6120 - read the saga that led to me getting that one here) to the HTC Hero and thought I'd share my experiences thus far. I'd been following the progress of Google's Android OS for a while and really quite like the T-Mobile G1 but I'm on Orange with no plans to switch network so was pretty excited when I heard Orange were introducing the HTC Hero just in time for my contract expiring. The big screen, WiFi and GPS were plus points and, whilst I would have preferred a real qwerty keyboard like that of the G1, this being effectively the third version of that phone it should hopefully have a fair few bug fixes and refinements.

First off it comes in a pretty nice Apple-esque white box and after you've phoned the connections people and turned it on you're presented with a detailed and bright screen. Setup is straight forward and you're up and running in no time.

I should mention that I'm a pretty big user of Google services; Mail, Calendar, Docs, Reader are apps I use every day. I've blogged in the past about syncing my phone contacts with those held in Google Mail and it was great to not have to do the usual chore of copying all my contacts over from my old phone. Once I set up my Google account details in the Hero my contacts were all synced down - brilliant! What's better is that my calendar was now synced too which didn't work with SyncML on the old phone. My only criticism of this being that "My Calendar" in the phone is not the same as my "Derek Fowler" Google calendar - this isn't immediately apparent, in fact the two calendars even share the same colour coding, but if you add an event to "My Calendar" it's not synced up to Google. Once you realise this and pick the [your name] calendar that option remains selected and you can even hide "My Calendar" on the phone to make things clearer.

A really nice extension to the contact list added by HTC themselves is the ability to link phone contacts to their Facebook and Flickr accounts so that whilst browsing contacts you also get their Facebook updates, their Facebook profile picture appears in the contact list and Photo Albums on the phone will also browser your contacts Facebook and Flickr photos in addition to any you have stored on the phone. All in all some brilliantly functional Web 2.0 integration.

Google Mail on the phone is pretty similar to the app you can get for other handsets and, oddly, is separate to the actual "Mail" app. Admittedly GMail has features like Labels that you don't get with normal e-mail but still. Text messaging is presented nicely with messages between you and a particular contact appearing as a never ending conversation - something that really does make a lot of sense and I'm surprised it's taken handset vendors this long to think of it.

The browser on the Hero is excellent. It renders pages well and has multi-touch for zooming which is invaluable when you're browsing normal pages rather than those tailored for a small screen. A double-tap zooms in until the object tapped on fills the screen, double-tap again returns to the full page view - very similar to the iPhone browser.

One of the things that I've found to really let the Hero down is the onscreen qwerty keyboard. Whilst it's quite usable in landscape mode it just isn't big enough in portrait mode and, comparing it to the one on the iPhone you can instantly see it's considerably smaller. Thankfully there's the compact qwerty and phone keypad modes you can switch to which are usable, I've stuck with phone keypad.

Other let downs are battery life and the odd bit of lag. Initially battery life was pretty poor, being less than a day between changes however after a few full changes it's now up to about two days. Whilst it's not the two weeks I was used to with the Nokia it's okay considering the big screen and multitude of devices inside the handset. Lag wise it's most noticeable when switching from portrait to landscape mode however in general the phone is very responsive and what lag there is generally isn't enough for you to start getting impatient so that's good.

The Google Market is already full of a wide variety of apps and what's brilliant is that most are free. Highlights I've come across so far are:

• AndNav - a SatNav app that uses OpenStreetMap maps, no 3D view but promising
• beebPlayer - an unofficial BBC iPlayer app that supports both on-demand replay of old TV and radio shows but also live TV and radio!
• Last.fm - streams your recommendations, friends, neighbourhood etc radio
• Layar - augmented reality browser, shows you a view through the phone camera with markers pointing you in the direction of particular things
• Google Maps - excellent use of the built in compass in Street View to allow you to look around as if you're in the place
• Google Sky Map - similar to normal Maps it makes use of the compass to allow you to look around the sky, the app telling you what stars/constellations you're looking at and it even has a search function that will guide you to looking at the correct point in the sky for a particular object

Finally I have to mention one aspect that had me pleasantly surprised about the Hero. If you read other articles on this blog you'll gather that I'm a pretty big hi-fi nerd so I was very impressed when I plugged my headphones in to the Hero (via the 3.5mm jack) and had a listen. Sound quality is really excellent with an airy detailed delivery - I'd be willing to bet it would give most portable music players a good run for their money.

The always-valid entity anti-pattern

Jeffrey Palermo wrote an article about the fallacy of the always-valid entity recently in which he highlighted that guarding against an entity becoming invalid by having validation logic in the setters of properties raises more issues than it solves.

Another way of enforcing an always-valid entity is, what I have found elsewhere termed, the "verbose constructor". Having a constructor which requires a value for every property, or every valid combination of properties.

public Car(string make, string model, string serialNumber, 
           decimal engineLitres, int maxPower, decimal urbanMpg, 
           decimal extraUrbanMpg, decimal combinedMpg, 
           int fuelTankCapacity) { ... }

Car myCar = new Car("Audi", "A4", "12345ABCD", 1.8, 120, 
                    28.5, 51.4, 39.8, 65);

The "verbose constructor" is itself a good candidate for an anti-pattern for the following reasons:

• Modifying the entity means modifying every instantiation of it also
• Forcing a programmer to set these values when they may not be available will result in garbage data which is useless anyway
• Derived classes must call this verbose constructor either replicating every parameter in their own constructors or hardcoding values for some parameters (another anti-pattern)
• Unreadable code, without help from the IDE it's difficult to identify each parameter

The method Jeffrey highlighted in his post has to use exceptions to catch validation errors, which forces a programmer to use another anti-pattern; exception handling. Where programming logic is implemented by the throwing and catching of exceptions. Any call to a property setter of the entity must be wrapped in a try...catch... block.

The always-valid entity, however it's implemented, seems to lead to a minefield of bad code. The thinking behind the need for this blurs the line between two important distinctions:

• not setting a value vs. setting it to something incorrect
• what makes an object a valid type vs. what makes an object valid for a particular use

I touched on the first of these before; where it may be the case that a programmer doesn't yet have a value for a particular property available yet. So long as we ensure the entity doesn't leak out in this invalid state we're okay.

Which leads on to the second item; we should guard against a value being set where that value violates the type e.g. setting Day to 32 for a DateTime, something bad has occurred and this is a real exception case. However, this is a much lower-level problem than enforcing business rules, for example where a credit card applicant's date of birth must be at least 18 years earlier than the date of the application. It could be the case that one company actually requires applicants to be 21 so hardcoding that type of validation into the class is not only restrictive but enforcing this by throwing exceptions is very inefficient.

The always-valid entity just serves to be very restrictive and limits the entity's uses in its current form. Validating from outside means that its easy to skip validation or make it more stringent when needed. Also, if implemented along the lines Jeffrey describes in his post, it means mechanisms have a common way of validating objects without needing specific knowledge of the particular object or the current validation being applied which makes for more robust code.

OpenSession with connection disables second-level cache in NHibernate

I've has this post in my drafts for nearly a year now so I decided I'd finish it off.

I came across an issue when using the second-level cache in NHibernate where none of my objects were being cached and NHibernate was always going to the database for them. What was more odd was the NHibernate debug output suggested the items were being retrieved from the datbase and added to cache but on the next request the items couldn't be resolved in the cache.

Attatching a debugger and stepping through shows a timestamp passed into Cache's Put() method is equal to MinValue which makes it skip the Cache.Add at the last minute (whilst outputting debug messages to the contrary).

Tracking this timestamp back revealed it was created when the session is first openned and was due to my passing in my own connection string rather than letting NHibernate provide one. I assume this is a safeguard because IDs aren't necessarily unique between databases so in that case the cache would perform oddly.

If in your case they are however then you can work around this by casting your ISessionFactory as an ISessionFactoryImplementor. This has an extra overload of OpenSession which takes a IConnection and a ConnectionReleaseMode but doesn't disable the second-level cache.

ISNULL vs COALESCE

Consider this SQL Server statement:

SELECT ISNULL(2, 2.0), COALESCE(2, 2.0)

You might assume, as I did, that they're equivalent and will produce the same result, however this is not the case.

They differ in the way they determine what data type to return. ISNULL always returns the data type of the first argument and the second argument must implicitly cast to that type. COALESCE on the other hand returns the data type of the argument with highest data type precedence.

As a result what you get out of the example above is:

2

2.0

The reason being that the constant "2" is treated as an integer while "2.0" is treated as a decimal. Therefore ISNULL will return an integer because the first argument is an integer but COALESCE returns a decimal because decimal has higher precedence.

One possible issue I can envisage here is if you were to inadvertently COALESCE a float column in with your decimals and then try to do some arithmetic. You'd end up doing dodgy float arithmetic where you thought you were doing safe decimal arithmetic.

Column layouts with XSL

Marking up a set of items so that they are laid out in a fixed number of columns from left to right can be tricky if the items vary in height. You need markup something like the example below to achieve this...

<div class="row">
 <div> class="item"></div>
 <div> class="item"></div>
 <div> class="item"></div>
</div>
<div class="row">
 <div> class="item"></div>
 <div> class="item"></div>
</div>

...with CSS like this...

.item { float: left; width: 250px; }

Outputting this from XSL is fairly straight forward and requires relatively little "code" by juggling some XSL and XPath. Here is some example XML:

<?xml version="1.0"?>
<items>
 <item title="Item 1"/>
 <item title="Item 2"/>
 <item title="Item 3"/>
 <item title="Item 4"/>
 <item title="Item 5"/>
</items>

The XSL to transform this into HTML of the format shown earlier looks like this:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:variable name="cols" select="3"/>
 <xsl:template match="/items">
  <xsl:apply-templates select="item[position() mod $cols = 1]" mode="row"/>
 </xsl:template>
 <xsl:template match="item" mode="row">
  <div class="row">
   <xsl:apply-templates select=".|./following-sibling::item[position() &lt; $cols]"/>
  </div>
 </xsl:template>
 <xsl:template match="item">
  <div class="item">
   <xsl:value-of select="@title"/>
  </div>
 </xsl:template>
</xsl:stylesheet>

First off, we've got a variable named "cols" for setting the number of columns to output. Next, inside the first template matching our root element, we have an apply-templates which selects all the item element with a position that when divided by the number of columns leaves a remainder of one. This should give us items 1, 4, 7, 10 etc and these are then passed to a template in mode "row".

This apply-templates will match the next template whose job is to output the div element with class row. Within this div there is another apply-templates, this time matching the current item element and a number of its following siblings. That being one less than then number of columns required so in this example we get the context item plus its two following siblings. The template that matches this apply is that last one, without the mode specified.

The last "item" matching template simply writes out the div with class item surrounding the content of the item itself.

Function overloading in JavaScript

Trying to write a function so that it will handle different numbers and types of argument always seems to take a lot more code that it should. Today I ended up with some nightmarish if...else... because I wanted to support:

• Object, Object
• Object, String
• Object, Object, String

I remembered a post by John Resig from a while back on this, however his method doesn't handle different types. A quick Google found this snippet which does the job but seems a bit clunky, converting constructors to strings and the like. Satisfied that it could probably be improved upon here is my go at it.

Implementation

Here an Impl class holds the different method implementations against their signatures, defined as an array of constructors. The add method maps a new signature to an implementation, the exec method identifies the correct implementation for the current arguments and executes it and the compile method returns a function that can be used to overwrite the "daddy" function.

function Impl(){
 var _impl = {};
 return {
  add: function(aSignature, fImpl){
   _impl[aSignature] = fImpl;
  },
  exec: function(args, scope){
   var aArgs = Array.prototype.slice.call(args);
   var aCtors = [];
   for(var i in aArgs) aCtors.push(aArgs[i].constructor);
   return (_impl[aCtors] || function(){}).apply(scope, aArgs);
  },
  compile: function(){
   var impl = this;
   return function(){
    return impl.exec(arguments, this);
   };
  }
 };
}

Usage

Here's an example setup of a function stringify that will take two strings, two numbers or an array and do different things depending on what arguments are passed.

function stringify(){
 var someVar = 'Items: ';
 var impl = new Impl();
 
 impl.add([String, String], function(sLeft, sRight){
  return sLeft + ': ' + sRight;
 });
 impl.add([Number, Number], function(iLeft, iRight){
  return 'Sum: ' + (iLeft + iRight).toString();
 });
 impl.add([Array], function(aIn){
  return someVar + aIn.join(', ');
 });
 
 stringify = impl.compile();
 return stringify.apply(this, arguments);
}

Each implementation is added with an array of constructors e.g. [Number, Number] representing the arguments signature to match and the implementation function. Notice that we don't need to do any type checking of the variables in the implementation function, as we have to have matched the signature to get that far, and we can give then relevant names.

Notice the last two lines are:

stringify = impl.compile();
return stringify.apply(this, arguments);

So on the first execution of the function it is overwritten with a "compiled" version and then that version is called on the next line. Subsequent calls to the function will go straight to the "compiled" version thus speeding things up. This could also be done without the compilation and overwriting bit by just calling exec directly thus:

return impl.exec(arguments, this);

Calling our function

stringify('foo', 'bar'); // => 'foo: bar'
stringify(26, 5); // => 'Sum: 31'
stringify( [ 1, 2, 3 ] ); // => 'Items: 1, 2, 3'

Our different numbers and types of argument are giving us the output we'd expect.

Excluding particular derived types in NHibernate queries

Today I came across an NHibernate problem where I needed to select every instance of a particular base type and all its derived types from a database, apart from one particular derived type. Here is a trivial example:

public class Mammal {}
public class Dog : Mammal {}
public class Cat : Mammal {}
public class DomesticCat : Cat {}

In this case the problem was equivalent to selecting every mammal that isn't a domestic cat.

We're using the table per class hierarchy inheritance model in NHibernate which uses values in a discriminator column to determine which type is held in a particular row of the table.

Selecting the whole hierarchy is done like this:

In HQL:

IQuery q = sess.CreateQuery("from Mammal");
IList mammals = q.List();

In Criteria:

ICriteria crit = sess.CreateCriteria(typeof(Mammal));
List mammals = crit.List();

I then needed to be able to effectively add a WHERE discriminator <> 'DomesticCat' to the end of the query. I had a quick search for this special discriminator property and for a Criteria Expression for excluding a particular type but couldn't find either.

The Solution

I finally found the solution on the WHERE clause page of the HQL chapter in the NHibernate reference. There is a special property called class which you can test against a type name in HQL or an actual type in Criteria queries e.g.

In HQL:

IQuery q = sess.CreateQuery("from Mammal m where m.class != 'DomesticCat'");
IList mammals = q.List();

In Criteria:

ICriteria crit = sess.CreateCriteria(typeof(Mammal));
crit.Add( Expression.Not( Expression.Eq("class", typeof(DomesticCat)) ) );
List mammals = crit.List();

Generic collections and inheritance

I stumbled upon a small annoyance today when trying to use a generic collection of type B where a generic collection of type A is expected where B inherits from A. With arrays this works fine and the elements are implicitly cast to the base type.

Here's a snippet compiler script which illustrates the problem - list-converter.txt.

In the script I'm using BaseType and InheritingType for A and B. The script initially shows the implicit cast taking place for an array of B objects on line 19. The ArrayTest method expects an array of A but is quite happy being called with an array of B.

public static void ArrayTest(BaseType[] bar) { ... }

InheritingType[] myArray = new InheritingType[]{ it1, it2 };
ArrayTest(myArray);

If we now look at the ListTest method and try running this section of code...

public static void ListTest(List<BaseType> bar) { ... }

List<InheritingType> myList = new List<InheritingType>();
myList.Add(it1);
myList.Add(it2);
  
ListTest(myList);

...we get an error...

Argument '1': cannot convert from 
'System.Collections.Generic.List<InheritingType>' to 
'System.Collections.Generic.List<BaseType>'

We get the same result if we try an explicit cast

ListTest((List<BaseType>)myList);

Obviously allowing an implicit conversion for generics in general doesn't make a lot of sense but for lists I think it does and it's a pain to have to convert from one generic collection type to another.

Solution

Thankfully, with the help of some generics (of all things) and the ConvertAll method of List there's quite an elegant solution to this problem, we can create ourselves a nice generic list converter, here's an example:

public class ListConverter<TFrom, TTo> where TFrom : TTo
{
 public static IEnumerable<TTo> Convert(IEnumerable<TFrom> from)
 {
  return Convert(new List<TFrom>(from));
 }
 
 public static List<TTo> Convert(List<TFrom> from)
 {
  return from.ConvertAll<TTo>(new Converter<TFrom, TTo>(Convert));
 }

 public static TTo Convert(TFrom from)
 {
  return (TTo)from;
 }
}

We use two type arguments, the type we're converting from, which will be B from the example above, and the type we're converting to, A. Notice also the where TFrom : TTo which enforces that B must inherit from A.

As we need the ConvertAll method of List we have a method that takes an IEnumerable and creates a new List. We also have the method that does the main ConvertAll on the List and the delegate which is passed to ConvertAll.

This allows us to create a type converter as we code without needing to mess about e.g.

ListTest(ListConverter<InheritingType, BaseType>.Convert(myList));