I recently released a new course on MonoTouch at Pluralsight.

I wanted to take a bit of time here to talk about MonoTouch and to tell you why you should be using it instead of developing iOS applications in Objective-C

Flipping directions

When I first started developing with iOS, I firmly believed that the job should be done using the tools that Apple provided.

I still think it is a very good idea to learn Objective-C and how to develop an iOS application using Objective-C and XCode.

But I am convinced now that overall MonoTouch is the way to go.

Objective-C is a decent language, but it has a fairly steep learning curve for a C# or Java developer.  XCode, the IDE for developing iOS applications, is a decent IDE, but it is not nearly as powerful as MonoDevelop or Visual Studio.

The reality of the situation is that Apple’s development platform is still back in 1990.  Even though there have been some changes and growth, I firmly believe now that Objective-C and the underlying technology cannot ever catch up to .NET or Java.

I don’t say this lightly.  As I said, before I developed a fairly large application in Objective-C.  I authored a Pluralsight course on iOS development with Objective-C.  I was pretty convinced this was the way to go until I gave MonoTouch a try.

An unfair test

I really gave MonoTouch an unfair test, but it passed anyway.  I set out to learn, configure, build a MonoTouch application, and deploy it to the Apple App Store in 1 weekend.

I figured if MonoTouch could pass this test then I would immediately save more than the $400 cost for the software since the next application I was going to build was going to probably take at least a week worth of time to build in Objective-C.

MonoTouch easily passed my test and really exceeded my expectations.

The main advantage

By and far the main advantage in using MonoTouch is the language.

C#’s ability to wire up events through event handlers and delegates makes working with iOS so much easier.

There are many situations in iOS where you have to create a special class to act as a delegate for providing behavior for various iOS controls and classes.  In C#, many of these delegate classes can be replaced by a C# delegate or lambda expression.

Another really painful situation in Objective-C is memory management.  If you aren’t used to tracking memory usage it takes a bit to get adjusted to it in Objective-C.  Sure, it really isn’t that hard, but once I started working with C# to build my iOS application, I realized how much faster I could fly through the code without having to even think about it.  (The newer version of Objective-C has somewhat built in memory management, but it is not a true garbage collection implementation.)

Along with C#, you get the full power of the .NET framework.  Almost all of the base class libraries from .NET are available in MonoTouch.  (You basically have the silverlight .NET profile.)

This really comes in handy in 3 main areas:

• Working with XML
• Working with databases
• Calling web services

If you try to do these things in Objective-C, it is possible, but it will hurt like hell.

Give it a shot

If you are interested in developing iOS applications and you haven’t tried MonoTouch, go give it a try.  Trust me, it is worth the effort.  One of the big factors that had me developing Android applications and shying away from iOS was the hurdle of trying to learn and work with Objective-C.

MonoTouch lets you reuse your C# skills without any extra overhead, since the application is compiled down to native ARM assembly code.

If you don’t know where to get started or want to learn a little bit more about MonoTouch, feel free to check out my course on Pluralsight.

Kudos to the Xamarin team for building such a great product!

(BTW, that photo is me flipping.  Actually it is a thing I used to call “throwing myself at the ground for dramatic effect.”)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Finally, I have succeeded in porting the application over to iPhone and it was definitely much harder than I had anticipated.

But I am glad to announce that as of today you can find PaceMaker for iPhone in the Apple App Store.

If you don’t know what PaceMaker is, you can read about it in my original post above or in the description in the app store, but to sum it up briefly, it helps you run at a desired pace by telling you to speed up or slow down when you are running too fast or too slow.

A unique perspective

Having originally written the application and then porting it over to iPhone gives me a kind of unique perspective on mobile development platforms.

Although it was a bit painful at times to basically recreate the same thing I already spent so much time and energy creating, I was able to very realistically contrast the two development platforms in many areas.

One of the major pain points I experienced was in documentation.  Google’s documentation on the Android platform is sometimes lacking, but is much more complete and descriptive than Apple’s iOS documentation.

I am still quite a bit torn on which platform I like more and which platform I think will win out in the end.  I do believe that if Apple improved their developer tools and moved to a new, more modern development language, that they would have a distinct advantage.

It seems to me though that whoever integrates the best across multiple devices and gets the highest quality applications built for their platform will be the winner.  iCloud could be a huge step in that direction for Apple.

Sharing the knowledge

I’ve just talked with my curriculum director at Pluralsight and I will be doing a beginning iPhone development for .NET developers course just like the Android Development for .NET Developers course I did earlier this year.

I’m pretty excited to do this because I am going to try and draw some major parallels between the two platforms and also from the .NET perspective.

I hope to create the course just like the Android one, where we will step by step create an application from scratch and then publish it to the Apple App Store.

Look for that in the next few months on Pluralsight.net.

Dailymile.com integration

