On my way home from ASP.NET connections I converted the Anthem Chat Example run with ATLAS using low level Web Service functionality along with script code. I've posted this demo along with the rest of the ASP.NET Connections demos here:
If nobody else is on when you're there, you have to open another window to have a conversation with yourself <g>. Imagine that - you can be Johnny the Cat!
I mentioned this before, a Chat application probably isn't the best example of what you should use AJAX technology for, because if this app were to get really busy it would really be a huge draw on server resources. AJAX is really a pull technology so it has to poll the server in order to be able to get update information of any kind, so this example pings the server every few seconds to see if there are updated messages for the client to display in the chat window. But I think it's kind of a fun example that demonstrates how the technology works really well because it relies on common AJAX elements such as polling and managing server driven messages.
It's interesting that there really isn't a lot of code to this. The client code makes the majority of it and most of that is actually a handful of utility functions (like a Shadow behavior function and the error display mechanism. The ASPX page has no code at all associated with it – it only acts as the HTML container. In fact this page could have been a .HTM page. The server side logic is handled via the ChatService.asmx page which talks to a business object to read and write messages to the database. The logic there isn't rocket science obviously – most of the methods actually return small HTML fragments to minimize the work that needs to be done on the client – the client picks up the Web Service result and simply assigns the snippets into the appropriate tags on the page. HTML is a great way to pass data back as long as data is not too large. In this case the data is things like the new messages, the User List with Activity status, and the drop down list of active chats. All of these are small result sets that get returned and can easily passed back from the server as HTML. In that respect the Web Service is not a pure DataService, but it becomes part of the UI layer as well (like a typical ASPX page).
The end result in all of this is that this sample has surprisingly little code and I managed to get all of this to run on one short battery charge on my flight home <g>, which isn't bad at all.
But remember that building applications like this, that require client and server side logic are essentially distributed applications and regardless of which technology you use to debug this stuff it will take significantly longer than the equivalent server only technology. It also requires more discipline than standard ASP.NET pages because you have to make sure your service code on the server works before you can even think about trying to call this stuff from the client. Debugging too – even server side – is much more challenging. IN this scenario for example I have to deal with timers firing requests every 5 seconds. Have you ever tried to debug ASP.NET or Web Service requests with multiple incoming hits? <g> So you get to turn off the timers and then set up your client code and debug one hit at a time, and then when that works turn on the timers again. This sounds pretty obvious now as I write this but while you're in the middle of a debug cycle there are a lot of parts in the air to remember and keep track of. It's doable but as with anything – it takes some time getting used to and find the common development patterns that occur over and over again. The same sort of issues popped up with the Progress Bar/Long Running Request sample also posted with the samples.
Anyway – that's a lot of talk about something fairly straight forward. Go check it out and poke around. I'm sure somebody will break it <g>…
The code for all the samples can be found here:
Other Posts you might also like