I have posted an alpha version of CSLA 4 version 4.3.0 for download from the CSLA download page.

Although Jonny has been extremely busy with a number of bug fixes and some feature changes, I think the biggest change in this alpha release is a major optimization of the MobileFormatter.

MobileFormatter is used to serialize object graphs on Silverlight and Windows Phone. It is used by the data portal, and n-level undo (if you use that feature).

Until now, I have recommended that you use compression on the byte stream that flows over the data portal, because the XML created by the MobileFormatter is often quite large. It compresses efficiently, and we’re quite efficient about what we put into the byte stream, but it is just plain big.

Sergey did some really nice work for version 4.3, allowing the use of alternate reader/writer objects so the data can be serialized into something other than XML. Specifically, he created binary reader and writer objects that are around 70% more efficient in terms of byte stream size. That’s about as much as you could expect to get with compression!

The result is that you can probably avoid the CPU intensive overhead of compression and still get a small byte stream to transfer over the network.

This is a non-breaking change, because the default is the same behavior as in 4.2. But this is a big change and we really appreciate your help in testing the new reader/writer objects to ensure they work across a wide range of applications.

If you purchased the Using CSLA 4 ebook series you already own the book, and can download it now.

This ebook (in PDF format) demonstrates how to create a Windows Phone 7 (WP7) application that uses a business layer created using CSLA 4. This ebook also demonstrates the use of the MVVM (Model-View-ViewModel) design pattern in a way that is very complementary to the capabilities provided by CSLA .NET business objects, resulting in an application that is easy to build and maintain with clear separation of concerns between the XAML-based view, the interface control code in the viewmodel and the model composed of CSLA-based business objects. This ebook also makes use of the open-source Bxf MVVM UI framework.

The ebook includes a sample application demonstrating the concepts and techniques discussed in the book.

The primary focus of this release is the introduction of support for mono (Mac, Linux), monotouch (iPhone, iPad), and mono for Android.

This version also supports Windows Phone “Mango” (SDK version 7.1).

You can now reuse your business code across .NET, Silverlight, Windows Phone, and these newly supported platforms as well. As demand grows to build applications that must work on various mobile devices, the ability to directly reuse your business classes is compelling!

Version 4.2 also includes a number of enhancements to the existing CSLA 4 rule engine, along with various other features and bug fixes. Check out the change log for more information.

Our next step is to provide support for Silverlight 5 in CSLA 4 version 4.3, followed by support for WinRT (Windows 8) in version 4.5. The expectation is that your existing CSLA-based business classes will continue to work in Silverlight 5 and WinRT, providing even more long-term reuse, maintainability, and cost-effective development.

The Beta 1 release of CSLA 4 version 4.2 is now available for download on the CSLA download page.

This version adds support for:

Windows Phone 7.5 “Mango”

mono

mono for iOS (iPhone/iPad)

mono for Android

Of course it continues to support .NET 4 and Silverlight 4.

This release also includes numerous bug fixes and small enhancements. In particular, Jonny has done a lot of work to make the business rules subsystem more flexible and powerful. See the change log for a list of all changes.

At this point we have spent zero time or effort on the samples. Most samples will continue to run when bound against the 4.2 assemblies, but some may encounter minor issues. The samples in the download are still bound to the 4.1 assemblies. We will be updating the samples during the 4.2 beta phase.

Because of the organizational changes of mono from Novell to Xamarin, the 4.2 release has taken a lot longer than any of us would have preferred. I am pleased that we’re entering the beta phase, and can now move deliberately toward a release.

If you are using 4.1, I strongly recommend that you test your code against 4.2. In part to help us identify any outstanding issues, and in part because the bug fixes and enhancements to the rules subsystem may be very helpful to you.

Bxf and CSLA .NET both include a TriggerAction control. This control helps support the MVVM design pattern in WPF, Silverlight, and WP7 applications.

(Bxf is completely independent from CSLA – I donated TriggerAction from CSLA to the Bxf project a while back though, so this type is available from either framework)

The specific problem addressed by TriggerAction is the need to invoke a verb (method/command) on your viewmodel object in response to any arbitrary UI event. One common UI event is something like a button click event, though you can often use commanding in that case. But there are numerous other UI events from many controls other than buttons, and you might want to have one of those UI events cause the viewmodel to perform an action.

