My book is finally available for pre-order! From the overview:

• Learn about all the latest features of C#, including the asynchronous programming capabilities that promise to make apps ultra-responsive
• Examine how C# evolved over the years to be more expressive, easier to write, and how those early design decisions enabled future innovations
• Explore the language’s bright future building applications for other platforms using the Mono Framework

In the later chapters of the book, you learn to build 3 different applications, the first is a Flickr viewer for Windows RT

The second is an HTML5 Mobile app using ASP.NET MVC that uses the geolocation APIs and SignalR to build a “SoLoMo” experience.

And finally, using MonoMac to build a Mac App using C# 5 (though, irony of ironies, Xamarin announces Xamarin.Mac yesterday).

It was a pleasure working with everyone from Packt on this title. Special thanks to Asher DeVuyst for reviewing the book and giving me great feedback

After much hard work, I’m happy to announce the release of a project I’ve been working on, Viewer for Khan Academy on the Windows Store (windows 8). The source code can be found on GitHub.

I really respect and appreciate what they’re doing over at the Khan Academy. With two small children of my own, anything that I can do to bring awareness to their great content and help enrich tomorrow’s generation (and even today’s) is time well spent in my book.

Huge shoutout to the folks over at Channel 9, who have produced a great set of tutorials and videos on the development of v1 of the app. The tutorials are written from the perspective of porting the Windows Phone 7 version of the app to Windows 8. Many thanks and props to Rick, Brian, Clint, and Dan. And of course, all of this wouldn’t be possible without the effort put forth by the Khan Academy Team.

Thanks!

C# 5.0 API Wrapper for the Universal Subtitles service, which is what the Khan Academy uses as their provider. I’m building this to add subtitles to the Khan Academy for Windows RT app.

Usage is simple:

using UniversalSubtitles;
...
var api = new UniversalSubtitles.v1.Api();

string video_url = "http://www.youtube.com/watch?v=W0VWO4asgmk&feature=youtube_gdata_player";

SubtitleLine[] subtitles = await api.SubtitlesAsync(video_url);
// returns the subtitles in the video's spoken language

You can also give the user a list of available languages that are available for this video

Language[] languages = await api.LanguagesAsync(video_url);
// display the list of available languages

SubtitleLine[] subtitles = await api.SubtitlesAsync(video_url, "it"); 
// or you can pass an instance of Language

Hope it’s useful for someone out there

But, as they say, time stands still for no man; so I’ve already got a few events coming up that you should totally come to and participate in!

• I will be a judge for an upcoming contest being run by the Orlando Windows Phone user group. The contest is to build a windows phone or windows 8 app using the Dark Sky API, for which I wrote an API wrapper:
  http://blog.tattoocoder.com/2012/07/orlando-windows-phone-metro-user-group.html
• August 23rd, I will be speaking at the Orlando .NET User Group on writing Twilio apps:
  http://www.onetug.org/Events/12-07-13/August_23rd_-_Joel_Martinez_presents_Twilio_is_the_Dealio.aspx

There’s a few other things in the works … it’s an amazing time to be a developer

• VoiceRequest
• SmsRequest
• StatusCallbackRequest

This makes it so that the MVC framework will automatically map the incoming parameters into a strongly typed object:

public ActionResult sms(SmsRequest request)
{
    var response = new TwilioResponse();
    response.Sms(string.Format("You said '{0}'", request.Body));

    return TwiML(response);
}

These changes were merged in with the pull request, which was originally meant to only include the MonoTouch and Mono For Android projects. But I had made these additional changes in preparation for the talk I’ll be giving at ONETUG on using Twilio. So those changes snuck right in to the main lib

https://github.com/joelmartinez/nBayes – specifically, in the Optimization namespace.

I won’t reiterate the pros/cons, and explanation of this algorithm, as Steve does a fantastic job over on his blog … so I’ll just present the sample program I wrote to go along with it. This program uses the API to create three options (the same used in the blog post), and then proceeds to simulate users who prefer to act on one option, then partway (35%) through the exercise changing preference. And you can see how the algorithm correctly begins to primarily show the new choice about halfway through.

