WUX202 - Building Rich Internet Applications Using Silverlight 2
I've fallen a bit behind on the Silverlight front, so it's great to take this opportunity to catch up a bit. This was a fairly low-level session to get you up and running, but without skipping over the details.
We were taken through setting up a Silverlight application, creating and (fairly radically) styling some controls, retrieving data from a web service, creating business objects from that data and then displaying it.
I can't think there's many times I'd want a slowly rotating text box whose background is playing one video, whilst the interior of each (multi-alphabet) character contains part of another video, but it's nice to know that you can.
One thing I was really pleased to see was quite how feasible it was to develop Silverlight by typing the xaml directly. I've only seen it generated in blend before, but I prefer the feel of the fine control you get from typing it yourself - I generate all my html that way for precisely the same reason. I suspected it would be too onerous to be practical, but was glad to see that it really wasn't.
Data access in Silverlight is really easy: it all works by calling web services, and using .NET's XDocument and XElement classes, converting the XML text to objects is a doddle. Web services can be called from the same site as where the Silverlight is being hosted, or, by negotiating a SilverLight policy file, from an external domain.
Creating reusable controls in Silverlight is just as easy as in ASP.NET, and data can be passed to them just by setting their DataContext property. In many cases that's all you have to do in the code behind, and the xaml will pick up the data and display it accordingly.
I deliberately avoided Silverlight 1, and I'm glad I did. Silverlight 2 has dozens more controls available to you in its core libraries, and a whole bunch more - mostly the more advanced ones such a DataGrids - that can be included by namespace. The neat thing is that if you don't use those namespaces, they aren't included in the the download, giving less of an impact on your user. Microsoft plan to release more control toolkits in future.
The argument they gave us for the lack of controls in version 1 was that you should design your own; it's nice that those of us with little artistic talent can throw the standard controls into our applications, but also that they're all completely re-stylable by applying templates.
Databinding works a lot like in ASP.NET, but with the additional power of 2-way binding, whereby data entered by the user automatically immediately changes the properties on your objects.
All in all, I'm looking forward to getting involved in some Silverlight development. Much of what I know of ASP.NET will be transferrable, but we'll also be spared the pain of trying to get a decent layout using css.
ARC205 - How IT will change in the next 10 years and why you should care
I thought the content of this talk would be similar to talks I've seen at the last two TechEds: long term projections about where software development will be going in the next decade. But no - one tenth of "the next decade" has already past since last year; nearly a quarter since the year before.
IT is undoubtedly a fast-moving industry, and I've often wondered what my job will look like when I'm 60; or even if I'll still have one. How will I keep up with the industry as it moves? How can I know if it's even possible when there aren't any 60-year-old software developers yet?
The key really is keep at the bleeding edge. IBM crashed and burned because they had a cash cow (the mainframe), and made the mistake of treating it as a sacred cow. The technology we rely on today can (and will) be obsolete soon after you get comfortable with it.
An interesting graph (I'll link to it when the slides from the session are published) showed the relationship between cost, risk, availibility and value as technology moves through the phases of being a future technology, emerging technology, widely applied and obsolete. We're running on a treadmill and you never want to get too close to the back. I think this is something we do well at Compsoft: we're always looking ahead and keeping abreast of what the next big thing will be, adopting it right as soon as it becomes available.
We covered quite a bit of how we'll not only treat software as a service, but treat hardware as a service too. With more and more processing being offloaded to the cloud, we don't expect most companies to have their own server room a few years from now. The car/ taxi analogy works well: if you're buying a car, you care about the make, the model, the colour, the tyres, etc.; if you're catching a cab you only care about how clean it is, how dodgy the driver looks, and how much they're going to charge you.
Expect to see some legislation coming in for IT services soon though - we're pretty much the only public service at the moment that isn't regulated; and also probably the fastest-growing one.
Some interesting international statistics and predictions came out. Nigeria's most profitable export is oil; its second is internet scams. Every year the US produces 100,000 new software engineers; China produces 500,000 (and that's if you only count the ones who can speak English). Iceland's data centre industry will be booming shortly: IT currently produces as much carbon as aviation and we need to radically cut back on our power consumption. We need cold, remote places with cheap electricity; Iceland has this, along with the fattest of pipes to America and Europe.
WUX307 - Developing Accessible Web Experiences With Silverlight
Like last year, the seminar on accessibility was poorly-attended, and with a lot people dropping out before the session ended. I guess it's just not a sexy topic, and unless you have a customer who particularly cares about it, you're likely to have a zero budget to implement any accessibility whatsoever. Ah well.
We covered some basic principles of making websites accessible. This applies to everything, not just Silverlight. The WCAG guidelines give some useful pointers about accessibility: everything should be perceivable (with low, colour-blind or no vision); everything should be operable (the keyboard should be the only tool you need); everything should be understandable (clear, readable, predictable layouts, and forgiving of mistakes such as miss-clicks); everything should be robust (we should assume as little as possible about the technology used by the end user.
We got to see a little more of ARIA (Accessible Rich Internet Applications) in this session. This adds a whole bunch of attributes to standard html that is respected by assisted technology (AT) for people with disabilities. Thsi basically lets you write less semantic html to produce all the nice effects your fully-able users want, but add the attributes that ensures it's still accessible.
For example, the tabindex attribute is now available on all elements, with the addtional support of tabindex="0" to let the browser decide the order, and tabindex as a negative value for items that shouldn't be accessible via the keyboard but that can be set programatically.
Also the role attribute lets you give a lot of information about what an html element is actually for - you can give your div a role of banner, navigation, main, etc., for example.
Setting live regions in your html lets AT know that these are parts of the page that will change dynamically. You get some pretty fine control over how sensitive it is to change, and even how the AT should announce that the region has changed (the settings are "polite", "assertive" and "rude").
I expected accessibility in Silverlight to be more painful that in html, but actually it opens a whole of new opportunities. As Silverlight is so media-rich, you can easily add your own subtitles to videos, as well as sign language options. Users can change the size of captions, turn additional descriptions on and off, etc. You really get to make the experience for disabled users as exciting and as varied as it is for everyone else.
The AutomationProperties class lets you add attributes such as name, help text, accelerator keys, etc. to pretty much any element, for use by AT devices.
Another nice feature is that Silverlight can detect that the user has set their browser to High Contrast mode, meaning we can automatically switch the Silverlight component to use a more clearly visible theme.
Media files support media markers that can trigger events code-side, so you can handle them however you want. We saw a demo of extended descriptions, where (if the user had turned them on) the video would pause, provide an audio description of what was happening, and then continue from where it left off.
There's still room for improvement: Silverlight doesn't yet support two videos playing in sync, so if the user's on a slow connection the sign language may get out of sync with the main video. However, as you can change the video stream being played dynamically, it's feasible to swap between one video with signing and one without, seamlessly whilst the video's playing.
The Silverlight demo (which showcases a whole bunch of best practices for accessibility) is available on CodePlex - look for AMP (Accessible Media Player).
WUX305 - ASP.NET MVC Practices
I've been resolutely avoiding MVC for the last year, waiting for it to settle down, iron some of its problems out, and then decide if I like it or not.
Well, it's done a fair bit of ironing, but I'm not entirely convinced that I like what I see.
On the one hand, I just LOVE the testability of the MVC paradigm. In this session we saw how tidily it integrates with Inversion Of Control and purity of the code that you get as a result.
On the downside, the html you write has bits of code littered through it, which is proper filthy dirty as far as I'm concerned. Hadi's argument in this session was that your view should have no logic in it, so the code in your page is going to minimal, so that little bit of dirt is just fine. Hmm... I don't know...
What we got to see today showed us a whole lot of how to implement a nice-looking, AJAX enabled, error-handling, fully testable MVC application. I'd like to have one of those, but getting there would just be such a hell of a lot of work.
The trouble is that we've invested a whole lot of effort ensuring that developing applications at Compsoft takes as little effort as possible. To edit a record, you barely have to write more than the properties you want to edit, and you get all the right controls for the datatypes, full error-checking, etc. right out of the box. Searching, listing, pageable repeaters, building up complex records without saving anything to the database - we can do it all in minutes. Unfortunately we do it all using the technology we have available: we use web forms, web controls, update panels, the view state - everything you lose if you switch to MVC.
So switching to MVC would be great because our code would be cleaner, purer, (in theory) more maintainable, more swappable; the problem is that we'd have to throw away most of the last year or two's investment in our reusable web controls.
Though today I saw a vision of how I would like to rewrite our reusable code libraries to work on MVC, it's not a few tweaks to upgrade it, but rather a total re-write.
Roy, can I have a while to do this? I reckon about three or four months solid work should be enough to get us back to a point indistinguishable from where we now, except for a warmer glow within. Thanks.
WUX306 - Silverlight 2 Security End-to-End
Silverlight has security built in at a pretty fundamental level. All Silverlight applications are sandboxed and so can't touch anything else on the client machine - not even other Silverlight applications.
However, the Silverlight plugin that the user has installed does have acces to their hard disk. Not all of it - it can store persistent data up to a limited volume. By default it's 1MB per site, but you can cause the application to request more storage capacity from the user. The store can be unique to each Silverlight app, or shared by the applications on a single site if you prefer.
This data can be accessed via the IsolatedStorage class. At its simplest it contains a dictionary of name value pairs, though you can also use it as a virtual file store where you can create folders and files of any kind.
Whenever a Silverlight application needs some data from the outside world, it's going to be getting that via web services. The web services you call are limited: you can always call webservices on the same point of origin as the original application (to the domain, sub domain, port and protocol).
That's sufficient for when you're developing your own self-contained Silverlight system, but you can also expose public services to other Silverlight applications. Out of the box, cross-domain web service calls aren't allowed. However, the server can opt in by having a file called clientaccesspolicy.xml in its route directory. This contains information about which Silverlight applications can call the web service, by domain name, with wildcards. For ease of upgrade, Silverlight also supports the existing Flash version of this file.
You have to make sure you disable any caching on this file, and you can't use any redirects.
As with web sites, these web services are susceptible to cross-site request forgery attacks, so you need to include a token both in the cookies for the site and the request itself. Also, if you have a service that's used both by your local application and also exposed publically, it's best to keep the service and the application in separate subdomains, so that cookies from your site don't inadvertently get included in requests from other Silverlight applications in the same browser session.
Labels: .NET, asp.net, business objects, Compsoft, data access, Rich Internet Applications, Silverlight, TechEd 2008, Tim Jeanes, web services, xaml, xdocument, xelement