Also included with this release for iPhone and Android is Dailymile.com integration.  I think this feature is pretty cool!  So I am really excited about it!

Dailymile.com is basically a social site for runners and cyclists.  It is basically a Facebook for runners.

I have added a feature to the Android and iPhone versions of PaceMaker to allow you to post your run details, including the GPX map of your run, up to the Dailymile.com server on your wall.

So when you go for a run you can capture all the information from your run and see it on Dailymile.com.

This was quite a pain to implement as I had to implement OAuth2 authentication in both platforms and integrate with a REST API.  But what a great learning experience!

Anyway, if you are a runner out there and you get PaceMaker, feel free to send me an email or drop me a comment.  I am always looking for feedback so I can improve the app.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Now that we are able to authenticate a service with OAuth, we need to be able to actually use that service to do something useful.

Many popular web service APIs like Facebook and Twitter provide a REST based implementation.

In this post I’ll show you how to easily connect to one of these web services from Android and parse any responses you get back.

Should I use a REST library?

This is a valid question we should address before getting into the details.

My answer to this question is basically “no.”

I first tried the approach of using a REST library to make it easier to communicate to a REST based web service, but quickly found the overhead of the library was more than the benefit it provided.

If you come from a background of calling XML and SOAP based web services, you might be surprised by this answer.  With SOAP based web services it was a huge benefit to use a library to generate a proxy for you to call the web service and let you not have to worry about parsing XML and SOAP headers.

With REST it is completely different.  The whole point of moving to REST based web services is to simplify the process of calling web services.

Most REST based web service interfaces are extremely simple to use.  The idea is that the URL itself contains as much of the data as possible and additional data is included in the POST body.

By adding the complexity of learning a REST library and implementing the proper interfaces required to make it work seamlessly, we can easily add more complexity and overhead than just creating a HTTP request ourselves and parsing the responses.

For this approach I am going to show you how to do just that.

Calling the REST service

In order to call a REST service in Android we are going to first have to discover and understand the REST API provided to us, then make the appropriate calls with the OAuth token we got from authenticating.  Finally, we will parse the result of the call and get back our response.

Discovering the API

Because REST is not really a standard, but rather an ideal, there is not a standard way REST APIs are implemented.

You’ll have to take a look at the documentation for the REST API you want to call to figure out exactly what a call should look like.

In general though a REST API will involve making some kind of HTTP GET, POST, PUT or DELETE request and passing data through the URL or in the request body.

Here is an example of the Dailymile.com API which I have been recently integrating my app to use.

You can see the full API documentation here.

For this API, I am going to show you how I am creating a workout entry using a post.

Making the REST call

In order to make a REST call in Android, we are going to use a HttpClient object and the appropriate http request class.

In this example we are going to use the JSONObject class to create some data in JSON format that we can pass to the REST call by embedding it in the post.

I looked at the API for posting a workout entry to Dailymile, and the format of the request should look like this:

https://api.dailymile.com/entries.json?oauth_token=<token>

The API also indicates that it expects the post body to contain some JSON and gives us a list of required and optional entries that need to be in that JSON object.

Let’s take a look at how I am making this call and then we’ll break it down some.

HttpClient httpClient = new DefaultHttpClient();
HttpPost httpPost = new HttpPost(
	"https://api.dailymile.com/entries.json?oauth_token=" 
    + token);

httpPost.setHeader("content-type", "application/json");
JSONObject data = new JSONObject();

data.put("message", dailyMilePost.getMessage());
JSONObject workoutData = new JSONObject();
data.put("workout", workoutData);
workoutData.put("activity_type", dailyMilePost.getActivityType());
workoutData.put("completed_at", dailyMilePost.getCompletedAt());
JSONObject distanceData = new JSONObject();
workoutData.put("distance", distanceData);
distanceData.put("value", dailyMilePost.getDistanceValue());
distanceData.put("units", dailyMilePost.getDistanceUnits());
workoutData.put("duration", dailyMilePost.getDurationInSeconds());
workoutData.put("title", dailyMilePost.getTitle());
workoutData.put("felt", dailyMilePost.getFelt());

StringEntity entity = new StringEntity(data.toString());
httpPost.setEntity(entity);

HttpResponse response = httpClient.execute(httpPost);

You can see that I am first creating an HttpClient object and an HttpPost object.  The HttpPost has its URL set to the URL for the API call and I am adding a query string parameter to provide the OAuth token we got when when authenticated in my previous post.

I set the content type to be JSON so that we can get back a JSON object from the API call and so it knows that we are passing JSON data.

Then I construct a JSON object in the format specified by the API.  The way to construct the JSON object is to basically create a set of keys and values that are specified by the API you are calling.  In this instance I have a “message” key which I put the message data into. 

The only tricky part is that JSON objects can be nested.  So if you look at the key “workout” in the example above, I am creating a brand new JSON object to use as the value for that key which has its own subkeys which could contain more JSON objects.

