Setting up the Android Emulator for HTTP debugging using Fiddler2

Fiddler2 is a great way to debug advanced HTTP communication and it can be very helpful in capturing and recreating SOAP messages. Getting up and running with the Android Emulator is pretty easy:

Android and XML De-/Serialization

I don’t have a lot of experience with it yet, but at least for the simple stuff I’ve been doing with the Android port, XStream is a great XML De-/Serializer.

Here’s the Android port: http://jars.de/java/android-xml-serialization-with-xstream

To get started using XStream, go for this easy to follow tutorial: http://xstream.codehaus.org/tutorial.html

There’s no I in standard

Coming from C# I personally prefer the I+DescriptiveInterfaceName (e.g. IList) convention, but that “I” seems to be a bit of a sin within the java community.

Imagine my surprise when I came across android.os.IBinder.

Although I’m just a random hacker using a language like C#, one thing I would always adhere to over my own preference in regards to naming, is a standard. I thought java guys were real sticklers for this kind of thing.

Guess I was wrong

Ready for the Enterprise: Setting up a VPN connection on Android

For my current project I needed access from my HTC Hero to a server that is not publicly visible. To my surprise it turns out that Android currently has NO VPN SUPPORT. Rumors say Donut will bring it and others are pointing to Google integrating a library from a company called Mocana. I did find some “workarounds” for enabling VPN. Common for all of them is the requirement of root access and a cooked ROM – not something that most users are going to be familiar with.

For me this puts a dent in the “enterprise readiness” of Android. And there are other things. Like the lack of support for Kerberos and NTLMv2 – in both the browser and the Java HTTP stack – and the previously mentioned unobtainable permissions.

I really hope that Google irons out these “kinks”. They make an otherwise promising OS hard to recommend.

Android documentation

I really like the Android documentation – it’s quite comprehensive, there’s nice API samples and the getting started tutorials are simple and easy to follow. With each class description, the documentation lists direct and indirect descendants – this is mostly a nice feature, but I couldn’t help smiling when I looked up “Object”: http://developer.android.com/reference/java/lang/Object.html

Android and permissions: Taking a screenshot

I had to do some screenshots for a presentation on the Android project I’m currently working on and to my surprise I found that searching for “Screenshot” on the Android Marketplace turned up zero results actually related to taking a screenshot.

I thought to myself that I would do a “shake to screenshot” app, but quickly realized that it was too good to be true, that nobody had thought of this. So I decided to investigate…

Android: Authenticating via NTLM

As a part of the Android project I just started, I need to access a service secured by NTLM. On Windows Mobile this is handled automatically by WebClient. For iPhone I had to make the move from the more modern and high level UrlConnection / UrlRequest API to the old school non object oriented C style CFNetwork API. Android turns out to be a bit of the same story as with the iPhone. I started out with HttpURLConnection, only to disappointed again and redirected to the Apache HttpClient. But unlike CFNetwork on iPhone, HttpClient actually does not support NTLM “out of the box”…

My previous attempt at a blog

As part of my new employment I have been photographed for the company website. I had to see if the less then flattering photo would turn up in a Google search but ended up stumbling on something much more interesting (to me at least): my first attempt at a blog.

I started the blog back in 2005 and only made three posts. One was my take of what would happen to devices in the future (look half way down). The conclusion was not so surprisingly: convergence. I go on to list specifications for what would be my dream device:

Processing: 400-600+ mhz processer

Memory: 128+ mb ram

Storage: 30+ gb harddrive

Screen: Vga resolution / device size / touch sensitive

Connectitity: Bluetooth longrange, wifi, 3g/gsm

Camera: 4-5+ megapixel with 3xoptical zoom

Size: Small

Weight: Light

Except for the 3 x optical zoom, that’s pretty the iPhone 3G i have in my pocket..

Update:
..or the Hero that just arrived on my desk

Securing REST for cross-domain Silverlight requests

A project I am currently working on involves a REST service and a Silverlight client. The service needs to support user authentication and must work in a cross domain environment. HTTP headers are not allowed when making cross domain request from Silverlight. Unfortunately this means using Basic Authentication is not an option.

The immediate suggestion was to employ a token system where a client would be presented with a GUID in return for a valid username and password. It would then be up to the client to append this token to every subsequent request as part of the querystring. A client implementation would look something like this:

Streaming MP3 audio from a WCF REST service

For a project i am working on in my spare time, i needed to stream MP3 audio from a REST service, implemented in WCF. I was supprised at how easy this was. It’s as simple as setting the response content type and returning a stream:

IAudioDemoService.cs method definition:

[OperationContract]
[WebInvoke(
Method = "GET",
UriTemplate = "/AudioStream")]
Stream GetAudioStream();

AudioDemoService.cs method implementation:

public Stream GetAudioStream()
{
	WebOperationContext.Current.OutgoingResponse.ContentType = "audio/mpeg";
	return new FileStream(@"c:\AudioFile.mp3", FileMode.Open);
}

(actually the content type isn’t strictly nessesary, but it enables a client to identify the information in the stream – a browser for instance might use it to select an appropriate application for processing)

Easy!