It’s been awhile since I blogged about Continuous Client with my last experiment. I’ve had a lot of thoughts since then about application boundaries and how this impacts users.

Computing is very app centric especially today with the emergence of App Store’s on mobile devices and desktop computers. We’ve streamlined selling applications directly to the end user and removed as many barriers as possible to get at the users money.

When do we start creating and selling user experiences?

We as developers are creating more and more boundaries and isolated experiences that end users have to deal with. Our operating system and applications are not aware of the users workflow and old solutions like Copy/Paste still exist to aide the user to cross boundaries but this is not intuitive or a good experience.

Most often we find integration API’s like Android intents, Windows Phone and Windows 8 contracts or iOS URL schemes and document types. Microsoft OLE is another abstraction that was created for integration purposes. These solutions help integrate and hop boundaries instead of apps gaining understanding.

Users who are not tech savvy stumble with these boundaries. The boundaries we create between one app and another, and between apps and the operating system cause users confusion.

Every time my mom wants to send me something via email I get a phone call with a question like:

“I saved something I wrote and want to email it to you. How do I get it from Word to an email again?”

Users struggle with boundaries between applications because that’s where the user experience ends and understanding the system begins.

It is a broken user experience whenever a user has to hop fences of boundaries. Web search for “how to email a file” and you’ll find 713 million results. Here’s an example of one for Microsoft Outlook help that I don’t think would help my father.

How much money does it cost the industry to support broken user experiences created by these boundaries?

Workflow

Applications and operating systems need to become aware of a users workflow and take part in it rather than expecting the user to navigating around boundaries and understand the system underneath.

Let’s take a look at a users workflow of creating an image in Photoshop, using the image in a document and sending the document to someone via an email.

Can you spot the boundaries?

If we think of these actions as events, it represents a timeline of the workflow. The events I have paired in matching colours (purple and orange) have potential correlation. This gives the application an opportunity to gain awareness of the users workflow instead of directing the user to a boundary. The boundary between applications starts to fade away.

If applications participate in the timeline both as producers and consumers they have the ability to make seamless experiences that help the user in what they are trying to accomplish as a whole and not just within the application.

Since our workflow is a timeline why doesn’t any of our software have an understanding of a timeline? There seems to be a fundamental mismatch with how we do work and how software is written to allow us to do work.

If we flip this vertically we can see the timeline and see how it may look represented as an event stream.

Having our workflow represented as a stream in the form of a timeline allows applications to have greater awareness than they have using other boundary bridging solutions like integration API’s.

This is not a suggested solution, I mention this to get people thinking.

User interactions

The concept of a timeline gives applications awareness of our workflow. Applications become Continuous Clients and participate in a continuous user experience. User interactions could be captured by storing events and timestamps in the events (I didn’t include them for simplicity in the image above) gives these applications the awareness of temporal cohesion of interactions that could span multiple applications and potentially the operating system.

Actions with high temporal cohesion in a workflow are steps in a workflow grouped together during the same task and execute closely together in time.

Bringing Continuous Client and Transmedia together

I’ve been talking about and experimenting with Continuous Client now for a couple years and I’m still trying to evolve a lot of ideas. We are starting to see Continuous Client like features here and there but there is still a long way to go yet.

There’s another community that has been working on this problem much longer than the developer community. This community is the Transmedia story tellers.

Transmedia was named by Marsha Kinder in 1991. She went on to say:

Transmedia intertextuality works to position consumers as powerful players while disavowing commercial manipulation.

Transmedia is described from Wikipedia as (emphasis mine):

Transmedia storytelling (also known as multiplatform storytelling) is the technique of telling a single story or story experience across multiple platforms and formats using current digital technologies, not to be confused with traditional cross-platform media franchises, sequels or adaptations.

From a production standpoint, it involves creating content that engages an audience using various techniques to permeate their daily lives.In order to achieve this engagement, a transmedia production will develop stories across multiple forms of media in order to deliver unique pieces of content over multiple channels. Importantly, these pieces of content are not only linked together (overtly or subtly), but are in narrative synchronization with each other.

We are starting to see increased transmedia story telling in the movie, television and gaming industries but there is a big need to also have this in the operating systems and applications we use. The people working on transmedia today are breaking down boundaries and making continuous user experiences.

What Transmedia and Continuous Client have in common is the goal to remove the boundaries the user faces and deliver a continuous experience that transcends mediums and devices. In computer software this could be taken to an even smaller level and remove application and operating system boundaries.

The way we interact with our computer is a story. A user emailing pictures to a family member on the other side of the world is a story.

If you want someone to fall in love with your product, try to focus on the possible stories and blur the boundaries. Don’t let the boundaries get in their way. Your users will love you for it.

I’d like to thank Hoop Somuah and Geoffrey Long for exposing me to transmedia. Here’s some really interesting videos on the topic.

Cassandra is optimized for very fast and highly available writes. Cassandra writes first to a commit log on disk for durability then commits to an in-memory structure called a memtable. A write is successful once both commits are complete. Writes are batched in memory and written to disk in a table structure called an SSTable (sorted string table). Memtables and SSTables are created per column family. With this design Cassandra has minimal disk I/O and offers high speed write performance because the commit log is append-only and Cassandra doesn’t seek on writes. In the event of a fault when writing to the SSTable Cassandra can simply replay the commit log. For more information on how Cassandra operates with writes read this article.

If you need BIG data and fast writes, Cassandra is worth a look.

Data Model

The Cassandra data model has 4 main concepts which are cluster, keyspace, column family and super column. I’ll leave out super column in this post to keep things simple.

Clusters contain many nodes (machines) and can contain multiple keyspaces.

A keyspace is a namespace to group multiple column families, typically one per application.

A column contains a name, value and timestamp (left out in the diagram).

A column family contains multiple columns referenced by a row keys.

Installing

Cassandra is written in Java and can run on a vast array of operating systems and platform. A lot of this post is relevant no matter what platform you are on. Since we are going to be jumping into how to use Cassandra in C# we will install Cassandra on a Windows machine. Fortunately the great people at DataStax (amazing bunch over there!) have created a Windows installer for their version of Cassandra. The DataStax version of Cassandra comes bundled with a lot of handy things I’ll cover later. The Windows installer will install the Java runtime and makes getting Cassandra up and running a breeze.

After installing you’ll find the following in your start menu.

Using the CLI

Run the Cassandra CLI Utility. Using the CLI we can create keyspaces, column families, etc. Let’s connect to our local node and create a blog keyspace.

Now let’s create the posts column family which will store our posts.

Now let’s add a couple sample blog posts.

Through the CLI we can also view what is stored in the column family.

Using DataStax OpsCenter

The DataStax version of Cassandra comes with an application that DataStax developed called OpsCenter. OpsCenter gives us the ability to view all kinds of metrics from our Cassandra cluster node but also allows us to create keyspaces and column families.

Here’s what the main view of OpsCenter looks like.

On the data modeling view we can see our blog keyspace which also shows us our posts column family.

The keyspace and column family we built via the CLI we can build through the OpsCenter user interface. The standard version of Cassandra from Apache doesn’t come with OpsCenter and there’s a lot of functionality there. I suggest taking a look at it and poke around.

Using the CQL Shell we can use a SQL-like query language called CQL (Cassandra Query Language) to query our keyspace.

Accessing Cassandra in C#

Now let’s write some code to access the posts we stored in the posts column family. There are 2 Cassandra libraries for .NET that I have used so far. Fluent Cassandra and Cassandraemon. I’m going to use Cassandraemon for this example.

There are many client libraries for several languages available to access data from Cassandra making it easy to use from almost anywhere.

One more thing…

As always I love to think of unconventional things to try so to prove how portable Cassandra and the client C# code is I ventured to make this work on a dual core 1ghz ARM Cortex A9 embedded SBC (Single Board Computer). This device can be compared to the dual core platforms available on smart phones these days.

My goal was to get big data on a little device.

First I had to install a Java runtime for Linux on an ARM platform which I found here. After installing I downloaded the tarball for the DataStax version of Cassandra. I was able to get it running very easily.

After getting Cassandra up and running I needed a Mono runtime for an ARM platform to run my .NET executable, “apt-get mono” was sufficient to get what I needed.

With those installed I was ready to go! I copied my bin\Debug directory to the embedded device and ran the executable that was compiled via Visual Studio. That’s right, I didn’t need to recompile! The binary straight from the Intel box developed with Visual Studio was used and run with Mono on the ARM based embedded device.

This is a testament to how portable Mono is. I did not change or recompile Cassandraemon or my application code. It just worked.

With Cassandra not only can we use high performance systems and scale to very big data but we can have big data on little devices such as this one which did all this with only a 5v USB cable plugged in.