Doing it this way is much more simple than trying to construct the string yourself.  The string we end up constructing will look something like this:

{"message":"fun!","workout":{"distance":{"value":5,"units":"miles"},

"activity_type":"running"}}

Finally, I put the JSON data into a StringEntity class and set it as the entity on the HTTP Post.  Then we can call execute on the HttpClient to execute the HTTP POST.

Handling the response

HttpResponse response = httpClient.execute(httpPost);
String responseString = EntityUtils.toString(response.getEntity());
JSONObject responseJSON = new JSONObject(responseString);
int workoutId = responseJSON.getInt("id");

All we are doing in this case is getting the response from the execute call on the HttpClient object, then using EntityUtils.toString to convert the response’s entity to a string representation.  Finally, we construct a new JSONObject from that string.

We can then easily extract any data out of the JSON object by using the methods on that JSON object that let us get typed values out of it.  For this example, I know that I am getting back some JSON that has a key “id” which is the id of the workout I created with my POST.

It is really that simple

The example I am showing you here is one of the more complex examples of calling a REST based API, because we are having to POST and parse JSON data.

In many API calls, you can just use an HTTP GET or a POST without any data to accomplish what you need to in the API.

Some REST based APIs will allow or require data to be passed in a different format, but most of them use JSON notation, which I find the easiest to work with.

Hopefully with these series of posts you can now authenticate against an OAuth 2 based service and make calls to the API to get and manipulate data in Android.

If you have any questions, feel free to drop me a line or post in the comments below.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Let’s talk about OAuth

The first thing you NEED to know about OAuth is that OAuth and OAuth 2.0 are not the same protocol.

From the OAuth guide on hueniverse:

OAuth 2.0 is a completely new protocol and is not backwards compatible with previous versions. However, it retains the overall architecture and approach established by the previous versions, and the same introduction (from the Official Guide to OAuth 1.0) still very much applies.

But, before we get into that, let’s talk a little bit about what OAuth is for.

OAuth basically does two things for a web site providing some kind of service or API that another application might want to use.

1. It prevents the consuming application from needing to store or have the user’s login and password.
2. It allows for a scoping of access to the producer’s services.  (For example, a user might be able to login to a site and access all of the features, but an app using OAuth might only be granted permissions to do certain things.)

So now that we know why, let’s talk about how both OAuth and OAuth 2 work from a high level perspective.

From the app developer perspective, the flow goes something like this:

1. You register your application with the service you want to access and get some unique identifiers for your application.
2. When you want to access something on the service, you make a request to the service using your unique identifier and telling it where to send the user after they authenticate.  (Usually you would launch a browser window here.)
3. User will login to the service using the browser window you launched for that service and choose to grant your application certain privileges.
4. The service will redirect the user to the callback url you provided and include a code you can use to get an access token.
5. You call the service one more time passing in your unique identifier and the code you got back and the service grants you an access token which you can use to access services you have been granted permissions for.
6. The next time you need to make a call you can just use that access token instead of going through this whole process again.  (At least till it expires.)

It really isn’t that complicated; the basic idea is that you tell the service who you are and ask the user the authenticate themselves and grant permissions to your application.  Then you prove that you got the response from the server and that it is still you and the service gives you a special pass to access the service.

The real difference between OAuth and OAuth 2 is the protocol itself, not the process.  So this is both good and bad.

Good, because we don’t have to change our process flow and understand something different.

Bad, because we can’t use the same libraries to access an OAuth 2 implementation as we do for an OAuth implementation and vice versa.  There is no backwards compatibility.

For the purpose of this post I am going to show how to use the Leeloo library to connect to an OAuth 2 service.

Connecting to OAuth 2.0

Download the library

The first thing you will want to do is to get the latest version of the Leeloo library.  It has moved to the Apache Amber project, so this link might change, but for now I found the ready to download binaries here.

Configure build path

Once you have the library downloaded you’ll want to add the following jars to your build path:

• jettison-1.2.jar
• oauth2-client.jar
• oauth2-common-0.1.jar
• slf4j-api.1.6.1.jar

Make initial request for authorization

Make sure you already have a unique client id created with the service you are going to access.  Most services out there like Twitter have a page where you can request one for your application.

Once you have this, you will use this to create a url that you will redirect the user of your application to.

In the code snippet below, I am creating the url and then creating a new Intent in Android that will open a web browser at that url.

OAuthClientRequest request = null;
request = OAuthClientRequest
       .authorizationLocation(authenticationUrl)
	   .setClientId("<your client id>").setRedirectURI("<your redirect url>")
		.buildQueryMessage();

Intent intent = new Intent(Intent.ACTION_VIEW,
        Uri.parse(request.getLocationUri() + "&response_type=code"));
startActivity(intent);

