GLaDOS for Android Released

Another quick post for you.

Decided to try releasing another list of quotes application for Android, this time the subject is the infamous GLaDOS from Portal and soon to be released Portal 2!

So I’ve got a few quotes from the original Portal, a couple from the trailers and even a few from the turrets. However if you haven’t played Portal, do so now!

I am also required to inform you that as part of test protocol, there may be cake included in this application. No further announcements of cake are required from the point onwards.

So click the GLaDOS for Android link above, and enjoy. I am charging £0.50 GBP for beer/development funds and supporting any users which might have a problem, also may go towards server costs.

Any suggestions? Missed a quote that you really want ? e-mail me through the marketplace or contact me via this site.


Android and List Views

Slight absence from the blog, as per usual I’m busy coding my fingers off for work and in spare time.

Anyway whilst I remember this, I had a particularly nasty bug with version 1.4 of DroidPartridge as I had changed the layout to incorporate a ListView instead of specifying the list of TextViews and ButtonViews, much more efficient.

Anyway the bug was, with the simulator I used the D-Pad (or trackball) to select items, however on a real device, when you touch an item on the list, the onItemClick event does not fire, but it does with D-Pad/trackball. Oddly enough if you have a context menu the event works perfectly. Confused ? I was.

Anyway, despite only having an ImageView and a TextView in my list items, I thought that these would not swallow the onItemClick event. I was wrong by the looks of it.

This took a little experimentation and a lot of time on Google, so I’m posting the answer for quick reference and for any poor souls trying to work it out.

In your list item view (The view that is used to display all the items in your list) in this example, row.xml ensure that all views have the property Clickable set to false.

I also set the layout container (the root element) of the row.xml Clickable to false for good measure.

Run your application and the items should be clickable by the touch input. Odd that seemingly non interactive Views swallow events instead of allowing them to bubble up.

Anyway, don’t say I never give you anything internet! DroidPartridge is now fixed also.

Disappearance and Coding

Well, erm.. hello there!

Been a bit of a recluse when it comes to the blog, haven’t had exactly a lot of time to sit down and write an entry with work eating all my time and any free time is spent in the company of real people.

Also my sincere apologies to all you Droid Partridge users, the same situation has befallen the development with regards to work, I’ll try and get that sorted as quick as I can, hopefully by the end of this month.

Anyway not much to report here, been working a lot with jQuery (try it, it’s the most awesome thing to happen since tables!) and ASP.NET MVC at work, perfecting a template and refactoring very old and nasty code which has become difficult to maintain. The amount of projects that are marked for re-write it growing by the week.

Anyway the main theme of this post is to complain and complain a lot at Samsung’s general direction. They deserve it.

Debugging with Eclipse

Now to debug with the Nexus One, it’s a dream. You plug in the device with USB debugging enabled, Windows isntalls the drivers after a few pokes in the right direction and you click debug on Eclipse, it deploys and runs. I couldn’t ask for a more seamless debugging experience there, beats Visual Studio 2008 for Windows Mobile as I have to select a device or emulator whereas the ADT plugin does this for me depending on what is plugged in to the system at the time.

I decided in a brief moment of rational thought to attempt to try debugging on other handsets than my own Nexus One, although the idea of Android and one operating system over many handsets gives you the feeling that you are writing portable code that will run anywhere. I decided not to try my luck and test … just in case.

So, I enable USB debugging on the Samsung, plug it in and sat with a smug smile waiting for Windows to install the device drivers and Eclipse to pick up that another Android device was available to debug on, expecting the same seamless experience. I had never been so wrong.

First the device drivers did not install. After prodding the ‘Add a new device wizard’ to install the ADB Composite Device driver, I found that the ADB daemon was not registering the handset. A restart of the daemon and Eclipse brought me no further forward. I hit Google and found a few solutions which involved changing the ADB executable and .dll files, but they were from a few years ago, so I didn’t bother attempting them. Another involved tinkering with the .ini file in the usb_driver folder in the android SDK. I tried this, however it did not work at all.

