[5 Aug 2014 | 0 Comments]
I’m very pleased to announce that my new Pluralsight course, XAML Jumpstart: Getting Started With XAML, is now live!

When you’re living in the Microsoft world, XAML is everywhere: it’s used in WPF, Silverlight, for Windows Phone & Windows Store apps. Since the release of the new Xamarin version, we can also use it to build cross-platform mobile applications. In conclusion: you should probably know XAML :-) 
[More]

.NET »

[19 Aug 2014 | 0 Comments]

One of my standard Visual Studio add-ins is XAML Styler.  This add-in auto-formats your XAML (typically on save), taking into account a bunch of options you can set to configure the add-in (attributes on a new row, take whitespace into account, et cetera). 

 

As the original version doesn’t look like it’s being maintained anymore, my colleague Nico Vermeir forked it a while ago, updated it so it also works in Visual Studio 2013, and put all of the source code on GitHub (great idea, by the way :-)).

 

I had some time left during my holidays, so I figured I’d add in a few extra options that might come in handy: auto-ordering by Grid & Canvas attached properties, and parallel processing of multiple files.  The original version processed a XAML-file one-way from beginning to end, so I had to rework this a bit to allow for easier tree manipulation.  

 

And this is where you come in :-) 

 

This blog post is a call to action: got a feature you’d like to see in XAML Styler that involves tree manipulation, well, then go to Nico’s XAML Styler repository, fork it, and add your manipulation to the processing step you’ll find in the source code.  The community will be thankful, and as an added bonus you’ll get that glowing feeling you get when helping someone out :-) 

 

Of course, you’re also welcome to simply suggest features or log a bug if you encounter one.

 

Happy coding!

.NET, Featured, General, Presentations and sessions, Silverlight, Headline, Windows 8, Windows Phone, WinRT, WPF »

[5 Aug 2014 | 0 Comments]

When I got home from a few weeks of holiday, I found a very enjoyable mail in my mailbox: I’m very pleased to announce that my new Pluralsight course, XAML Jumpstart: Getting Started With XAML, is now live! 

 

When you’re living in the Microsoft world, XAML is everywhere: it’s used in WPF, Silverlight, for Windows Phone & Windows Store apps.  Since the release of the new Xamarin version, we can also use it to build cross-platform mobile applications.  In conclusion: you should probably know XAML :-)

 

And that’s what this new course is for.  It covers XAML in a very practical, demo-driven way, so you can start building apps right away. The topics include syntax, shapes, brushes and masks, working with controls & content models, panels, trees & the layout system, right up to interacting with XAML, data binding, styling and working with resources. The course also offers an overview of how you can analyze & debug your XAML code.

 

Here’s the complete index:

  • An Introduction to XAML
  • Basic Elements, Shapes, Brushes and Masks
  • Control Basics and Interacting With Them
  • Panels and the Layout System
  • Data Binding Essentials
  • Working With ItemsControls
  • Using Resources and Styling Controls
  • Debugging and Analyzing XAML
  • Choosing the Right Tool for the Job

 

So, if you’re interested in learning XAML, check it out

 

I hope you enjoy watching it as much as I enjoyed creating it.  Happy  coding (/learning)! :-)

.NET, Featured, Headline, Windows 8, Windows Phone »

[16 Jul 2014 | 0 Comments]

More often than not, when a client asks for a mobile app he wants that mobile application to run on multiple platforms.  For the back-end, the decision isn't hard to make at all: a REST-based service layer is the way to go, oAuth2 is how you handle authorization.  The discussion focuses on the front-end: how should we build our client applications - the part of your code that will reside on phones/tablets? 

 

Without going in too much detail, there's a few ways to approach this.  The first is to build the client apps in their own languages - one codebase for iOS, one for Android, one for Windows Phone.  If you've got the resources (money + people + knowledge), this is a pretty good option - but it tends to cost a lot to build, and especially to support afterwards.  As a client, you'll essentially have to ensure you not only have the means to hire people to code in those different languages, you'll also have to ensure you can keep these people at hand to support the application once it's been published.  It's a good option, but for a lot of companies it means extra costs they want to avoid. 

 

So, from that, hybrid apps were born, and those exist in different flavours.  The idea is to find a way to share code on the client across different platforms, so the costs to build & maintain the apps go down.

 

One approach here is to use PhoneGap/Cordova.  This allows us to use HTML/JS/CSS to build an application that can then be deployed across platforms.  It results in an application that consists of a WebView that interprets your HTML, wrapped in a "native" shell, using a native bridge to access platform-specific native API's.

 