A couple of things to note about this code snippet:

• You’ll need to replace client id with your client id and redirect URI with your redirect URI.
• The redirect URI for an Android application is going to be some protocol that doesn’t really exist, but you can tell your application to respond to.  (We’ll cover that in the next step, but you might have some URI like myapp://oauthresponse)
• I had to add a “&response_type=code” to the end of my URL because the authentication service required it.  You might have to look and see how the service you are trying to access expects requests to be formed.

Configure your application to respond to your unique URI

In the previous step we had set the redirect to a unique URI like “myapp://oauthresponse”, now you will need to configure the activity you want to handle the response from the service to intercept that protocol.

You can do this by adding an intent filter to that activity like so:

<intent-filter>
	<action android:name="android.intent.action.VIEW"/>
	<category android:name="android.intent.category.DEFAULT" />
	<category android:name="android.intent.category.BROWSABLE"/>
	<data android:scheme="myapp" android:host="oauthresponse"/>
</intent-filter>

With this intent filter we are telling our activity to respond to a URI request in the form of “myapp://oauthresponse”.

Configure your activity to respond to handle the intent you registered to receive

Next we’ll want to set up an override in our activity to handle the new intent that will be called on our activity.  We can then pull the code the service gave us out and use that to request a real token.

@Override
protected void onNewIntent(Intent intent)
{
	Uri uri = intent.getData();

   if (uri != null && uri.toString()
           .startsWith("myapp://oauthresponse"))
	{
        String code = uri.getQueryParameter("code");
        // ...
   }
}

This code will allow us to respond to the intent that will be fired by the web browser when the service redirects the user to “myapp://oauthresponse.”

Exchange the code for a token

Next we need to get a real token instead of a code.  When the user typed in their username and password and granted access to our application, the server called our callback URI with a code that we extracted in the last step.

Now we can pass that code back up to the server along with our client secret and client id and get an access token.

OAuthClientRequest request = null;

request = OAuthClientRequest.tokenLocation("<service request URL>")
	.setGrantType(GrantType.AUTHORIZATION_CODE)
   .setClientId("<your client id>")
	.setClientSecret("<your client secret>")
	.setRedirectURI("myapp://oauthresponse")
	.setCode(code)
	.buildBodyMessage();

OAuthClient oAuthClient = new OAuthClient(new URLConnectionClient());

OAuthJSONAccessTokenResponse response = oAuthClient.accessToken(request);
String token = response.getAccessToken();

In this bit of code we are sending back to the server all the information we have that identifies our application as well as the code that proves the user allowed us to access that service.

Then we get back an access token from the server.  I would recommend you save this access token so that you don’t have to do this reauthentication in the future.

Wrapping it up

So what we have been able to do here is to redirect a user to the right page to authenticate our application, and then wire up our activity to respond to the redirect the service gives us in order to ultimately get an access token we can use to prove we are authorized to access that service on behalf of the user.

Be cautious though, because not everyone is implementing OAuth 2.0 exactly the same way, since the spec is not finalized.  So you might run into issues where things aren’t working exactly as laid out in this post.  If that is the case, you may have to modify a URL that is generated or something along those lines.

In my next post, I’ll show you what you can actually do with your authorization token.  We’ll go through calling a REST based API web service from Android.

Feel free to post any questions in comments.  I used this code to connect to the Dailymile.com API in my PaceMaker application.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I just got my first course published on Pluralsight!

The course is called Android Development for .NET Developers and it covers most of the basic knowledge you would need to go from knowing nothing about Android development to being able to create a fairly simple application and publish that application to the Android Market.

If you haven’t checked out Pluralsight, it is a really good site for a wide variety of developer training videos.  They really managed to get some very good content on the site and there are videos on just about every .NET topic you can think of.

I have also really enjoyed working with the guys that run Pluralsight, they are all very friendly and very knowledgeable.  Thanks to David Starr and Fritz Onion for all their help getting my course ready and published.

You never really learn something till you teach it

This simple truth became more apparent to me than ever during the process of making this course.

I thought I had a pretty good understanding of the Android fundamentals, having published a fairly complex application, PaceMaker.

What I became quickly aware of is that there is a huge difference between having knowledge and having understanding.

I equate knowledge as possessing a formula to be able to do something, but lacking knowing why or how to make modifications to the process.

Cooking provides an excellent example of this.  There are many people in the world who know how to cook a large number of dishes.  But many of these people only have the knowledge of cooking.  They have a large collection of recipes which they can follow to produce the desired result.

A professional chef on the other hand, has a true understanding of cooking.  This person might have knowledge of many recipes, but they also understand why the particular ingredients are used and can make modifications to those ingredients and steps.  They may even create something without preset steps because they understand what they are doing, not just have knowledge about it.

It was great to have the experience of creating these videos because I was able to acquire an in-depth understanding of Android development, not just a knowledge of what to do.

If you ever have the opportunity to teach, I definitely recommend you take that opportunity.  Even if you don’t think you are qualified to teach a subject, by the time you have prepared what you are going to teach, you will be qualified.  Trial by fire perhaps, but well worth the outcome.  Plus you’ll be helping others in the process.

Much harder than I thought

I do have to admit though, recording training videos is definitely much harder than I had originally anticipated.

In order to get 40 minutes of video, it might take 6 hours worth of work or even more depending on the prep work involved and how much editing after getting the raw footage.

I really expected that it would take about as much time as it takes to record something to produce that something, but I definitely learned that is not the case.

I often found that I had to draw a line and stop trying to refine a video because you can literally spend an unlimited amount of time editing and tweaking a video.

Another revelation that might be apparent to everyone else, but was quite an epiphany to me was that you can edit “umms” out of video very easily.  You can’t even notice where they are cut out!  My first video, I didn’t even realize I could edit anything, and I ended up taking like 50 cuts until I could get it right.

Overall though, great experience, lots of fun

I felt like I’ve been stretched in a different direction, as I had never done any video or audio recording before and had never really spent much time in a room talking to myself pretending to talk to other people, but it was a good kind of stretching.

I really actually enjoyed the process and I will definitely be doing more of this kind of work in the future.  Probably going to take a bit of a break before I start my next course though.  I want to make sure I take some time to get a good retrospective of the process and sharpen my saw a bit so my next videos can be even better.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

First month of sales are over, and it was much better than I had expected.  About 75 purchases in the first 30 days.  Not a huge amount, but that is almost with no advertising, most people who found the app found it in the market.

So what is the next step for PaceMaker?

Well, with the iPhone coming to Verizon this month, I think it is pretty obvious that it is time for the iPhone version.

Only problem is…

I know nothing about iPhone development!

Well I didn’t last week, but I am slowly learning.

I bought my first Mac ever last week, a MacBook Air.

I have to say, the operating system on Macs has come a long way since I last used one.  (Did I mention I also don’t even know how to properly run a Mac?  But I know Unix, so I should be ok.)

I feel like the Mac interface is so much more polished and uniform than Windows, but it is pretty scary inside when you consider all the low level C and Objective C code.

Then again you have to consider that the wonderful .NET CLR is written right on top of a really crusty win32 API layer which is a bunch of scary C code that is about 20 years old.

So I am setting out on a brave new quest to learn Mac, iPhone and Objective-C and somehow port my application over to the platform.

Objective-C is kind of like an alternate universe

I was trying to think how I would describe Objective-C and here is what I came up with:

Objective-C is like one of those movies where there is an alternate universe where the same people exist as in this universe, but in some areas their technology is really advanced, but in others it’s really ancient.  Like a bunch of people flying around in flying cars, but their weapons are still bows and arrows.

I used to be a C++ programmer, so not too many things scare me, but some of the magical constructs in Objective-C are very frightening indeed.

I was just reading about a strange construct today that allow you to basically create the equivalent of a C# interface, but in Objective-C it is called a “Protocol.”  This seems fine and normal until I read the paragraph that says you can define some of the methods as “Optional.”  What?

Let me put it in C# terms so you can understand it.  In C# it would look like this:

public interface ILovePuppies
{
   private void HugThem();
   private void SqueezeThem();

   perhaps Corpse KillThem(); // Implement this one
                              //only if you feel like it.

}

This is not a joke.  I still can’t quite figure out what this is for, but it is kind of interesting.

Another thing I found interesting is Objective-C has this thing called a “Selector.”  It is not a function pointer, it is a variable that references the name of a method.

How is this different than a function pointer?

It is actually the name of the method being referenced.  So if you have a class Dog that has a method “Wag” and you have a class WildGuesser who has a method “Wag”, passing them the “Wag” selector will cause very different results.  How bizarre.

It’s weird to get sucked into the Mac world

It’s actually kind of funny.  Here were all us Java and C# programmers off basically doing the same thing; creating our interfaces and arguing about dependency injection and mocking our unit tests and these Mac geeks with their bow ties and designer jeans were going a totally different direction.

It was only by random chance that our two parallel universes should violently collide.  The iPhone came out and suddenly all these strange “Mac boys” were teaching us this new old language and reminding us to free up own memory again.

FOR GOD’S SAKE I JUST IMPORTED A C HEADER FILE FOR THE FIRST TIME IN 10 YEARS!  THIS IS CRAZY!

But, I have to admit it is actually kind of fun.

Sometimes a change of pace is refreshing

I don’t mean my harsh language to be derogatory towards you Mac heads out there.  You know you are cool, your boy Steve is leading this century’s computing revolution.

I honestly mean that.  Good job guys, you may just take over the world.

I’m actually enjoying this experience and beginning to think that if I come out alive, I will have gained some very valuable insights into programming in C# and Java.  It is good sometimes to view something from a totally completely different perspective.

Who knows maybe I’ll get to write that Objective-C vs Java vs C# post I’ve been dreaming of.

But what about…

MonoTouch?

Meh.  If I am going to program for a platform, I am going to program for that platform.  I’m not going to half learn how to program for the iPhone and learn on the C# crutch.  I didn’t do that for Android and I’m not going to do it for iPhone either.

Why?

Because I am stubborn and cranky?  Partially, but I actually have a few sensible reasons also:

1. MonoDroid and MonoTouch both implement another layer over the phone’s framework.  Adding this additional layer makes it harder to do low level stuff, and with something as low level as a phone, doing low level stuff is often important.
2. You are still using the underlying framework for either Android or iPhone.  It is not like using C# code behind the scenes allows you to write a Silverlight UI that you can use on any of the mobile platforms.  You still have to learn the entire phone development framework, which dovetails into point three…
3. It is much easier to get help and find resources for raw Android or iPhone development than for MonoX development.  Not trying to bash the Mono projects here, but most of mobile programming is spent googling for how to do things.  By sticking with C# you are really limiting yourself in terms of finding answers.
4. Change and learning different things is good.  I’m not sure you can fully appreciate the design of a framework or platform unless you develop against it the way it was designed.  I could be wrong, but I think there is a potential “lost in translation” problem in using C# on the iPhone or Android platforms.

After I learn iPhone development, I might try MonoTouch and see if it makes my life easier, but I need a good baseline first.

Well, I’m off on my journey.  Going to head on to the back of the wardrobe in the “Spare-Oom.”  I have to meet Mr. Tumnus, we are having tea with Mr. Wozniak and Mr. Jobs.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

The book goes through creating an Android application using Eclipse. It contains many source code examples that are very complete. The book really seems to be focused more on getting going vs going in-depth with the APIs.

The good:

• Great jump start diving right into Android development without wasting much time.
• Very complete examples that can get you going and can be modified for your own application.
• Balances basic examples with more complex architectural constructs well. There is a good mix of examples that build on basic concepts and show how to implement more of an MVP style of development.
• Covers a pretty wide breadth of the Android platform, which makes it easy to know what exactly is capable.

The bad:

• Although the beginning of the book was very interesting and informative, some of the chapters seemed to drag on.
• A whole huge chapter devoted to search.  Search is not something that most applications would need to make use of.
• A whole huge chapter on 3d application development.  Not something I felt should have been in the book.  Pretty boring and actually really scary.  I don’t think I’ll ever develop a 3d application for Android.

What I learned:

I had already started building my Android application before reading this book, so not very much of it was completely new to me, but I definitely learned some things from the book.

I was really surprised to see how easy 2D animation is with Android.  The book does a good job of explaining it and providing examples.  I feel like I could very easily implement 2D animation after reading this book.

I learned about  to create and use content providers.  This aspect of Android development is a bit tricky, but I felt like Pro Android 2 did a good job of explaining it and providing examples that I would be able to use.

I also learned to create a home screen widget.  The examples in the book were really good and provided a complete usable implementation that could be easily used as a base for creating your own.

Towards the end of the book, Titanium Mobile is mentioned.  Titanium Mobile is a WebKit-based native application development framework which allows developers to write applications that target multiple platforms.  It looks really cool, and I kind of wish that was the first chapter in the book, so that I could have explored that before getting so far into actual Android development.

Overall, I would definitely recommend the book.  I feel pretty confident that someone with no Android experience should be able to pick up that book and get going with their first application.  I definitely learned some things the hard way, before I read the book.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I got some requests to show some sample code, so I thought I would explain what I was doing here and see if anyone had better suggestions.

Roboguice

To make it easier to unit test and to decouple my system as much as possible, I am using a dependency injection framework called Roboguice.  It is basically the Google Guice framework that is ported to Android and adds some Android specific functionality.

One challenge you will most likely first encounter when working with Roboguice is that a presenter is going to need a reference to the Activity class that is going to represent its view.  Since the Activity class has to create the presenter, this presents a dependency injection challenge.

We can’t just ask for a presenter from our container and have it auto-resolve the dependency on the Activity.  (That is we can’t rely on constructor injection in this case.)

Setter injection to the rescue

One thing we can do, is use setter injection instead of constructor injection to inject the other references our presenter will need.

Guice provides us with an easy way to perform setter injection after we have created the object.  I use this technique to make sure that I can pass my activity into the presenter and still have the benefits of having the other dependencies injected into the presenter.

Here is some code showing my OnCreate method inside my activity.

@Override
public void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);

    setContentView(R.layout.pacemaker);

    this.presenter = new MainPresenter(this);
    Injector injector = Guice.createInjector(new PaceMakerModule());
    injector.injectMembers(presenter);
}

