Moving Forward

I’m a big fan of UI surfaces that load content on demand. When a list-based control loads more items asynchronously as I near the bottom of a list I smile, it makes my life a little better. When it’s easy for me as a developer to implement, I smile even wider.

To get this behavior you’ll have to implement ISupportIncrementalLoading, an interface with a name so long only a mother could love it. It has to be implemented by the binding collection unfortunately. This poses a problem, it doesn’t fit into the MVVM architecture really cleanly. For example, here’s an except from a typical ViewModel, making use of the excellent MVVMLight framework:

    public class SubredditViewModel : ViewModelBase
    {
        private Subreddit _subreddit;
        private ObservableCollection<PostViewModel> _posts;

        private bool _isLoading = false;

        private RelayCommand _loadMoreCommand;

        public SubredditViewModel(Subreddit s)
        {
            _subreddit = s;
            _posts = new ObservableCollection<PostViewModel>();
            _loadMoreCommand = new RelayCommand(LoadMoreAction);
        }

        public ObservableCollection<PostViewModel> Posts
        {
            get
            {
                return _posts;
            }
        }

        public bool IsLoading
        {
            get
            {
                return _isLoading;
            }
            private set
            {
                _isLoading = value;
                RaisePropertyChanged("IsLoading");
            }
        }

        public RelayCommand LoadMore
        {
            get
            {
                return _loadMoreCommand;
            }
        }

        private async void LoadMoreAction()
        {
            this.IsLoading = true;

            int newPosts = await DataNs.Helpers.EnsureCompletion<int>(_subreddit.Posts.More);

            for (int i = _subreddit.Posts.Count - newPosts; i < _subreddit.Posts.Count; i++)
            {
                _posts.Add(new PostViewModel(_subreddit.Posts[i]));
            }

            this.IsLoading = false;
        }
    }

I have a ViewModel sitting in front of a model exposing simple lists of objects, and exposing an ObservableCollection for binding to the control. Retrieving more data items requires setting a IsLoading property, querying the underlying model, and finally updating the list. That sort of logic doesn’t belong in a one-off collection class, which is what implementing ISupportIncrementalLoading would force us to do, so instead I chose to make a wrapped that lets me specify the load-more action and function to determine if a collection has more values available as part of the constructor. This lets me pass in a refresh function that might even modify the ViewModel’s state and reuse the collection in multiple ViewModels.

    public class IncrementalObservableCollection<T>: ObservableCollection<T>, ISupportIncrementalLoading
    {
        private Func<bool> _hasMoreItems;
        private Func<uint, IAsyncOperation<LoadMoreItemsResult>> _loadMoreItems;

        public IncrementalObservableCollection(Func<bool> hasMoreItems, Func<uint, IAsyncOperation<LoadMoreItemsResult>> loadMoreItems)
        {
            _hasMoreItems = hasMoreItems;
            _loadMoreItems = loadMoreItems;
        }

        public bool HasMoreItems
        {
            get { return _hasMoreItems(); }
        }

        public Windows.Foundation.IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
        {
            return _loadMoreItems(count);
        }
    }

So now we’re getting somewhere. We have a collection that supports the necessary interface, and takes two functions as parameters that match the signatures of the methods we have to implement. The real tricky part comes next. LoadMoreItemsAsync is required to return an IAsyncOperation<LoadMoreItemsResult> object. We end up with an initialization that looks like this:

            _posts = new IncrementalObservableCollection<PostViewModel>(
                // This lambda simply returns a predicate indicating whether
                // more posts are available
                () => { return _subreddit.Posts.HasMore; },

                // This one is much more complex... it returns an AsyncOperation,
                // which is the WinRT-equivilant of a pure task in C#/.Net4.5 that
                // is attached to the completion of the asynchronous load operation,
                // returning the number of additional rows in TResult.
                (uint count) =>
                {
                    Func<Task<LoadMoreItemsResult>> taskFunc = async () =>
                    {
                        // IsLoading raises an INotifyPropertyChanged event and causes
                        // the progress indicator to appear.
                        this.IsLoading = true;

                        int newPosts = await _subreddit.Posts.More();

                        // Add all the new posts to the current collection.
                        int currentPostCount = _posts.Count;
                        for (int i = currentPostCount; i < _subreddit.Posts.Count; i++)
                        {
                            _posts.Add(new PostViewModel(_subreddit.Posts[i]));
                        }

                        this.IsLoading = false;

                        return new LoadMoreItemsResult()
                        {
                            Count = (uint)newPosts
                        };
                    };
                    Task<LoadMoreItemsResult> loadMorePostsTask = taskFunc();
                    return loadMorePostsTask.AsAsyncOperation<LoadMoreItemsResult>();
                }
            );