TriggerAction basically wires arbitrary UI events to methods on the current DataContext (usually the viewmodel object).

TriggerAction listens for the trigger event from the TargetControl. When it handles that event, it invokes the specified method (MethodName) on its current DataContext object. There’s nothing more to it.

To get TriggerAction working you need two things: source and target.

Source:

TargetControl must be set

TriggerEvent may be set (default is “Click”)

Target:

DataContext must be set (or inherited from the container)

MethodName must be set

Parameter (optional):

MethodParameter may be set (to a value or binding expression)

RebindParameterDynamically may be set to true (to force rebinding of MethodParameter to work around issues with certain control properties such as ListBox.SelectedItems)

The most common causes of failure when using TriggerAction are that the TargetControl isn’t set right, or the DataContext isn’t set right, and of those two the most common is that the DataContext isn’t what you think it is (that happens to me all the time).

The method TriggerAction invokes on the DataContext object can accept either 0 or 2 parameters:

public void MyAction()

or

public void MyAction(object sender, ExecuteEventArgs e)

The ExecuteEventArgs class is also defined in Bxf and CSLA. If you use TriggerAction from Bxf.Xaml, you must use ExecuteEventArgs from Bxf.Xaml. If you use TriggerAction from Csla.Xaml, you must use ExecuteEventArgs from Csla.Xaml.

If you are using Bxf and CSLA together it is important to understand that the ViewModel<T> class from Csla.Xaml uses the Csla.Xaml.ExecuteEventArgs type. If you are using the Bxf TriggerAction control, you’ll need to create your own viewmodel types from Csla.Xaml.ViewModelBase<T> to accept the Bxf.Xaml.ExecuteEventArgs type.

Although there are numerous new features in version 4.1, the primary focus of this release is Windows Phone 7. With CSLA 4 version 4.1 you can now author business classes that run unchanged across the entire .NET platform:

Windows Phone 7

Silverlight

WPF

ASP.NET MVC

ASP.NET Web Forms

WCF services (SOAP and REST)

asmx web services

Windows Forms

The ability to reuse your business layer on .NET, Silverlight and WP7 is incredibly powerful, enabling you to extend your application to users on Windows, the web, and now the phone.

You can learn how to use CSLA 4 to build scalable, flexible, and maintainable applications through the Using CSLA 4 ebook series. This ebook series is currently a work in progress and will be finished in the first half of 2011.

I’ve had it for a while now (since launch date in the US), but wanted to wait a little before blogging about it to really get a good feel for what I do and don’t like.

Also, by way of disclaimer, I’m coming to WP7 from Windows Mobile 6.5, so I can’t compare and contrast to other modern phones like iPhone or Droid.

In short, I really like Windows Phone 7, but there are better devices than the HD7 (unless you are on T-Mobile).

Coming from an older phone like I did, the new WP7 phone OS is remarkable. Wonderful. Truly a joy to use! And the HD7 has enough cpu, graphics and memory to make it fast and very enjoyable.

My only real issue is that the HD7 device’s camera button is so hard to push that it is almost impossible to take a good picture, which makes the camera nearly useless. That’s not the fault of WP7, that’s the fault of some HTC engineer with overdeveloped finger muscles or something…

The WP7 user experience is smooth and intuitive. It is loosely based on the Zune HD user experience, but Microsoft clearly learned a lot from the Zune HD about what did and didn’t work, and the phone’s user experience is consistently pleasant and easy.

One of the most touted features of the phone are the the “live tiles” on the home page. And they are nice. I’ve got mine customized to show phone, people, email and weather on the very first page, with messages and a few other commonly used items further down. There are a few other apps I’ve used now and then that I haven’t put on the home page, because it is just as easy to get to them using the voice navigation.

The cool thing though, is that the weather status and my wife’s Facebook status are shown on that front page through the live tiles, so the most important information is always right there

I’ve downloaded some free and commercial apps from the Marketplace. That’s a seamless experience, and includes seamless updates of the apps as they become available. My only quibble with the Marketplace is that it doesn’t seem to filter between apps, music, videos, etc. So sometimes searching for an app can be tedious because it seems that a lot of songs use the same words in their titles, so it can take some time to sift through the songs to find the app you want…

