[17 Dec 2014 | 0 Comments]
I’ve pushed a new version of JsonPatch for .NET to NuGet. This new version includes a bunch of bug changes, but the most notable addition is support for deeply nested objects. JsonPatch now allows you to patch properties that are in nested objects, or in-between nested objects / object trees.  
[More]

.NET, Featured, GitHub, Headline, WebAPI »

[17 Dec 2014 | 0 Comments]

I’ve pushed a new version of JsonPatch for .NET to NuGet.  If you’re already using it, a simple update from the NuGet dialog will do. 

 

This new version includes a bunch of bug changes, but the most notable addition is support for deeply nested objects.  JsonPatch now allows you to patch properties that are in nested objects, or in-between nested objects / object trees. 

 

This allows scenarios as such:

 

// replace StringProperty in nested object
patchDoc.Replace<string>(o => o.NestedObject.StringProperty, "B");

// copy StringProperty value from root to nested object
patchDoc.Copy<string>(o => o.StringProperty, o => o.NestedObject.StringProperty);

// Move integer value from array in nested object (position 0) to IntegerProperty at root
patchDoc.Move<int>(o => o.NestedObject.IntegerList, 0, o => o.IntegerProperty);

 

 

You can find the new version at NuGet, and you’re always free to look into the source code, log issues or contribute at my GitHub repository.

 

Happy coding! :)

.NET, Featured, General, Headline, GitHub, WebAPI »

[5 Nov 2014 | 0 Comments]

I’ve been working on my next Pluralsight course the last few weeks.  At a certain moment I needed support for JSON Patch (RFC 6902), to allow partial REST-ful updates (HttpPatch) with Web API. 

 

That’s not supported out of the box, so I kinda had to roll out my own implementation.  I choose to open source that, and publish it on NuGet.

 

It’s still early days & there’s work to be done, but all the basics are there.  Any comments are much appreciated, and issues can of course be reported on GitHub

 

Here’s a bit more detail:

 

“JSON Patch (https://tools.ietf.org/html/rfc6902) defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

 

One of the things this can be used for is partial updates for REST-ful API's, or, to quote the IETF: "This format is also potentially useful in other cases in which it is necessary to make partial updates to a JSON document or to a data structure that has similar constraints (i.e., they can be serialized as an object or an array using the JSON grammar)."

 

That's what this package is all about. Web API supports the HttpPatch method, but there's currently no implementation of the JsonPatchDocument in .NET, making it hard to pass in a set of changes that have to be applied - especially if you're working cross-platform and standardization of your API is essential.”

 

For examples on how to use this, check my GitHub repository

 

Hope you like it! :-)

.NET, Featured, General, Headline »

[3 Oct 2014 | 0 Comments]

Over the past years, a lot has been said and thought about XAML.  At a certain time, there were even questions about whether or not it would still be worth investing your time in. 

 

Currently, its future looks very bright indeed.  I thought it’d be a good idea to create an overview of how it all started, what happened to it over the last years and what you can do with it today.  In short: the history & future of XAML (hint: we went from “meh” to “ok, looks good”, to “oh no, it’s dead” to “we can target almost every platform with it” :-)).

 

If you’re interested, check out my blogpost at Pluralsight’s blog: The Future of XAML

 

Enjoy!

.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! :-)