I'm starting another blog on the business/psychology/technology of the new social web over here. The purpose of it is to be less nuts and bolts and more study of the interplay between the business, technology and psychology of the Web 2.0 world. I'm going to analyize, break-down and study as much as I can about that world and hopefully open up some interesting dialog as the blog continues to grow.

...I have become more and more interested in that business/psychology/technology aspect of web world lately and have been wanting to study it more (and thus write about it). However, I didn't want to muddy up the point of this blog as a place for people to go to understand the under-the-hood pieces of Microsoft .NET technologies, so I just created a second one.

I invite you to come on over when you have a chance, I'll be posting regularly and - hopefully - have some interesting things to say.

In my previous post I gave a brief overview of what an Animation is in ASP.NET AJAX, and now it's time to understand how you go about actually using them. By the end of this post you should be able to look at a block of Animation XML and understand what it's doing and you should be able to write a block of Animation XML without needing to lookback on a sample block of code (too much).

Let's Recap for a Moment

Before diving, let's recap from my previous post: an Animation in the ASP.NET AJAX framework is any DHTML effect that leverages the Animation framework provided by the ASP.NET AJAX toolkit (which can be found here). The problem found in playing with DHTML in the past has been that you've needed JavaScript (and sometimes pretty hairy JavaScript) to do anything meaningful with it. As programmers we're "resourceful" (or lazy) and therefore don't want to do more work than we need. With the Animation framework in ASP.NET AJAX, you only need to worry about XML markup specific to the animation you want.

In short, ASP.NET AJAX Animations are the easy way of adding cool DHTML animations and effects to your page - it achieves this by letting you define and play with your animations declaratively through an XML syntax.  

Show Me an Example

Let's go back to an earlier example that I did (because of its utter simplicity) and work out from there. In my previous post I showed an example effect on a button where, once you clicked the button, it's text color changed red and then faded out:

to....

You achived this effect by using declarative XML syntax. The syntax let you play with the properties (the starting color and ending color in this example) without needing to write any code; thereby making things easier and more manageable for everyone. Let's break the syntax I showed you earlier down one element at a time so that you can see why a particular element exists and what it does.

Understanding the ASP.NET Animation XML Syntax

As I said earlier, to write an Animation in ASP.NET AJAX, you use an XML syntax. The syntax that resulted in the above button color change looks like this:

First thing to take away is that this is a control extender - or an object in the ASP.NET AJAX framework that let's you apply AJAX'ish properties to an already existing, standard ASP.NET control (you can learn more about extenders here). What this means, practically, is that the animation needs to know to what standard ASP.NET control the animation will be applied. If you take a look at the first line of XML, you'll see the TargetControlID property pointing to Button1. You should know that this Animation will, then, be applied to Button1.