Common things you will hear is how “NoSQL” databases are schema-less and using them to serialize objects removes a lot of the pain in comparison to using and maintaining a RDMS (relational database management systems).

There are 4 high level categories of “NoSQL” databases that I’m aware of which are ColumnFamily, Document, Graph and Key-Value databases. Within the 4 groups there are many options to choose from.

For example Cassandra and HBase (Hadoop) although both modeled based on Google BigTable and both in the ColumnFamily category are implemented very different and share some strengths and weaknesses but also have some that oppose each other.

The lack of schema you hear mentioned a lot in the “NoSQL” camps isn’t exactly accurate either. Wikipedia states that a Database schema is:

A database schema (pronounced skee-ma, /ˈski.mə/) of a database system is its structure described in a formal language supported by the database management system (DBMS) and refers to the organization of data to create a blueprint of how a database will be constructed (divided into database tables).

If you look at the HBase DataModel documentation you will find quotes like:

A column family regroups data of a same nature in HBase and has no constraint on the type. The families are part of the table schema and stay the same for each row; what differs from rows to rows is that the column keys can be very sparse

In the Cassandra DataModel documentation you’ll find documentation describing Keyspaces, Column Families, Columns and Super Columns. Column and Super Column sorting behaviour can be defined as Bytes, Long, Ascii, UTF8, Lexical UUID and Time.

In my opinion this is database schema. Perhaps much less schema than a typical relational database but schema nonetheless.

If we back up to the concept that many people adopt which is serializing objects into a “NoSQL” database then it is true the use of schema is almost non-existent even in Cassandra because as your data model changes your schema wouldn’t change. It’s schema but one that doesn’t change.

Using ColumnFamily, Document, Graph and Key-Value databases and all their diverse implementations as an object serialization store is not using them to their strengths and ignoring their weaknesses. They are very different choices and they often solve a different set of problems although you can misuse them in the same manner. A perfect example is Facebook. Facebook was the initial developer who created Cassandra but Facebook today uses both Cassandra and HBase (along with other database solutions). They use them for their strengths and align them with a specific problem.

For some cases serializing objects to these “NoSQL” databases may make sense but it’s important to consider that as an option and not the only way to use these alternatives.

Based on this information I think the term “NoSQL” is doing all of the non-relational database options a disservice. The term “NoSQL” does help to argue with management that maybe a relational database is not the best option but that’s about where it’s usefulness ends.

Don’t treat them all the same. Learn what the advantages and disadvantages of each are and choose wisely.

Arfa Karim Randhawa first discovered computers at the age 5 and was introduced to computers at the age of 6 after insisting to her father she wanted a PC. A computer prodigy was born.

3 years later in 2004 Arfa, a Pakistani student became the worlds youngest Microsoft Certified Professional at the age of 9. Arfa prepared for her certification exams during her four month summer break from school.

What makes this more amazing is that this feat would be challenging for an adult with a well established career in software development let alone someone who not long ago touched a keyboard for the first time.

August 2nd 2005 Arfa was presented the Fatimah Jinnah Gold Medal in the field of Science and Technology by the then Prime Minister of Pakistan Shaukat Aziz. The Prime Minister also presented her with the Salaam Pakistan Youth Award.

Arfa also received the President’s award for Pride and Performance, a civil award for people who have shown excellence in their respective fields over a long period of time.

The computer prodigy was honoured by the MKR Foundation with the Shabaash award.

With what most of us would consider a career full of achievements already accomplished at 10 years old Arfa was far from done. Arfa represented Pakistan on many international forums and was invited to join the Pakistan Information Technology Professionals Forum for two weeks in Dubai. Not only did she attend, a dinner reception in her name was hosted with dignitaries of Dubai including the Ambassador of Pakistan.

During the trip to Dubai Arfa added more awards to her collection including a laptop. The Dubai trip would be considered a dream for most of us but Arfa had more in mind to accomplish during the tour. Arfa was not just a computer prodigy but pursued to be pilot. She flew a plane in a flying club and at the age of 10 received her first flying certificate. Not bad for a 2 week trip.

November 2006 Arfa attended on invitation from Microsoft the Tech-Ed Developers conference themed Get ahead of the game held in Barcelona which she was part of the keynote. She was the only Pakistani among over 5000 developers. A fitting conference title for someone that seemed to be 2 or 3 generations ahead of everyone else in attendance.

In 2010 Arfa was made brand ambassador for the 3G wireless broadband service named EVO from Pakistan Telecommunication Company.

The brilliant Arfa became a national talent and with the pride of a nation behind her.

Her brilliance and wise beyond her years

When reading a quote or listening to one of her audio or TV interviews you start to realize in a few seconds that Arfa is an exceptional human being. In her TV interviews she looks relaxed but confident without a hint of uncertainty almost like she has everything all figured out.

In these audio interview highlights from geekwire Arfa reflects on her meeting with Microsoft’s then CEO and Chairman Bill Gates. Most of us would be awestruck but Arfa challenged Mr. Gates.

Arfa said

“I asked him why there are no kids and why kids can’t join your company and why they have to wait so much.”

Followed by

“Next I asked him why there aren’t any women around here. There should be an equal amount of men and women.”

She goes on to discuss her programming with loops and implementing sorting algorithms. Her main language being C# but she was already learning VB.NET and commented on how they are almost the same. At 10 it seems you can’t fool her and she’s already aware of the value to diversify her skills. A budding polyglot programmer in the making.

When asked what she might want to do after college she answers that she wants to engineer satellites and explains that since the world is going wireless there is a need for engineering in that sector.

The most profound quote from the interview highlights for me was at the very end

“If you want to do something big in your life, you must remember that shyness is only the mind. If you think shy, you act shy. If you think confident you act confident. Therefore never let shyness conquer your mind.”

Just as she insisted her desire for a PC at 5 years old Arfa always insisted the areas IT lab be upgraded so it can provide maximum educational facilities to the young people, especially females. Arfa believed that other girls of her village should get opportunities of good education as there was so much talent in them.

Tragedy strikes

At the age of 16 in her 2nd year studying her A Levels at the Lahore Grammar School Paragon Campus Arfa suffered from a cardiac arrest after an epileptic seizure and was admitted to Lahore’s Combined Military Hospital in critical condition on December 22nd 2011.

On January 13th 2012 parts of Arfa’s brain started to show signs of improvement but on January 14th 2012 the 16 year old Arfa Karim died at 9:50PM Pakistan Standard Time at the Combined Military Hospital Lahore. She was buried at her ancestral village Chak No. 4JB Ram Dewali, Faisalabad.

Personal comments

Usually I blog because people express interest in a topic but this time I felt compelled to write this post for myself so that I could persist this story and never forget.

I did not know Arfa but I know people who did and they all speak extremely highly of her. I learned about her amazing story when the story broke of her critical condition in December. Due to a medical illness when I was 8 I was minutes from my own life so her story affected me immediately and I prayed for her recovery.

I’m convinced if I had the chance to meet her with my love for learning she would have taught me a thing or two. Or ten. Maybe she could have helped me get over the hump on some things in C# I struggle with. I can’t even imagine what she would have accomplished if she lived to my age. I wish she was given the chance.

I wish the celebration and pride for her brilliance extended further around the world in the same way it did in Pakistan. Pakistani’s realized they had a national treasure in their hands.

There are a couple things I take from her attitude and insights. Never let things like shyness get in your way from your potential and that you can attack and achieve anything you put your mind to, no matter what your age.

On January 12th 2012 the world lost some of it’s potential.

I’ll finish with a tweet that sums up my thoughts exactly from Richard Campbell

Lost one of the good ones.

R.I.P. Arfa Karim Randhawa. Our thoughts are with Arfa’s family and friends.

Arfa Karim Randhawa and Clemens Vasters at the Pakistan Developer Conference in 2005

Arfa Karim Randhawa and Scott Hanselman in 2006

Arfa Karim Randhawa and Kate Gregory from 2006 in Barcelona

With any post like this it’s important to keep in mind it is my point of view based on what I enjoy or don’t enjoy from Metro. Your opinions may differ. Also keep in mind I’m disregarding the Metro design guidelines from Windows Phone 7 in this post.

The three pillars of Metro

In my opinion Metro has 3 pillars of strength and if you leave any one of the 3 out the experience falls apart. These 3 pillars are typography, simplicity and… the one usually left out…

Typography

Typography is emphasized in Metro and this benefits the user in many ways. We had a saying,

If the user can’t walk down stairs with their eyes alternating between the device and where they are going while navigating with their thumb the design isn’t ready.

The large text in the screenshot above makes it easy to consume and navigate on the go. It also ensures the content you want the user to consume is front and center because it’s difficult for anything to dominate it. Steve Streza pointed out on Twitter that Metro scales well to different form factors and I agree.The focus on typography scales well from phones to tablets and consoles (Xbox).