This code is creating an instance of my presenter which holds a reference to the Activity, or view, it is manipulating.  Then Guice injects dependencies using the module I created into any properties that are annotated with @Inject.

Here is what some of those presenter set methods look like:

@Inject
public void setSystemClock(ISystemClock systemClock)
{
     this.systemClock = systemClock;
}

@Inject
public void setRunSerializer(IRunSerializer serializer)
{
     this.runSerializer = serializer;
}

You can see that they are declared in the module like so:

public class PaceMakerModule extends AbstractAndroidModule
{
   @Override
   protected void configure()
   {
	bind(ISystemClock.class).to(SystemClockWrapper.class);
	bind(IRunSerializer.class).to(GPXRunSerializer.class);
    }

}

It’s not exactly pretty, but Android applications are really a loosely coupled sets of Activities which are the entry point into your code.  It makes it very difficult to create a MVP type of framework that we might be used to.

If you know of a better way than what I am doing please let me know, and if you have any questions or suggestion, I’m always glad to hear them or help if I can.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

• Unit test on the real device or emulator using the real android framework
• Unit test on our PC using the JVM

Each choice has some pros and cons, but for me it came down to the speed and flexibility allowed by running in a real JVM.  I actually tried to create an Android unit testing project using the scaffolding provided by Google but it turned out to be very restrictive, especially since I couldn’t use JMock.