Check out the above code block. WinRT APIs tend to only accept IAsyncOperation implementing objects in place of Tasks. This at first can be kind of confusing. Luckily inside the System namespace there exists a static WindowsRuntimeSystemExtensions class that contains a bunch of extension methods for doing the kind of interop needed to hook this up. We capture the lambda function defining how to pull new records into a Task, and then return it to the framework as an AsyncOperation, so that the ListView can act upon its completion.

I took this code from my Windows 8 Reddit app. It’s something I’ve been working on in my spare time to give the new WinRT API surface a good run-down. You can check out the Reddit app from my GitHub page. It’s a really clean MVVM implementation that’s coming along nicely and I’ve discovered a good number of tips and tricks along the way to making it functional.

One of the major projects I’ve worked on while at the University of Michigan has been HiJack, a peripheral that plugs into the audio port of a mobile phone, harvests energy, and provides a channel of bidirectional digital communication between the phone and a microcontroller.

When I started working on the project, the original implementation was written in a embedded operating system called TinyOS. It’s research-oriented and extremely elegant. Unfortunately it has such a high concept count that ramping up to become productive in it takes a significant amount of time. We’ve wanted to see HiJack reach wide-spread adoption, which means making the code accessible to people who don’t have a few weeks to spare to setup the build environment we use to create applications for it. It has been available from Seeed Studio for quite some time, and I really want to see these things enabling cool new projects.

To that end I’ve taken some time and reimplemented the platform in raw C, while taking the time to clean up the abstractions and make things a little more accessible, easier to modify, and portable. The results of this effort are available on my GitHub here.

Included is an Android application as well that presents a simple RPC interface. This allows you to toggle and read some digital IO pins out of the box. Please notice that I haven’t fully implemented the ADC portion of the code, but it’s all pretty well templated. The Android application has a mirror of the abstractions you’ll find in the C code, which makes it ideal for testing out new interfaces.

Feel free to fork it, make it better, and tailor it to your purposes.

It’s a little preemptive but I think I’m going to set a New Year’s Resolution for myself. This past year I set out to read a ton of books. As a result I’ve grown a ton as a developer. The books I read were full of insightful patterns and design strategies and careful study of them has made my ability to succinctly express my ideas in a way that it meaningful and clear grow significantly. I’ve kind of hit a wall though. After a while of reading the books start to sound eerily similar. There’s a ton of really great ideas, but after you’ve taken a broad survey of the landscape, there’s not much else to do when you’re not trying to solve a specific problem.

After doing all this reading I think the next best way for me to grow as a developer is to just keep writing code. Write code for personal projects, for research, and for work, and make sure that it’s constructed in the best ways possible. To that end I’m going to try to set a goal for myself that should keep things on track. I’m a big fan of GitHub, and I’d like to try to do at least one public commit a day for the next year.

I think this is a great goal for anyone who finds themselves in a similar place. It’s sometimes a little tricky to find the time and motivation to really write code, so set a goal and stick with it. Start some interesting projects and start committing. One commit is fairly simple, it doesn’t have to be a large change set, just make sure every day you look at some code and make it better.

I love the challenges that embedded devices present. They come with an environment that lacks the abstractions we enjoy when programming for modern desktop and mobile platforms. A lot of the time it’s just you against the hardware. There are no seg faults because there is no memory protection unit. You get things done by writing bytes to magical memory locations called registers, which cause physical changes in the operation of the microcontroller to take place. Most platforms don’t have built-up libraries, and most developers work at the register-level, twiddling bits.

A crucial part of writing code for embedded systems is wrapping hardware peripherals in libraries that abstract their functionality well. This will really make or break a project. For larger projects it makes sense to invest time in exploring real-time operating systems to give one a nice layer of abstraction on top of the hardware. For smaller projects, or because of lack of platform support sometimes a real-time operating system isn’t available. In these cases you write code on the bare metal.

I’ve been working with writing a library for an ADC recently, and there’s some interesting lessons to be learned. For those that don’t know an ADC is an analog to digital converter, which is responsible for converting an analog voltage into a corresponding digital representation. ADCs are rather unwieldy, they have a complex set of settings that interact in complex fashions to produce the final behavior. It’s not obvious at first how to abstract such a thing. After trying a few times to get it right some lessons emerged on how to approach the creation of this kind of API:

Make Things Orthogonal

The hardest part of using the ADC in it’s native form is understanding the dependencies between settings and getting the ordering right. If the component isn’t brought online in a specific order it might not work, and it’s not obvious that Setting B requires Setting A to operate. Don’t make your API like this.

Confusing Awful Initialization Functions

// Places the Channel in high-impedance mode to
// avoid excessive current-drain
void adc_setupChannel(enum adc_channelEnum channelNumber);

// Sets the sampling rate of the ADC
void adc_setSampleRate(enum adc_sampleRateEnum sampleRate);

// Sets the clock divider to the ADC engine.
void adc_setClockDiv(enum adc_clockDivEnum clockDiv);

// Turn the ADC peripheral on or off. Use to converse power.
void adc_setPower(bool on);

// Enable ADC conversions
void adc_setConversions(bool enabled);

// Initialized the ADC registers
void adc_init(void);

It’s not clear looking at these functions what order things needs to be called in. Do you need to initialize the ADC before setting the sampling rate? Should conversions be enabled before? Does it even matter? Does the ADC have to be turned off if the channel needs to be adjusted? It’s completely non-obvious what order things need to be done in.

I think that this is the wrong approach in a lot of cases. The goal of your library is to wrap the functionality of this peripheral and get your nose out of the datasheet as much as possible as you focus on the higher-level problems. With this implementation you’ll always need to consult the documentation before writing code, and it’s easy to make mistakes.

A Much Better Version

// Parameters to initialize and startup the ADC
struct adc_init_struct {
    enum adc_clockDivEnum clockDiv;
    enum adc_sampleRateEnum sampleRate;
    enum adc_channelEnum channel;
};

// Initializes and starts the ADC.
void adc_init(struct adc_init_struct);

// Turn the ADC peripheral on or off. Use to converse power.
void adc_setPower(bool on);

In this case we’ve reduced the API surface significantly, and made the order of operations something that is handled by the library. We’ve moved further away from the hardware and this is starting to look like an interface that could actually be used without the documentation open.

Do a Few Things Well

In a similar vein I’ve found that it’s really tough to actually support the entire set of functionality exposed by ADCs. They do everything in every which way possible, and that’s tough.

It’s our nature as programmers to try and modularize everything, and create this large API surfaces that expose all the underlying functionality. It’s fun to try and build these kinds of things up, but sometimes a single, concise working example is much, much more valuable than the ultimate, modularized ADC library that is so complex no one can actually use it. Strike a good balance between functionality and doing a few things really well. At first I tried to write ADC libraries that did everything in every which way, but I found a much smaller library that did the one or two things I needed to be both a much better use of my time, and easier to work with.

So the takeaway from all this is that writing libraries for hardware is hard, but a few decent principles fall out of experimenting that are generally useful. Strive to reduce dependency between API calls, support a minimal, but useful subset in cases where the richer functionality isn’t needed, and always make the interface as narrow as possible. Every function you add is an increased burden you place on yourself and future developers. Every function increases the complexity of the interface, and must be considered when calling every other API as well.

These lessons aren’t significantly different from the lessons learned doing high-level object-oriented design, but it’s easy to lose sight of them in the context of a platform that’s extremely resource-constrained and while wrapping hardware that is incredibly feature-rich.

I’ve built a number of web-things during my career. They have spanned the domains of elegance and quality, some projects ended up being abominations to all that is good, and others turned out alright. That’s about the best I could hope for, all things considered. Throughout these projects I’ve thought about what the perfect web application looks like. This is the application I would build if I had a team of developers, a large project to work on, and the time to execute it properly.

There’s a lot of traits the perfect web application needs. It needs to be elegant in a way that makes maintenance easy. There’s a lot of kuldges running on the web today, held together with metaphorical string and tape and my application couldn’t be one of those. It would have a clean architecture that minimized code duplication and provided squeaky clean abstractions. It also needs to be responsive, and load fast. Servers are far away, and users aren’t super happy if ever click has to travel half way across the world and back before something happens. That’s just not acceptable anymore. Things have to be fast, and even when they can’t be it needs to display spinning wheels and progress bars. Users have short attention-spans. Finally I think it needs to be portable. I want this thing to run on anything with an IP address. I’ll settle for modern browsers and smartphones however.

I think we have the technology to build this application today. From an architectural point of view I think it would look something like this:

A Single Web Page Consisting of a Big DIV Tag