Simplicity

The emphasis on typography already contributes to the level of simplicity. The other areas where simplicity appears in Metro is shapes and icons. Single colour square boxes contain flat single colour icons, both of which are prominent on the screen. When the emphasis on typography and the focus on simplicity are combined with the last pillar of strength, the content pops out at you.

Live tiles are a great example of simplicity. They generally don’t have a lot of content crammed within them but they are usually oversized squares that have quite a lot of padding around the icon within them (if there is an icon). The icon itself is one colour and a simple 2D shape.

The screenshot above of the new metrofied Xbox 360 dashboard could be on a tablet and you wouldn’t know the difference because it’s so simple it can scale to different form factors. The same interface could be slightly tweaked to be more vertical and offered on a phone experience. Squares and big text is easy to move around.

In contrast one of the older dashboard implementations isn’t so flexible.

Although this dashboard contains some similar aspects with the Metro inspired dashboard, the interface wouldn’t scale as well to a phone, especially the text based menus since they are close together and some of them difficult to read as they fade into the background.

Another example of simplicity is the application bar on Windows Phone 7. For phones, the content should consume the screen real estate. You could argue this is important for many other form factors, but it is especially important on phones. You need menus and navigation but in a minimal fashion.

The app bar uses simple to understand icons but can still offer additional options while educating the user what the icons mean in case of any confusion.

Vibrant

Vibrant is the last of what I consider the 3 pillars of Metro and the one which is often missing. The best Metro experiences, those that really set them apart from other platforms, are the ones that are alive and colourful while at the same time emphasize typography and simplicity.

When I think of Metro I think of this

and this

and this

Metro is not an excuse to stop graphic design

When only 2 of the 3 pillars of what I consider a great Metro experience are present, it is usually the vibrant pillar that is left out, leaving us with just typography and simplicity. When vibrant is missing you’re left with an interface that more closely resembles a unix shell experience and that doesn’t offer much to engage the user.

In all those videos of great Metro experiences what we don’t see much of is this type of experience on the right. Unfortunately it’s all over the place in Windows Phone 7 and 7.5 “Mango”.

Some apps or screens make sense to be plain text but not as many as we see in the marketplace or in the Windows Phone operating system itself.

Live tiles are amazing but swipe to the side and all elegance goes away. What happened?

We can’t have an infinite list of live tile screens but I’m pretty sure some design could have went into this beyond a list with search. Maybe static tiles?

These are just 2 examples of what happens when vibrant is left out.

Which one of the above pops out more? I’m guessing the right (Newsroom).

It’s no secret that the Apple community has had a lot of design influence within their developer ecosystem and I think Microsoft has made some gains with investments in designer tooling that work along side the developer workflow (Expression Blend) but Metro opens a big door to creating black background with white text interfaces and calling it a day. It’s really easy as a developer just to place some solid colour rectangles and oversized text. Maybe it is Metro but its not engaging anyone.

I like that Microsoft as a company is jumping on board in a unified effort to adopt Metro but at times it seems like there are no real designers involved in implementing the Metro experience and that the deltas between one divisions designs and another divisions designs are really far apart.

Metro offenses on the web

For example, take the Windows Azure website. I’m not sure where this Metro experience was inspired from but it doesn’t resemble the others and if I was a startup it certainly isn’t getting me jazzed about the platform.

Navigate to the developer download page and you experience an even worse page that is slightly better than finger paint.

Windows Azure supports a great list of development platforms (.net, node.js, java, php) tell that story in a compelling Metro experience!

Engage and excite the user. Show your product off. Two examples of developer tooling websites with great user experiences are Xamarin and the MassTransit websites. Obviously these are not Metro inspired but the point here is even developer tooling should get great user experiences. Good experiences matter.

I decided to take a crack at redesigning the Windows Azure developer tools download page with more focus on the aspects of Metro that I enjoy most. In the image below you can see the content is heavily influenced from the current page but includes a background that is a little more alive.

Great examples of Metro

Here are some other examples of vibrant Metro experiences that I think have done a great job.

What I like most about these experiences is how alive they feel but don’t sacrifice simplicity. The large text, simple shapes and solid colours on the important content doesn’t get overshadowed. Many of those interfaces have active animations and make for a unique experience in comparison to other platforms that usually only animate based on user interaction.

Conclusion

These days I’m seeing a wide gap between good Metro and bad Metro experiences. I really like Metro but I think no matter what design principles you’re following, when designing a user experience you should sweat every last pixel and make the best user experience you can.

Having an HTTP server accept GET requests or POST and responding with XML, JSON or some other data format is not automatically RESTful. This statement will seem very odd to many reading this.

Unfortunately many of the HTTP-enabled API’s out there such as Twitter, who promote themselves as REST, have created confusion on what REST really is.

The definition of REST lost its way when popular services emerged calling themselves REST which were not. An API like Twitter is ignoring the values of the web and the browser by using HTTP as a transport for RPC (Remote Procedure Call). SOAP services also use HTTP in this way. Instead of doing RPC, HTTP should be used to transfer application state which is what REST is designed for.

It’s not bad for a service to not be RESTful if the problem needing a solution calls for it. Each situation is different and REST has it own set of advantages and disadvantages to consider. The problem is the term REST is being used where it does not belong.

REST constraints

Roy Fielding, one of the principal authors of the HTTP 1.0 and 1.1 specifications introduced REST in 2000 in his doctoral dissertation.

Conforming to the constraints for REST from Roy’s dissertation is referred to as being RESTful. As pointed out earlier these terms are used improperly in cases where the constraints are violated. Simply having a HTTP service that responds with JSON or XML does not make a RESTful service.

Client-Server constraint

Separation of concerns is the purpose of the client-server constraint which is intended to separate user interface concerns from data storage concerns. With the popularity of HTTP-enabled API’s being an integration point for online services the separation of the client and server was already chosen since the client is typically a 3rd party.

Stateless constraint

The client-server interaction must be stateless in nature. Each request from the client to the server must contain all of the data that is necessary to handle the request. Tackling concurrency and scalability becomes drastically easier when you don’t have to transition state between servers and handle scenarios when state has been mutated in multiple locations. Be careful not to confuse state and resources (data).

As Roy mentions in his dissertation making a choice to adopt an architecture style always has trade-offs. One disadvantage of being stateless is the repetition of data sent in a series of requests.

This constraint in my opinion is one of the first ones violated in self proclaimed REST services. Having the server retain state also has its advantages which for one service may make total sense.

Cache constraint

The data within a response to a request must be implicitly or explicitly labeled as cacheable or non-cacheable. The advantage of this constraint reduces partially or completely client to server interactions for a request or series of requests. Gains come in many facets such as user perceived performance and reliability (the service isn’t always required). Data reliability is a trade-off however.

Because of the stateless constraint, understanding when a cache is invalid is easier to identify because you don’t have any cases where server-side state has been mutated on one server but not others and consistency is easily achieved.

Layered system constraint

The layered constraint was added to address improving internet sized scalability requirements. Each layer cannot see beyond the immediate layer with which it is communicating with. This places boundaries on the overall complexity of the system.

Like most solutions for scalability there are usually trade-offs. Latency is increased with the introduction of layers but the cache-constraint above can certainly help reduce the amount of requests over the network.

I would imagine that many would still consider your service RESTful if you bent the rules on this constraint and solved scalability differently. From the outside your clients could interpret your service as being completely RESTful even if you did this differently.

One has to wonder what other constraints you broke if your layers cross all sorts of boundaries. I imagine violating the stateless constraint would cause all kinds of odd topologies as you start to wrestle with the concurrency challenges that introduces.

Pandoras box opened have you? State you’ve allowed Hmm?

Code-on-demand constraint

The code-on-demand constraint allows clients to be extendable by downloading and executing code. Similarly to java script in a web browser this allows you to add functionality without re-deploying client software.

The code-on-demand constraint is optional.

Uniform interface

Information is transferred in a standardized form which is certainly a trade-off. You gain in a common standard for information but you lose in efficiency by the inability to handle a specific applications needs.

REST has 4 interface constraints. I’m not going to go through all of them but I’ll give a quick summary:

Identification of resources

Each resource has a URI and is access through a defined set of HTTP methods (GET, PUT, POST, DELETE)

Manipulation of resources through representations

Each resource can have one or more representations. Such as application/xml, application/json, text/html, etc. Clients and servers negotiate to select representation.

Self-descriptive messages

Requests and responses contain not only data but additional headers describing how the content should be handled. Such as if it should be cached, authentication requirements, etc.

Hypermedia as the engine for application state

