Mobile Phones – My thoughts on the whole thing (NSFW possibly)


Klaxon for Android – Now a Paid Application on the Market

The new improved Klaxon is now available on the Market for a reasonable $1.99! There have been several bug fixes, as well as some new features:

  • The compass is used to detect flip events. This allows vibration to be used for the alarm as well (it previously used to mess with the accelerometer, making it unusable).
  • Alarms can now optionally vibrate.
  • Alarms are now nameable.
  • Snooze can now be disabled.
  • Alarm will now turn off if the Home button is pressed.
  • Click and hold an alarm on the main screen to delete it.

Expression Trees, dynamic, and Multithreading in C# 3.0/4.0

I just had a brain fart the the other day: the dynamic keyword in C# 4.0 is more than just a way to plug interact dynamic languages. It can be used as a mechanism to evaluate any expression tree at runtime. One such example is that any arbitrary data source can be generically fashioned into dynamic objects that developers can interact with at run time. Take for example the following XML document:


Given a proper dynamic binding implementation for XML, the following pseudo code could be used to interact with this document:

XmlDocument doc = new XmlDocument();
dynamic dynamicDoc = DynamicXmlDocument.From(doc);

foreach (dynamic person in dynamicDoc.Person)
Console.WriteLine("Name: {0}", person.Name);
// modify the person's age in the document

This approach can be used to access or modify any potential data source, such as a databases, web services, RPC, etc. What would normally be done with code generation tools (like xsd.exe, LINQ to SQL, wsdl.exe, etc) at design time can now be done at runtime. [0]

This train of thought continued until it derailed into another area I find interesting: multithreading (and parallel computing). Consider the following simple program (disregard the [Future] attribute for now, more on that later):

static int LongOperation(int result)
return result;
static void Main(string[] args)
int normalResult = LongOperation(LongOperation(1) + LongOperation(2)) + LongOperation(LongOperation(3) + LongOperation(4));

LongOperation is an operation that takes 1 second and returns the value it was passed. It is a pseudo function that simulates an operation that takes a significant amount of time to complete and return a result. Examine the expression that you see above: How long do you think it would take to complete? If you guessed 6 seconds, you guessed correctly.

Those operations are begging to be run asynchronously by way of threads. A friend of mine, Jared Parsons, released his implementation of “Futures” in his BclExtras library, which makes building concurrent operations fairly easy. A Future is an object that wraps a long running operation in a thread, and blocks only when the Value of that operation is necessary. That way, a developer can define several values they will need in the Future, and start computing the results concurrently. For example, to do the above asynchronously using Futures, it would be expressed as follows:

var op1 = Future.Create<int>(() => LongOperation(1));
var op2 = Future.Create<int>(() => LongOperation(2));
var op3 = Future.Create<int>(() => LongOperation(3));
var op4 = Future.Create<int>(() => LongOperation(4));
var outer1 = Future.Create<int>(() => LongOperation(op1.Value + op2.Value));
var outer2 = Future.Create<int>(() => LongOperation(op4.Value + op3.Value));
int futureResult = outer1.Value + outer2.Value;

This implementation, which uses multithreading, will take only 2 seconds to complete (1 second to complete op1-op4 simultaneously, 1 second to compute outer1 and outer2 simultaneously). But it is not very pretty; it is difficult to look at this code and understand what is going on.

And although this is easy enough to write, I had the thought that migrating code towards a concurrent model can be done really easily with “dynamic” types in C# by implementing a dynamic runtime to handle futures. Consider following pseudo code:

public class Foo
public int LongOperation(int value)
return value;

dynamic future = new FutureObject(new Foo());
int result = future.LongOperation(future.LongOperation(1) + future.LongOperation(2)) + future.LongOperation(LongOperation(3) + future.LongOperation(4));

This would work because the implementation of the dynamic runtime would create expression trees which handle method calls with the [Future] attribute specially: Instead of calling the method directly, it would create all Future<T> objects up front when the expression is initially evaluated or created. Since I do not have the Visual Studio 2010 CTP, I decided to forego implementing this for the moment (although the implementation of a Future<T> dynamic runtime would provide this nice syntactic support for DLR languages like IronPython and IronRuby).

However, C# 3.0 does have a very powerful Expression support that can be used to achieve similar results. To paraphrase from IanG’s blog post about Expressions:

Consider the following code:

Expression<Func<int, bool>> exprLambda = x => (x & 1) == 0;