Javascript is cool, server-generated HTML is not. A lot of frameworks try to mix what gets generated on the server and what gets dynamically created on the client with varying results. It never ends up being that clean. Some would argue that the world is a messy place, and that it’s just the way things have to be. I don’t think that’s true. Server-generated views are old technology, and largely employed by tradition, not for technical reasons.

I see an extremely light HTML page being loaded initially. Just a page with a script tag in the header, and maybe a div in the body. Let this page load, and let it load Javascript and fire the onLoad events, and let these create all that needs to be created. That’s clean. Build an application with views. Google Closure’s templating system is great for this, it lets you build a ton of views that can be loaded into the DOM with your code.

Many would consider a completely Javascript-based application with no server-generated views to be idealistic. They claim it would take a long time to load all that Javascript initially and might be broken on older browsers. I’m not so sure these points are valid any more. Connections are fast and mobile browsers are apt at handling modern Javascript. Sure, we have to address some concerns surrounding cross-browser support, but modern libraries address that quite nicely.

A RESTful Interface to the Server

My beautiful single-page Javascript application needs an equally elegant server-side interface to talk to. It should be something that is clearly defined, and it should be entirely decoupled from the front-end. One of the best patterns to fall out of the HTTP spec is that of RESTful interfaces. These are clean interfaces, well-suited to my perfect application. Some of the best-regarded APIs ever designed are designed to REST specifications. My application would build the server-side of things using REST, it is clean and would present a well-defined set of methods for the client code to call.

This means we get this really cool Javascript front-end that loads, and then performs all data-manipulation across this API. The API is stateless, so we don’t have to be too worried about clients navigating away from the page, and it scales well. Clients request only the data they need, and if the site grows big I just install another back-end server and balance the load between the two API endpoints.

As a big bonus we get a great starting point for a public API. If I’m building something that could benefit from exposing a publicly accessible API I’m really killing two birds with a single stone here. That’s pretty cool.

Elegant View Degradation for Mobile Devices

This one is truly tricky. Making things work on mobile devices and look good is tough, and this is the biggest obstacle to the successful realization of my perfect application. I think it can be cracked however. With data loading across a nice RESTful API, and Javascript completely in control of the presentation of this data I actually think we’re uniquely suited to making this work well. We have the power to arbitrarily change the presentation layout of our data, and can even load views uniquely suited to mobile devices. While a Javascript-heavy application might at first sound poorly suited for mobile devices, I think this might end up being a general strength of the architecture.

Where is my perfect application?

So why hasn’t anyone built something quite like this yet? Well first, I’m certain people have. Some of Google’s applications are mighty close to this, and more applications are moving this way. Frameworks such as backbone.js provide some of this kind of functionality and have been used on some high profile sites. Second, I think that it’s pretty tough to build something like this. Large scale development like this is tough to get right. A lot of developers are struggling to get fundamental things working like decent DOM APIs and cross-browser support, so it’s hard to think about overarching ideas like this when the basics sometimes don’t even seem solid.

Lately I’ve been developing Windows 8 applications, and as a result I’ve been immersed in the new C# 5.0 language features. The new async and await keywords are awesome, taking almost all of the pain out of composing really nice asynchronous code.

It’s a little jarring to get used to these new features. With a lot of the CLR APIs being rewritten to only support Async methods it’s trial by fire. You’re just not going to avoid them and keep doing things ‘the old way’.

I’ve gotten up to speed with things and taken some notes. There’s a couple key bits I’ve discovered that helped me cross the bridge from understanding that these new features exist, to implementing patterns that use them effectively.

Why is async/await a big deal?

You’ve almost certainly heard the buzz around stuff like Node.js. Event-driven programming is cool and for good reasons. The nature of the callback rich approach gives the system a better idea of what exactly you’re trying to do, which results in tighter, more efficient scheduling.

C# has traditionally been not event-driven, but instead thread-oriented. In recent years there’s been a shift towards the task model, with code executing on the ThreadPool, and support for asynchronous network and disk operations. Technologically this shift gives us a lot of the benefits of event-driven programming, but from a ‘writing-the-code’ standpoint there’s a pile of boiler-plate code required to make it work. Writing good, asynchronous, callback-driven code while possible, has not been fun.

With async/await all of this changes. What they bring to the table is, in essence, a way to create and run tasks on the ThreadPool and wait for asynchronous IO to complete while preserving your current execution context while these tasks complete. That’s a really powerful idea. Previously you’d have to create BackgroundWorkers, and store state, and create callback functions, but with async operators all of that is done transparently by the compiler. It allows you to attach complex, long running operations to UI events with ease, without the pain of setting up callbacks and tasks.