I’m going to focus on the last interface constraint Hypermedia as the engine for application state because I think there is a lot to learn when it comes to hypermedia and why many services are not RESTful by violating this constraint.

A REST API must be hypertext driven

Hypermedia as the engine for application state is the 4th Uniform interface constraint.

Roy himself has gotten frustrated by the misuse of the term REST and blogged about it with some great info on why certain services are not RESTful.

After talking with Darrel Miller and reading Roy’s post the key awareness I came out of it was that the use of hypermedia, particularly hypertext and linking are very important.

Roy states

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].

An example of hypertext aware clients are web browsers.

In my observation many services which claim to be REST but are not exclude hypertext and requires deep knowledge of the services API to understand how to navigate the application.

Let’s look into a Twitter response and discover what is missing and what hypertext enables which is required for REST.

Not RESTful (Twitter)

<?xml version="1.0" encoding="utf-8"?>
<statuses type="array">
  <status>
    <created_at>Thu Sep 01 22:19:10 +0000 2011</created_at>
    <id>109389864092442624</id>
    <text>Login issue on dev.twitter.com is now fixed.</text>
    <source>web</source>
    <user>
      <id>6253282</id>
      <name>Twitter API</name>
      <screen_name>twitterapi</screen_name>
      <location>San Francisco, CA</location>
      <profile_image_url>
        http://a2.twimg.com/profile_images/1438634086/avatar_normal.png
      </profile_image_url>
  </status>
</statuses>

The Twitter API also has API for looking at a users profile. Notice how the <user> element has no hyperlink to direct the client to the location of where the user resource is located. This means unlike a browser, a Twitter client needs to understand deep knowledge of the Twitter API to navigate to the user resource. If the Twitter API was RESTful within the response the <user> element would have a hyperlink which the client could automatically understand. The benefits of this are many and one of the most obvious ones is if Twitter changes its URI for user profiles the client would require no changes because like a browser the server response includes hyperlinks and the client understands them.

RESTful (Twitter modified)

<?xml version="1.0" encoding="utf-8"?>
<statuses type="array">
  <status>
    <created_at>Thu Sep 01 22:19:10 +0000 2011</created_at>
    <id>109389864092442624</id>
    <text>Login issue on dev.twitter.com is now fixed.</text>
    <source>web</source>
    <user href="http://api.twitter.com/1/users/show.xml?screen_name=TwitterAPI">
      <id>6253282</id>
      <name>Twitter API</name>
      <screen_name>twitterapi</screen_name>
      <location>San Francisco, CA</location>
      <profile_image_url>
        http://a2.twimg.com/profile_images/1438634086/avatar_normal.png
      </profile_image_url>
  </status>
</statuses>

Notice the href in the above XML markup. With the inclusion of hypertext, a RESTful client can navigate this all by it’s own just like a browser does when it makes links clickable by the user.

It is important to point out that in the world of REST a link may have uses outside of user navigation. The client could use links to navigate the data. A link could also be used for previous or next records for example.

Ever read a multi-page article on a website that has a next page link? The browser just knows how to handle that. RESTful clients often behave the same way.

Let’s take an Atom reader for example. The Atom format supports hypertext and you can easily see the benefits over the Twitter response.

<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:as="http://atomserver.org/namespaces/1.0/"
      xmlns:os="http://a9.com/-/spec/opensearchrss/1.1/">
  <os:totalResults>65801</os:totalResults>
  <os:startIndex>0</os:startIndex>
  <os:itemsPerPage>2</os:itemsPerPage>
  <as:endIndex>153</as:endIndex>
  <link href="/myserver/v1/widgets/acme?start-index=153&amp;max-results=2" rel="next" />
  <link href="/myserver/v1/widgets/acme?start-index=0&amp;max-results=2" rel="self" />
  <author>
    <name>AtomServer APP Service</name>
  </author>
  <title type="text">acme entries</title>
  <updated>2007-10-05T19:17:42.750Z</updated>
  <id>tag:atomserver.org,2007:v1:acme</id>
  <entry>
    <id>/myserver/v1/widgets/acme/205390.en.xml</id>
    <as:entryId>205390</as:entryId>
    <title type="text"> Entry: acme 205390.en</title>
    <author>
      <name>AtomServer Atom Service</name>
    </author>
    <link href="/myserver/v1/widgets/acme/205390.en.xml" rel="self" />
    <link href="/myserver/v1/widgets/acme/205390.en.xml/2" rel="edit" />
  </entry>
</feed>

Lines 9 and 10 show how Atom allows the client to understand it’s current location as well as where to navigate for the next collection of results. Atom clients can be far more dynamic than Twitter clients because of the use of hypermedia.

Line 25 you can see the inclusion of an edit link. By using the rel attribute Atom clients can automatically understand where to navigate for editing. The use of hypermedia specifically hypertext enables dynamic scenarios non-RESTful clients don’t get with responses that include no hypermedia. For this reason Hypertext is a constraint. Without including hypermedia a service is not RESTful.

Another good source of information on hypermedia is a blog post from Glenn Block. He talks about Hypermedia and forms.

RESTful Clients

When we build RESTful systems the way we build clients also changes. The clients behave very much like a browser and the clients start to benefit in the same ways that a browser does. Hypermedia unlocks many scenarios we don’t typically think of when we are accustom to building RPC-style services.

Conclusion

What should be clear after reading this is that many of the services you’ve used and interacted with which call their API a REST API don’t exhibit many of the benefits that the true definition of REST provides and violate many of the key constraints. To re-iterate this does not mean the service is poorly built or does not solve the problem set it attempts to solve. It simply means they are not RESTful. REST comes with it own set of advantages and disadvantages. I described some but not all of these in this post.

Understanding how clients could benefit from hypermedia and particularly hypertext was the “AHA” moment for me which encouraged me to look into this deeper. There is so much more to grasp and understand on this topic I’ve only begun.

I highly suggest reading Roy’s doctoral dissertation where he defines REST.

After spending all weekend on this post I’m going to get some REST myself. Oh who am I kidding…

In part 1 of this series we started reducing the Service Locator calls by removing them from the view models and moving it to the ViewModelFactory since this class is responsible for creating the view models. This allowed us to cut the ties in the view models where they were requesting dependencies from a global container.

Some of the benefits we gained from the first iteration of refactoring:

1. Reduced coupling between view models and the IoC container.
2. View model dependencies are push not pull. This removes coupling between the view model and the source of the dependencies.
3. View models are more intention revealing. What view models depend on and require is explicit and not hidden.
4. View models are easier to test. An IoC container isn’t required to initialize a unit test.

After all of the changes in the first iteration we still retained Blendability and did not have to compromise the design time experience.

This still left us with a global container which the ViewModelFactory calls to resolve dependencies for view models. Once our view models were up and running again it was time to remove the global container and dramatically reduce the coupling.

Why a type asking the IoC container to resolve its dependencies is bad

Having view models use a Service Locator or request the IoC container to compose the dependencies on its behalf couples the view model to the source of its dependencies. The view model does not need the IoC container itself to do any work. It only needs its dependencies. The view model requesting the dependencies has created a requirement on the view model for the IoC container to exist although it is not needed when you look at what the view model is responsible for.

This is brittle and instead should be handled declaratively. With service locator the view model is dependent on the IoC container which needs to be exposed as global state (so that it is accessible) whereas with dependency injection any IoC container can handle the creation.

This includes your tests. The global container is required for your objects to do their work. With dependency injection, testing your view models becomes simpler.

My original idea to minimize the coupling to a specific IoC container was to introduce IServiceLocator so that I could create implementations for various containers like Funq and Unity. What I found out was that it was easy to abstract the resolve methods of these IoC containers but abstracting the register methods was proving to be far more difficult. I was experiencing a lot of friction and it wasn’t clear how I could achieve this.

I learned a couple more things from this experience. It’s really difficult to abstract 2 things that do similar things but are implemented differently. The abstraction can become complex and the benefits start to fade.

What we did about the IoC container

As mentioned above rather than abstract the IoC containers with a layer of API that looks just like another IoC container we took the approach of encapsulation. Encapsulating the IoC container instead of abstracting it allowed us to still retain the ability to create new implementations based on different IoC containers but remove the coupling throughout the code base.

We introduced 2 key things to contribute to removing dependency on the IoC container. A Composition Root and ViewModelResolver.

Composition root

The concept of a composition root comes from Mark Seemann. He writes about it in his excellent book Dependency Injection in .NET. I highly recommend reading it. You won’t regret it!

Mark writes:

DEFINITION A Composition Root is a (preferably) unique location in an application where modules are composed together.

A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container.

We had to bend the rules a little bit to allow for ViewModelResolver but I think you will find it an acceptable solution because we closed off any abilities of container abuse.

