XAML or JavaFx?

This a quick, subjective, unauthorative and very non-scientific comparison of building applications with XAML and with JavaFx. The comparison is based on my personal experience working with each. On the XAML side this means WPF and Win8 store apps. On the JavaFx side this means a Windows 7 application.

JavaFx
JavaFx is touted by Oracle (and Sun back in the day) as new and modern way to build UIs. It's focused on supporting the flexibility and graphical niceness that modern UIs demand. JavaFx can run in and out of browser, and on various OSs.

My experience with JavaFx is building a good looking and quite modern desktop application targeting only Windows 7. We opted for writting the view code in ScalaFx, a declarative JavaFx DSL in Scala. This works fine: The application looks good, performs fine, and the code base is pretty clean. But there are few things bothering me:

• The UI code is just not as declarative as I would have liked. In general we've found that the built-in controls do not suit our needs, so most of the UI is build from .pngs, that have mouse events attached to them. These events change the .pngs around for hover, clicked and so on. While this works just fine, it means that there is more logic in the views than I'd have liked.
• In part as a consequence of the above, it's hard to create something like a XAML datatemplate and then bind the data into it. Again this results in more imperative logic in the views.

The things I really like are:

• The fact that we can use Scala in the views really cuts down on the amount of noise in the view code, compared to Java counterparts, in my opinion. For instance attaching the mouse event handlers is a lot easier with a language where functions are first class citizens.
• It's fairly easy to run the view code in headless mode from tests. This enables a decent albeit slightly slow TDD workflow for the view code.

XAML

XAML is used in a range of Microsofts UI technologies including WPF and the Win8 store app (formerly Metro) and Silverlight. The XAML UI frameworks are also focused on supporting the needs of moderns UIs, and also runs both in and out of browser.

My experience with XAML is from WPF and Win8 store apps, where we've followed the MVVM approach without any particular framework, but with some homegrown conventions inspired by Caliburn.Micro to ease some of the repetition in XAML - particularly around binding.

This has also worked out well, resulting in nice applications, but again there are some things that bother me:

• First and foremost I detest writing code in XML. So I'm not a fan of the XAML language at all. You might, at this point, say that XAML is meant to be generated by tools, not written by humans. And you may be right. Nonetheless, my experience is that you do write most of your XAML by hand. I find doing that to be much quicker and more maintainable than using Blend or Visual Studio to edit XAML.
• I don't like the code behinds. We've kept them quite small in the projects I've worked on, but they are still there tempting developers at weak moments to hide untestable code.

The things I really like are:

• As with JavaFx it's fairly simple to run the views headlessly for testing. Again this enables an acceptable TDD workflow. Again albeit somewhat slow.
• Databinding works very well. Especially with some conventions in place to cut down on boilerplate code.
• Datatemplates in particular enable keeping the views declarative.

Conclusion?
Hmm, I don't think I have enough data here to conclude much. What I will conclude though is that for building Windows applications my experience is that both JavaFx and XAML will get the job done, but it's faster to work with XAML, because the databinding is easier, the datatemplates help a lot and there seems to be less hand rolling controls.
Beware though: The projects I'm comparing are not the same, so there is a certain level of comparing apples and oragnes going on. Also this very subjective. So YMMV.

Update - 2012-12-21
Based on feedback I've decided the conclusion above is too vague. To clarify: In my experience both technologies work, but XAML is faster (and thus cheaper, and faster to market) to work with.

WPF View Smoke Testing