How do I use it effectively?

I think the best way to become skilled in using these new keywords is just jumping right in. It takes a little bit of trial and error to get the usage patterns down. I’ve found a couple that are especially common as I’ve started building some apps in Windows 8.

Calling async functions from the UI thread

Many examples show the new async keywords used directly from UI event handlers to perform long-running operations, and then update the UI after completion. Here’s a typical example of this:

public async void ButtonClick(object sender, RoutedEventArgs e)
{
	int result = await CalculateSomething();
	TextBlock1.Text = String.Format("The result is {0}", result);
}

private async Task<int> CalculateSomething()
{
	await Task.Delay(5000);
	return 123;
}

When the system invokes the OnClick function it reaches the await statement. The task machinery at this point saves the stack (if anything needed saving), and creates a new task to execute on a worker thread. The UI function at this point returns, and the UI becomes responsive. At this point our calculating function crunches a result and returns it as a task result. In reality it actually sets up a system timer and does a similar operation due to the use of the awaited Task.Delay operation. After returning the UI function is resumed, on the UI thread (its execution context was saved), from the point of execution it was suspended on.

When structuring your own async methods it’s possible to have the calling function continue without waiting for the async method to complete. If the return type of the function is void the calling function will not wait for execution to finish when using the await keyword, instead execution of both functions will happen in parallel. It’s important to keep this in mind when designing functions that access and modify shared data structures. Either full synchronization code should be written, or alternatively you should make your async function of the type Task when you don’t need to return a result. This will ensure that the await keyword will delay continuing execution of the calling method until the pending task completes.

Another common problem with this example is that it’s often a poor idea to launch multiple concurrent executions of a background task at once. When a user repeatedly clicks the refresh button, it’s not a great idea to launch multiple web requests off, it’s more desired to ensure only a single request is pending at any time. To do this we can employ some simple synchronization code:

private int _pendingUpdate = 0;
private async void PerformRefresh()
{
	bool previousPendingUpdate = Interlocked.Exchange(ref _pendingUpdate, 1) == 1;
	if (!previousPendingUpdate)
	{
		await InternalPerformRefresh();
		Interlocked.Exhcnage(ref _pendingUpdate, 0);
	}
}

Here we use the Interlocked methods and a synchronization variable to ensure that only one instance of InternalPerformUpdate is running at any time. The first Exchange call will always set the variables to 1, while returning the previous value. If the value was not one previously we know we can safely perform an update. At the completion of the update we set the variable back to 0, readying the function for another invocation.

Updating the UI from a long-running background task

A really common way to do things is to run a background thread that periodically performs updates on the UI. This background thread might periodically pull updates from the web or wait on producer-consumer queues for new items to process and take the results and post them to the UI thread. In previous versions of .Net there was an Dispatcher.Invoke function available to allow work to be run on the UI thread. This method has essentially been renamed and changed to work with the new async architecture:

private void DoWork()
{
	while (true)
	{
		int result = PerformLongRunningComputation();
		Task updateTask = Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
		{
			TextBlock1.Text = result.ToString();
		}).AsTask();
		updateTask.Wait();
	}
}

Waiting for the UI update to complete is optional. This approach works well for direct ports of legacy code. Purpose-centric threads might not be the most efficient, but when porting it’s simpler to keep previous architecture intact, rather than migrating to the tasks and thread pool model.

Hopefully these scenarios are useful if you are just starting to use the async keywords. I’ve found them to really simplify programming C# code and they’ve been a pleasure to use while I work on Windows 8 apps. The implementation behind the scenes is really interesting as well. I fully recommend taking ILSpy and picking apart a few simple async functions to get a feel for how Microsoft’s compiler implements them. It will be of great help when debugging.

I’ve been breaking into Windows Phone app development lately. The platform is awesome, the technology is a joy to work with, and I’m convinced that Windows Phone will continue to gain market share and become one of the dominate platforms for mobile devices. Currently development is done in an environment based on Silverlight. Code is written in a .Net language, and as a developer you have access to the entire compact .Net framework. All the display is done using XAML, the WPF-derived layout technology, with a powerful declarative XML syntax for building UI elements.

As my first app for Windows Phone I built something really basic, but awesome. On iPhone there exists an app that displays custom strings of scrolling text on your phone. I’ve seen it recently at concerts and other venues, used by people in the crowd and even the performers to display messages. It’s super simple but actually a really fun idea. I set out to duplicate this app for Windows Phone.