Second is the Animations element which will house all of the animations you will apply to Button1 (that's right, you can apply more than one, even in parallel). This may seem somewhat redundant, but it is required.

Third we have an event name. In our example, OnClick, means that the Animations will be executed during the OnClick event of Button1 (bear in mind that this is the client onclick event, not the server one). Therefore when someone clicks Button1, the animations specified below the OnClick event node will be executed.

The events OnClick, OnLoad, OnMouseOver, OnMouseOut, OnHoverOver and OnHoverOut are valid events; meaning you don't have to just use OnClick, you could also use OnHover. It's interesting to note that you can have all of these event handlers under the same Animations element if you wanted to - therefore, you could have one Animation registered for OnClick, and a totally different one registered for OnMouseOver, thereby creating a very dynamic control!

Fourth we have a sequence element; but - I have to admit to something here, this is actually not necessary in our example. I added it because I wanted to make a point about something. The point I want to make is a subtle one: you can only have one Animation registered for a particular event type (OnClick, OnMouseOver). The reason this isn't a limitation, however, is because there are two Animations called Sequence and Parallel which are not only valid Animations themselves, but allow nesting of other animations. Therefore, Sequence is an Animation itself that will call each child Animation one after another (in "Sequence"), and Parallel is an Animation that will call each child Animation at the same time (in "Parallel"). This is a subtle, yet powerful, thing to realize.

So..the following XML is actually valid (note the missing Sequence element):

But, if you wanted to change the color of the button and THEN fade it away completely, for example, you would have to nest the Color Animation and FadeOut animation within a Sequence Animation (not doing so will result in a runtime exception). The XML must look like this:

The result from the above XML declaration is to fade the button's color from FF0000 to 666666 and then completely fade it out of existence in .5 seconds. What's really cool is if you wanted to do both at the same time, all you have to do is change the Sequence element to a Parallel element:

Cool, huh? Now the color change and the fade-to-nothing will happen at the same time or in Parallel.

The lowest level element of the structure is always the actual Animation itself (Color for color change, FadeOut for fading out the element, etc).

Does it Get Tougher?

Yes, somewhat because you can actually tie into the XML script to be executed when certain events occur and conditional statements. We'll explore that, however, next time...

In two previous articles here and here I did a fairly high-level description of JSON and why it's important in ASP.NET AJAX. Hopefully you either read those or you already have a fairly decent understanding of the topic. The point behind writing those posts was to give you the knowledge required to understand the internals of the Animation framework in ASP.NET AJAX. I'm going to begin the dive now, but before doing so actually give a brief overview of, exactly, what Animations are in ASP.NET AJAX. I'll attempt to answer the questions why are they important, and why should you - as a .NET developer - care.

What are Animations in ASP.NET AJAX?

Animations are not built-in to ASP.NET AJAX, they are an addition to it brought about by the ASP.NET control toolkit, an open-source project going on over here. What they provide is an easy-to-use method of adding fancy DHTML effects (such as call-out windows, flashing buttons, rotating objects, etc) to your page. You will find a feature such as this handy when you need to make a web-site that stands out above the rest and is a bit more interactive than, say, your typical web application. For example, you could make a window pop-out at the user when he/she clicks a button, like this:

What makes the ASP.NET Animation framework compelling, however, is not that you can do things as above (after all, you have been able to do shtick like this for years in JavaScript), but that all that's required  is a bit of XML markup in your ASPX page:

<ajaxToolkit:AnimationExtender id="MyExtender"
  runat="server" TargetControlID="MyPanel">
  <Animations>
    <OnClick>
      <FadeOut Duration=".5" Fps="20" />
    </OnClick>
  </Animations>
</ajaxToolkit:AnimationExtender>

...therein lies the cool factor.

Cool, how do I do it?

I'll show you, but I'll do it with a rather simple example first so that we don't spend a great deal of time (and space) with the inconsequential.

First, you create a new ASP.NET AJAX web application using Visual Studio 2005. I won't go into the details of doing this as you already know how to do this.

Second, you add a reference to the control toolkit's main assembly to your project (if you do not have this, then you can download it and all the supporting stuff from here).

Third, register the assembly and it's namespace in your ASPX page:

Fourth, slap a button on your ASPX page:

Fifth, flip over to the code view and add the following code:

...note two things: first, I added OnClientClick event handler to the button to prevent it fom posting back to the server; second, I added a block of XML markup as an AnimationExtender (the ajaxToolkit:AnimationExtender block). Also note how I assigned the TargetControlID property of the AnimationExtender to the Button I just added moments ago.

Now, if you F5 and run the application, you'll see that - when you click the button - the button text will turn red:

...and then fade out:

What else can Animations do?

Practically anything you want. It's a framework, mind you, so it's very extensible and maleable; but the nice folks that built the framework have supplied a great deal of pre-made animations for your consumption, and you can find the list here (which includes everything from fadeouts to movement).

After following through the list of pre-made animations, you can't help but get a bit excited about the kinds of things you can do. In the next section I'll explain the nature of Animations (the mindset you need when working with them), and then in the section after that I'll explain how they work (given that we now understand JSON).

....stay tuned.  

Okay, in my last post on this topic I gave a brief overview of what JSON is and how it comes into play with your ASP.NET AJAX solution. Now I'm going to stretch out a bit and show you a few examples doing something practical with JSON data in ASP.NET AJAX. I'll be careful to explain what I'm doing along the way. By understanding this, you'll be ready to move into how Animations work in ASP.NET AJAX, and therefore be able to leverage them in your applications.

You know that JSON is a "stringified" version of an object, and you know that this stringified version is used to preserve the object across boundaries where raw, binary data transmission is not practical (or possible). However, one thing I didn't really touch on, and so I'll now explain, is exactly why someone would transmit an object to some other environment anyway. Objects are nice ways to not only pack functionality, but also state - so in the case of browser-based programming, for example, you could easily see yourself creating an object that represents the behavior of a button element, setting some state (such as color, what happens when the button is clicked, etc) and sending it down to the client. So, the reason you'd do such a thing as send an object down to the client is because that object represents state and functionality specified by you on the server; once downloaded to the client browser it can then be used to reflect that state to elements within the browser in a nice, packaged form.

Let's step back a bit and make up a quick example.

Say you have a DIV tag on your page and this DIV tag is to do something when you click it. You could set the div tag's onclick handler to run some kind of javascript:

<div id='mydiv' onclick='doSomething();"/>

We've all seen this before and it's nothing new; it's just JavaScript. However, what if you wanted some sort of variation in what the method doSomething() actually does? Perhaps it displays something a bit different depending on the user logged in, or perhaps you want something special done because it's Halloween - whatever.  Now you're in a pinch. In ASP.NET, you might go ahead and start doing more dynamic things to it through inline ASPX or through Response.Write(); basically modifying what the browser gets through the output stream (such as tweaking arguments to doSomething()). After a while, however, this gets really, really ugly to manage. What would be nicer is if an object basically represented the functionality of the DIV tag, and so on the server all you had to do was set up a couple properties (such as the text displayed to the user when he/she clicks the DIV tag) and have those properties get reflected in the client browser. In this scenario, an object would exist on the server where you can programmatically tweak properties, and then it gets sent down to the client where it actually "behaves" as script.

As you can imagine, the way the object would be sent down to the client is as a JSON-seralized object.

We saw earlier that the modern browser has capabilities, through the eval() method, to rehydrate an object out of JSON-formatted data. We also saw earlier how the ASP.NET AJAX framework provides a number of ways to wrap the eval() method to make it more robust and secure. All that's needed, then, is a way to take an object on the server and create a JSON-formatted string of data out of it so that the browser can create a version of it for itself. There is - it's called the JavaScriptSerializer.

If you had an instance of the JavaScriptSerializer in your class like this:

Then you could serialize an object with it like this:

...you can see here that I'm taking some instance of an Animation type and serializing it as a JSON string. Note that the Animation type isn't JavaScript, it's a full-blown .NET type (a real managed typed). The string returned simply represents the properties and events of the type.

If my animation had properties (like, say, the text that is displayed when I click something), then the JSON string will represent the property and the  value of that property. Anything that will rehydrate the object from that JSON string will set the property to the original value. Therefore, the object's state gets preserved as it crosses from the server to the client.

There are a number of ways to rehydrate the object using the client framework of ASP.NET AJAX so it gets reborn in the browser. A handy shortcut method for doing this is $create(). The create method will take the type it is to create as the first argument, and then a initialize properties and events on the type through JSON-formatted data. The $create() method, then, creates objects out of JSON. Once done, the newly created object will have it's initalize() method called by $create() (giving you the opportunity to attach event handlers and the like).

Therefore, say we had some JavaScript class called AnimationBehavior and it has a series of properties. On the server you set those properties and then create a JSON string out of the object. $create() can take that string, initilialize a JavaScript version of the type and then call the new AnimationBehavior object's initalize() method. From there you can attach event handlers based on the properties and events you set through JSON.

So....

1. You have a fully-qualified .NET object.
2. You can set properties on that object and have that object serialized as a JSON string.
3. The ASP.NET AJAX client framework can take that string and create a version of the managed type in JavaScript for it's own use through JSON and the $create() method.
4. The $create() method, once finished initializing the new type, will call the type's initialize() method, giving you the opportunity to do something meaningful (such as initialize your object).

Note that eval(), normally, creates an opaque object out of JSON data. eval(), used alone, will not create anything typed strongly. $create(), on the other hand, expects an already existing type in JavaScript to instantiate and initialize through the JSON data. If you're creating a valid ASP.NET AJAX client type, it will have an initialize() member method, thereby working perfectly fine with $create().

In the next section I'll walk you through exactly what an Animation is, and then we'll see how they use all of what you just learned.

I'm starting to note an interesting trend.

Okay, it's obvious that I'm a software developer and, in my opinion, a good one. I spend a great deal of time learning the details behind things and love understanding how the world works a bit under the covers. When I first went into developing software I figured that those who had made a fair amount of money on the internet were also good developers who spent their time doing very much the same thing - learning, exploring, understanding, etc. I'm actually experiencing a bit of a down-time right now as I recently recieved a nice position as a senior-level ASP.NET developer for a while with a startup company in my area (good opportunity, in my opinion); and so I'm taking some time to get more a grasp on my blog, on blog marketing, etc. Therefore, I decided I would read a few blogs, take a few notes on what I should do, and just try them out....what I found was interesting.

Probably the best site I found for advice is this one: http://www.problogger.net/archives/2007/01/11/how-to-market-your-blog-in-2007/. The guy was very logical and concise; and the advice he gives does make sense. One of the bits of advice he gave was to register yourself with various blog directories and social site networks (what these sites do is try to promote EVERYONEs blog by just signing up, and in the process gain traction themselves). However, a few of the sites he pointed me to were having serious problems (both in their esthetics and in their function); in fact, a few of the sites were downright crappy.

Top100bloggers.com immediately gave me this:

and blog-clicker.com threw up on me with this....

 

From my brief experience over at rentacoder.com I learned to pick out sites that were created by a business-weasel hiring out to some college freshman for one hundred fifty bucks. It's my guess that these sites were created in just this way. Something goes wrong with the site and the owner freaks out and tries to pull the XBOX 360 paddle out of the hands of the original programmer to fix the "issue" - and what you get is, well, what you see above.

My initial, gut-instinct here is that these sites were created in a rat-race fashion.

However, a few sites weren't bad and - in fact - were downright good. I thought BlogExplosion.com was interesting....the premise here is that you gain points by visiting other people's blogs for a period of time; apparently these points credit you for some standing in their system (I'm still new to this). Also, within a brief period of time I'm already noticing a slight number of hits coming from BlogFlux. B5Media.com looks really nice, but they appear to not be accepting new people at this moment (not sure why).

Oh well. My point behind this post is that I have to quietly chuckle to myself when a site just poops all over itself when someone is trying to join it and enhance it's community; it takes me back to a few people I use to work for/with who seemed gifted at putting themselves into the "putting out fires" department because careful, concise work seemed like a waste of time. I dunno', some of the sites might actually be good and, I'm sure, sites like MySpace.com started off similarly (in fact, when I had a MySpace.com account it seemed like the darn thing was breaking nearly every five minutes). I guess what do I know....

I'm playing around with FeedBurner (finally). I updated all of the RSS links to point to feedburner's, so if anyone has any trouble reading this blog from here on out (don't ask how you'd see this post if you were, but I'm doing my bit), please let me know.

Thanks.

I'm going to go out on a limb here because I'm going to make it well known that I don't understand the craze behind the iPhone. I can appreciate the look and appeal of it to a degree, because I can understand that technology is cool and that Apple, with their interface, makes interacting with it different (therefore "cool" in the eyes of many); but what I cannot understand is the foaming-at-the-mouth for features that have already exist in other phones (like my iMate).

For example - PopCap recently announced that they're bringing out a version of Bejeweled just for the iPhone (you can read more about it here). To me this isn't news - this is almost sad that some find it even newsworthy. How long has that game been around and how long have I been able to play it on my smart phone? To make matters worse - you have to leverage Safari as the sole platform for developing applications for the iPhone. I just recently purchased Age of Empires for my phone so that I had something to play during my transatlantic flight to Italy - can that be done on the iPhone? Well, if it's all browser-based certainly it cannot (and can you imagine the minutes charged to my phone had I done it WHILE in Europe?). I'll admit I'm not sure of the physics behind how the iPhone plays the game, it's possible (quite possible) that it exists in some sort of cache on the phone, but - still - I would really like to see the implementation of something like Age of Empires in the Safari browser on the iPhone.

Plus, what's up with no flash?

Trust me, I definitely understand and appreciate the power of Web 2.0 and the new mindsight of moving tradiational, desktop applications over to the web (for quite a while that has been the point of many posts on this blog), but to me it seems like Jobs basically cut out of the iPhone a major feature and, through his legions, turned it around to something to marvel at.

If nothing else this reminds me of the time I got into a debate regarding PPC vs. Intel with a relative of mine. Months before Apple started the Intel transition he was tossing his hands about as to how great PPC was over Intel - a month after the transition started he was telling me how great Intel was. Seriously - I don't get it!

I have an interest into going into detail over the serialization framework provided by ASP.NET AJAX. The reason - ultimately - is that I would like to start explaining how the Animation framework works in ASP.NET AJAX. However, as with any sort of understanding, there are earlier pieces that must be grasped first before you can truly understand the later pieces: the "crawl before you walk" problem. So, let's start off with the basics and, over the next couple days, we'll move our way through the serialization framework and into the Animation framework of ASP.NET AJAX. Doing so, you'll be able to really start cooking with some fascinating animations in your browser-side programming. My goal, also, is to aid you in understanding how it all works under the hood (as usual).

So, let's explore JSON.

JSON - the JavaScript Object Notation - is a "stringified" version of an object; or an object represented as human-readable text. It is valuable because the web, primarily, doesn't do well with raw, binary data....as you know, the data must be encoded so that it can be properly transmitted via the web medium (learn more). However, it is more space-savvy then various alternatives (such as XML), thereby making it more appealing to transmit large, detailed blocks of data (such as objects).

The basic idea behind JSON is that when you need to transmit some object over the web boundary, you serialize it in the JSON wire-format, make the transmission, and then deserialize it on the receiving end into the original object. The result is a clean hand-off of the object from one universe to another across the finicky web. The actual data format isn't important; though if you are interested Wikipedia has a nice overview of it here. But, suffice it to say that in JSON, you're taking some opaque object and representing it as a block of ASCII-based text.  

Why is it important?

In ASP.NET AJAX, especially, JSON is VERY important. Why? Because ASP.NET AJAX is striving, very hard, to be as strongly-typed as it can at all times for objects written in ECMA script. Objects are flittering and flying about all over the ASP.NET AJAX world and, therefore, a consistent wire-format for transmitting and working with those objects is necessary. As we will see when we start encountering the Animation framework of ASP.NET AJAX, serialization via JSON is used extensively in converting the animation XML into maleable, server-side objects that we may program against; likewise, those same objects on the server can be serialized into meaningful JavaScript objects for the client-side framework. All of this is done using JSON formatting in ASP.NET AJAX.

How does it work?

I mentioned earlier that the formatting rules of JSON isn't important - and for us, as ASP.NET AJAX programmers - it isn't. The reason is due to the fact that we rarely ever need to hand-tweak anything because formatters for JSON exist and are quite mature already, on both the client AND the server-sides. However, there is a powerful framework at work here that deserves a bit of understanding, regardless of the actual formatting rules.

At the core, the most important element required for JSON serialization within the browser itself is the eval() method. The eval() method takes a block of data, which can be either script or JSON data, and evaluates it. The "evaluation" process will do something to the text; if it's script, then it will execute it, otherwise it will go through and parse out the JSON data and return a deseralized object back to the script. There are security implications involved in this sort of process, and so you should be very cautious to leverage eval() on your own. Instead, you should use Sys.Serialization.JavaScriptSerializer as an ASP.NET AJAX developer. This type exposes two, obvious methods: serialize() and deserialize(). Under the hood, this JavaScriptSerializer object leverages eval(), but more cautiously.

So, JSON works by leveraging API frameworks that convert the formatted data to objects and back again for us.

Conclusion

In the next part of this topic I'll go over the actual process of taking objects represented in XML and creating ECMA script from them (and back again); a process that is used extensively in the Animation framework of ASP.NET AJAX to work with the animation objects declaratively.