/// <summary>This sample program has 3 options, and will use the the optimizer
/// to run a test scenario. Two options are picked, and we will simulate user interest in one,
/// then user sentiment changing to favor the second option.</summary>
private static void TestOptimizer()
{
  var optimizer = new Optimizer();

  // define the available options
  Option[] options = new Option[] {
    Option.Named("Orange"),
    Option.Named("Green"),
    Option.Named("White")
  };
  optimizer.Add(options[0]);
  optimizer.Add(options[1]);
  optimizer.Add(options[2]);

  // pick two options, and define when user interest will change
  var firstWinner = options[2]; // white
  var secondWinner = options[1]; // green
  var switchRatio = .35f; // 35% of the way through the test set
  int tries = 100; // the test set

  for (int i = 0; i < tries; i++) {
    Option selected = optimizer.Choose().Result; // don't care about asyncrony in this particular example
    Console.WriteLine("Choosing: {0}", selected);

    // decide which chosen option 'the users' will prefer
    bool isFirstBatch = (float)tries * switchRatio > i;
    if (isFirstBatch && selected == firstWinner)
      firstWinner.IncrementSuccesses();
    else if (!isFirstBatch && selected == secondWinner)
      secondWinner.IncrementSuccesses();
  }

  Console.WriteLine("\nResults! We expect that ({0}) will have the highest success rate, and ({1}) will be in second place", secondWinner, firstWinner);
  Console.WriteLine("\nThis is the final result after {0} tries\n{1}", tries, optimizer);
}

There are multiple strategies to solve the ‘multi-armed bandit‘ problem. This particular implementation is using ‘Epsilon-Greedy’. It’s still early, and I have other ideas on how to structure the code in order to facilitate multiple strategies … but for now, let me know if you’ve got any thoughts or feedback on this bit of code. Thanks!

You can find the project here on GitHub: https://github.com/joelmartinez/darksky-csharp

Currently supported platforms are: Windows Phone, iOS, and Android via MonoTouch/Mono for Android.

Usage is very simple:

using DarkSky;

...

var darksky = new DarkSky.Api(YOUR_API_KEY);
var orlando  = new Position { Latitude=28.5381f, Longitude=-81.3794f };
Task<FullForecast> response = darksky.Forecast(orlando);

response.ContinueWith(forecast => DisplayText(forecast.Result.HourSummary));
// displays something like "Rain starting in 3 Min, Stopping 30 Min Later"

Please let me know if you have any feedback either by opening an issue, emailing me, commenting on my blog, or forking the project and submitting a pull request.

Task
  .StartNew(() => MakeSomeDecisionSlowly())
  .ContinueWith(result => ProcessResult(result));

You can simply say:

bool result = await MakeSomeDecisionSlowly();
ProcessResult(result);

While the two pieces of code are exactly equivalent, the second code is so much simpler to understand. Because you don’t really have to think about the fact that there is an asynchronous context switch going on, you are free to focus on your program’s logic, rather than worrying about manually orchestrating what tasks are doing what.

However, after using these features for several days while porting my KhanAcademy windows phone app to windows 8, I’ve come to approach them with a bit of caution. While they are great for low level IO-bound tasks, in my opinion they don’t scale well to higher level API design. A few things to watch out for:

If you use await somewhere in your code, then the containing method needs to be marked with the async keyword, and there are specific rules about return types. Namely, the method must either be void, or return Task<T>. For example, the example above would have to be in a method

public async void DoThatThing() { … }

Or, if you wanted to return the result of ‘MakeSomeDecisionSlowly’ back to the caller, it would have to look like this:

public async Task<bool> DoThatThing() { … }

Which is great, and all, but then it means that the calling method must be decorated with ‘async’ as well. If you are refactoring an existing codebase, this can have the effect of rippling up the inheritance chain with numerous (albeit small) changes … depending on the situation.

Ok, fine, maybe that’s not a huge deal; it’s kind of annoying but I can definitely deal with that kind of refactoring. The big problem I have with async/await is that outside of relatively trivial pieces of code, it can tend to wipe away many benefits of proper abstractions.

Let’s say you are implementing a remote API call, and you have several requirements:

• Process the results if
  • You have a network connection (common mobile requirement)
  • The server is reachable (what if you’re connected at starbucks, but haven’t accepted the wifi’s terms of use?)
  • The server returns a code 200 (bugs happen)
  • The server indicates that your credentials are ok (what if the user’s password expired, or was changed by the user on your website?)
  • The server’s json response indicates a successful request
• If any of the above conditions are false, notify the user of the problem (with specific text for the situation).

This is a very common scenario in any occasionally connected mobile application, and you can see that there are no less than five distinct decisions that need to be made during the course of an API call. If you use async/await blindly, you have two problems:

First, you are deferring these decisions to the caller … you’ll do a nice asynchronous call, and return a Task<string> with the json results; or if you’re sophisticated, a Task<T> with the results already parsed and converted to a strongly typed object. However, it’s up to the caller to handle exceptions, check for network connections, deal with individual response scenarios (logged out, invalid request, etc.). So you may end up with every call site looking like this:

if (HasConnection())
{
  try
  {
    MyObject result = await MakeRemoteAPICall();
    ProcessSuccessfulResult(result);
  }
  catch(Exception e)
  {
    ProcessError(e.Message);
  }
}
else
{
  ProcessError("No Connection");
}