This takes that Func delegate, and uses it as the type parameter for a generic type called Expression<T>. It then proceeds to initialize it in exactly the same way, so you'd think it was doing much the same thing. But it turns out that the compiler knows about this Expression<T> type, and behaves differently. Rather than compiling the lambda into IL that evaluates the expression, it generates IL that constructs a tree of objects representing the expression.

This was the point at which I went: "what the?.."

To be more explicit about this, here's roughly what that second line compiles into:

ParameterExpression xParam = Expression.Parameter(typeof(int), "x");
Expression<Func<int, bool>> exprLambda = Expression.Lambda<Func<int, bool>>(
Expression.BitAnd(xParam, Expression.Constant(1)),

Basically, given a normal C# expression, we can see the expression tree at runtime! If we walk the expression tree, and modify all the MethodCallExpressions that have the [Future] attribute, we can achieve similar results to the previous solution:

// Notice that I am not changing the contained expression below at all! It is the same as the normal code.
// The futures are created automatically.
int futureResult = FutureExpression.Process<int>(() =>
LongOperation(LongOperation(1) + LongOperation(2)) + LongOperation(LongOperation(3) + LongOperation(4))

Remember, the contents of the expression with LongOperation are not actually being executed; only an expression tree for that expression is being created. It is not analyzed until FutureExpression.Process is called with that expression.

This is pretty awesome! Syntactic support for automatic multithreading with little to no code changes:

  • Tag any long running methods with [Future]
  • Wrap your original expression in a FutureExpression.Process

But, there are still an issue with Expressions, in that they are somewhat limited. Expressions that are parseable at compile time must be single statements. For example, the following would not compile:

// does not compile: A lambda expression with a statement body cannot be converted to an expression tree
Expression<Func<int>> expr = () => { if (someValue == 2) return 0; return 3; };

However, it can be rewritten as the following to make it compile:

Expression<Func<int>> expr2 = () => someValue == 2 ? 0 : 3;


It is possible to alleviate some of this problem, albeit somewhat sloppily:

  • FutureExpression.Process<T> can return a Future<T> rather than T.
  • Future<T> can implement all the operators to return further Future<T> which executes an expression tree of that operator on T (this would fail if T does not support that operator) .
  • The result of an operator on two Futures is a Future, so the actual result is never analyzed until the Value is explicitly retrieved.

Anyhow, the code samples containing the FutureExpression analyzer is available for download. I may resume working on the dynamic runtime for Futures, as that seems rather interesting. But don’t hold your breath for another post. :)


[0] Obviously this would be at the cost of runtime performance. Another issue with dynamic objects is that there is no “strong” typing. This can be addressed by duck typing.

Web 2.0 Is Dead. Long Live Desktop 2.0!

WebKit, Mozilla, and Chrome are seeing some phenomenal gains in the arena of JavaScript and HTML rendering standards and performance. If you bust out your magnifying glass, you will find a one pixel tall bar on those charts: Internet Explorer, the browser with the largest user share, is trailing the pack. And that is causing thousands of tiny violins to play in unison with the cries of web developers claiming that Microsoft is holding back Web 2.0. And that may be true; that is, if Web 2.0 will have HTML, JavaScript, AJAX, CSS, et al championing this so-called revolution. (These technologies will be from here-in referred to as just HTML/JS for brevity)

One of the prominent characteristics of Web 2.0 applications is that many of them are mimicking traditional desktop applications while using the browser as the application platform. The primary benefit to this is that the application is then cross platform, and that your data is available anywhere. A platform agnostic application runtime, eh? That sounds familiar. Essentially, a primary goal of Web 2.0 is to bring web applications to the desktop.

But, HTML/JS was not intended to behave or be used in the manner that it is heading. Every 10 or so years, there have been fundamental changes in application development, and it is beginning to show its age. To paraphrase the past and my vision of the future of development:

1975 – Imperative Programming fundamentals: C, Pascal, Basic

1985 – Object Oriented: C++, Ada

1995 – Rapid Application Development: Java, Visual Basic, Delphi (HTML and JavaScript are born)

2005 – Metaprogramming/Reflection, XML integrated development (LINQ to XML, XAML, XUL): Ruby, .Net, Python

2005 and beyond – Language Agnostic, Platform Agnostic, Web based distribution, Ubiquitous data access

HTML/JS, initially a static markup driven platform, is trying to morph into a desktop application platform tied to the web: the current/next application development platform. I think its time to put that horse down. And apparently so does Microsoft (Silverlight) and Adobe (Air). Rather than try to bring the web to the desktop, they’re approaching it from another angle: bring the desktop to the web. I will dub this movement Desktop 2.0. [0]


My blatant ageism aside, what is wrong with HTML/JS?

1) Everything you write is automatically Open Source