There is also something to be said for being able to execute the unit tests extremely quickly.  If you have to wait for an emulator to come up, or try to run them on a real device, it is less likely the unit tests will be run.

How to do it

The basic idea of this approach is fairly simple.

We are going to try and abstract away any Android specific calls from our application and then unit test the plain Java logic in the application just like we would any other Java project.

Step 1:  Create a JUnit project

Create a new JUnit project just like you would for unit testing any Java application.

Make sure you chose Java Project rather than Android Test Project.

From here you can add your JUnit references to your build path.  I would also recommend adding Instinct for doing BDD style testing.  Instinct uses JMock internally to create mocks for you using a declarative approach.

The only other thing you will want to do with this project is to add the android.jar to the build path.  The android.jar can be found in your Android SDK directory under the platform directory that corresponds to the API version you are targeting with your application.

For example, on my machine, I am targeting Android 1.6, so my android.jar is at:  C:\Android\android-sdk-windows\platforms\android-4.

Now remember, you are including the android.jar in the project only so your classes can understand what types exist in the Android framework.  If you even try to call a constructor on a class in android.jar, you will get an exception.

Step 2: Pull all the code you can out of the Activity.

The next thing we need to do is clean up our Activity class to make sure that it has the smallest amount of logic in it as possible.

Since we can’t actually instantiate any types that exist in the Android framework, we are not going to be able to create an instance of our Activity in the test project.  So we are not going to be able to unit test our Activity.  This isn’t a problem if most of the logic we care about testing exists in other layers in our system.