The resulting app isn't an actual native app: it's an app that runs your code in an embedded WebView.  But: it's a viable option.

 

Another way to build hybrid applications is by using Xamarin.  It allows you to use C# to write your client-side non-UI code, and you use the platform-specific UI language to build the different UI’s and hook ‘m up to your C# code.  Contrary to Phonegap apps, this does result in a natively built application for each specific platform, but it still requires some extra knowledge for developing it: you’ll have to know the platform-specific UI language.

 

I dabbled into this in the past, but to be honest, I wasn’t that impressed when I first tried Xamarin (last year).  It might have been my setup, but the developer experience was too buggy at that time for me to consider it a viable option.

 

But times change.  Recently, the Xamarin people released v3, and it included something *really* interesting: Xamarin.Forms.  This is a new to build native apps with a shared C# code base – and by using the included Form elements, you don’t need to worry about your UI anymore: when you use one of those elements, these are automatically translated to their native counterparts on the different platforms, as this screenshot illustrates:

image

 


(Just as an FYI: no, I'm not getting paid to write this blog post ;-)  These are simply my thoughts after diving into Xamarin.Forms for a few days.  I do accept free beer though, if anyone want to buy me a drink ;-))

 

Well, that’s interesting, right?  In a way, and for some apps: definitely.  But as we all know: a lot of apps have specific needs for their UI, and in most apps, you’ll quickly run into something that can’t be done with the included elements.  So, we need a way to extend these forms: a way to build our own UI elements when needed.

 

Xamarin allows two options here: the first is to combine Forms with Android/iOS/WinPhone specific UI-elements.  That brings us back to the fact that you’ll need to know the platform-specific UI language – the amount of work you’ll have to do in each platform-specific language is less than before, but, well, even if it’s just a small part, you’ll still need developers that are fluent in those languages to build & support the app.

 

The second option?  Use XAML to build your UI.  For all platforms.  And this is the part that *really* grabbed my attention: does this mean that we can now build cross-platform applications using nothing more than XAML + C#? Let’s look into this a bit more.

 

When we create a new XAML file for Xamarin Forms, the first thing you notice is the fact that the default namespace is different than what we’re used to from WinPhone/WPF/… apps:

 

image

 

From that, we can say that the the XAML processor used to interpret XAML & translate it to (un)managed object is different than the one from, say, WinPhone.  The differences go a bit further, even.  If we look at how we define a label:

 

image

 

we immediately notice those properties don’t look all that familiar.  So, it’s a different XAML dialect altogether – which makes sense.  

 

Note:  no, you can’t just copy over existing XAML code.  Just like you cannot - or should not - just copy over the HTML you use on your website to a Cordova/Phonegap app or to a Windows Store app - in fact, as said, there are quite a few differences in what's accepted by the XAML processor used by the XAML dialect Xamarin.Forms uses versus what other XAML flavours (dis)allow.   And that's a good thing.

 

This is, by the way, one of my major gripes with how languages & frameworks are marketed by their vendors and/or OSS admins - and I really do mean almost all of them.  "Use the code you know", they said.  "It will be easy", they said.  No, it's not.   We should not copy over code that's optimized for one specific framework/language flavour on one specific platform to another platform.   We shouldn’t even *want* to be able to do that.

 

So, no, it’s not the XAML dialect most of us know from one of the other platforms.  But I’ve got to say I’m pretty impressed.  Even though it’s a different dialect, writing cross-platform XAML in the new dialect feels very familiar. Data Binding support is included, and I can even use my favourite MVVM framework: MVVM Light.


So: what you CAN use is your existing knowledge.  And that's a lot.   I'd even go as far as to say that this will result in better apps than were you to use something like PhoneGap; a Xamarin application results in a natively built app, while a Phonegap application results in a WebView-wrapped-in-an-app-container. 

 

Would I use this for building cross-platform apps at the moment?  Difficult question. This is obviously a v1 product, and a lot is missing - a visual designer would be nice, for example.  Blend support would be even better.  But I like the direction it's heading, so I’d probably give it a try.

 

In essence, if you're a Microsoft developer, you can now build cross-platform mobile applications using your existing XAML & C# knowledge, and it will result in natively-built apps for those platforms. 

 

That's a pretty huge deal.

.NET, Windows 8, WinRT, Presentations and sessions, General »

[6 Jun 2014 | 0 Comments]

I just finished delivering my Given to Fly session at NDC 2014 Oslo – thanks to all of you who stayed ‘till the last session on the last day of the conference, I really appreciate it :-)

 

Session & slides are on my OneDrive, and for those who weren’t there, this is a short description of what that session was all about:

 