If you recall earlier we had an ApplicationHost.Current singleton which exposed an ApplicationHost.Current.Container property so that we could resolve abuse dependencies anywhere we wanted. We replaced this with the Composition Root which we named Bootstrapper.

Before

public class ApplicationHost
{
    private static volatile ApplicationHost instance;
    private static object syncRoot = new Object();

    private ApplicationHost()
    {
        Execute.InitializeWithDispatcher();

        // Initialize the Funq container.
        this.Container = new Container();
    }

    public static ApplicationHost Current
    {
        get
        {
            if (instance == null)
            {
                lock (syncRoot)
                {
                    if (instance == null)
                        instance = new ApplicationHost();
                }
            }
            return instance;
        }
    }

    public Container Container { get; private set; }
}

As you can see in the singleton I exposed the container making it available for abuse to people writing code against it and coupling to it all over the place. Things can get out of control fast and become difficult to maintain and not flexible to change going forward.

After

public class Bootstrapper
{
    private Container container = null;

    public Bootstrapper()
    {
        Initialize();
    }

    private void Initialize()
    {
        container = new Container();

        container.Register<IEventAggregator>(new EventAggregator());
        container.Register<IDatabase>(new Database());

        container.Register<MainViewModel>(c => new MainViewModel(
            c.Resolve<IEventAggregator>(),
            c.Resolve<IDatabase>()));

        container.Register<BrowserViewModel>(c => new BrowserViewModel());

        container.Register<SettingsViewModel>(c => new SettingsViewModel(
            c.Resolve<IDatabase>()));
    }
}

In the Bootstrapper which is our Composition Root, we create the object graph dependencies in the Initialize() method. If you recall in part 1 we modified view models to support constructor injection. Those constructor parameters map to this composition we declare in the Bootstrapper. The types we define will get injected in the constructors of the view models when the IoC container resolves them.

It is important all your dependencies are declared in the Composition Root or else you will get a failure when you try to resolve one of the view models.

Also very key is we have not exposed the IoC container at all. We are completely closing off the ability for arbitrary code being able to call the container directly.

In the App.cs we instantiate the Bootstrapper to kick off the container registrations.

One thing still remains that is referencing the IoC container. In part 1 we moved the container resolve calls from the view models to the ViewModelFactory in our iterative refactoring. Now that view models are not aware of the IoC container and we have a Composition Root in place we need to find a solution to remove the coupling between ViewModelFactory and the IoC container.

We did this by introducing IViewModelResolver.

IViewModelResolver

My original idea of abstracting the IoC container into an IServiceLocator interface introduced an array of problems such as:

1. Still coupling view models to a generic Service Locator interface. View models still require a Service Locator to do work.
2. Sacrificing the power of each IoC implementation because the abstract layer on top would be a compromised feature set.
3. Fighting a lot of friction trying to make API’s that aren’t common work in a common way.

IViewModelResolver allows us to do the opposite. We can encapsulate the IoC container implementation and leverage that IoC containers full feature set because we aren’t exposing it. We can also implement different IoC container types easily.

In the Composition Root we declared our view models and their dependency composition. The view model resolvers will be used by the ViewModelFactory to resolve the view models. The view models just as before will be injected by their constructors.

As a side benefit we are achieving a better level of Single Responsibility Principle because the ViewModelFactory is responsible for providing run time or design time view models and the view model resolvers are responsible for resolving dependencies against a specific IoC container.

The resolver is also very easy to mock making it easier to test the ViewModelFactory than it was when we had the globally exposed IoC container with Service Locator requests.

In our case since we are using Funq, we created a FunqViewModelResolver implementation of IViewModelResolver.

public interface IViewModelResolver
{
    IViewModel Resolve();
}

public class FunqViewModelResolver : IViewModelResolver
{
    private readonly Container container;
    private Dictionary<type  , MethodInfo> methods = null;
    private MethodInfo method = null;

    public FunqViewModelResolver(Container container)
    {
        this.container = container;

        method = container.GetType().GetMethod(
            "Resolve", new Type[0]);

        methods = new Dictionary<Type,MethodInfo>();
    }

    public IViewModel Resolve(Type viewModelType)
    {
        MethodInfo genericMethod = null;
        if (!methods.TryGetValue(viewModelType, out genericMethod))
        {
            genericMethod = method.MakeGenericMethod(viewModelType);
            methods.Add(viewModelType, genericMethod);
        }

        var result = genericMethod.Invoke(container, null);
        return (IViewModel) result;
    }
}

Now that the Funq version of the resolver is implemented we need to refactor ViewModelFactory again to use the resolvers instead of the Service Locator call that we broke removed when we deleted the globally exposed IoC container.

Before

public abstract class ViewModelFactory<TViewModel, TDesignViewModel>
    where TViewModel : IViewModel
    where TDesignViewModel : TViewModel, new()
{
    public ViewModelFactory()
    {
    }

    public TViewModel ViewModel
    {
        get
        {
            TViewModel viewModel;
            bool designMode = DetectDesignMode();

            if (designMode)
            {
                // At design time instantiate design time version.
                // Populates mock data, dependencies don't have to be real.
                viewModel = new TDesignViewModel();
            }
            else
            {
                // Request IoC container to resolve view model & its deps.
                viewModel =
                    ApplicationHost.Current.Container.Resolve<TViewModel>();
            }

            viewModel.OnLocated();
            return viewModel;
        }
    }
}

After

public abstract class ViewModelFactory
{
    protected static IViewModelResolver resolver = null;
    public static void InitializeResolver(IViewModelResolver resolver)
    {
        // This is where we set the resolver for the ViewModelFactory.
        // This should get set in the Bootstrapper (Composition Root)
        // to the resolver implementation using the
        // IoC container that has been chosen for the application.
        ViewModelFactory.resolver = resolver;
    }
}

public abstract class ViewModelFactory<TViewModel, TDesignViewModel>
    : ViewModelFactory
    where TViewModel : IViewModel
    where TDesignViewModel : TViewModel, new()
{
    public ViewModelFactory()
    {
    }

    public TViewModel ViewModel
    {
        get
        {
            TViewModel viewModel;
            bool designMode = DetectDesignMode();

            if (designMode)
            {
                viewModel = new TDesignViewModel();
            }
            else
            {
                if (resolver == null)
                {
                    throw new InvalidOperationException();
                }

                // Use the resolver implementation to resolve
                // the view model requested.
                viewModel = (TViewModel)resolver.Resolve(typeof(TViewModel));
            }

            viewModel.OnLocated();
            return viewModel;
        }
    }
}

We introduced a new static method on the ViewModelFactory named InitializeResolver(). Like the other dependencies in the system we can initialize the ViewModelFactory with the proper resolver in the Composition Root.

The reason this needs to be static is because the ViewModelFactory is created in XAML as a resource so that it can be statically bound. The static method is to allow the resolver to be injected manually because the ViewModelFactory is not created by the IoC container and cannot resolve it’s dependencies.

Now we need to update the Bootstrapper.Initialize() method.

Before

private void Initialize()
{
    container = new Container();

    container.Register<IEventAggregator>(new EventAggregator());
    container.Register<IDatabase>(new Database());

    container.Register<MainViewModel>(c => new MainViewModel(
        c.Resolve<IEventAggregator>(),
        c.Resolve<IDatabase>()));

    container.Register<BrowserViewModel>(c => new BrowserViewModel());

    container.Register<SettingsViewModel>(c => new SettingsViewModel(
        c.Resolve<IDatabase>()));
}

After

private void Initialize()
{
    // Create the IoC container.
    container = new Container();

    // Initialize the ViewModelFactory with the Funq ViewModelResolver.
    ViewModelFactory.InitializeResolver(new FunqViewModelResolver(container));

    // Register the dependency composition.
    container.Register<IEventAggregator>(new EventAggregator());
    container.Register<IDatabase>(new Database());

    container.Register<MainViewModel>(c => new MainViewModel(
        c.Resolve<IEventAggregator>(),
        c.Resolve<IDatabase>()));

    container.Register<BrowserViewModel>(c => new BrowserViewModel());

    container.Register<SettingsViewModel>(c => new SettingsViewModel(
        c.Resolve<IDatabase>()));
}

This is how we use the ViewModelFactory in XAML (leaving out the less important markup). This is all created via Blend, no hand written XAML required. A designer can hook this up in a few clicks.

<phone:PhoneApplicationPage
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:vm="clr-namespace:kellafeed.ViewModels">

    <phone:PhoneApplicationPage.Resources>
        <vm:MainViewModelFactory x:Key="MainViewModelFactgoryDataSource"
                                 d:IsDataSource="True"/>

    </phone:PhoneApplicationPage.Resources>

    <phone:PhoneApplicationPage.DataContext>
        <Binding Mode="OneWay"
                 Path="ViewModel"
                 Source="{StaticResource MainViewModelFactgoryDataSource}"/>
    </phone:PhoneApplicationPage.DataContext>

    <-- XAML visuals... -->