You can design the lower layers however you want.  I am still not quite sure the best approach here, but what I did was put a presentation layer directly below the Activity.  I have a Presenter class directly below the Activity that tells my activity what to do.  The Activity passes on any interesting events or information to the Presenter.

You should leave the Activity with the responsibility of setting the text on its own view objects, but create methods for your lower layers to tell the Activity what text to set the objects to and so forth.  Activity is going to act as an adapter to a large portion of the Android framework for your application.

Because the entrance point into your application is going to be the Activity, you will need to wire up the rest of your layers from the Activity.  This is a little strange, but it works.  In my application, I create a new Presenter and pass this into it on the constructor.

When you are done, your Activity should look pretty thin.  It should delegate all its event handler logic down to the lower layers and act as a pass through for manipulating the view.

Step 3: Wrap remaining Android object calls.

You’re going to find that some of the remaining Android API will need to be called from lower down than the Activity.  This is not as big of a problem as it seems.

In my application I needed to make some calls to android.os.SystemClock.  I needed to make those calls lower down than the activity because it is part of the heart of the logic of my application.

I created a simple SystemClockWrapper class that wraps system clock and delegates any calls to the real SystemClock class.  Then I extracted an interface from that class called ISystemClock (hey, I like the C# convention for interfaces.)

Finally, in my application logic, I allowed the ISystemClock reference to be passed in or “injected” through the constructor of the class that used it.

public class SystemClockWrapper implements ISystemClock
{
     public long getElapsedRealTime()
     {
          return SystemClock.elapsedRealtime();
     }

}

public interface ISystemClock
{
     public abstract long getElapsedRealTime();

}

In my unit test I just pass in a mock version of the ISystemClock interface.

One hint here is to use the refactor tool in your IDE to extract an interface.  This can save you some time of trying to manually create interfaces for large pieces of functionality you are wrapping.

Putting it all together

Now you should be able to create your unit tests against most of your application logic and run them just like any other unit test project.

The only thing you won’t be able to do is unit test the logic in your Activity classes.  This shouldn’t be much of a problem if you have made them into views, because they should only contain view logic.

If you really want to be able to write some tests for the Activity though, you can create another actual Android Test Project and use Google’s framework to write unit tests from there.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

In the course of building this app, in a previous post I mentioned that I wanted to find the right, or perfect way, to build an Android application.

I haven’t found the best way to build an Android application into a nice clean design pattern, but have found a way that seems to work, and makes the application testable and easy to maintain.

I do believe though, that I have found the optimal way to do unit testing in Android right now.  Yes, a bold statement, but I have looked high and low for a better solution, and can’t find one.

The problems

So first a little bit of background on the problem with unit testing in Android.  Take what I say with a grain of salt here, because I am not an Android platform expert, and feel free to correct me if I misstate something.

Android.jar

If you download the Android SDK from google, you will find that the android.jar you get with the SDK is much like a C++ header file; it doesn’t actually contain any working code.  As a matter of fact, all the methods are stubbed out to throw an exception with the message “Stub!” when you call them.  How cute.

The real android.jar implementations live on the emulator, or your real Android device.  So, if you want to actually run any code that is going to call any methods or try to construct real Android framework classes, you must run that code inside the emulator or a real device.

Dalvik VM

When you’re working with Android, it sure feels like you are writing regular old standard Java SE code, but you are not. You probably won’t notice the difference, as almost everything that you need is there in the Dalvik VM implementation of Java.

Dalvik is not even a Java Virtual Machine at all.  That is right, it runs on cross-complied .class files which are converted to a .dex format.  Yes, is does not use java byte code.

Why do I mention all this?  Because you might want to use something like JMock to mock your dependencies when writing your unit tests.

Well, you can’t.  It just isn’t going to work, because the Dalvik VM doesn’t use java byte code, so the reflective coolness that mocking frameworks like JMock use doesn’t work the same.

Be aware that any external library you try to use in your Android project may not work because Android does not support the full Java SE implementation.  It actually is a subset of the Apache Harmony Java implementation.

There is no main()

Where does an Android application start running?  From the activity.  Which is basically the view.  (Some people will argue this is the controller or presenter.  And yes, I agree in respect to the Android framework it is, but in regard to your application framework it is the view.)

Android applications define a starting activity and launch from there.  Activities can even be launched from other applications.

This tends to disrupt most of our MVC, MVP, MVVP pattern architectures, as the view is going to be the entry point and will have to be responsible for initializing the rest of the application.  (That is not entirely true, as there is an android.app.Application class that gets called the first time your app is run, to launch the main activity, but for the most part you can’t do much here.)

Essentially though, you have to build your architecture based on each Activity being its own separate little application, with the entry point being in the activity.  This puts some serious constraints on unit testing.

Putting it all together

So if I can sum up the problems briefly, I would say:

• Android framework code has to run in the emulator or on a device.
• Dalvik VM doesn’t allow us to use our standard mocking frameworks.
• Entry points for our applications are in the views.

The first problem, combined with the second, lead us to an interesting choice.  Should we run our unit tests on an actual emulator or device using the Dalvik VM, or should we run them in a JVM?

It is probably not an obvious question, but let me explain why it is the most relevant.

In writing an application, we are going to have application logic that has nothing specifically to do with the Android platform, and we are going to have Android platform specific logic (drawing views, handling Android OS events, interacting with Android APIs etc.)

If we want to write true unit tests, we need to isolate our classes and test them individually.  We should be able to do this for our application logic, without relying on the Android framework.  If we don’t rely on the Android framework, we don’t need to run on a real or emulated device, thus we are not constrained to the Dalvik VM.

If we choose to run our unit test code on a real or emulated device:

• We will be able to use the Android framework APIs in our testing efforts.  For example, we can create new location objects instead of mocking them up.
• We will be completely true to the real execution of our code.  Since we will be using the real VM the code will run on.
• Since we are running our tests on a device or emulator, they will run much slower.
• We won’t be able to use JMock, EasyMock, or Mockito, we’ll either have to roll our own mocks or use a fledgling Android mocking framework.

If we chose to run our unit test code in a JVM on our PC:

• We will have the full power of the JVM available to our test code, so we can use mocking frameworks like JMock, and BDD frameworks like Instinct.
• We will run our unit tests much faster, since they will be using our PC instead of a device.
• We can use standard unit testing practices and not have to inherit from special Android classes, or use special Android test runners.
• We will have to wrap any calls to the actual Android framework if we need to use any Android classes or services deeper down in our application.
• We have a small risk of having different behavior between running the tests and the real application, because we will be running the code on different VMs.

In my next post, I’ll detail which option I chose and why and also give some detailed steps of how to get setup and running.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.