I enjoy TDD. I enjoy the way it makes me code and I enjoy the rhythm. That is, I really enjoy TDD'ing the logic in my applications: The business logic, the controller logic, the domain logic; wherever there is logic that I can isolate and unit test cleanly TDD is just all fun and productivity. I enjoy TDD'ind integration points a little less: The database access, the web service calls, and so on are slow to test, so the TDD rhythm is broken. I still prefer TDD'ing these parts too though. I do not enjoy TDD'ing UIs: In my experience the tests are slow, either the rate of false negatives is high or the rate of false positives is high, and UI test are a pain to write (don't even get me started on the horrors of recording UI tests). Therefore I usually settle for subcut tests and manual UI testing when it comes to views. That is: I want to TDD my presentation logic, but am usually ok with checking that the pixels are in the right spot manually.
Working with WPF this is - at first sight - supported by MVVM: The view models sit right under the views, and are able to cut the .xaml.cs code behinds down to (almost) nothing, so testing the view models is subcut testing right? Right?? Not quite: There is a little bit of stuff going on in the bindings. I want to test that stuff.

WPF has been around for a while so I expected this to be a solved problem. Maybe it is, but my googling didn't yield an answer. It did however yield a number of candidated solutions. Below is a quick summary of my evaluation I of these candidates. (TLDR: None of the libraries worked, but Window.Show and FrameworkElement.FindName turned out to be my friend, and maybe, just maybe. Approval Tests could finally win me over to UI testing).

Notes From My Evaluation

Below there is a section for each of the candidates I quickly evaluated with some rough notes on how it went. The evaluations are not terrible thorough nor objective, so YMMV 

IcuTest

IcuTest is a library that works by asking you the first time a test is run to accept or reject the result: It shows you a snapshot of the window to assert on, and you accept or reject. If you accept the image is saved and used as the acceptance criteria in subsequent runs.
I have a few issues with this: The asserts come down to bitmap comparisons, which means (1) that they are imprecise - they assert on the whole window/control instead of just the one thing the current test is about and (2) they depend on the machine the test is running on. These are execatly the issues with UI testing that have bitten me in the past. So IcuTest is not what I'm after.

White

White seems to be the most grown up UI testing framework for Windows applications around. Promising. But: I installed the NuGet in my projects and was immediately sent into the Log4Net strong naming cirkus. Annoying but not Whites fault.I went on to clone the source off Github. It compiled out of the box, but most of the tests failed. After fiddling around for a few hours I got like 60% of the tests running. Not a good sign to be honest. The fiddling included changing things like which properties were used to input text into a textbox in ways that were pure guessing on my part. All in all this seemed like a route that would lead to unstable tests. So White is not what I'm after.

AvalonTestRunner

The AvalonTestRunner is an old thing from back when WPF was still Avalon. It doesn't claim to do a lot either. But none of these are bad things in themselves. If it works it works. One of the things AvalonTestRunner claims to do is sanity check all the bindings in a view: I.e. throw an exception if there is a binding path that is not found in the data context. That is part of what I'm after and actually a quite nice first line of defense to have. Only problem: I couldn't get it to work, not out of the box and not after debugging through the source for a while. Maybe it's just me, but again I concluded: AvalonTestRunner is not what I'm after.

Guia

Guia seems to try to solve the same thing as white but only for WPF. It also seems defunct: The current version is 0.1.1 and is 2 years ole (at the time of writing) . But again: If it works it works. Sadly it didn't work out of the box, and because of the lack of activity I didn't investigate further. Guia is not what I'm after.

Hand Coding

With all the libraries I tried out not really working I'm left with hand coding the tests myself. As it turns out this is in fact not nearly as bad as it sounds  - not for the subcut type of tests I'm after anyway.

MS UI Automation lib

MS UI Automation is a library intended to support building screen readers, remote controls and other types of applications that need to automate the UI of some other - known or unknown - application. It seems to provide everything you'd need to write UI test for WPF. I haven't tried it out though because it seems like overkill for what I'm looking for.

.FindName

As it turns out I probably shouldn't have spent so much time wading through testing libraries because the simple little kinds of tests I set out to write: Tests that drive and check the bindings in my XAML are actually (for the most part at least) easily written by just opening the window under test directly, finding the controls of interest by calling .FindName on the window under test and then manipulating or asserting against properties on those controls. Like this:

This is so darn easy, that once I realized, that this is actually what I am after I stopped looking at libraries although there are still a couple on my list. So there you have it: It's just not complicated enough to need a library.

Promising ones I haven't gotten around to evaluating

In spite of the conclusion above the following may be worth checking out. I'm pretty sure at least ApprovalTests work although I haven't tried it. WhiPFlash seems active, but beyond that I know nothing.

ApprovalTests

WhiPFlash

Exploring a WPF Business Application Architecture 1

I've been spending some time looking into how to easily build WPF based line-of-business applications lately. To illustrate my thoughts on that subject I'll put together a sample based on the time honored Java Pet store. In this post I'll write a bit about the type of application I'm aiming for, the pet shop, and the architecture I'm aiming for. In a series of following posts I'll show how the domain model, the persistence, the presentation and so on are coded.

So, I'm not trying to figure out how every WPF app should be architected. Far from it. I'm trying to figure out a default architecture for moderately sized business applications. I.e. apps that: Use WPF for presentation, use an SQL Server database for persistence, runs on an intranet, has in the order 100 - 200 unique users, has moderate to large amounts of data (not huge, though), and no special security issues.

To illustrate I'll use a pet shop: The users can browse through categories of pets, put them in their shopping cart, and eventually check out and pay for the pets.

The plan is to use the MVVM pattern which is a variation on MVC, that focuses on allowing for use of WPF's 2-way data binding while still allowing for separation of concerns. The domain model is nicely separated from the view by the view model, which adapts the data in the domain model to the needs of the view. The presentation logic is pulled out of the code behind files to keep it separated from the view itself. All-in-all MVVM delivers a nice structure that allows for good testability and maintainability. To implement this part I might use Caliburn or PRISM or I might do it by hand. I haven't decided yet.

For the persistence of the domain model to the database I'll use Castle.ActiveRecord which is build around Fowler's Active Record pattern: Each domain object is responsible for its own persistence. Each domain class maps to a database table and has CRUD operations. Each domain object corresponds to a database row. Castle.ActiveRecord makes it really easy to use the Active Record pattern: You just have to add a few attributes to the domain classes and their persisted fields and off you go. Your domain objects are still POCOs except for the attributes, so you get to keep your domain object clean and almost-free of infrastructure.

Lastly I plan to throw in Castle.Windsor for dependency injection.

That's it for now. Next post will be about the pet shop's domain model, and about persisting it through ActiveRecord.