</phone:PhoneApplicationPage>

Here’s how that XAML is created by the designer in Blend.

This is how the view looks with the DataContext set within Expression Blend. Full design time support!

After this 2nd iteration of refactoring we have now encapsulated the IoC container and removed it from being globally accessible and abused. This is important because we enforce a clean path rather than opening the container up and allowing people to go in a wrong direction. We do use the IoC container in the ViewModelResolver but it is a specialized implementation to solve a specific problem and does not open the door for abuse.

Our code base is even more maintainable than it was after part 1 which also raises the level of testability. Our view models were already very testable after part 1 but the ViewModelFactory is now testable without requiring an IoC container by mocking the resolvers.

We reduced a lot of coupling and increased testability quite a lot in these 2 iterative refactoring steps!

Stay tuned for more improvements!

Series

• Part 1: View Models
• Part 2: Reducing IoC container coupling
• Part 3: Handling special cases like late registrations outside the composition root
• Part 4: Unit testing

I had a great opportunity to pair program with Glenn Block and we went through several iterations of refactoring. I’m amazed at his ability to see small parts of a code base and within a couple minutes he has a strategy for decoupling and separating the concerns.

This series of blog posts shouldn’t only be for people interested in MVVM. In general I learned a lot of of values that I’ll take with me in different problem sets and I hope I am successful in translating those into this series.

One thing I’ve struggled with for a long time is how to cut the dependency on the IoC container. I knew that Service Locator code was bad but every time I tried to reduce the coupling I would run into road blocks where I had to expose the container.

We started at the ViewModelFactory<TViewModel, TDesignViewModel> and worked our way out from there.

What is ViewModelFactory

ViewModelFactory is one of my favourite classes when implementing MVVM. Jeremiah Redekop created this bit of code and I modified it slightly. ViewModelFactory allows us to provide run time view model data and design time view model data. This enables us to have Blendability (ability to see data in Expression Blend as we design our user experiences with a visual tool).

The original version of ViewModelFactory<TViewModel> from Jeremiah provides 2 methods OnLocatedAtRunTime() and OnLocatedAtDesignTime() so that you can separate run time execution (for example querying a REST service) from populating mock data.

I slightly modified ViewModelFactory<TViewModel> to
ViewModelFactory<TViewModel, TDesignViewModel> because I liked the design time implementation to be completely separate from the run time implementation.

The DataContext of the view binds to the ViewModelFactory.ViewModel property, which returns the proper view model based on if it is executing in the designer or runtime.

What’s wrong with my view models

Now that we know what ViewModelFactory does, let’s dive into the problems with my implementation and why we started here in the refactoring.

My View models have a bunch of dependencies like Event Aggregator, access to the data store etc. I was using the Service Locator pattern to resolve these dependencies from a Funq container. The view model gets created from the ViewModelFactory which is created in XAML. I didn’t see a way that I could allow constructor injection of these dependencies so this is why I had put in place Service Locator. I knew it was a bad choice, I just didn’t know what to do about it.

To be able to solve this we had to first fix ViewModelFactory since this is where view models get created.

ViewModelFactory refactor iteration 1

The fun thing when pairing with Glenn especially with refactoring is he has a very iterative approach which avoids an “OMG the whole thing is busted!” situation. It’s also great for learning experiences because you can see step by step the evolution of the changes that are happening.

The first iteration was to introduce resolving dependencies for view models by the ViewModelFactory since it is currently responsible for creating view models.

This is what the ViewModel property looks like for ViewModelFactory before the first iteration of refactoring. As you can see we are simply serving the run time or design time version of the view model.

Before

public TViewModel ViewModel
{
    get
    {
        TViewModel viewModel;
        bool wasCreated;
        bool designMode = DetectDesignMode();

        if (designMode)
        {
            viewModel = new TDesignViewModel();
            wasCreated = true;
        }
        else
        {
            if (shareInstances)
            {
                viewModel = (TViewModel)sharedInstances.CreateOrGetValue(
                                typeof(TViewModel),
                                () => new TViewModel(), out wasCreated);
            }
            else
            {
                viewModel = new TViewModel();
                wasCreated = true;
            }
        }

        viewModel.OnLocated(wasCreated);
        return viewModel;
    }
}

The first iteration of refactoring we introduced the IoC container in a Service Locator like fashion so that we could then refactor our view models without breaking everything.

This is how it looked after the changes.

After

public TViewModel ViewModel
{
    get
    {
        TViewModel viewModel;
        bool designMode = DetectDesignMode();

        if (designMode)
        {
            // At design time instantiate design time version.
            // This populates mock data, dependencies don't have to be real.
            viewModel = new TDesignViewModel();
        }
        else
        {
            // Request IoC container to resolve view model & its deps.
            viewModel =
                ApplicationHost.Current.Container.Resolve<TViewModel>();
        }

        viewModel.OnLocated(wasCreated);
        return viewModel;
    }
}

This allowed us to now continue to refactor our view models so that they can support constructor injection for their dependencies. This is how a view model looked before the refactoring.

Before

public class MainViewModelFactory
    : ViewModelFactory<MainViewModel, MainViewModelDesign>
{
}

/// <summary>
/// Design time version of the MainViewModel.
/// </summary>
public class MainViewModelDesign : MainViewModel
{
    public override void OnLocated(bool newInstance)
    {
#if DEBUG
        // This gets called at design time.
        this.Stories = new ObservableCollection<Story>();
        this.Stories.Add(
            new Story("The Windows Blog", "Upping our game..."));
        this.Stories.Add(
            new Story("Robot Overlords", "Nevada Passes Law..."));
        this.Stories.Add(
            new Story("TechCrunch", "eBay Acquired Magento..."));
        this.Stories.Add(
            new Story("Inside Facebook", "Facebook Testing..."));
        this.Stories.Add(
            new Story("FOSS Patents", "Eastman Kodak v..."));
#endif
    }
}

public class MainViewModel : BaseViewModel
{
    private Database db = null;

    public MainViewModel()
    {
    }

    public override void OnLocated(bool newInstance)
    {
        // This gets called at run time.
        // Gah! Bad me. Wish I knew how to fix this.
        // I will learn how though!
        db = ApplicationHost.Current.Container.Resolve<Database>();
        this.Stories = new ObservableCollection<Story>();

        LoadDatabase();
        GetFeedStories();
    }
}

As you can see from this view model the Service Locator is used to resolve dependencies. As you can imagine this code is littered through various view models.

Since we moved the Service Locator code to the ViewModelFactory, now we can shed the container dependency from the view models (remember, we are taking an iterative approach, it gets better later, stick with me).

After

public class MainViewModelFactory
    : ViewModelFactory<MainViewModel, MainViewModelDesign>
{
}

public class MainViewModelDesign : MainViewModel
{
    public MainViewModelDesign()
        : base(new EventAggregator(), new DesignDatabase())
    {
    }

    public override void OnLocated(bool newInstance)
    {
#if DEBUG
        this.Stories.Add(
            new Story("The Windows Blog", "Upping our game..."));
        this.Stories.Add(
            new Story("Robot Overlords", "Nevada Passes Law..."));
        this.Stories.Add(
            new Story("TechCrunch", "eBay Acquired Magento..."));
        this.Stories.Add(
            new Story("Inside Facebook", "Facebook Testing..."));
        this.Stories.Add(
            new Story("FOSS Patents", "Eastman Kodak v..."));
#endif
    }
}

public class MainViewModel : BaseViewModel
{
    private IDatabase db = null;
    private IEventAggregator events = null;
    private Feed feed = null;

    public MainViewModel(IEventAggregator events, IDatabase db)
    {
        this.events = events;
        this.events.Subscribe(this);
        this.db = db;

        this.Stories = new ObservableCollection<Story>();
    }

    public override void OnLocated(bool newInstance)
    {
        LoadDatabase();
        GetFeedStories();
    }
}

Interfaces were introduced because at design time we may need to mock some of these dependencies and not use the real types. We created IDatabase and in the generic parameters of the design time view model there is a design version of the database defined. Since we don’t want to be attempting to talk to isolated storage at design time we can implement a mocked version of the interface which does nothing. The mocked database is pretty simple.

public class DesignDatabase : IDatabase
{
    public Feed GetFeed()
    {
        return new Feed();
    }

    public void SaveFeed(Feed feed)
    {
    }

    public void Reset()
    {
    }
}

The MainViewModel is far more testable now as well in this version. We don’t need to wire up an IoC container to test it’s functionality. We can inject mock dependencies in the constructor and test the view model easily.