Your offline enabled application will have the entirety of it’s HTML/JS source code available. Thousands of man hours of a company’s IP can be easily inspected and reproduced. And though this concept would probably make GNU Richard Stallman shit his diapers with glee, 99.9% of the time, open source models are not profitable. Money makes the world go around.

2) Performance Blows

JavaScript performance will always and forever suck compared to languages that support strict typing.

3) No Developer Freedom

If you took every bad thing about C and every bad thing about Visual Basic and added in a few more bad things, it would be almost as bad as Javascript.” Developers should be able to do application and web development in any language of their choice. Being restricted to an eternity of JavaScript development is sort of how I imagine the ninth circle of hell. [1]

4) HTML has no Sex Appeal

It’s just too hard to make HTML sexy. Don’t even get me started on animating said HTML. And yes I know about how awesome Canvas is supposed to be. So following that to its logical end, web pages will eventually just become a HTML hosting a single canvas:

<script type="text/javascript">
function drawStuffOntoCanvas()
<canvas id=”the_canvas”></canvas>

How is that any different from HTML hosting a single Silverlight or Flash object?

<div id="SilverlightHost">
<script type="text/javascript">
createSilverlight("/pathToSilverlight/Page.xaml", "SilverlightHost", "Silverlight Application");

Well, for starters, Canvas is not markup driven like XAML/MXML. Why is HTML 5 taking a step backwards in UI development? Canvas is a flimsy JavaScript Band-Aid on the bullet wound that is HTML. [2]


To summarize, I can’t imagine any desktop applications of real significance being created with the existing web technologies. Imagine the best attempt of creating a Web 2.0 version of Microsoft Office in HTML/JS. Actually, you don’t need to imagine. Just visit Google Docs. Does anyone actually use that to do real work? The applications themselves are extremely crippled in comparison to their desktop counterparts. The only value it really provides over Microsoft Office is ubiquitous data access. And sadly, I’d rather use Sharepoint, which is no spring chicken either. [3]

Furthermore, as the line between the Web and the Desktop is blurred, you will see developers from one camp bleeding into the other. They’ll be presented with two technologies that are trying to achieve the same thing. Learning HTML/JS allows developers to build great web sites, but clumsy desktop applications. Learning a “Desktop 2.0” technology will allow that developer to build better web sites as well as great desktop applications. What do you think they’ll choose?


[0] Crap, it looks like someone else beat me to it. With a similar article title and thesis to boot. WTF!

[1] Why is it called JavaScript anyways? About the only thing Java and JavaScript have in common anymore is how much they suck.

[2] Someday, someone, somewhere will invent a XML markup that can be converted at runtime into Canvas JavaScript which is then eval’d and consumed by web pages. Files that contain the Canvas markup will have the “.cnvs” file extension. Usage of CNVS will become widespread and ECMA will standardize this format. Soon everyone will write their web pages in entirely CNVS, and browsers will forego the necessity of the HTML host. HTML slowly withers away. </jest>

[3] Live Mesh would also allow you to access your documents from anywhere, seamlessly. I actually prefer that to Sharepoint. It’s pretty awesome, truth be told.

Push Notification to Mobile Devices via SMS – Part 2

To implement push, let’s start by sending the SMS that will be the notification that the mobile device will receive. To do that, we will use the free SMS service from ZeepMobile. Doing a search for “ZeepMobile C#” results in a match to AboutDev’s Weblog. He has already done all the heavy lifting of writing a managed wrapper around ZeepMobile’s SMS API. I rearranged the code slightly so it is easily reused.

Here’s the code sample from my ZeepMobile managed API:

ZeepMobileClient myClient = new ZeepMobileClient(API_KEY, SECRET_ACCESS_KEY);

private void mySendButton_Click(object sender, EventArgs e)
if (string.IsNullOrEmpty(myUser.Text) || string.IsNullOrEmpty(myMessage.Text))
MessageBox.Show("Please enter a user and message");
myClient.SendSMS(myUser.Text, myMessage.Text);

Ok! Now, let’s hook up the SMS notification to my blog. The iframe below is hooked up to a ASP .NET application that uses the ZeepMobile managed API to subscribe a user and allow them to send SMS to themselves. First enter a user name to register on this blog, then follow the steps that show up to allow this site to send you SMS through ZeepMobile:

You should be able to use this site to send SMS to yourself. Next step, intercept the SMS on your phone and handle it. More to come in a later post!

Click here for the code used in this tutorial. The code sample includes a standalone Windows Application that allows you to send SMS to your phone (once you get a free API key with ZeepMobile).

“Push” Notification to Mobile Devices via SMS

One of the questions I seem to get on a frequent basis is “How is push notification implemented?”. Push notification is extremely useful for mobile devices; whenever there is a power constraint, typical polling/pull approaches will tax the device’s battery. Some examples of Push vs. Pull:


  1. ActiveSync
  2. Gmail on Android


  1. IMAP/POP3 email (user configurable polling interval)
  2. Twitter Clients (which checks Twitter periodically)

The obvious problem with polling cycles and pull is that the phone needs to come out of sleep/power save periodically and poll the server for messages: and there may be none waiting! For example, if you set a 5 minute email check interval on your Windows Mobile phone’s IMAP/POP3 account, your battery will be dead before the end of the day.

As far as I know, there are two ways to implement Push notification to a mobile device:

  1. Persistent TCP/IP Connection: Ideally the server would initiate the connection to the phone, but most phones do not have a static IP address available to them. Thus, generally, the phone initiates and maintains the connection. I know that actually maintaining a connection indefinitely will also drain the phone’s battery quite quickly due to a constant stream of keep-alive pulses. I’m a little hazy on the details here, but I have read that ActiveSync actually utilizes connections with a 15 to 30 minute time out to get around this problem.
  2. SMS: This is the ideal way to implement push, as the client only gets notified via SMS when there is something new on the server. Beware potential SMS costs that may be incurred.


Setting up SMS Interceptors

So, how does a developer use SMS to to implement a custom push solution? Well, first, the phone needs to set up an SMS interceptor: you don’t want to be sending protocol related SMS to the user’s Inbox!

Android: Register a receiver that watches for the android.provider.Telephony.SMS_RECEIVED broadcast.

Windows Mobile: Set up an Application Launcher for SMS events.


By way of SMS message prefixes, a developer can the specific SMS that are meant to be handled by the application. For example, a sample SMS in my custom protocol could be:

Koush: Poll!

By filtering SMS that begin with “Koush:” as they arrive, the user will never see them, and my application can utilize them to implement Push notification.


Sending an SMS to a Phone

There are several web services that allow you to send an SMS to a phone. Some free, some not. In the free category, I would recommend trying ZeepMobile. It’s easy to set up, and the API is straightforward.


Code sample and demo coming in a later post!

Samsung Mobile Innovator: A Step in the Right Direction

Windows Mobile developers that have used the Windows Mobile Unified Sensor API may know that painful reverse engineering process took place to add support for Samsung and HTC phones. This is because no phone manufacturer has released the internal API specifications for their device sensors!

However, Samsung recently released the SDK for their Light Sensor and Accelerometer on their new Samsung Mobile Innovator website. I don’t have a Samsung phone available at the moment, but the SDK looks pretty straightforward! And although it would have been ideal if Samsung had officially supported the Sensor API, this is a step in the right direction! A published API is better than no API. Hopefully HTC follows suit!

Here’s a snapshot of the managed bindings that were included with some of the SDK sample code:

namespace SamsungMobileSdk
    public class Accelerometer
        public struct Vector
            public float x;
            public float y;
            public float z;

        public struct Capabilities
            public uint callbackPeriod; // in milliseconds

        public delegate void EventHandler(Vector v);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetVector")]
        public static extern SmiResultCode GetVector(ref Vector accel);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetCapabilities")]
        public static extern SmiResultCode GetCapabilities(ref Capabilities cap);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerRegisterHandler")]
        public static extern SmiResultCode RegisterHandler(uint period, EventHandler handler);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerUnregisterHandler")]
        public static extern SmiResultCode UnregisterHandler();

I’ll be adding support for the official Samsung API to the Sensor API shortly.

Back from Hawaii!

The deafening silence for the past week on my blog was due to my being in Maui! It was a great trip overall.

High point: I swam with a 4 foot long sea turtle.

Low point: I let someone convince me that the Road To Hana was a good idea. I am pretty sure that Road To Hana is actually the largest man made fractal. Here’s my artistic rendition:


The scenery and such is unbelievably beautiful, but not even that can offset the nausea that sets in after the 300th hairpin turns on the highway. Here’s an actual satellite image of a typical 1 mile stretch of road along Hana (tile this image 40 times for actual representation):