A PDF Intent

Here's a naughty bit of behavior from the Android's Intents.
When you want to customize the mime-type of the requested intent, the setter for reason resets the previously set Data parameter. Cute right?
And to overcome this great issue, the API has another method setDataAndType(). See what they did there?
Anyways - here's a correct method (opening a PDF in this example):

NullPointerException Confusion

It's good to know that our field is called Computer Science. We're scientists. We like facts, laws and rules... Yeah, right. You think that if you've learned the basics of Data Structures, Algorithms and other courses in your B.Sc. it would prepare you for the real world. Nope. It's craaaaazy out there.

Today I had a real head-scratching moment when a completely innocent 'hashtable.put(key,val)' started giving me NullPointerException. Now, since I do know how hashes work, all I checked was - is the table itself null ? Nope, it's good. So what the hell?

Here comes the scary part:

put

public V put(K key,
             V value)

Maps the specified key to the specified value in this hashtable. Neither the key nor the value can be null.The value can be retrieved by calling the get method with a key that is equal to the original key.

Specified by:

put in interface Map<K,V>

Specified by:

put in class Dictionary<K,V>

Parameters:

key - the hashtable key.

value - the value.

Returns:

the previous value of the specified key in this hashtable, or null if it did not have one.

Throws:

NullPointerException - if the key or value is null.

Apparently the usual approach is not good for the Java folk. They don't want no stinking nulls in their precious hashes!
The reasoning behind the idiocity is this - the default behavior of get() method in hashtable is to return null if key was not found. So when the designers of the API chose that wrong path, they had to follow it up with a wronger path, since they couldn't distinguish between a null from 'no key found' and 'null found  as a value'.

I hate people.

GridViews, Buttons, Oh My.

In Android, there is a versatile class called GridView which can display any custom designed cells. You provide it with a layout for each item, fill in the values - and voila - it's working.
All is well, until you try to add something interactive to the Grid cell - like a button - you come across an interesting effect.
If you add a onClick listener to both the GridView and the Button inside the GridView - only one will get the click event. And you won't guess which one :) (hint: it's the button)
So basically, you can have interactivity - but not paired with OnItemClick events of the Grid.
Bummer, right?
Wrong. This can be rather easily fixed, and the problem lays in the way Android handles focus resolution between parent and child Views. For ListView you can play with Focusability parameter which controls who reacts first, and on GridView, just the the Button's Focusable parameter to false - and it just works. It still gets the touch events which cause the click, but it doesn't interfere with the focus mechanics of the Grid.
You're welcome!