5 Minutes of Android from a .net dev

Introduction

I have been part of a casual group of senior developers working on building a standard development platform for our teams, and have been using it for a few simple trial projects quite successfully.  The original design was to support desktop, web, and Windows Phone development, with the primary focus being the core tiers (data/business) with the presentation layers currently fairly underdeveloped. 

I have produced effective WP7 applications using this framework however, so I figured I would build an Android app to get some insight into how much effort would be involved in supporting multiple native applications.

Backend

I started with a simple design, a ratings system where users can rate, and view the average rating, for a list of items.  As Android doesn’t support SOAP very well, I decided to expose my services via webHttp (REST) endpoints, which works quite well with the ratings model that I am building.

I had a few issues setting up Json support through WCF, for a couple of reasons. 

Firstly I was using DataContract(IsReference=true) to support the data contract serialisation of my entities, which is not supported by DataContractJsonSerializer.  This was required to prevent circular references in my entity design for previous projects.  The solution was to turn this off, and ignore the circular references from my entities using IgnoreDataMember attributes.

As always, as this was within the WCF layer, the errors were woefully inadequate, and it took a while to actually identify this as the issue :/

Secondly, I downloaded and installed cUrl to test my POST/PUT calls, and getting the exact right quotes/escaping strategy for the Json parameter was a pain.  In the end I needed the entire parameter enclosed in single quotes, and each double quote for the key/value pairs needed to be escaped with a standard escape character (\) .

Android

So I now had a RESTful service that android would be able to access quite easily, so on to the android development part.

• Getting the tools
  • This was fairly easy, Google has a very simple guide on how to get the SDK, as well as links to appropriate IDEs
  • The development can be done in a variety IDE’s, including eclipse, but for a change I decided to go with Telerik IntelliJ Idea, which has “built in” android support.
  • It was a bit of a process to download all the components for development.  Once the SDK was installed there were then a number of sub-components to download.
  • And then I needed the right Java Versions, with android only working on Java 1.6 meaning I needed to sign up for an Oracle account to download a legacy jdk.
• Hello World
  • IntelliJ IDEA was good here, creating a new android project was straight-(ish) forward.
  • Much like java projects in general, the code, assets, and resources were scattered all over a number of folders, but at least the build files were all set up and everything built up front.
  • While IDEA has no graphical designer, it does have a preview.  I will need to work out how I can support test data in the designer to make sure things look right.
• Testing
  • Setting up an emulator was very simple, and deploying was automatic when debugging.
  • Debugging was very slow, I would definitely switch to a real device for tracing/debugging in anger.
• Next Steps
  • Web Access
    • Getting a single http request to my REST service was easy
    • note, do not use localhost (yeah i should have known this from my WP7 apps too)
  • Data Binding
    • Not quite there yet, but it is not as simple as I expected – there is no JSON binding support off the bat, and binding list data actually involves creation of arrays of hashmaps.  This was a big surprise.
  • Page Navigation
    • Haven’t looked at this yet
  • UI Design
    • Haven’t looked at this yet

 

Conclusion

I had a lot of reservations on how hard it would be to make a simple android app, but offloading all the logic to the service layer, using RESTful services and designing your application flow for the mobile form factor, it looks like it can be done with fairly minimal effort.

Obviously providing ‘local’ device processing and resources (inputs etc) will complicated this dramatically, but for LOB systems it is definitely feasible.  Providing a native WP7 and Android front-ends is definitely within reach of our application framework.