It turns out to be pretty simple. I called the app Roll N’ Scroll, it’s available on the marketplace, and you can find the complete source on my GitHub. However, there were a couple nuances in the platform:

Display Elements are Limited by 2048 Pixels

A big part of Roll N’ Scroll is the scrolling text (super important). The naive approach here is to place the entire text string into a TextBlock, and just tweak the offset of that TextBlock at every frame. This was my original attempt, and it worked alright, but the text would suddenly be cutoff. It turns out that Microsoft has put a limit on the size of an element for performance rendering reasons. The phone screen is only 480×800 pixels, and it is very rare that a display element would exceed 2048 pixels, so when rendering individual elements for placement on the display once they exceed 2048 pixels they are no longer rendered. This makes a lot of sense in retrospect. Even if only a little bit of the element is displayed on the screen, it most likely is loaded as a texture of the entire size, with a small render view determining what is actually presented on the screen.

The solution is pretty simple, in place of the single TextBlock I placed a StackPanel and added individual TextBlocks. This way only the letters currently on the screen are rendered, while the ones off the screen influence layout but are not.

for (int i = 0; i < _rollText.Length; i++)
{
    TextBlock letterTextBlock = new TextBlock() {
        Text = _rollText[i].ToString(),
        FontFamily = new FontFamily("Arial"),
        FontSize = 600,
        Foreground = (SolidColorBrush)accentColorNameConverter.Convert(
                         _foregroundColor, typeof(SolidColorBrush), null, null)
    };
    txtScrollView.Children.Add(letterTextBlock);
}

To get the entire size of this ScrollView (and not just the size of it as constrained by the phone screen) we call the Measure method and pass in an infinite canvas size. This makes the desired size of the element available through the DesiredSize property:

txtScrollView.Measure(new Size(double.PositiveInfinity, double.PositiveInfinity));

I tweak the Margin property and everything works out pretty well.

Animating is Not Simple

The other challenge involved with making smooth scrolling text is the challenge of actually making the text move. We’re writing managed code, which isn’t known for its blistering speed of execution, on a framework that isn’t really designed for high-frequency animation loops. It wasn’t entirely obvious what the best method to do the incremental updates to the position of the StackPanel was.

In retrospect, the most elegant way to do this would be to attach an animation onto the StackPanel and allow the rendering system to take care of positioning. Our code in Windows Phone runs on a thread dedicated to processing UI tasks, which is separate from the thread responsible for rendering. Render work really should happen on the render thread, which blazes along at 60fps most of the time. The UI thread is often much slower. Unfortunately I built this app as part of a competition, and there was very little time to figure out the exact attributes needed for the TranslateTransform.

What I did end up doing is invoking an action on the UI thread continuously. I use the Dispatcher.BeginInvoke method to schedule this action, which executes almost immediately, and completes by scheduling itself for another activation. This method does not guarantee precise timing, it is not the most performant, and there are better ways, but it does produce sufficient behavior.

            // Since we call this action recursively we have to define it and
            // set it to null before attaching a lambda function to it.
            Action a = null;

            a = new Action(() =>
                 {
                     UpdateMarquee();
                     // Schedule the invokation of this Action as soon as
                     // possible.
                     Dispatcher.BeginInvoke(a);
                 });

            // Start the recursive call of our main movement function.
            Dispatcher.BeginInvoke(a);

Despite my general discomfort with the inelegance of this approach it is decent. By using the current UI element’s Dispatcher we ensure the updates will occur on the proper thread, and from a scheduling standpoint it doesn’t introduce a ton of overhead. Text scrolls smoothly on all the Windows Phone models I tested this on and I’m happy with it.

I’ll continue to dev for Windows Phone, I found making this app really refreshing. Do check out the source if you’d like to play with my code, or just go ahead and download the app, it’s in the marketplace.

Audio Assist is a fun, silly plugin for Visual Studio. I’ve had a number of people ask me to open source the code, and maybe explain a little bit of how it’s put together. Despite my reservations about giving away proprietary secrets, I’ve decided to do just that. You can now find it on my GitHub account. While extending Visual Studio isn’t the hardest thing on earth (mostly tedious), there’s a couple gotchas that are worth mentioning.

Getting Started