If we wanted to we could also place the design time view models and mocks in a separate assembly.

This is what I had in the App.cs to initialize the Funq IoC container.

private void InitApplicationHost()
{
    events = new EventAggregator();
    db = new Database();

    ApplicationHost.Current.Container.Register<EventAggregator>(events);
    ApplicationHost.Current.Container.Register<Database>(db);
}

Since we are now going to be utilizing the IoC container to construct more of the object graph and inject dependencies into the constructors we need to ensure we are registering all the types we need. While we were at it we decided to reduce the amount of calls to ApplicationHost.Container to position ourselves nicely for when we nuke that sucker all together.

private void InitApplicationHost()
{
    var container = ApplicationHost.Current.Container;

    db = new Database();

    container.Register<IEventAggregator>(new EventAggregator());
    container.Register<IDatabase>(db);

    container.Register<MainViewModel>(c => new MainViewModel(
        c.Resolve<IEventAggregator>(),
        c.Resolve<IDatabase>()));

    container.Register<BrowserViewModel>(c => new BrowserViewModel());

    container.Register<SettingsViewModel>(c => new SettingsViewModel(
        c.Resolve<IDatabase>()));

    container.Register<NavigationManager>(c => new NavigationManager(
        c.Resolve<IEventAggregator>()));
}

We’ve reduced coupling significantly to the IoC container from the view models and as a result as mentioned things are becoming more testable. We still have the service locator code within the ViewModelFactory but in the next part in this series I will discuss how we created ViewModelResolver and a composition root in the form of a bootstrapper to completely eliminate the ApplicationHost.Container property all together.

Things get much cleaner in part 2, stay tuned!

Series

• Part 1: View Models
• Part 2: Reducing IoC container coupling
• Part 3: Handling special cases like late registrations outside the composition root
• Part 4: Unit testing

I understood the message around setters but was confused about the message regarding getters (I’ll get to setters later). I’m not sure if people are repeating messages from others without understanding why or they are simply leaving out the details so I thought this post might have some value for people learning like I am.

Getters

The confusion for me around why getters were bad was based on seeing implementations of query methods. This led me to believe that the message people were conveying was getter properties are bad but query methods are okay. This confused me as I see them as the exact same thing.

Today when chatting with Yves Reynhout (@yreynhout) on Twitter I decided to ask “why’ and get to the root of the reasoning. What I learned was my thinking wasn’t incorrect, I misunderstood the message which I think maybe a lot of people do also. Here’s what I learned:

Getter properties containing the same code as the query method comes down to preference. It’s the same thing. Getter properties are not bad.

What people are actually advocating is a tell don’t ask approach to your business logic. They are questioning the use of a query (whether it is a getter or method) to drive your behaviour. This makes a whole lot more sense to me now.

Setters

Having for example a collection of items for a shopping cart and simply calling cart.Items.Add(item) promotes a CRUD style architecture. When you start writing business logic in the form of setters now your creating an array of getters to support the setters to ensure you can do what you want to do in the setter. You’re also littering your code base with business logic by having to check properties on the cart before adding items to it in the various places the user can add items to their shopping cart.

If your business rules said a user can only purchase 5 items, now you are going to be checking if cart.Items.Count >=5 throughout your code base. Also your collection isn’t protecting against this rule in any way. On top of this, if you build your business logic with a lot of properties, it becomes an ask then tell style of development. This makes it easy to scatter your business logic and creates a lot of coupling throughout your system as well as reduces your code bases flexibility for change.

Tell don’t ask

A tell don’t ask approach to your API and behaviours promotes encapsulation. Your cart object will have queries for displaying information but these won’t be used to drive business logic. You will have command methods to handle this which encapsulate the behaviours that drive your business rules.

Here’s a few quotes I found that describe it well:

@lucisferre: @kellabyte @yreynhout the idea is to hand off the responsibility to the classes responsible, rather than query them and decide for them

Alec Sharp states:

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

I think Alec’s message makes a whole lot of sense. Writing good object-oriented code allows us to encapsulate the responsibilities of the cart within the cart itself rather than exposing state and allowing everyone else to implement the business rules outside of the cart.

Conclusion

I think queries in the form of getters or methods returning a value have a place. Some cases it just makes sense. Some times an outside object does need to know about something from another object to make its decisions.

In most cases by designing your objects around encapsulating behaviour which that object is responsible for you are creating a much cleaner and maintainable code base.

As Yves said on Twitter, when creating a query, think about why.

It may have reason to be there but you should be able to identify the times you are exposing state to create behaviours that belongs to an object outside of it’s scope. In these times you should pull it back into the object’s responsibilities.

I suggest reading Yves blog post on Guards and Queries in the domain model. It has some great code examples. It’s geared to DDD but the same principals apply to any business logic behaviour in my opinion.

Is that not crazy awesome? I was amazed at how simple it was. Below is how I did it. I can’t wait to work on a more elaborate demo. Stay tuned! Follow my Twitter and this blog.

How I got to this point

My experiments in continuous client architecture has started to gain a lot of traction since I have been tweeting and creating working code and videos. My user experience rant on the potential of continuous client has spanned almost a calendar year now and for the people just following along recently based on my last video I’d like to recap a bit of history.

In July 2010 I posted my thoughts of how I thought the cloud plays a key role in continuous client. The cloud helps bridge the gap between cloud hosted code and on-premise hosted code. On-premise in the case of continuous client is devices such as PC’s, tablets, smart phones and any other device. At the time I wasn’t exactly sure of a way to implement it architecturally without introducing large amounts of complexity and synchronization code.

In the last 5 months I’ve been researching and learning enterprise integration patterns and a pattern called CQRS. Fast forward to a month ago (May 2011) and the stars seemed to align in my head one day. I wrote a post about combining some principals of both which helps us build an architecture that allows us to fairly easily implement some continuous client experiences. It dawned on me that the challenge is really an integration issue.

How did I build it

Enterprise integration patterns brings the value of integrating multiple apps, services and devices through messaging patterns. CQRS gives us the value of building an event driven architecture centered around our state changes. In CQRS the domain mutations only occur as a result of an event being handled. This allows you to support event sourcing where you can get replay ability. In this case we aren’t so much worried about a domain but the user experience state.

Let’s put these together to enable continuous client:

• Every user interaction generates an event. The application handles the event and mutates internal state.
• The event gets sent as a message to a service bus hosted in the cloud with a copy per device we want the user experience to be capable of transitioning to.
• The cloud hosted service bus enqueues these messages in a separate queue per device. This allows for each device to event source what happened on the other devices.

It would look something like this:

This gives us a system where event sourcing is essentially automating the user experience and since our application code is developed to handle events natively it operates the same. Another key thing to note is that the cloud infrastructure is holding the queue of events. Devices don’t have to be running the application to take part in the state transitions. Reliable messaging allows us to consume these messages whenever the application starts up.

To prove this out I developed a video player demo as my first attempt at continuous client. The video player has 2 basic functions which are play and pause. I created 2 port’s. One for Windows Phone 7 and Silverlight and my friend Martin Pilkington helped with the iOS iPhone port (thanks Martin!).

We utilized the new Azure Service Bus cloud platform for the messaging infrastructure. The upcoming Azure Service Bus platform has support for topics. I used a topic per user and separate subscription per device. This gives a queue per device, each having their own copy of the messages pushed into the topic. Filtering based on device id was used so that a device would only get messages generated by other devices and not self-generated messages.

In a weekend I had my first continuous client demo working. Most of that time was spent learning Azure Service Bus and writing ports. The actual application code was very simple and I used the Greg Young’s CQRS sample as a reference point.

Show us the code

One thing to keep in mind here in the Windows Phone 7 and Silverlight code is I did not implement this using the MVVM pattern. I’m a fan of MVVM but the purpose is to keep the sample code as simple as possible. Implementing this in MVVM doesn’t change a whole lot.

Here is the WP7 and Silverlight web application code. It is exactly the same and shared between both:

using System;
using System.Windows;
using System.Windows.Media;
using Microsoft.Phone.Controls;

using VideoDemo.Messaging;