Second, providing further abstractions is difficult because you are limited to a single return type. So if you want to handle all of the stated requirements for the caller, you will have to wrap up the result in a special return value that can provide some details to the user, such as ‘was it successful’, the error message if it wasn’t, and the parsed return value if it was. While the pros and cons of using error codes for return values have been debated for ages; I tend to prefer simpler return values for local APIs, since a complex return value adds an additional burden on the caller to know how to interpret the results. At best, every call site would look something like this:

Result<MyObject> value = await MakeRemoteAPICall();
if (value.WasSuccessful)
{
  ProcessSuccessfulResult(value.Result);
}
else
{
  ProcessError(value.ErrorMessage);
}

That’s a bit better than before, but still rather verbose for my taste.

I propose that the callback style of API design still has a place for situations like this. Consider the following sample:

MakeRemoteAPICall(
  result => ProcessSucessfulResult(result),
  error => ProcessError(error));

For the local consumer of this API, this is logically the same: if the call was successful do this, otherwise do that. But the caller doesn’t have to worry about all the nuances of deciding whether a call was successful or not. They can focus on how to process the results, rather than dealing with all of this ceremony. And after all, isn’t that what we’re all aiming to do, simplify our code?

I would love to hear thoughts about how this kind of code can be made even simpler. Would love to hear any opinions, for or against. Thanks!

edit: lively debate over on Reddit http://www.reddit.com/r/programming/comments/txhfq/the_problem_with_c_5s_asyncawait_pattern/

The mono versions are using the silverlight version of the API, which uses async style methods where you pass in callbacks. There are two dependencies: RestSharp, and json.net. Though it looks like RestSharp has shed their dependency on json.net, there are still some references in the twilio code. The json.net project maintain mono specific versions … they depend on a portable library for that cross platform support. Unfortunately that means that you can’t compile it if you’re on a mac and only using monodevelop. Thankfully I found this helpful fork that did this work for me.

At the risk of  ‘pushing’ my pull request onto them, I submitted a pull request; But I made sure to word it such that I’m ok if they want to push back and ask for any changes … or maybe they don’t want to maintain a Mono version at all, in which case I’m happy to keep it in my fork. So we’ll see what happens. Please let me know if you have any feedback on this change.

As an aside, I also noticed while I was looking around github that many projects that have mono versions tend to use *.MonoTouch and *.MonoDroid for their project/solution names. It’s a subtle thing, but  Xamarin is careful not to refer to their product as MonoDroid, but Mono For Android. I wonder if this has to do with the trademarks that are owned by Lucasarts, if so I’d hate to wake up to a nice C&D in the mailbox

So I copied the file into my xml folder, and wrote this simple parser that reads the file in, and parses it into a HashMap

package cyborg;
 
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashMap;
 
import org.xmlpull.v1.XmlPullParser;
import org.xmlpull.v1.XmlPullParserException;
 
import android.content.Context;
 
/**
 * This class parses an iOS plist with a dict element into a hashmap.
 */
public class XmlMapParser {
	private XmlPullParser parser;
 
	public XmlMapVisitor(Context context, int xmlid) {
		parser = context.getResources().getXml(xmlid);
	}
 
	public HashMap<String, ArrayList<String>> convert() {
		HashMap<String, ArrayList<String>> map = new HashMap<String, ArrayList<String>>();
 
		final String KEY = "key", STRING = "string";
		
		try {
			parser.next();
			int eventType = parser.getEventType();
			String lastTag = null;
			String lastKey = null;
			
			while (eventType != XmlPullParser.END_DOCUMENT) {
				
				if (eventType == XmlPullParser.START_TAG) {
					lastTag = parser.getName();
				} 
				else if (eventType == XmlPullParser.TEXT) {
					// some text
					if (KEY.equalsIgnoreCase(lastTag)) {
						// start tracking a new key
						lastKey = parser.getText();
					}
					else if (STRING.equalsIgnoreCase(lastTag)) {
						// a new string for the last encountered key
						if (!map.containsKey(lastKey)) {
							map.put(lastKey, new ArrayList<String>());
						}
						
						map.get(lastKey).add(parser.getText());
					}
				}
				
				eventType = parser.next();
			}
		} catch (XmlPullParserException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
 
		return map;
	}
}

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>key1</key>
	<array>
		<string>one</string>
		<string>two</string>
	</array>
	
	<key>key2</key>
	<array>
		<string>one</string>
		<string>two</string>
	</array>
</dict>
</plist>

The way I look at it, may as well reuse what we’ve got, and spend less time yak shaving (ie. translating between platforms) … git ‘er done!