To begin developing Visual Studio extensions you’ll need the Visual Studio SDK. I based Audio Assist off a publicly available code sample that might be worth taking a look at as well. In the example they additionally add a menu item for the Add-In. My code is a greatly simplified version of that example, which will make it easier for someone just getting started to understand.

It’s COM All the Way Down

Visual Studio uses a complex COM model to allow for extensibility. Microsoft has been nice enough to provide managed assemblies to wrap these COM components for us, making it easy to extend Visual Studio from managed code. Audio Assist is built as an Add-In for Visual Studio, which turns out to be just a COM-visible managed assembly, bundled with a manifest file that gives Visual Studio the namespace and class name to load, and controls how and when the extension is loaded. The class specified in the Manifest implements the IDTExtensibility2 interface, which allows it to receive notification of Add-In specific events, such as loading and unloading, and bind to IDE events.

Part of the interface is the OnConnection method, which fires when the Add-In is loaded, and gives it a handle to the general Visual Studio root extensibility object:

        public void OnConnection(object application,
            ext_ConnectMode connectMode,
            object addInInst,
            ref Array custom)
        {
            _applicationObject = (DTE2)application;
            _addInInstance = (AddIn)addInInst;
        }

The _applicationObject variable contains the DTE2-typed application reference. The type of this reference changes with versions of Visual Studio, with the object supporting all previous iterations of the DTE interface for backwards compatibility, while implementing potentially new versions to provide for new features. From this object we can get references to the various commands:

        public void OnStartupComplete(ref Array custom)
        {
            // Upon VS successfully starting up we add all the
            // event subscriptions neccessary to make AudioAssist work.
            AddSubscription();
        }

        private CommandEvents _breakpointsEvents;

        public void AddSubscription()
        {
            try
            {

               _breakpointsEvents
                    = _applicationObject.Events.get_CommandEvents(
                        "{5EFC7975-14BC-11CF-9B2B-00AA00573819}",
                        769);
                _breakpointsEvents.BeforeExecute
                    += breakpointsEvents_BeforeExecute;
                // ... and so on
            }
            catch (Exception e)
            {
                System.Windows.Forms.MessageBox.Show(e.Message);
            }
        }

In Visual Studio almost all button presses correspond to a command behind the scenes. These commands are identified by GUID and command ID pairs. To capture these values there’s a trick to enable a popup dialog upon performing a command action. We use a command on the DTE object that gets an instance of the CommandEvents object for that command.

Things get a little odd here. It’s not immediately obvious why we create a private member variable to hold a reference to the CommandEvents object returned from the get_CommandEvents method. The fact of the matter is if we don’t do this we’ll experience some really weird behavior, with button command events never triggering. Because the object returned is a COM-wrapped object, and because no other managed object holds a reference to it, when garbage collection runs it will be disposed of. Objects that have no references, even if they are holding on to unmanaged resources, look abandoned to the garbage collector. To avoid collection we simply hold onto a reference to these objects for the lifetime of our Add-In and life is good.

We attach event handlers to the BeforeExecute events of the commands we’re interested in, implement, and finally play the sound. All of this is pretty mundane, so I’ll defer you to the GitHub repo for all the gory details.

As a final note on this code, I usually wouldn’t recommend catching all exceptions, it’s just bad practice in my opinion to catch an exception that you hadn’t thought about before hand. In this case however I think that it’s justifiable. The code inside the exception try block is pretty simple, only does one thing, and if it fails the Add-In will simply stop working, while displaying a mildly helpful error message to the end user. If this were a production product it would be worth investigating what exceptions could be thrown and handling them appropriately.

Wrapping Things Up

I’ve highlighted the really interesting parts here, everything else is in the GitHub repo. All in all it’s not to create something like Audio Assist, but the documentation is scarce and a little hard to go off of. A lot of the methods I used, especially for debugger hooking, were undocumented and labeled as Microsoft internal use only. That’s a little odd, and makes it difficult to use them effectively, but things generally seemed to make sense.

Today I’d like to share a little something I’ve been working on for Visual Studio. Audio Assist is a powerful new Visual Studio extension designed to enhance developer productivity while debugging. By using a novel audio-based cueing system it keeps the developer engaged in the process of debugging and helps to establish strong audio-associative memory patterns in their mind. Audio Assist is the cummulation of years of natural user interface and human learning research

You can read a little bit more about Audio Assist and download it yourself here.

Exceptions always seemed weird to me. Why would I want to catch an exception, when with proper coding they shouldn’t occur in the first place? I felt at first like exceptions were designed into the language for someone else to use, and even when I did want to make use of them I found them awkward and cumbersome.

