Tag: XAML
I got into a longish, public discussion last night about XAML versus the HTML/CSS stack last night. I think they both have merit and pros and cons but it made me decide to add a short series of posts that highlight some of the CSS things that surprised me most (like my JavaScript for the C# Guy posts - and yes, more of those are coming too).
The first topic I am covering is some subtleties of the selector syntax. CSS selectors allow you to pick children, descendants and adjacent siblings. I found that I used descendant selector quite a lot:
#main h1 /* descendant */
{
color: Red;
}
This syntax effectively says, any h1 inside an element named "main". I see people assume this actually means, *directly* inside the "main" element. So if you had some HTML like this, all h1's inside "main" would be colored red:
<!DOCTYPE html>
<html>
<body>
<h1>Top</h1>
<section id="main">
<h1>Main Level</h1>
<section id="article">
<h1>Second Level</h1>
<p>Yup</p>
</section>
</section>
</body>
</html>
Note that it applies to all the descendants. But but if you did want just the h1's directly inside (or...ahem a child) of "main"? That's child selector syntax:
#main > h1 /* child */
{
font-size: 24px;
}
Then only the h1 containing "Main Level" will have the rule applied. I've seem some CSS with tons of "!important" to override the descendant syntax because they didn't seem to know about child selector.
The last one is the adjacent sibling selector. This selector looks for elements that are directly next to each other (or...ahem...adjacent):
h1 + p /* adjacent siblings */
{
border-bottom: black 2px solid;
}
In this case, the p (not the h1) will have a border under it. The other h1's will be left unmolested. Here's a complete example if you want to play:
"If you're not careful, you just mind learn something..."
So I've done it again. I survived another 30 minutes with Woody and Keith. Whew. We had a good conversation about the current state of Web Development and the future of XAML development.
I also got to discuss fried foods and make fun of Keith. Couldn't have been a better time. Go listen now:
A lot has been made since a report from Microsoft late last week (http://shawnw.me/HPEh0R) that seemed to say that Silverlight on the phone was going away in Windows Phone 8 (Apollo). I liked a lot of what this article had to say (from e-week):
http://shawnw.me/IwMgR2
So it got me thinking that much of the Silverlight community would be jumping out of windows (lower case and not TM) this week due to the news. But of course, if that's the case for you, I'd urge you not to panic. Why? Let me tell you.
CAVEAT: I am guessing and have no inside knowledge on what Windows Phone 8 is going to do. Really!
Silverlight and Me
I came into Silverlight because of my prior work with WPF. But it's more complicated than that. I came to WPF at a time when I was primarily known as a database guy (my old moniker was "The ADO Guy"). So why would I care about WPF? Data binding.
I am not a UI/UX guy. I can barely match my own socks. But I came to XAML because I saw the potential of building apps using a smart markup language that has the possibility of a real data binding framework (unlike MFC, VB5/6, WinForms, ASP.NET WebForms before it).
I got into Silverlight because I lucked into being there at the ground floor (I taught a WPF/E course at Microsoft to MS employees and partners before it was publically named). But even in the early days of XAML + JS, I saw the potential of building apps (not sites) with XAML. The fact that Silverlight was originally to build them in the browser was tangential. In fact, I liked Silverlight (v2 and beyond especially) because it learned from the lessons of WPF (which in my opinion is over engineered somewhat) and simplified the XAML so that it was consumable in a short period. The lack of features like Triggers and a simplified text stack meant that people could get up to speed fairly quickly.
Windows Phone 8 and XAML
What the Microsoft folks said was that Windows Phone 8 development would be much more like Windows 8 XAML development. That meant that Windows Phone 8 would probably have the underpinnings of WinRT. Should anyone panic? Nope. Here is why.
The WinRT XAML stack is based on Silverlight 4. What losing Silverlight does is say that the XAML (and data binding stacks) are going to be unmanaged. That's a good thing. In Silverlight (especially on the phone) the managed part of the XAML stack (data binding et al.) got in the way of a great touch experience. In Mango, the Windows Phone team built several ways of keeping the experience smooth by doing a lot of tricks, but it is still pretty easy to screw it up as a developer. WinRT works differently. The entire XAML stack is in unmanaged code and the entire WinRT framework is built with async in mind. It makes it easier to build fluid, touch-enabled applications (or it should).
The other benefit is that it brings together the Metro-style application development on tablets and the phone. This is a big win for developers. This is likely not going to result in a single app working on both devices, but it should allow many of the assets to be more sharable. We have no details or promises yet, but if some of the features of WinRT come to the phone, we're all in luck. I am especially looking forward to Contracts.
WinRT XAML Development
I've been digging into the Windows 8 XAML stack and as of the Consumer Preview I am really enjoying the experience. The Consumer Preview build is pretty close to Silverlight's implementation IMO. There are likely some missing pieces, but all the big pieces are there. Adding to that, the great Visual Studio 11 XAML editing experience (powered by Blend) and I think you'll find the development experience is really good right now.
If you're a Windows Phone developer already, the experience of developing for Windows 8 (and Windows Phone 8 probably) will be pretty similar. App.xaml holds the application level events. Navigation to individual XAML files and support for a back-stack. Adding to the benefits here are things like Live storing of settings in the cloud (instead of inventing this yourself) as well as smoother touch APIs mean that the transition to WinRT should be smooth for Windows Phone developers.
If you're a WPF or Silverlight developer, there are pieces to learn (like Navigation and touch) but the XAML design experience should very familiar. If you're not digging into WinRT yet, it's time to dip your toes into the water!
I saw a tip by Tim Heuer on a StackOverflow question about how to show binding errors in the Output window of managed WinRT (e.g. Metro-style) XAML projects. Tim mentioned that:
You get this automatically for C++ applications and for managed applications you have to turn on unmanaged debugging to see them.
Since I had a hard time finding it, I thought I'd drop a quick image to help you find it. You have to go to your project properties and look at the Debug tab:
With this, you get the tried and true binding failures that you might already be used to in Silverlight or WPF. Wahoo!
If you're a XAML developer and have proudly stated that you hand-code all your markup, it’s time to learn how to be more productive. I’ve authored a new course for PluralSight. If you have a subscription, you can view it my new “Blend for Developers” course now:
Hope you enjoy the course!
If you are in the Washington, DC area (or are close enough to fly), I am coming to teach two courses just after Thanksgiving.
The Silverlight Tour
The first is my newly revamped Silverlight Tour course that has been updated for Silverlight 5. This three-day course includes information on how to build line-of-business applications using Silverlight. Topics include:
- Designing with XAML
- Data Binding
- Using MVVM
- Unit Testing with Silverlight
- Accessing Services with Silverlight
If you’re trying to get up to speed with the latest version of Silverlight, or are new to XAML-based development – this is the course for you. Free with every attendance to the Silverlight Tour are several key tools:
If you signup before November 2nd, you get the early-bird pricing of $1,695 for the course! You can register for the event being held on Nov 30-Dec 2nd here:
https://agilitrain.com/Workshop/EventInfo/267
If you would like an outline of the course, get it here!
Web Development for XAML Developers
In addition, I am debuting a brand new course called “Web Development for XAML Developers”. In this two-day course I help XAML developers take their design, data binding and MVVM knowledge and apply it to client-side web development. This course will cover
- Comparing HTML5 and XAML
- JavaScript and Managed Code
- Making Sense of HTML5 and CSS3
- Understanding jQuery
- JavaScript Basics including Object Oriented JavaScript and using JSON
- Working with Services
- Implementing MVVM on the Web with KnockoutJS
Since this is our first holding of this course, we’re introducing a special pricing for this and only this event of $1,295 ($200 off). If you register before Halloween, you can get an additional $300 off (for a final price of $995)! You can register for November 28-29th event for this special price here:
https://agilitrain.com/Workshop/EventInfo/275
You can get an outline of the course here.
At the suggestion of Tim Heuer this week, I took a break from writing my Windows Phone 7 book to delve into HTML5 a bit. I wanted to see what was different and how it would possibly impact Rich Internet Applications (RIA).
I did a couple of HTML5 tutorials which include the new tags that I think will be really cool (like <nav/>, <article/>, etc.) for traditional web design. I think the <datagrid /> and <datatemplate /> tags are interesting but unsure about how they'll be implemented. I also very interested in the local storage story, but it feels a long way from full implementation. But I don't want to talk about the entire HTML5 stack as I am just scratching the surface.
My real goal was to look at the <canvas /> element as that's what I get asked about a lot when compared with Silverlight. In looking at it I was surprised. It seems that the only way to actually draw on the canvas is to use JavaScript. While this is useful for interactive drawing and that sort of application it leaves me a little bewildered. When I asked about this on Twitter, I got a couple of answers like "just use SVG". But SVG is another disruptive technology thrown into the mix. Browsers have to support it. I had expected that HTML5 was going to formalize the SVG support and make that the markup for the canvas. But it doesn't look like that happened. Maybe its me but if its not part of HTML5, then its another thing for the browser guys to agree on. It starts to feel hobbled together for me. Another answer I got was that markup for Canvas didn't matter. Canvas is for drawing and its just not necessary. But I will totally agree that I am viewing it from a XAML lens.
But for me, Markup matters. Without markup, it would be very difficult to build tools for the canvas. But this gets at a very heart of why I like XAML. Let's start a long time ago. As we would design user interfaces and we the designs would take different forms (including binary files, generated code, etc.) The problem with this was that the designs were not easy to edit. More importantly was that the separation of business logic was particularly difficult. It became too simple to add and glue business logic to the user interfaces which of course makes it very difficult to test and extend existing systems. The typical spaghetti code problem.
As I've discussed before, I think there is a benefit of markup is that separation. But keeping the user interface design (look, feel, data binding, etc.) in markup, it encourages business logic to be separate from the user interface. Declarative user interfaces are a key to simplifying how we're building applications.
Other basic idea here that is powerful in Silverlight is that the markup (e.g. XAML) represents the initial object graph that makes up the user interface. It is very common to change this as the application runs (in response to user input or other changes). This means we can build great tools to create the original look and feel and use code to make the application come alive and change the object graph as necessary. Again, on Twitter I was cautioned against changing it too much using JavaScript. A weakness in my eyes.
That's where I thought HTML5 was going to be doing great things. But at this point it feels like HTML5 is going to rely far too heavily on JavaScript (or any code for that matter) instead of allowing us to do more with design tools. In addition, I wish they had integrated SVG (or something similar) as a drawing/animation solution to be closer to a real, rich platform. Instead, HTML5 feels like another 1/2 measure. But that's my opinion with my prejudices...I am sure I'll get an earful in reply ;)
Url: http://www.dotnetrocks.com/default.aspx?ShowNum...
Before I left for Europe, I had a chance to sit down with Richard and Carl and espouse my views on views. Specifically we discussed how the separation of UIs (in declarative UI's like XAML and JavaScript templating) may help developers know specifically when they are in or out of the user interface part of their project. Hopefully this will make it easier to keep our code from getting tangled. Watch out for the bad pizza/spagetti code reference...
Url: http://blogs.msdn.com/mswanson/archive/2009/01/...
Mike Swanson has updated his excellent plugin to address some issues with the output to make the XAML smaller as well as fix some issues with the way that PathGeometries are created that makes them more Blend friendly. In case you haven't been watching closely (and I wasn't), the plugin now supports export of Silverlight XAML which means that Expression Design isn't the only way to get Illustrator files to Silverlight XAML!
I've been digging into some of the open source and 3rd party controls that are becoming available for Silverlight 2. While running into some odd issues with some of them it occurred to me that there are some design guidelines that haven't been well communicated. Back in the early days of WPF I learned (though exactly where is unclear) that every control should support an empty constructor and that all properties (e.g. XAML Attributes) should have a default value. I knew this to be true but I couldn't document where it came from.
So as usual when I am stuck, I contacted Chris Sells as he was my mentor in early XAML usage. He was at MSDN at the time gathering content and helped me get the Data Binding articles as well into the Software Design Review for WPF (then Avalon). If anyone could help me figure out where I learned this, he'd know. He reminded me of the language they use internally: "Create-Set-Use". Essentially this means that the design pattern for controls is that they should work without requiring any properties:
<Grid ...>
<Rectangle />
</Grid>
You can see that the Rectangle doesn't require any properties to be valid. Of course this Rectangle has no fill brush and no stroke brush which means it will likely not be visible. But that's OK because it is valid XAML and doesn't break. The XAML for a control doesn't have to read the mind of the user, but should behave (e.g. not throw exceptions). One of the most egregious was a control that threw an exception if I failed to set the Width and Height. Worse yet, when it did throw these exceptions, it didn't tell me what *all* the properties I needed therefore it was painful to use. Width and Height are particularly problematic in this way in that by not defaulting to "Auto", showing the control in a non-Canvas container meant I needed to set "Auto" to the values which is what they should *always* be defaulted to.
Create-Set-Use happens during parsing of the XAML. This comes back to thinking of XAML as a serialization format for in-memory objects. XAML is simply a way to define what the structure of a particular document should be when its de-serialized. If you keep in mind that an Element becomes an object construction and that properties become SetValue calls, it makes it fairly clear what is happening during the parsing of the XAML itself.
As you write your own Silverlight or WPF classes that you expect to be used in XAML (this includes controls but also may be types that can be created as resources), try to keep these design ideas in mind. It will make life easier for your users.