After a lot of searching on Google, I found the solution which was not on any Android or Samsung documentation that I could find for Éclair and the GT-I9000 respectively which is absolutely disgraceful, so I’ve decided to write the steps out for you.

  1. Ensure that the USB mode is set to ‘Mass Storage’ (Menu Key -> Settings -> About Phone -> USB Settings)
  2. Ensure USB Debugging is enabled. (Menu Key -> Settings -> Applications -> Development -> USB Debugging)
  3. Download the Samsung drivers and install them. I found them on Softpedia the x86 (32bit) version is here and the x64 (64bit) version is here. I’ve also mirrored them (32bit version here) and (64bit version here)
  4. Run the setup files and let it complete.
  5. Attach the phone and let Windows do it’s stuff with getting the drivers sorted out for you. If this does not happen as you attempted to force a driver to install as I did, you will need to un-install the Android device from the Device Manager first.
  6. Fire up Eclipse and let the debugging commence.

Why this wasn’t on offical documentation or at least a well known affliated wiki I will never know.

Credits to this forum post who gave me the answer.

Bluetooth Pairing

In a nutshell. I’m writing an Android application for work at present and using my trusty Nexus One to test and debug. (Glad I bought it as it is now the official developer phone. Hurrah!) Anyway, I decided to test this application on another Android device to ensure that I was writing code that at least worked on two separate handsets. So I picked up a Samsung Galaxy S (GT-I9000) and started hooking it up for debugging. Now I am transmitting data via bluetooth (as per my woes in the previous post) and so I started the pairing process for the bluetooth device, and it did not show up. Odd.

I checked on my own Nexus One and a colleague’s Nexus One and yes the device was visible and I was able to pair up the device with the phones, but not on the Samsung, very strange. So I forced the bluetooth device to initiate pairing with the Samsung and no problems there. The bluetooth device has no user interface, so it is a tad clumsy trying to pair it up like this. Then I modified the program to search for the device I needed by matching the advertised name and connecting, hoping that the phone would pick it up and initiate the pairing process. Tested this on the Nexus One, no problem worked first time, now we move over to the Samsung handset.

Now to cover what I had, basically it is a very simple BroadcastReceiver class which has the Intent filters for ACOUNT_FOUND and DESCOVERY_FINISHED which was fired with the Nexus One, but not on the Samsung. A lot of profanity ensued at this point (I had just gotten over the debugging stupidity above) and I trawled the LogCat section of Eclipse and I found this gem:

E DTUN_HCID Device [00:07:CF:59:04:38] class is 0x00 - skip it

I must say that I blinked once or twice and read this again trying to make sure I had gotten the meaning correct. Basically, Samsung have taken the liberty when modifying a version of Android (Éclair 2.1-update1) to ignore any bluetooth device which advertises itself as class 0x00 and wont allow connections, fire off Intents on discovery or even list it on the sodding bluetooth settings page. I was (and still am) outraged. Why on earth have they made this decision for me and can I override this behaviour or am I going to have to re-write/place the management module for bluetooth on Android? It is not a nice thing to be considering!

So far I’ve posted on xda-developers and the Android Developers Google group asking for assistance, I am not hopeful, which is a shame as it’s a damn impossible brick wall to smash through. I’ll post an update if I can get around this complete insanity on Samsung’s part. Any suggestions are more than welcome.

So there goes the line of thought that Android would be a good platform to develop for because everything is provided for you at no cost and manufacturers would never need to do more than skin and add their own applications in the ROMs that they ship with their handsets. I do hope I find the solution to this, Android is a very nice platform to develop on and comes on some very sexy handsets and it would be a great shame to have manufacturers like Samsung taking an awesome platform and ruining it so that when developers come along, they’ve got to write more code to cope with the idiotic decisions they make with the operating system.

Anyway, I’ll get back to coding, ranted enough for one evening, I’ll keep you all posted on Droid Partridge updates as soon as I have completed them.

The inane comments of a C# developer