In terms of apps, there are only three apps I am missing at this point:

Bing (I want the voice-prompted navigation that comes with the Bing app – the built-in Maps app is ok for maps, but horrible for actual driving navigation)

TripIt (the mobile web access is OK, but a smart client experience would be a lot better)

EverNote (here the smart client (with offline caching of notes) is really important, and the web interface is a poor substitute – enough so that I’m considering migrating back to OneNote where I can share everything on my SkyDrive)

In terms of phone features, the only thing missing is tethering and/or using the phone as a wifi hub. My 6.5 phone did both of those things and I used them constantly, so losing this ability is a serious drawback. If I wasn’t such a Microsoft loyalist the lack of tethering would probably have prevented me from getting this phone – but as it is I’ve chosen to live with the pain.

On the other hand, the way WP7’s “hubs” integrate together is wonderful. The People and Pictures hubs, for example, automatically pull data from Facebook, Live, Outlook and so forth – automatically bringing together nearly all the information I care to see about everyone I interact with. This type of automatic data integration is amazingly useful, and directly increases my productivity from a business and inter-personal perspective.

And of course the fact that the phone is a Zune device (and so can use my beloved zune.net subscription) is just icing on the cake. While I still carry my Zune HD when traveling because it has enough memory to hold all my songs, I do have a couple Smart DJ playlists synced to the phone for times when I’m sitting somewhere and just need a little music. I always have the phone, but don’t always have the Zune HD.

Finally, there’s Netflix. The high-res screen on the phone makes watching video content reasonably enjoyable. Not comparable to a TV or even laptop screen of course, but certainly workable. So again, when I’m sitting somewhere and feel like a little diversion there’s always Netflix content available.

Would I recommend that someone get a WP7 device? Absolutely – WP7 is a joy to use!

Would I recommend the HD7? Probably not, but if you are on T-Mobile you are kind of stuck… And really, other than the stupid camera button, it is a perfectly decent phone (I really like the large screen and overall form factor).

I just put CSLA 4 version 4.1 beta 2 online for download. This is probably the last beta release of version 4.1, so please download and try it – I appreciate any help I can get in testing these releases.

Added a new Csla.Xaml.PropertyInfo control for WP7, WPF and Silverlight that is like PropertyStatus but totally non-visual. See the Samples\NET\cs\SimpleNTier solution’s WP7 UI project for an example of how this works

Created a copy of the DataAnnotations functionality for WP7; this is a nice concept that Microsoft didn’t put into WP7, so I ported the parts of System.ComponentModel.DataAnnotations required by CSLA .NET, so if you have classes using DataAnnotations attributes in .NET or Silverlight, that code will now work in WP7 as well

Laying the groundwork for a NuGet installer when 4.1 is released, so people will be able to download and install CSLA 4 via NuGet (thanks Jaans!)

Laying the groundwork for a vsix installer for Visual Studio templates, so when 4.1 is released we can add this to the Visual Studio gallery (thanks Jonny!)