After resisting exceptions for a while, I started to come around. It started to become clear that even if code is perfect (which it rarely is) there is still a pile of network and system related errors that can occur. While one way to handle these errors is to add return codes to all functions that happen to touch the outside world, a perhaps cleaner way is to throw an exception. All of the sudden exceptions became cool.

Knowing that exceptions have a time and place in a program, I started designing all kinds of complex exception handling machinery. My code was destine to handle all exceptions with grace and ease, and easily recover. An exception handler would in turn try another body of code that could throw an exception, which would enter a wait state before retrying and catching another exception and so on. It was quite a mess, and the more I developed these techniques, the more I became acutely aware that this wasn’t really the right way to do things either. Applications simply can’t be able to recover from every possible scenario.

A few years and a couple of paradigm shifts later I’m finally starting to see what the point of catching an exception is, why they are useful, and what to do when one occurs. The bottom line is the point of an exception is to limit damage when something unexpected happens in your code, get back to a known state if possible, or abort if not. Exceptions do not make your code bullet-proof, however they do a great job of mending wounds and keeping the system up, despite unexpected occurrences. Nowadays my exceptions follow a pretty rigid two-phase pattern, restoring state and restoring flow control, and this works reasonably well.

Restoring State

The most immediate goal of an exception is to return the application to a known state. This involves performing any necessary maintenance on modified data structures, managing any unmanaged resources that need to be released, and deleting any temporary files that had happened to be created during the execution of the routine.

I’ve been doing a lot of server work lately, and this usually consists of another try block to close any open database connections, and an iteration through a list of temporary files. As certain methods execute in my program that use intermediate files they keep a list of created temporary files, and my error handling routine iterates through this list and deletes any files still in existence.

In other cases I end up deleting items from a HasMap structure, where the value of the entry points to an incompletely initialized object. Either way, after this part of the exception routine is done, the application should be in a state identical to before it entered the try block.

Restoring Flow Control

After restoring the application’s state, the next problem is where to transfer flow control to. I’ve found that exceptions usually break down into two pretty clean categories.

Temporary exceptions occur when servers go down, or network requests fail. They are often transient, and upon retrying might succeed. For these kinds of exceptions I usually implement some sort of retry loop, with a fixed number of retries allotted based on the timing requirements of the function I’m in.

Permanent exceptions involve events that are not likely to ‘fix themselves’ if given time. File permissions issues, logic errors, and most other non-IO exceptions fall into this category. When I encounter this kind of exception the show is basically over. If the exception occurs in a reasonably compartmentalized task, as is often the case, the entire program doesn’t need to cease execution, we after all did restore it to a known state, but we do need to abort the current task and present a failure message to the user.

When a temporary exception times out after a certain number of retries it too becomes a permanent exception.

Exception Hierarchy

In this model it’s actually really reasonable to throw in a hierarchical approach to exceptions as well. It’s common in the Java world to catch an exception, only to throw another one. For example a class named MagicMoneyWorker might throw MagicMoneyWorkerException exceptions as a result of network timeouts when performing remote procedure calls. It has wrapped the more low-level exception with a high level one.

The reasons for doing this fit well with the object oriented approach to programming. The MagicMoneyWorker class probably knows best how to handle a network timeout. It knows how to preserve it’s inner state, and recover, and probably even has some retry and reconnect logic built in to it. By the time it’s done handling the exception, if an error occurs, it’s a permanent exception and it means that the task at hand failed. This needs to be handled now by the caller function.

Wrapping exceptions in this manor allows you to keep the primitive exceptions hidden, and preserves the level of abstraction you’re operating with. If you’re writing a function that deals with MagicMoneyWorkers on a high level, you don’t want to have to dive into the bowels of the implementation. It makes much more sense for an exception with a matched level of abstraction to be thrown, and for your function to act on this exception.

Simply my Personal Approach

I doubt this approach will work well for all systems or applications, but I’ve found it works reasonably well for my development lately. Throughout my computer science education there hasn’t been much focus on how to handle exceptions. I think they are considered more of an engineering problem, because the code we deal with is so algorithmic in nature, and brushed under the rug as something you’ll pick up over time. Developing a personal framework for how to handle an exception, and giving a rigid procedure, purpose, and ordering to the process has tremendously helped hone my skills in developing real world applications. If you don’t have a clear idea of how to deal with exceptions in your own projects, I would definitely recommend spending some time to mediate on them and figure out what the goals of catching an exception are for you.