One of the most important aspects of a Windows Store app is its performance: an end-user will simply not keep on using your app if (s)he has to wait too long to complete the task (s)he’s using it for – after all, for most apps, there will be loads of alternatives. For Windows 8.1 XAML apps, quite a few things changed concerning performance when you compare it to Windows 8. In this session we’ll cover those topics as well as learn about performing tasks in parallel, offloading tasks, keeping your UI thread responsive, data and UI virtualization, overdraw & analyzing performance… In short: if you’re serious about developing a Windows Store app and you want to learn how to ensure you keep it fast & fluid, you’ll want to attend this session.

 

Happy coding! :-)

.NET, Featured, General, Presentations and sessions, Headline, Windows 8, WinRT »

[29 May 2014 | 0 Comments]

Today, I delivered a session at Techorama, a new (and good – congrats to Gill, Kevin, Pieter and everyone who made this happen!) Belgian conference.  The session was about validation & business rules for Windows Store apps.

 

LOB applications for Windows tablets are slowly but surely becoming more prevalent – but there’s one big gaping hole: business apps require validation and business rules, and those rules are often way more complicated than what you can handle with data annotations.  And, regardless of that, there’s really very little support for validation in Windows Store apps.  If you’re used to, say, WPF, you’re used to binding properties like ValidatesOnExceptions, ValidatesOnDataErrorInfoChanged, … which tie in nicely with the UI.  Not so in Windows Store apps, not even when you use data annotations.

 

So validation for LOB Windows Store apps is a 3-part story: you need a component/engine that allows you to define complex business rules, and that component must be available on both client and server.  You need a way to get your property setters to nicely interact with that business rule component.  And you need a way to visualize those errors.

 

So, rather than explaining how to write a MinLength, RegEx, async, … validator, I wanted to take another approach: the session was aimed at building a business rule engine that ties in nicely with Windows Store apps.

 

I promised everyone the code & slidedeck, so: here it is! :-)  I hope you enjoy it!

 

PS: @M3rken (jokingly, I think ;-)) asked me if I would publish this as a NuGet package. I’m not going to do that, for one simple reason: what I showed in the session was a skeleton component that still requires *a lot* of work & extensions before I would call it a true “business rule engine” – the code should be considered as something to start building from, not something to use in a production environment.  For that, it should include way more validation options, should take property chains into account, handle expressions in RuleBuilder extensions, allow conditional rules, allow multiple RuleSets, inheritance, influencing properties, more support for data binding types in the behavior, more actions, etc, etc.  So, in short, I don’t think it’s good enough to qualify as a useful NuGet package.  But regardless of that, it was very nice to read that question. :-)

 

Oh, and if you need more info on such a component, I’m working on a thing or two, so drop me a line ;-)

.NET, Featured, General, Headline »

[20 May 2014 | 0 Comments]

I just received word the new edition of NDC Magazine (an IT mag, published 4 times a year) is out – and I’m very happy to have been asked to write an article for this edition. 

 

image

 

The article I wrote is on fluent API’s, detailing what they are and how you can start building them. 

 

Next to that article, this edition includes articles on using Prism in Windows Store Apps, Modern Web Front-End Architecture, F# Type Inference and many more.  So what are you waiting for?  Go read it :-)

.NET, Featured, General, Headline, Windows 8 »

[24 Apr 2014 | 0 Comments]

Almost every Visual Studio solution work on these days has one or more ASP .NET MVC / ASP .NET Web API projects, most of which require a full IIS, often hosted locally on my own pc. 

 

To get this to work, I have to run my Visual Studio in administrator mode.  By default, even though you might be admin on your own machine, Visual Studio doesn’t start in administrator mode – which makes for a lot of cursing at my screen when I accidentally open such a solution for the n-th time in normal mode. 

 

But there’s a way to make Visual Studio auto-start in administrator mode – thought I’d share it on my blog after I tweeted it yesterday, b/c surely I won’t be the only one who experiences this annoyance :-)

 

It’s pretty simple actually: you have to associate some compatibility mode changes with devenv.exe.  Here’s how:

  • First, locate devenv.exe (if you’re using VS2013 on Windows 8.1, you’ll find it in folder C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE)
  • Right-click it, and choose Troubleshoot compatibility
  • Next, click on Troubleshoot program, and check This program requires additional permissions.  Click Next
  • The compatibility wizard will ask to test the program.  Do this, and afterwards, click Next
  • Save the settings, and close the compatibility wizard.

 

You might want to apply the same procedure to vslauncher.exe as well (vslauncher.exe is located in C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv).

 

And there we go, that’s all there is to it. 

 

Happy coding! :-)