namespace VideoDemo
{
    public partial class MainPage : PhoneApplicationPage,
        IHandle<PlayMessage>,
        IHandle<PauseMessage>
    {
        private EventAggregator events;
        private TimeSpan duration;

        public MainPage()
        {
            InitializeComponent();

            this.Loaded += new RoutedEventHandler(MainPage_Loaded);

            this.buttonPlay.Click +=
                new RoutedEventHandler(buttonPlay_Click);
            this.buttonPause.Click +=
                new RoutedEventHandler(buttonPause_Click);
            media.CurrentStateChanged +=
                new RoutedEventHandler(media_CurrentStateChanged);
        }

        void MainPage_Loaded(object sender, RoutedEventArgs e)
        {
            events = App.Container.Resolve<EventAggregator>l;();
            events.Init();
            events.Subscribe(this);

            media.Source = new Uri("http://someurl/tron.wmv");

        }

        void media_CurrentStateChanged(object sender, RoutedEventArgs e)
        {
            switch (media.CurrentState)
            {
                case MediaElementState.Playing:
                    media.Position = duration;
                    break;
            }
        }

        void buttonPlay_Click(object sender, RoutedEventArgs e)
        {
            // Here we publish the interaction as an event to Azure
            // ServiceBus. We don't do any mutation of state without
            // the event going through our event mechanism. This
            // ensures all our code when event sourced from Azure
            // ServiceBus runs as-is with the native behaviors of the app.
            events.Publish(new PlayMessage(media.Position));
        }

        void buttonPause_Click(object sender, RoutedEventArgs e)
        {
            // Same as above.
            events.Publish(new PauseMessage(media.Position));
        }

        public void Handle(PlayMessage message)
        {
            // Since we are handling the even there we can mutate
            // state. Live interactions or event sourced events from
            // Azure ServiceBus will all go through this path. It is the
            // native behavior of the app.
            duration = message.Duration;
            media.Play();
        }

        public void Handle(PauseMessage message)
        {
            // Same as above.
            duration = message.Duration;
            media.Pause();
        }
    }
}

// Here are the message types.
public class PlayMessage : Message
{
    public TimeSpan Duration { get; set; }

    public PlayMessage()
    {
    }

    public PlayMessage(TimeSpan duration)
    {
        this.Duration = duration;
    }
}

public class PauseMessage : Message
{
    public TimeSpan Duration { get; set; }

    public PauseMessage()
    {
    }

    public PauseMessage(TimeSpan duration)
    {
        this.Duration = duration;
    }
}

Notice here when the interaction event occurs all we do is fire an event. This event is self handled. The events published to the EventAggregator get sent to Azure Service Bus so that all messages are delivered to the topic which each device subscribes to.

I am receiving messages from Azure Service Bus over HTTP. I serialize messages as JSON and when a new message is received we deserialize the JSON into the message type and pump them through the EventAggregator.

subscription.MessageRecieved +=
    new EventHandler<SubscriptionMessageEventArgs>(messageRecieved);

subscription.ReceiveMessage(10);

void messageRecieved(object sender, SubscriptionMessageEventArgs e)
{
    EnvelopeMessage msg =
        JsonConvert.DeserializeObject<EnvelopeMessage>(e.Message);

    Type type = MessageMapper.GetType(msg.MessageId);

    object message = JsonConvert.DeserializeObject(
        msg.MessageContent.ToString(), type);

    Publish(message);
    subscription.ReceiveMessage(10);
}

Since a user interaction is publishing a message to the EventAggregator and our Azure Service Bus topic subscription is also publishing to the EventAggregator our application code is now architected to be natively event driven and our application code has no concept of the source of the event.

Messages have an id that is canonical so that it is not specific to any platform. I chose to use a URI format such as http://kellabyte.com/samples/VideoDemo/Messages/PlayMessage and we use a MessageMapper to get the app specific type that message relates to for deserialization purposes since we can’t share types across platforms who don’t share languages. This could probably be done cleaner, I didn’t spend much time here since it wasn’t the primary focus of the sample.

I’m not covering all the Azure Service Bus code in this post there is already a lot of content out there for Azure. If you feel I should blog about it I can do a specific post for that, let me know!

It’s really very simple and straight forward. As long as you adhere to the rules your application operates the exact same whether it is interactions as a result of a user action or event sourced from the cloud.

Here’s Martin’s Objective-C iOS application code for the iPhone:

#import "Video_DemoViewController.h"
#import "AWSServiceController.h"

NSString *M3PlaybackTime = @"Duration";
NSString *M3PlayMessage =
    @"http://kellabyte.com/samples/VideoDemo/Messages/PlayMessage";
NSString *M3PauseMessage =
    @"http://kellabyte.com/samples/VideoDemo/Messages/PauseMessage";

@interface Video_DemoViewController () 

- (MPMoviePlayerController *)_moviePlayer;

@end

@implementation Video_DemoViewController 

@synthesize serviceController;
@synthesize contentView;

/***************************
 Set up
 **************************/
- (id)initWithCoder:(NSCoder *)aDecoder {
    if ((self = [super initWithCoder:aDecoder])) {
        [self addObserver:self
               forKeyPath:@"serviceController"
                  options:NSKeyValueObservingOptionOld
                  context:NULL];
    }
    return self;
}

/***************************
 Update notifications when the service controller changes
 **************************/
- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(NSDictionary *)change
                       context:(void *)context {
    if ([keyPath isEqualToString:@"serviceController"]) {
        [[SAFE_NULL([change objectForKey:NSKeyValueChangeOldKey])
                    notificationCenter] removeObserver:self];

        id centre = [[self serviceController] notificationCenter];

        [centre addObserver:self
                   selector:@selector(playMovie:)
                       name:M3PlayMessage
                     object:nil];

        [centre addObserver:self
                   selector:@selector(pauseMovie:)
                       name:M3PauseMessage
                     object:nil];
    }
}

/***************************
 Set up the movie player
 **************************/
- (void)viewDidLoad {
    MPMoviePlayerController *player = [self _moviePlayer];
    [[player view] setFrame:[[self contentView] bounds]];
    [[self contentView] addSubview:[player view]];
    [super viewDidLoad];
}

/***************************
 Set up and return the movie player
 **************************/
- (MPMoviePlayerController *)_moviePlayer {
    if (!moviePlayer) {
        NSURL *url = [NSURL URLWithString:
        @"http://someurl/tron.m4v"];
        moviePlayer = [[MPMoviePlayerController alloc]
                                  initWithContentURL:url];

        [moviePlayer setShouldAutoplay:NO];
        [moviePlayer setControlStyle:MPMovieControlStyleNone];
    }
    return moviePlayer;
}

/***************************
 Handle a play notification
 **************************/
- (void)playMovie:(NSNotification *)aNote {
    NSNumber *time = [[aNote userInfo] objectForKey:M3PlaybackTime]
    CGFloat playbackTime = [time floatValue];

    [[self _moviePlayer] setCurrentPlaybackTime:playbackTime];
    [[self _moviePlayer] play];
}

/***************************
 Handle a pause notification
 **************************/
- (void)pauseMovie:(NSNotification *)aNote {
    NSNumber *time = [[aNote userInfo] objectForKey:M3PlaybackTime]
    CGFloat playbackTime = [time floatValue];

    [[self _moviePlayer] setCurrentPlaybackTime:playbackTime];
    [[self _moviePlayer] pause];
}

/***************************
 Post a play notification when the user presses the play button
 **************************/
- (IBAction)play:(id)sender {
    CGFloat time = [[self _moviePlayer] currentPlaybackTime];
    NSNumber *timeObj = [NSNumber numberWithFloat:time];
    id info = [NSDictionary dictionaryWithObject:timeObj
                                          forKey:M3PlaybackTime]

    id centre = [[self serviceController] notificationCenter];
    [centre postNotificationName:M3PlayMessage
                          object:nil
                        userInfo:info];
}

/***************************
 Post a pause notification when the user presses the pause button
 **************************/
- (IBAction)pause:(id)sender {
    CGFloat time = [[self _moviePlayer] currentPlaybackTime];
    NSNumber *timeObj = [NSNumber numberWithFloat:time];
    id info = [NSDictionary dictionaryWithObject:timeObj
                                          forKey:M3PlaybackTime]

    id centre = [[self serviceController] notificationCenter];
    [centre postNotificationName:M3PauseMessage
                          object:nil
                        userInfo:info];
}

/***************************
 Clean up
 **************************/
- (void)dealloc {
    [contentView release];
    [super dealloc];
}

- (void)viewDidUnload {
    [self setContentView:nil];
    [super viewDidUnload];
}
@end

Keep an eye out because I will be working on a more elaborate continuous client sample! I’ve begun work on a mobile RSS reader so that I can prove that the architecture shown here can carry over to all kinds of applications while enabling all sorts of user experience transitions.

If you would like to help port it to a specific platform and work with me on the continuous client concepts feel free to contact me on Twitter

Shout out to Martin Pilkington for working on the iOS port in parallel with me and the Azure Service Bus team (Clemens Vasters and Will Perry) for answering my questions on Twitter and logging some bugs that I encountered. I really enjoyed working with Azure Service Bus. It’s very easy and handy to use on multiple platforms.

I’m excited about this progress. Stay tuned for more continuous client!