This ebook is incomplete, but I’m providing work-in-progress drops of the book as I work on it. People who’ve purchased the entire Using CSLA 4 ebook series (from http://store.lhotka.net/) can download this pre-draft content. This new drop includes a lot more content than the previous drop – including the entire sections on declaring and implementing properties and methods, and a good start on the metastate fields/methods available from BusinessBase and other base classes.

Finally, I also put a top level type diagram online that is available to anyone who has purchased either the Using CSLA 4: CSLA .NET Overview ebook or the entire ebook series. It is available from the same download.lhotka.net web page.

I can understand that, because I was an anti-digital-music person for a long time. My thought was that I had no reason to pay for a music subscription when radio was free.

Of course radio isn’t free, and over time (as I’ve gotten older?) I find the DJ dialog and commercials on radio to be increasingly annoying. To the point that radio costs way too much – there’s less music than drivel and I just can’t take it.

The other alternative is to buy CDs, rip them and create your own collection. That way you “own” the music. And certainly compared to buying digital MP3s it is better to buy the CD. I’ve “purchased” digital music several times over the years, and several times I’ve had the originating company go out of business and so the DRM locked me out of my “purchase”. And I’ve had hard drive failures, and so lost my “purchase”.

Sure, a CD can get scratched, but if you buy a CD, rip it and then only use the digital copy, you always have the pristine master source, even in the case of hard drive failure.

However, a CD costs around $12, and zune.net costs $15/mo. So I can buy around 12-13 CDs each year, or I can spend the same money to have access to a few hundred thousand songs. Even over my entire lifetime, at 12 CDs per year I’ll never get a collection the size I have access to via zune.net.

So radio is out (because it just sucks), and buying CDs isn’t really cost-effective.

But there are streaming services like pandora and last.fm and others. They are free, or at least cheaper than zune.net, so why not use them?

I used to use pandora, but it started getting pretty flaky with its song selections. Lately I’ve been using last.fm because they came with my xbox gold subscription (and zune.net didn’t until recently). I like last.fm, they do a good job and they stream to my xbox and my Windows Phone 7.

However, streaming services don’t work when I’m on an airplane, in a hotel (you never get good bandwidth in a hotel), in northern Minnesota camping or fishing, etc. Basically they are for city people who don’t travel, not for people like me who travel and/or spend a lot of time in rural areas.

So how does zune.net differ from things like radio, CDs or streaming services?

For about $15/mo you get this:

Access to several hundred thousand songs via streaming

10 free purchases (DRM free) each month (basically I get to “buy” for free almost an entire album every month)

Smart DJ, which does what pandora and last.fm do: creating a themed “radio station” drawing music from my personal library plus the entire zune library (those hundreds of thousands of songs)

The ability to sync Smart DJ playlists to my zune device or Windows Phone – so that music is available when I’m entirely offline

So think about this. For just over the price of a CD I get (more or less) a CD’s worth of music I actually own each month. I figure that’s $10 of the $15 covered each month right there.

But more importantly, for my other $5/mo I get unlimited streaming just like pandora or last.fm – and in a form that works when I’m entirely offline like on an airplane or sitting on a lakeshore in far northern Minnesota where there’s no cell coverage, much less Internet.

(it is this pure offline feature that even iTunes doesn’t have – and why zune.net is (for me) the ultimate solution)

In the end, yes, I understand the arguments against paying a subscription fee for music. But when compared to the alternatives, it has become clear to me that none of those arguments really hold water. The zune.net service is pretty much the perfect way to consume music.

Over the past few months there’s been this ongoing buzz about whether WPF is dead, or whether Silverlight is really mature – in short, people trying to figure out whether to use WPF or Silverlight or both.

Having worked with WPF since it came out, and with Silverlight 2.0 and higher since before it came out, I thought I’d share my thoughts.

This post flows from my experiences with CSLA .NET, UnitDriven and Bxf – three frameworks I’ve created or been directly involved with, that run on WPF (.NET), Silverlight and now Windows Phone 7 (WP7). With CSLA in particular, I’ve been maintaining this one codebase on .NET since 2001, and to my knowledge it was the first major framework ported to Silverlight from .NET. Also, as I write about this, I’m thinking about how I build XAML-based apps, using the MVVM pattern as discussed in the CSLA 4 MVVM video series and some of my previous blog posts.

The way I use SL and WPF there is no meaningful difference between them. My MVVM demos, for example, are mostly the same across WPF, SL and even WP7.

The business layer, created with CSLA 4, is typically identical across all three platforms. That’s one of the big benefits of CSLA 4, in that you can write your business, validation and authorization rules once and use them across multiple interface technologies. And with the data portal managing any interactions with the application server, you are shielded from any complexity or differences you’d normally encounter there as well.

The way I use MVVM, with a strong focus on having zero code-behind any XAML, means that nearly all interface control logic (any actual code in the presentation layer) is also reused. Any presentation layer code is either in the viewmodel, in value converters, in attached properties or custom controls. This reuse isn’t always 100%, especially when you get to WP7, because the tiny phone screen often forces a different user workflow than if you have a full-size screen like in WPF or SL. But between WPF and SL, the viewmodel code is typically the same, as is most value converter and attached property code. Some custom controls may be different – again especially on the phone.

This commonality of viewmodel code is thanks to the use of Bxf. But any decent MVVM framework will offer the same kind of abstractions, so your application code is never directly interacting with the UI shell or any platform-specific constructs or types.

With WPF and SL there are places of direct difference however, depending on how you structure your user experience.

WPF doesn't have a URL based navigation scheme or a navigation framework, so you have to come up with your own UI framework to manage any sort of navigation model. I usually do this by having exactly one Window, and that hosts all my content in the form of UserControl objects, but you could use many Window objects.

SL does have an optional URL based navigation scheme and framework, which is nice - makes things simpler. However, you can use the same "one Window that hosts UserControl objects" model just like WPF (hence my samples are the same). What you can't do is have a lot of Window objects (which to me is no loss, since the multiple SDI interface went out of style in 1997).

WP7 also has a URL based navigation scheme and framework. I still use the hosted UserControl idea too, and that makes a lot of the code common with SL and WPF.

I think the thing to understand, is that while SL runs in the browser, it is a smart client technology. It is far more like WPF than like HTML. In fact it is virtually identical to WPF in most ways that matter for a business app.

And the key to my success in this area, is that all my business “forms” or “pages” are always a subclass of UserControl. So every bit of meaningful UI content (forms/pages) are UserControl objects that can be hosted by the UI shell. This means that I can usually change out the shell, or even have different shell styles (URL navigation vs Outlook-style navigation for example) and this has no effect on the actual business UI elements. Yes, the shell code may be different, but the business code is unchanged.

This is one powerful technique that makes it quite realistic to create your app in Silverlight, even using the navigation framework, and then port it to WPF if you need to in the future. You might have to write some new WPF shell code, but your UserControl XAML, your viewmodels, your business domain objects, your data access code and your database remain unchanged.

Beyond UI and navigation differences, there are some technical differences between WPF and SL, including:

Some minor, niggling differences in XAML - this is the sort of thing I personally want fixed now that the WPF and SL product teams have merged - this niggling differences are stupid and are nothing but an annoyance – why is the binding Mode default different between WPF and SL (for example)??

SL requires that all server interactions be async, WPF allows sync or async - I tend to use async in both places, because the user experience is so superior with async, I can't figure out why I'd want to punish my end users just because they are using WPF

SL has the navigation framework, WPF doesn't

WPF has an application model that includes navigation, but it is hopelessly broken - it tried to emulate the worst features of the web without any of the benefits - to me this is the "ActiveX Documents" of WPF

WPF apps can use all of .NET, SL uses a subset - but the SL subset is everything I've needed to build typical business apps

WPF apps can interact with the full client workstation hardware (odd peripherals, the full hard drive, etc)

WPF apps are (typically) deployed via ClickOnce, SL apps are deployed transparently via the browser - so WPF is slightly more "in your face" for your users, but the difference should be pretty incidental

WPF apps can tap into all of DirectX, though SL now has hardware acceleration for some graphics scenarios too - so this difference is probably less meaningful for most business apps than for games

SL doesn't have the complexity of the legacy "crap" that comes with WPF (DataSet, IBindingList, etc) so it is a simpler, easier and more consistent programming environment

SL runs on Windows, in the browser, on the Mac, in the browser on the Mac, and in WP7; WPF of course runs only on Windows

Again however, I come back to the same thing - I always use as little of any platform/technology as necessary to get the job done. SL is a subset, so if I can get the job done with SL then that's the best thing to do (I can always upsize to WPF later if necessary). If I can't get the job done with SL, I'll use WPF.

In my mind it is a superset/subset decision - always default to the subset that meets your needs.

As long as you understand both technologies, you can architect your UI so transitioning from SL to WPF is relatively easy (the other way isn't always so easy - because your WPF code might use superset technologies).

In conclusion, my recommendation has been (since SL3 at least) to design your app for SL, and fall back to WPF only if SL can’t meet your needs. The most common scenarios for business apps to fall back to WPF are:

Your app is only occasionally connected, and is mostly offline, so you use a client-side database like SQL Express or SQL CE

Your app needs to interact with client-side peripherals

Your app needs full access to the client-side hard drive

I don’t think this is a “WPF vs SL” thing at all. I think it is a sliding scale, where you default to SL, and slide up to WPF if necessary. All the angst is unnecessary.

The first WP7 app built by Magenic is now in the WP7 app marketplace: GuestList.

This app allows you to easily check in attendees at an event, using EventBrite as the backend service. You create your event in EventBrite, users register through their web site, and as they arrive at your event you get the attendee list on your phone, and easily check them in right there.

Chris Williams (Microsoft MVP and author of an upcoming WP7 developer book) did the development on this project, with assistance from Donn Felker (author of a similar app for Droid). Anthony Handley (from our Magenic Studios group) created the user experience flow and look and feel.

With this release, it is now possible to write a single business layer composed of business domain objects that run unchanged on a WP7 device, in Silverlight, on a Windows client, on Windows Server and on Windows Azure.

The samples download includes Samples\Net\cs\SimpleNTier, which does implement the following interfaces over one common business layer:

Windows Phone

WPF

Silverlight

ASP.NET MVC

Of course this is just the first beta release, so there’s more work to be done. At the same time, we have completed the vast majority of the effort, and it is quite possible to build WP7 applications using this beta.

As with all CSLA releases, this one does include some bug fixes and enhancements to other parts of the framework. Please see the change log for a list of all changes. Enhancement highlights include:

Add ability to get a consolidated list of broken rules for an object graph

New BackgroundWorker component that automatically initializes background threads with the current principal and culture from the UI thread

TriggerAction provides better debugging information, following the lead of many Microsoft XAML controls

and much more…

In related news, UnitDriven has also been updated to support WP7, and provides a pretty comprehensive unit test runner and framework for WP7 code. CSLA uses UnitDriven for its automated testing, but UnitDriven can be used for any application on .NET, Silverlight or WP7.

Similarly, Bxf (Basic XAML Framework) has been updated to support WP7, thereby providing a common MVVM framework for WPF, Silverlight and WP7 UI development efforts. Some CSLA sample apps use Bxf, but Bxf can be used for any application, including those that don’t involve CSLA at all.

This is kind of a running commentary, or personal log (stardate July 2010), recording the various things I had to do to get the CSLA 4 Silverlight codebase to build in the WP7 (Windows Phone 7) beta SDK.

This has nothing to do with getting anything actually running – this is just the stuff I had to change to get the code to compile.

To create the Csla.Wp project, I just linked in files from Csla and Csla.Silverlight. There are almost no actual files in Csla.Wp – it is almost completely reusing the same code used to implement Csla.Silverlight. That’s really cool, as it means my maintenance burden is (theoretically) quite low.

(though this exercise did highlight the need for me to go through the Csla and Csla.Silverlight projects to remove all code files from the Csla.Silverlight project too – ideally there’d be exactly one of any given file, with a few #if statements to deal with platform differences – but that’s a task for another day)

Most of my issues building on WP7 turned out to be caused by the fact that CSLA 4 targets Silverlight 4, and WP7 is based on SL3.

Missing: DataAnnotations

Missing: Reflection.Emit

Missing: Lambda expressions

Missing: string.IsNullOrWhiteSpace

Missing: Browsable attribute

Most of the DataAnnotations code I just had to block out with #if statements, though I did create my own DisplayAttribute class because I don’t want to lose that particular feature (the friendly name part). So business classes using that particular attribute should work fine, but the other DataAnnotations attributes won’t compile in WP7.

I also created my own BrowsableAttribute class, even though it doesn’t do anything. This saved me from littering tons and tons of code with #if statements, and I can’t see where it hurts anything to have this dummy attribute in my code. The attribute normally just affects the behavior of Visual Studio, which wouldn’t be affected either way.

The IsNullOrWhiteSpace method I just replaced with the (not as good) IsNullOrEmpty using #if statements. A little cluttered, but a workable answer.

What I’m working on now is the final part: dealing with the lack of lambda expressions and dynamic methods. Basically I need to revert the CSLA code back to using raw reflection in those cases, since none of the modern reflection alternatives appear to exist in WP7. That shouldn’t be too hard, as I can get most of that older code from earlier versions of CSLA and just put it into the existing codebase using #if statements (so I don’t affect the .NET or SL implementations).

Given the size and complexity of CSLA 4, I’m really quite pleased with the relative easy by which I’ve been able to get the code to (almost) build in WP7.